Business continuity in African operating environments is usually written for the wrong scenario. Plans anticipate a single, discrete disruption — a fire, a system outage, a burst pipe. What actually arrives is a compound event: an election dispute that produces protest, that produces a curfew, that closes an office, while the internet is throttled and the currency moves against you in the same week.
Continuity is a decision framework, not a document
The useful output of a continuity programme is not the plan. It is a small set of pre-made decisions: which activities continue at any cost, which pause, who decides, and what evidence triggers the decision. Organisations that make those choices in advance recover quickly. Organisations that make them during the event spend the first forty-eight hours negotiating internally.
- A business impact analysis that names critical activities and their maximum tolerable downtime — in hours, not adjectives.
- Recovery strategies for each critical activity, with the dependency chain made explicit: people, premises, systems, suppliers, cash.
- Named decision-makers and deputies with documented authority thresholds.
- Trigger criteria written in observable terms, so activation is not a matter of opinion.
The dependencies that break first in Africa
Continuity plans imported from headquarters routinely miss the local failure modes. Power availability and fuel supply for generators. Internet shutdowns and throttling around elections and protests. Cash liquidity where banking is constrained and payroll is partly cash-based. Border and airspace closures affecting regional support functions. Customs and permit renewal cycles that quietly determine whether stock can move at all.
Test whether your regional support functions can survive simultaneous disruption in two countries. Correlated country risk is the assumption most plans omit.
Aligning to ISO 22301 without drowning in it
ISO 22301 provides a sound structure — context, impact analysis, strategy, plans, exercising, improvement — and organisations should use it as a checklist rather than a compliance project. For most country offices, a fifteen-page plan that is current and exercised outperforms a hundred-page manual that is neither.
Where continuity meets security
The two disciplines are separated on organisation charts and joined in reality. A security incident that closes an office is a continuity event. A continuity failure that strands staff without payroll is a duty-of-care event. Crisis management sits at the join: one activation process, one team, one log — with security, continuity, communications and welfare represented rather than running parallel responses.
Exercising: the only reliable test
- One tabletop per year minimum, using a scenario drawn from the actual risk register.
- One unannounced element — a call tree test, a systems failover, a relocation of one team for a day.
- A written lessons-identified log with owners and dates, reviewed at the next exercise.
- Participation from finance and logistics, not only security and IT — they hold most of the real dependencies.
The test of a continuity programme is not whether the plan exists. It is whether, on a bad Tuesday, the right five people know what they are authorised to do before anyone calls headquarters.