ISO 27001 Risk Assessment, Step by Step
The risk assessment is the heart of ISO 27001. Every control you implement, every policy you write, and every line of your Statement of Applicability should trace back to a risk you identified and decided to treat. Auditors read the risk assessment first because it explains every other decision in the ISMS.
The standard tells you what a risk assessment must achieve but deliberately does not prescribe how. That freedom trips up first-timers. This guide walks through the practical choices: which methodology to use, how to score risks consistently, what belongs in the risk register, and how treatment decisions flow into the SoA.
Asset-based vs scenario-based methodologies
The classic approach is asset-based: list your information assets (databases, laptops, SaaS platforms, source code, people), then identify the threats and vulnerabilities that apply to each one. It is thorough and easy for auditors to follow, but large asset inventories can balloon into hundreds of near-duplicate risk entries that nobody maintains.
The alternative is scenario-based (sometimes called event-based): start from realistic bad outcomes, such as a ransomware outbreak, a leaked customer database, or a critical supplier failure, and work backwards to the assets and controls involved. The 2022 revision of the standard sits comfortably with either method. Many organisations blend the two, using scenarios for the big strategic risks and asset thinking for technical coverage. Pick one documented method and apply it consistently, because consistency is what the auditor tests.
Scoring likelihood and impact
Define your scales before you score anything. A simple 1 to 5 scale for likelihood (from rare to almost certain) and 1 to 5 for impact (from negligible to severe) is enough for most organisations. What matters is that each level has a written definition, for example that impact level 4 means regulatory breach or losing a major customer, so two different assessors would score the same risk the same way.
Multiply or matrix the two scores to get a risk level, then set an acceptance threshold: the line above which a risk must be treated and below which it can be accepted. Document that threshold and get management to approve it, because risk acceptance criteria are a requirement of the standard, and the auditor will ask who signed off on them.
Building and maintaining the risk register
The risk register is the living output of the assessment. Each entry should record the risk description, the assets or scenario affected, the owner, the likelihood and impact scores, the resulting risk level, the treatment decision, and the controls applied. An owner per risk is essential: risks without owners are the entries that rot.
Keep the register in a tool people actually use, whether that is a spreadsheet, a GRC platform, or a compliance automation tool. Review it at planned intervals and whenever something material changes, such as a new product, a new supplier, or an incident. A register last touched a year before the audit is one of the most common nonconformities.
Treatment options and the link to the SoA
For every risk above your acceptance threshold, choose one of four treatments: modify the risk by applying controls, avoid it by stopping the activity, share it through insurance or a supplier, or retain it with a documented justification. Most risks end up modified, which is where Annex A comes in: you select controls that reduce the likelihood or impact to an acceptable level.
The Statement of Applicability is the bridge document. Every Annex A control you include should trace to one or more risks in the register, and every exclusion needs a justification. When the risk register and the SoA tell the same story, the audit conversation is short. When they contradict each other, expect findings. Compliance platforms such as Vanta can keep the register, the controls, and the SoA linked so they do not drift apart.
ISO 27001 policy templates
Use these starting documents to turn the control into evidence. Adapt each template to your scope, systems, legal obligations and actual operating process.
Automate ISO 27001 with Vanta
Vanta maps the controls, collects evidence automatically, and keeps you audit-ready. The market-leading compliance automation platform.
FAQ
- Does ISO 27001 require an asset-based risk assessment?
- No. The 2022 version of the standard requires a documented, consistent, repeatable method that produces comparable results, but it does not mandate asset-based over scenario-based approaches. Choose the method that fits your organisation and apply it consistently.
- How often should the risk assessment be repeated?
- At planned intervals, commonly at least annually, and whenever significant changes occur, such as new systems, new suppliers, or a security incident. The register should be a living document, not an annual scramble.
- Who should own the risk register?
- One role should own the register itself, often the CISO or ISMS manager, but each individual risk needs a named owner with the authority to act on it. Ownerless risks are the ones that never get treated.