Risk assessment

ISO 22301 Clause 8.2.3 requires you to perform a risk assessment that identifies and analyzes risks to your prioritized activities and the resources they depend on, then uses defined criteria to decide which risks need treatment through business continuity strategies (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements). Operationalize this by tying risks to BIA outputs, scoring them consistently, assigning owners, and retaining evidence that decisions were made and acted on.

Key takeaways:

• Scope the risk assessment to prioritized activities and their supporting resources, not generic enterprise risk.
• Use defined criteria (likelihood/impact and thresholds) so treatment decisions are auditable and repeatable.
• Keep evidence that links BIA → risk register → treatment decisions → continuity strategies and plans.

A common failure mode in business continuity programs is running a “risk assessment” that is either too broad (an enterprise risk register that never informs continuity plans) or too narrow (a list of scenarios without clear ties to what the business must keep running). ISO 22301:2019 Clause 8.2.3 is specific: assess risks to prioritized activities and the supporting resources that make those activities work (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements). That scope matters because it forces a line of sight from operational necessity to practical continuity decisions.

For a Compliance Officer, CCO, or GRC lead, the fastest path to a defensible implementation is to treat this requirement as a controlled workflow with defined inputs and outputs. Inputs come from your BIA and your dependency mapping. Outputs are a risk assessment record that ranks disruption risks, states evaluation criteria, and explicitly identifies which risks require treatment through business continuity strategies. If you cannot show that the assessment drives strategy selection and plan updates, auditors will treat the exercise as “paper compliance,” even if the document looks mature.

This page gives you requirement-level guidance you can put into operation immediately: who should own what, how to structure the scoring, what artifacts to keep, and where teams get stuck during certification audits.

Regulatory text

ISO 22301:2019 Clause 8.2.3 states: “The organization shall undertake risk assessments to identify and analyze risks to prioritized activities and supporting resources.” (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements)

What the operator must do (plain reading):

• Perform risk assessments (not optional; not ad hoc).
• Focus the assessment on prioritized activities (usually determined via BIA) and the supporting resources required to deliver them.
• Identify credible disruption risks and analyze them in a structured way.
• Use the analysis to decide which risks need treatment through business continuity strategies ¹ (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).

Plain-English interpretation (what auditors expect to see)

You need a repeatable method to answer, for each prioritized activity: “What could disrupt it, how bad would it be, how likely is it, and what are we doing about it?” The assessment should explicitly account for dependencies (people, facilities, technology, third parties, data, and key suppliers) and should produce decisions that change your continuity posture (strategies, plans, exercises, and investment priorities).

If your organization already has an enterprise risk management (ERM) process, you can reuse pieces of it. The ISO 22301 expectation is that BCMS risk assessment is traceable to continuity outcomes, not just recorded in a corporate risk tool.

Who it applies to (entity and operational context)

Applies to: Any organization implementing or certifying to ISO 22301, including business continuity practitioners and control owners supporting prioritized activities (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).

Operational context where it matters most:

• Organizations with defined prioritized activities (from a BIA) and dependencies that include shared services, IT platforms, critical facilities, and third parties.
• Regulated or customer-audited environments where you must prove continuity readiness, not just claim it.
• Complex operating models (multiple sites, outsourced functions, SaaS reliance) where supporting resources are the primary failure points.

What you actually need to do (step-by-step)

Use this as a minimal, auditable workflow. Adapt details, but keep the chain of evidence intact.

1) Lock the scope to BIA outputs

• Confirm the list of prioritized activities from the BIA (or equivalent prioritization method).
• For each activity, document supporting resources: teams/roles, applications, infrastructure, facilities, data sets, third parties, key records, and upstream/downstream process dependencies.
• Define assessment boundaries (sites, business units, critical products/services).

Operator tip: If you cannot map a risk to a prioritized activity and a dependency, it does not belong in this ISO 22301 8.2.3 assessment. Keep it in ERM instead.

2) Define and approve risk criteria (before scoring)

• Choose scoring dimensions your organization can apply consistently, typically:
  • Likelihood (qualitative scale)
  • Impact (aligned to BIA impact categories like operational, financial, legal/regulatory, safety, reputational)
  • Velocity or time-to-impact (optional, but useful for continuity)
• Define risk acceptance thresholds and what triggers treatment (e.g., “high” risks must have a continuity strategy decision recorded).
• Get criteria approved by the BCMS governance body (or equivalent).

Evidence goal: A documented method that prevents teams from “scoring to taste.”

3) Identify disruption scenarios for each prioritized activity

Build a scenario library that reflects your environment. Examples (customize to your dependencies):

• Loss of facility or inaccessible site
• Loss of key personnel/skills
• Technology outage (core platform, identity, network, endpoint management)
• Data integrity loss or ransomware impacting availability
• Third party outage (cloud/SaaS provider, call center, logistics partner)
• Utility failure or telecom disruption
• Critical supplier failure for a key input

Document scenario sources (incident history, IT problem records, supplier issues, exercise findings). You do not need a perfect catalog; you need a credible, reviewable basis.

4) Analyze and evaluate risks against criteria

For each scenario, record:

• The activity impacted and the supporting resource that fails.
• The cause (where known) and the failure mode (what stops working).
• The existing controls (preventive and detective) that reduce likelihood.
• The residual impact if the scenario occurs (use BIA-informed impact framing).
• The risk rating per your defined criteria.
• The evaluation decision: accept, monitor, treat.

Practical decision check: If the risk threatens achievement of your recovery objectives for that activity (as established through your continuity requirements), it should almost always be tagged for treatment through strategy, design changes, or readiness improvements (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).

5) Determine risk treatment actions tied to continuity strategies

For each “treat” decision, specify:

• Treatment type: avoid, reduce, transfer/share, accept with contingency.
• The business continuity strategy implication: alternate site, manual workaround, additional capacity, diversification of suppliers, improved backup/restore capability, pre-positioned equipment, call tree enhancements, etc.
• Owner, target dates, and dependencies.
• How you will validate effectiveness (exercise objective, technical test, supplier evidence).

This is where many programs fail: they write “mitigate” and stop. ISO 22301 expects risk assessment to drive continuity strategies and supporting plans (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).

6) Integrate with third-party risk management (where relevant)

Where a supporting resource is a third party, add BC-specific assessment fields:

• Service criticality to prioritized activities
• Continuity commitments (RTO/RPO alignment where applicable)
• Concentration risk (single provider for multiple activities)
• Subcontractor dependencies (fourth parties) where known
• Required evidence: continuity plan summary, test/exercise attestations, incident notification expectations

Daydream fit (earned mention): If your third-party inventory and criticality mapping are scattered across procurement, IT, and risk tools, Daydream can act as the system of record that ties a third party to the prioritized activities it supports, then tracks continuity-related treatment actions and evidence in one place.

7) Review, approve, and keep it current

• Route results through BCMS governance for approval.
• Ensure treated risks create tracked actions (with status).
• Refresh on a defined cadence and after material changes (new systems, reorganizations, supplier changes, major incidents, BIA updates).

Required evidence and artifacts to retain

Auditors will look for traceability and decision-making evidence. Keep these artifacts in a controlled repository:

1. Risk assessment methodology

• Scope statement (prioritized activities and supporting resources)
• Risk criteria definitions and thresholds
• Roles and responsibilities

2. BIA outputs and dependency mapping

• Prioritized activities list
• Supporting resource inventory for each activity (including third parties)

3. Risk assessment results

• Risk register (or equivalent) with scenarios, ratings, and rationale
• Evidence of review/approval (meeting minutes, sign-offs, workflow approvals)

4. Treatment linkage

• Treatment plan/action register
• Mapped continuity strategies and plan updates
• Evidence of completed actions (change records, contracts, runbooks, system configs)

5. Validation

• Exercise schedule and objectives that map to top risks
• After-action reports and remediation tracking

Common exam/audit questions and hangups

Expect these lines of questioning in ISO 22301 certification audits:

• “Show me how your risk assessment scope ties to prioritized activities from the BIA.”
• “What are your risk criteria, and who approved them?”
• “How do you identify risks to supporting resources, especially shared services and third parties?”
• “Pick one high-rated risk. Show the treatment decision and the resulting continuity strategy or plan change.”
• “How do you ensure the risk assessment stays current after organizational or technology change?”

Hangup: Teams often present an ERM risk register with no mapping to prioritized activities. That usually fails the intent of Clause 8.2.3 (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Scenarios aren’t tied to dependencies.
   Fix: Require every risk entry to name the supporting resource that fails (application, facility, role, third party) and the activity impacted.

2. Mistake: No documented criteria, or criteria change by workshop.
   Fix: Publish the scoring rubric and acceptance thresholds in advance; train facilitators to enforce it.

3. Mistake: “Treat” decisions don’t produce strategy changes or funded actions.
   Fix: Make treatment decisions create trackable work items with owners and governance review.

4. Mistake: Third-party continuity risk is handled only by procurement questionnaires.
   Fix: Map each critical third party to prioritized activities and test continuity assumptions through exercises, SLAs, and incident notification workflows.

5. Mistake: The risk assessment is a one-time certification artifact.
   Fix: Tie refresh triggers to change management and BIA updates. Require post-incident updates.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, the risk is less about “fines for Clause 8.2.3” and more about failed audits, lost customer confidence, and operational exposure: without a defensible link from prioritized activities to disruption risks and treatment, you will miss single points of failure in shared services and third-party dependencies (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).

Practical execution plan (30/60/90)

Use this as a fast operational rollout. Timing labels indicate sequencing, not guaranteed duration.

First 30 days (Immediate)

• Confirm BIA outputs: prioritized activities and owners.
• Build dependency templates for supporting resources, including third parties.
• Publish risk criteria and scoring rubric; assign governance approver.
• Run a pilot risk assessment on a small set of prioritized activities to validate the method.

By 60 days (Near-term)

• Complete risk assessments for remaining prioritized activities.
• Produce a ranked list of top residual risks and decisions (accept/monitor/treat).
• Stand up a treatment action register and governance routine to track progress.
• Update continuity strategies and plans for treated risks; align exercises to top scenarios.

By 90 days (Operationalize and sustain)

• Integrate refresh triggers into change management and supplier onboarding/offboarding.
• Add evidence automation where possible (workflow approvals, centralized repository).
• Run at least one tabletop or technical validation focused on a top treated risk, and track remediation to closure.
• Prepare an audit-ready traceability pack: BIA → dependencies → risk assessment → treatment → plan change → validation.

Frequently Asked Questions

Does ISO 22301 require a separate risk assessment from ERM?

ISO 22301 requires a risk assessment focused on prioritized activities and supporting resources (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements). You can reuse ERM methods, but you still need BC-specific scope, criteria, and traceability to continuity strategies.

What counts as a “supporting resource” in practice?

Supporting resources include people/roles, facilities, technology platforms, data, utilities, and third parties that enable the prioritized activity. Document them at a level where you can point to an owner and a failure mode.

How detailed do disruption scenarios need to be?

Detailed enough that someone can understand what fails and what the operational consequence is for the activity. If two scenarios lead to different treatments (for example, alternate site vs. manual workaround), they should be separate entries.

How do we prove we “analyzed” risks, not just listed them?

Keep your scoring criteria, the rationale for likelihood/impact, and evidence of review/approval. Auditors look for consistent application of criteria and documented treatment decisions tied to continuity strategies (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).

How should we handle third-party outages in the risk assessment?

Map the third party to the prioritized activities it supports, rate the disruption risk, then document treatment such as contractual continuity commitments, diversification, or validated workarounds. Retain the evidence you relied on (attestations, reports, exercise outputs, contract clauses).

What’s the minimum artifact set for an audit?

A documented methodology, a risk register mapped to prioritized activities and supporting resources, and evidence that high risks drove treatment actions and continuity strategy/plan updates (ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements).

Footnotes

1. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements