How to Build a Disaster Recovery Plan.

Published: 7 July 2026  |  By AOLC

Every South African business owner knows that things go wrong. A ransomware attack encrypts your files on a Friday afternoon. Load shedding causes a power surge that kills your server. A flooded server room, a disgruntled employee, a botched software update — disasters come in many forms, and they do not wait for a convenient time. The question is not whether your business will face a serious IT disruption. The question is whether you will be ready when it does.

A disaster recovery plan (DRP) is your documented, tested blueprint for restoring your IT systems and data after a disruption. Without one, your team will waste critical hours figuring out what to do — while your business haemorrhages revenue and your customers lose confidence. With one, you can recover in a controlled, predictable way. This guide will walk you through exactly how to build a plan that works for a South African business.

What Is a Disaster Recovery Plan?

A disaster recovery plan is a formal document that describes how your business will respond to — and recover from — an IT disaster. It covers what qualifies as a disaster, who is responsible for what, which systems must come back first, and exactly how they will be restored.

It is often confused with a business continuity plan (BCP), which is broader and covers how the whole business operates during a disruption (not just IT). A DR plan focuses specifically on your technology — servers, data, applications, connectivity, and endpoints.

Your managed IT provider should help you build and maintain this document. It should be reviewed at least annually and after any significant infrastructure change.

Understand Your RTO and RPO.

Before you can build a DR plan, you need to answer two critical questions that will shape every decision you make:

• Recovery Time Objective (RTO) — How long can your business operate without a given system before the impact becomes unacceptable? An RTO of 4 hours means your accounting system must be back online within 4 hours of a failure.
• Recovery Point Objective (RPO) — How much data can you afford to lose? An RPO of 1 hour means you need backups taken at least every hour, so you never lose more than 1 hour of transactions.

Different systems have different RTO and RPO requirements. Your point-of-sale system may have an RTO of 30 minutes and an RPO of zero — you cannot afford to lose a single transaction. Your email archive may tolerate an RTO of 24 hours and an RPO of 24 hours. Map every critical system before you write a single line of your plan.

Six Steps to Build Your Plan.

A solid disaster recovery plan does not need to be 100 pages long. It needs to be accurate, actionable, and actually read by the people who will use it. Here is a proven six-step framework:

• Step 1: Identify critical systems and data — List every application, server, and database your business depends on. Score each by business impact: what stops working if this goes down, and for how long can you tolerate it?
• Step 2: Set RTO and RPO for each system — Work with department heads and finance to put a number on acceptable downtime and data loss. These targets will drive your backup frequency and recovery method.
• Step 3: Document your recovery procedures — For each critical system, write the step-by-step recovery process. Who performs it, what tools are needed, what credentials are required, and how do you verify the system is back to full operation? This documentation should be detailed enough for someone to follow in a crisis — not just the person who built the system.
• Step 4: Define roles and responsibilities — Name the people who will declare a disaster, coordinate the response, communicate with staff and customers, and execute technical recovery. Assign backups for each role in case the primary person is unavailable.
• Step 5: Plan for load shedding and connectivity loss — In South Africa, your DR plan must account for Eskom outages. Do you have a UPS or generator? How long will it run? If your ISP goes down, do you have a mobile data failover? Document these decisions explicitly — this is a uniquely South African dimension that many offshore DR templates miss entirely.
• Step 6: Test, review, and update — A plan you have never tested is a hypothesis, not a plan. Schedule a tabletop exercise every six months and a full failover test at least once a year. Update the plan whenever infrastructure changes.

Backup Is Not the Same as Disaster Recovery.

This is the most common misconception we encounter. A backup is just one component of a disaster recovery strategy. On its own, it is not enough.

Consider this scenario: your file server fails catastrophically at 9 a.m. on a Monday. You have backups — they run nightly to an external drive attached to the same server. The drive is also dead. Or the backups ran fine, but nobody has ever tested a restore, and it turns out the backup software has been silently failing for six weeks.

Disaster recovery is the end-to-end process — including the backup, the verified restore procedure, the fallback environment, the communication plan, and the post-recovery validation. If you only have a backup, you have only one piece of the puzzle.

POPIA Compliance and Your DR Plan.

Under the Protection of Personal Information Act (POPIA), South African businesses have a legal obligation to protect the personal data they hold. This extends to your disaster recovery practices. If your business processes personal information — and almost every business does — your DR plan must address how that data is protected during and after a disaster.

Key POPIA considerations for your DR plan include:

• Data location — POPIA restricts cross-border transfers of personal information unless specific conditions are met. If your cloud backup destination is outside South Africa, confirm that the transfer is legally compliant before relying on it as your primary recovery target.
• Access controls during recovery — In a crisis, there is pressure to bypass normal access controls to get systems back online quickly. Your DR plan should specify that access controls must be maintained throughout the recovery process, and that any temporary access must be documented and revoked afterwards.
• Breach notification — If the disaster involves a data breach (a ransomware attack that exfiltrated data, for example), POPIA requires notification to the Information Regulator and affected data subjects within a reasonable time. Your DR plan should include a decision tree for when and how to notify.
• Encrypted backups — All backups containing personal information should be encrypted at rest and in transit. This protects the data even if the backup media is stolen or the storage provider is compromised.

Your cloud and security strategy should align with your DR plan — both documents are stronger when they reference each other.

Why Testing Your Plan Matters.

A disaster recovery plan that has never been tested is not a plan — it is a wish. Testing is the only way to know whether your recovery procedures actually work, whether your RTO and RPO targets are achievable, and whether your team knows what to do under pressure.

There are two levels of testing you should schedule:

• Tabletop exercise (every 6 months) — Bring together the key people in your DR plan and walk through a simulated disaster scenario. "It is Monday morning, ransomware has encrypted your accounting server. Walk me through exactly what happens next." This tests decision-making and communication without touching live systems.
• Full failover test (annually) — Actually restore your critical systems from backup in a test environment. Measure how long it takes. Compare against your RTO. Fix whatever is slow or broken. Document everything. This is the only way to validate that your backups are actually restorable and that your recovery procedures are accurate.

---

What to Do Next.

If your business does not yet have a documented disaster recovery plan, start today — not because a disaster is imminent, but because building the plan takes time and the best time to do it is before you need it. Here is a practical starting checklist:

• Inventory your critical systems — List every system, application, and data set that your business cannot operate without for more than a few hours.
• Set your RTO and RPO targets — Work with your operations team to define acceptable downtime and data loss for each critical system.
• Audit your current backups — Verify that backups are running, test a restore, and confirm that your backup data is stored in at least one off-site or cloud location.
• Document your recovery steps — Even a rough first draft is better than nothing. You can refine it over time.
• Identify your load shedding exposure — Assess which systems are at risk during power outages and what failover measures you have in place.
• Schedule your first test — Put a tabletop exercise in the calendar within the next 90 days.

If this feels like a lot to take on internally, you do not have to do it alone. An experienced managed IT partner can help you build, document, and test a disaster recovery plan that is matched to your business size, risk profile, and budget — and that accounts for the South African-specific challenges of load shedding and local connectivity.

← Back to Blog