01
Prioritise the business
Recover the services that keep the organisation operating, not simply the systems that are easiest to restore.
NorthWave Guide · Disaster Recovery · 14 min read
What a Small Business IT Disaster Recovery Plan Should Actually Contain.
A practical framework for deciding what must be recovered, how quickly it matters, what backups need to exist, who does what and how you prove the plan works.
A disaster recovery plan is not simply a list of backup products. It is a practical agreement about how a business will restore important technology and data after something has gone seriously wrong.
For a small business, the trigger might be ransomware, accidental deletion, a failed server, a lost laptop, a damaged office, a cloud-service problem, a compromised administrator account or a supplier outage. The event changes; the planning principles remain similar.
This NorthWave guide focuses on the IT side of recovery: what needs to be identified before an incident, what should be documented, what recovery order makes sense and how to test the process without waiting for a real disaster.
The key idea
A backup is a copy of data. A recovery plan explains what to restore, in what order, using which people and systems, and how you know the restored environment is safe to use.
The recovery framework
A useful plan answers 12 practical questions.
The following structure is designed to be understandable by a business owner as well as the person responsible for IT.
Priority 1
Know what must return
Critical systems, people, data and dependencies come first.
Priority 2
Protect the recovery path
Backups, administrator access and recovery credentials must survive the incident.
Priority 3
Prove it works
Test restoration, record failures and improve the plan.
1
Define the scenarios the plan is meant to cover.
Start with realistic events: ransomware, accidental deletion, lost or stolen devices, hardware failure, office damage, internet or power disruption, cloud-service problems and loss of a key administrator account.
2
Identify critical systems and business processes.
List the systems the business cannot operate without, such as Microsoft 365, finance, customer records, line-of-business applications, telephony, websites, file storage, production systems and authentication.
3
Assign a recovery priority.
Do not restore everything at once. Decide what enables the next business process. For example, identity and connectivity may need to return before users can access applications or data.
4
Set a realistic Recovery Time Objective (RTO).
RTO is the target time within which a service or process should be restored. It should reflect the actual business impact of downtime, not an arbitrary technical target.
5
Set a realistic Recovery Point Objective (RPO).
RPO describes how much recent data the business could afford to lose. A system with an RPO of four hours needs a recovery approach that can realistically provide a usable copy within that tolerance.
6
Document what is actually backed up.
Record the data, configurations and systems covered, the backup frequency, retention period, storage locations and who owns the backup service. Do not assume that because something is in the cloud it is automatically covered by an independent recovery strategy.
7
Protect backups from the same incident.
Recovery copies need appropriate separation and access controls. Consider offline or segregated copies, version history and protections against unauthorised deletion or modification.
8
Record the people and credentials needed to recover.
Document who can contact the IT provider, backup provider, hosting company, telecoms supplier and other critical vendors. Make sure emergency access is available without depending on a single unavailable employee.
9
Document the recovery sequence.
Write the order of operations in plain language: contain the incident, establish a clean recovery environment, restore identity and core services, recover data and applications, validate systems, then return users to normal operation.
10
Define how you verify a restored system is safe.
A successful restore is not enough. Check that systems are clean, accounts are controlled, security updates are applied and important business functions work before declaring recovery complete.
11
Test the plan and record the result.
Run practical restore tests and tabletop exercises. Record what took longer than expected, what information was missing and which dependencies were overlooked.
12
Review and improve it after changes.
Update the plan after major technology changes, supplier changes, office moves, new applications, acquisitions, incidents and recovery tests.
RTO and RPO
Two numbers that make recovery planning practical.
RTO and RPO are useful because they turn a vague statement such as “we need our systems back quickly” into something that can be discussed, costed and tested.
RTO: how quickly should the service return?
If email can be unavailable for a working day without stopping operations, its target can be different from a system that processes orders or controls production. The important point is to agree the business requirement before selecting a technical recovery solution.
RPO: how much recent data can be lost?
If losing the last day's transactions would create a serious problem, a daily backup may not meet the business requirement. RPO should therefore be considered alongside backup frequency, retention and restore capability.
NorthWave recommendation
Write RTO and RPO in business language. “Restore the finance system within four hours and lose no more than one hour of transactions” is more useful than “high availability” because everyone can understand what success means.
Backup design
A recovery plan is only as strong as its recovery copies.
The NCSC advises organisations to back up important data, know how to restore it and regularly test that restoration works. It also highlights the importance of protecting backups from ransomware and maintaining separation or isolation where appropriate.
For a small business, document at least:
- what data and systems are included;
- how often backups run;
- how long versions are retained;
- where copies are stored;
- who can administer or delete backups;
- how a restore is requested;
- how restoration is tested; and
- what happens if the primary backup platform is unavailable.
A 3-2-1 approach is a popular strategy: multiple copies, different storage media or systems and at least one copy offsite. It is a strategy rather than a magic compliance number; the right design depends on the business and the threats it needs to withstand.
Microsoft 365 and cloud services
Cloud does not remove the need for recovery planning.
Cloud services can provide strong availability and built-in recovery features, but a business still needs to understand what data is covered, what can be restored, for how long and who controls the recovery process.
For Microsoft 365 and other cloud platforms, include identity and administrator access in the recovery plan. If an administrator account is compromised or unavailable, the business may struggle to reach the very services it needs to recover.
Also document critical tenant settings, domains, DNS, licensing, key integrations and third-party backup arrangements. Recovery is broader than restoring a file.
People and suppliers
The plan must work when the usual person is unavailable.
A common weakness in small organisations is undocumented knowledge. One person may know the Microsoft 365 administrator account, another may know the backup platform and the IT provider may hold information that nobody inside the business has recorded.
Document named owners, deputies and supplier contacts. Keep the emergency contact information somewhere that remains accessible if normal systems are unavailable.
If IT is outsourced, the recovery plan should state what the provider is expected to do, how the incident is escalated, what information the provider needs and which responsibilities remain with the business.
The recovery sequence
Use a simple order of operations.
Every environment is different, so the exact sequence should be tailored to the business. A useful starting framework is:
01 · Stabilise
Confirm the incident, contain further damage and protect recovery resources.
02 · Establish clean access
Use trusted accounts, devices and recovery information rather than assuming compromised systems are safe.
03 · Restore foundations
Recover identity, connectivity, core infrastructure and other dependencies required by later steps.
04 · Restore business services
Recover applications and data according to the agreed priority and RTO/RPO.
05 · Validate
Check security, data integrity, application function and user access before returning to normal.
06 · Learn
Record what happened and update the plan, controls and documentation.
External guidance
Use the plan alongside trusted UK guidance.
NorthWave's framework is a practical planning guide, not a certification or a substitute for incident-response or legal advice. The UK National Cyber Security Centre provides detailed guidance on preparation, backups, response and recovery.
NCSC Small Business Response & Recovery →Prepare for incidents and plan the recovery process.NCSC Backing Up Your Data →Practical advice on backups and restoration.NCSC Ransomware-Resistant Backups →Principles for protecting recovery copies.NCSC Data Security →Guidance on protecting and recovering important data.
Testing the plan
A recovery plan that has never been tested is still an assumption.
Testing does not have to mean shutting down production. Start with a tabletop exercise: choose a scenario, gather the people involved and walk through what would happen from the first alert to restored service.
Then test the technical pieces that matter most. Restore selected files. Confirm that backup versions are usable. Check emergency administrator access. Rebuild a representative device or system where appropriate. Measure how long the process actually takes.
Record failures without treating them as a sign that the exercise went badly. The purpose of testing is to find weaknesses while there is still time to fix them.
NorthWave test rule
Every test should leave behind at least one written result: what was tested, what happened, what failed or slowed recovery, who owns the fix and when it will be reviewed.
NorthWave view
Recovery is an operating capability, not a backup product.
Buying backup software can be a sensible first step, but it does not answer the wider questions. A business needs to know what matters, how long it can tolerate disruption, what information is required, who can act and how a restored environment will be validated.
The strongest small-business recovery plans are usually the ones people can actually understand. They avoid unnecessary technical language, keep emergency information accessible and are tested often enough that the people responsible know what to do.
NorthWave's approach is to connect recovery planning with everyday IT management: clear ownership, sensible security controls, maintained systems, documented dependencies and tested backups.
02
Protect recovery
Keep backups, credentials and documentation resilient against the same event that caused the outage.
03
Test and learn
Use exercises and restore tests to turn a written plan into a capability the business can rely on.
Continue reading
Related NorthWave guidance.
IT Baseline
The NorthWave Small Business IT Baseline
25 practical checks covering identity, Microsoft 365, devices, email, backup and recovery.
Read the baseline →Microsoft 365
Microsoft 365 Security Review
A practical review framework for identity, administrator access, email, sharing and recovery.
Read the guide →Cyber Security
Small Business IT Security Checklist
Work through practical checks for identity, devices, email, backups and incident readiness.
Open checklist →Need a recovery plan?
Turn recovery requirements into a practical action plan.
If you need help mapping critical systems, recovery priorities, backup arrangements and testing, NorthWave can review the environment and discuss practical next steps.