Almost no SME goes down because of a movie-style cyberattack. They go down because of the boring stuff: a server that switches off and never comes back, ransomware that encrypts the shared folder on a Friday afternoon, a burst pipe over the rack, a cloud provider with a six-hour outage. The question that really matters isn’t whether it will happen, but how many hours your company can go without invoicing, without producing or without serving customers before the damage is irreversible. A business continuity plan for an SME is exactly the answer to that question, written down and tested.
And no, you don’t need a 200-page manual or a multinational’s budget. You need to know which processes can’t stop, how long you can really hold out and which three things you do in the first hour. The rest is decoration. Let’s get to the point.
Continuity vs. recovery: what a BCP is and what a DRP is
They get mixed up constantly, and that confusion is expensive. The BCP (Business Continuity Plan) answers “how does my business keep running while something is broken”. The DRP (Disaster Recovery Plan) answers “how do I recover the technology that has gone down”. One looks at the business; the other, at the systems.
An example: your ERP goes down. The DRP says how you restore the database from the backup and which server you bring it up on. The BCP says how the invoicing team keeps issuing delivery notes on a temporary template in the meantime, so the warehouse doesn’t grind to a halt. The DRP fixes the machine; the BCP keeps the money coming in through the door. You need both, and you need them to talk to each other.
Recovering the system in two days is no use if your business dies in four hours without it.
The classic SME mistake is having (if you’re lucky) a scrap of DRP —the backups— and no trace of a BCP. You have backups, yes, but nobody knows who decides to trigger the recovery, who gets notified, how customers are looked after in the meantime or how much time is “too much”. That’s not a plan: it’s a folder of files and a set of crossed fingers.
Which processes can’t stop and how long you can hold out: RTO and RPO in plain English
Every serious plan starts the same way: not everything matters equally. If you try to protect every system with the same urgency, you’ll never finish and you can’t afford it. Make an honest list of your processes —invoicing, producing, handling orders, paying salaries, giving support— and rank them by what happens if they stop for an hour, a day, a week. The ones that hurt within hours are your critical processes. Those call the shots.
On top of that list, two acronyms appear that sound technical but are pure common sense:
- RTO (Recovery Time Objective): how long a process can be down before the damage becomes serious. It’s your “clock”. If your online shop can’t go more than 2 hours without selling, your RTO is 2 hours.
- RPO (Recovery Point Objective): how much data you can afford to lose, measured in time. If you back up every 24 hours, your RPO is one day: in a disaster, you lose up to a day’s work. For an invoicing ERP that’s usually unacceptable.
The magic lies in crossing both against reality. If your critical process demands an RTO of 2 hours but your only backup sits on a USB drive that someone takes home on Fridays, your real recovery capability is days, not hours. There’s your gap, measured and in numbers. And with those numbers you can now decide where to invest: cloud replication, more frequent backups, a secondary server. Not out of fear, but out of judgement.
A piece of advice that saves money: set the RTO and RPO to the value of the process, not to your anxiety. The marketing file server can tolerate a 24-hour RPO without drama. The orders database can’t. Protecting everything as if it were critical is the fastest way to blow the budget and never finish the plan.
A simple plan you’ll actually use
The best continuity plan isn’t the most complete one: it’s the one your team can execute at 3 in the morning, running on adrenaline, with the on-call IT person nowhere to be found. That means short, clear and actionable. A well-made two- or three-page document is worth more than a tome nobody has ever opened.
The bare minimum it should contain:
- Critical processes and their RTO/RPO: the list from the previous section, prioritised. What gets recovered first and what can wait.
- Who decides and who executes: names and stand-ins. Who declares the incident, who authorises the recovery, who talks to customers. Without roles, there’s paralysis.
- Key contacts outside the system: phone numbers for the team, the IT provider, the bank, the insurer. Printed or on your phone, because if the network goes down you won’t have access to the Drive.
- Where the backups are and how to restore them: location, controlled access credentials and the step-by-step procedure. A backup nobody knows how to restore isn’t a backup.
- The manual plan B: how each critical process keeps operating without its system. Invoicing on a template, taking orders by phone, whatever keeps the business alive for those hours.
Notice what’s not there: jargon, gorgeous architecture diagrams, improbable scenarios. The plan describes what to do in the first hour of the three or four outages that can really happen to you. Everything else is superfluous until this core works. Start small, put it in writing today and improve it later.
How to test it so it really works
An untested plan is a hypothesis. And in continuity, hypotheses collapse exactly when you need them most. The backup that “ran on its own” had been failing silently for three months; the restore procedure took eight hours instead of two because nobody had timed it. You don’t discover these things by reading the plan: you discover them by running it.
You don’t need to simulate a fire. Test in layers:
- Real backup restore: take a backup and recover it in a separate environment. Time it. Does it meet your RTO? Is all the data there? This is done every quarter, not once in a lifetime.
- Tabletop exercise: gather the team for an hour, pose “it’s 9:00 and the ERP won’t start” and have each person say what they do. The gaps surface without touching a single system.
- Manual plan B drill: spend half a day invoicing or taking orders as if the system didn’t exist. You’ll find out what’s missing before you actually need it.
Each test leaves tasks behind: update a contact, fix a backup, clarify a confusing step. That cycle —test, find the fault, fix it— is what turns a document into a real capability. And here monitoring plays a silent but decisive role: if you watch your systems and backups in real time, many incidents are detected and contained before they turn into a disaster that triggers the whole plan. Prevention comes out far cheaper than recovery.
How MagicBoxDesk sets it up
All of this —classifying processes, setting realistic RTOs and RPOs, building backups that genuinely restore, writing the plan and testing it every quarter— is specialised, ongoing work. It’s exactly what we do when we outsource a company’s IT department: we don’t sell a PDF and vanish, we leave in place the real capability to take a hit and keep invoicing. We design the BCP and the DRP around your operation, with 24/7 monitoring that spots problems before they knock you down and with backups that are verified automatically, not “in theory”.
We provide remote and on-site support across Spain, with the experience of people who have brought downed systems back up on a Sunday night more times than they’d care to admit. If you don’t know how many hours your business can survive without its systems, that’s exactly the starting point. Request a no-obligation quote and we’ll tell you, with numbers, where your real risk is and what you genuinely need to sleep easy.
