If there is one activity that defines ISO 27001, it is risk assessment. The standard is fundamentally risk-based: rather than handing you a fixed list of controls, it requires you to identify what could harm your information and choose controls in proportion to those risks. This is what makes an ISMS efficient and defensible.
This practical guide explains how to run an ISO 27001 risk assessment: choosing a method, identifying and rating risks, deciding treatments, and connecting it all to your controls on the path to iso 27001 certification.
Why risk assessment is central
ISO 27001 does not tell you which controls to implement; it tells you to assess risk and treat it. That single design choice puts risk assessment at the heart of everything. Your Statement of Applicability, your controls, and your priorities all flow from it.
It is also what auditors probe hardest. Pick any control and they will ask ‘why is this here?’, expecting an answer that traces to an identified risk. A weak risk assessment undermines confidence in the entire ISMS.
Investing properly here pays back across the whole project.
Choose a methodology first
Before assessing anything, define how you will do it. ISO 27001 requires a documented, repeatable risk-assessment methodology — one that would produce consistent results if two different people applied it. ISO 27005 offers aligned guidance, though you may use any sound method.
Your methodology should define how you identify risks, the scales you use for likelihood and impact, your risk criteria (what counts as acceptable), and how you will treat risks. Agreeing this up front prevents inconsistent, hard-to-defend results.
Keep it as simple as your context allows; complexity rarely improves the outcome.
Free resource
The Complete Guide to ISO 27001
A practical, plain-English guide to building your ISMS and earning ISO 27001 certification.
Asset-based vs scenario-based identification
There are two main ways to identify risks. The asset-based approach inventories your information assets and asks what threats and vulnerabilities apply to each. The scenario-based (event-based) approach starts from plausible scenarios — ‘customer data is exposed by a misconfiguration’ — and works back.
Asset-based is thorough but can become unwieldy; scenario-based is faster and more focused on what actually matters. The 2022 edition of ISO 27005 explicitly supports both, and many teams blend them.
Choose the approach that fits your size and complexity rather than forcing one model.
Identify your risks
With a method chosen, identify the risks to the confidentiality, integrity, and availability of information in your scope. Draw on real sources: past incidents, threat intelligence, known vulnerabilities, staff knowledge, and the obligations of interested parties.
Aim for risks that are specific enough to act on — ‘unauthorised access to the customer database via over-privileged accounts’ beats ‘hacking’. Specificity makes the later steps, especially control selection, far easier.
Capture each risk in a register, the living document at the centre of the assessment.
Analyse and evaluate
For each risk, estimate its likelihood and its impact using your defined scales, then combine them into a risk level. This turns a list of worries into a ranked set you can prioritise.
Evaluate each risk against your acceptance criteria: is this level tolerable, or does it require treatment? Consistency matters here — similar risks should receive similar ratings regardless of who assesses them, which is why the methodology exists.
The result is a clear view of which risks demand action and which can be accepted.
Decide on risk treatment
For risks above your acceptance threshold, choose a treatment. The classic options are: reduce the risk with controls, accept it consciously, avoid it by stopping the activity, or transfer it (for example via insurance or a supplier).
Most risks are reduced with Annex A controls. The choices you make here populate your risk treatment plan and, in turn, your Statement of Applicability — the explicit link auditors look for between risk and control.
Document the rationale for each decision, especially any conscious acceptances.
Connect risks to controls
The output of treatment is a mapping from risks to the Annex A controls that address them. This linkage is the spine of the ISMS: it justifies every control you implement and every control you exclude.
Building the Statement of Applicability directly from this mapping keeps the two consistent. When an auditor asks why a control exists, you point to the risk; when they ask why one is excluded, you point to the absence of a relevant risk.
This traceability is what separates a deliberate ISMS from an arbitrary pile of controls.
Document the risk register
The risk register is the central record of the assessment: each risk, its rating, its owner, its treatment, and its status. It is a key piece of audit evidence and a genuinely useful management tool.
Keep it practical — detailed enough to be meaningful, simple enough to maintain. A risk owner for each entry ensures accountability and keeps the register from going stale.
A clear, living register signals to auditors that risk genuinely drives your decisions.
Keep it alive
A risk assessment frozen at certification quickly becomes fiction. ISO 27001 requires you to review risk at planned intervals and when significant changes occur — a new product, a major supplier, a new market, or an incident.
Build these reviews into your maintenance rhythm so the register reflects reality. When risks change, your controls and Statement of Applicability may need to change too, keeping the whole system coherent.
A living risk assessment is also a real decision-making aid, not just an audit artefact.
Common risk-assessment mistakes
Frequent errors include: treating the assessment as a box-ticking exercise disconnected from controls; over-engineering an exhaustive asset register that never resolves into action; inconsistent scoring across assessors; and never revisiting the assessment after certification.
Another is vague risks too general to act on. The antidote to all of these is a clear methodology, specific risks, consistent criteria, and regular review — the discipline the standard is really asking for.
Avoiding these keeps the assessment useful rather than performative.
Tools and help
A well-structured spreadsheet is enough to run a solid risk assessment, especially for a focused scope. Compliance platforms can add value by linking risks to controls and evidence automatically and keeping the register current.
Because risk assessment is the part teams find most conceptually demanding, it is also where experienced help pays off most — a partner brings a proven methodology and calibration on what ‘good’ looks like.
ISpectra builds ISO 27005-aligned risk assessments as a standard part of every engagement, with free VAPT and a multi-framework discount.
The bottom line
Risk assessment is the engine of ISO 27001: choose a documented, repeatable methodology; identify specific risks to confidentiality, integrity, and availability; analyse and evaluate them consistently; decide treatments; and map risks to controls in your Statement of Applicability.
Keep the register alive through regular review, avoid the common pitfalls, and your controls will always trace back to real risk — exactly what auditors reward and what makes the ISMS genuinely effective.
Get this foundation right and the rest of the standard becomes far more straightforward; ISpectra can build it with you if risk is where your team feels least sure. ISpectra helps organisations achieve iso 27001 certification efficiently, from gap analysis through to the certificate.
Free consultation
Need help with ISO 27001?
Talk to our certified compliance team — we’ve supported 200+ audits.