A small ritual for reading other people's threat models

When someone hands me a threat model document, I don’t read it top to bottom. I’ve learned — after reviewing maybe two hundred of these — that the first thing I need to understand is not what’s in the document, but what the document thinks it is.

Here are the five questions I ask, in order, before I ever look at a diagram:

1. Who wrote this, and when? If the author has left the company or the document is more than six months old, I’m probably reading fiction. Threat models decay faster than code.

2. What decision was this document written to support? A threat model that exists because “compliance said we need one” is a different animal than one written because “the team genuinely couldn’t decide whether this architecture was safe.” Most documents fail here. They exist, but they don’t have a purpose.

3. What’s the most expensive thing that can go wrong? Not the most likely — the most expensive. If the document doesn’t have a clear answer to this question within the first two pages, the authors haven’t done the hard work.

4. What did they decide not to model? Every threat model has a scope boundary. The interesting question is whether that boundary was chosen deliberately or whether it’s an artifact of what the authors happened to know about.

5. What has changed since this was written? Architecture evolves. Dependencies change. New features get bolted on. A threat model that was correct in January may be dangerously incomplete by June.

Only after I have answers to these five questions do I start reading the actual content. By that point, I usually know whether the document is worth my time — and what I need to look for if it is.