Business Impact Analysis & Resilience Board Summary

Operational resilience is about the SERVICE the business delivers to customers — not a list of IT systems. Start from the critical business services, work out how long the company could survive each being down, then set the recovery objectives and the investment needed to stay within the board's impact tolerance. This summary is the one-page version the board reads; the full BIA workings sit behind it.

• Fill it service-first: name the customer-facing outcome, then the systems, people and vendors it depends on.
• Every recovery target is a business decision the board owns, not a technical number IT sets alone.
• Keep the figures honest — an untested recovery capability is a hope, not a control, so mark what has actually been tested.

List the customer-facing outcomes the business cannot do without, most critical first. The RTO (how fast you must restore) and RPO (tolerable data loss) are set per service, against the impact tolerance in section 6.

Impact grows non-linearly: an hour may be absorbed, a day triggers SLA penalties and customer defection, a week risks contracts and solvency. Map each critical service across the time horizons so the board can see where the cliff is.

A service is only as resilient as its weakest dependency — including the vendors your vendors rely on. Map what each critical service needs, then flag where a single loss would halt it (one cloud region, one vendor, one key person).

• Concentration risk assessed — one cloud provider / region, one critical vendor, one key individual
• Upstream and fourth-party dependencies mapped (your vendors' own dependencies)
• Recovery expectations for critical vendors set in contracts / SLAs, not assumed
• Key-person knowledge documented and cross-trained — no undocumented single expert

For each critical service, compare current recovery capability to the RTO/RPO target, and prioritise investment by criticality AND the size of the gap. Backup is not DR is not resilience — be explicit about what is actually tested.

• Immutable and/or offline (air-gapped) backup copies exist outside the production blast radius (ransomware resilience)
• Recovery has been tested end to end and timed against the RTO — not assumed from a successful backup job
• Test cadence set for each critical service, including severe-but-plausible scenarios (loss of people, vendors, network)
• Investment prioritised by criticality and gap, not spread evenly or by the loudest sponsor
• Findings from the last test fed back into the RTO/RPO targets and this plan

Impact tolerance is a risk-appetite decision the board owns: how much disruption to each critical service the organisation is willing to accept. Management delivers the capability to stay within it. Record the agreed targets and the approvals here.