Why technical training does not fix every pentest team problem

Imagine a tester whose reports keep coming back from QA with the same comment: the severity explanation is incomplete. As their manager, you want to help. A technical course is one option, but the rejected findings can tell you whether it is the right one.

One tester may misunderstand the access needed to exploit a weakness. Another may understand it but leave it out of the report. A reviewer may also be asking for information that the team’s own reporting guidance never required.

The QA comment can look much the same in all three cases. Talking through the work helps you see what kind of support would make a difference.

Start with the work that needed correcting

Start with a few recent examples of the problem. Reading a finding alongside the test notes, then asking the tester to talk you through it, makes their reasoning easier to follow. A report that passed review can be a useful comparison too.

You are trying to understand where the explanation broke down. If the impact is overstated, did the tester misunderstand the result? Or did they understand it during testing, then make a broader claim when writing it up? Those answers lead to different development work.

Keep the review specific to the work. A label such as poor judgement does not tell a tester what to practise. Feedback that a finding claimed access to records without identifying the account’s permissions gives them something to examine.

Match the response to the cause

Here are four ways that conversation might lead. These illustrative examples give you something to look for; the tester’s own work still needs to guide the response.

Observation	Response to investigate
The tester cannot explain the exploit’s preconditions, even with their notes	Technical instruction followed by a supervised exercise on those preconditions
The tester explains the result accurately, but the report omits a condition that changes its meaning	A worked reporting example and feedback on the tester’s next draft
The tester knows what evidence is needed, but left collection until access had expired	An evidence check during testing and a review of how time is allocated
Different reviewers require conflicting severity explanations	Agreement between reviewers on the standard, with examples of acceptable reasoning

A course may be appropriate in the first case. The remaining cases need changes closer to the work itself. More than one cause can apply to the same finding, so a development plan may need both technical instruction and supervised delivery.

Make practice resemble the decision

If the difficulty is explaining severity, use a finding the tester has already investigated. Ask them to write the rationale from their evidence without copying the final reviewer-approved text. Then compare the two explanations.

The useful feedback explains which part of the reasoning is missing and why it changes the conclusion. Let the tester make the revision. Replacing the paragraph yourself may get today’s report out, while leaving the tester unsure how to approach the next one.

For client handling, practise a specific objection. A reviewer might explain that a compensating control exists and ask the tester to respond. The useful part of the exercise is seeing whether the tester checks what the control covers before accepting or rejecting it.

Consulting skills develop through this kind of practice. A course can introduce the method; the tester still needs feedback when applying it to an unfamiliar situation.

Check what the delivery process allows

The conditions around the tester matter as well. If access ends before findings can be verified, evidence collection becomes harder. If QA starts once they have moved to another project, useful feedback arrives after the chance to apply it. An individual development action cannot resolve those scheduling problems on its own.

Also check whether reviewers are distinguishing material defects from preferences about wording. Repeatedly rewriting an acceptable paragraph can create the appearance of a capability problem.

A shared QA standard helps reviewers explain what must change and why. It also gives the tester a basis for checking their draft before submission.

Review the next relevant engagement

Agree the evidence that would show improvement. For the severity example, that might mean the next applicable finding states the access requirements and supports its impact claim without a reviewer having to reconstruct the reasoning.

Review that work with the tester. If the defect recurs, check which part of the agreed response failed. The exercise may have been too simple, the feedback may have been unclear or the working conditions may be unchanged.

A completed course tells you that training happened. The next relevant engagement shows what the tester can now do with it. Give them enough opportunity to demonstrate that before deciding whether the development action is complete.