Business Impact Analysis, BC and DR planning, RTO/RPO tiering, and recovery testing — the resilience programme built before a disruption forces the question of whether your plans would actually work.
Most organisations have a disaster recovery plan. Most of those plans were written once, approved by a committee, filed, and never tested against the actual environment. The RTO targets were agreed in a spreadsheet — not measured in a live recovery exercise. The dependencies listed in the BIA reflect the architecture as it existed eighteen months ago, not the cloud services added since and the legacy systems quietly decommissioned.
Business continuity planning often fails at a different layer: the assumption that office access is guaranteed, that key personnel will be available, that manual workarounds documented in an appendix will actually work under pressure. These are the things that a disruption event tests, and they are almost never tested before one occurs.
The organisations that recover well from disruptions are not the ones with the thickest DR binders. They are the ones that have run recovery exercises, know their actual RTO rather than their target RTO, and have tested the manual workarounds before the systems went down and the workarounds became the only option.
The RTO had been agreed in a planning meeting and documented as a target. The recovery procedure had never been timed. When a storage failure forced an actual DR invocation, the restoration of the primary database took six hours alone — a configuration dependency introduced eleven months earlier had never been incorporated into the runbook. The 4-hour RTO was not a plan. It was an aspiration that nobody had tested.
The Business Impact Analysis had been completed as part of an ISO 27001 certification project. It listed ten critical systems. By the time a major disruption occurred, four of those systems had been decommissioned, two new SaaS platforms had become operationally critical, and a cloud data pipeline that touched customer records daily appeared nowhere in the document. The BIA described a business that no longer existed.
Every manual workaround in the BC plan assumed physical access to the primary office — paper-based approval workflows, a localised backup of critical reference data, and a phone tree that relied on a landline at the reception desk. When the building became inaccessible, the workarounds in the plan were not executable. The plan had been written for a disruption scenario that did not include the building being unavailable — which turned out to be exactly the scenario that occurred.
A structured recovery programme starts with the BIA — understanding which systems and processes are genuinely critical to the business, and at what cost disruption to each one accumulates over time. RTO and RPO targets that are grounded in business impact, not convention, produce DR plans that are proportionate, testable, and fundable.
A BIA that reflects the current business. Plans written around the actual technology and team. Recovery targets that have been tested, not estimated. And a maintenance process that keeps the capability current as the business changes.
A structured BIA that identifies which processes and systems are genuinely critical, what the cost of disruption is over time, and what recovery objectives are proportionate to that impact. The BIA is the foundation of the entire programme — recovery targets that are not grounded in a current BIA are targets that nobody can justify when a real disruption forces a recovery decision.
A BC plan that covers what the business does when normal operating conditions are unavailable — office access, key systems, critical personnel. Manual workarounds, alternative locations, communication protocols, and decision authorities during a disruption event. Written to reflect how the business actually operates, including remote and distributed workforce scenarios that a traditional BC plan often fails to account for.
A DR plan with recovery runbooks for each tier, written around the actual technology stack — not a generic template adapted from another industry. Backup validation procedures, failover sequence documentation, dependency-aware recovery ordering, and restoration timings that have been measured rather than estimated.
DR failover testing to validate RTO targets against reality. Backup restoration exercises to confirm that the RPO targets are achievable with current backup infrastructure. Tabletop exercises to test BC plan decision-making with the cross-functional teams who would be managing a real disruption. Each exercise produces findings that update the plan — the programme improves with every test.
The engagement moves in sequence: understand the business impact, develop the plans, test them against reality, and establish the maintenance cycle that keeps them current. Each phase builds on the last — the BIA drives the plan, the tests refine the plan, and the maintenance cycle ensures the plan does not drift from the business it is meant to protect.
Structured interviews with process owners, review of the technology stack, and dependency mapping to produce a current BIA. Recovery tiers and RTO/RPO targets are derived from measured business impact — not from a template or a prior BIA that may no longer reflect the current environment. For organisations with an existing BIA, the first phase is a structured review and gap analysis: what has changed in the business and architecture since the BIA was last updated, and what that means for current recovery tier assignments and targets.
Weeks 1–2The BC and DR plans are developed in collaboration with the technical, operational, and leadership teams responsible for executing them. The BC plan manual workarounds are validated with the people who would use them. The DR runbooks are written with the engineers who know the current configuration. Plans written in isolation and handed over are plans that contain assumptions that only become visible during a real disruption. Plans developed with the people who will execute them are tested by that process itself.
Weeks 3–5A DR failover test for Tier 1 systems, timed against RTO targets. An end-to-end backup restoration exercise to validate RPO targets against the actual backup infrastructure. A tabletop exercise with cross-functional participants to test BC plan decision-making under realistic disruption conditions. The testing phase is where plans meet reality — and where the gap between the plan and the current environment surfaces in a controlled setting rather than during an actual incident.
Weeks 6–7Plans are updated based on testing findings. The annual BIA review date, DR test schedule, and BC tabletop cadence are calendared. Change management integration is established — a process for updating the BIA tier assignments and recovery runbooks when material changes are made to the technology stack or business operations. A BC/DR programme without a maintenance schedule is a plan that will drift from the business it is meant to protect. The maintenance cycle established at close is the most important output of the engagement.
Week 8The organisations that benefit most are not necessarily those facing the highest immediate risk. They are the ones that have recognised that an untested BC/DR programme is a liability — one that will be tested eventually, and in the worst possible conditions if it has not been tested first.
The plan exists. It was written during a certification project or a risk programme. The RTO targets were agreed and documented. The runbooks have never been executed in a recovery exercise, the backup restoration has never been timed end-to-end, and the configuration dependencies introduced over the past year are not reflected in any procedure. The plan describes what the teams intend to do. Whether it would actually work is unknown — and an untested assumption is not a recovery capability.
The business has changed faster than the BIA has been updated. New SaaS platforms have become operationally critical. Cloud infrastructure has replaced on-premises systems. Key processes have been outsourced or restructured. The BIA still reflects the architecture and operating model from the last review. Recovery tiers and RTO targets that were appropriate eighteen months ago may be materially wrong for the business as it operates today — and wrong recovery targets drive investment decisions in the wrong direction.
ISO 27001 Annex A and SOC 2 Availability criteria both require documented BC/DR procedures, evidence of testing, and mechanisms for reviewing and updating plans. Financial services regulators and critical infrastructure frameworks impose specific RTO requirements and mandatory testing evidence. A programme developed for the audit will satisfy Type I. A tested programme with documented recovery exercises and BIA reviews is what Type II and ongoing regulatory compliance require — and what protects the business when disruption actually occurs.
The disruption happened. The plans were invoked. Some things worked. Many did not — the runbook did not account for the cloud dependency, the manual workaround required office access that was unavailable, the recovery took four times the documented RTO because the backup configuration had changed. The post-incident review identified the specific gaps. This engagement rebuilds the programme around what was actually learned, rather than revising a template that produced the same failure points the first time.
The engagement closes with a BC/DR programme the business owns — not a document set that drifts. The BIA is current, the plans have been tested, and the maintenance cycle is embedded before the engagement closes.
A BIA that reflects the current technology stack, operating model, and third-party dependencies. Recovery tiers with RTO/RPO targets derived from measured impact — with a documented review schedule so it does not drift. The foundation the rest of the programme is built on — and the document that makes recovery investment decisions defensible.
A BC plan covering the disruption scenarios relevant to the business — office loss, key personnel unavailability, critical supplier failure. Manual workarounds that have been tested with the people who would execute them. Crisis communication templates pre-drafted before they are needed. A plan that reflects how the business actually operates — including distributed workforce realities.
Tier-specific DR runbooks written around the actual technology stack and validated through recovery exercises. RTO targets that reflect what the systems actually take to recover — not what was agreed in a planning meeting. Backup RPO targets validated against the actual backup infrastructure. A DR plan where the targets are measurements, not aspirations.
A documented test report covering the DR failover exercise, backup restoration test, and BC tabletop — findings, gaps identified, and plan updates made. An annual maintenance schedule with review dates, test cadence, and the change management process for keeping plans current. The evidence of testing that satisfies auditor requirements — and the mechanism that makes the capability sustainable.
When a disruption occurs, the recovery sequence is known and has been practised. The RTO targets are real because they have been timed. The manual workarounds work because the people who would use them helped validate them. The BIA reflects the current business, so the recovery priorities are the right ones. The first call goes to someone who already knows the environment. The disruption is managed — not because the event was simple, but because the preparation was genuine.