How do you create a disaster recovery plan for a small business?

A disaster recovery plan sets out how your business restores systems and data after an incident such as ransomware, a fire, a flood or a major failure. It names who acts, what is restored first and how long it should take. Fast Response IT sets out eight steps for building one below.

What is a disaster recovery plan?

A disaster recovery plan is a documented set of steps to get your IT systems and data working again after an incident. It reduces the impact of natural disasters, human error and cyber attacks on operations, data security and compliance.

If your plan is out of date, incomplete or does not exist, recent major IT outages are a reason to review it now. A plan written before a crisis is far easier than improvising during one.

Step 1: Who should be on the disaster response team?

Set up a response team and define each person's role. This team leads recovery and keeps staff, customers and other stakeholders informed. Document responsibilities so nobody has to guess, and name backup people who can step in if a key member is unavailable.

Step 2: What are your RTOs and RPOs?

Two measures drive the rest of the plan.

Recovery time objective (RTO) is how long an application can be offline before it harms the business. Recovery point objective (RPO) is the maximum amount of data you can afford to lose, which decides how often you back up.

These are examples only. Set your own targets by asking what each system's downtime and data loss would cost you. Budget matters too, because faster recovery costs more.

Step 3: How do you map your network and systems?

Draw a simple map of your servers, applications, connections and services. Label each as mission-critical, essential or non-essential, and note dependencies. A system may look minor but be required by something critical. The map shows what to restore first.

Step 4: How do you pick a disaster recovery solution?

Storage, recovery speed and setup complexity all affect cost. You often choose between a solution that recovers quickly but may lose some data, and one that keeps running continuously but costs more and is more complex.

A suitable solution generally includes replication of server images and production data to a recovery location, the ability to run planned tests, and a way to fail over to the recovery environment and back again. Fast Response IT plans disaster recovery for on-premises servers and protects cloud-hosted systems with patching, security and backups.

Step 5: When should the plan be activated?

Not every incident needs a full response. A short power cut is different from losing your premises. Write a checklist that sets out what counts as a disaster and who decides to activate the plan. This avoids both overreaction and delay.

Step 6: How do you document the recovery process?

Write clear, step-by-step instructions so your team can act as soon as it is safe to do so. Include contacts, credentials access, supplier details and the order of restoration.

Keep a copy of the plan somewhere that will not be affected by the same event, such as off-network or in secure storage. A plan stored only on a server encrypted by ransomware is no help.

Step 7: How often should you test the plan?

Test regularly. Partial recovery tests during the year and a full simulation at least annually are a sensible pattern, with occasional unannounced drills to see how people respond. Each test should end with a list of fixes.

Testing depends on good backups. Our guide to why data backups matter covers methods, encryption and monitoring.

Step 8: How do you keep the plan up to date?

Review the plan when your business changes: new systems, new staff, a new office, a new supplier. Your disaster recovery plan is one part of a wider business continuity strategy, so review both together.

What mistakes should you avoid?

The most common mistakes are practical. Plans are written once and never updated. Copies are stored only on the systems they are meant to rescue. Nobody has tested a restore, so the first test happens during a real incident.

Other mistakes are about people: no named decision maker, contact details that are out of date, or credentials that only one person knows. Check each of these in your own plan, and fix them before you need them.

How does this differ from a backup?

A backup is a copy of your data. A disaster recovery plan covers everything needed to use that copy: who acts, which systems return first, where they are rebuilt and how long it takes. You need both, and the plan should state clearly where each backup lives and how to reach it.

What should you do next?

Start with Steps 2 and 3. Write down your most important systems, how long you could cope without each, and how much data you could afford to lose. Even that one page is a useful base. For help turning it into a tested plan, see our backup and disaster recovery services or begin with the IT health check below.