Disaster Recovery for Small Business: A Practical Plan

Why small businesses need disaster recovery (without the budget for it)

A small business owner called me after an employee accidentally deleted a shared Google Drive folder containing three years of client project files. They had “cloud storage,” so they assumed backups were automatic. Google Drive’s native version history had a 30-day retention limit. The deletion happened 32 days before they noticed. The files were gone. That is the actual disaster risk profile for a small business — not earthquakes and data centers, but a single accidental action and a backup assumption that was never tested.

A disaster recovery plan for a small business is not about preventing catastrophic data center failures. It is about getting back online quickly when your cloud services fail, your account is compromised, or someone accidentally deletes critical data.

Downtime has outsized impact on small businesses. A mid-market company losing email for four hours might lose deals. A five-person company loses payroll processing, customer communication, and momentum. A breach or ransomware attack that takes three days to recover from can destroy customer trust in a way larger companies might survive. You cannot absorb downtime the way incumbents do.

But you also cannot afford the infrastructure redundancy that enterprise organizations maintain. You do not have a second data center. You do not have a dedicated IT team. You probably do not have a budget for annual DR exercises or a full-time person to maintain the plan.

The solution is a small-business DR plan that reflects your actual constraints: it is mostly about data backup, account recovery, and the decision-making procedures your leadership follows when something breaks. It documents what to do in the first hour, the first day, and the first week. It identifies the three to five systems that will break your business if they go down, and it focuses recovery effort there first.

What actually causes disasters at small businesses

Before you build a plan, know the actual risks you face. Small businesses do not fail because of earthquakes or collapses of the power grid. They fail because of:

Ransomware and account compromise. An employee’s password is stolen or phished. An attacker gains access to your main cloud account (Google Workspace, AWS, Microsoft 365). They either encrypt your data for ransom or delete it to extort payment. This is now the most common “disaster” small businesses experience. Recovery requires restoring from backup, changing all credentials, and validating that the attacker no longer has access.

SaaS outage or data loss. Your email provider, CRM, or document storage has an unplanned outage (rare but it happens) or a bug corrupts data. You lose access to email, customer records, or project files. Recovery usually takes minutes to hours if the vendor can fix it, longer if you need to restore from backup.

Human error. An employee with admin access accidentally deletes a shared folder, a database, or an entire user. Restores are usually simple if backups exist, catastrophic if they do not.

Deleted or compromised credentials. Someone leaves the company and you forget to revoke access. Or worse, a major vendor credential (AWS, Google Cloud) is left in source code on GitHub or Slack. An attacker uses it to spin up compute, incur charges, or access your data. Recovery is credential rotation and account audit.

Enterprise disasters (hardware failure, facility loss, regional outages) happen to you too, but they are handled almost entirely by your cloud vendors. Your job is to have a plan for the disasters you can actually cause or experience: data loss, account compromise, and confused response when something breaks.

The small-business DR plan structure

A full disaster recovery plan for an enterprise is 50+ pages. A small-business DR plan should fit on a single page or a short document. It does not need to be formal; it needs to be specific and actionable.

Page 1: Recovery priorities and contact list

List your critical systems and their targets:

Next to this table, list the people who own each system and their out-of-band contact information: personal phone numbers, personal email, a text-based communication channel that does not require your corporate infrastructure. If email is down, you cannot use email to coordinate recovery. If Slack is down, you cannot use Slack.

Page 2: Backup procedures and proof of restoration

For each critical system, document:

• What is backed up? (Customer database, email, documents, accounting records)
• Where is it backed up? (Specific service: AWS Backup, Backblaze, a separate Google Workspace account, an external hard drive)
• How often? (Hourly, daily, weekly)
• How do you restore it? (Specific steps, not “restore the database” but “go to AWS Backup console, select the snapshot from [date], click Restore, wait 15 minutes, validate record count”)
• When was it last tested? (Quarterly or monthly, not “we assume it works”)

The most critical line: for each system, have you actually restored from that backup in the past six months and verified the data is complete and correct? If not, that backup might be corrupted or empty. Backups are worthless unless restoration is tested.

Operator note: The most common small business backup failure is silent: the automated backup job stopped running months ago because of a credential rotation or an API change, and no one noticed because the backup service still shows the account as active. A “backup exists” status in a dashboard is not proof that data is being backed up. Schedule a 30-minute quarterly test — pick one critical system, initiate an actual restore to a test environment, and verify record count. If you cannot restore in the test, you will not be able to restore in the emergency.

Page 3: Attack/incident response procedures

If the disaster is ransomware or account compromise:

1. Identify the compromised account or system.
2. Immediately revoke access: reset the user’s password, deactivate the account, revoke API keys.
3. Check for lateral movement: what other systems or accounts did the attacker access?
4. Isolate backups: verify they are in a separate account and that the attacker cannot delete them.
5. Do not immediately restore. Contact a security professional (even a fractional CISO or incident response service) to confirm the scope of compromise before you restore and risk restoring infected data.
6. Once the attacker is locked out, restore critical systems from backup.

If the disaster is a data deletion or accidental loss:

1. Stop. Do not write new data to the system where data was deleted. The longer you wait, the more likely you can recover deleted files from the backup system.
2. Restore from the most recent backup before the deletion occurred.
3. Identify what data was lost and validate completeness.

Operator note: Small businesses almost always start the ransomware response by trying to restore immediately. This is the wrong sequence. Before restoring, confirm the attacker is no longer in your environment — check what accounts they may have accessed, whether they still have active sessions, and whether any persistence mechanisms were installed. Restoring to a compromised environment means re-infecting from restored data. A 30-minute call with a qualified incident response service before you restore is cheaper than discovering your restored environment is encrypted again 6 hours later.

If the disaster is a vendor outage:

1. Check the vendor’s status page. Is it a known outage?
2. If the outage lasts more than your RTO, begin restore procedures from backup.
3. If the vendor recovers and you are in the middle of restoring, you may need to re-backup from restored systems and fail back to the vendor’s live service.

Page 4: Communication and escalation

When something breaks, who makes decisions? For most small businesses, the owner or a senior manager. Document:

• Who decides whether to activate the DR plan? Usually this is whoever has authority to spend money and disrupt business operations.
• How quickly can you reach them? (Phone number, not email)
• What communication channels work if email is down? (Slack, text, a conference call bridge)
• Who communicates with customers? (If you have customer-facing systems down, who tells customers and how?)
• When do you bring in outside help? (After 2 hours of unresolved downtime? When you do not know what to do? When you are attacked?)

For a small business, this section might be: “Call Nick. If Nick is unreachable, call Sarah. If you cannot reach either, start restoring from backups. Post a status update to Slack every 30 minutes. If downtime exceeds 4 hours, call [incident response service].”

The 3-2-1 backup rule for small business

The 3-2-1 backup rule is a simple checklist:

• 3 copies of your critical data. Example: Salesforce (live copy) + automated backup to AWS Backup (second copy) + monthly export to a USB drive in a physical safe (third copy).
• 2 different storage types or services. Do not back up to another folder on the same cloud service. Use a different service (AWS Backup, Backblaze, Wasabi, or a local drive). The reason: if your cloud account is compromised, the attacker can usually delete backups in the same account.
• 1 offsite copy. At least one backup should be geographically separate from your main operations or in an account you do not use daily. If your main account is compromised, the offsite copy should still be intact.

For a five-person company using Google Workspace and Salesforce, 3-2-1 might look like:

1. Google Workspace: Automated daily backup to a second Google Workspace domain (controlled by your MSP or a backup service like Spanning or Backupify). Monthly export of all email and Drive to an encrypted USB drive.
2. Salesforce: Daily automatic backup via Salesforce backup service (Spanning, Odaseva, or Salesforce’s native backup tool). Store backups in a separate AWS account. Monthly export of all records to CSV, stored locally.
3. Website and code: Source code in GitHub. Website deployed to Vercel or AWS. Vercel or AWS handles replication to multiple geographic regions automatically. Weekly export of any custom data.
4. Accounting data: QuickBooks or Xero with daily automated backup. If using QuickBooks Desktop, nightly backup to an external hard drive stored offsite.

The implementation does not require exotic tools. For most small businesses, automated cloud-to-cloud backup (Spanning, Backupify, Acronis) plus a quarterly or monthly manual export to an encrypted drive is sufficient.

RTO and RPO in small-business terms

RTO (how long you can stay down) and RPO (how much data loss you tolerate) should be set realistically, not aspirationally.

If you cannot afford four hours of email downtime — because you lose customer response time or miss opportunities — your email RTO is 2 hours. That means your backup must be restorable in 2 hours or less. If you back up email weekly to a USB drive, and restoring takes 6 hours, you do not meet your RTO.

RPO is often overlooked. Ask: how much customer or operational data can you lose? For most small businesses, the answer is zero — you cannot lose a customer record. But for logs, analytics, or temporary files, you might tolerate losing 24 hours. That informs your backup frequency: zero-loss systems need hourly or continuous backup; less critical systems need daily.

Document your actual targets, not industry benchmarks:

• Email: RTO 2 hours, RPO 1 hour (hourly backup)
• CRM: RTO 4 hours, RPO 4 hours (daily backup at end of day)
• Website: RTO 8 hours, RPO 24 hours (no customer data, rebuild from source code)
• Accounting: RTO 4 hours, RPO 0 hours (every transaction matters; backup on every transaction)

Once targets are set, choose backup frequency to meet them. Hourly backup is more expensive than daily; set it only for systems where you genuinely cannot tolerate one day of data loss.

Testing without a budget

The most common failure: a business builds a DR plan and never tests it. Six months later, they need to use it, discover the backup is corrupted or the restoration steps are wrong, and lose days recovering.

Testing does not require a consultant or a “DR drill” exercise. Here is what small-business testing looks like:

Quarterly backup restoration test (1 hour, no cost). Pick one critical system. Follow the restoration steps from your DR plan as if the system was really gone. Restore from backup to a test environment or a separate account. Verify the data is complete. If you use a SaaS tool, this might mean: log into the backup console, initiate a restore, wait 15 minutes, check record count. Document the time it took and whether anything was missing. Update the plan if the steps were wrong or took longer than expected.

Annual tabletop exercise (2 hours, no cost). Gather your leadership team and a colleague from IT if you have one. Walk through a disaster scenario: “Our Google Workspace account is compromised and an attacker is deleting emails.” Read through your DR plan. Discuss what you would do at each step. Identify gaps: Can you reach your backup administrator? Do you know the restore procedure? Is the backup still valid? Fix the gaps in your plan.

Incident retrospective (no additional cost). When a real incident occurs — an accidental deletion, a brief outage, a suspicious login attempt — treat it as a test. After the incident is resolved, review what went right and what went wrong. Update your plan and backups accordingly.

These testing activities require no external consultant and cost nothing. They catch real problems: outdated contact information, broken backup systems, and procedures that sound good on paper but fail in practice.

Cloud vs. on-prem: what changes

If you run your own servers or use a hybrid setup (some cloud, some on-prem), your DR plan becomes more complex. You now own infrastructure recovery, not just data restoration.

For a small business with on-prem servers:

• Backup becomes both your responsibility and more critical (no vendor to recover infrastructure for you).
• You need redundancy: a second server or a cloud failover target.
• Recovery time is longer: you cannot provision a new server in minutes the way you can in the cloud.
• You need tested procedures for rebuilding a server from scratch.

The risk: on-prem infrastructure for a five-person company usually means one or two servers, no redundancy, and no one who understands all the systems. Ransomware or a hardware failure becomes catastrophic.

For most small businesses, the answer is: migrate to cloud. It is cheaper than maintaining on-prem infrastructure, more resilient (vendors handle hardware redundancy), and requires simpler DR plans. If you are still running on-prem, work with an MSP (managed service provider) to add cloud backup and to test disaster recovery procedures.

When to call a professional

Build your basic DR plan yourself using this guide. Test it quarterly. You will catch 90% of potential problems.

Call a professional if:

• Your business handles regulated data (healthcare, payment processing, financial records). Regulations often require specific DR procedures, tested recovery times, and documented evidence.
• You have customer-facing uptime commitments (SLAs). If you promise 99.5% uptime, you need to guarantee it with documented recovery procedures and tested failover.
• Your systems are custom-built or complex. If you have in-house applications, legacy systems, or integrations between multiple services, you need help mapping dependencies and validating recovery procedures.
• You have experienced a previous incident and want professional guidance on preventing the next one. An incident response engagement can identify what broke and how to fix it.
• You have more than 50 employees or more than a few critical systems. Complexity increases; so does the value of professional oversight.

For businesses with 5 to 50 employees using standard SaaS, a well-maintained one-page plan plus quarterly testing is usually sufficient.

The one-page DR plan template

Here is the minimal template you can use:

CRITICAL SYSTEMS & CONTACTS

| System | RTO | RPO | Owner | Personal Phone | Backup Location |
|--------|-----|-----|-------|----------------|-----------------|
| [System] | [2 hrs] | [hourly] | [Name] | [###] | [Service] |

COMMUNICATION DURING DOWNTIME
- Decision maker: [Name], [Phone]
- Backup: [Name], [Phone]
- Team channel (if infrastructure allows): [Slack, SMS, call bridge]
- Customer communication: [Who, how]

RESTORE PROCEDURES
- Email: [3-step procedure]
- CRM: [3-step procedure]
- [Add one per critical system]

TESTING SCHEDULE
- Quarterly: Restore one system from backup
- Annual: Tabletop exercise with team
- Last tested: [Date]

ESCALATION
- If downtime > 4 hours and we cannot resolve, call [Incident response vendor]
- Contact: [Phone, email]

Print this. Give a copy to your leadership team. Update it every six months.

Key links for deeper guidance

• Disaster Recovery Plan Template — a comprehensive template for organizations with more complex requirements.
• Data Breach Prevention — before you need disaster recovery, understand how to prevent the breach that triggers it.
• Incident Response Plan Template — when a security incident occurs, the incident response plan activates first; DR follows after containment.
• Business Continuity and Disaster Recovery — if you have operations beyond IT systems (people, facilities, supply chain), integrate that into your broader continuity plan.
• Cybersecurity for Startups — if your business is early-stage, start with foundational controls (backups, MFA, account security) before building a full DR plan.

Summary

A small-business disaster recovery plan is not a consultancy project. It is:

1. A one-page document listing your critical systems, contact information, and recovery steps.
2. An automated backup strategy (cloud-to-cloud, with one offsite copy).
3. A quarterly test that proves you can actually restore from backup.
4. A clear decision about who makes the call to activate recovery procedures.

Build it yourself. Test it quarterly. Update it when systems change. That is what disaster recovery looks like at a company with no IT department.