A security review produces findings that engineering teams dispute or ignore. How should the findings be communicated to be acted on?

Why findings are disputed or ignored

• No stated impact. A finding described as a deviation from a standard invites the question "and what would happen", which if unanswered makes it a matter of opinion.
• Severity that does not match consequence. A catalogue-derived severity that ignores whether the path is reachable, whether the data is sensitive, or whether a compensating control exists trains teams to discount all severities.
• Volume. A report of two hundred findings will not be acted on, and the ones that matter are indistinguishable from the ones that do not.
• No owner or date, so it joins a backlog and loses to work with a sponsor.

What makes a finding actionable

• A concrete attack narrative: who does what, and what they obtain. "An authenticated user of tenant A can read tenant B's records by altering a parameter" is undeniable; "insufficient authorisation controls" is arguable.
• Evidence — a reproduction, a query, a log excerpt — which converts the conversation from whether it is true to how to fix it.
• A specific remediation rather than a principle, with an estimate.
• A severity derived from consequence and reachability, not from a catalogue score.
• A named owner and a date, negotiated rather than imposed, so the commitment is real.
• A small number of findings, prioritised. Five findings that get fixed are worth more than two hundred that get filed.

The framing that changes the reception

Collaborative rather than adversarial. A finding presented as a failure invites defensiveness; the same finding presented as "here is a way an attacker gets in, let us work out the cheapest way to close it" invites engagement.

That is not merely a style preference: defensive engineers describe systems less accurately, which makes the next review worse.

The escalation path that must exist

Some findings will be accepted as risk rather than fixed, and that is legitimate — but an accepted risk needs a named accepter at an appropriate level, a recorded rationale, and a review date. Without that, "accepted" is indistinguishable from "ignored", and the distinction matters enormously when the risk materialises.