ISO 27001 Risk Assessment: How to Conduct Clause 6.1.2 and Build a Risk Register That Satisfies Auditors

Why the risk assessment is the centrepiece of ISO 27001

ISO 27001:2022 is often described as a risk-based standard — and clause 6.1.2 is where that description becomes concrete. Before you can write a Statement of Applicability, select Annex A controls, or claim ISO 27001 certification, you must conduct a systematic information security risk assessment. Without it, you have no documented basis for the controls you've selected or excluded.

Auditors spend significant time on the risk assessment during certification audits. They test whether your risk register is credible, whether the identified risks are connected to real threats and vulnerabilities, whether risk owners are assigned, and whether the Annex A control selections in your SoA are traceable back to assessed risks. A risk register that looks like it was generated in an afternoon without any genuine analysis is a major finding.

This guide covers what clause 6.1.2 actually requires, how to build a risk register that satisfies auditors, and how the risk assessment connects to the Statement of Applicability and risk treatment plan.

What ISO 27001:2022 clause 6.1.2 requires

Clause 6.1.2 requires that your organisation defines and applies an information security risk assessment process that:

Establishes and maintains information security risk criteria, including risk acceptance criteria and criteria for performing risk assessments
Ensures that repeated risk assessments produce consistent, valid, and comparable results
Identifies information security risks — including assets, threats, and vulnerabilities within the defined ISMS scope
Analyses information security risks by assessing the realistic likelihood and consequences of identified risks, and determining risk levels
Evaluates information security risks against your risk criteria and prioritises risks for treatment

The output is documented risk assessment results. These results must be retained as documented information (i.e., you can't just do this in your head — it must be written down and controlled as a document).

The 5×5 risk matrix: likelihood × impact

ISO 27001 doesn't mandate a specific risk scoring methodology. The most common approach in use is a 5×5 matrix where risk score = likelihood (1–5) × impact (1–5), producing scores from 1 to 25. ISO 27005 (the risk management standard that supports ISO 27001) provides guidance on calibrating these scales.

Level	Likelihood	Impact	Typical score range	Action
Critical	≥4	≥5 (or L×I ≥20)	20–25	Immediate treatment required
High	3–4	3–5 (L×I 12–19)	12–19	Treatment plan with defined timeline
Medium	2–3	2–4 (L×I 6–11)	6–11	Treatment plan, monitored
Low	1–2	1–3 (L×I <6)	1–5	Accept or monitor; document rationale

The key principle is consistency: you must apply the same methodology every time you run the assessment. If your methodology changes, that's a version change requiring management approval and documentation.

What goes in each risk register entry

Each entry in the risk register must contain enough information for an auditor to understand the risk, its basis, and what's being done about it. A minimal risk register entry should contain:

Risk ID — a unique identifier (R-001, R-002, etc.) for traceability
Information asset — what asset is at risk (customer database, employee endpoints, source code, cloud infrastructure, etc.)
Threat — what could go wrong (phishing attack, ransomware, insider exfiltration, supply chain compromise, misconfigured cloud storage)
Vulnerability — why the threat could materialise (absence of MFA, unpatched software, no secrets rotation, no DLP)
Likelihood score (1–5) and Impact score (1–5)
Risk score and risk level (Critical / High / Medium / Low)
Risk owner — the individual accountable for treatment
Treatment decision — Mitigate / Transfer / Avoid / Accept
Annex A control reference — the specific ISO 27001:2022 Annex A controls that address this risk
Control implementation status — Planned / Partial / Implemented / Reviewed
Residual risk score — the expected risk level after controls are in place

The connection between risk register entries and Annex A control selections is precisely what the Statement of Applicability documents. Auditors will cross-reference the two: every control in the SoA should be traceable to at least one risk in the register, and every significant risk should have corresponding controls.

Identifying assets, threats, and vulnerabilities for SaaS companies

For a cloud-native SaaS, the asset register typically includes five categories:

Asset Category	Examples	Common Threats	Key Annex A Controls
Customer data	Personal data, tenant data, auth tokens	Exfiltration, breach, ransomware	A.5.12, A.8.24, A.5.33
Infrastructure	Cloud VMs, databases, Kubernetes clusters	Misconfiguration, privilege escalation	A.8.20, A.8.9, A.5.18
Source code / IP	Code repositories, CI/CD pipelines	Supply chain attack, insider theft	A.8.25, A.8.29, A.5.21
Endpoints	Laptops, developer machines	Malware, theft, phishing	A.8.7, A.8.1, A.6.3
Credentials / secrets	API keys, cloud access keys, certificates	Exposure in repos, rotation failure	A.5.17, A.8.24

The four risk treatment options

ISO 27001 clause 6.1.3 requires that risks are addressed through one of four treatment options:

Mitigate — implement controls to reduce the risk to an acceptable level. This is the most common treatment and results in Annex A control selections in your SoA.
Transfer — contractually or financially transfer the risk to another party (insurance, contractual liability shift, outsourcing to a certified provider).
Avoid — cease the activity that creates the risk. A valid option if the business process generating the risk isn't essential.
Accept — acknowledge the residual risk and document a formal acceptance decision. Acceptance must be documented with management sign-off and reviewed annually. Auditors will scrutinise accepted risks — they expect to see a conscious decision with documented rationale, not a lazy default.

How the risk assessment connects to the Statement of Applicability

This is the critical link that many organisations get wrong. Your Statement of Applicability (clause 6.1.3(d)) must include all 93 Annex A controls from ISO 27001:2022, with a documented decision for each: applicable or not applicable, and the justification for that decision.

The justification for inclusion typically references the risk register: "Control A.8.7 (malware protection) is applicable because risk R-004 (ransomware infection of employee endpoints, score 12 — High) requires anti-malware controls as part of the Mitigate treatment." The justification for exclusion must include why the control is not applicable (e.g., "A.7.1 (physical perimeter security) is not applicable — the organisation is cloud-native with no physical premises").

A common audit finding is an SoA with all 93 controls marked as applicable with no traceability to the risk register. Auditors will ask: "If everything is applicable, what risks justify all of them?" — and if you can't answer, you have a nonconformity.

Common risk assessment mistakes that cause audit findings

Mistake	Why it's a finding	How to fix it
All risks rated the same (e.g., all Medium)	Shows the methodology wasn't genuinely applied	Calibrate likelihood and impact independently for each risk
No risk owners assigned	Clause 6.1.2(d) requires risk owners	Assign named individuals (not roles) to each risk
Risk register not updated after incidents	Clause 10.1 improvement; shows dormant document	Include risk register review triggers in your IRP
Annex A controls not traced back to risks	SoA selections have no documented rationale	Add Annex A reference column to each risk register entry
Accepted risks without management sign-off	Acceptance must be a conscious management decision	Create formal risk acceptance table with signature block
Risk assessment not reviewed annually	Clause 6.1.2 requires periodic reassessment	Schedule annual review; trigger on major changes too

Review triggers: when to update the risk assessment

Annual review is the minimum. But ISO 27001 also requires that the risk assessment be reconsidered when significant changes occur. Common triggers include:

New product features or significant architecture changes
A significant security incident or near-miss
New sub-processors or major third-party relationships
Entry into a new jurisdiction with new regulatory requirements
Changes to the ISMS scope
New threat intelligence (major CVE, industry-specific attack campaign)
Acquisition or merger

Document these triggers in your Risk Assessment Methodology section. Auditors will ask how often the assessment is reviewed and what triggers an out-of-cycle review.

⚠️ This guide is for informational purposes only and does not constitute legal advice. Consult a qualified ISO 27001 auditor or information security consultant for advice specific to your organisation.