Business continuity planning: a practical framework for any organisation

Why business continuity planning matters

Every organisation depends on technology, people, and processes to operate. When any of these fail - whether through a cyberattack, power outage, natural disaster, or simple human error - the consequences ripple through revenue, reputation, and regulatory standing.

Business continuity planning (BCP) is the discipline of preparing for disruptions before they happen, so your organisation can maintain critical functions and recover quickly when things go wrong.

South African businesses face a particular set of risks: loadshedding, cable theft, water shortages, and a threat landscape that grows more sophisticated each year. Despite this, many organisations still treat continuity planning as a “nice to have” - something to address after the next budget cycle. The reality is that the cost of planning is always less than the cost of improvising during a crisis.

What a business continuity plan actually covers

A BCP is not a single document. It is a collection of policies, procedures, and resources that together ensure your organisation can:

Identify which functions are critical to survival
Understand the impact of disruptions on those functions
Define acceptable recovery timeframes
Document the steps required to restore operations
Assign responsibility so that people know their roles during an incident

The plan spans technology, people, facilities, and third-party dependencies. It is as much about communication and decision-making as it is about servers and backups.

Step 1: Business impact analysis

The foundation of any BCP is a business impact analysis (BIA). This exercise answers a simple question: what happens when a process stops?

For each critical business function, the BIA captures:

Financial impact - lost revenue, penalties, overtime costs, and recovery expenses per hour or per day of downtime.
Operational impact - which downstream processes are affected? If invoicing stops, does payroll also stop?
Reputational impact - how do customers, partners, and regulators react to extended outages?
Legal and regulatory impact - are you breaching SLAs, POPIA obligations, or contractual commitments?

The BIA produces a prioritised list of functions ranked by their impact severity and time-sensitivity. This ranking drives every subsequent decision in the plan.

Step 2: Define recovery objectives

Two metrics anchor your recovery strategy:

Recovery Time Objective (RTO)

The maximum acceptable time between a disruption and the restoration of a function. An RTO of four hours means the business has decided it can tolerate four hours of downtime for that function before consequences become unacceptable.

Recovery Point Objective (RPO)

The maximum acceptable amount of data loss measured in time. An RPO of one hour means you need backups or replication that captures data at least every 60 minutes. Anything older than that is acceptable to lose; anything newer is not.

RTOs and RPOs vary by function. Your email system might tolerate 24 hours of downtime, while your ERP or point-of-sale system might need an RTO of under one hour. Setting these objectives forces honest conversations about risk appetite and the investment required to meet them.

A business continuity and disaster recovery partner can help you benchmark these objectives against industry norms and design solutions that meet them cost-effectively.

Step 3: Develop plan components

With the BIA and recovery objectives in hand, the plan itself takes shape across several areas:

Technology recovery

Backup strategy - what is backed up, how often, where backups are stored (on-site, off-site, cloud), and how they are tested.
Failover architecture - for critical systems, do you have redundant infrastructure that can take over automatically or with minimal manual intervention?
Network and connectivity - if your primary internet link fails, is there a secondary path? If the office is inaccessible, can staff work remotely?

People and communication

Incident response team - who is responsible for declaring an incident, coordinating recovery, and communicating with stakeholders?
Contact lists - up-to-date phone numbers and email addresses for key personnel, vendors, and emergency services.
Communication plan - how do you notify staff, customers, and regulators? What channels do you use if email is down?

Facilities and logistics

Alternate work locations - if your primary office is unavailable, where do people go?
Equipment and supplies - do you have spare laptops, mobile hotspots, or access to temporary office space?

Third-party dependencies

Vendor continuity - do your critical suppliers have their own BCPs? What happens if your payroll provider or cloud host goes down?
SLAs and escalation paths - are recovery commitments documented in contracts?

Step 4: Testing and exercises

A plan that has never been tested is a plan that will fail. Testing validates assumptions, reveals gaps, and builds muscle memory so that people can execute under pressure.

Common types of tests:

Tabletop exercise - the incident response team walks through a scenario verbally. Low cost, high value for identifying gaps in roles and communication.
Walkthrough test - teams physically perform their assigned tasks without actually failing over systems. Validates procedures and identifies missing steps.
Simulation - a realistic scenario is introduced (e.g., “the primary data centre is offline”) and teams respond in real time. Tests both technology and human response.
Full failover test - critical systems are actually switched to backup infrastructure. This is the most rigorous test and the only way to confirm that your RTO and RPO are achievable.

Test at least annually, and run tabletop exercises more frequently - quarterly is ideal. Document results, track issues, and feed findings back into the plan.

Step 5: Maintenance and review

A BCP is a living document. It must be reviewed and updated whenever:

The organisation adds new systems, locations, or business functions
Staff changes mean that roles or contact details are out of date
A real incident reveals gaps or incorrect assumptions
Regulatory requirements change
Third-party vendors or contracts change

Assign an owner - typically someone in operations, IT, or risk management - who is accountable for keeping the plan current. Schedule formal reviews at least twice a year.

Common mistakes to avoid

Treating BCP as an IT project. Technology recovery is one component. A plan that ignores people, communication, and facilities will fail.
Setting unrealistic RTOs. An RTO of zero sounds ideal, but achieving it is expensive. Align recovery objectives with actual business impact.
Never testing. An untested plan is a guess. Even a simple tabletop exercise is better than nothing.
Letting the plan gather dust. Organisations change constantly. A plan written two years ago and never updated is dangerous.
Ignoring supply chain risk. Your continuity depends on your vendors’ continuity. Ask the hard questions.

Getting started

You don’t need to build a perfect plan on day one. Start with the BIA, define your most critical functions, set recovery objectives, and build from there. The process itself - the conversations, the prioritisation, the testing - is where most of the value lies.

ITHQ helps South African organisations build, test, and maintain business continuity frameworks that are practical, proportionate, and aligned to real risk. Our managed IT services ensure your day-to-day environment is resilient, while our BCDR solutions cover backup, failover, and recovery planning. We design and manage the infrastructure that underpins it all.