Appearance
Business Impact Analysis
Where to find it: Operational Resilience, then BCM & Resilience (/bcm), then BIAs.
A Business Impact Analysis (BIA-YYYY-NNNN) establishes what happens if a business service stops, and how quickly it must come back.
The four recovery objectives
| Objective | Question | Unit |
|---|---|---|
| RTO — Recovery Time Objective | How long may the service be down? | Minutes |
| RPO — Recovery Point Objective | How much data may be lost? | Minutes |
| MTD / MTPD — Maximum Tolerable Disruption | Beyond what duration is harm intolerable? | Minutes, at or beyond RTO |
| MBCO — Minimum Business Continuity Objective | What minimum capability must resume? | Description |
Recovery objectives are explicit human executive determinations
All four are set by people with the authority to set them, backed by business impact assessment.
None is synthesised by a heuristic from criticality tier, transaction volume or system tier. A platform that derived an RTO would be making a business decision about acceptable customer harm, which is not a decision a platform can make.
The MTD and RTO relationship
MTD is the point at which disruption becomes intolerable. RTO is the target for restoration, and must sit at or inside it. An RTO longer than the MTD is a stated intention to accept intolerable harm — worth catching at the point of drafting.
What a BIA carries
| Field | Purpose |
|---|---|
| Business reference | BIA-YYYY-NNNN |
| Business service | The resilience subject |
| RTO, RPO, MTD | The quantitative objectives |
| MBCO description | The minimum capability on resumption |
| Impact categories | Financial, customer, regulatory, reputational, operational |
| Time-based impacts | How impact escalates with outage duration |
| Dependencies | Assets, third parties, organisational units, via the Scope Registry |
| Owner | Who is accountable |
| Status | Its governance state |
| Historical snapshots | Immutable frozen states at approval |
Time-based impact
Impact is not constant. A payments service down for ten minutes is an inconvenience; down for six hours it is a regulatory reportable event.
Time-based impact records how each impact category escalates across durations, which is what makes an RTO defensible rather than arbitrary.
| Duration | Financial | Customer | Regulatory |
|---|---|---|---|
| 0 to 1 hour | Low | Low | None |
| 1 to 4 hours | Medium | Medium | Notification threshold approached |
| 4 to 12 hours | High | High | Reportable |
| Over 12 hours | Severe | Severe | Reportable, supervisory engagement expected |
An RTO of four hours reads very differently once this table exists beneath it.
Dependencies
BIA dependencies are recorded through the Scope Registry — applications, infrastructure, third parties, outsourcing engagements and organisational units linked as what they are, with no duplicate registry.
This is what makes concentration visible. When four important business services all depend on the same third-party engagement, the dependency links say so.
Approval
BIAs follow a governed approval chain:
Draft and update BIA, then risk and continuity review, optionally escalating to business or committee approval, then approved or rejected.
Segregation of duties: the author or submitter cannot approve their own BIA. Approval requires bcm.bia_approve.
On final sign-off, an immutable historical snapshot is appended, preserving the exact approved state — objectives, impacts, dependencies and reviewer identity.
Currency
A BIA has a review validity window. An out-of-date BIA is reported as such rather than being treated as current.
This matters for the resilience assessment, where BIA currency and approval is one of the six dimensions.
AI assistance
AI can draft BIA impact suggestions and scenario narratives. All output is advisory, carries provenance, and requires explicit human confirmation. It never sets a recovery objective.
Requires bcm.ai_assist.
Permissions
| Action | Permission |
|---|---|
| View BIAs and resilience status | bcm.read |
| Create, edit and maintain BIAs and recovery objectives | bcm.bia_manage |
| Approve or review BIAs | bcm.bia_approve |
| Generate advisory AI drafts | bcm.ai_assist |
Requires the bcm_resilience entitlement.
Example
BIA BIA-2026-0003 — Retail Payments Service.
| Objective | Value | Basis |
|---|---|---|
| RTO | 240 minutes | Regulatory reportability threshold at 4 hours; customer impact escalates sharply beyond |
| RPO | 5 minutes | Synchronous replication capability; any loss beyond one settlement window requires manual reconstruction |
| MTD | 480 minutes | Beyond 8 hours, settlement obligations to the scheme are breached |
| MBCO | "Card authorisation and balance enquiry at 60% of peak throughput. Batch settlement and statement generation may be deferred up to 24 hours." |
Dependencies: 11 applications, 23 infrastructure assets, 2 third-party engagements (ENG-2026-0041 core hosting, ENG-2026-0055 card scheme gateway), and 3 organisational units.
Approval: drafted by the Head of Payments Operations, reviewed by the Head of Operational Resilience, approved by the Chief Operating Officer. Snapshot frozen.
What the MBCO does: it converts "recover the service" into something testable. An exercise can now verify 60% throughput on authorisation and balance enquiry, rather than debating whether a partially restored service counts as recovered.
Troubleshooting
"The BIA shows as out of date." Its review validity window has passed. Review and re-approve it.
"I cannot approve a BIA I drafted." Segregation of duties. An independent approver is required.
"RTO was not derived from criticality." Correct. Objectives are set, not derived.
"An approved BIA changed." The live record can be revised, but the approved snapshot is immutable. Compare the two to see what moved.