After an incident, compare what happened with what your threat model said could happen. Add the attack path it missed, fix any wrong assumptions in the diagram, give the new threat a response and an owner, and write a test so it cannot return quietly. Do it in a blameless session within days.
Why this belongs in the process
The Threat Modeling Manifesto values a journey of understanding over a single snapshot, and continuous refinement over one delivery. An incident is the strongest evidence you will ever get that your model was incomplete. Use it.
The fourth question in the OWASP cheat sheet is whether you did a good enough job. An incident is a direct, uncomfortable answer.
A seven step checklist
- Write the attack path in plain steps. Start at the entry point and end at the impact. Use your incident timeline as the source.
- Find the row. Was this threat in the model? If yes, why did the response fail? If no, why was it missed?
- Classify the gap. The usual causes: an element missing from the diagram, a wrong trust assumption, a mitigation that was planned but never done, or a mitigation that did not work.
- Fix the diagram first. Add the missing component, flow or boundary. A wrong diagram produces wrong threats.
- Add or revise the threat. Give it a rating, a response, an owner and a ticket.
- Check neighbours. If one component had this gap, ask which others share the pattern and walk them with the same question.
- Write the test. Add an automated or manual test so a regression is caught.
Questions that work well in the session
- What did we believe was true that was not?
- Which control existed on paper but not in practice?
- Which alert should have fired, and why did it not?
- What would have made this path harder?
Keep it blameless
If the tone becomes punishment, people stop reporting near misses. Focus on the system and the model, and name owners for next steps, not culprits.
Record what changed
Add a short entry to the model: date, what changed, why. This builds a history that shows the model improving, which helps the next review. See turning findings into requirements and tests for the follow through.
I did not use any named incident as an example because the sources I fetched do not describe one. Use your own incident record.
Try it yourself
Click through it at your own pace, or open it full screen. Click through it and look at how new risk is flagged as code and dependencies change.
Quick check
What if the incident was a threat we had already accepted?
Reopen the decision. Check whether the rating was right and whether the owner still agrees. Update the rating and response, and record the reason.
Do near misses count?
Yes. A near miss shows the same gap without the cost. Treat it as input to the model.
A note on tooling
Safeguard covers continuous monitoring of dependencies, SBOMs and policy gates, which help catch some supply chain paths early. Try the free scan.
Sources
Last reviewed: 19 October 2026.
