ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
An ISO 27001 risk assessment is the process of identifying what could compromise the confidentiality, integrity or availability of information inside your ISMS scope, scoring each risk for likelihood and impact, and deciding which risks you will treat. Clause 6.1.2 of ISO/IEC 27001:2022 requires you to define the method before you use it; clause 8.2 requires you to run it at planned intervals and retain the results. Everything else in the ISMS depends on it — the Statement of Applicability, the risk treatment plan and every control justification trace back to this one exercise. For a first ISMS, budget two to four weeks of elapsed time.
Clause 6.1.2 is short, and every line of it is auditable. It requires you to establish and maintain information security risk criteria — both the criteria for accepting risk and the criteria for performing assessments — and then to ensure that repeated assessments produce consistent, valid and comparable results. That last phrase is what separates a method from a workshop. If two people assess the same risk six months apart and land in materially different places, you have not met 6.1.2.
The clause then sets out three activities in sequence:
Clause 8.2 is the operational twin. It requires you to perform information security risk assessments at planned intervals, or when significant changes are proposed or occur, and to retain documented information of the results. Your risk register, with a visible review history, is what evidences 8.2.
What the standard deliberately does not do is prescribe a method. Since the 2013 revision, ISO 27001 has not required an asset-based approach — any method qualifies as long as it is documented, repeatable and produces comparable results. If you want a published method to anchor on rather than inventing one, ISO/IEC 27005:2022 is the companion guidance standard for managing information security risks, published in October 2022 as the fourth edition. It is guidance only. No certification body audits you against it.
This is the sequence that survives Stage 2.
1. Write the method before you score anything. Document who runs the assessment, the scales you use for likelihood and impact, how those two combine into a risk level, your acceptance threshold, and how often you reassess. This document is the thing that makes the exercise repeatable, and it is usually the first artifact an auditor opens. They will then check whether your register actually follows it.
2. Confirm the ISMS scope, then build the input list. Lock the scope statement first, then list what sits inside it: information assets and data stores, the processes that use them, the systems and cloud tenants that host them, the suppliers who touch them, and the people and locations involved. Anything outside scope stays out.
3. Identify risks, not missing controls. This is where most first attempts go wrong. “No MFA on the admin console” is a gap. The risk is “an attacker uses credential stuffing against the admin console and exports the customer database.” Write each entry as a sentence containing a threat, the weakness it exploits, the asset affected and the consequence. Then name a risk owner for every line — the standard requires it, and unowned risks never get treated.
4. Analyse likelihood and impact. Score both on the scale defined in your method. Decide explicitly whether you are scoring inherent risk (ignoring current controls) or residual risk (with them in place). Both are acceptable; scoring some rows one way and some the other is not. Most organizations score residual, because it maps directly to the decisions they have to make next.
5. Evaluate against your acceptance criteria. Compare each risk level to the threshold you wrote down in step 1 and sort into accept, treat now, or treat later. The threshold is a business decision made by management, not a number a consultant hands you.
6. Record a treatment decision and get the owner to sign it. Four options exist for every risk above the line: modify it by applying controls, avoid it by not doing the activity, share it through insurance or contract, or retain it as an accepted risk. Accepted risks need explicit sign-off by the risk owner and a review date. An accepted risk with no signature is an unmanaged risk.
Two approaches dominate, and certification bodies accept both. The choice determines how big your register gets and how much of the work is mechanical.
| Asset-based | Scenario-based (event-based) | |
|---|---|---|
| Starting point | An inventory of assets, then threats and vulnerabilities for each | A set of plausible security events, then what they would hit |
| Register size | Large — often several hundred rows for a mid-sized company | Compact — typically a few dozen well-written scenarios |
| Strength | Systematic coverage; hard to miss an asset class | Reads like the real world; easier for management to engage with |
| Weakness | Repetitive, and the register ages fast as assets change | Coverage depends on the imagination of the people in the room |
| Best for | Regulated, asset-heavy or on-premise environments | Cloud-native companies and small security teams |
A hybrid works well in practice: run a scenario-based assessment as the backbone, then use an asset inventory as a completeness check to catch anything the scenarios missed. What matters to the auditor is that whichever approach you pick is the one your documented method describes.
Most of an ISO 27001 risk assessment is judgement applied consistently, which is easier to show than to describe. Say your method uses a 5×5 matrix — likelihood 1 (rare) to 5 (almost certain), impact 1 (negligible) to 5 (severe) — with the risk level as the product of the two, giving a range of 1 to 25. Suppose management sets the acceptance threshold at 8: score 8 or below is acceptable, 9 to 14 needs treatment this year, and 15 or above needs treatment now. Those numbers are an example, not a standard requirement; you choose your own and record them.
| ID | Risk statement | Owner | L | I | Level | Decision |
|---|---|---|---|---|---|---|
| R-08 | An attacker uses stolen credentials against the internet-facing admin console and exports customer records | CTO | 4 | 5 | 20 | Treat now — enforce phishing-resistant MFA, alert on bulk export |
| R-14 | A departing employee retains access to the code repository after their last day | Head of People | 3 | 4 | 12 | Treat this year — automate offboarding, quarterly access review |
| R-21 | The single payment provider suffers an outage and checkout is unavailable for a working day | COO | 2 | 3 | 6 | Accept — signed off by COO, review in 12 months |
Three things make these rows defensible. Each statement describes an event with a consequence rather than a missing control. Each has a named human owner, not a department. And the accepted risk carries an explicit sign-off and a review date, which is exactly what an auditor looks for when they sample your acceptances. The controls named in the decision column are then the ones you justify in the ISO 27001 Statement of Applicability.
People conflate these constantly. They are separate documents with separate clause hooks, and an auditor will ask for all three by name.
| Document | What it contains | Clause |
|---|---|---|
| Risk assessment methodology | Scales, scoring rules, acceptance criteria, roles, review frequency | 6.1.2 (a)–(b) |
| Risk register / assessment results | Every identified risk with owner, scores, level and treatment decision | 6.1.2 (c)–(e), 8.2 |
| Risk treatment plan | The outstanding actions, owners, target dates and status | 6.1.3, 8.3 |
The Statement of Applicability sits downstream of all three under clause 6.1.3(d). Build it in that order — assessment, treatment decisions, then SoA — and the justifications write themselves. Build it the other way round, by opening Annex A and ticking boxes, and you end up with justifications that collapse under a single follow-up question. All four documents appear on the list of ISO 27001 mandatory documents your certification body will request at Stage 1.
If you would rather start from a working method than a blank spreadsheet, the ISO 27001 Toolkit ($99, 175 editable Word and Excel templates) includes a documented risk assessment methodology, a pre-built risk register with the scoring matrix already wired up, a risk treatment plan, and a Statement of Applicability with all 93 Annex A controls loaded. It is the same document set used to take organizations through ISO 27001 certification.
Annually is the floor, normally timed to feed management review. Clause 8.2 also requires a reassessment whenever significant changes are proposed or occur: the ISMS scope changes, you adopt a significant new cloud service, you take on a supplier with access to production data, you acquire another entity, a new legal or contractual obligation lands, or an incident exposes something the register did not anticipate. Fast-moving companies often run a lighter quarterly review between the full annual passes.
Two dates matter right now. The transition from ISO/IEC 27001:2013 to the 2022 edition closed on 31 October 2025, so a register still mapped to the old 114-control structure is no longer certifiable — the current set is 93 controls across four themes. And Amendment 1:2024, published free by ISO, added a requirement to determine whether climate change is a relevant issue for the organization. Where it is relevant, the risks it creates belong in the ISO 27001 risk assessment like any other risk: identified, scored, owned and treated. Our breakdown of the ISO 27001:2022 Annex A controls covers the current structure in detail.
Most of these surface at Stage 1, which is what Stage 1 exists for. Fixing them before the certification body arrives costs a few days; fixing them as a nonconformity after Stage 2 costs a corrective action cycle. The ISO 27001 audit process guide walks through what gets examined at each stage.
No. The standard requires that your method is documented, applied consistently and produces comparable results over time. A simple likelihood × impact matrix satisfies clause 6.1.2 perfectly well. ISO/IEC 27005:2022 and NIST SP 800-30 are common reference methods, but neither is mandatory and you are not audited against them.
For a first pass at a small to mid-sized company with a clearly defined scope, two to four weeks of elapsed time is typical — roughly a week to agree the method and criteria, a week or two of identification workshops, and a few days to score, rank and get owner sign-off. Complex or multi-site scopes take longer. Annual refreshes are much faster once the register exists.
No. A well-structured spreadsheet meets every requirement in clause 6.1.2 and 8.2, and plenty of certified organizations run on exactly that. Dedicated GRC tooling helps once the register gets large or several teams need to update it at once, but it is a convenience, not a compliance requirement.
The ISO 27001 risk assessment establishes what the risks are, how serious they are and who owns them. The risk treatment plan is the schedule of work that follows: which actions are outstanding, who is doing them and by when. One is a statement of position, the other is a plan of action.
Yes. Clause 6.1.3 requires the risk owner’s approval of the residual risks. In practice that means a name, a date and a review point recorded against every risk you decide to retain. Unsigned acceptances are one of the more common findings raised against an otherwise sound ISO 27001 risk assessment.
August 11, 2026
August 10, 2026
August 9, 2026
August 7, 2026
