Why technical pentesters need consulting skills

Imagine a report debrief where the client challenges an invoice download finding. The tester has shown that an authenticated user can retrieve another customer’s invoice by changing a reference in a request. The client explains that the account belongs to a trusted partner. Both are talking about the same result, but they see its significance differently.

The tester can reproduce the request. The harder part of the conversation is establishing what the client’s objection changes. The account’s permissions need checking, including whether cross-customer access was ever intended. The sensitivity of the invoice also affects the assessment.

Showing the request again will only take the conversation so far. The tester needs to explain what it established, listen to the client’s information and agree what needs checking before the report is finalised.

Work through the client’s objection

The client may accept that the request worked while disagreeing with the risk described in the report. They may believe that the partner is authorised to see the information. They may instead be worried that the proposed fix will disrupt a legitimate workflow.

Those concerns lead to different conversations. Asking which part of the finding the client disagrees with gives you somewhere to start. If the question is authorised access, you need the business rule. If the concern is remediation, you need someone who understands how the function is used.

In this example, describing the partner as trusted does not establish that every partner account should have access to every customer’s invoices. The team needs to confirm the intended boundary. If that information changes the assessment, the report should change with it.

The detailed process for handling severity disputes helps keep that review consistent.

The tester should be able to describe the starting account and the request they changed. They also need to identify the invoice returned and explain why its owner matters to the finding.

Access to one invoice establishes a specific result. A claim that the user can download every invoice needs further support. The report can describe a broader potential consequence, provided it explains the basis for that inference and the limits of the testing.

That care matters in the conversation too. It is reasonable to say you need to check whether a restriction applies to another account type, then agree how to do that. A guess made to keep the call moving can become another claim someone has to defend or correct later.

OWASP’s reporting guidance expects reporting to serve technical readers as well as explain risk to an executive audience. A tester may therefore need to explain the same result differently to an engineer implementing the fix and to the person approving its priority.

These skills matter in everyday communication too. Before writing an update or joining a client call, clarify what the client needs to know and what decision they are trying to make. A useful written update explains progress, any uncertainty and the next step in language the reader can use. It also makes clear where you need information from them.

Give the client a recommendation they can use

A recommendation to improve access control leaves the engineer with substantial work to interpret. In the invoice example, the report should identify the download function and state which access must be rejected. It should also preserve legitimate access for the partner’s own customers.

The tester may not have enough knowledge of the application’s design to prescribe the implementation. They can still describe the required behaviour and what a retest would need to verify.

The client can then leave the debrief knowing what needs to change and how the fix will be checked. Their engineering team may still need to choose the implementation, but they have a clear problem to work on.

Give testers practice before difficult calls

Client explanation needs practice under supervision. Before a debrief, ask the tester to explain a finding to a reviewer who has not worked on the engagement. The reviewer can introduce a plausible objection and watch how the tester handles it.

The best feedback gives the tester something they can practise. Perhaps they defended the rating before understanding the objection, or accepted a control without checking whether it applied. Working through that moment makes it easier to see which question or evidence request would have helped.

Where a senior reviewer joins the client call, the tester can still lead the explanation. The reviewer should take over when the decision exceeds the tester’s authority or expertise. Afterwards, they can discuss what prompted the intervention.

That gives the next practice session a purpose. A tester can rehearse how to explain an unverified assumption; a general instruction to be more confident gives them much less to work with.

Close the discussion with a recorded decision

Before issuing the report, record whether the client’s information changed the finding. If a check is outstanding, give it an owner and agree when it will be completed. Keep any resulting qualification in the report so someone reading it later can understand the conclusion.

In the invoice example, the client and tester should finish with a clear account of the permitted access and the behaviour observed. Any difference between them needs to be resolved or stated as a limitation. That is part of delivering the finding, and it needs time in the engagement plan.