The call comes in at twenty to seven in the morning. Systems encrypted, the IT provider has pulled both sites off the network, nobody can get into the ERP. The first question from the management team is rarely a technical one. It is this: can we still ship today?
Business continuity in an SME is decided by that question, and it is decided weeks earlier. Not by firewall redundancy and not by the backup design, but by whether somebody settled before the outage which few things have to run first and what is allowed to sit still. In most companies that decision was never made. So it gets made in the crisis meeting, under time pressure, by people who have very different worries at that moment.
Business continuity is a prioritisation made by the management team, not a technical task: which processes have to be back within what time, what runs by hand in the meantime, what can wait. Decide that in advance and you need less high availability, yet you come back faster than a company full of mirrored systems with no order of priority.
Why "everything matters" is the most expensive answer
Ask the management team of an SME which processes have to come back first after an outage and the answer is almost always: all of them. That is humanly understandable and commercially a capitulation. Without prioritisation, the order is left to chance, to the loudest department head or to the engineer who has an idea first.
IT translates "everything matters" into the only language it has for it: redundancy. A second site, mirrored systems, failover licences, a maintenance contract with short response times across the board. That costs money, and against ransomware it helps only so far. A cleanly mirrored system mirrors the damage too.
There is also a thinking error about the cause. Plan business continuity only against attacks and you plan past a lot of outages. In our experience an SME stands still just as often because a weekend migration could not be rolled back, because something was burning at the IT provider, because a cloud service failed in one region, or because a firewall change cut access to half the production line. Shipping does not care why nothing works. The prioritisation is the same in all of these cases, which makes it the cheapest preparation an SME can do.
The uncomfortable version: prioritisation means going without. Business continuity only works once somebody with authority says that payroll can wait three days. That sentence costs nothing and does more than most investments in availability. More protection, fewer tools, lower cost starts here, not with the next product.
How long can an outage last before it hurts?
No IT department can answer that, and no consultant either. The number comes from the business: the point at which a stalled process costs revenue, contractual penalties, delivery reliability or trust. For one process that is four hours, for another two weeks. That spread is the whole point, because it decides where the money goes and where it does not.
In the jargon the two numbers are called RTO and RPO. The first says how long a process may stand still before the damage stops being tolerable. The second says how much work may be lost in the worst case: an hour of data entry, or a full day. Both terms sound technical and are still business decisions. IT can deliver what is ordered, and it can say what a shorter deadline costs. The ordering is the management team's job.
This is what an honest prioritisation looks like, here for a manufacturing business. The numbers belong to that business, not to yours:
| Process | May stand still | What happens then |
|---|---|---|
| Shipping and delivery notes | under 8 hours | Delivery dates slip, customers escalate to the top |
| Production and batch release | under 24 hours | Machines idle, staff without work, catching up only on overtime |
| Receivables and invoicing | 3 to 5 days | Liquidity shifts, customers notice nothing |
| Payroll | until the next pay run | Nothing, as long as the cut-off date holds |
As a foundation, business continuity in an SME needs no more than this table. It took ninety minutes, with sales, production and finance around the same table. It does not replace an analysis, it ends an illusion: that you can rescue everything at once.
When is running the business by hand worth it?
When the process still works physically without the system and the damage per day is larger than the effort for the workaround. Shipping against an exported list, production from printed work plans, order intake by telephone and notepad. Inelegant, and on day two after an outage often the only thing holding customers.
There is the other side, and it tends to go unmentioned. Where a legal record-keeping duty hangs on the system, where a fully automated warehouse without its control software is just a rack, where nobody remembers how the process ran before the software arrived, there is no manual mode. That is not a weakness, it is information. For those processes the recovery time has to be short, and that is allowed to cost something. For all the others it is not.
What a manual mode needs is unspectacular. Data that can be read outside the system. People who still know the process without the software, which in companies with an older workforce is no longer a given. And explicit permission to deviate from the policy in that situation without having to answer for it later. Where manual mode ends in your company is usually clearer to production than to IT.
What holds in a real incident and what only holds on paper
Emergency plans rarely fail on content and often on small things. The phone list sits in the encrypted file share. The plan sits in the intranet, which is down. The credentials for recovery sit in the password tool that depends on the same directory service as everything else. BACS, the Swiss Federal Office for Cybersecurity, provides an emergency planning model with a template for SMEs, including an emergency sheet and a four-phase model. The template is useful. It just never says who in your company is allowed to decide.
What holds is settled decision rights: who may shut down operations, including against the wishes of sales. Who talks to customers and from what point. Who declares manual mode open and who declares it closed. How those roles get settled before an incident is covered in our piece on the SME incident response plan.
Then there is the reporting question, which many companies first ask during the incident. Operators of critical infrastructure have had to report cyberattacks to BACS within 24 hours of discovery since 1 April 2025. Companies outside that scope often have the same deadline in a customer contract anyway. A 24-hour reporting deadline ties up people who are already busy with recovery at that moment. Which person files that report is one of the things that should be settled in advance.
From practice: 190 employees, two plants
A manufacturer of medical technology components with 190 employees and two production sites in western Switzerland. The IT lead had twice asked for budget for a second server room, and twice the answer was that it was too expensive. The topic then sat untouched for a year, not because anyone thought it unimportant, but because nobody could express the benefit in business language.
In the mandate we turned the question around and asked what standstill costs, process by process, instead of what redundancy costs. Of around forty applications, four mattered in the first twenty-four hours. Two processes, shipping and batch release, needed a short recovery time. The rest could wait days, including two systems the budget listed as business critical.
The investment ended up smaller than the original request. Instead of mirroring everything, recovery was documented for four systems and exercised once, and a readable export list for shipping has been kept outside the environment daily ever since. The exercise did not go well: six hours were planned, eleven were needed, and half the delay came down to access nobody held outside the production environment. That was the value of the exercise. Otherwise those eleven hours would have been measured by a real incident.
What the management team gets out of it
Business continuity in an SME is therefore a leadership instrument above all. The priority list answers the board's question of what an outage costs the company in defensible sentences rather than guesses. It gives the insurance questionnaire and the customer audit an answer that can be checked. And it makes the security budget defensible, because every line points at a process somebody has signed for.
That usually shows up in sales first. In the supplier questionnaires we answer for clients, there is now regularly a question about the recovery time for exactly the service the customer is buying. A number from an exercise that was actually run ends the conversation. "We have a backup concept" pulls in the next question and then one more. The difference costs no licence, only a decision and a day of exercise.
That ties the list directly to the risk register. An accepted recovery time of five days is an accepted risk, and only somebody who has to answer for the damage may accept it. Who carries what the register says is covered in our piece on IT risk management in an SME.
In a mandate this work is part of normal operations: sharpening the priorities with the management team once a year, one exercise a year, and closing the gaps that surface in between. What that covers and in what depth is set out under packages and pricing.
Frequently asked questions
Do we need an ISO 22301 certification for this?
Rarely. ISO 22301 is the standard for business continuity management systems and pays off when a customer or a regulator asks for it explicitly. For most SMEs the logic behind it holds without the certificate, and it is not free: it costs a decision by the management team and an exercise that hurts. ISO 27001 requires in any case that information security is maintained during a disruption.
Is a tested backup not enough?
A backup answers whether the data comes back. Business continuity answers what the business does in the meantime. The two belong together, and between them sits the restore duration, which in our experience is consistently underestimated. Restoring a large ERP does not take minutes, and while it runs the business has to keep going somehow.
Who owns business continuity, IT or the management team?
Shared, but not arbitrarily. The management team owns the prioritisation and the accepted recovery times. IT owns the technical recovery planning and the honest answer about what is realistic today. If both own the same document, in the end nobody owns it, and you find that out at twenty to seven in the morning.