Pentester (Offensive Security)

A pentester, or penetration tester, is an offensive cybersecurity specialist who looks for and exploits vulnerabilities within an authorised scope. Their penetration tests help the business understand the risks its systems face and the fixes it should consider. Their work includes technical investigations and explaining the results to those responsible for making decisions or taking action.

The assigned scope may cover systems, networks and web or mobile applications. It must be defined before testing begins: the environments concerned, objectives, constraints and expected deliverables. The ability to work in one of these areas does not establish expertise in all the others.

Authorisation to test sets the limits of the engagement. When a component is discovered outside this scope, the pentester explains its significance to the risk owner. The risk owner may decide to extend the test or retain the original scope. In the latter case, this limitation must appear in the test conclusions. The tester does not decide on this extension alone.

Pentester, technical security auditor and developer: who does what?

• The pentester carries out the agreed penetration tests and reports the vulnerabilities, risks and recommendations.
• The technical security auditor covers a wider range of assessments, which may include configuration or code reviews. Not all of this work is necessarily part of a pentester's role.
• During relevant application tests, the developer receives guidance on coding practices to improve. The pentester provides useful findings without taking over from the organisation responsible for remediation.

A penetration test should help the business decide which vulnerabilities to address and how. A list of flaws offers little value if it does not explain the risks, the systems affected and possible solutions. The value of the work therefore also depends on analysis and reporting, beyond the technical discovery itself.

The organisation remains responsible for assessing risk and deciding on remediation. The pentester may not know every way a system is used or the business consequences of exploiting a vulnerability. Their rating must be discussed with the relevant people in charge. This discussion serves to assess the risk to the business, not to play down an uncomfortable finding.

For bespoke software and web applications, the results should give developers feedback on coding practices to improve. Plan reporting that connects each problem to the technical details needed to understand it. Discussions with IT teams help turn recommendations into possible fixes, whose implementation the organisation then decides on.

Hypothetical example: a business commissions a test of an application used by several departments. The report describes a vulnerability and proposes a fix. Before a priority is set, the application owner explains how the application is used and what exploiting the vulnerability could mean for those activities. The pentester provides the technical explanation needed for this decision, while internal managers organise remediation.

A poorly matched candidate can make this reporting more difficult: expertise that does not fit the environment being tested, conclusions that are hard to understand or poorly explained limits to the engagement. To define the recruitment requirements, connect each requirement to a situation the role involves. Network expertise should not be taken as evidence of proficiency with mobile applications. Similarly, look for the ability to report in a way that suits the report's recipients, rather than simply proficiency with tools.

• Agree with the commissioning party which systems to test, the objectives, constraints and expected deliverables.
• Prepare investigation scenarios suited to the environments and authorised actions.
• Look for and exploit vulnerabilities within the agreed limits.
• Document the tests carried out and the technical findings obtained.
• Analyse the vulnerabilities discovered and the risks they pose to the activities concerned.
• Propose fixes and explain their objectives to IT teams.
• Present the conclusions in a report suited to its recipients.
• Flag components outside the scope and refer any proposed extensions to the risk owner.

IT education pathways at French bac +3 to bac +5 level, with a specialisation in cybersecurity, are reference points described by ANSSI for technical security auditing. They do not establish a mandatory qualification for every pentester role.

A relevant pathway should develop an understanding of operating systems, networks and applications, followed by the ability to apply this knowledge in an investigation. The knowledge and skills acquired also cover conducting tests and analysing results.

The École 2600 framework includes a simulated technical audit, a detailed report and a presentation to experts. However, it covers a broader field than pentesting alone.

A certification alone does not guarantee the autonomy needed to carry out an engagement from start to finish.

The common foundations of GetPro's assessment approach

GetPro uses a search criteria matrix that prioritises the requirements of the role and assigns an assessment method to each. It distinguishes aspects of a candidate's background that can be verified from skills to explore further at interview. Open questions and concrete examples are used to examine the key criteria. Reference checks complement this analysis by placing skills in the context of a past working relationship.

Adapting the assessment approach to a pentester role

The steps below suggest an adaptation for this role. They do not describe a specific protocol used by GetPro. You can adapt them to the environments and responsibilities of the position, particularly when designing a practical exercise.

1. Define criteria linked to the expected work

Separate essential skills from specialisms that are useful only for certain engagements. Name the systems to be tested, the expected deliverables and the decisions the candidate will need to refer to a person in charge.

Build a short assessment matrix around technical understanding, the investigative approach, respect for the agreed framework and reporting. For each criterion, distinguish what the candidate does independently from what requires support.

Treat a precise explanation of the environments they know well as a positive sign. Probe answers that claim universal expertise without corresponding examples of work.

2. Examine a past piece of work

Ask the candidate to describe an engagement whose details they can share without breaching their commitments. Have them specify the objectives, authorised limits, their own work and the conclusions delivered.

Ask about a choice of scenario and a difficulty they encountered. Ask what they were able to conclude, what remained uncertain and how this limitation appeared in the report.

Look for a clear distinction between tool output, an analysed finding and an explained risk. A string of tool names without a rationale for the approach calls for further questions.

3. Set an authorised practical exercise

Prepare an exercise representative of the role in an environment explicitly intended for assessment. Provide the objectives, permitted actions and expected deliverables before starting.

Hypothetical example: you give the candidate findings from a test application and ask them to prepare a short presentation of the results. Ask them to distinguish established findings from the information needed to assess their impact.

Ask for an explanation of their priorities and a report extract. Observe the consistency between the available evidence, the conclusions drawn and the recommendations.

Value the ability to recognise missing information. Treat a categorical conclusion that the candidate cannot connect to the evidence in the exercise as a warning sign.

4. Assess communication and autonomy

Ask for two explanations of the same finding: one for a technical contact, the other for a business manager. Assess how much precision is retained when the vocabulary becomes more accessible.

Then present the discovery of a component outside the scope. Look for a response that explains the problem and seeks a decision before any extension of testing.

If the role includes leading an engagement, ask the candidate to explain how they would allocate the work and prepare the reporting. Limit this criterion to the responsibilities actually envisaged.

5. Arrange technical input and reference checks

If your business does not have the necessary expertise, have the exercise and report examined by a specialist in the environments concerned. Ask HR to assess mutual expectations and working conditions.

With the candidate's agreement, use references to clarify the responsibilities they actually held. Ask about autonomy, report quality and communication with teams.

Compare this information with your interview observations. Document the skills established, remaining uncertainties and planned support before deciding.