Enterprise business continuity planning frameworks produce 150-page documents with recovery team org charts, alternate site agreements, and supply chain continuity annexes. Most small businesses don't need 150 pages. They need to be able to answer five questions under pressure.
The goal isn't a comprehensive BCP document. It's knowing what happens to your business when something breaks.
The Five Questions Your Plan Needs to Answer
1. Which systems and processes, if unavailable, would cause unacceptable business impact?
This is your Business Impact Analysis — scaled down. For most SMBs, the critical functions are: customer-facing operations, payment processing, access to client data, email and communication. You're not mapping every system; you're identifying the handful that, if down for more than a few hours, cause real harm.
2. How long can each critical function be offline before the harm becomes serious?
This is your Recovery Time Objective (RTO) — the maximum tolerable downtime for each function. Be honest. "We need email back within 2 hours because that's how we communicate with clients" is an RTO. "We'd prefer email to be back quickly" is not. RTOs drive prioritization during recovery: you restore the highest-priority function first, not the easiest one.
3. How much data can you afford to lose?
This is your Recovery Point Objective (RPO) — how far back can you roll before the data loss is unacceptable? If your accounting system backs up nightly and the system fails at 4pm, you lose a day's work. If that's tolerable, your RPO is 24 hours. If it isn't, your backup frequency needs to change.
4. Do your backups actually restore?
Having backups and having working backups are not the same thing. Most small businesses have a backup solution. Too many of those businesses have never tested a full restoration. Backup testing — restoring data from backup to a test environment and verifying it's usable — should happen at least quarterly for critical systems.
If your backup system has never been tested, the answer to "do your backups actually restore" is "you don't know." That's the most important gap to close.
5. What happens when your primary IT contact isn't available?
Many small businesses have one person who knows how everything works. If that person is unavailable during an incident — on vacation, sick, or the subject of an insider threat investigation — how does the business recover? Who has the credentials? Where is the documentation?
This is the key-person dependency problem. It's not solved by a document; it's solved by knowledge transfer, documented runbooks, and credential management that isn't locked to one person's head or personal password manager.
The Ransomware Scenario
Ransomware is now the primary BCP trigger for small businesses. It's worth planning for explicitly rather than treating it as an edge case.
What ransomware looks like in practice: you arrive Monday morning and discover that your file server, your QuickBooks installation, and your shared drives are encrypted. A ransom note instructs you to contact an address for decryption keys. Your backups are on a network share that was also encrypted.
Your BCP needs to address this scenario directly:
Day 1: Don't reboot affected systems. Preserve them for forensic analysis. Identify what's encrypted and what isn't. Check backup integrity — if backups are on the same network, they may also be encrypted. Call your cyber insurance carrier. Engage legal counsel. Determine what operations can continue on unaffected systems.
Day 2-3: Assess whether you have clean backups to restore from. If not, evaluate whether paying the ransom is even an option (no guarantee of decryption, re-infection risk, potentially illegal in some contexts). Determine how long you can operate in degraded mode. Communicate to clients if their data or services are affected.
Day 5-7: Begin restoration from clean backups if available, or consider rebuilding from scratch. Harden the rebuilt environment before re-connecting to the network.
After: Post-incident review. Root cause analysis. What allowed the initial compromise? What allowed the attacker to move laterally to backups?
A BCP that doesn't account for the possibility that your backups are also compromised isn't ready for the most common SMB disaster scenario.
The 5-Page BCP That People Will Actually Use
A business continuity plan that nobody reads is overhead, not protection. The goal is a short, specific document that your key people can follow under pressure:
Section 1 — Critical Systems and RTOs (1 page)
A table: System/Process | Owner | RTO | RPO | Recovery Method
Fill it in for your five to ten most critical functions. This is the prioritization map during recovery.
Section 2 — Backup Summary (half page)
What's backed up, where, how frequently, when it was last tested. If backups are cloud-based, confirm the provider's RTO for restoration.
Section 3 — Key Contacts (half page)
Who to call, in what order, for different scenarios. Include your cyber insurance carrier, external IT support or MSP, legal counsel, and — for regulated businesses — relevant regulatory contacts.
Section 4 — Vendor Dependencies (half page)
Which vendors, if they had an outage, would stop your operations? What's your fallback? Even knowing that "we'd be down if Stripe goes down" is useful — it means you have manual payment processes documented somewhere.
Section 5 — Communication Templates (half page)
Brief templates for: notifying staff that systems are down, notifying clients that services are disrupted, notifying regulators if required.
That's it. Five pages, specific to your business, reviewed annually and updated when things change. This is not a document that impresses auditors with its length — it's a document that works at 7am when the file server is encrypted and the IT contractor is on a plane.
What Business Continuity Is Not
BCP is sometimes confused with disaster recovery, sometimes confused with incident response. They're related but distinct:
Incident Response addresses active security incidents — the detection, containment, and recovery process when a breach or attack is underway. IR is about what you do while the incident is happening.
Business Continuity addresses maintaining or recovering business operations after a disruption — whether that disruption is a security incident, a natural disaster, a power outage, or a key person leaving unexpectedly.
Disaster Recovery specifically addresses IT systems recovery — getting systems, applications, and data back online after a failure.
A BCP that addresses only technology recovery misses the business operations layer. What does your customer service team do if CRM is down for two days? What's the manual workaround? Who calls the customers? Those questions are in the business continuity plan, not the disaster recovery runbook.
SOURCES
- NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems: csrc.nist.gov/publications/detail/sp/800-34/rev-1/final
- FEMA, Business Continuity Planning: ready.gov/business-continuity-planning-suite
- ISO 22301:2019, Security and resilience — Business continuity management systems: iso.org/standard/75106.html
Want help building a business continuity plan that reflects how your business actually operates? Schedule a consultation to talk through what your organization needs.
