Business Impact Analysis: Turning Impact Curves into Recovery Objectives
Domain focus
The Business Impact Analysis domain tests whether you can convert an organisation chart into a time-based map of consequences. Items probe how impact differs from likelihood, how recovery objectives are derived rather than negotiated, and how dependency data feeds later strategy work. Expect scenario stems that give an activity, an impact curve over time, and four candidate RTOs.
Activities, not departments
A BIA identifies prioritized activities - the processes whose loss harms the organisation, its customers or its obligations. Department-level questionnaires are only a data-collection route; the analysis must cut across functions so shared dependencies (one identity service, one warehouse, one payroll provider) become visible. Record impact across categories - financial, regulatory/legal, operational, reputational and safety of people - at fixed intervals (for example 2, 8, 24, 72 hours and one week), because impact is a function of duration, not a single number.
Parameters you must define precisely
- MTPD/MAO - the point at which impact becomes unacceptable. A business judgement, not a technical one.
- RTO - target time to resume the activity; it must sit inside the MTPD, leaving room for detection and declaration.
- RPO - tolerable data loss, expressed in time.
- Minimum resources - people, facilities, technology, data, suppliers and vital records needed at the RTO, not at full scale.
- Dependencies - internal and external, each with a recovery expectation at least as short as the activity's.
Worked example
Card transaction settlement: a regulator treats failed settlement beyond 48 hours as a reportable breach, so MTPD = 48 h. The business sets RTO = 12 h, allowing 36 h of degraded manual reconciliation plus margin for declaration. RPO = 15 minutes, because lost or duplicate postings must be reconcilable. The BIA then records a dependency on the payment gateway, whose own stated recovery is 24 h. That dependency exceeds the activity RTO, so the BIA cannot simply be signed off - it becomes a strategy gap to resolve.
Traps
Confusing MTPD with RTO; deriving RTO from IT capability rather than business tolerance; using the risk register as a BIA; interviewing only managers; and producing a prioritised list with no resources or dependencies attached, which leaves later strategy selection unevidenced.
Plan Development and Implementation: Structure, Activation and Controlled Distribution
Domain focus
Plan development items ask whether you can turn strategy into something a tired duty manager can execute at 03:00. Expect questions on plan structure, activation and escalation criteria, roles, communications and controlled distribution.
Three-layer architecture
- Strategic - crisis/incident management team: direction, stakeholder and media interface, declaration, resource release.
- Tactical - business continuity coordinator: prioritisation, allocation, liaison with responders and suppliers.
- Operational - activity recovery teams executing procedures.
Each plan, per ISO 22301 clause 8.4, should contain: purpose and scope; roles, responsibilities and authority; the activation and escalation process with objective triggers; communication with staff, customers, regulators and media; recovery priorities and procedures for the prioritized activities; dependencies and resource requirements; and reporting to the tactical level. Appendices carry contacts, maps, supplier lists, site plans and checklists.
Writing rules
Write in the imperative, one action per line, in plain language, addressed to a role rather than a named person. Use checklists and time markers (T+0, T+4h). Keep contact data in a controlled annex refreshed independently of the narrative. Classify copies, version them and log who holds each - uncontrolled copies are a classic audit finding. Approve plans formally and record the approval.
Implementation
Plan production is the easy half. Implementation means role-mapped training; competency evidence for recovery teams; awareness for all staff; inclusion of suppliers and contractors in call trees and expectations; embedding triggers into business-as-usual processes; and the change-control route that keeps the plan alive.
Worked example
A distribution call-centre plan declares when any two of the following occur: the primary site is unusable for more than 4 hours; more than 30% of agents cannot log in; or the telephony provider reports an outage with no restoration estimate. Reasoning: a single condition produces false declarations, while requiring all three delays recovery beyond the RTO. The plan names the duty manager as sole declarer, with the operations director as alternate.
Traps
Writing a departmental plan that never covers the prioritized activity end to end; missing activation criteria or unclear authority; naming individuals; confusing the plan with the policy; omitting third parties; and distributing uncontrolled copies that mislead responders later.