I have been in the room when a critical system stopped and everyone turned to the plan.
Someone said, “We have a plan.”
What followed was not a plan. It was one of five substitutes. I have used at least two of them myself.
A tested way to keep the process running when the system it depended on went down was rare. The belief that one existed was not.
The Five
No plan. The process is critical, everyone knows it, and nothing has been written or rehearsed for what happens when it stops. This survives because the process has not stopped recently—or because the last interruption ended before the absence became undeniable.
Wait for the system to be restored. The system recovery plan is treated as the business contingency plan. Recovery time objectives may be documented and even tested. Nobody has asked what the business does during that objective, or what happens if it is missed.
Go back to manual. This may be the most dangerous substitute because it sounds like a plan. The procedure says that staff revert to manual processing. Nobody has established that manual processing is still possible at current volume, with current staffing, or with people who still know the procedure. The people who could do it may have left years ago. The manual version survives as institutional memory—usually someone else’s.
A plan that was not tested. There is a document. It has an owner, a version, a date, and sometimes an audit sign-off. It has never been run, or it was run once, years ago, on a smaller process with different people. A plan nobody has run is a belief with a version number. The organization is confident because it can produce the document. That confidence is the condition the other four substitutes grow in.
A reason a plan was not needed. The system is too reliable. The vendor guarantees availability. It is in the cloud. The process is not really critical. The regulator has not asked. Each explanation is plausible until operating conditions ask a different question.
Before Any of the Five
A contingency plan does not become executable because it exists. Two decisions make it actionable. First, an authorized person declares that the normal process can no longer continue. Second, an authorized person invokes the contingency plan.
That is the incident-management problem: who recognizes the condition; who has authority to declare it; who is called; who decides to leave the normal process behind and invoke the contingency plan; and by when.
Without either decision, the best contingency plan in the building may never be used. Nobody with authority declares the incident, or the plan exists but is never invoked. Everyone else waits to be told.
Most of the five substitutes conceal this first failure. “Wait for the system to be restored” is what happens when nobody owns the decision to stop waiting. “Go back to manual” is only a plan if someone can order it and knows when to do so. The untested plan remains untested because no exercise has forced the declaration and invocation decisions into the same room.
The question therefore comes in two parts:
Who declares—and what do they invoke?
One Operating Environment
In one operating environment, a critical external service became unavailable, returned, and later failed again.
Each time, the first hour went to deciding whether the condition qualified as an incident and who could declare it. Then the room reached for the same two substitutes: wait for the service to return, or insist that no fallback was needed because the contract still described acceptable availability.
There was no tested alternative route.
After repeated disruptions, the first justification disappeared. “Wait” remained.
The people in the room were good at their jobs. That is the uncomfortable part. One group ran the process. Another managed the dependency. The plan for operating without it belonged to nobody who could execute it.
Orphaned recovery—before I had a name for it.
Orphaned Recovery
Orphaned recovery begins when three things separate: the people who run the process, the people who plan for its failure, and the platform the process depends on.
When one person or team owns the process and its fallback, the operating procedure can carry both. When those responsibilities split across business, resilience, technology, and third parties, a recovery plan can exist on paper without belonging to anyone who must make it work.
The issue is not organizational size by itself. It is separation without executable ownership.
What AI Changed
Nothing about the pattern. Everything about the fuse.
A conventional outage can be visible: the service is unavailable. An AI-dependent step can fail differently. It may continue returning complete-looking output while its performance becomes unreliable.
Current guidance and law already recognize parts of this problem. NIST’s Generative AI Profile calls for organizations to identify fallbacks for third-party generative AI and to define, communicate, and rehearse incident-response responsibilities. For covered high-risk systems, the EU AI Act addresses anomaly detection, human override, safe interruption, and—in cases of non-compliance—regulatory correction, withdrawal, or recall.
Those controls do not prove that an organization can continue the process after the AI is interrupted, disabled, withdrawn, or no longer trusted. They expose the question.
The same substitutes reappear. Go back to manual, for a process that has not been run manually. Wait for restoration, when there may be nothing conventional to restore. Say a plan was unnecessary because the AI was “only assisting.” Produce an untested plan written for the surrounding system rather than the step the AI now performs.
The fuse got shorter. The excuses did not get better.
The Question
Which substitute are you counting on?
Not what the plan document says. What would actually happen on the day the process that matters most stops?
If you can answer in one phrase—no plan, wait, manual, untested, not needed—you know where to look.
If you cannot, that is the finding.
Ask the question before the process stops:
Who declares—and what do they invoke?
The answer, not the document, is the plan.
