ISO 27001 Risk Assessment Methodology: A Complete Guide
The ISO 27001 risk assessment is the engine that drives the rest of your information security management system. It tells you which Annex A controls actually apply, where to spend your security budget, and how to defend a Statement of Applicability when an auditor asks why you excluded a control. Get the methodology right and the rest of the certification falls into place. Get it wrong and you spend the next three years patching findings.
This guide walks through what an ISO 27001 risk assessment is, the methodologies that pass certification, the step-by-step process, and the documentation auditors actually open. By the end you will have a methodology you can document and apply.
What is an ISO 27001 risk assessment?
A defensible ISO 27001 risk assessment can compress audit cycles. Industry data from 2024 audit reports shows certification engagements at small businesses run $11,000 to $25,000, while enterprise programs average $40,000 to $90,000 — and the risk assessment quality drives 30% to 50% of that variance. Get the methodology right early and the savings compound across every annual cycle.
An ISO 27001 risk assessment is a structured process for identifying, analyzing, and evaluating information security risks within the scope of your ISMS. The standard requires it in clause 6.1.2. According to a 2024 survey by ISMS.online, 67% of failed ISO 27001 audits were tied to risk assessment defects, not to control implementation gaps. The output is a list of risks, each with an owner, a likelihood and impact rating, and a treatment decision (mitigate, transfer, accept, or avoid).
The risk assessment must be:
- Documented with a defined methodology
- Repeatable — anyone applying the methodology to the same data should get similar results
- Traceable — every Annex A control on your Statement of Applicability links back to a risk
- Reviewed regularly — at planned intervals and when significant changes occur
Auditors do not just want a risk register. They want to see how you got there.
ISO 27001 risk assessment methodology options
ISO 27001 itself does not prescribe a methodology. Most organizations choose between two families:
Asset-based risk assessment
The classic approach. You inventory information assets (databases, source code, customer records, employee laptops), identify threats and vulnerabilities for each asset, and calculate risk per threat-vulnerability pair.
Strengths: thorough, defensible, easy for auditors to follow. Weaknesses: explodes in complexity. A 200-asset inventory with 5 threats per asset and 3 vulnerabilities per threat produces 3,000 risk lines, most of which are noise.
Scenario-based risk assessment
You identify a small number of high-impact scenarios (a breach of customer PII, a ransomware infection of production servers, an insider exfiltrating IP) and assess each scenario directly. Each scenario draws on multiple assets, threats, and vulnerabilities, but it is rated as one unit.
Strengths: stays manageable. Easier to communicate to executives. Maps cleanly to incident response. Weaknesses: gaps are easier to miss. You need a strong threat model up front.
A hybrid approach is now common. Use scenario-based for the headline business risks, then layer asset-based for technical controls (encryption, patching, access management). Auditors accept hybrid approaches as long as the methodology is documented.
For broader context on certification, see our ISO 27001 certification guide.
The 7-step ISO 27001 risk assessment process
A defensible ISO 27001 risk assessment follows these steps. The order matters: skipping ahead is the most common cause of an audit nonconformity.
Step 1: Define the methodology
Before you assess a single risk, document:
- The scale you will use for likelihood (e.g., 1 to 5)
- The scale for impact (e.g., 1 to 5 across confidentiality, integrity, availability)
- How you will combine the two into a risk score
- Risk acceptance criteria (e.g., "any score of 12 or above must be treated")
- Who owns each step
This document is usually called the Risk Assessment Methodology or Risk Management Procedure. It lives in your ISMS document set and is reviewed annually.
Step 2: Establish the context
Define the boundaries of the assessment. They must match your ISMS scope. If your scope is "the SaaS platform and supporting corporate IT," then your risk assessment cannot include the marketing website unless that website is in scope.
Identify external factors (regulations, customer contracts, threat landscape) and internal factors (organizational structure, business objectives, policies) that shape risk.
Step 3: Identify risks
This is where the methodologies diverge. Asset-based: build the asset inventory, then for each asset identify threats and vulnerabilities. Scenario-based: build the scenario list with input from business owners and engineering leads.
Either way, the output is a risk register. Each entry should have:
- A unique ID
- A clear, single-sentence description
- The asset(s) or scenario it covers
- The threat source (external attacker, insider, environmental, system failure)
- The vulnerability or weakness exploited
Step 4: Analyze risks
For each risk, assess:
- Likelihood on your defined scale (how often will this happen if you do nothing?)
- Impact on your defined scale (how bad is it when it happens?)
- Inherent risk score = likelihood × impact (or another combination per your methodology)
The likelihood rating should consider threat actor motivation, vulnerability exposure, and existing protective controls. The impact rating should consider all three security objectives (confidentiality, integrity, availability), plus any business impacts (regulatory, financial, reputational).
A simple 5×5 matrix gives you risk scores from 1 to 25. Many organizations use a 4×4 matrix to avoid the temptation to land everything on the middle row.
Step 5: Evaluate risks
Compare each inherent risk score to your acceptance criteria. Risks above the threshold need treatment. Risks at or below can be accepted, but the acceptance must be approved by the risk owner and documented.
This step also produces a residual risk score for each risk after applying existing controls. The residual score is what auditors care about most.
Step 6: Determine risk treatment
For each risk that exceeds acceptance, choose one of four treatment options:
- Mitigate — apply controls to reduce likelihood or impact
- Transfer — shift the risk to another party (insurance, contract, vendor)
- Avoid — eliminate the activity that creates the risk
- Accept — formally accept the residual risk with sign-off
Most ISO 27001 risk treatment goes to the mitigate column, drawing controls from Annex A. Each chosen control links to one or more risks in the risk register, and that linkage drives your Statement of Applicability.
Step 7: Document and review
Produce these artifacts:
- Risk register — the table of all identified risks with scores, owners, treatments, and status
- Risk treatment plan — for each risk being mitigated, the specific controls, owners, and target dates
- Statement of Applicability — every Annex A control marked applicable or not, with justification
Review the assessment annually at minimum, and trigger a re-assessment whenever there is a significant change (a new product line, a major incident, a regulatory shift). Many organizations now run quarterly mini-reviews on the top-10 risks plus a full annual cycle.
Risk scoring matrix example
A simple 5×5 matrix that auditors accept:
| Likelihood ↓ / Impact → | 1 (Insignificant) | 2 (Minor) | 3 (Moderate) | 4 (Major) | 5 (Severe) |
|---|---|---|---|---|---|
| 5 (Almost certain) | 5 | 10 | 15 | 20 | 25 |
| 4 (Likely) | 4 | 8 | 12 | 16 | 20 |
| 3 (Possible) | 3 | 6 | 9 | 12 | 15 |
| 2 (Unlikely) | 2 | 4 | 6 | 8 | 10 |
| 1 (Rare) | 1 | 2 | 3 | 4 | 5 |
Common acceptance bands:
- 1 to 4: Low. Accept with monitoring.
- 5 to 9: Medium. Treat where cost-effective.
- 10 to 15: High. Treat within 90 days.
- 16 to 25: Critical. Treat immediately.
The exact bands are your choice. What matters is that you set them in the methodology and apply them consistently.
Risk assessment example: PII breach scenario
A small worked example to make the process concrete.
Risk: Unauthorized disclosure of customer PII via compromised production database Threat source: External attacker Vulnerability: Database admin credentials reused across services Likelihood: 4 (Likely) — credential stuffing attempts observed weekly Impact: 5 (Severe) — 200,000 customer records, GDPR notification triggered Inherent risk: 20 (Critical)
Treatment: Mitigate Annex A controls applied:
- A.5.17 Authentication information (move to managed credential vault)
- A.8.2 Privileged access rights (enforce MFA on all privileged accounts)
- A.8.5 Secure authentication (require strong MFA per system)
- A.5.7 Threat intelligence (monitor for credential exposure)
Residual likelihood: 2 (Unlikely) Residual impact: 5 (Severe) — impact of breach unchanged, only likelihood drops Residual risk: 10 (High) — within High acceptance band, with quarterly review
This is the level of detail an auditor expects on every risk above the acceptance threshold.
Documentation auditors will request
When the certification body arrives, expect them to ask for these documents in this order:
- Risk Assessment Methodology (the procedure that defines how you do it)
- Risk Register (the current output)
- Risk Treatment Plan (how you are addressing risks above acceptance)
- Statement of Applicability (every Annex A control with a yes/no decision)
- Evidence of review (minutes of risk review meetings, sign-off on accepted risks)
- Evidence of risk owner involvement (interviews with named risk owners)
The single most common nonconformity in ISO 27001 audits is a Statement of Applicability that does not match the risk register. If you mark a control as applicable, an auditor expects to see the risk it addresses. If you mark a control as not applicable, the risk register should show no risks needing it.
For more on the SoA itself, see our ISO 27001 Statement of Applicability template.
Common ISO 27001 risk assessment mistakes
A short list of failure patterns that show up in audits:
Confusing risks with controls. "We do not have MFA" is a vulnerability or a control gap, not a risk. The risk is the consequence: "Account takeover via credential stuffing leads to unauthorized data access."
Single-axis impact ratings. Rating impact only on financial loss misses confidentiality and integrity impacts. Use a multi-dimensional impact scale.
Risk owners who do not own. Every risk needs a single named owner who can actually accept or reject the residual risk. Listing "IT Security Team" as owner is an audit finding.
Static residual scores. Residual risk should change as controls are implemented. If your register shows the same residual scores as inherent scores, you are not capturing the value of existing controls.
Annual-only review. A risk assessment that only changes once a year is rarely current. Build a quarterly mini-review into the cadence.
For a closer look at the broader audit cycle, see our ISO 27001 internal audit guide.
Frequently asked questions
Does ISO 27001 require a specific risk assessment methodology?
No. Clause 6.1.2 requires you to define and apply a documented methodology, but it does not prescribe one. Asset-based, scenario-based, or hybrid approaches are all acceptable as long as the methodology is documented and applied consistently.
How often should I run an ISO 27001 risk assessment?
At minimum annually, plus whenever a significant change occurs (new product, major incident, M&A, regulatory shift). Most mature ISMS programs run a full annual assessment plus quarterly reviews of the top risks.
What is the difference between inherent risk and residual risk?
Inherent risk is the score before any controls are applied. Residual risk is the score after considering existing controls. Auditors focus heavily on residual risk because it represents the actual exposure the organization is carrying.
How many risks should an ISO 27001 risk assessment identify?
There is no required number. A small SaaS company typically identifies 30 to 80 risks. A large enterprise may identify several hundred. Far fewer than 20 risks usually means the assessment is too thin; far more than 200 usually means risks are duplicated or confused with controls.
Can I use a third-party tool for the ISO 27001 risk assessment?
Yes. Tools like Vanta, Drata, Sprinto, and Secureframe include risk assessment modules that align with ISO 27001 clause 6.1.2. The auditor still wants to see the methodology document and confirm the tool's output matches your defined approach.
What is the link between the ISO 27001 risk assessment and the Statement of Applicability?
Every Annex A control on the SoA must trace back to at least one risk. Marking a control "applicable" without a risk that requires it is a common audit finding. Marking a control "not applicable" requires a justification, usually that no risks in the register need that control.
Do I need separate risk assessments for ISO 27001 and SOC 2?
Not necessarily. A single, well-documented risk assessment can satisfy both, but the methodology should be explicit about which framework requirements it addresses. Many organizations build one risk register and tag each risk with the frameworks it supports.
Bottom line
The ISO 27001 risk assessment is not a tick-box exercise. It is the source document that justifies your Statement of Applicability, drives your risk treatment plan, and convinces an auditor that your ISMS is actually addressing the risks your business faces. Time spent on the methodology pays off across every subsequent audit cycle.
Pick a methodology you can document and explain in one page. Apply it consistently. Review it on a published cadence. According to BSI's 2024 audit data, organizations that document a clear methodology cut their certification timeline by approximately 30%. The certification follows from there.
For the official requirements, see ISO/IEC 27001:2022 clauses 6.1.2 and 6.1.3.
