Disaster Recovery Plan Template for Small Businesses

Disaster recovery plan template (copy this)

Copy this into Word or Google Docs and fill in the brackets. Keep it short, and where detail already lives somewhere else, such as an IT supplier's runbook, say where it is. Never write passwords into the plan: say where access is held and who holds it.

DISASTER RECOVERY PLAN: [Business name]
Version: [ ]   Last reviewed: [date]   Next review: [date]   Plan owner: [name]

1. WHO DOES WHAT
   Recovery lead:            [name]        Deputy: [name]
   Who can declare a disaster and start this plan:  [name]   Deputy: [name]
   IT support:               [company or person, phone, out-of-hours number]
   Who tells staff:          [name]
   Who tells clients:        [name]
   Who calls the insurer:    [name]   Policy and helpline kept at: [where]

2. SYSTEMS AND DATA (everything the business runs on)
   System        What it's for     Account owner   Where the data lives   Backed up how, how often   Last restore test
   [email]       [ ]               [ ]             [ ]                    [ ]                        [date]
   [files]       [ ]               [ ]             [ ]                    [ ]                        [date]
   [accounts]    [ ]               [ ]             [ ]                    [ ]                        [date]
   [devices]     [laptops, phones, any server or network kit]

3. RECOVERY ORDER (what comes back first, at the top)
   Order   System      Recovery time (RTO)   Data loss limit (RPO)   Depends on
   1       [ ]         [hours]               [ ]                     [ ]
   2       [ ]         [ ]                   [ ]                     [ ]
   3       [ ]         [ ]                   [ ]                     [ ]

4. FIRST STEPS FOR EACH SYSTEM
   System: [ ]
   - Who restores it:                [ ]
   - First call (supplier support):  [ ]
   - Where the backup is:            [ ]
   - How we check it's working:      [e.g. two people sign in and open today's files]

5. WORKING WITHOUT IT
   While [system] is down, we:       [the manual workaround, or "see continuity plan"]

6. EMERGENCY ACCESS
   Admin accounts for:               [list]
   Held by:                          [two named people]
   Recovery codes kept:              [where, never in this document]

7. CONTACTS
   IT support, internet provider, key software suppliers, bank, insurer:
   [company, account reference, support number]

8. THE FIRST HOUR
   [ ] Stop the damage: disconnect affected devices if advised by IT support
   [ ] Recovery lead decides whether to start the plan
   [ ] Work out which systems are affected and what still works
   [ ] Call IT support and, if it's a cyber attack, the insurer's helpline
   [ ] Tell staff what to use and when the next update is
   [ ] Start a log: time, what happened, decision, who made it

9. TESTING AND CHANGES
   Last restore test: [date, what, result]   Last walk-through: [date]
   Next test: [date, owner]   Changes since last version: [ ]

Two rules hold this together. Every system has a named account owner, so somebody can actually call the supplier and be recognised. And the plan can't depend on the thing that's broken: if the only copy lives in the shared drive, print one and keep a copy somewhere else.

What a disaster recovery plan covers

The word "disaster" puts people off. In a small business the usual causes are ordinary: a ransomware attack, a laptop left on a train, an email account taken over, someone deleting the wrong folder, a supplier outage or a broken update. The plan doesn't need to predict which one. It needs to answer the same few questions for each system:

• What do we have, and where does its data actually live?
• Which systems come back first?
• How quickly do we need each one, and how much data can we lose?
• Who restores it, and who do they call?
• How do we know the backup works?

That's all disaster recovery is. The rest of the business carrying on while it happens is your business continuity plan, and the two should fit together.

RTO and RPO in plain words

Disaster recovery uses two terms that sound more technical than they are. You need both for every system on your list.

The recovery time is about speed; the data loss limit is about how often you copy. A system can need a fast recovery and tolerate a lot of data loss, or the other way round. A website might be fine rebuilt from last month's copy, but you'd want it back within a day. Your accounts might be able to wait two days, but you can't lose a week of entries.

The US government's business preparedness site, Ready.gov, makes the point that IT recovery times should match what the business activities depending on them need. That's the link with your continuity plan.

Try sorting a few. Each line is a typical example.

How to set the recovery order

Section 3 of the template is where the plan earns its keep. On the day, everyone wants their own system first. Decide now, when nobody's under pressure.

1. Start with what everything else depends on. In a small business that's usually your main email and sign-in account, because most other tools sign in through it or send password resets to it. Then your internet connection and the devices people work on.
2. Then the systems tied to money and clients. Whatever you deliver client work from, invoicing and payroll. If your continuity plan already lists critical activities, the systems behind them go here.
3. Then everything that can wait a few days. Internal reporting, archives, the intranet, marketing tools.

Group them into three tiers if a numbered list feels too precise.

Check each recovery time against the data loss limit. If you've promised the accounts back in a day with no more than a day's data lost, your backups have to run at least daily and someone has to know how to restore them in under a day.

A worked example (typical, made up)

Here's how section 3 might look for a typical 10-person architecture practice. The firm and figures are invented to show the format.

Look at what the table forces. Somebody has to keep a spare laptop ready. Two people need admin access, so recovery doesn't depend on the office manager being reachable. Files must never live only on a laptop. Those are small jobs, and they're easy to give an owner once they're written down.

Cloud software: your part and theirs

Many small businesses no longer have a server, and that's made recovery simpler. It hasn't made it disappear. A cloud provider keeps its service running. What it usually can't fix for you is an account taken over by someone else, a folder a member of staff deleted months ago, or the only admin login belonging to someone who's left.

For each cloud system on your list, find out three things from the provider's own help pages:

• How long deleted data can be restored for, and who can restore it
• Whether you need a separate backup for anything that must go back further than that
• How you'd recover the account if your admin couldn't sign in

Write the answers into section 2, and put the second admin's name in section 6. The UK's National Cyber Security Centre covers backups and account security for organisations without IT specialists in its small organisations guide.

Disaster recovery vs business continuity

The two get mixed up because they're used in the same week. They answer different questions.

The rule that joins them: a system's recovery time has to be shorter than the time the work depending on it can stop. If client delivery can stop for one day, the files it runs on can't take three days to restore. Our business continuity plan template covers the other side, and your risk register is where the likelihood of each disruption gets recorded.

Test it before you need it

A backup you've never restored from is a hope. Testing needn't mean switching anything off.

• A restore test (half an hour). Restore one real file or folder from backup to a different place, and check it opens. Do a different system each time.
• An access test. Ask your second admin to sign in to each admin account without help. You'll often find a recovery code that went to someone who's left.
• A walk-through (about an hour). Sit the recovery lead and two others round a table, describe a situation ("email is locked and the shared drive shows a ransom note") and follow the plan. Write down every "we'd have to check".

For cyber attacks in particular, the National Cyber Security Centre has a free, ready-made exercise called Exercise in a Box. After any real incident, review what worked and update the plan.

Keep it current

Review the plan once a year and after any real incident. Update it straight away when one of these changes:

• You add, replace or stop using a key system or supplier
• Someone named in the plan, or holding an admin account, leaves or changes role
• A client contract promises how quickly you'll restore their service
• Your insurer asks new questions at renewal

When someone leaves, removing their access and handing over their admin accounts is part of the handover. It's also the moment recovery plans most often go out of date.