How to Build a Business Continuity Plan for South African Organisations

A business continuity plan (BCP) is a documented set of procedures that enables your organisation to continue operating — or resume operations quickly — when a disruptive event occurs. Not a theoretical event. A real one: ransomware, extended load shedding, a key person leaving unexpectedly, a flood in the server room, a supplier failure that cuts off a critical input.

The distinguishing feature of a useful BCP is that it works under the conditions in which it will be needed. That means it was built on honest risk assessment, has been tested by the people who will execute it, and reflects the actual infrastructure and workforce of your organisation — not a generic template populated with placeholder text.

This guide walks through the components of a business continuity plan that actually functions, with specific attention to the South African context.

BCP vs Disaster Recovery: The Distinction That Matters

These terms are often used interchangeably. They are related but distinct.

Business Continuity Planning (BCP) addresses how the organisation continues to deliver its core functions during and after a disruptive event. It encompasses people, processes, suppliers, facilities, communications, and governance — the full operational picture.

Disaster Recovery (DR) is specifically about restoring IT systems and data after a disruptive event. DR is a component of BCP, but BCP is broader: it addresses what your sales team does when they cannot access the CRM, how you pay staff if the payroll system is offline, and which clients need to be called personally within the first two hours.

An organisation that has a DR plan but no BCP has thought about how to restore its servers. It has not thought about what its staff do while they wait, how it communicates with clients, or how it continues generating revenue during the recovery window.

Step 1: Business Impact Analysis

A Business Impact Analysis (BIA) identifies which business functions are critical, what the consequences of their disruption are over time, and how long they can be disrupted before the impact becomes severe.

For each critical business function, define:

Recovery Time Objective (RTO): The maximum time this function can be unavailable before the impact becomes unacceptable. A professional services firm might tolerate 24 hours without its CRM. Its billing system may have an RTO of four hours.

Recovery Point Objective (RPO): The maximum amount of data loss acceptable for this function. A business that processes 200 transactions per hour cannot afford to lose more than one hour of transaction data. Its RPO is 60 minutes or less.

Minimum Business Continuity Operations (MBCO): The minimum level at which this function must operate during recovery. Full capacity is not always achievable immediately — define what "good enough to continue" looks like.

The BIA forms the foundation of every subsequent planning decision. Your backup strategy, recovery architecture, and crisis staffing plan are all derived from the RTOs and RPOs it produces.

Step 2: Risk Assessment with SA-Specific Factors

South African organisations face a risk landscape that differs from international benchmarks. Your risk assessment should explicitly include:

Load shedding: Extended power outages affect not only your own operations but those of suppliers, clients, and infrastructure providers. Your BCP should address operations during stage 6 load shedding — UPS autonomy for critical systems, generator fuel logistics, and staff working-from-home arrangements that may be affected by residential load shedding simultaneously.

Ransomware: The most frequently realised serious disruption risk for South African businesses. Your BCP must address the ransomware scenario specifically — not just "IT outage" generically. The ransomware scenario requires a breach notification thread alongside the IT recovery thread.

Key person dependency: Many South African SMEs have critical operational knowledge concentrated in one or two individuals. The unplanned departure, illness, or incapacitation of these individuals is a business continuity risk that BCPs frequently overlook. Document critical procedures that are currently held only in someone's head.

Supplier failure: Single-source suppliers for critical inputs or services represent continuity risk. Identify them and build contingency arrangements before they fail.

Connectivity failure: Your business's dependence on internet connectivity for cloud services, remote staff, and client-facing systems — and the fallback if your primary ISP is unavailable.

For each identified risk, assess probability and impact, and prioritise your planning effort accordingly.

Step 3: Recovery Strategies

For each critical business function, define the recovery strategy.

IT recovery: For each critical system, define the recovery approach. Cloud backup with tested RTO. Failover to a secondary system. Manual operation with paper-based processes during the recovery window. The strategy must be achievable within your defined RTO — which means it must be tested, not assumed.

Workplace recovery: If your primary premises are unavailable, where do staff work? Remote working arrangements are the most practical option for knowledge-work businesses, but require pre-configured laptop access, VPN credentials, and communications tools that work independently of the primary office network.

Supplier alternatives: For critical single-source suppliers, identify at least one alternative and maintain a current contact. You do not need a formal contract — but knowing who they are means you can act quickly when needed.

Communication infrastructure: How do you reach staff, clients, and suppliers when your primary communications infrastructure is unavailable? Maintain a contact list with personal mobile numbers for key staff and critical clients.

Financial continuity: How do you pay staff and critical suppliers if your banking access is unavailable? What is the minimum cash flow required to maintain operations for two weeks? Do you have an emergency credit facility?

Step 4: The Plan Document

A BCP document should be concise, specific, and usable under pressure. Structure it as an operational tool, not a compliance document.

Crisis activation criteria: Define clearly what triggers activation of the BCP — specific, observable conditions, not "a significant disruption."

Incident command: Who leads the response? Who has authority to activate the plan, make financial commitments, communicate with clients, and engage external support? Define roles, not just names.

Immediate response checklist: The first 30 minutes after a crisis is declared. Specific actions, specific owners. This section should be usable by someone who has not read the full plan.

Function recovery procedures: For each critical business function, a specific procedure — what to do, who does it, what resources they need, what "recovered" looks like.

Communication scripts: Template communications for staff, clients, and suppliers, drafted and ready before an incident.

Contact directory: All contacts needed during a crisis — staff mobile numbers, critical suppliers, IT support, insurance broker, legal counsel, key clients. Stored in printed form and independently of your primary systems.

Step 5: Testing

A plan that has never been tested is a plan with unknown gaps. Test at three levels:

Document review (annually): Update contact details, verify that systems and processes described are still accurate, review whether the risk profile has changed.

Tabletop exercise (annually): Walk the incident command team through a scenario — ransomware and extended premises unavailability are the two most useful for most SA businesses. Identify gaps and unclear decision points.

Live test (every two years): Test actual recovery procedures under realistic conditions. Restore systems from backup and measure actual recovery time against your RTO. This is the only way to find the gaps that tabletop exercises miss.

POPIA and Business Continuity

POPIA's security safeguards condition requires appropriate measures to ensure operational continuity for systems processing personal information. A POPIA audit will ask whether a BCP exists, whether it has been tested, and whether the technical measures it relies on have been verified.

An organisation without a BCP — or with a plan that has never been tested — cannot credibly claim to have appropriate measures for continuity of personal information processing. This is a compliance gap as well as a business risk.

Our resilience architecture assessments evaluate your BCP, DR capabilities, and backup infrastructure together — giving you a single, integrated view of your continuity readiness against both operational and compliance requirements.