Business Continuity Plan for Small Business: 8 Steps

A business continuity plan for small business is a short, practical document that explains how your company keeps selling, collecting payments and serving customers when something critical stops working: email, your order system, a cloud provider, the office internet connection or the one person who knows how everything runs. Boiled down, it answers four questions: which processes can't stop, how long each can stay down, what you do in the meantime and who makes the call.

This guide is for owners and managers who run on cloud tools and have never written a formal plan. You'll get the steps, a priority table, a worked example and a checklist you can use this week.

What is a business continuity plan (and what isn't it)?

A continuity plan is not a backup. Backups protect your data; a continuity plan protects your operations. You can have every invoice safely copied and still lose a full day of sales because nobody knows how to reach customers when the usual channel is down.

It also isn't only for hurricanes and fires. For a company that runs on software, the most common disruptions are mundane: a SaaS vendor goes down, an admin password nobody can recover, an update that breaks label printing, or a payment integration that stops responding.

A useful plan answers concrete questions:

• Which processes bring in or protect revenue and can't be down for more than a few hours?
• Which systems, vendors and people does each one depend on?
• What's the workaround if that system fails?
• Who declares an incident, who talks to customers and who decides when you're back to normal?

Why do you need one if everything is in the cloud?

Moving email, files and your CRM to the cloud removes a lot of risk, but it doesn't remove dependency. It hands it to a vendor. This week made that obvious. According to myITforum's weekly roundup, Microsoft 365 had a major outage that started on November 12, 2026 and stretched into a second day, hitting Outlook hardest and also affecting Teams, Copilot, SharePoint, Intune and other services across 74 countries.

NewsMobile reported that Downdetector logged nearly 130,000 Outlook problem reports shortly after 1 p.m. EST, and that scammers moved fast with fake emails asking users to "verify" accounts or offering outage refunds. In other words, a technical outage quickly turns into a security problem too.

The useful question isn't whether your vendor will fail again. It's what your team does during those hours. The businesses that got through it calmly didn't have better technology. They had an agreed backup channel, a list of customers to notify and someone with the authority to say, "Here's how we operate until this is fixed."

How to create a business continuity plan in 8 steps

Frameworks like NIST's contingency planning guide, SP 800-34, are written with large organizations in mind. For a small or midsize company, this condensed version covers what matters without becoming a months-long project.

1. List your critical processes. Start with anything that touches money or customers: taking orders, getting paid, invoicing, shipping, handling complaints, running payroll. If a process can wait a week without consequences, it isn't critical.
2. Map each process's dependencies. Write down the system it uses (email, ERP, online store, messaging, banking), the vendor behind it and the people who know how to run it. This is where surprises show up, like a key process that lives in a spreadsheet on one person's laptop.
3. Decide how long each process can be down. That's your recovery time objective (RTO). Then decide how much recent data you can afford to lose, your recovery point objective (RPO): an hour of orders? A day?
4. Design a workaround. For every critical process, write Plan B in plain language: a second communication channel, a manual order form, an alternate way to take payment, an offline copy of the price list.
5. Assign roles and a decision chain. One person declares the incident, another handles customer communication, another works with the vendor. Name a backup for each role.
6. Write the messages before you need them. Draft templates for customers, partners and staff, and agree on which channel you'll use if company email is down.
7. Store the plan outside the systems that can fail. If the plan only lives in SharePoint and SharePoint is down, you don't have a plan. Keep a printed copy and one in a separate service.
8. Test it and keep it current. Run a short tabletop exercise at least once a year: "Email went down at 10 a.m. What do we do?" Update the plan with what you learn and every time you change a major system or vendor.

RTO and RPO: how long can each process be down?

These sound like IT jargon, but they're business decisions. RTO is how long you can wait before a process works again. RPO is how much recent information you're willing to lose. IT shouldn't set them alone; the people who understand the impact on revenue and customers should.

Here's an example of how to prioritize. The time frames are illustrative; every business needs to set its own.

Process	Main dependency	Priority	Tolerable downtime (example)	Plan B
Taking orders	Online store, CRM	High	A few hours	Manual order form and an alternate support channel
Collecting payments	Payment gateway, bank	High	A few hours	A second payment method already set up
Customer communication	Company email	High	Less than a day	Phone or business messaging with ready-made templates
Invoicing	Billing system	Medium	One to two days	Log of sales waiting to be invoiced
Internal reporting	BI tools, spreadsheets	Low	Several days	Wait for recovery

The classic mistake is marking everything "high." If everything is a priority, the plan can't tell you where to spend your energy in the first few hours.

Business continuity plan example: when email goes down

Take this week's scenario. A distributor receives orders by email, confirms them by email and sends invoices by email. Without a plan, outage day looks like this: nobody knows whether the problem is internal, sales reps keep resending messages that never leave the outbox, and customers call frustrated because they never got a confirmation.

With a plan, the same morning looks different:

• The incident owner checks the vendor's service health page and confirms the failure is on the provider's side.
• They declare the incident and switch to the agreed backup channel (phone and business messaging) using a template message.
• Orders are captured on a temporary numbered form, to be entered in the system once service returns.
• Staff are told not to act on emails asking them to "verify" accounts or promising compensation, because that is exactly when scammers strike.
• When service is back, someone reconciles the temporary orders against the system and closes the incident in writing.

None of this takes a big budget; it takes thinking ahead. Where technology does matter is reconciliation. When processes are scattered across disconnected tools, rebuilding what happened during an outage is slow, manual work. That's where custom software that keeps orders, customers and payments in one place makes recovery much faster.

Common business continuity planning mistakes

• Treating it as a backup policy. Copies of your data don't tell anyone how to serve customers while systems come back.
• Letting IT write it alone. Without sales, billing and operations at the table, the plan describes servers, not the business.
• Single points of failure in people. If one person holds the admin credentials or the vendor relationship, the plan fails the day they're out.
• No real alternate channel. Many companies get email, chat and file storage from the same vendor. When it goes down, all three go with it.
• Never testing it. Untested plans tend to have outdated phone numbers, expired access and steps nobody understands.
• Forgetting the website. Your site is the natural place to post a status notice when other channels fail. Make sure your business website lets you publish an update in minutes.

Business continuity plan checklist

Use this to check whether your plan is ready. If you answer "no" to more than three items, start there.

• We have a written list of critical processes, ranked by priority.
• Each critical process has its dependencies identified: system, vendor and people.
• We've set tolerable downtime and acceptable data loss for each one.
• Every process has a Plan B written so anyone on the team can follow it.
• There's an owner and a backup for declaring an incident and for communications.
• Customer message templates and an alternate channel are agreed on.
• Admin credentials and vendor support contacts are securely accessible to more than one person.
• A copy of the plan lives outside the systems that could fail.
• We've run at least one exercise in the last twelve months.

If this exercise shows that your critical processes are spread across too many tools or depend on manual work, we can help you review it. Get in touch and we'll walk through it with your team.

Frequently asked questions

What should a small business continuity plan include?

At minimum: your critical processes, their dependencies, how long each can be down, the workaround for each, who is responsible and your communication templates. It should also say where the plan is stored and how often it's reviewed.

What's the difference between a business continuity plan and a disaster recovery plan?

A disaster recovery plan focuses on restoring systems and data. A business continuity plan is broader: it covers how the company keeps operating while that recovery happens, including people, customers and vendors.

Does a small business really need a business continuity plan?

Yes, and small businesses are often more exposed than large ones because they rely on fewer people and fewer vendors. You don't need a thick binder; a few clear, tested pages beat a manual nobody reads.

How often should you update a business continuity plan?

Review it at least once a year and whenever you change a major system, vendor or the people in key roles. A short tabletop exercise is the fastest way to find what's out of date.