Disaster recovery plan: what to do in the first hour

A disaster recovery plan sets out how a business restores its systems and data after something breaks badly — ransomware, a failed server, a flooded office, a provider outage that lasts days rather than hours. It is the technical half of the broader question covered in business continuity plan, which is about keeping the business running by any means while recovery happens.

The version most small businesses need is two pages, not a binder. What kills recovery is rarely the absence of a procedure; it is that nobody knew who was allowed to decide, the credentials were in the system that went down, and the backup had not been tested.

Two numbers that shape everything

• Recovery time objective: how long you can be down before the damage is serious. An hour, a day, a week — say it per system, because the answer for email is not the answer for the accounting package.
• Recovery point objective: how much data you can afford to lose, measured in time. A daily backup means up to a day of work gone, and that is a decision rather than an accident once you have written it down.
• Those two numbers determine what you need to buy. Most businesses discover their current arrangements imply a recovery point of a week and are surprised, which is the useful part of the exercise.

What the plan has to contain

1. Who declares an incident and who leads it, with a named deputy. Decisions stall when nobody is sure they have the authority.
2. Contact details for everyone involved — staff, providers, insurer, landlord — held somewhere reachable when the systems are down. Printed, or on a phone.
3. The recovery order: which system comes back first, and which can wait a week. Restoring in the wrong order is a common way to waste the first day.
4. Where the backups are, who can access them, and how a restore actually starts, covered in data backup.
5. Credentials and recovery codes, held outside the systems they unlock. This is the single most common reason recovery stalls in hour one.
6. What to tell customers, and who says it. Silence during an outage does more commercial damage than the outage.
7. When to involve the insurer, and what they require you to preserve — several policies have notification deadlines and evidence conditions.

Keep a copy offline. A plan stored only in the system that failed is a plan you cannot read during the event it was written for, and this is not a hypothetical failure — it is the most frequently reported problem in ransomware recovery. One printed copy at home, or a file on a phone, costs nothing.

Testing, at a realistic scale

A full failover rehearsal is out of reach for most small businesses, and a tabletop walkthrough is not. Take an hour, pick a scenario, and talk through who does what — you will find three missing things, and finding them costs nothing. Beyond that, the specific thing worth actually doing is restoring a real file from a real backup and timing it, because the gap between having backups and being able to restore is where most of the surprise lives.

Ransomware, briefly

It deserves separate mention because it breaks the usual assumption: your backups may be encrypted too, if they were reachable from the machine that was infected. That is the argument for at least one copy that is offline or otherwise not writable from your network. On paying, the position of most law enforcement is that it funds the next attack and does not reliably return the data, and in some jurisdictions payment carries legal exposure of its own. That is a decision for the business with proper advice, not one to improvise at 2am — which is precisely why the plan should say who makes it.

Where it lives

Ettex Records holds the plan, the contact list and the test log as entries with owners and review dates, so that the annual review is visible rather than remembered. The immediate-response side is covered in incident response plan and the wider continuity question in business continuity plan.

Being clear: we are not a backup or disaster recovery provider. There is no failover, no replication, no recovery service. What we hold is the document — and the document is the part that is usually missing.