A Field Guide to the Threat Model

4 MIN READ

Most security teams have a document they call the threat model. Most of those documents were written in 2022, presented to the board, and then sat in a SharePoint folder that nobody has opened since. Three years on, the architecture has changed, the threat actors have changed, the controls have changed, and the document still says the same thing. The audit accepts it every year. The auditor reads the section, ticks the box, moves on. The document is technically current, and the actual environment it was written to describe is long gone.

Here is the field guide version. The shorter version is what the security engineer has time to read on a Tuesday afternoon, not the 40 page deliverable the consultant charges for.

What a living document actually is

A threat model is three working lists kept in one place and updated on a known cadence. The asset list names the systems, the data stores, the credentials, the customer records that an attacker would actually go after, not the generic production environment paragraph the template ships with. The actor list names the people who would try. The cybercriminal after the payout, the insider after the data, the hacktivist after the visibility, the nation state after the pressure point. The control list names the specific defences, mapped back to the specific assets and the specific actors, with the gaps marked openly rather than hidden. A model that does those three jobs and updates them quarterly does the work. A model that does not amounts to a compliance artefact dressed as a security tool.

What the typical model gets wrong

Three failure modes show up in almost every model the author has reviewed. The actor omission one is common. The model names the external threat, the ransomware gang, the credential seller, and forgets the insider, who causes as many breaches as any external actor in healthcare, financial services, and most regulated industries. The auditor rarely catches this one because the auditor is looking for the section to exist, not for the analysis inside it to be honest. Asset abstraction shows up next. The model says “the production system” without naming the actual Postgres cluster, the S3 bucket with the customer PII, the service account with the read access to the billing database. The engineer cannot test a defence against an abstraction. Control assumption is the third. The model says MFA is in place, segmentation is in place, detection is in place, and does not say for which assets, with what coverage, verified when. The control list reads as a copy of the policy document rather than a record of what is actually running.

How to keep the model alive

Three moves turn the document from a static deliverable into a working tool. Tie the model to the architecture change. Every new service, every new vendor, every new data flow carries a threat change, and the document that updates on the architecture change tracks the production system. The document that updates at the annual review tracks the production system from twelve months ago. Schedule the review before the year starts, on the calendar, with the attendees blocked, and the group actually does it. The review that gets committed to in advance is the review that happens. Use the model in the design review. The engineer who reads it before the new service ships writes the defence into the design. The engineer who finds it in the compliance folder writes the defence into the postmortem after the incident.

The bottom line

Asset list, actor list, control list, refreshed quarterly and used in the design review. The group that ties the document to the architecture holds the line. The group that shelves it for the next audit writes a beautifully formatted model about a system that no longer exists.

By the Human Required Editorial Desk · Reviewed by a human editor · Last updated 2026-08-07