Most ISO 27001 implementations fail quietly. The certification gets issued, the auditors leave, and within six months the risk register sits untouched in a SharePoint folder. Security engineers ignore it because it does not connect to anything they can act on. Auditors accept it because it ticks the required boxes. Neither party is getting what they need.
The root cause is almost always the same: the risk register was built around assets rather than scenarios. Teams list "customer database — unauthorised access — High" and move on. There is no specific attack path, no connection to actual system architecture, and no meaningful way to decide which controls address which risks. The register satisfies clause 6.1.2 on paper while delivering no security value in practice.
Threat modeling solves this, but only if you understand exactly what ISO 27001 asks for — and where the standard deliberately leaves methodology up to you.
What ISO 27001 actually requires from your risk assessment
ISO 27001:2022 is intentionally methodology-neutral. Clause 6.1.2 requires that you establish and maintain an information security risk assessment process that identifies risks associated with the loss of confidentiality, integrity, and availability of information, assigns risk owners, and analyses likelihood and impact. Clause 8.2 requires that you actually run this process on a schedule.
The standard does not prescribe STRIDE, OCTAVE, FAIR, or any other framework. That flexibility is a feature — it accommodates every sector and organisation size — but it is also the source of enormous confusion. Teams read "identify risks" and default to the vaguest possible interpretation.
The key requirement: ISO 27001 clause 6.1.2(c) requires that you identify risks associated with information assets and their owners. It says nothing about how to identify them — that is entirely your choice. Threat modeling is a valid, defensible, and unusually thorough way to satisfy this clause.
Annex A provides 93 controls (in the 2022 revision) that your Statement of Applicability must address. For each control, you must state whether it is applicable and, if so, provide evidence of implementation. The implicit requirement that most teams miss is this: your risk register should justify your Annex A choices. Controls that do not trace back to identified risks have no business being in your SOA, and risks that do not connect to any control are unaddressed liabilities.
The asset-centric trap — and why it produces useless registers
The dominant approach to ISO 27001 risk assessment is to list information assets — databases, laptops, source code repositories, cloud environments — and assign a generic risk to each. The result looks approximately like this for every row: asset, threat category (confidentiality/integrity/availability), likelihood (1–5), impact (1–5), risk score (likelihood × impact), and a mitigation that references an Annex A control number.
This approach has three serious problems:
- It conflates asset value with risk. A high-value asset is not automatically high-risk. Risk depends on the exploitability of a specific attack path, not on how sensitive the data is in the abstract. A customer database behind an authenticated API, strict RBAC, and network segmentation carries very different risk to the same database exposed on a public IP with default credentials.
- It produces controls with no traceability. "Apply access control (A.8.3)" appears on dozens of rows for a dozen different assets. There is no way to tell which specific vulnerability prompted which specific control. When a penetration test finds a gap, there is nothing in the register to update.
- It cannot answer the question auditors will eventually ask. A mature ISO 27001 auditor will ask: "Walk me through how you identified the risks that justify these controls." If the answer is "we listed our assets and brainstormed," the auditor knows the register is decorative.
Threat modeling as the ISO 27001 risk identification engine
A threat model approaches risk identification from the other direction: it starts from your architecture rather than your assets. As we explored in our introduction to threat modeling, you begin by drawing a Data Flow Diagram — every process, data store, external entity, and the flows between them — and then systematically enumerate the ways an adversary could abuse each element.
The result is a set of threat scenarios, not a set of worried assets. Instead of "customer database — unauthorised access," you get entries like:
- "Attacker sends crafted SQL payload via the unauthenticated product search endpoint, bypassing parameterisation to extract rows from the user credentials table."
- "Compromised CI/CD pipeline injects malicious code during build, signing a deployment artifact that exfiltrates secrets at runtime."
- "Privileged support account with no MFA is credential-stuffed using breached password lists, granting admin access to the billing system."
Each of these is a complete risk statement. It names the attacker capability required, the attack path, the entry point, and the consequence. You can immediately see which controls are relevant, which Annex A entries they map to, and what a successful mitigation looks like. The risk register that follows from this kind of threat model is one that both security engineers and auditors can use.
Mapping threat model outputs to ISO 27001 Annex A
Once you have a set of attack-tree leaf nodes — the specific terminal threats in your threat model — mapping them to Annex A controls becomes largely mechanical. Each leaf node represents a specific threat scenario. The mitigations you assign to that node correspond to one or more Annex A controls.
Below are examples drawn from common attack-tree leaf nodes and their natural Annex A counterparts in the ISO 27001:2022 revision:
| Threat scenario (leaf node) | STRIDE category | Annex A control(s) |
|---|---|---|
| Credential stuffing on login endpoint due to absent rate limiting | S Spoofing | A.8.5 Secure authentication, A.8.20 Networks security |
| JWT forged using weak signing secret stored in version control | S Spoofing | A.8.24 Use of cryptography, A.8.12 Data leakage prevention |
| API response leaks stack trace with internal file paths to unauthenticated caller | I Info Disclosure | A.8.26 Application security requirements, A.8.29 Security testing |
| Malicious dependency injected via compromised package registry | T Tampering | A.8.30 Outsourced development, A.8.9 Configuration management |
| Admin function accessible to standard user due to missing RBAC check | E Elevation of Privilege | A.8.3 Information access restriction, A.8.18 Use of privileged utility programs |
| Unauthenticated endpoint accepts unbounded file upload, exhausting storage | D Denial of Service | A.8.6 Capacity management, A.8.20 Networks security |
| Deleted records unrecoverable due to absent backup verification process | T Tampering | A.8.13 Information backup, A.8.14 Redundancy of information processing |
With this mapping in place, your Statement of Applicability writes itself. For each Annex A control, you can point to one or more threat scenarios that justify its inclusion. Controls that appear in your SOA but have no corresponding threat scenario in your register are candidates for removal — or signal that your threat model is incomplete.
Satisfying the Statement of Applicability with evidence
The SOA is where ISO 27001 gets contentious. Many organisations treat it as a compliance checkbox: list all 93 controls, mark most as "applicable," cite a generic policy for each, and move on. Auditors accepting this approach are doing organisations a disservice.
A threat-model-derived SOA has a fundamentally different character. For each applicable control, you can state:
- Why it is applicable — because threat scenario X in forest Y (identified in the threat model on date Z) requires this control to be implemented.
- How it is implemented — the specific technical or procedural countermeasure that addresses the threat.
- How you verified it works — the acceptance test, penetration test result, or automated check that confirms the control is effective.
This traceability chain — threat scenario → control → implementation → verification — is what separates a compliant SOA from a genuinely mature one. It also dramatically reduces the effort of scope management: when an auditor asks why you chose not to implement a particular control, you can point to the absence of any threat scenario that would require it, rather than producing a vague justification.
Keeping it alive: from certification to continuous assurance
ISO 27001 is not a one-time certification — it requires annual surveillance audits and a triennial recertification. The risk register must be reviewed and updated whenever significant changes occur to the information environment. In practice, "significant changes" happen constantly: new services are launched, architecture evolves, third-party integrations are added, and cloud configurations drift.
This is where a living threat model has a decisive advantage over a static spreadsheet. When your architecture changes, you update the DFD. Updated DFDs expose new trust boundaries and data flows. New flows generate new threat scenarios. New threat scenarios propagate to new risk register entries. The register stays honest because it is derived from a model of how the system actually works, not from an inventory of what someone thought the system did twelve months ago.
Practical cadence: Review your threat models whenever a new system or significant feature is introduced, whenever a penetration test surfaces a finding not already in the register, and at least quarterly as part of your ISO 27001 management review. The effort is small when the model is maintained continuously; it becomes overwhelming when deferred to pre-audit panic mode.
The teams that find ISO 27001 valuable — rather than burdensome — are the ones that treat the standard as a forcing function for doing threat work they should be doing anyway. The risk register is not a document you produce for auditors. It is the output of your security thinking, formatted in a way that auditors can also read.
In the next post, we look at a related trap: how many teams confuse CVSS vulnerability severity scores with actual risk — and how attack trees give you a contextual picture that patch-priority spreadsheets cannot.