Not "do we have backups?" — a real plan for what happens next. This guide covers how to prioritise, how to set a recovery time objective that actually means something, and how to test a plan before a real incident does it for you.
Disaster recovery planning goes wrong when it starts with "what backup software should we buy?" Start instead with: if this system disappeared right now, what actually happens to the business? A DR plan is a business continuity document that happens to involve IT — not the other way round.
Email, your main line-of-business application, customer data, your website, payment processing — everything the business genuinely can't function without for more than a few hours.
A system that's annoying to lose is not the same as one that stops the business trading. Rank by real business impact — lost revenue, contractual breach, safety, reputational damage — not by which is easiest to protect.
Worth knowing
Most small businesses over-invest in protecting the system that's easiest to back up and under-invest in the one that would actually put them out of business. The ranking exercise, done honestly, fixes that.
Your Recovery Time Objective is simply: how long can this system realistically be down before it causes serious harm? This single number drives almost every other decision — cheap cold backups are fine for a 5-day RTO; a 1-hour RTO needs a very different (and more expensive) approach.
An RTO of "zero downtime" for everything sounds responsible but is rarely true or affordable. Ask what actually happens at 1 hour, 4 hours, 24 hours, and a week — the honest answer is usually more forgiving than people assume for most systems.
RTO is how long you can be down; RPO is how much data you can afford to lose. Daily backups mean you could lose up to a day of data — is that acceptable for this system?
Worth knowing
RTO and RPO are what turn "we should have good backups" into an actual, fundable, testable plan. Without them, "disaster recovery" stays a vague intention rather than a number someone can be held to.
Once you know how fast each system needs to come back, the right technical approach becomes obvious rather than a guess. Don't buy the same solution for everything — that usually means overpaying for low-priority systems and underprotecting the ones that matter.
Daily automated backup to a separate location is enough. Cheap, low-maintenance, fine for systems that can wait.
Backups alone aren't enough — you need a documented, rehearsed restore procedure so "hours" is realistic rather than optimistic.
For the handful of systems where minutes matter, you likely need active redundancy, not just backup — a genuinely different (and more expensive) architecture.
In a real incident, the person who understands the recovery process best may be on holiday, unreachable, or the actual cause of the problem. A plan that only exists in one person's head is not a plan.
Who has the authority to declare a disaster and start the recovery process? Ambiguity here costs time exactly when time matters most.
Not "restore from backup" — the specific steps: where the backups are, what credentials are needed, what order systems come back in, who to notify and when.
If the plan itself only lives on the server that just went down, or in an email account you can't access, it isn't useful in the moment you need it.
An untested DR plan is a hypothesis, not a plan. Most organisations that discover their backup doesn't actually restore cleanly find out during a real incident — the worst possible time to learn that.
A backup job reporting "success" tells you the copy was made, not that it can be restored. Actually restore a folder, a database, or a full system periodically and confirm it works.
Walk through the plan as a team without touching any real systems: "the file server goes down right now — what do we actually do?" This surfaces gaps in the written plan far more cheaply than a real incident does.
Worth knowing
ISO 27001 and Cyber Essentials Plus both expect evidence that continuity arrangements are tested, not just documented — a dated record of your last test (and what you changed afterwards) is exactly the evidence an assessor asks for.
A DR plan written when you had one system and five staff is not a DR plan for the business you are today. Treat it as a living document, not a one-off exercise.
At least annually, and whenever you adopt a new critical system, change infrastructure providers, or grow significantly.
A real outage — even a minor one — is the most valuable test data you'll get. Feed what you learned back into the plan.
What's the difference between a backup policy and a disaster recovery plan?
A backup policy covers how data is copied and retained — the raw material. A disaster recovery plan covers what happens next: who declares an incident, in what order systems are restored, how long it should take, and how you confirm the business is actually back to normal. You need both, and the DR plan is usually the one that's missing.
Do we need a separate DR plan from our incident response plan?
They overlap but answer different questions. Incident response is about detecting and containing a security incident (is this a breach? who do we need to tell?). Disaster recovery is about restoring operations after any major disruption — a cyber incident, but also a fire, a supplier failure, or a simple hardware failure. Many small businesses combine them into one document, which is fine as long as both sets of questions are actually answered.
How often should we test our DR plan?
At minimum, annually, plus a real restore test whenever you change your backup provider or infrastructure. A full tabletop exercise once a year, with a real file or database restore test more frequently (quarterly is common), catches most of what actually goes wrong.
What RTO is realistic for a small business?
It genuinely varies by system, which is the point — don't set one RTO for everything. Email and file storage can often tolerate 24 hours for most small businesses; whatever system directly generates revenue or fulfils orders usually can't. Set the number per system based on real business impact, not a guess.
Fortify's free assessment baselines your backup and recovery posture in about 10 minutes. In the portal, the Continuity Builder drafts a tailored recovery plan from a plain-English description, and the Recovery Objectives and Testing areas turn each step here into a tracked target with an owner and a due date.