A risk methodology your ISMS can actually run on.
ISO/IEC 27005 is the method behind the requirement. ISO 27001 obliges you to assess and treat information security risk on a repeating cycle; it does not tell you how. 27005 does — how to establish context, identify and analyze risk, evaluate it against criteria you set, choose a treatment, and keep the whole thing under review. It is guidance, not a certifiable standard, and it is deliberately agnostic about whether you score risk qualitatively or quantitatively.
The failure mode is familiar. A risk assessment is run once, beautifully, for the certification audit, and then becomes a spreadsheet that ages. Risks close without anyone recording why; new assets arrive without a row; the treatment plan and the control library drift apart because they were never the same object. 27005 assumes a living process. Most risk registers are a photograph.
Who it applies to
Anyone running an ISMS, certified or not — because clause 6 of ISO 27001 requires a risk process and 27005 is the reference answer for what that process should look like. It is also picked up on its own by teams who need a defensible information-security risk method without the rest of the management system around it.
How 27005 relates to 27001
27001 states the requirement; 27005 describes the method. The same pairing exists between 27001 and 27002 for controls, and between ISO 42001 and ISO 23894 for AI risk. What 27005 adds in practice is a structure the auditor recognizes: risk criteria set before assessment, not after; analysis that names likelihood and consequence rather than a gut score; treatment options that are chosen, recorded and owned; and a review trigger that is an event, not a calendar month. A register built on that shape survives surveillance audits. A register built on a template does not.
What it asks, in operating terms
Read as an operating requirement rather than a methodology document, 27005 reduces to a handful of standing asks — each answerable from a live register, not a file from last year.
| What 27005 asks | Where it is answered |
|---|---|
| Set risk criteria before you assess against them | Risk register · criteria held as configuration, versioned |
| Identify risk against a real asset and supplier inventory | Asset and supplier register · one record every framework reads |
| Analyze and evaluate, with the reasoning recorded | Risk entries · likelihood, consequence and rationale per risk |
| Treat each risk, and tie the treatment to a control | Control library · treatment linked to the control that delivers it |
| Review when something changes, not when the calendar says | Review triggers · asset, supplier and incident events |
What you'd actually look at
In the dashboard, every figure opens on click to the risk, the control and the person behind it. This excerpt is what a risk register is made of:
- Risks open
- 23 · each with a named owner
- Treatment
- 19 modify · 3 retain · 1 share
- Linked controls
- 23/23 · treatment tied to a control
- Last review trigger
- new supplier onboarded · 6 days ago
- Export
- sealed · sha256:e3b7...51c2
Where teams usually start
With a demo walked through by TruSecure — your risk criteria set once, a single risk opened to its analysis, its treatment and the control that delivers it, and the review that fires when an asset changes rather than when a quarter ends. A Resilience Sprint then produces the first baseline; the subscription keeps it current. Packaging is scoped in the conversation, not a price list.
TruSecure helps operationalize requirements and prepare evidence. Legal interpretation should be validated by qualified counsel.
The short answer
ISO/IEC 27005 provides risk management guidance specific to information security, supporting the risk assessment and treatment process ISO 27001 requires. TruSecure's risk register is structured to align with 27005 guidance directly.