A disputed Critical: writing a report that survives a hostile reading

One finding, two registers, one evidence chain.

Technical body (for the IT director):

• Title and affected component with exact endpoint and parameter.
• CVSS v4.0 with the full vector and a one-line justification per metric. Crucially: WAF presence is not a base-metric reducer - it belongs in threat/environmental context. If you quietly discount AV or AC because of the WAF, the IT director wins the argument on your own arithmetic.
• Reproduction steps a developer can follow in under five minutes, including the WAF request ID and timestamp so they can pull their own logs and see the request arrive.
• Root cause: string concatenation in the lookup query, missing parameterisation - with the code location if you have it.
• Evidence: request/response pairs, 12 rows redacted to two with hashes of the rest, the recording's hash, and the tester's source IP.

Business statement (for the CISO and board): "An unauthenticated internet user can retrieve clinician records from the patient portal without logging in. The WAF did not block the request. The database account can read 41 tables. No authentication control is engaged because the request never reaches the login layer."

Why MFA is irrelevant here: MFA protects authentication. This is a missing authorisation and input-handling defect that executes before any session exists. Say that in one sentence in both sections so the rebuttal is answered before it is raised.

Remediation with verification criteria: parameterised queries deployed, plus a re-test request that must return a 400/403 and no rows. Give the patch date they committed to, so the report measures them against their own promise rather than yours.

In the room, argue with evidence, not volume.

1. Make it falsifiable. "Here is the exact request, sent at 14:22:07 from our registered IP, with your WAF request ID. Pull that ID from your logs - if it isn't there, I'm wrong and I'll withdraw the finding." Very few objections survive an invitation to be proven wrong.
2. Separate the two claims. He is making a control claim ("the WAF blocked it") and an architecture claim ("MFA covers it"). Address them separately: the screen recording shows a 200 with data, so the WAF did not block this payload; and MFA is upstream of the vulnerable code path, so it is not in the loop.
3. Offer a joint reproduction in a 30-minute session with their developer and your tester. Co-witnessing converts a dispute into a shared observation.
4. Concede what is true. If the WAF blocks the sqlmap default payloads and only the tuned --technique=U variant passes, say so - that is a real mitigating detail and stating it buys you credibility for everything else.

If he still disagrees, do not escalate the adjectives. Escalate the documentation. Add a "client response" subsection: the objection verbatim, your evidence, and the residual risk the client has chosen to accept, with the name and date. This is standard practice and protects both sides - them from an undisclosed risk, you from an allegation of overstatement.

Do not remove the finding, downgrade the severity to end the meeting, or let the disagreement move into an email thread that never reaches the report. The report is the record; the meeting is not. If the client later insists the finding be deleted, that instruction goes in writing, and you decide whether the engagement can still be signed.

Change the register, never the substance. These are different requests wearing the same words.

What I would change:

• Strip payloads, tool names, and CVSS vectors from the executive summary. The board does not need --technique=U.
• Replace severity jargon with consequence: "clinician records can be read without logging in" rather than "unauthenticated SQLi, CVSS 9.x".
• One page, one decision request. Boards act on decisions, not findings. Example: "Decision requested: approve a 14-day emergency patch window instead of 30, or accept documented risk until the vendor release."
• A short "what is already working" paragraph - the WAF did stop the commodity payloads, MFA is correctly deployed. Accurate framing reduces fear more effectively than euphemism.

What I would not change:

• The severity, the exploitability statement, or the fact that clinician data was retrieved.
• The number of affected records reachable (41 tables) or the internet-facing exposure.
• The disagreement log, if one exists.

Why the line sits there: a report that understates a confirmed data-exposure finding is worse for the client than one that alarms them. If a breach occurs later, the report is the first document subpoenaed, and "we softened it at the client's request" is not a defensible position for either party. It also destroys the retest comparison - a finding that was Critical in draft and Medium in final cannot be measured.

Delivery: issue a two-page board brief alongside the full report, with the same findings and severities. Offer to attend the audit committee for ten minutes. Executives rarely object to plain language; they object to being surprised, and a briefing you present is not a surprise.