A recovery plan you have never tested is a hypothesis

Operational resilience is now a board and regulator question. FCA, PRA, DORA and the NCSC CAF all expect proven recovery of important business services - not a binder on a shelf. So here is the honest test: if your most critical service went down tomorrow, could you recover in time, and prove it?

Now a regulator question

For years, business continuity was a compliance artefact - a document you produced, filed and hoped never to need. That era is over. The FCA and PRA operational-resilience rules, DORA, and the NCSC Cyber Assessment Framework all ask the same thing in different words: can you keep your important business services within their impact tolerance, and can you prove it?

Most teams still answer that question with a spreadsheet and a Word document. The regulator is asking for a tested capability; the organisation is holding a hypothesis.

A plan you have never tested is a hypothesis

The typical business continuity plan is written once, approved, and filed in a SharePoint folder. It is never exercised. The first real test is the incident itself - which is a brutal and expensive way to discover that the recovery steps are out of date, the contacts have left, and the assumed recovery time was optimistic.

A plan that has survived a full failover exercise is a capability. A plan that has only ever been written down is a wish with a cover page. The difference only shows up when it matters, so it has to be found beforehand.

What does your citizen portal actually depend on?

Ask an honest question of any critical service - say, a citizen-facing portal - and the answer is rarely written down. It depends on identity and SSO, a core database, a primary data centre, a single cloud region, perhaps a legacy mainframe and a payments supplier, plus a key team that happens to be three people. Any one of those failing can take the service down.

Right now, that map lives in a few people’s heads. So when something fails, the organisation works out what it takes down during the incident, at 3am, under pressure. The blast radius should be known before the incident, not discovered live.

What the blindness costs

This is not a documentation gap, it is three concrete failures. Your real recovery time is whatever the slowest hidden dependency takes - and you have never measured it. Your continuity plan is untested until it is real. And when the regulator asks whether your important services stay within impact tolerance, you cannot show the working.

None of those are fixed by a tidier spreadsheet, because the problem is that the service, its dependencies, its plan and its test results all live in different places and nobody owns the chain.

Connect the whole chain

The fix is to make one thread run from a critical service all the way to a tested recovery: critical service to business impact analysis, to a real dependency graph, to an owned continuity plan, to a tested recovery, to a resilience score. Every link a real record, not free text in a cell.

When the dependencies are linked to your actual systems, assets and suppliers, the graph becomes queryable - you can see the cascade. And when you change one link or fail one test, the per-service dependency-risk and recovery scores move with it. The picture stays live instead of ageing the moment it is saved.

Prove it, before the incident does

Proven recovery means owned plans with real structure, an exercise log that records tabletop, simulation and full-failover tests, and achieved RTO captured against target. Roll that up with prevention and absorption into a live Prevent, Absorb, Recover posture, and you have a resilience picture the board understands and the regulator accepts.

If your most critical service went down tomorrow, you should be able to say how long recovery takes, who owns the plan, and when it was last proven. Map your services to a tested recovery before the incident does it for you.