Business impact analysis

ISO 22301 Clause 8.2.2 requires you to complete a business impact analysis (BIA) that identifies time-sensitive activities, measures disruption impacts over time, and sets MTPD, RTO, and RPO so recovery priorities are defensible and testable. Operationalize it by scoping critical services, mapping dependencies, assigning recovery objectives, and retaining evidence that links those objectives to impact data and approved decisions. ¹

Key takeaways:

• A BIA is a decision record: why specific activities recover first, and within what time/data loss bounds (MTPD, RTO, RPO).
• The hardest part is dependency mapping (people, facilities, tech, third parties, data) and making RTO/RPO achievable with current capabilities.
• Auditors look for traceability from impact analysis → recovery objectives → resourcing and continuity strategies. ¹

A “business impact analysis requirement” is not satisfied by a generic criticality list or a one-time workshop. ISO 22301:2019 Clause 8.2.2 expects a structured BIA that evaluates how disruption impacts change over time, then uses that analysis to identify time-sensitive activities and define recovery requirements: Maximum Tolerable Period of Disruption (MTPD), Recovery Time Objective (RTO), and Recovery Point Objective (RPO). ¹

For a Compliance Officer, CCO, or GRC lead, the goal is fast operational clarity: which activities must be recovered first, what “first” means in measurable targets, and what evidence proves those targets are based on impact and approved by accountable leaders. Done well, your BIA becomes the backbone for incident prioritization, disaster recovery planning, third-party continuity requirements, tabletop exercises, and management reporting. Done poorly, it becomes an isolated spreadsheet that no one can defend during audit or use during a real outage.

This page gives requirement-level implementation guidance you can execute quickly: scope, method, roles, step-by-step workflow, artifacts to retain, and common audit pitfalls.

Regulatory text

Requirement (excerpt): “The organization shall conduct a BIA to evaluate potential impacts from disruptions and identify time-sensitive activities with MTPD, RTO, and RPO.” ¹

Operator interpretation (what you must do):

1. Conduct a BIA (not just document one) using a defined approach you can repeat.
2. Evaluate impacts over time (impacts are not static; the harm typically escalates as downtime lengthens).
3. Identify time-sensitive activities (the activities whose interruption becomes unacceptable within a defined window).
4. Assign recovery requirements to those activities:
   • MTPD: the maximum time the activity can be disrupted before the impact becomes intolerable.
   • RTO: the target time to restore the activity after disruption.
   • RPO: the maximum tolerable data loss measured in time (how far back you can roll data and still function).
     ¹

Plain-English requirement: what “good” looks like

A compliant BIA produces a ranked list of time-sensitive activities with named business owners, quantified impact narratives (financial, operational, legal/regulatory, customer, safety where relevant), dependency maps, and approved MTPD/RTO/RPO targets that your technology and operations teams can actually meet. The BIA must also reveal where you cannot meet targets so leadership can accept risk or fund changes. ¹

Who it applies to

Entity scope: Any organization implementing ISO 22301 requirements, across business units and enabling functions. ¹

Operational context where BIAs are examined closely:

• Organizations with customer-facing digital services where downtime and data loss translate quickly into contractual, reputational, and operational harm.
• Regulated operations where service interruption triggers reporting, customer harm, or control failures (even if the regulator is not explicitly named in ISO 22301).
• Environments with concentrated dependencies (single data center, key SaaS platforms, single points of failure in staffing, or critical third parties).
  ¹

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

1) Define scope and “activity” taxonomy

• Decide whether you are analyzing products/services, business processes, or capabilities. Pick one primary lens to avoid double counting.
• Set the scope boundary: in-scope legal entities, locations, platforms, and customer segments.
• Establish an ownership model: each activity needs a business owner who can approve impact assumptions and recovery objectives.
  ¹

Practical tip: If you start with org charts, you’ll miss cross-functional services. Start with your external “services delivered” list, then map internal activities that enable them.

2) Build an inventory of activities and dependencies

For each candidate activity, capture dependencies in these categories:

• People: key roles, minimum staffing, specialized skills.
• Facilities: sites, access requirements, equipment constraints.
• Technology: applications, infrastructure, identity, endpoints, networks.
• Data: authoritative sources, data flows, retention points, backup/replication paths.
• Third parties: SaaS, payment processors, call centers, logistics providers, key suppliers.
• Upstream/downstream internal dependencies: handoffs, batch jobs, shared services.
  ¹

Deliverable: dependency map per activity (a table is fine; diagrams help but are not required if the table is clear).

3) Define impact categories and a consistent scoring method

ISO 22301 requires evaluating “potential impacts from disruptions.” To make this repeatable, define impact categories and how you assess them:

• Customer impact (service unavailability, missed SLAs)
• Operational impact (backlog, rework, manual workarounds)
• Legal/regulatory impact (missed filings, control breaches, contractual noncompliance)
• Financial impact (lost revenue, penalties where contractually defined, incremental costs)
• Reputational impact (customer trust erosion)
• Safety impact (if applicable)
  ¹

Mechanics: Use time bands (for example, “short disruption,” “extended disruption,” “multi-day disruption”) and record how impacts worsen across those bands. Avoid invented precision; capture defendable ranges and clear narrative triggers (e.g., “after invoices cannot be issued,” “after claims queue exceeds capacity”).

4) Determine MTPD per time-sensitive activity

MTPD is the “hard stop” point where continuation of disruption becomes intolerable. To set it:

• Review impact escalation by time band.
• Identify the earliest time band where impacts cross an “intolerable” threshold for the organization (based on your defined criteria).
• Document rationale and approver.
  ¹

Common hangup: Teams confuse MTPD with RTO. MTPD is the outer bound; RTO is your target restoration time.

5) Set RTO and RPO (and verify achievability)

For each time-sensitive activity:

• RTO: pick a restoration target that is within MTPD and aligned to operational reality (staffing, runbooks, failover design).
• RPO: define tolerated data loss in time terms, then map it to technical mechanisms (replication frequency, backup schedules, transactional integrity).
  ¹

Reality check you must run: Compare proposed RTO/RPO to current DR/BC capabilities. Where capability cannot meet objective, record a gap and route it for a decision: improve capability, change the objective, or accept risk. Auditors routinely look for this traceability. ¹

6) Identify minimum resource requirements

For each activity at its recovery state, define minimum resources:

• Minimum staffing and skills by role
• Required systems and access dependencies
• Workspace or remote-work prerequisites
• Critical data inputs/outputs
• Third-party service prerequisites and escalation paths
  ¹

7) Produce prioritized recovery sequence and approvals

• Rank activities by time-sensitivity and dependency constraints.
• Confirm there are no circular dependencies that make the sequence impossible.
• Obtain approvals from accountable leaders (business + IT/BC/DR stakeholders) and record sign-off.
  ¹

8) Operationalize the BIA outputs

A BIA that sits on a shared drive will fail in practice. Convert outputs into:

• Incident severity and prioritization rules aligned to RTO/RPO.
• DR tiers for systems mapped to business activities.
• Third-party continuity requirements where their services support time-sensitive activities.
• Test plans that validate the stated RTO/RPO and minimum staffing assumptions.
  ¹

Where Daydream fits naturally: Daydream can act as the system of record for activity inventories, dependency mapping, approvals, and evidence packaging, so BIA decisions and artifacts stay audit-ready and version-controlled.

Required evidence and artifacts to retain

Auditors and certifying bodies typically want to see that the BIA exists, is approved, and drives actions. Retain:

• BIA methodology document (scope, definitions, impact categories, scoring, time bands)
• Activity inventory with owners
• Dependency register (including third-party dependencies)
• Impact assessment worksheets/interview notes (or structured survey outputs)
• MTPD/RTO/RPO register with rationale
• Gap log (where objectives exceed capability) with documented decisions
• Approval records (sign-off emails, meeting minutes, ticket approvals)
• Change log and review cadence evidence (show it is maintained)
  ¹

Common exam/audit questions and hangups

Expect questions like:

• “Show me how you determined which activities are time-sensitive.” (They want criteria and consistency.)
• “Where is MTPD documented, and who approved it?” (They want accountable ownership.)
• “How do your RTO/RPO values map to actual system recovery capabilities?” (They want feasibility, not wish lists.)
• “Which third parties support your most time-sensitive activities, and what continuity expectations exist?” (They want dependency awareness.)
• “How does the BIA drive testing and improvement?” (They want operational linkage.)
  ¹

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Setting RTO/RPO based on aspiration.
   Avoid: Require a technical feasibility check and document gaps and decisions. ¹

2. Mistake: Ignoring internal shared services (IAM, network, monitoring, service desk).
   Avoid: Treat enabling services as dependencies with their own recovery needs. ¹

3. Mistake: Treating “process = department.”
   Avoid: Define activities around outcomes delivered; map cross-functional steps and handoffs. ¹

4. Mistake: No third-party dependency mapping.
   Avoid: Capture third parties per activity and align contracts/SLA expectations to RTO/RPO where feasible. ¹

5. Mistake: BIA completed once and never revisited.
   Avoid: Tie updates to material change triggers (new systems, product launches, outsourcing, reorganizations). ¹

Enforcement context and risk implications

ISO 22301 is a standard, so “enforcement” typically shows up as certification findings, customer audits, and contractual disputes rather than regulator penalty schedules. The practical risk is straightforward: without a defensible BIA, you cannot justify recovery priorities under pressure, and you will struggle to prove that continuity planning aligns to business harm and dependency reality. ¹

A practical 30/60/90-day execution plan

Days 0–30: Stand up the BIA program foundation

• Confirm scope, activity taxonomy, and owners.
• Publish BIA methodology (impact categories, time bands, definitions for MTPD/RTO/RPO).
• Build initial inventory of services/activities and the dependency template.
• Schedule interviews/workshops with the highest-impact business lines first.
  ¹

Days 31–60: Execute BIA data collection and draft targets

• Run interviews/surveys; collect impact narratives and time-based escalation.
• Document dependencies, including third-party dependencies.
• Draft MTPD/RTO/RPO and minimum resource requirements per activity.
• Perform feasibility checks with IT/DR and operational teams; open gaps where needed.
  ¹

Days 61–90: Approve, publish, and wire into operations

• Hold an approval review with business and technology leadership.
• Finalize prioritized recovery sequence and publish BIA outputs to stakeholders.
• Update DR tiers, continuity plans, incident prioritization, and test scenarios to reflect BIA targets.
• Package evidence for audit: methodology, outputs, approvals, and gap decisions.
  ¹

Frequently Asked Questions

Do we need MTPD, RTO, and RPO for every process?

Clause 8.2.2 focuses on identifying time-sensitive activities and setting MTPD, RTO, and RPO for them. Start by determining which activities are time-sensitive, then apply recovery objectives there first. ¹

Can IT set RTO and RPO without business input?

You can’t defend recovery objectives without business impact rationale and an accountable business owner. IT should validate feasibility, but the business must own the impact-based requirement and approvals. ¹

How do we handle third-party services in the BIA?

Treat third parties as dependencies for the activities they support and document the operational consequence if the third party is unavailable. Then align continuity expectations and escalation paths to the activity’s RTO/RPO where feasible. ¹

What evidence is strongest during audit?

Auditors look for traceability: methodology → impact-over-time analysis → identified time-sensitive activities → MTPD/RTO/RPO → approvals and actions. A clean gap/decision log is often as important as the targets themselves. ¹

How often should we update the BIA?

ISO 22301 requires you to conduct the BIA and keep it effective in operation; practical maintenance is usually driven by change. Update it when you introduce new critical services, replace core systems, change outsourcing arrangements, or restructure ownership. ¹

We can’t meet the RTO/RPO the business wants. What do we do?

Document the gap, validate the constraint (architecture, staffing, third-party limits), and route a formal decision: improve capability, revise the objective, or accept the risk with approval. Keep that decision with the BIA records. ¹

Footnotes

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