ISO 27001 Risk Assessment: Complete Guide
Quick Answer
The ISO 27001 risk assessment is the cornerstone of the ISMS. It requires you to identify information security risks, analyze their likelihood and impact, evaluate them against your risk criteria, and select appropriate controls from Annex A to treat unacceptable risks.
Why Risk Assessment Is Central to ISO 27001
Unlike prescriptive frameworks that tell you exactly what to do, ISO 27001 is risk-based. The risk assessment determines which security controls you implement and why. Everything flows from it: your Statement of Applicability, your control selection, your resource allocation, and your security priorities.
Key Takeaways
- Risk assessment is mandatory under Clause 6.1.2 — you cannot skip or shortcut it
- ISO 27001 doesn't prescribe a specific methodology — you choose your own approach
- The risk assessment must be repeatable and produce consistent, comparable results
- Risk treatment connects to Annex A controls — each selected control should trace to a risk
- Must be reviewed and updated at least annually or when significant changes occur
Risk Assessment Process
Conducting an ISO 27001 Risk Assessment
Define your risk assessment methodology
Choose and document your approach: asset-based (identify assets first, then threats/vulnerabilities), scenario-based (identify risk scenarios), or threat-based. Define risk criteria: how you measure likelihood and impact, and what level of risk is acceptable.
Identify information assets
Catalog information assets within the ISMS scope: data, systems, processes, people, physical locations. Consider all forms — digital, paper, verbal. Assign owners to each asset.
Identify threats and vulnerabilities
For each asset, identify potential threats (what could go wrong) and vulnerabilities (weaknesses that threats could exploit). Common sources: threat catalogs, incident history, industry reports, penetration test results.
Analyze risks (likelihood x impact)
Assess each risk's likelihood of occurring and potential impact if it does. Use a consistent scale (e.g., 1-5 for each). Calculate risk level. Many organizations use a risk matrix (e.g., 5x5 grid).
Evaluate risks against criteria
Compare assessed risk levels against your predefined risk acceptance criteria. Determine which risks are acceptable (retain) and which require treatment. Prioritize risks for treatment.
Select risk treatment options
For each unacceptable risk, choose a treatment: mitigate (apply controls), transfer (insurance, outsourcing), avoid (stop the activity), or accept (with management approval). Map mitigating controls to Annex A.
Create the risk treatment plan
Document the selected treatment for each risk, responsible owners, timelines, and resources needed. This plan drives your ISMS implementation.
Risk Treatment Options
| Option | Description | When to Use | Example |
|---|---|---|---|
| Mitigate (Modify) | Apply controls to reduce likelihood or impact | Most common option for significant risks | Implement encryption, access controls, backup procedures |
| Transfer (Share) | Move risk to a third party | When another party can manage it better | Cyber insurance, outsourcing to specialized provider |
| Avoid (Terminate) | Stop the activity that creates the risk | When the risk outweighs the business benefit | Discontinue a high-risk service, stop collecting certain data |
| Accept (Retain) | Acknowledge and accept the risk | When risk is within acceptable levels or treatment cost exceeds impact | Document acceptance with management sign-off |
Common Risk Assessment Methodologies
- Asset-based approach: Start with information assets, identify threats and vulnerabilities for each. Most traditional and thorough, but can be time-consuming for large organizations
- Scenario-based approach: Identify risk scenarios (e.g., 'ransomware encrypts production database') and assess each. More intuitive and faster, increasingly popular
- NIST SP 800-30: Risk assessment methodology from NIST. Well-documented and widely referenced. Compatible with ISO 27001 requirements
- OCTAVE: Operationally Critical Threat, Asset, and Vulnerability Evaluation. Developed by Carnegie Mellon. Focuses on organizational risk
- FAIR: Factor Analysis of Information Risk. Quantitative approach that estimates financial impact. Useful for communicating risk to business stakeholders
✅ Keep It Practical
The biggest mistake organizations make is overcomplicating the risk assessment. A simple 5x5 likelihood-impact matrix with 30-50 well-identified risks is better than a complex methodology with 500 poorly assessed risks. Auditors care that your methodology is consistent, documented, and repeatable — not that it's the most sophisticated approach available.
Clause 6.1.2
ISO 27001 Requirement
Mandates risk assessment process
30-80
Typical Risk Count
Risks identified in most assessments
Annual
Minimum Review Frequency
Or when significant changes occur
4 Options
Risk Treatment
Mitigate, transfer, avoid, accept
Does ISO 27001 require a specific risk assessment methodology?
No. Clause 6.1.2 requires that the methodology produces consistent, valid, and comparable results, but doesn't specify which methodology to use. You can use asset-based, scenario-based, NIST, OCTAVE, FAIR, or your own approach — as long as it's documented and repeatable.
How many risks should we identify?
There's no magic number. Most organizations identify 30-80 risks. Too few suggests you haven't looked hard enough; too many suggests you're being too granular. Focus on meaningful risks that could genuinely impact your information security. Quality over quantity.
Can we use a compliance platform for risk assessment?
Yes. Platforms like Vanta, Drata, and Secureframe include risk assessment modules with pre-built risk libraries, scoring matrices, and treatment tracking. They streamline the process and maintain the documentation auditors need. They're especially useful for organizations new to formal risk management.
How does the risk assessment connect to the SoA?
The risk assessment drives the Statement of Applicability (SoA). For each Annex A control, the SoA documents whether it's applicable based on identified risks. Controls selected for risk mitigation are marked as applicable with justification traced to specific risks. Controls not needed based on your risk profile can be excluded with documented reasoning.
Simplify Your Risk Assessment
Compare platforms with built-in risk assessment frameworks, pre-built risk libraries, and automated risk tracking.
Browse ISO 27001 Tools