IT disaster recovery plan template for a small business

Most small businesses do not have an IT disaster recovery plan because the templates they find are written for organisations with an IT department and a data centre. This one is not. It is the structure Dig IT uses with businesses of up to 250 people, with each section explained and example wording you can adapt. Fill it in over an afternoon, test it, and it will do more for your recovery time than any piece of hardware.

Before you start

Three inputs make the writing quick:

1. A list of the systems the business cannot trade without, agreed with the directors.
2. A recovery time objective and recovery point objective for each, set in the way described in RTO vs RPO explained.
3. An honest picture of the current backups: what, where, how often, and when one was last restored.

With those in hand, the sections below almost write themselves.

The template: purpose, people and systems

1. Purpose and scope

One paragraph. What the plan covers and what it does not.

Example: This plan sets out how [Company] restores its IT systems and data after a serious failure, cyber attack or loss of premises. It covers the systems listed in section 3. Wider business continuity arrangements, including premises and staffing, are in the business continuity plan.

2. Roles, contacts and delegation

Who does what, with a named deputy for every role and contact details that do not depend on company email.

Add mobile numbers, personal email addresses, the IT provider's out-of-hours line, the VoIP provider, the broadband provider, the insurer's claims line and key software vendors. State explicitly who may authorise emergency spending and up to what amount.

3. Critical systems inventory and recovery targets

The heart of the plan. One row per system, sorted by RTO so the table doubles as the restoration order.

Dependencies matter: restoring an application server before the domain controller it authenticates against wastes an hour.

The template: scenarios, backups and procedures

4. Risk scenarios

The five or six most likely events, each with a one-line description of the impact. Typical for an SME:

• Ransomware encrypting the servers and synced cloud files.
• Failure of the main server or virtualisation host.
• Loss of the office through fire, flood or denial of access.
• Broadband outage lasting more than a few hours.
• Compromise of a Microsoft 365 administrator account.
• Departure or unavailability of the only person with admin access.

Each scenario gets a procedure in section 6.

5. Backup arrangements

State the facts, so nobody has to find them out during an incident:

Example: Servers are backed up as images to the Synology NAS every two hours and retained for 30 days. The NAS replicates to encrypted cloud storage nightly with 90-day retention. Immutable snapshots are held on the NAS for 14 days. Microsoft 365 is backed up daily by [service] with one-year retention. The backup console uses separate credentials held in the password manager. Backup jobs are checked daily by [IT provider]. The last full server test restore was on [date] and took [time].

Check the design against the 3-2-1 backup rule, and if any of the sentences above cannot be written truthfully, that is the first gap to fix.

6. Recovery procedures per scenario

One page per scenario, written so that a competent person who has never seen the environment can follow it. Numbered steps, expected time for each, where the credentials are, and how to confirm success.

Example, ransomware:

1. Isolate: disconnect affected servers and PCs from the network. Do not power off servers if forensic evidence may be needed. (15 minutes)
2. Contain: reset all administrator passwords and enforce MFA. Disable remote access until cleared. (30 minutes)
3. Assess: identify the last clean immutable snapshot. Confirm the backup console was not compromised. (30 minutes)
4. Notify: incident lead informs insurer and, if personal data is affected, data protection lead assesses ICO notification within 72 hours. (concurrent)
5. Restore: domain controller first from the clean snapshot to the host, then application servers in section 3 order. Verify each before the next. (2 to 6 hours)
6. Cloud: restore affected Microsoft 365 data from the independent backup. (1 to 2 hours)
7. Reconnect: bring PCs back after scanning and patching. (as capacity allows)
8. Review: record timeline, cause and lessons. Update this plan.

Repeat for each scenario. The detailed technical runbooks, with commands and screenshots, go in the appendices.

The template: communication, suppliers and upkeep

7. Communication plan

How staff are told when email and Teams are down (a WhatsApp group or phone tree from the contact list). Who speaks to customers and the pre-agreed holding message. Which suppliers and partners are told and by whom. When and how the ICO is informed, following the ICO's guidance on personal data breaches. For hosted VoIP, the pre-recorded closure greeting and who switches it, as described in VoIP and business continuity.

8. Interim workarounds

How each critical function runs for a day without its system. Phones on mobile apps. Email from the web. Orders taken on paper and keyed later. Payroll from a laptop at a director's home. Write them down so nobody invents them under pressure.

9. Suppliers and escalation

For each supplier that recovery depends on: what they provide, the support number, the account reference, the contracted response time and who at your end holds the relationship. Include the IT provider, VoIP, broadband, line-of-business software vendors, the hardware supplier for emergency replacements, and the cyber insurer.

10. Testing schedule

Record every test. The reasons this matters are in why IT recovery plans fail.

11. Review triggers and version control

The plan is reviewed after every test and after any of: a new server or cloud service, a new line-of-business system, a new site or office move, a change of IT provider or supplier, or the departure of anyone with administrator access. Front page carries the version, the owner, the date and the next review date.

Appendices

• Network diagram.
• Asset and licence list.
• Technical runbooks per system.
• Location of credentials (the password manager, not the credentials themselves).
• Insurance policy summary and claim requirements.

Making it real

A completed template is a start. What makes it a plan is testing it with the usual person absent, storing it where the scenarios cannot destroy it, and keeping it current. Most small businesses can complete and test a first version in a day with their IT provider, and Dig IT's backup and disaster recovery service includes the scheduled test restores that populate section 10 without anyone having to remember.

What to do next

If you would like this template completed for your own systems rather than in the abstract, the quickest route is a half-day session covering the inventory, the targets and the current backups, followed by a first test restore. Book an IT health check and Dig IT will run it with you.