The ISO 22301 risk assessment is the half of clause 8.2 that gets skipped. The business impact analysis tells you what an interruption would cost and how fast an activity has to come back; the risk assessment asks what could cause the interruption in the first place, and how likely that is. Clause 8.2 requires both, and a BCMS built on one of them has a predictable failure mode.
This guide covers what the risk assessment has to cover, how it differs from an information security risk assessment, and how its output feeds the strategy decisions that follow.

What the ISO 22301 risk assessment is for
Its subject is disruption. For each prioritized activity and the resources it depends on, the assessment identifies what could stop it, evaluates how likely that is and what it would do, and decides which risks need treatment. The BIA has already established the consequence of the activity stopping — the risk assessment is about the causes and their probability.
| Business impact analysis | ISO 22301 risk assessment | |
|---|---|---|
| Question | If this stops, what happens and how quickly does it hurt? | What could make it stop, and how likely is that? |
| Output | Prioritized activities with MTPD, RTO, RPO and minimum resources | Disruption risks with likelihood, consequence and treatment decisions |
| Drives | Recovery targets and resource requirements | Preventive measures and the choice of continuity strategies |
| Owner in practice | Activity owners, with BCM facilitation | BCM and risk, with activity and resource owners |
The ISO 22301 risk assessment and the BIA both feed clause 8.3. The BIA says an activity must be back inside four hours; the risk assessment says the most likely cause of it stopping is a single supplier with no alternate. Together they justify the strategy. Separately, each produces a plan with a hole in it. Our guide to the ISO 22301 business impact analysis covers the other half in detail.
What an ISO 22301 risk assessment covers, and at what level
Assess disruption to the resources that prioritized activities depend on, rather than to the activities in the abstract. That gives a workable list:
- People — loss of key skills, concentration of knowledge in one person, absence at scale.
- Premises — denial of access, utilities failure, the site being unusable rather than destroyed.
- Technology — platform failure, ransomware, a dependency on one data centre or one region.
- Information — loss, corruption, or inaccessibility of the records the activity needs.
- Suppliers and partners — failure, insolvency, or their own disruption reaching you.
An ISO 22301 risk assessment is most productive when framed as the single point of failure question, asked per resource: if this one thing were unavailable for the MTPD, what would we do? Risks that survive that question are the ones worth treating.
Likelihood is where BCMS risk assessments go wrong
Two habits undermine the output. The first is scoring likelihood on gut feel with no scale — the fix is defined risk criteria agreed before scoring, so that “unlikely” means the same thing in two departments. The second is scoring the hazard rather than the disruption: the probability that matters is not the chance of a storm but the chance that a storm makes this activity unavailable beyond its tolerance, given what you already have in place.
How this differs from an ISO 27001 risk assessment
The vocabulary is shared and the scope is not. An information security risk assessment looks at confidentiality, integrity and availability of information assets. The ISO 22301 risk assessment looks at availability of activities — including ones with no information component, such as a physical process or a customer-facing service.
They overlap heavily on technology and supplier risk, and it is reasonable to run one exercise producing two views, provided the criteria and the register can carry both. What does not work is submitting an information security risk assessment as the continuity one: an auditor reading it will find no assessment of premises, people or the physical dependencies, and clause 8.2 will be raised as a finding.
Turning the ISO 22301 risk assessment into treatment
Continuity treatment options are narrower than general risk treatment, and naming them makes the decisions cleaner:
- Reduce the likelihood — resilience in the infrastructure, supplier diversification, maintenance regimes.
- Reduce the impact — standby capacity, alternate sites, cross-trained staff, manual workarounds.
- Transfer part of the consequence — insurance and contractual remedies, which fund recovery but never deliver it.
- Accept, explicitly and at the right level, where the cost of treatment exceeds the exposure.
Record the decision, the owner and the review date against each risk. The audit test is not whether your register is comprehensive but whether the strategies in clause 8.3 can be traced back to something in it — and whether the risks you accepted were accepted by somebody with the authority to do so.
Frequently asked questions
Does ISO 22301 require a risk assessment?
Yes. Clause 8.2 requires both a business impact analysis and a risk assessment; they answer different questions and neither substitutes for the other.
Can we reuse our ISO 27001 risk assessment?
Partly. The technology and supplier risks transfer; the people, premises and physical-process disruption risks generally do not appear in an information security assessment at all.
What scale should we use?
Whatever your defined risk criteria say, provided the definitions are written down and applied consistently. Undefined labels make the register impossible to aggregate.
How often should it be repeated?
At planned intervals and whenever something material changes — a new site, a new critical supplier, a significant technology migration, or a disruption that revealed a cause you had not listed.
Who signs off the accepted risks?
Someone with the authority to accept the consequence. A continuity risk accepted by the BCM coordinator alone is not an organizational acceptance.
Where this leaves you
Run the ISO 22301 risk assessment against the resources your prioritized activities depend on, score it against criteria you agreed in advance, and ask the single-point-of-failure question for each dependency at its MTPD. Keep it distinct from the BIA — one is about causes, the other about consequences — and make sure every continuity strategy can be traced back to a risk somebody owns. That traceability is what an auditor tests, and it is the part most BCMS documentation cannot show.
References
- ISO 22301:2019 — Security and resilience, business continuity management systems, including clause 8.2.
- ISO 31000:2018 — the risk management guidelines behind the criteria and process.
More on business continuity
- The ISO 22301 risk assessment — you are here
- The ISO 22301 business impact analysis
- Running an ISO 22301 gap analysis
- Setting risk criteria
The scoring workbook that carries the BIA and the risk assessment together is the ISO 22301 Assessment Tool, or start with the free ISO templates.