.png)
%20(1).png)
.svg)
The short answer: An ISO 27001 risk assessment is the documented process of identifying what could go wrong with the information inside your ISMS scope, scoring likelihood and impact, and deciding what to do about the ones you cannot live with. ISO 27001 does not prescribe a method. It requires that yours is written down, produces consistent and comparable results, names an owner for every risk, and feeds a risk treatment plan and Statement of Applicability. A 5×5 matrix with a written acceptance threshold satisfies every auditor we have met.
The risk assessment is where a first-time ISO 27001 project either becomes real or becomes theatre. Every control you chose and every one you excluded is supposed to trace back to a risk you scored. When it does, Stage 2 is a conversation. When the register was downloaded and never touched again, Stage 2 is an interrogation. This page is the how, not the what: the clause itself is explained in our clause 8.2 guide.
{{snapshot}}
ISO 27001 risk assessment at a glance
- Two clauses, one process. Clause 6.1.2 says define the method and the criteria; clause 8.2 says run it at planned intervals and whenever something significant changes.
- The method is your choice. Asset-based, scenario-based or a hybrid all pass. What fails is no written method, or one that gives different answers on different days.
- Likelihood × impact is enough. A 5×5 matrix with defined scales and a written acceptance threshold is the most common approach in UK certifications.
- Every risk needs an owner, by name or role, who signs off the treatment decision. "IT" is not an owner.
- The output is three documents. A risk register, a risk treatment plan, and the justifications that populate your Statement of Applicability.
{{/snapshot}}
What clauses 6.1.2 and 8.2 ask you to produce
Clause 6.1.2 is the design brief. It requires a documented process that sets risk acceptance criteria, identifies risks to the confidentiality, integrity and availability of information in scope, assigns owners, analyses likelihood and consequence, and evaluates the results against the criteria. The phrase it leans on is "consistent, valid and comparable results": run the method twice and it should produce the same ranking.
Clause 8.2 is the operating instruction. Run the process at planned intervals, run it again when a significant change is proposed or occurs (a new product, an acquisition, a serious incident), and keep documented information of the results. Planned intervals means at least annually in practice. ISO/IEC 27001:2022 names no methodology and mandates no scoring scale. The flip side is that "we did it in our heads" is not a method either.
Asset-based or scenario-based: pick one and write it down
Asset-based assessment starts from an inventory: laptops, servers, SaaS tools, databases, people, suppliers. For each asset you ask which threats apply and which vulnerabilities make them credible. It is thorough and maps neatly onto Annex A. Its weakness is volume: a 40-person company with 300 assets and a dozen threats each has a register nobody will read.
Scenario-based assessment starts from events: "a laptop holding customer data is left on a train", "our payroll bureau is breached". It produces a shorter register that leadership will actually engage with. Its weakness is coverage: it is easy to forget the boring scenario that bites you.
Since the 2013 revision the standard has not required you to identify assets, threats and vulnerabilities explicitly, so either route is compliant. Our recommendation: build the asset register anyway, because scoping the ISMS and several Annex A controls depend on it, then assess risk at the level of asset groups and scenarios. Write the choice into your methodology document, with the scales below, and date it.
A worked example: scoring likelihood and impact
Define both scales before you score anything. This set works for a UK SaaS or services business.
Likelihood (1 to 5). 1: not expected within five years. 2: once in two to five years. 3: once a year. 4: several times a year. 5: monthly, or already happening. Phishing attempts reaching inboxes are a 5 everywhere; a successful one is usually a 3.
Impact (1 to 5). 1: minor inconvenience, no customer or regulatory effect. 2: internal disruption under a day, no personal data involved. 3: customer-facing disruption, a contractual notification, or a personal data breach affecting a handful of individuals. 4: a breach reportable to the ICO, loss of a key customer, or an outage over a day. 5: regulatory action, loss of the certificate, or the business unable to trade.
Score = likelihood × impact, giving a range of 1 to 25. Then the part people skip: the acceptance criteria. A set we see work: 12 and above must be treated, with a plan and a date. 8 to 11 must be treated or explicitly accepted by the risk owner and signed off at management review. 7 and below are accepted and reviewed annually. Any risk with an impact of 5 is treated regardless of likelihood, because low-probability catastrophes are what risk assessment exists to catch.
A risk register excerpt
Six rows from a register for a 60-person B2B SaaS company holding customer and employee data, scored on the scales above. The treatment column deliberately covers all four options the standard allows.
| Asset or scenario | Threat | Vulnerability | L | I | Score | Treatment | Owner |
|---|---|---|---|---|---|---|---|
| Production customer database | External attacker exfiltrates customer records | Database admin access reachable without MFA | 3 | 5 | 15 | Modify: enforce MFA and an IP allow-list on admin access | Head of Engineering |
| Staff laptops (fleet of 60) | Device lost or stolen with local data | Disk encryption not verified on every device | 4 | 3 | 12 | Modify: MDM-enforced encryption with compliance reporting | IT Manager |
| Payroll bureau (supplier) | Supplier breach exposes employee data | No security clauses in the contract, no due diligence on file | 2 | 4 | 8 | Share: contractual security terms plus an annual supplier review | Finance Director |
| Cloud hosting root account | Credential compromise gives full control of production | Root credentials shared between two people, no hardware key | 2 | 5 | 10 | Modify: hardware MFA, root locked away, named admin roles | CTO |
| Card details in support tickets | Cardholder data exposed in the ticketing system | Agents accept card numbers by email and paste them into tickets | 3 | 4 | 12 | Avoid: stop taking card details by ticket, redirect to a payment provider link | Head of Support |
| Legacy marketing site | Defacement or malware injection | Unpatched CMS plugin | 4 | 1 | 4 | Retain: below threshold, reviewed quarterly | Marketing Lead |
Two things to notice. The cloud root account scores 10, inside the discretionary band, yet it is treated because the impact is 5. The card-data row is avoided rather than mitigated: the cheapest control for a process you should not be running is to stop running it. Residual score, next review date and the Annex A controls treating each row are dropped here for width.
From register to treatment plan and Statement of Applicability
Clause 8.3 asks what you will do about the risks, and risk treatment is where the four options get applied: modify the risk with new or improved controls, retain it because it sits inside your acceptance criteria, avoid it by stopping the activity, or share it with a supplier or insurer through a contract. Sharing does not make a risk disappear; the payroll bureau row still needs an owner watching the supplier.
Each "modify" decision produces a line in the risk treatment plan: which control, who implements it, by when, and how you will know it worked. Auditors read the plan against the register, and a risk scored 15 with no treatment line is the fastest route to a non-conformity.
The same decisions populate your Statement of Applicability. Every Annex A control you select should point back to at least one risk it treats, and every control you exclude needs a justification that survives a read-through. Built from the treatment plan rather than a template, the justifications write themselves. That is the chain the auditor follows at Stage 2: context, scope, risk, treatment, control, evidence.
Keeping that chain intact is the main reason registers leave spreadsheets. In Hicomply, the risk register populates from the information asset register, so adding a SaaS supplier or a production database creates its candidate risks. Scoring is guided, or you load your own methodology if your auditor has already accepted one, and treatment plans and the SoA sit on the same records. CloudPass, a UK and EU access-control cloud provider, ran its ISMS from OneDrive folders and paid roughly £5,000 a year for consultants. After moving the register and evidence into Hicomply, it went through audit with zero non-conformities.
Owners, acceptance and review cadence
A risk owner is the person with authority to accept the risk or spend money treating it. That rules out "the IT team" and, usually, whoever ran the assessment. Get each owner to confirm the score and the decision in writing; that confirmation is the evidence that acceptance happened. Auditors distinguish between a risk consciously accepted by its owner and one that was simply never treated. The second is a finding waiting for a date.
On cadence: a full re-run annually, before management review, plus a targeted reassessment whenever clause 8.2's significant-change trigger fires. Keep earlier versions, because your surveillance auditor will want to see scores move as controls landed. A register that has not changed in twelve months tells the auditor something, and it is not that you are secure. If you deploy AI systems, the same discipline extends to an AI risk assessment under ISO 42001, where the scales carry over and the threats do not.
The generic register mistake, and three others
Copying someone else's register. The most common way to fail this part of the audit. A template register lists risks to a data centre you do not run and a scale nobody in your business can explain. Auditors spot it within minutes because the risks do not match what they saw during scoping. Start from your own asset register and incident log, however thin.
Scoring everything a 3. A register in which every risk is medium says nothing. If your top ten and bottom ten carry the same score, the assessors were hedging. Force a ranking.
Treating it as an IT exercise. Half the rows in a good register are about people, suppliers and processes. Run it as a workshop with engineering, operations, HR and finance in the room, which also settles ownership in one meeting. Our guide to ISO 27001 for small businesses covers sizing the rest of the ISMS to match.
Doing it after the controls. Pick controls first and back-fill risks to justify them, and the auditor will find the controls that treat no risk at all. Run a gap analysis to see what you have, then a risk assessment to decide what you need.
{{snapshot}}
Hicomply's take
We have read hundreds of risk registers, and the good ones share one trait: they are short enough that leadership has actually read them. Sixty well-scored risks with real owners beat four hundred rows of template nobody has opened since they were pasted in. The mistake we see most is spending three weeks perfecting the methodology and three hours running it. Reverse that. Agree the scales in an afternoon, get the right people in a room for a day, and let the register be wrong in places. You fix it at the next review.
{{/snapshot}}
Run a risk assessment your auditor can follow, without the 400-row spreadsheet
Done properly, the risk assessment takes a day of workshop time and an afternoon of write-up, then a couple of hours a quarter to keep alive. In a spreadsheet, add the weekend before every audit reconstructing who agreed to what.
Watch the two-minute risk assessment walkthrough to see the register populate from assets, then book a demo and bring your current register, however rough. We will tell you honestly whether it would survive Stage 2.
