Push back on a pen test finding with evidence and a specific question. Reproduce the issue, say exactly which part of the claim you dispute (severity, exploitability or scope), attach what you tried, and ask the tester to confirm or revise. A written, dated reply protects both sides.
First, check whether you really disagree
Disagreement comes in four kinds, and each needs a different reply.
| You think... | Type | What to send |
|---|---|---|
| The issue does not exist | Factual | Reproduction attempt and the result |
| The issue exists but cannot be exploited here | Context | The control that blocks it, with proof |
| The severity is too high | Rating | Your reasoning on likelihood and impact |
| The affected asset is out of scope | Scope | The scope text from the statement of work |
Mixing these in one reply is the usual mistake. "This is wrong and also low risk and also out of scope" reads as defensive. Pick the one that is true.
Reproduce before you reply
Run the tester's steps exactly as written. If you cannot reproduce, record the environment, the build, the time and the output. If you can reproduce, you now have a real finding and a better conversation: how fast can it be fixed. Do not skip this step. A dispute that collapses on reproduction costs credibility you need later.
Ask questions instead of making claims
Testers often see things that logs and diagrams do not show. Phrase the reply as a request for the missing piece:
- "We could not reproduce step 4 on build 2026.10.3. Which environment and account role did you use?"
- "The request in the report returns 403 in our environment. Was a proxy or test header involved?"
- "We rate this as medium because it needs an authenticated admin. Do you have a path that avoids that?"
This keeps the exchange technical. It also makes it easy for the tester to say "good point, I will downgrade it", which is what you want.
Show the compensating control, with proof
If a web application firewall rule, network policy or feature flag blocks the attack, show it working. A screenshot of the blocked request, a config diff and the date it was tested is stronger than a sentence in an email. Be honest about limits: a control that blocks one payload may not block a variant. If the control is temporary, say so and put a date on the real fix.
Keep the paper trail
Write the outcome in the report tracker or ticket, not just in chat. Record the finding, your dispute, the tester's reply and the final rating. If the finding is accepted as a residual risk, record who accepted it and when it will be reviewed. Auditors and customers asking for the report later will want the final state, not the first draft.
Know when to just fix it
If the fix is an hour of work, fixing it is often cheaper than a week of debate, even if you rate it lower than the tester did. Save the argument for findings where the fix is costly or the rating drives a contractual or reporting consequence.
Safeguard's reachability analysis and zero-day discovery can supply the code-level evidence behind a dispute about whether a flaw is exercised, and the free scan at gold.safeguard.sh/scan is a quick way to generate a first set of facts.
Quick check
Can I dispute a finding after the report is final?
Yes. Most testers will issue an addendum or revised report if you send evidence. Ask for the revision in writing.
Should I ever downgrade a finding myself?
Record your own rating alongside the tester's, with reasons, rather than silently editing theirs.
Last reviewed: 19 October 2026.
