Severity disputes are normal in penetration testing.
A client may ask for a finding to be lowered. Another may ask for a finding to be raised. An engineering team may challenge exploitability. A risk owner may provide business context that was not available during testing.
The dispute itself is not the problem.
The problem is how the team handles it.
Handled well, a severity discussion can improve the accuracy of the report. Handled badly, it becomes defensive, political and expensive.
Severity is a judgement, not a negotiation
A severity rating should be based on evidence, impact, likelihood, exploitability and context.
It should not be changed simply because the client dislikes the finding. It should also not be defended blindly when the client provides valid new information.
This is where teams need discipline.
A severity discussion should not become a negotiation. It should be a structured review of the judgement.
The tester should be able to explain:
- what was proven
- what impact was demonstrated
- what assumptions were made
- what client context was considered
- what would change the rating
- what would not change the rating
This keeps the conversation grounded.
The client may still disagree, but the team can show how the decision was reached.
This is one reason technical pentesters need consulting skills. The issue is not just whether the tester understands the vulnerability. It is whether they can explain the judgement clearly when it is challenged.
Start with the evidence
The first question is simple: what was proven?
A finding should not rely on vague language or assumed impact. It should be clear what the tester did, what access they had, what result they observed and what security boundary failed.
For example, there is a difference between:
- proving access to another user’s data
- proving access to a function that may expose data
- identifying a control weakness that could be exploitable
- identifying a configuration issue with limited demonstrated impact
Those differences matter.
If the evidence is strong, the rating is easier to defend. If the evidence is weak, the team may need to review the finding before defending the severity.
A good severity discussion starts with the facts, not the rating.
This is where good QA in a penetration testing team matters. QA should make sure the evidence supports the conclusion before the report reaches the client.
Separate impact from likelihood
Severity disputes often become confused because impact and likelihood are mixed together.
A vulnerability may have high potential impact but low realistic likelihood. Another may be easy to exploit but have limited impact. A client may focus on one side of that equation and ignore the other.
The tester needs to separate them clearly.
Impact asks what could happen if the issue is exploited. Likelihood considers how realistic that exploitation is, based on access requirements, complexity, exposure, controls and other constraints.
Both matter.
If the client provides evidence that exploitation is less likely than first assumed, the rating may need to change. If the client only says “this would be hard for us to fix”, that is not the same thing.
Difficulty of remediation may affect priority and planning, but it does not automatically reduce security risk.
Client context can change the rating
The tester does not always have full business context during testing.
The client may later explain that the affected function is isolated, the data is synthetic, the system is being decommissioned or a compensating control exists. They may also explain that the affected workflow is business-critical, externally exposed or linked to sensitive customer records.
That context can matter.
Teams should be open to changing ratings when new, relevant information is provided.
This is not weakness. It is good professional practice.
The important point is that the change should be evidence-based. The report should explain why the rating changed and what context was considered.
This protects the team from looking arbitrary.
Do not overstate to make the client act
Sometimes testers overstate severity because they want the client to take the issue seriously.
That is understandable, but risky.
An overstated finding may get attention in the short term, but it weakens trust. It also creates problems when the client challenges the rating and the team cannot defend it properly.
Severity should be proportionate.
The role of the tester is to explain the risk clearly, not to inflate the rating to force action.
If an issue is low severity but operationally important, say so. If it is medium severity but affects a sensitive business process, explain that context. If remediation should be prioritised for reasons outside the technical rating, make that clear.
Good reporting can express urgency without distorting severity.
Do not lower findings just to avoid friction
The opposite problem is also common.
A client challenges a finding and the team lowers the severity too easily. This may avoid an awkward call, but it damages the integrity of the report.
It also creates internal problems.
Testers lose confidence in the rating process. Clients learn that challenge can change results. QA becomes inconsistent. Future findings become harder to defend.
A severity rating should change when the evidence or context changes.
It should not change because the conversation is uncomfortable.
Teams need to support testers in holding the line when the rating is defensible.
This is also a commercial issue. Poorly handled challenge can create rework, escalation and unplanned senior involvement. That is one way poor client communication erodes pentest margin.
Give testers a structure for the conversation
Junior and mid-level testers often struggle with severity disputes because they lack a structure.
They may know the issue is real, but not know how to explain the reasoning under pressure.
A simple structure helps:
- Restate the finding.
- Explain what was proven.
- Explain the realistic impact.
- Explain the relevant assumptions.
- Ask for additional client context.
- Explain whether that context changes the rating.
- Document the decision.
This keeps the discussion calm.
It also helps the tester avoid two common mistakes: becoming defensive or conceding too quickly.
This kind of structured client handling is why technical training does not fix every pentest team problem. A tester may understand the vulnerability, but still need development in judgement, communication and professional challenge.
Know when to escalate
Not every severity dispute should stay with the tester.
Some situations need senior review.
Escalation is sensible when:
- the client provides material new context
- the finding affects a sensitive system or major account
- the tester is unsure whether the evidence supports the rating
- the client is applying commercial pressure
- the dispute may affect contractual or compliance obligations
- there is disagreement between QA and delivery
The point is not to remove the tester from the conversation.
The point is to make sure the decision is controlled and defensible.
Senior involvement should be used carefully. If every severity challenge escalates, the team has a development problem.
Document the outcome
Severity disputes should leave a clear record.
If the rating changes, the reason should be documented. If it does not change, the rationale should also be clear.
This helps with consistency, QA and future client conversations.
A good record should capture:
- the original rating
- the client’s challenge
- any new context provided
- the review decision
- the reason for any change
- any remaining caveats
This does not need to be bureaucratic. It just needs to be clear enough that someone else can understand what happened later.
What this means for pentest teams
Severity disputes are part of professional penetration testing.
They are not a sign that the work has failed. In many cases, they are part of refining the accuracy of the report.
The important thing is to handle them with structure.
Teams should train testers to separate evidence, assumptions, impact, likelihood and client context. They should also give testers enough support to defend sound judgement without becoming defensive.
A good severity process protects the client and the provider.
It makes reports more accurate, reduces unnecessary escalation and helps the team maintain trust when findings are challenged.