How penetration testing teams should handle severity disputes

A client challenges the rating on a finding. They may know something you did not, or be facing a difficult remediation deadline because of that rating. Finding out what is behind the challenge gives you a much better starting point for the conversation.

Imagine the client explains that a network restriction prevents the access described in the report. That gives the team something specific to check: which systems and users does the restriction cover, and does it apply to the attack path demonstrated? Knowing that a control exists is only the start of that review.

Keep the original rationale to hand. It helps you explain which part of the assessment would change if the client’s information is confirmed.

Separate the parts of the assessment

Layer	Question	Record
Evidence	What did the tester directly demonstrate?	Test action, affected asset, access, result and limitations
Technical characteristics	What makes exploitation possible and what technical impact follows?	Scoring vector or equivalent rationale
Threat	What relevant exploitation conditions or current threat information apply?	Source, date and confidence
Environment	Which client-specific controls, exposure and business consequences change the assessment?	New context and who supplied it
Professional judgement	How do the preceding layers support the final rating and priority?	Decision, owner, date and rationale

FIRST’s CVSS v4.0 specification separates Base, Threat and Environmental metric groups. Use the rating method agreed for the engagement and identify which assessment is being discussed. Client context may affect an environmental assessment without changing the intrinsic technical characteristics represented in a Base score.

Where the engagement uses a different method, document how it treats those considerations. Avoid changing the basis of a rating during a dispute without making that change explicit.

Check the evidence and the new information

Begin with the result the tester observed. Identify their starting access and the security boundary involved. Check that the finding distinguishes demonstrated consequences from inferred ones.

Access to another user’s data differs from access to a function that might expose data. If the report makes the broader claim, the team needs to explain its basis before defending the associated rating. QA should examine that reasoning before the report is issued.

For the network-restriction example, request enough information to establish whether the control blocks the relevant path. If verification needs additional testing, agree the scope and timing of that work. Until then, record what remains unverified and how it affects the conclusion.

Revise the assessment when the new evidence warrants it. If the control applies to a different system or does not cover the tested route, explain why it leaves the relevant conclusion unchanged.

Keep remediation pressure separate

A difficult fix deserves a practical conversation about remediation. It does not, by itself, make exploitation less likely or its consequences less serious. Recording those discussions separately lets you agree a workable implementation schedule without quietly changing the meaning of the rating.

The same discipline applies when the client wants a higher rating to secure budget. Explain the significance of the issue using the available evidence. The report can describe a sensitive business consequence without changing a score that the agreed method does not support.

Teams also need to resist inflating findings themselves. An overstated claim makes the report harder to defend and can distract the client from the weakness that was actually demonstrated.

Give the conversation a sequence

Where the tester has the knowledge and authority, let them lead the explanation. A simple sequence can help them keep the conversation useful:

1. Confirm which claim or rating the client disputes.
2. Explain the observed result and the original rationale.
3. Review the client’s new information and identify any checks still needed.
4. Apply the agreed method and explain the resulting assessment.
5. Confirm the report changes and record the decision.

If the tester needs to check a detail, agree a follow-up rather than guessing on the call. Name the person who will do the check and state when the client can expect an answer.

Senior review is appropriate where the evidence is uncertain or the proposed decision exceeds the tester’s authority. Commercial pressure and disagreement between delivery and QA also need a defined escalation route. Keep the tester involved so they can understand the resulting decision and explain it afterwards.

Keep one decision record

For each material dispute, record:

• The original rating and its rationale, including assumptions at the time.
• The client’s challenge and any supporting information supplied.
• Checks performed, their results and any limitations that remain.
• The final assessment, with the reason for changing or retaining the rating.
• The decision owner and date, plus any separate change to remediation advice or priority.

Someone who was not on the call should be able to follow the decision from that record. Bring the report into line with the conclusion too, including a clear qualification where a control could not be verified.

Before closing the dispute, confirm who will tell the client the result. If the rating remains unchanged, explain which evidence was considered and why it did not alter the assessment. If it changes, preserve the reason so future reviewers can apply the same method consistently.