Twelve Documents Is Not a Programme

Ask an organisation whether it has a business continuity plan and the answer is almost always yes. Ask where it lives and the answer gets longer: a plan document on SharePoint, a risk register in Excel, a call tree in someone’s inbox, an application dependency list maintained by a team that has since been restructured, and a test report from the last exercise, which was eighteen months ago.

Every one of those artefacts was accurate when it was written. None of them know about each other. That is the gap between having plans and having a capability, and it does not announce itself until the day you need the whole picture at once.

Static plans decay on different schedules

A continuity plan is not one fact. It is a bundle of them — which processes matter, who owns them, what they depend on, how quickly they must come back, and who to reach when they do not. Each of those decays at its own rate.

Teams restructure monthly. Vendors change on contract cycles. Applications move when somebody migrates them. Recovery objectives change when the business changes what it sells. An annual review catches none of this on time, because the review cadence has nothing to do with the decay rate of the thing being reviewed.

Kept as separate documents, the inconsistencies are invisible. Kept as connected data, a change in one place shows up everywhere it matters — which is the entire practical argument for doing it that way.

What a programme actually consists of

Across the engagements we run, the same five capabilities do the work:

Business impact assessment. Establish how critical each process, technology and service really is, and agree recovery objectives and priorities with the people who will be held to them. This is the foundation; everything downstream inherits its accuracy.

Continuity and recovery planning. Structured plans, recovery strategies, roles and procedures that are maintained and approved rather than written once — and that are ready to activate without a reconstruction step.

Risk and dependency mapping. Risks across people, operations, technology and suppliers, with upstream and downstream dependencies made visible. This is where single points of failure surface, and they are almost never where the plan assumed.

Exercises and testing. Scenarios run against the real plan, with outcomes, lessons and corrective actions recorded. An untested plan is a hypothesis.

Automation, dashboards and integration. Reviews, approvals and escalations that chase the owner rather than the programme manager, readiness visible in real time, and connections to the HR, identity, ITSM and risk systems that already hold the truth about who works here and what runs where.

None of these are exotic. What is hard is holding all five in the same place, so that a dependency discovered during a test updates the map, and a map that changes flags the plans built on it.

Assess, plan, respond — and then keep going

The sequence is unglamorous and it matters in order.

Assess and map what matters, so priorities are agreed rather than assumed. Plan and test with confidence, so the plan is current and has been run at least once under something resembling load. Respond and recover with coordinated responsibilities and tracked activity. Then feed readiness data, test results and lessons back into the programme, so the next cycle starts further forward than the last one.

That fourth step is the one most programmes skip, and it is the one that separates a continuity function that improves from one that merely renews.

Where the local part matters

Resilience programmes are not only a technology question. They are also a question of who is in the room when something breaks, and in which time zone.

Our delivery teams sit in New Zealand, Australia and the Philippines, which is deliberate: a continuity programme supported from the other side of the world is fine until the incident starts at 3am local time. Deployment follows the same logic — cloud where speed and continuous product improvement matter, private cloud in an approved APAC region where data sovereignty, regulatory obligation or in-country hosting decides it. Which of those applies is settled during discovery, against your data classification, security controls, integrations and service levels, rather than assumed at the point of sale.

The honest test

Here is the question worth asking internally, before anyone asks it of you. If an incident started this afternoon, could the people running the response see the same picture — processes, dependencies, recovery priorities, responsibilities — without first assembling it from five systems and two people’s memories?

If the answer is no, the problem is not that the plans are bad. It is that they are not connected to anything. That is a fixable problem, and fixing it is considerably cheaper before the incident than during it.