A security review hands engineering 47 findings on a five-by-five likelihood-impact matrix: 9 high, 12 medium, 26 low, each with a numeric score and a risk-accepted column that three rows already use. Nine weeks later two findings are fixed. Review this pack. What would you remove, what would you change, and what would you keep even though it looks odd?

What is actually required

The pack has one job: cause a small number of specific changes to be made, and cause the rest to be knowingly not made. Judge every element against that. On this evidence it produced two changes in nine weeks, so almost all of it is failing.

What I would remove

• The 26 low findings, from the pack. They are not wrong; they are noise with a training effect. A document that is 55% items nobody will act on teaches its readers to skim it, and they skim the nine that mattered too. Move them to a backlog the security team owns.
• The five-by-five matrix and the numeric score. The score is a product of two guesses, and multiplying them discards the thing an engineer needs, which is which guess is doing the work. "Likelihood 2, impact 5" and "likelihood 5, impact 2" both score 10 and require completely different responses. Worse, the score is arguable, so the meeting is spent negotiating ratings rather than discussing fixes. Any prioritisation scheme that can be argued with will be argued with instead of acted on.
• Severity labels with no attacker. "High: insecure deserialisation in the import service" gives a reader nothing to evaluate.

The one change that matters

Rewrite each surviving finding as an attack path plus one change:

Entry point → what the attacker gets → what stops them today → the one change that removes the path → the cost of that change.

For example: an unauthenticated internal endpoint on the import service, reachable from any pod in the cluster, lets an attacker who has any container in the namespace write to the billing database; nothing stops them today except network reachability; adding mutual TLS to that one route removes the path; about three days of work.

This form is actionable because it names the code that changes, it is arguable only on facts rather than on ratings, and it lets the engineer who knows the system say "that path is already blocked because…", which is the fastest way to find the review's own errors.

What I would keep, even though it looks odd

• The findings that are already mitigated. They look like padding. They are the most reusable content in the document, because the reason a path is blocked is the design constraint the next service must also satisfy. Keep them in an appendix with the mechanism named.
• The risk-accepted column, with three additions that make it real: a named person who is accepting it, a date, and an expiry. An accepted risk with no owner and no expiry is a finding that has been deleted while looking as though it was managed. On expiry it returns to the pack automatically.

How I would argue this in the review

Not as a methodology debate. Bring the two fixed findings and ask what was different about them, because the answer is almost always that someone could tell exactly which line of code to change. Then offer a trade: security drops the matrix and the low findings, engineering commits to dates for the rewritten high findings. Both sides give up something visible, which is what makes the change stick.

When this is the wrong answer

Where an external standard or an auditor mandates a scored register, you keep the register and produce the attack-path pack alongside it for engineering. Fighting the mandated artefact wastes credibility you need. The matrix is a reporting instrument; the mistake is using it as the work instruction.

Common weak answers

• "Escalate to the CTO so teams are forced to fix them." Produces nine rushed fixes and a durable adversarial relationship, and it does not survive the next quarter's priorities.
• "Add the findings to the sprint backlog." They will sit there, because a backlog item nobody can size does not get picked up.