The outage happened overnight. By morning, the technician already had the server back up — files, management system, everything restored. And the company still lost another full day, because no one knew what came next: which system to turn on first, who would call the clients about the delay, who had the authority to say "stop trying to fix it, switch to the backup plan".
NIST — the United States government's technical standards institute — describes this moment, in its contingency planning guide, as a process with phases: first someone has to be notified and decide to activate the plan; then comes recovery itself, system by system, in an order defined ahead of time; only at the end comes the return to normal operation. The same guide flags a detail most companies overlook: copies of that plan, with the list of who to notify and in what order, need to be kept somewhere that survives the outage itself — because the system holding that file may be exactly the one that went down.
For whoever decides at a small or mid-sized company, the money lost between the server coming back and the business billing again rarely sits in the backup itself. It sits in the time someone spends looking for a phone number, deciding alone something that should have been decided already, and explaining to a client a delay that should have had a ready message.
Bringing the server back isn't bringing the business back
A serious outage — an attack that scrambles the files, a hardware failure, a flood in the server room — takes the system down for more than a few hours. The backup, when it exists and works, handles the technical side. It doesn't answer four questions that stay open: what comes back first, who talks to the bank and the suppliers, when to give up fixing it, and where the contact list is if the system that held it is the one that went down.
A 2025 Veeam survey of companies worldwide that had been hit by ransomware — the data-hijacking attack where a program scrambles the files and demands payment to return them — in the previous year measured exactly that gap. Only 30% of them had defined, before the attack, a chain of command for handling the crisis. And only 26% had a ready process to guide the most critical decisions under pressure. Most decide on the spot — at the worst possible moment to decide well.
The same survey found a number that helps explain why: 69% of these companies believed they were prepared before being attacked. After the attack, that confidence dropped by more than 20 percentage points. What existed on paper didn't survive the real test — often because the "plan" was just a backup routine, without the decision-making part.
There's a sign of improvement, and it points the same way. Sophos's 2025 report, with 3,400 IT and security leaders across 17 countries whose companies had been hit by ransomware in the previous year, found that 53% of them were back operating within a week — more than double the rate recorded in 2024. The improvement didn't come only from faster backup: it came from companies that had already rehearsed the response, not just stored a copy of the data.
The usual approach isn't a plan
The usual way of handling the day of an outage follows roughly the same script at every company that hasn't stopped to think it through beforehand. The company trusts that if the backup exists, everything else sorts itself out. Who calls whom gets decided on the spot, usually by whoever happens to be the calmest person around at that moment. And the response gets coordinated over the same corporate email or the same messaging app the company always uses — which, if the server is down, may also be offline.
The list of important contacts — the bank manager's phone number, the critical supplier's, the client who needs to be told first — usually lives inside the very computer that went down, or only in the head of whoever always handles it. When that person is on vacation, asleep, or also affected by the outage, the list doesn't exist for anyone else.
CISA's guide — the United States infrastructure security agency — on incident response plans is blunt about this: print the document and its associated contact list, and hand a copy to everyone who will play a role in the crisis, because the company's email, chat, and document storage may be down exactly when they're needed most. The same guide describes two roles a small company usually lacks: someone responsible only for leading the response and making the call — without also carrying the technical work — and someone responsible only for talking to outsiders, like clients and suppliers. Without that split, the same person trying to fix the server also tries to remember the bank's phone number, and does both jobs poorly.
What has to be in place
A recovery plan that works on the bad day is defined by decisions made beforehand, not by the size of the backup stored somewhere.
The restart order written down, system by system. Decided in advance what comes back first — the financial system, email, whatever serves the client — instead of figured out on the spot, by whoever shouts loudest in the room.
One person with the authority to decide, not a meeting. Someone who can say "stop trying to fix it, switch to the backup plan" without needing to gather everyone for a vote — and that person is defined ahead of time, with a clear backup for when they're unavailable.
An agreed cutoff time to flip the switch. A limit set in advance — "if it's not fixed by a certain time, we activate the backup plan" — so the decision doesn't depend on the optimism of whoever is trying to fix it.
The contact list kept outside the system that can go down. Name, phone number, and order of priority for who calls the bank, who talks to the client, and who contacts the supplier — on paper or somewhere that doesn't depend on the server that went down.
A ready message for the client, missing only the date and time. A text already written in advance, so no one has to compose a sentence during the crisis, and it doesn't come across as improvised.
This is how Skills IT works: with the restart order defined before the outage, a clear owner for the decision to switch plans, and the contact list kept outside the environment that can go down.
What deciding ahead of time earns the business
The gain from having decided this beforehand is operational and financial at once. Less time lost to indecision means less downtime — and downtime means unbilled orders, employees waiting for instructions, and rework afterward. A client warned in time, with a message that already existed, tends to accept the delay; a client who finds out through silence tends to look for another supplier.
There's also a gain in who decides under pressure. The same Veeam survey cited above found that companies with better outcomes after an attack more often had exactly the decision-making elements — a defined chain of command, a ready process for the hardest choices — built into the plan itself, not just the technical side of backup and restore. Having this written down doesn't prevent the outage. It prevents the outage from becoming two crises: the technical one, which the team resolves, and the decision-making one, which stays without an owner.
Five questions to bring to the next meeting
Before writing another document, it's worth testing whether the answers already exist — and whether two different people, asked separately, give the same answer.
- If the server went down today, which system would come back first? If the answer varies from person to person, the order isn't defined — it's in each person's head.
- Who has the authority to decide to switch plans, and who is that person's backup? If the answer is "we'll get together and decide," there isn't a plan yet — there's a promised meeting.
- Where is the contact list if the system holding it also goes down? Paper, a service separate from the server, someone's personal phone — anywhere that doesn't depend on what went down.
- Is there an agreed time to give up on the fix and switch strategy? Without that limit, the decision stays hostage to the optimism of whoever is trying to solve it.
- Is there a ready message for the client, missing only the date and time? If the answer is "we'll write it when it happens," the client will notice the improvisation — and remember it at the next negotiation.
