Short answer
An ISO 27001 risk assessment, required by clause 6.1.2, identifies risks to the confidentiality, integrity and availability of information in the ISMS scope, names a risk owner for each, rates likelihood and consequence against criteria you defined in advance, and compares the result with your acceptance criteria to decide which risks need treatment.
Key takeaways
- Define risk criteria and acceptance criteria before you assess anything.
- Every risk needs a named risk owner, not just a department.
- The method must produce consistent, valid and comparable results when repeated.
- Risk treatment decisions drive the Statement of Applicability.
What clause 6.1.2 requires
ISO/IEC 27001 doesn't tell you which method to use. It tells you what the process must achieve. You must set risk criteria, including risk acceptance criteria and criteria for performing assessments. Repeated assessments must produce consistent, valid and comparable results. You must identify risks associated with the loss of confidentiality, integrity and availability within the ISMS scope, identify risk owners, assess consequences and likelihood, determine risk levels, and compare them with your criteria to prioritise treatment. The process must be documented, and so must its results (clause 8.2).
Step 1: set the criteria first
Most nonconformities in this area come from criteria that were never written down, or that changed between assessments. Decide the scales before the first workshop.
| Rating | Likelihood | Consequence |
|---|---|---|
| 1 | Rare: not expected in the next 3 years | Minor: no customer impact, fixed within a day |
| 2 | Possible: could happen in the next 3 years | Moderate: limited customer impact or contract breach risk |
| 3 | Likely: expected within 12 months | Major: regulatory notification, significant data loss or outage |
| 4 | Almost certain: happening now or several times a year | Severe: loss of key customers, licence or sustained outage |
Risk level is likelihood multiplied by consequence (1 to 16). A common acceptance rule is that risks scoring 8 or more need treatment, and risks below 8 can be accepted by the risk owner. Whatever you choose, write it down and get it approved by management.
Step 2: identify risks
You can identify risks from assets and their threats and vulnerabilities, or from scenarios. ISO 27001:2022 no longer requires the asset-based approach, but auditors still expect the result to cover the whole scope. Scenario-based assessments are usually faster and easier for business owners to understand. Use an asset inventory () to check you haven't missed anything.
Step 3: name risk owners and rate the risks
A risk owner is the person with the accountability and authority to manage the risk. That is usually a business or system owner, not the security team. Rate each risk against your scales, record the reasoning, and note the existing controls you relied on.
A worked example
| Risk | Owner | L | C | Level | Decision |
|---|---|---|---|---|---|
| Former employee keeps access to the CRM after leaving | Head of Sales Ops | 3 | 3 | 9 | Treat: automate deprovisioning, quarterly access review (A.5.18) |
| Ransomware encrypts file shares and backups | IT Manager | 2 | 4 | 8 | Treat: immutable backups, restore tests (A.8.13), EDR (A.8.7) |
| Supplier processing customer data has a breach | Procurement Lead | 2 | 3 | 6 | Accept with monitoring; reassess at contract renewal (A.5.19) |
The example scales and threshold are illustrations. Use criteria that fit your organisation, and keep them stable between assessments so results stay comparable.
Step 4: treat, and connect to the SoA
Clause 6.1.3 takes over from here. For each risk above your threshold, choose a treatment, determine the controls needed, and compare them with Annex A to make sure nothing necessary was missed. Those decisions produce the Statement of Applicability and the risk treatment plan, which the risk owners approve, including their acceptance of residual risk.
How often to reassess
Clause 8.2 requires risk assessments at planned intervals and when significant changes are proposed or occur. Annually is the usual planned interval. Significant changes include new products, new suppliers handling sensitive data, acquisitions, major architecture changes and serious incidents.
Checklist
Records auditors ask for
0 of 5 done
Put this into practice on QULDEX
Frequently asked questions
Does ISO 27001 require an asset-based risk assessment?
No. The 2022 edition, like 2013, doesn't require identifying risks from assets, threats and vulnerabilities. Scenario-based methods are acceptable if they cover the scope and give consistent results.
Who should own information security risks?
The person with the accountability and authority to manage the risk, usually a business or system owner. The security team facilitates the assessment but rarely owns the business risk.
How often must the ISO 27001 risk assessment be repeated?
At planned intervals, usually annually, and whenever significant changes are proposed or occur, as clause 8.2 requires.