A disaster recovery plan (DRP) sets out how a small business keeps its critical systems, data and revenue-generating work running after an outage, flood, fire or cyberattack. The first action, before any document gets written, is to identify your three most critical systems and confirm at least one backup already exists for each, ideally following the 3-2-1 rule. Everything else, including RTO and RPO targets set against NCSC guidance, follows from that.
TL;DR:
- Most small businesses lack a comprehensive asset inventory, backup documentation, and tested recovery procedures crucial for effective disaster response.
- Ransomware-resistant backups require at least one offline or isolated copy, with routine testing to ensure data can be restored before an incident occurs.
- Recovery objectives should be tailored to each system’s importance, with critical functions aiming for a four-hour RTO and a one-hour RPO, and less vital systems having longer targets.
- Regular testing, including quarterly restore exercises and annual full simulations, is essential to verify the plan’s effectiveness and identify gaps early.
- Outsourcing disaster recovery tasks to managed providers can deliver continuous monitoring, proactive backup testing, and clear ownership, reducing reliance on tribal knowledge.
Table of Contents
- What is a disaster recovery plan and how does it differ from business continuity?
- Essential components: a small-business DR plan checklist
- Backups and ransomware-resistant practices
- Setting recovery objectives and prioritising what to restore first
- How to build a usable small-business DR plan step by step
- How often should you test and review your DR plan?
- What does a disaster recovery plan cost, and how does insurance fit in?
- Keeping the plan current: ownership and review triggers
- Publisher perspective: why a managed approach often beats DIY
- How Ctasystems supports your disaster recovery plan
- Where to go for official guidance and templates
- Sources
- FAQ
What is a disaster recovery plan and how does it differ from business continuity?
A disaster recovery plan is the technical rulebook for getting your IT systems, data and applications back online after something breaks them. It focuses narrowly on infrastructure: servers, software, files, phone lines, the till system. The goal is simple. Get the tools your staff need back into their hands as fast as possible, in the right order.
Business continuity is the wider umbrella. It covers everything a DRP does, plus how you keep serving customers, paying staff and managing suppliers while the technical recovery happens. Think of the DRP as the engine room and business continuity as the whole ship, including who talks to customers, where staff work from, and how cash keeps flowing.
Small businesses often blur the two, and that is fine in practice, provided the plan actually gets written down somewhere. What tends to trigger a DRP includes:
- A ransomware attack that encrypts your server or shared drive
- A burst pipe or fire that damages office hardware
- A prolonged power or broadband outage at your premises
- Accidental deletion or corruption of a core database
- Theft of laptops or on-site servers holding customer data
Each scenario demands a slightly different response, but the plan’s job is always the same: know what broke, know what to restore first, and know who does it.
Essential components: a small-business DR plan checklist
A workable DR plan checklist has five moving parts, and most small businesses are missing at least two of them. Here’s what needs to be on paper before an incident, not during one.
- Asset and dependency inventory. List where your data actually lives (cloud storage, local server, a laptop nobody backs up), which suppliers you depend on, and where the credentials to access each system are stored.
- Contact and escalation list. Names, mobile numbers and email addresses for staff, your IT provider, your insurer, your landlord and key suppliers, plus a clear statement of who has the authority to declare an incident and activate the plan.
- Recovery playbooks per critical function. A short, numbered set of steps for restoring each system, with a named owner responsible for that function, not just a general “IT will sort it” note.
- Backup schedule and storage record. Who is responsible for backups, how often they run, and exactly where copies sit, including at least one offline or isolated copy per the NCSC’s small business guidance.
- Activation and incident log template. A simple form to record what happened, when, who was notified and what actions were taken, since this becomes vital for insurance claims and post-incident review.
Pro Tip: Store a printed copy of the contact list and activation steps somewhere other than the office network. If ransomware takes down your systems, the plan describing how to fix them shouldn’t be locked inside them too.
The inventory step catches most businesses out because nobody has mapped which cloud accounts, spreadsheets and supplier logins actually keep the business running day to day. Doing that mapping once, properly, is worth more than any amount of polished formatting on the rest of the document.
Backups and ransomware-resistant practices
The 3-2-1 rule remains the backbone of a resilient backup strategy: keep three copies of your data, on two different types of storage, with one copy stored offsite. For a small business, that might mean your live files, a local network-attached drive, and a cloud backup service, each independent of the others so a single failure or attack cannot wipe out everything at once.

Ransomware specifically hunts for backups. Attackers know that if they can reach and encrypt your backup copies alongside your live systems, you have no choice but to pay. The NCSC’s guidance on ransomware-resistant backups sets out the core defence: at least one backup copy must be offline or otherwise isolated from your everyday network, so malware spreading through your systems physically cannot reach it.
Practical steps that apply even on a tight budget:
- Rotate an external drive offsite weekly, disconnecting it from any network when not actively backing up
- Enable versioning and retention on your cloud storage so you can roll back to a point before an attack, not just the latest (possibly infected) copy
- Use a dedicated backup account with its own credentials and multi-factor authentication, never the same login your team uses for daily work
- Restrict which devices and staff accounts can even see the backup destination
NCSC’s analysis of ransomware incidents found that attackers frequently target backups directly once inside a network, which is why isolation and separate credentials matter as much as the backup itself.
None of this matters if the backup cannot actually be restored. NCSC’s own guidance stresses that testing restores exposes missing credentials and corrupted files long before an incident forces the issue. Schedule an actual restore, not a status check, at least quarterly, and scan the restored files for malware before reconnecting them to your live network.
Setting recovery objectives and prioritising what to restore first
Recovery time objective (RTO) is how long your business can tolerate a system being down. Recovery point objective (RPO) is how much data you can afford to lose, measured in time since the last good backup. Both need setting per critical function, not as one blanket figure for the whole business, because TechTarget’s guidance on RTO and RPO is clear that a one-size target usually overprotects low-value systems and underprotects the ones that matter.
A simple worksheet approach works well for most small businesses. List every system, then assign a tier:
- Tier 1 (revenue-critical): point-of-sale, e-commerce site, accounting software. Typical target: RTO of 4 hours, RPO of 1 hour.
- Tier 2 (operationally important): email, shared drives, internal scheduling tools. Typical target: an RTO and RPO around one day.
- Tier 3 (lower impact): archived records, internal wikis, non-urgent reporting tools. Typical target: an RTO and RPO around one week.
These figures are illustrative starting points, not fixed rules; a busy café’s till system might demand a tighter RTO than a consultancy’s, and yours should reflect what actually stops revenue or customer service.
The tier you assign directly drives cost. A four-hour RTO on your point-of-sale system means near-continuous backups and probably a standby device ready to go. A one-week RTO on archived records means a monthly backup is perfectly adequate. Matching investment to actual business impact, rather than backing everything up identically, is where a limited planning budget stretches furthest.

How to build a usable small-business DR plan step by step
Building a DR plan does not require a consultant or a six-month project. It requires an afternoon, a spreadsheet, and honesty about what actually keeps your business trading.
- Do a rapid crown-jewels assessment. List the systems, data and suppliers that, if lost for a day, would stop you serving customers or getting paid. Flag any single points of failure, such as one supplier who hosts your entire website or a sole member of staff who holds all the passwords.
- Draft the activation section first. Write down what counts as an incident serious enough to trigger the plan, who can declare it, and the first three phone calls that need making. This section gets used under stress, so keep it short.
- Write recovery tasks with named owners. For each critical system, list the concrete steps to restore it and who is responsible. Vague ownership is the single most common reason recovery drags on longer than it should.
- Build three short incident playbooks. A power or broadband outage playbook covers rerouting calls and switching to mobile data. A flood or fire playbook covers evacuating safely, contacting your insurer, and relocating to a reciprocal workspace if one is arranged. A ransomware playbook covers isolating infected devices immediately, not powering them off, and contacting your IT support before touching backups.
- Store the plan securely but accessibly. Keep an editable master copy in cloud storage with restricted access, and a printed or offline copy that survives if your network goes down. Share access credentials with your deputy or IT provider in advance, not during the crisis.
Pro Tip: For the ransomware playbook specifically, write “isolate, don’t shut down” in bold at the top. Powering off an infected machine can destroy forensic evidence your insurer or IT provider needs, and some ransomware behaves differently on reboot.
A fillable template structure that covers most small businesses looks like this: incident classification and activation criteria; emergency contacts with backup numbers; critical systems list with RTO/RPO per tier; step-by-step recovery tasks per system with named owners; the three incident playbooks; and an incident log for recording what happened and when. Copy that structure into a shared document today and you already have a working IT disaster recovery template, even before you fill in every detail.
How often should you test and review your DR plan?
A plan that has never been tested is a guess dressed up as a document. Testing falls into three practical categories for a small business: tabletop exercises, where the team talks through a scenario without touching any systems; restore tests, where you actually pull a backup and confirm it opens correctly; and full playbook walk-throughs, where someone follows the written steps exactly as written to see where they break down.
A workable cadence for most SMEs:
- Monthly: a quick check that backups actually ran and completed without error
- Quarterly: an actual restore test of at least one critical system, ideally to a separate environment away from your live network
- Annually: a full tabletop exercise involving the whole team, walking through at least one incident scenario end to end
Toolkit guidance from bodies such as IBHS recommends testing every six months as a practical minimum for smaller organisations, which is a reasonable floor if quarterly feels ambitious. Document every test result, including failures, since a restore that didn’t work is more valuable information than one that did.
Bring in external IT support when a restore test fails, when the business grows past the point where one person understands every system, or when you’re setting up ransomware-resistant backups for the first time and want the configuration checked properly.
What does a disaster recovery plan cost, and how does insurance fit in?
The real cost of downtime rarely comes from hardware. It comes from lost revenue, staff paid to sit idle, and customers who go elsewhere while you’re offline. Estimating that impact, even roughly, is what justifies the spend on prevention.
Business interruption insurance and cyber insurance cover different gaps, and it’s worth checking both carefully. Business interruption typically covers lost income during physical disruption, such as fire or flood damage to premises. Cyber insurance covers incident response costs, data recovery and sometimes ransom negotiation, though policies vary enormously on what triggers a payout and what evidence they demand.
Low-cost mitigations often deliver more resilience per pound than any insurance premium:
- A reciprocal premises agreement with a nearby non-competing business, letting you use their space temporarily if yours becomes unusable
- Cloud backups configured once and running automatically, rather than depending on someone remembering to plug in a drive
- A small emergency cash reserve to cover the first few days without needing to file a claim
Document any pre-authorised emergency spending limits in the plan itself, so whoever activates it doesn’t need to hunt down sign-off mid-crisis.
Keeping the plan current: ownership and review triggers
A DR plan that sits untouched for two years is worse than no plan, because it gives false confidence. Assign one plan owner and at least one deputy, and store both an editable master copy and an offline emergency copy.
Certain events should trigger an immediate review, not wait for the next scheduled check:
- A key staff member with system access leaves or joins
- A supplier or hosting provider changes
- Any incident occurs, resolved or not
- New software or hardware gets introduced
Beyond that, run a light check every three months and a full review annually, in line with NCSC’s guidance that continuity plans work best as living documents rather than one-off projects.
Pro Tip: Set a recurring calendar reminder tied to a specific date each quarter, such as the first Monday. Plans reviewed “when there’s time” simply don’t get reviewed.
Publisher perspective: why a managed approach often beats DIY
DIY works when your systems are simple and one person genuinely understands all of them. It stops working the moment that person is unreachable during the actual emergency, which happens more often than owners like to admit.
Managed support earns its keep in three ways: continuous monitoring that spots trouble before it becomes an outage, backups that get tested rather than just scheduled, and clear ownership so recovery doesn’t depend on tribal knowledge. A managed provider like SupraITS makes a similar case for smaller firms outsourcing this groundwork rather than carrying it all internally.
— Will
How Ctasystems supports your disaster recovery plan
Writing the plan is the easy part. Keeping backups tested, systems monitored and recovery steps current, every month, without someone chasing it manually, is where most small businesses quietly fall behind. That’s the gap Ctasystems fills, with proactive monitoring that catches issues before they force a recovery in the first place.

Ctasystems’ Backup & Recovery service builds the ransomware-resistant, tested backup setup this article describes, rather than leaving it to a checklist that never gets actioned. The Care Plans wrap that into fixed monthly costs, so there’s no surprise bill when something does go wrong, and Remote Monitoring & Management keeps an eye on the systems your plan marks as critical, around the clock. Getting started can include a risk review of your current setup, a care plan matched to your actual RTO and RPO needs, and a recovery runbook built with your team rather than handed to them. If your backups haven’t been tested this quarter, that’s the place to start.
Where to go for official guidance and templates
For primary sources rather than summaries, consult the NCSC’s ransomware-resistant backup guidance and its small business incident preparation guide, alongside the UK government continuity handbook for practical checklists and quick wins.
Sources
- NCSC: Ransomware‑resistant backups
- UK government continuity handbook: Achieving rapid results and quick wins
FAQ
What should be in a disaster recovery plan?
A disaster recovery plan needs an inventory of critical systems and data, a contact and escalation list, recovery playbooks with named owners, a documented backup schedule, and an incident log. The NCSC’s small business guidance frames this as identifying, prioritising and testing, in that order.
How much does a disaster recovery plan cost?
There’s no fixed figure, since cost depends on how many systems you have and how tight your RTO targets are, but many of the highest-value steps, such as configuring cloud backup versioning or a reciprocal premises agreement, cost little beyond time. Ctasystems’ current service pricing is available directly on its managed IT support page.
What are the four C’s of disaster recovery?
Definitions vary across providers, but a common version covers Communication, Coordination, Continuity and Control, referring respectively to how you notify people, organise the response, keep operations running, and manage decision-making authority during an incident.
What are the five steps of disaster recovery?
A practical five-step sequence is: identify critical systems, assess risk and impact, set RTO/RPO targets per system, build and document recovery playbooks, then test and review regularly. This mirrors the approach NCSC recommends for small organisations preparing for incidents.
