A business continuity plan for a small company

On a Monday morning a twenty-eight-person equipment distributor found the office floor sealed off: a pipe had burst in the unit above overnight, and the building manager closed the floor for three days. Nobody was hurt and nothing burned down. What happened instead was quieter. The order desk moved to personal phones, so half the day's orders existed only as text messages. The pricing exception file lived on one desktop machine behind the taped-off door, so two shipments went out on terms nobody could confirm. A customer who called twice and got voicemail placed the order elsewhere. The company was never in danger. It simply could not read its own business for three days, and paid for it the following month.

A business continuity plan is the act of writing down, in advance, what happens on days like that, instead of hoping someone improvises well. What follows covers how continuity planning differs from crisis management and disaster recovery, why listing consequences beats listing risks, how to identify the processes that are genuinely critical, how to set recovery targets, what outage risk and data-loss risk and key-person risk each look like in practice, the format the plan should take, why a drill is not optional, where this whole approach stops working, and what to do in the first thirty days.

How is continuity planning different from crisis management?

Three ideas get blurred together, and because they blur, none of them gets built. Crisis management is about what gets said after an event: to customers, to the team, sometimes to the public. Disaster recovery is technical; it covers bringing systems, data and access back. Business continuity sits above both and answers one question: while the systems are down, the building is shut or the key person is unreachable, how does the work carry on?

The difference shows up in practice. The recovery side says the database will be back in six hours. Continuity planning answers what happens during those six hours: how orders get taken, what customers are told, whether shipments pause. In most small companies nobody asks the second question, so even when the technical side hits its target, operations lose half a day anyway, and the customer feels that half day rather than the restore.

Count consequences, not risks

Conventional advice starts with a long risk register: fire, flood, power cut, ransomware, supplier failure, illness, a resignation. In a thirty-person company that list reaches forty lines, nobody finishes it, and the document dies in a folder. The faster route runs backwards: skip the causes and list the consequences they produce.

The consequence list is short and rarely exceeds five entries. We cannot get into the building. We cannot reach the systems. We have lost data. The key person is unavailable. The supplier cannot deliver. A fire, a flood and a lease dispute all end in the same place, so writing three separate plans for them is wasted effort. Do not write a fire plan. Write the plan for the first four hours of not having the building. That single page holds up across dozens of unrelated causes, which is exactly why it stays current instead of decaying.

Which processes are actually critical?

The next step is to filter the company's work through one question: what breaks if this stops? A critical process is one that costs money, customers or legal standing when it halts; everything else can wait a week. Teams struggle with this, because everyone considers their own work critical. The tiebreaker that works is blunt: if this were not done at all for three days, would anyone outside the company notice?

The list of yes answers is usually short: taking orders, shipping, invoicing, collections, critical customer support, payroll. The no answers, such as reporting, content production and internal planning meetings, get suspended deliberately during a disruption. Make that call in advance or the day of the incident becomes a scramble in which everyone rescues their own desk and the genuinely critical process gets the least attention.

While counting critical processes, count where the revenue leans as well. In a company where most turnover comes from one account, continuity is a commercial question rather than a technical one; a disruption inside that customer's purchasing process will hurt more than any server failure of yours. How to measure and reduce that dependency is the subject of our piece on customer concentration risk.

How long can we be down, and how much data can we lose?

Two numbers form the backbone of the plan. The first is how long a process can be stopped. The second is how much data you can afford to have lost once you are back. Neither is a technical decision; both belong to whoever runs the business. Saying we cannot lose any data is easy, but once the infrastructure that implies is on the table, most companies conclude that losing half a day of entries will not sink them, and that is a perfectly legitimate call. The bad outcome is never making the call and leaving it to whoever configured the backup. The table below is illustrative; your own numbers will look different.

The moment those targets exist on paper, infrastructure decisions settle themselves. A backup taken once a day cannot serve a two-hour data-loss target; either the target moves or the backup frequency does. Frequency, retention, where the copy lives and how a restore gets tested make up a discipline of their own, and we walk through it step by step in our guide to backup and disaster recovery.

Outage risk: building, connection and supplier

Outages arrive in three common shapes: the building, the connection and the supplier. What they share is that none of them is under your control. On the building, the useful question is not what if there is a fire but who works from where in the first four hours if we cannot reach the door tomorrow. On connectivity, the cheapest answer is usually not a second line but a team able to fall back to mobile data, which only works if the critical systems are reachable from a browser and a phone and nobody depends on a file sitting on one office machine.

Supplier outage gets the least preparation of the three. If the operation runs through a single carrier, a single manufacturer or a single software vendor, the alternative has to be identified before the crisis rather than during it. Shopping for an alternative on the day means finding one expensively and on someone else's terms, whereas a single conversation in a calm week at least establishes contact and a price list you can act on.

The most neglected task during an outage is telling customers. A company that goes quiet lets a customer who has no idea how long this will last imagine the worst version, and that silence is usually filled by a competitor. How to build a status page and a broadcast flow is covered in announcing service disruptions and running a status page, and the language for delivering a delay without sliding into defensiveness is in delivering bad news to a customer.

Data loss: having a backup is not the same as being safe

Most companies have backups. Almost none have restore tests. That gap matters more than it sounds: a backup proves a file exists, while a restore proves a working company can be rebuilt from it. A corrupt or partial backup is more dangerous than no backup at all, because you take no other precaution while trusting it.

A company is not prepared because it has a backup; it is prepared because it has tried coming back at least once.

Run a stopwatch during the test. The sentence we can restore from backup becomes a very different sentence when the restore turns out to take six hours, and that discovery sends you back to your recovery target. The second question the test answers is where the data lands. Restoring into the same system is fine, but if the provider itself has a long outage you need a readable copy in your own hands. Being able to pull your data out in a format you control on a regular schedule is the only real insurance here, and the practicalities are in importing and exporting your data.

One step beyond that question sits portability: if you have to change systems, does your data come with you, or does it merely appear on a screen? How to assess vendor dependence, and what to ask before signing, is the subject of vendor lock-in and data portability.

Key-person risk: getting the knowledge out of one head

In small companies the largest continuity risk is not a server, it is a person. One password only one person knows. One supplier only one person has a relationship with. Pricing exceptions that exist entirely in someone's memory, alongside verbal agreements nobody wrote down. None of it is documented, because writing it down never reaches the top of anyone's week and that person is always there anyway. Until one day they are not.

The standard advice at this point is to document everything, and in practice it mostly fails. A document is accurate on the day it is written, partly wrong three months later, and unopened after six. Rotation is more reliable: hand the critical task to the backup person for one week each quarter. Whatever the document left out surfaces during that week, and the backup person has now genuinely performed the job once. Rotation is the audit mechanism for documentation, and if you can only afford one of the two, rotation is worth more. A written base still helps, and the right level of detail for capturing critical flows is covered in process documentation and SOPs.

Handing over access and authority

The harshest version of key-person risk is not knowledge but authority. One person who can approve a payment. One account that can log into the portal. One mailbox holding the domain registration whose password nobody remembers. Authority cannot be delegated during a crisis; a second approver has to exist beforehand, company accounts have to sit on corporate addresses rather than personal ones, and every critical access needs at least two people who hold it. How to model who can see and approve what is covered in roles and permissions management.

What format should the plan take?

A forty-page continuity document does not get opened on the day. The format that works is a single page, readable on a phone screen. It contains the following:

• Trigger consequence: The condition that activates the plan, written as one sentence such as no building, no systems, data lost or key person unavailable.
• Call order: Who calls whom, in what order, who makes the first decision, and where authority moves if the first two people cannot be reached.
• Access vault: Where critical credentials are stored and who can open the store in an emergency; the route to the vault, never the passwords themselves.
• Manual fallback: How orders get taken without systems, what document goes out with a shipment, and how those records are entered once you are back.
• Customer and supplier notice: Who tells whom on which channel, with a draft message already inside the plan; nobody writes good copy on the day.
• Return criterion: Who declares normal operations restored and what they look at to decide, without which the company stays in half-crisis mode for weeks.

Keep a copy of that page outside your digital environment. A continuity plan that lives only inside the company systems becomes unreachable at precisely the moment it is needed, whereas a printed copy and a version saved on a few phones removes that failure mode entirely.

There is no plan until it has been rehearsed

A plan written and never tested is a statement of good intentions. A drill does not have to be expensive or elaborate; a one-hour tabletop exercise is more than enough for most companies. Gather the team, tell them nobody can log into anything this morning, and walk through the first four hours out loud without anyone touching a keyboard. The gaps that surface are usually surprising: nobody knows the main supplier's number, the person who writes customer notices is on leave, and the key to the access vault turns out to be held by the key person again.

Twice a year is enough, with a different consequence scenario each time. Make at least one of them a security incident such as ransomware or an account takeover, because the possibility that the backups are encrypted too rewrites the plan from the first line and saves you from having to argue for an offline copy. The baseline defenses worth having in place first are collected in cybersecurity for small businesses.

Where does this approach stop working?

Continuity planning is not about duplicating everything. In a six-person team, a second office, a second connection and a second server create more burden than the risk they guard against. For small teams the right answer is usually simplification rather than duplication: fewer systems, fewer manual steps, less knowledge tied to one person. Consolidating a customer list that currently lives in five places buys more continuity than renting a second server ever will.

The second limit is that a plan does not cure indecision. The real delay in a crisis is rarely technical; it is the pause while everyone waits to see who is allowed to say it. That is why the most valuable line in the document is not a recovery target but a decision right. The third limit is subtler: preparation time spent on rare, catastrophic events is stolen from the frequent small ones. Writing a week-long earthquake scenario while having no plan for the half-day outage you experience three times a year is procrastination wearing the costume of preparedness.

What to do in the first thirty days

Start small. In week one, write down five consequence scenarios and six critical processes; that fits inside a single meeting. In week two, set tolerable downtime and acceptable data loss for each critical process, then check whether your current backup arrangement matches those numbers. In week three, set up the access vault and confirm that every critical account is open to at least two people. In week four, run the one-hour tabletop drill and fold whatever gaps appear into that single page.

The easiest way to keep a plan alive is to attach it to a ritual already on the calendar: review it during annual planning, whenever someone joins or leaves, and whenever you move to a new system. A lighter version of the same logic applies to predictable disruptions, and how work keeps moving when part of the team is away at the same time is covered in sales continuity during holidays and leave.

For a continuity plan to work at all, the critical knowledge has to live in a record the whole team can reach rather than in one person's head. Rocketly keeps customer history, quotes, tasks, bookkeeping records and user permissions in the same place, so one person's absence does not stop the work; open a free account and set up your own continuity arrangement.