Business Continuity Plan for SMBs: Structure, Template, and Common Mistakes
Daniel Sarica
Published: May 13, 2026
This article is about how you build, concretely, a business continuity plan that actually works for a company of 50–150 people. With the structure of every page, the questions you need to ask, and the mistakes I see in 8 out of 10 companies.
How long it should be
15 pages maximum. Ideally 8–10. Any longer and nobody reads it, which makes it useless in practice.
I’ve seen 80-page continuity plans, written by consultants, signed by the CEO, filed in a binder nobody ever opens again. Those are for audits, not for running the company. And in an audit, the fact that nobody in the company can explain what’s in the plan looks worse than not having one at all.
The real plan is short and actionable - a CEO reads it in 15 minutes and understands it completely, and the management team can execute it at 3 a.m. without opening it again.
The plan’s structure, section by section
Section 1: Roles and contacts (1 page)
The list of people with a role in an incident, with name, cell phone, and a personal backup email (in case company email is down).
- CEO (final decisions, major external communication)
- Internal IT manager or IT point of contact
- External IT provider (company name, contact person, direct number)
- The cybersecurity firm / MSSP you have an incident response contract with (if you have one)
- Attorney (for legal breach notifications - every US state has its own law)
- Cyber insurance carrier (if you have a policy)
- CISA and the FBI (CISA’s 24/7 line: 1-844-SAY-CISA; cybercrime reports: ic3.gov)
Next to each name, in 1–2 sentences: what decisions that person makes during an incident.
Printed. On executives’ phones. In a personal Drive. NOT on the company network, because the network can be down exactly when you need the plan.
Section 2: Critical systems and impact (2–3 pages)
For each critical system, a mini-file with:
- The system’s name and what it does for the company (in business language, not technical)
- Vendor and direct contact
- How long the company can operate without it (in hours or days, concretely)
- Estimated loss per day of downtime (in dollars)
- Temporary workaround (how we operate without it if it goes down)
- Recovery plan (how we come back, who does what)
The typical systems for a 100-person company: ERP, email, the file share / network drive, phones, internet, the access system (for getting into the building), the payments/banking system. Manufacturing companies add the OT systems - the production line, the control systems. B2B services companies add the CRM and client communication platforms.
Important: don’t copy a generic template. Your list is specific to your company. What’s critical for a food manufacturer (the traceability system) is irrelevant for a consulting firm.
Section 3: Scenarios and response (3–4 pages)
This is the part missing from 80% of the plans I see. Four or five concrete scenarios, each with steps to follow.
Scenario 1: Ransomware attack - systems are encrypted
- In the first hour: isolation. Who decides. What gets shut down (disconnecting from the internet, stopping the VPN, isolating affected systems).
- In the first 4 hours: assessment. Who calls the incident response firm. What data we collect before touching anything (forensics - the evidence is lost if you restart systems).
- In the first 24 hours: notifications. Your cyber insurance carrier, your attorney (who determines which state breach notification laws apply and starts the clock), industry regulators if you’re in a regulated space (HIPAA for health data, GLBA for financial services), affected customers.
- In the first 72 hours: the payment decision. You decided in advance that you don’t pay; here you only reconfirm it.
Recovery: from backup, in critical-system order.
Scenario 2: Major data loss (corruption, accidental deletion)
- Different from ransomware: you don’t need to isolate the network, but you do need to stop operations on the affected system so you don’t overwrite the data
- Restore from backup
- Re-enter the data lost between the last backup and the moment of the incident
Scenario 3: Extended outage at a cloud provider
- Microsoft 365 or Google Workspace goes down for a few hours
- How we communicate without email
- What the priorities are for the first 4 hours
- Who stays in touch with key clients
Scenario 4: Loss of internet or phone service
- Internal backup (LTE/5G as redundancy)
- If an entire area goes down, what we do
- How we communicate internally and with clients
Scenario 5: Data compromise through email (BEC, successful phishing)
- Who resets the affected passwords
- How we check whether emails went out in the compromised employee’s name
- Notifications if customer data was exposed
For each scenario, half a page to a page is enough. More than that means you’re planning for the audit, not for real use.
Section 4: Incident communication (1 page)
- Internal: who informs employees, what gets communicated, through which channel (Slack, Teams, text message, personal email if company email is down)
- To key clients: who calls, what gets said (short template)
- To vendors: who notifies them if we’re unavailable
- Public / press: never an initial statement without the attorney. Decide who speaks if the press shows up.
Short templates for each one. 3–4 sentences. You customize during the incident, but the base is ready.
Section 5: Recovery and return to normal (1 page)
- The order in which systems come back (critical ones first, auxiliary ones after)
- Validation that everything works (how you test that the ERP doesn’t just start, but actually saves data correctly)
- Internal communication that we’re operational
- Post-mortem after 1–2 weeks: what worked, what didn’t, what we change
How you test the plan
An untested plan is a hypothesis. Testing can be simple - there’s no need for elaborate exercises.
Quarterly test: 1 hour, scenario on paper. Everyone in the incident plan gets together. You state a scenario (“it’s Monday morning, IT calls you and says no system will start”). Each person says what they would do in the first 30 minutes. You write down where confusion or disagreement shows up. That’s where the plan needs clarifying.
Semi-annual test: a real simulation on one system. You schedule with IT to shut down a non-critical system for 4 hours on a Thursday. You watch what happens. What doesn’t work? How does the team react? What was planned for and what wasn’t?
Annual test: a complex scenario. A full day. Your external IT provider simulates an attack. You see how you respond. More painful, but this is where the company learns the most.
The common mistakes
The plan exists but it’s generic. Bought as a template, copied from another company, written by a consultant who never spent a day inside your business. It’s not specific to your company. When you need it, it doesn’t help.
The plan is too long. 80 pages. Nobody reads it. During an incident, nobody opens it because they know they won’t find what they’re looking for fast. Useless in practice.
The plan isn’t accessible. Saved on the company network, which is unavailable during the incident. Or in the Drive of someone who’s on vacation. An inaccessible plan = a nonexistent plan.
The plan isn’t tested. It was written 3 years ago. Since then, the company changed its ERP, moved to a different email provider, opened a new office. The plan talks about systems that no longer exist. When you need it, it’s fiction.
The plan is about IT, not about the business. Written in technical language, full of configuration details. The CEO doesn’t understand it. During an incident, the CEO can’t make the decisions the plan expects from them.
The plan has no owner. Nobody is responsible for maintaining it. People change inside the company, the plan stays static. After a year, it’s outdated.
How you keep the plan current
A clear owner: one person (usually the IT manager or the COO) is responsible for maintaining the plan.
Quarterly review: 30 minutes, to check that the contact details are correct, the critical systems listed are still the relevant ones, and the scenarios still apply.
Major annual review: 2–3 hours, after the annual test. What changed in the company over the past year? What new systems do we have? What new vendors? What new management decisions?
Formal annual sign-off from the CEO: it’s not just a formality - it’s how the CEO revisits the decisions made earlier and confirms they still hold.
What building a plan costs
For a company of 80–150 people, building a working plan from scratch takes 2–3 weeks of distributed work. The person responsible invests 10–15 hours. The management team - 2–3 hours in total, for meetings and approvals.
If you work with an external consultant who guides you through the process, the typical cost is $8,000–$16,000 for a plan adapted to your company, plus 1–2 days per year for maintenance and testing.
The average cost of an incident handled without a plan, for the same company: $250,000–$800,000. Plus reputation, lost contracts, plus the impact on a team that has just been through weeks of crisis.
The ratio isn’t close. And yet, in 8 out of 10 mid-market companies I look at, the continuity plan either doesn’t exist or is so generic that it’s useless. That’s not a technical problem - it’s a postponed management decision.
If you want to build a continuity plan for your company
If you don’t have a continuity plan, or the one you have no longer reflects the reality of your company, you can start with a short conversation where we look at your current structure and identify the real priorities.