Why technical training does not fix every pentest team problem

A manager choosing training for a tester needs to understand the work that prompted the request. Take a hypothetical case where reports repeatedly return from QA because their severity explanations are incomplete. Before buying a technical course, the manager should examine the rejected findings.

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 similar in each case. The response should depend on what caused it.

Start with the work that needed correcting

Take a small sample of recent reports with the recurring defect. Read the original finding alongside the test notes, then ask the tester to explain how they reached the conclusion. Include a report that passed review if one provides a useful comparison.

The discussion should establish where the reasoning or record broke down. For an overstated impact claim, check whether the tester misunderstood the technical result. If they understood it correctly during testing, find out why the written claim became broader.

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.

NIST SP 800-115 covers assessment planning and reporting as well as technical execution. That wider process is worth considering when a report defect is being treated as a training problem.

Match the response to the cause

The following examples illustrate different responses to a rejected finding. They are diagnostic starting points, not conclusions to apply without reviewing the work.

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 reviewer should identify the missing reasoning and explain why it changes the conclusion. The tester should revise their own work. If the reviewer simply replaces the paragraph, the report may be ready to issue while the development need remains.

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

Before assigning an individual development action, check whether the team gave the tester a reasonable opportunity to do the work. Evidence collection suffers if testing access ends before findings can be verified. Feedback arrives too late to help an engagement if QA starts after the tester has moved to another project.

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.

Course completion confirms that training happened. The next engagement provides evidence of whether the tester can use it. Keep the development action open until there is enough relevant work to make that assessment fairly.