Does Your Business Have a Real Disaster Recovery Plan?

A disaster recovery plan is a documented, tested set of steps your business follows to get systems, data and people working again after an outage, cyber attack, hardware failure or site loss. Backups are one ingredient. A plan defines who does what, in what order, how fast, and how you prove it works — before you need it.

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

This is where most South African small businesses get caught out. You ask the owner, "Do you have a disaster recovery plan?" and the answer is, "Yes, we back up to the cloud." That's not a plan. That's one component of a plan — and often an untested one.

A backup is a copy of your data. A disaster recovery (DR) plan is the full playbook: how you restore that data, onto what hardware, in what sequence, who makes the call to invoke it, how long it realistically takes, and how your team keeps serving clients while it happens.

The gap between "we have backups" and "we can be trading again by Tuesday" is where businesses lose weeks of revenue, client trust, and sometimes the business itself.

What actually counts as a disaster for an SA business?

It's not just floods and fires. In the South African context, the realistic list looks like this:

• Ransomware encrypts your file server and nobody can open a document
• A fibre cut takes your office offline for two days
• Prolonged loadshedding kills a UPS mid-cycle and corrupts a database
• An ex-employee deletes files on their way out
• A laptop with the only local copy of a matter file is stolen from a car
• Your Microsoft 365 tenant gets compromised through a phishing attack
• A burst geyser upstairs floods the server cupboard on a Saturday

Each of these needs a different response. A DR plan maps the response to the scenario, so your team isn't inventing a solution at 7am on a Monday while clients are already phoning.

What should a disaster recovery plan actually contain?

Skip the 80-page template. For a 20-80 person professional-services firm, a workable DR plan covers eight things:

1. Asset inventory — every system, server, SaaS platform and critical data store, and who owns it.
2. Recovery priorities — what has to come back first (usually email, matter/client files, accounting system) and what can wait.
3. Recovery Time Objective (RTO) — the maximum time each system can be down before it hurts. Different for your practice management vs the office printer.
4. Recovery Point Objective (RPO) — how much data loss you can tolerate. One hour? One day? The answer drives your backup frequency.
5. Backup architecture — where backups live, how many copies, how often they're taken, how long they're kept. The old 3-2-1 rule still holds: three copies, two different media, one off-site.
6. Response roles — who declares the incident, who talks to staff, who talks to clients, who liaises with your IT provider, who handles POPIA notification if personal data is involved.
7. Communication plan — how you reach staff and clients if email is down. (If your plan assumes email works, your plan is broken.)
8. Test schedule — when and how you prove it all works.

If you've got Microsoft 365 management in place, remember that Microsoft protects the platform but not your data retention — you still need a third-party backup for mailboxes, OneDrive and SharePoint.

How often should you test your disaster recovery plan?

At least once a year end-to-end, and quarterly for the critical components (restoring a file, restoring a mailbox, failing over your internet). An untested plan is a hope, not a plan. We've seen businesses discover during a real incident that their backup had been failing silently for seven months because nobody checked the status email anymore.

Testing doesn't have to be dramatic. Pick a Saturday morning. Try to restore last week's version of a specific client file to a different folder. Time it. Note what broke. Fix it. That's a test.

How do you know if your current setup is good enough?

Ask your IT provider — or yourself — these five questions:

• When was the last successful restore test, and can I see the report?
• If our office burned down tonight, what would we be doing on Monday morning?
• Who declares a disaster, and what's their mobile number?
• If ransomware hit tonight, how far back would we be rolled to?
• Does our plan cover a POPIA-reportable data breach, including notification to the Information Regulator?

If any of those answers is a shrug, you've got a gap. This is also one of the clearer 5 signs your business has outgrown its IT guy — DR planning is where part-time support quietly falls short.

What does good disaster recovery look like day-to-day?

With a proper plan and proactive monitoring in place, most "disasters" never become visible to your team. A failing drive is swapped before it dies. A backup failure triggers an alert at 2am and is fixed before the office opens. A phishing attempt is caught at the mail filter. The server that always crashes at month-end gets patched on the first Saturday of the month.

That's the quiet version. The loud version is the one you want to avoid: a Monday morning where nobody can log in, the phone is ringing, a client wants their file by midday, and nobody can tell you when it'll be back.

Key facts

• Backups and disaster recovery are not the same thing — backups are data copies; DR is the full response plan.
• RTO (how fast you recover) and RPO (how much data you can lose) are the two numbers every plan needs.
• Microsoft 365 does not back up your data in the way most people assume — third-party backup is needed.
• Under POPIA, if a breach involves personal information, the Information Regulator must be notified as soon as reasonably possible after reasonable grounds exist to believe a compromise occurred — you don't need to finish investigating first. See inforegulator.org.za.
• MiBOT Support is ISO/IEC 27001:2022 certified, so our own backup, recovery and incident-response processes are externally audited.

Frequently asked questions

How much does a disaster recovery plan cost for a small business?

The plan itself is mostly time, not money — a day or two of structured work with your IT provider. The underlying infrastructure (backup software, off-site storage, failover internet) varies based on how fast you need to recover and how much data you hold. A practical setup for a 20-person firm is usually a modest monthly line item, far smaller than one day of being offline.

Isn't cloud enough? Why do I still need a DR plan?

Cloud removes some risks (hardware failure, site loss) but adds others (account compromise, accidental deletion, SaaS vendor outages). You still need a plan for how your business keeps functioning if your Microsoft 365 tenant is locked, your fibre is down, or an admin account is breached. Cloud is a tool, not a plan.

How does POPIA affect our disaster recovery plan?

If a disaster involves a compromise of personal information — ransomware, a lost laptop with client data, an email breach — POPIA requires notification to the Information Regulator and affected data subjects as soon as reasonably possible. Your DR plan should include who makes that call, what template you use, and how you document the incident. Build it in now, not on the day.

Can MiBOT help us build and test a DR plan?

Yes. It's part of how we run managed IT support for regulated professional-services clients — documenting the plan, running the restore tests, and making sure the people, process and tech all line up. If you'd like a second opinion on your current setup, book a free consultation.

---

If your current "plan" is a backup you've never tested and a hope that nothing goes wrong, that's the gap worth closing. The businesses that recover well from a bad week are the ones that decided, on a quiet week, exactly what they'd do.

Last reviewed: October 2026