How to Build an ISO 27001 Risk Assessment Methodology That Passes Audit (Clause 6.1.2)

Most organisations that fail an ISO 27001 Stage 1 audit on the risk clause do not fail because they never assessed their risks. They fail because what they have is a list — a spreadsheet someone filled in once, ranking a dozen threats by gut feel — and not a methodology. Clause 6.1.2 of ISO/IEC 27001:2022 does not ask “did you think about risk?” It asks you to define, document, and then actually follow a repeatable process that produces “consistent, valid and comparable results” every time you run it. [2] A list answers the first question. It fails the second.

This guide covers what clause 6.1.2 actually requires, the ISO/IEC 27005:2022-aligned approach auditors expect (asset-based and event-based identification, likelihood x impact scoring, acceptance criteria, and the four treatment options), a compact example risk register, and how its findings should trace forward into your Statement of Applicability. If you already run a NIS2 Article 21(2)(a) risk analysis, there’s a section on how much of that work carries over and what still needs to be built.

Why Clause 6.1.2 Demands a Methodology, Not a Risk List

ISO 27001’s risk clause has a specific structure. Before you’re allowed to identify a single risk, the standard requires you to “establish and maintain information security risk criteria” — including risk acceptance criteria — and criteria for how assessments will be performed. [2] Only after that groundwork is defined does the standard let you identify, analyse, and evaluate risks. The order matters: an auditor checking clause 6.1.2 conformance verifies the criteria existed before the assessment ran, not that they were reverse-engineered afterward to justify whatever numbers came out.

The repeatability requirement is where most ad-hoc risk lists collapse. If “likelihood” and “impact” aren’t defined against fixed scales every assessor uses the same way, two people scoring the same scenario a year apart will land on different numbers — and an auditor has no way to tell whether your risk picture actually changed or your scoring just drifted. A documented methodology fixes the scales, names who participates, states the review interval, and keeps a version history an assessor can trace. [2] That documentation is usually a single standalone document — commonly titled the Risk Assessment Methodology — that sits alongside, but separately from, the risk register itself.

For where this clause sits inside the full ISO 27001 clause structure, and how it connects to certification, see our ISO 27001 compliance guide.

The ISO/IEC 27005:2022-Aligned Approach: Two Ways to Identify Risk

ISO 27001 doesn’t mandate a specific risk methodology — it leaves that choice open, provided the result is documented and repeatable. In practice, most ISMS implementations align their methodology to ISO/IEC 27005, the companion standard written to guide information security risk management under ISO 27001. [1] Which version matters: the 2018 edition ran twelve clauses across six annexes built almost entirely around a single asset-threat-vulnerability model, while the 2022 revision compresses that into ten clauses and one annex, and adds a second identification approach alongside it. [3]

The two approaches ISO/IEC 27005:2022 now describes are: [1][3][4]

• Asset-based identification — the traditional, in-depth model. You inventory assets (systems, data stores, processes), map the threats that could act against each one, and identify the vulnerabilities a threat could exploit. This is granular and thorough, but it can be slow to run across a large estate.
• Event-based (scenario) identification — a newer, higher-level model. You start from plausible risk scenarios — a ransomware event, a supplier breach, a cloud outage — and work outward to the assets, stakeholders, and business objectives each scenario would affect. It’s faster to run and better suited to communicating risk to a board that doesn’t think in asset inventories.

Most organisations don’t pick one exclusively. A common, defensible pattern is an event-based pass first to identify which scenarios matter most, then asset-based detail only for the scenarios that clear a materiality threshold. Whichever mix you choose, your methodology document should state which approach you use and why — “we do both, for everything” rarely reflects what actually happened and reads as unconsidered to an auditor.

Scoring Risk: Likelihood x Impact and Setting Acceptance Criteria

Once a risk scenario is identified, ISO 27001 requires it to be analysed and evaluated against consistent criteria. [2] The near-universal mechanism is a likelihood x impact matrix: both dimensions are scored on a fixed scale (3-point and 5-point scales are both common), and the product gives a risk score. A 5×5 matrix scored 1–5 on each axis produces scores from 1 to 25, which map into bands — low, medium, high, critical — that determine what happens next.

What separates a compliant methodology from an informal one is what happens at the boundary of those bands. Clause 6.1.2 requires the organisation to define risk acceptance criteria before assessment begins — a documented answer to “above what score does this risk require formal treatment, and below what score can it simply be accepted and logged?” [2] Without that threshold set in advance, every treatment decision looks arbitrary to an auditor, even when the underlying judgment was sound. With it defined, a risk owner can point to the register, the score, and the pre-agreed threshold, and the decision defends itself.

Risk Treatment: The Four Options ISO 27005 Recognises

Scoring a risk only tells you how serious it is, not what to do about it. ISO/IEC 27005 groups every response into four treatment options, and your methodology document should state which one was chosen for each risk above the acceptance threshold, and why. [1][3]

• Modify — apply a control (typically drawn from Annex A) to reduce likelihood, impact, or both. This is the most common outcome and the one that feeds directly into the Statement of Applicability.
• Retain (accept) — a documented decision that the risk, at its current score, doesn’t warrant further action. Acceptance is a legitimate outcome, not a failure to act — provided it’s a deliberate, recorded decision made against the acceptance criteria, not silence.
• Avoid — eliminate the activity or asset that creates the risk entirely, for example by discontinuing a legacy system rather than securing it.
• Share — transfer part of the risk to a third party, most commonly through cyber insurance or a supplier contract that shifts liability.

ISO/IEC 27005:2022 puts particular weight on one detail here: the risk treatment plan and the acceptance of residual risk both need a named, accountable risk owner to formally approve them — not just the person who ran the assessment. [3] An auditor checking treatment decisions will look for that sign-off specifically, separate from the analyst’s working notes.

A Compact Risk Register Example

The register is where methodology becomes evidence: one row per risk scenario, scored consistently and carried through to a treatment decision. A full ISMS register typically runs to dozens or hundreds of rows across an organisation’s asset estate, but the structure scales down cleanly. Here’s a five-row illustration of the format:

Asset / scenario	Threat	Likelihood (1–5)	Impact (1–5)	Risk score	Treatment
Customer database (production)	Ransomware encryption via compromised admin credentials	3	5	15 (High)	Modify — MFA on admin accounts, offline backups, EDR
Cloud storage bucket (backups)	Misconfigured public access	2	4	8 (Medium)	Modify — automated configuration scanning, access review
Managed payroll supplier	Supplier breach exposing employee PII	2	4	8 (Medium)	Share — contractual liability clause + cyber insurance
Legacy internal reporting tool	Unpatched software, no vendor support	4	2	8 (Medium)	Avoid — decommission, migrate to supported platform
Guest Wi-Fi network	Unauthorised network access to guest segment	2	1	2 (Low)	Retain — below acceptance threshold, reviewed annually

Notice that the treatment column doesn’t just name an option — it names the specific action or control tied to that decision. That specificity is what an auditor traces forward into the Statement of Applicability, and what a risk owner points to a year later when the assessment is repeated and someone asks whether the treatment actually happened.

From Risk Register to Statement of Applicability

A risk assessment that never leaves its own spreadsheet hasn’t done its job under ISO 27001. Clause 6.1.3 requires the organisation to select controls to treat the identified risks and to produce a Statement of Applicability (SoA) — the document that runs through all 93 Annex A controls and states, for each one, whether it’s applicable, and why. The connection an auditor checks most closely is traceability: does each “applicable” justification in the SoA point back to a specific risk in the register, and does each “not applicable” justification explain why no relevant risk exists?

This is where a lot of first-time ISMS builds go wrong. It’s easy to write a plausible-sounding justification for including a control — “access control is obviously needed” — without opening the risk register to check which specific risk that control actually treats. An auditor who spots that pattern across several controls will reasonably conclude the SoA was written independently of the risk assessment, which undermines the ISMS’s internal logic, not just one document. For the full template and worked structure, see our Statement of Applicability template guide. A gap analysis run before this stage — covered in our ISO 27001 gap analysis guide — is a useful way to catch missing traceability early.

Already NIS2-Compliant? Your Article 21(2)(a) Risk Analysis Is a Real Head Start — Not a Finish Line

If your organisation is already subject to NIS2, you have almost certainly done risk analysis work under Article 21(2)(a), which requires essential and important entities to maintain “policies on risk analysis and information system security” as one of the ten baseline risk-management measures. [5] That existing work is a genuine asset when you start an ISO 27001 project — it’s not wasted effort, and it sits inside the roughly 70–80% foundational overlap between the two frameworks that shows up consistently once you compare them control by control.

But “we did a risk analysis” and “we have a clause 6.1.2-conformant risk assessment methodology” are not the same claim, and the gap between them is usually specific rather than total. Three things typically need to be added or reformalised:

• A fixed scoring model. NIS2’s Article 21(2)(a) doesn’t mandate a particular likelihood x impact matrix or acceptance-criteria threshold — many NIS2 risk analyses are narrative documents describing risks in prose rather than scored rows. ISO auditors expect a defined, numeric, repeatable scale.
• A standardised register format. The asset/scenario → threat → likelihood → impact → score → treatment structure an ISO auditor expects to see is more granular and more consistently formatted than most NIS2 risk documentation, which is often organised around the ten Article 21(2) measures rather than individual risk scenarios.
• Documented traceability to the SoA. NIS2 has no equivalent of the Statement of Applicability, so even a thorough NIS2 risk analysis has never had to prove that each finding maps to a specific control decision — that link has to be built from scratch.

The practical upshot: expect your NIS2 risk analysis to shorten the identification phase significantly — the assets, threats, and vulnerabilities are usually already known — while the scoring methodology, acceptance criteria, and register format still need dedicated build time. For the fuller business case and a decision framework on whether to start that build now, see our guide on pursuing ISO 27001 certification as a NIS2-compliant organisation.

FAQ

Does ISO 27001 require you to use ISO/IEC 27005 specifically?
No. ISO 27001 clause 6.1.2 requires a documented, repeatable methodology, but it doesn’t mandate a specific one. [2] ISO/IEC 27005 is the companion standard written to guide that methodology and is the most common choice, but frameworks like NIST SP 800-30 are also used, provided the result meets clause 6.1.2’s consistency and documentation requirements.

How often does the risk assessment need to be repeated?
ISO 27001 doesn’t set a fixed interval. Most organisations repeat the full assessment annually and update it after significant changes — a new system, a major incident, or a materially new threat. Your methodology document should state your chosen interval explicitly, since that statement is itself part of what an auditor checks.

What’s the difference between a 3-point and a 5-point likelihood/impact scale?
Both are valid under ISO 27001; the standard doesn’t specify scale size. A 3-point scale (low/medium/high) is faster to apply consistently across a large team but gives coarser risk bands. A 5-point scale differentiates risks more finely but requires more assessor training to score consistently — often the wrong starting choice, simply because consistency is harder to maintain.

Can accepting a risk (retention) cause an audit finding?
Not on its own. Retention is one of the four recognised treatment options. [1][3] What causes a finding is an undocumented acceptance — a risk with no recorded owner sign-off, or one accepted above the organisation’s own stated acceptance threshold with no justification for the exception.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• [1] ISO/IEC 27005:2022 — Information security, cybersecurity and privacy protection: Guidance on managing information security risks, ISO.org
• [2] How to Implement ISO 27001:2022 Clause 6.1.2 Information Security Risk Assessment, ISMS.online
• [3] ISO/IEC 27005:2022: Main Changes and Implications, PECB
• [4] The ISO 27005 Approach to Information Security Risk Management: 2022 Updates Explained, Secureframe
• [5] NIS 2 Directive, Article 21 — Cybersecurity risk-management measures, nis-2-directive.com (verbatim mirror of Directive (EU) 2022/2555)