How to Write a Disaster Recovery Plan for a Small Business

Most small businesses do not have a disaster recovery plan. They have backups – maybe – and an assumption that someone will figure it out if something goes wrong. That assumption is what turns a manageable incident into a week-long crisis. The difference between a business that recovers from a server failure in hours and one that struggles for days is almost never the technology. It is whether someone wrote down what to do before the emergency happened.

A disaster recovery plan does not need to be a 40-page document. For a small business, it needs to answer six questions: what systems are critical, who is responsible for recovery, what is the recovery order, how do you actually restore each system, who do you call, and how do you communicate with staff and clients during the outage. If you can answer those six questions on paper before something goes wrong, you are ahead of the vast majority of small businesses.

What a disaster recovery plan actually is

A disaster recovery plan is a documented set of procedures for restoring your IT systems after an incident. The incident could be a server failure, ransomware, a fire, a flood, a power outage, or anything else that takes your systems offline.

The plan is not a backup strategy. You need a backup strategy to have a recovery plan, but they are different things. Your backup strategy defines where your data is stored and how often it is copied. Your recovery plan defines what you do with those backups when you need them – in what order, by whom, and how.

The plan is also not a business continuity plan. Business continuity covers how the business keeps operating while IT systems are down – can staff work from home, can you take orders manually, can you access client information through alternative means. Business continuity is the broader question. Disaster recovery is specifically about getting the IT systems back.

Section 1: Critical systems inventory

The first section of your plan lists every system your business depends on, ranked by how critical each one is. This is the foundation everything else builds on, because you cannot prioritize recovery if you do not know what needs recovering.

For each system, document:

• System name and description. What it is and what it does.
• Where it runs. On-premises server, cloud service, hosted application.
• Who depends on it. Which departments or roles cannot work without it.
• RTO. How long can this system be down before it seriously hurts the business.
• RPO. How much data loss is acceptable for this system.

If you have not defined your RTO and RPO for each system, do that first. Those two numbers drive every decision in the plan.

A typical small business critical systems list looks something like this:

Priority	System	RTO	RPO
1	Email (Microsoft 365)	2 hours	4 hours
2	Line-of-business application (EHR, accounting, CRM)	4 hours	1 hour
3	File server / SharePoint	4 hours	24 hours
4	Phone system	4 hours	N/A
5	Internal tools (project management, wiki)	8 hours	24 hours
6	Website	8 hours	24 hours

The priority ranking determines recovery order. When everything is down, you do not restore everything at once. You restore priority 1 first, then priority 2, and so on. Getting email back in 2 hours while the wiki takes a day is acceptable. Getting the wiki back while email is still down for a day is not.

Section 2: Recovery team and responsibilities

Your plan needs to name specific people, not roles. “The IT person will handle recovery” is not a plan. “Sarah Chen (IT Manager, 555-0142, [email protected]) leads recovery. If Sarah is unavailable, Mike Torres (Office Manager, 555-0187, [email protected]) contacts Sequentur at 555-0200” is a plan.

Document for each person:

• Name and role
• Phone number (personal cell, not office phone – the office phone might be down)
• Email (personal email as backup – company email might be down)
• What they are responsible for during recovery
• Who backs them up if they are unavailable

For a small business, the recovery team is usually three to five people:

• Recovery lead. Makes decisions, coordinates the effort, communicates status. Usually the IT person or the person who manages the IT relationship.
• Executive decision-maker. Authorizes spending, makes business decisions during the incident (shut down operations vs. work manually, notify clients or wait, engage outside help). Usually the business owner or a senior manager.
• Communications lead. Handles staff and client communication during the outage. Updates the team on recovery progress. Usually an office manager or operations person.
• IT provider contact. If you use a managed service provider, their emergency contact information and the process for initiating emergency support.

Section 3: Vendor and service provider contacts

When your systems are down, you need to reach your vendors fast. Searching for a support phone number while the business is offline is wasted time.

List every vendor that touches your IT infrastructure:

Vendor	Service	Support contact	Account number	SLA
MSP / IT provider	Managed services	555-0200, [email protected]	ACCT-1234	1-hour response
Internet provider	Business internet (and any redundant secondary connection)	555-0300	78901234	4-hour repair
Microsoft 365	Email, file storage	admin.microsoft.com	Tenant: company.onmicrosoft.com	N/A
Backup vendor	Cloud backup	555-0400	BK-5678	N/A
Phone provider	VoIP phone system	555-0500	PH-9012	Next business day
LOB vendor	Accounting software	555-0600	LIC-3456	Email support

Include login credentials or a reference to where credentials are securely stored (password manager, sealed envelope in a safe). Do not put passwords directly in the DR plan document if it is stored digitally – reference the secure location instead.

Section 4: Backup configuration summary

Your plan needs to document your current backup setup so that anyone executing the plan knows where the backups are and how to access them. This section should answer:

• What is being backed up? List every system and data set.
• Where are the backups stored? Local appliance location, cloud provider, account details.
• How often do backups run? Daily, hourly, continuous – for each system.
• How long is backup data retained? 30 days, 90 days, 1 year.
• How do you access the backup system? Admin URL, credentials (reference to secure storage).
• When was the last successful test restore? Date and what was tested.

If your backup follows the 3-2-1 rule, document all three copies: the production data, the local backup, and the offsite/cloud backup. If it does not follow the 3-2-1 rule, this section of your plan will make that gap obvious, which is useful information.

Section 5: Step-by-step recovery procedures

This is the core of the plan – the actual procedures someone follows to restore each critical system. Write these for the person who will execute them, which might not be the person who set up the systems.

If you have a managed service provider, they may already have procedures for some of these systems. If you have been through a ransomware incident, the recovery steps you followed (or wished you had) are a starting point for this section.

For each critical system, document:

Assessment

• How to determine if this system is affected
• How to check if the backup for this system is intact
• Decision criteria: restore from backup vs. rebuild vs. contact vendor

Recovery steps

Write the actual steps. Be specific enough that someone who is not the primary IT person can follow them under stress. Example for a server restore from a local backup appliance:

1. Verify the backup appliance is operational and accessible at [IP address]
2. Log into the backup management console at [URL] with credentials from [secure location]
3. Navigate to the server backup for [server name]
4. Select the most recent clean backup point (verify the timestamp predates the incident)
5. Initiate a full restore to [target – original hardware / new hardware / virtual machine]
6. Estimated restore time: [X hours] for [X GB] of data
7. After restore completes, verify [specific services] are running
8. Test [specific functionality] to confirm the system is operational
9. Notify the recovery lead that this system is back online

Validation

• What to check after restore to confirm the system is working
• Who to notify when this system is back online
• Any post-restore steps (repoint DNS, update configurations, reconnect dependent systems)

You do not need procedures this detailed for every system. Cloud services like Microsoft 365 rarely need an infrastructure restore procedure because Microsoft handles that, though you still need a plan for restoring M365 data from your third-party backup if mailboxes or files are compromised. But for on-premises servers, line-of-business applications, and anything with a local component, documented steps prevent guesswork during a crisis.

Section 6: Communication plan

When your systems go down, people need to know what is happening. Staff need to know whether to come to the office, work from home, or wait for updates. Clients need to know if their deliverables are affected. Your communication plan defines who communicates what, to whom, and through which channels.

Internal communication

• Initial notification. Who tells staff that systems are down, through what channel (personal cell phone group text, WhatsApp group, personal email list – not company email or Slack, which might be down).
• Status updates. How often (every 2 hours during active recovery), through what channel, from whom.
• Work instructions. Can staff work from home? Should they come to the office? Are there manual processes they should switch to?
• Recovery notification. Who announces that systems are back and what to expect (data that may be missing, things that need to be rechecked).

External communication

• Client notification. If the outage affects client deliverables or access, who contacts them and what the message says. Have a template drafted in advance.
• Vendor notification. Which vendors need to know about the incident (especially if it affects shared systems or integrations).

Communication templates

Draft two or three short templates in advance:

Initial outage notification (internal):

“We are experiencing a system outage affecting [email/file access/specific application]. The IT team is working on recovery. Current estimate for restoration is [X hours]. Please [work instructions]. Updates will be sent every [2 hours] via [channel].”

Client notification (if needed):

“We are experiencing a temporary IT disruption that may affect [specific service/deliverable]. We expect to resume normal operations by [time/date]. Your data is secure. We will update you when systems are restored.”

Having these templates written before an incident saves time and prevents poorly worded communications sent under pressure.

Keeping the plan current

A disaster recovery plan that was written two years ago and never updated is better than nothing, but not by much. Systems change, people leave, vendors change, and backup configurations evolve. A plan that references a server you decommissioned last year or a contact who left the company six months ago has gaps that will surface during an incident.

Review the plan quarterly. Pair this with a quarterly review of your backup configuration against the 3-2-1 rule – a plan that references a backup that no longer meets your needs is not much better than no plan. A 15-minute review every three months catches most drift:

• Are all contact names and phone numbers current?
• Have any critical systems been added or removed?
• Has the backup configuration changed?
• Have any vendors changed?

Update the plan after any infrastructure change. New server, new backup system, new cloud service, new IT provider – any of these should trigger a plan update.

Update the plan after any incident. If you use the plan (or wish you had one when something went wrong), update it with lessons learned while they are fresh.

Who owns the plan

Someone specific needs to own the disaster recovery plan. Not “the IT department” or “whoever handles IT.” A named person who is responsible for keeping it current, ensuring it is accessible during an emergency, and running periodic reviews.

For small businesses without dedicated IT staff, this is often the business owner or the office manager who handles the IT relationship. If you work with a managed service provider, ask whether plan maintenance is part of their service. Businesses that use Backup as a Service (BaaS) often get DR plan maintenance bundled with the backup management, since the provider already knows the backup configuration intimately. At Sequentur, DR planning and documentation is part of how we manage client environments – we build the plan, keep it current, and execute it when needed.

The cost of backup and disaster recovery is modest compared to the cost of an unplanned recovery – having a plan that reduces recovery time by even a few hours can save tens of thousands of dollars in downtime.

The plan itself needs to be stored somewhere accessible during an emergency. If it only exists on the file server that just failed, it is useless. Keep copies in at least two locations: a cloud location (SharePoint, Google Drive, or the provider’s documentation system) and a physical copy (printed and stored in a known location – the office manager’s desk, a fireproof safe, or with the business owner).

What your plan does not need to be

A disaster recovery plan for a 20-person business does not need to be a 40-page document with appendices and revision history. It needs to be accurate, accessible, and actionable. Five to ten pages covering the six sections above is sufficient for most small businesses. The goal is a document that someone can pick up during a crisis and use to make decisions and execute recovery, not a compliance artifact that sits in a drawer.

If writing the full plan feels overwhelming, start with just the critical systems list and the contact information. Those two sections alone put you ahead of most small businesses and give you a foundation to build on.

If you want help building a disaster recovery plan for your business, or if you have a plan that has not been tested or updated recently, reach out through our contact page. We can help you document your recovery procedures, identify gaps in your backup infrastructure, and make sure the plan actually works before you need it. A plan that is actually executable typically sits on top of a real backup and disaster recovery service, not on best-effort internal processes.