BCP and BIA: Building a Dynamic Business Continuity Plan That Works

Many organisations treat their Business Continuity Plan (BCP) as a static, check-the-box exercise: write the plan, store it on a shelf, hope it is never needed. Against supply-chain shocks, cyber incidents and climate events, that is a recipe for failure.

An effective BCP is not a document. It is a living programme built on a current Business Impact Analysis, continuously tested, and wired to the same risk data the rest of the organisation uses. This guide covers how the BIA feeds the BCP, how RTO and RPO are actually derived, and why most continuity programmes decay.

What Makes a BCP "Dynamic"

A dynamic BCP:

• Derives from a current Business Impact Analysis (BIA), so recovery priorities reflect real criticality rather than the loudest department.
• Updates when the organisation changes — new systems, vendors, locations — so the plan never silently goes stale.
• Is tested regularly through tabletop exercises and simulations, with findings fed back into the plan.
• Sits alongside incident management, so when an event happens you move from plan to action without switching tools.

1. Identify critical processes & owners
2. Define RTO (recovery time) & RPO (data loss)
3. Map dependencies (people, systems, vendors)
4. Prioritize recovery order
5. Document in BIA report & link to recovery plans

Linking RTO and RPO to the BIA

This is the connection most continuity programmes get backwards, so it is worth being precise.

RTO (Recovery Time Objective) is the maximum acceptable time a process can be unavailable before the consequences become unacceptable. RPO (Recovery Point Objective) is the maximum acceptable data loss, measured in time — how far back you can afford to restore.

Neither is a technical decision, and neither should be set by IT. Both are outputs of the BIA, derived from business consequence over time:

1. For each critical process, map how impact accumulates over an outage — after 1 hour, 4 hours, 24 hours, 72 hours, a week. Impact is rarely linear; most processes have a knee in the curve.
2. The point where impact crosses the unacceptable threshold is the MTPD (Maximum Tolerable Period of Disruption).
3. RTO is set below MTPD, with margin. An RTO equal to MTPD leaves no room for the recovery itself to go wrong.
4. RPO comes from data-loss tolerance, which is a different question entirely — how much re-keying, reconstruction or reconciliation the business can absorb.

A worked example: order capture is fine for two hours, painful at eight, and causes contractual penalties at 24 hours. MTPD is 24 hours, so RTO might be 8 hours. Separately, the business can reconstruct at most 15 minutes of orders from email and phone records, so RPO is 15 minutes. Those two numbers are unrelated to each other, and both come from the business, not the platform.

Only once RTO and RPO exist does the technical conversation make sense — because they determine the recovery architecture and its cost. A 15-minute RPO means synchronous or near-synchronous replication. A 24-hour RPO means nightly backup is sufficient. Setting the objective after choosing the technology inverts the whole exercise, and is how organisations end up paying for replication on systems nobody needs and running nightly backups on systems that cannot tolerate it.

Mapping Dependencies Across the Enterprise

A BIA that stops at process criticality is only half done. The recovery order is determined by dependencies, and dependencies cross departmental boundaries in ways no single BIA interview reveals.

Each critical process depends on:

• Applications, and those applications on infrastructure, and that infrastructure on facilities and network.
• People — named roles and their deputies, with skills that may exist in only one person.
• Third parties, whose own RTOs may exceed yours; a supplier with a 72-hour RTO caps every process that depends on them at 72 hours, regardless of what your plan says.
• Data, including upstream feeds that must be recovered before your process can restart.
• Other internal processes, which is where circular dependencies hide.

The failure that catches people out is the dependency chain longer than its weakest link. A process with a 4-hour RTO that depends on an application with an 8-hour RTO does not have a 4-hour RTO — it has an 8-hour one, and the plan is documenting a fiction. Reconciling these across the whole estate is exactly the analysis that spreadsheet-based BIAs cannot do, because each spreadsheet only sees its own process.

Holding every BIA in one system makes the chain traversable: you can ask which processes a given supplier or application supports, roll up the true achievable RTO, and see the conflicts as a list rather than discovering them during an incident.

Why "Checklist" BCPs Fail

1. They are outdated. Organisations change constantly; last year's plan does not know about this year's systems and suppliers.
2. They are disconnected. BIA in one place, recovery plans in another, incidents in a third — nobody holds the full picture.
3. They are untested. A plan that has never been exercised will crack under pressure, usually at a step everyone assumed was obvious.
4. They are unowned. Without a named owner and a review cadence, currency decays silently.
5. They are optimistic. Plans assume key staff are reachable, documentation is accessible, and the recovery site works. Exercises exist to falsify those assumptions before an incident does.

Testing That Actually Tells You Something

Exercise types, in increasing order of cost and value:

• Plan walkthrough — read it aloud with the owners. Catches staleness cheaply; catches nothing else.
• Tabletop — a facilitated scenario with decision points. Catches unclear authority, missing contacts, and unexamined assumptions.
• Functional test — actually fail over one component. Catches the technical gap between documented and real recovery times.
• Full simulation — end to end, ideally unannounced. Expensive, and the only test that produces a defensible recovery time.

The output that matters is the gap list, and gaps have to become tracked actions with owners and dates. An exercise whose findings are not tracked to closure is theatre. Aim for at least one tabletop per critical process annually, and a functional test of the highest-criticality recovery paths.

Aligning to ISO 22301

ISO 22301 formalises this as a management system: understand the organisation (BIA and risk assessment), determine strategy, implement procedures, exercise them, evaluate, and improve. Its practical demands are a documented BIA methodology, defined and justified RTO/RPO, tested procedures, and evidence of management review.

The evidence requirement is what pushes continuity into a GRC platform. Auditors ask for the BIA that justifies an RTO, the exercise record that validates the procedure, and the actions that closed the last round of gaps — all with dates and owners. Reconstructing that trail from documents and email each cycle is where the effort goes.

From Document to Programme

Moving to a dynamic BCP means treating continuity as a process rather than a project. Practically:

• One BIA repository, with a consistent methodology and refresh cycle rather than a per-department spreadsheet.
• Dependencies as data, not prose, so RTO conflicts surface automatically.
• Recovery plans versioned and linked to the BIA entries that justify them.
• Exercises scheduled, findings tracked, with closure evidence retained.
• Incidents feeding back, so a real event updates the assumptions rather than just being survived.

When BIA, recovery plans, exercises and the incident log live in the same GRC platform as the risk register, continuity stops being a parallel universe with its own vocabulary and becomes another view of enterprise risk. That is the point at which the plan stays current without heroics.

To see how ActiveERM supports this end to end, explore Business Continuity, our ISO 22301 coverage, and Risk Management — or request a demo.