ISO 27005: Information Security Risk Management, Properly
ISO 27001 clause 6.1.2 tells you to assess information security risk. It does not tell you how. ISO 27005 is the companion standard that fills that gap — the method behind the mandate. If ISO 31000 is your organisation-wide risk philosophy, 27005 is its information-security dialect.
Where it sits
You certify to ISO 27001. You run your risk process according to ISO 27005 (and align both to ISO 31000’s principles). Auditors can’t issue nonconformities against 27005 itself — but when they probe whether your risk assessment produces “consistent, valid and comparable results” (a 27001 requirement), a 27005-shaped process is the easiest way to say yes with a straight face.
The process, concretely
| Stage | What you actually do |
|---|---|
| Context | Define scope, risk criteria and acceptance thresholds up front — what does “high” mean in money, downtime or harm, and who can accept it? |
| Identification | Event-based (what scenarios threaten our objectives?) or asset-based (asset × threat × vulnerability). Modern practice starts event-based, then drills into assets. |
| Analysis | Score likelihood and consequence on defined scales; note the controls already in place and how much they actually reduce exposure. |
| Evaluation | Rank against your acceptance criteria. The output is a decision list, not a heat map for its own sake. |
| Treatment | Modify (add controls), retain (accept, with a named owner), avoid (stop the activity) or share (insure/outsource). Feeds the Risk Treatment Plan and the SoA. |
| Monitor & communicate | Risks are living records: review on change and on schedule, and report in terms the board can act on. |
Practical choices that make or break it
- Define scales before scoring. A 1–5 likelihood scale means nothing until “4” is anchored to “expected at least annually”.
- Score inherent AND residual risk. Auditors want to see that control effectiveness — not optimism — is what moved the number.
- Keep the register small enough to manage. Fifty well-owned risks beat four hundred orphaned ones.
- Tie every “modify” decision to specific controls — that link is exactly what your Statement of Applicability needs.
- Record acceptance explicitly. “Nobody got round to it” is not risk acceptance; a named owner and date is.
27005 vs 31000: which do I follow?
Both. ISO 31000 gives the enterprise-wide principles and vocabulary (we covered it a few weeks ago); 27005 specialises the process for information security — threat catalogues, vulnerability thinking, control-driven treatment, and alignment with the ISMS clauses of 27001. Run one register, use 31000 language at board level, and let 27005 govern how infosec risks enter and move through it.
A risk register built the 27005 way
Cyber Horizon scores inherent and residual risk, links treatments to controls and your SoA, and keeps every acceptance owned and dated — audit-ready by construction.
Book a Demo