Infrastructure
What Belongs in Your Business's Written Disaster Recovery Plan
Good backups answer whether your data can be restored. A disaster recovery plan answers what your team actually does, in what order, once something has already gone wrong. This checklist covers the roles, contacts, communication templates, and failover steps the document itself needs, and how testing the plan differs from testing a backup.
Good backups answer one question: can the data be restored. A disaster recovery plan answers a different one: what does your team actually do, in order, starting the moment a server room floods, a ransomware attack locks every workstation, or the building loses power for three days. Most small businesses have an answer to the first question and nothing written down for the second, which is why recovery often takes far longer than the technology alone would suggest.
This is a checklist for the document itself: what a disaster recovery plan should contain, independent of which backup product or cloud platform sits behind it.
A Backup Is Not a Plan
Backups and a disaster recovery plan solve different problems. A backup is a technical control that preserves data. A plan is an operational document that tells people what to do with that data and everything around it once something has already gone wrong.
Without a written plan, a real incident runs on improvisation. Someone has to figure out, under pressure, which systems matter most, who is allowed to make the call to fail over to a backup site, who tells employees to stay home or log in from a different location, and who calls the insurance carrier before anyone touches the compromised network. Figuring all of that out for the first time during the actual event is slower and more error-prone than following a plan written when nobody was panicking.
What the Written Plan Should Actually Contain
A usable plan is short enough that someone will actually read it during an incident, and specific enough that it does not require guessing. At minimum, it should cover the following.
1. A system and data inventory, ranked by recovery order. List the servers, applications, and data sets the business depends on, and decide in advance which ones come back first. Not everything can be a top priority; the point of ranking is forcing that decision ahead of time instead of during the outage. Pair each system with a recovery time objective and recovery point objective, the targets for how fast it comes back and how much data loss is tolerable. Our guide to backup testing covers how to set and verify those two numbers in more depth.
2. Named roles, not job titles that happen to be busy elsewhere. Decide in writing who has the authority to declare an incident a disaster and trigger the plan, who leads the technical recovery, and who owns communication. If the usual decision-maker is unreachable, name a backup person for each role.
3. A contact sheet that does not depend on the systems that might be down. Internet and cloud provider support numbers, your backup and IT vendor's emergency line, your cyber insurance carrier's incident hotline, and legal counsel if the incident involves a data breach. Keep this list somewhere that does not require the network to be up to read it.
4. Draft communication templates. A short, pre-written notice to employees and a separate one to customers, with blanks for the specifics, save real time over composing one from scratch while the business is still figuring out what happened.
5. Alternate operations for the systems people lean on without thinking about them. Where staff work if the office is unavailable, how office phone calls reroute if your VoIP provider or internet circuit is down, and which connection carries the business if the primary one fails.
6. Instructions for where the plan itself lives. A disaster recovery plan stored only as a file on the file server it is supposed to help recover is a plan nobody can open when it matters most. Keep a printed copy and an electronic copy stored outside the environment the plan covers.
Test the Plan, Not Just the Backup
Restoring a file from backup proves the data is recoverable. It does not prove that the people involved know their roles, that the contact sheet is current, or that the plan's assumptions still match how the business actually runs today. Ready.gov's business continuity planning guidance lays out planning as a six-step process that ends with testing, not with writing the document and filing it away.
A tabletop exercise is the practical version of that step: gather the people named in the plan, walk through a specific scenario out loud, such as a ransomware incident discovered on a Monday morning, and see whether the plan actually answers the questions that come up. Run this at least once a year, and again after any major change to your systems, staff, or vendors. Combine it with the technical restore testing described in the backup testing guide above; one confirms the data, the other confirms the people.
How Cyber One Solutions Helps
Our backup and disaster recovery services cover the technical side, including immutable backups and recovery objectives. Try our backup and disaster recovery self-assessment for a quick, private readiness score on where your current setup stands. Where the plan depends on failover connectivity or phone routing, that work runs alongside our managed internet and VoIP services rather than as a separate project. If your business does not have a written plan yet, or has one nobody has looked at since it was created, contact us and we will review what you have or help you build one your team could actually follow.
Frequently Asked Questions
What is the difference between a backup and a disaster recovery plan?
A backup is a copy of your data that can be restored. A disaster recovery plan is the written document describing who does what, in what order, and through what alternate arrangements, from the moment an incident is declared until normal operations resume. You need both; one without the other leaves either no data to recover or no clear way to recover it.
Who should be responsible for declaring a disaster and running the response?
Name specific people in the plan itself, not just job titles, along with a backup person for each role in case the usual decision-maker is unreachable. At minimum, assign someone with the authority to declare the incident and trigger the plan, someone to lead the technical recovery, and someone to own communication with staff and customers.
How often should a disaster recovery plan be tested?
Run a tabletop walkthrough of the plan at least once a year, and again after any significant change to your systems, staff, or vendors. This is separate from, and in addition to, the technical restore testing covered in our backup testing guide, which confirms the data itself is recoverable.
Where should the disaster recovery plan be stored?
Somewhere it can be reached without the systems it is meant to help recover. Keep a printed copy and an electronic copy stored outside the environment the plan covers, such as a cloud folder independent of your primary file server, so the plan is not the first casualty of the outage it describes.