In nearly every business continuity engagement we begin, the plan already exists. It is documented. Leadership has reviewed it. In regulated environments it has been submitted to an examiner or an auditor and accepted. By every visible measure the organization is prepared.
Then we ask when it was last executed.
The answer is usually some version of never. Not never written. Never run. There may have been a tabletop exercise two or three years ago, facilitated by a vendor and scoped to one scenario. There has rarely been an attempt to execute the plan as written, under time pressure, with the people who would actually be on the call.
That distance between a plan that exists and a plan that works is where most continuity risk lives. It is also the least expensive risk to reduce, because closing it rarely requires new technology. It requires finding out what is no longer true.
Five places we consistently find that gap.
1. The plan assumes people who are no longer there
Continuity plans are written by named individuals, and they tend to name individuals. A specific director declares the incident. A specific engineer executes failover. A specific analyst handles customer notification. That is reasonable on the day the document is written. It becomes a liability the moment someone changes roles.
We routinely open plans listing three or four people who have left the organization, and several more who have moved into unrelated functions. Nobody removed them because nobody owns reconciling the plan against the current org chart. The document was approved once and then treated as finished.
The correction is structural rather than editorial. Assign responsibilities to roles, then maintain a single appendix mapping roles to current people. That appendix becomes the only page requiring review when someone joins or leaves, which turns an annual rewrite into a five minute update.
2. Recovery objectives were negotiated, not measured
Ask a leadership team for the recovery time objective on a critical system and you will usually get a confident number. Four hours. One business day. Ask how the number was determined and the confidence drops.
In most cases it was negotiated. Someone proposed a target, someone else said the business could not tolerate longer, and the number went into the document. It reflects what the organization wants to be true. It has not been compared against how long a restore actually takes on current infrastructure, at current data volumes, with the staffing available at two in the morning on a holiday weekend.
Untested objectives create a specific and expensive failure. Leadership makes commitments to customers, regulators, and partners based on a number operations cannot deliver. The gap surfaces during the incident, in front of everyone.
3. Dependency mapping stops at the perimeter
Internal dependency mapping is usually competent. Teams know which applications depend on which databases, which servers, and which network segments.
What is far less often mapped is everything outside the organization. The payment processor. The identity provider. The clearing partner. The managed service provider holding administrative credentials. The single cloud region where three supposedly independent systems all happen to run.
Planning that stops at the perimeter produces a document that is accurate about the part of a failure the organization controls and silent about the part it does not. External dependencies cause a substantial share of real disruptions, and they are precisely the disruptions where an organization has the least ability to act and the greatest need to have decided in advance.
4. Teams have rehearsed the procedure, not the decision
This is our most consistent finding and the one clients least expect.
Technical teams often know the steps well. They can describe failover, restoration sequence, and validation with real fluency. What has almost never been rehearsed is the moment before any of that begins.
Who declares an incident. On what threshold. With what authority when that person is unreachable. Who decides to fail over knowing that failing back will be expensive and may lose data. Who authorizes telling customers before the picture is complete.
Those are judgment calls made under uncertainty by people, not runbooks. Organizations lose hours at the start of an incident not because nobody knew what to do, but because nobody was certain they were the person allowed to say so. An exercise that begins after the declaration has skipped the hardest part.
5. The documentation lives inside the failure
And the simplest one. We have found runbooks stored on the file share the runbook exists to recover. Contact trees maintained in the email system that was down. Credentials in a vault reachable only through the single sign on service that had failed.
Every one of those was built by a competent team. The dependency is easy to miss precisely because the document is used during normal operations, when everything is reachable.
What a readiness review actually produces
A readiness review does not produce a longer plan. Done properly it produces a shorter list of statements the organization can defend. This objective has been measured and here is the number. This dependency has been mapped. This decision has an owner and a named alternate. This document is reachable when the primary environment is not.
That is a different kind of confidence than an approved document provides. It is the kind that survives the first hour.
Call to Action
If your continuity plan has been approved but never executed, a readiness review is a contained exercise with a clear output. System Custom Consultants works with organizations across financial services, healthcare, and the public sector to test continuity plans against real conditions and close the gaps that testing reveals. Start a conversation at systemcustom.com.
