Business impact analysis and risk assessment

ISO 22301:2019 Clause 8.2 requires you to establish and maintain a formal, documented process for business impact analysis (BIA) and risk assessment that you apply consistently across prioritized activities. To operationalize it, define scope, methods, roles, and cadence; run BIA and risk assessments with evidence; then use results to set continuity requirements and strategies. ¹

Key takeaways:

• You need a documented, repeatable BIA and risk assessment process, not a one-off exercise. ¹
• BIA output must translate into prioritized activities and measurable continuity requirements that drive strategy selection. ¹
• Auditors look for traceability: scope → method → workshops/data → approvals → decisions → ongoing maintenance. ¹

“Business impact analysis and risk assessment” is where your business continuity program stops being a set of generic recovery statements and becomes a decision system tied to your actual operations. Clause 8.2 of ISO 22301:2019 is short, but it has teeth: you must be able to show a formal, documented process that you maintain over time, with outputs that clearly influence continuity priorities and strategies. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat Clause 8.2 as an operational requirement with three deliverables: (1) a written methodology (how you perform BIA and risk assessment), (2) executed analyses with approvals and evidence, and (3) governance that keeps the analyses current as your business changes. If you can’t demonstrate repeatability, consistent application, and linkage to continuity decisions, you will struggle in an ISO 22301 certification audit or an internal assurance review. ¹

The guidance below is designed to help you implement Clause 8.2 quickly, with a clean audit trail and minimal rework.

Regulatory text

Requirement excerpt: “The organization shall establish and maintain a formal and documented process for BIA and risk assessment.” ¹

What an operator must do:

• Establish: define scope, roles, methods, and criteria for both BIA and risk assessment, and get the process approved as part of your BCMS governance. ¹
• Maintain: keep it current as the organization, services, third parties, technology, and operating environment change; show version control and evidence of periodic refresh. ¹
• Be formal and documented: auditors should be able to follow your process without tribal knowledge. If it’s “how we do it in meetings,” it’s not compliant. ¹

Plain-English interpretation (what Clause 8.2 really expects)

You must run BIA and risk assessment in a way that is:

1. Systematic (same core steps each time),
2. Evidence-based (inputs and assumptions are captured),
3. Comparable (activities can be prioritized using consistent criteria),
4. Decision-driving (outputs inform continuity requirements and strategies, not just a report). ¹

A practical interpretation: if you can’t explain why one activity got a tighter recovery requirement than another, using your documented criteria, you are exposed in audit. ¹

Who it applies to

Entity scope: Any organization implementing an ISO 22301-aligned business continuity management system (BCMS). ¹

Operational context (where it bites):

• Customer-facing services with downtime sensitivity (revenue, safety, contractual performance).
• Regulated or critical operations where outages create legal, safety, or systemic impacts.
• Dependency-heavy operating models: cloud services, outsourced operations, and other third parties supporting prioritized activities. The BIA and risk assessment must reflect these dependencies in a usable way, because continuity strategies often hinge on them. ¹

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

Step 1: Define scope and “unit of analysis”

Pick what you assess consistently, and document it:

• Activities/processes (recommended for most organizations),
• Products/services, or
• Business units (works if you can still isolate dependencies and impacts). ¹

Write down inclusion rules (what is in/out) and how you handle shared services (IT, HR, Facilities) that support multiple activities.

Step 2: Document the BIA methodology

Your BIA procedure should specify:

• Impact categories you assess (financial, legal/regulatory, customer/contractual, operational, safety, reputational). Use categories that match how executives make decisions. ¹
• Impact levels and scoring: define the scale and what each level means in plain language.
• Time-based degradation: how impacts increase as outage duration grows (the “impact curve” concept).
• Data sources: SMEs, system records, incident history, customer commitments, and third-party SLAs (where relevant).
• Approval: who signs off on BIA results and who arbitrates disputes.

Deliverable: a controlled document (policy/procedure/work instruction) that a new analyst could follow.

Step 3: Run the BIA workshops and capture evidence

Execute BIAs for in-scope activities and record:

• Activity owner and participants
• Description and boundaries (what starts/stops the activity)
• Inputs/outputs and upstream/downstream dependencies
• Systems, data, locations, roles, and third parties required to operate
• Impact analysis across your time horizons and categories
• Stated assumptions and known gaps (for example, missing third-party transparency) ¹

Practical tip: treat “dependency mapping” as a first-class output. Many BIAs fail because they list systems and third parties, but don’t tie them to the activity’s tolerances and recovery needs.

Step 4: Translate BIA results into continuity requirements

Your BIA should produce decisions that downstream continuity planning can use, such as:

• Which activities are prioritized
• The activity’s required recovery characteristics (for example, the maximum tolerable disruption and minimum resources needed)
• Minimum staffing and skills needed to resume
• Key third parties and facilities required ¹

Even if you express requirements in your own terminology, document how the output is used to select continuity strategies and plans.

Step 5: Document the risk assessment methodology (aligned to BC)

Your risk assessment process should specify:

• Threats and vulnerabilities considered (internal, external, technology, people, facilities, third party)
• Likelihood and impact criteria (and whether impact comes from the BIA or is independently scored)
• Risk evaluation rules (what becomes “unacceptable” and requires treatment)
• Risk treatment options and how they map to continuity strategies (avoid, reduce, transfer, accept)
• Ownership and approval for risk acceptance ¹

Step 6: Perform risk assessments for prioritized activities

Focus where the BIA says the organization is most exposed:

• Validate top scenarios against real dependencies (single points of failure, concentration risk in third parties, facility constraints)
• Identify existing controls and continuity capabilities
• Document residual risk and required treatments
• Create a trackable action plan (owner, due date, status) ¹

Step 7: Establish “maintenance” governance

Maintenance is where many programs fail. Define triggers for update:

• Material process change (new product, new workflow)
• Major technology change (system replacement, cloud migration)
• Third-party change (new critical third party, SLA changes, exit event)
• Significant incident or near miss
• Organizational restructure ¹

Maintain version history for the methodology and a register of completed BIAs/risk assessments with last review dates.

Step 8: Build traceability for audit

Auditors test whether your BIA and risk assessment outputs actually drive continuity choices. Maintain a clear chain:

• Prioritized activity → requirements → strategy → plan/testing scope ¹

If you use Daydream to coordinate third-party due diligence and continuity evidence collection, map critical third parties identified in the BIA to required artifacts (SLAs, resilience commitments, incident communications paths) so you can evidence that dependencies are managed consistently.

Required evidence and artifacts to retain (audit-ready list)

Keep these in a controlled repository with versioning:

• BIA procedure/methodology and templates ¹
• Risk assessment procedure/methodology and templates ¹
• Inventory of in-scope activities and owners
• Completed BIA reports/worksheets with participant lists, dates, and approvals
• Dependency maps (systems, facilities, data, third parties) tied to activities
• Completed risk assessments with scoring, rationale, and approvals
• Risk treatment plan(s) and evidence of execution tracking
• Governance artifacts: meeting minutes, management review inputs, change triggers, exception/acceptance records ¹

Common exam/audit questions and hangups

Auditors commonly press on:

• “Show me your documented process.” If the methodology is scattered across slides and emails, expect findings. ¹
• “How do you know it’s complete?” Be ready to explain scoping logic and how you identified activities. ¹
• “How do results drive decisions?” Provide examples of strategy choices that changed because of BIA/risk assessment outputs. ¹
• “How do you keep this current?” Bring evidence of updates after changes or incidents, plus governance triggers. ¹

Frequent implementation mistakes (and how to avoid them)

1. Treating BIA as a questionnaire exercise. Fix: require facilitated review with challenge of assumptions and dependency validation. ¹
2. No decision criteria. Fix: define scoring scales and risk acceptance thresholds in the methodology, then enforce them. ¹
3. Outputs don’t connect to continuity strategies. Fix: add a mandatory “strategy implications” section in every BIA/risk assessment. ¹
4. Third-party dependencies listed but unmanaged. Fix: identify “critical third parties” from the BIA and route them into third-party due diligence and continuity requirements tracking (where Daydream can help centralize requests and evidence). ¹
5. Stale analyses. Fix: define update triggers and require owners to attest to continued accuracy. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, the risk is assurance failure: if you pursue ISO 22301 certification or rely on BCMS outputs for board reporting, a weak BIA/risk assessment process leads to unprioritized recovery spend, missed third-party single points of failure, and audit nonconformities tied to lack of documentation and maintenance. ¹

Practical 30/60/90-day execution plan

Exact timelines depend on scope and resourcing; treat these as phased outcomes, not calendar promises.

First 30 days (foundation)

• Set scope and inventory activities; assign owners. ¹
• Publish BIA and risk assessment methodologies (templates, scoring, approval path). ¹
• Pilot one or two high-impact activities end-to-end and refine templates based on friction. ¹

By 60 days (execution at scale)

• Run BIAs for prioritized activities and document dependencies, including critical third parties. ¹
• Produce initial prioritization and continuity requirements for each activity. ¹
• Start risk assessments for the highest-priority activities; open treatment actions with named owners. ¹

By 90 days (governance and audit trail)

• Complete risk assessments for remaining prioritized activities and formalize risk acceptance where needed. ¹
• Establish maintenance triggers, review cadence, and management reporting. ¹
• Build audit-ready traceability from prioritized activities to continuity strategies, plans, and testing scope. ¹

Frequently Asked Questions

Do we need separate documents for BIA and risk assessment, or can it be one combined process?

ISO 22301 requires a formal, documented process for both BIA and risk assessment; it does not require separate documents. A combined procedure is fine if it clearly distinguishes methods, outputs, and approvals for each. ¹

What is the minimum “evidence” an auditor will accept for BIAs?

Expect to show the methodology, completed BIAs with dates and participants, and approvals by accountable owners. You also need evidence that outputs drove continuity requirements and strategy decisions. ¹

How should we handle third parties in the BIA?

Capture third parties as dependencies for each prioritized activity and identify which ones are critical to resumption. Then connect those critical third parties to due diligence, contractual continuity requirements, and exit planning where applicable. ¹

Can we rely on IT disaster recovery documents instead of running a BIA?

DR documents describe recovery approaches for technology; they do not substitute for a business-led BIA that defines prioritized activities and required continuity outcomes. Use DR as an input to feasibility and strategy selection after you set requirements. ¹

How do we prove we “maintain” the process?

Keep version history for your methodology, record review events, and show updates triggered by changes or incidents. A register of BIAs and risk assessments with last review status supports this quickly in audit. ¹

What if business owners disagree with impact ratings?

Document escalation and arbitration in your methodology, and require final sign-off by accountable leadership. Keep the rationale and assumptions so the decision is auditable later. ¹

Footnotes

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