Five reasons continuity plans fail at the first outage

Almost every company I talk to has a continuity plan. It is well structured, approved and passed the last audit. The honest question is: has anyone ever used it under pressure?

From more than 15 years in IT operations I know the moments when a plan is needed for the first time. Five patterns keep coming back.

1. It lives where the outage happens

The plan sits in the wiki, on the file server or in SharePoint. Exactly the systems that go first in a ransomware attack or a power cut. What helps: a current copy offline, printed and in a known place. For knowledge platforms like Confluence, a regular export that stays readable without a network is worth it.

2. The contacts are out of date

Phone lists age faster than any other chapter. People change roles, providers change their contact, mobile numbers change. What helps: check the contact list every quarter and name one person responsible for it.

3. Nobody knows who starts

The plan describes procedures, but not who makes which decision in the first hour. In an incident everyone waits for everyone else. What helps: one card per role, a single page with the first steps and the people to call.

4. It is too long

80 pages convince an auditor. In an incident nobody reads them. What helps: keep the plan as a reference, but move the first hours onto cards and checklists.

5. It was never tested

This is the most important point, and it explains the other four. An untested plan contains assumptions nobody has checked: estimated recovery times and dependencies nobody knows about. What helps: a tabletop exercise with the crisis team. A realistic scenario at the table shows within a few hours where the plan holds and where it does not.

What you can do today

Take your continuity plan, switch off the network in your head and ask: who finds this document now, and whom do they call first? If the answer is not immediately clear, you have found your starting point.