A threat model is technically thorough and the engineering team does not act on it. What is wrong with how it is communicated?

What is wrong

It is a list rather than a set of decisions. A thorough enumeration of threats, without a decision attached to each, leaves engineers with a document and no obligation.

Three specific communication failures:

1. No prioritisation by exploitability and impact. Forty threats presented equally means the team cannot tell where to start, so they start nowhere. Ranking by realistic exploitability and blast radius usually reduces the urgent list by an order of magnitude and makes it actionable.

2. Threats stated abstractly. "Insufficient input validation" is a category. "A seller can submit a discount code through the API twice concurrently and have it applied twice, because the redemption check and the write are separate operations" is a bug someone can fix today, and the difference in response is total.

3. No disposition per threat. Every threat should be marked prevented, detected, or accepted — and if detected, by what and who acts on it. A threat with no prevention and no detection is an accepted risk whether or not anyone accepted it, and making that explicit is what forces the decision.

What good communication looks like

• Ranked, with the top few called out. The team should know which three matter most.
• Concrete, with an attack narrative — a specific goal, a specific path, a specific consequence. Narratives are remembered and categories are not.
• Attached to owners and to the backlog, not to a document.
• Accepted risks recorded with who accepted them, which is what makes acceptance a real decision rather than a default.
• Timed with the design, when changing the design is still cheap. A threat model on a shipped system produces findings that compete with the roadmap and lose.

The framing that gets engagement

Walk the flow as an adversary with a goal, not as a checklist of techniques: get the item free, get it before others, get someone else's data, deny it to others, make the merchant lose money.

Goal-oriented narratives find business-logic abuse that technique checklists miss entirely — concurrent discount redemption, inventory manipulation for scarcity, card testing — and they engage engineers because they are stories about the system rather than taxonomy.

The measure of success

Changes made, not threats identified. A threat model whose output is a document has not done its job; one whose output is three design changes and four accepted risks with names attached has.