Business Continuity Planning
Keep critical operations viable through disruption.
Translate business-impact requirements into technology recovery priorities, dependencies, runbooks and exercises.
Discuss this requirement →Start with the environment, risk and required outcome.
Translate business-impact requirements into technology recovery priorities, dependencies, runbooks and exercises. Namandla Consultants begins with evidence and recommends a proportionate engagement rather than a generic technology package.
Connected expertise for the wider environment.
Clear steps. Visible decisions.
What a business continuity plan is, and what it is not
A continuity plan answers one question: if a given capability is unavailable, how does the organisation keep working, for how long and what does it take to get back.
That is broader than IT. It covers people, premises, suppliers, information and systems. IT disaster recovery is one component of it, and treating the two as the same thing is the most common structural error in this discipline. A recovery plan for your servers is not a continuity plan for your business.
The distinction shows up immediately in practice. If your warehouse management system is unavailable, the IT question is how long until it is back. The continuity question is whether the warehouse can dispatch on paper, who authorises that, where the paper forms are, how the resulting data gets back into the system afterwards and who tells the customers. The second set of questions is what keeps the business trading. Only the first is usually documented.
The four documents and how they relate
| Document | Answers | Owner |
|---|---|---|
| Business impact analysis | What matters, how quickly and what it depends on | Business, supported by IT |
| Business continuity plan | How the organisation keeps operating without a capability | Business |
| IT disaster recovery plan | How systems and data are restored, in what order | IT |
| Incident and crisis management plan | Who decides, who communicates, how it is coordinated | Executive |
They are built in that order. A recovery plan written before an impact analysis is a plan built on assumption about what matters, and it is usually wrong in a specific and expensive way: it protects the systems that are technically interesting rather than the ones that stop the business.
The business impact analysis
This is the work. Everything else follows from it and it is the part that gets skipped.
What it establishes
Which processes matter, ranked
Not systems. Processes. “Dispatch orders”, “invoice customers”, “pay staff”, “receive stock”, “run payroll”, “report to the regulator”. Systems appear as dependencies of processes, which is the correct relationship and the opposite of how most plans are structured.
Maximum tolerable period of disruption
For each process, the point beyond which the consequences become unacceptable. This is a business judgement and it should be made by the person accountable for the process, not by IT and not by a consultant.
Minimum business continuity objective
The reduced level of operation that is acceptable during disruption. Full capacity is rarely the target. Dispatching at forty percent for three days may be entirely acceptable, and knowing that changes the recovery design and the cost substantially.
Dependencies
Systems, data, people, premises, suppliers, equipment and utilities. This is where the analysis earns its keep, because dependency chains are longer than anyone expects and the surprises are consistent: a licence server nobody knew about, a single supplier with no alternative, one person who is the only one who can authorise a particular transaction, a scheduled task running on a workstation under a desk.
Turning that into RTO and RPO
Two numbers per system, derived from the process they support.
Recovery time objective. The target elapsed time from disruption to the system being available again. Driven by the maximum tolerable period of disruption of the processes that depend on it, minus whatever manual workaround buys you.
Recovery point objective. The maximum acceptable data loss, expressed as time. An RPO of four hours means you accept losing up to four hours of transactions. That is a business decision about re-keying effort and about what can be reconstructed from elsewhere, not a technical preference.
The numbers drive the architecture and the cost, and the relationship is steep.
| RTO | Typical architecture | Relative cost |
|---|---|---|
| 24 to 72 hours | Offsite backup, rebuild on replacement or cloud infrastructure | Baseline |
| 4 to 24 hours | Warm standby, pre-provisioned infrastructure, restore from replicated backup | 2 to 3× |
| 1 to 4 hours | Replicated standby environment, tested failover procedure | 4 to 6× |
| Minutes | Active-active or synchronous replication with automated failover | 8× and upward |
Setting every system to a one-hour RTO is the default reflex and it is how continuity programmes become unaffordable and get shelved. The value of the impact analysis is that it lets you spend the four-hour money on the three systems that need it and the seventy-two-hour money on the other forty.
Building the plan
Scenario-based, not event-based
Plans written against specific events age badly and multiply endlessly. A plan for a fire, a plan for a flood, a plan for a cyber incident, a plan for a supplier failure.
Plans written against loss of capability stay useful, because the recovery is broadly the same regardless of cause.
- Loss of a site or premises
- Loss of systems and data
- Loss of people, whether through illness, industrial action or departure
- Loss of a key supplier or service
- Loss of utilities, power, water or connectivity
Five scenarios cover almost everything, and they map cleanly onto the dependency work already done.
What each plan section has to contain
Activation criteria and authority
What triggers the plan and who has authority to invoke it, with named deputies. Plans routinely stall at this point because the only named person is unreachable, which is a common feature of the circumstances in which plans get invoked.
Roles, by name and by deputy
Not job titles alone. Two deep on every role.
The workaround
How the process runs without its normal system. Paper forms attached, not referenced. Where they are held, in a form that does not require the system that is unavailable.
Recovery sequence
The order systems come back, respecting dependencies. Identity and directory services before anything that authenticates against them. Database before application. Network before all of it.
Communication
Who tells staff, customers, suppliers, insurers and, where the incident involves personal information, the Information Regulator and affected data subjects. Templates drafted in advance, because nobody writes well under pressure.
Return to normal
How you get back, including reconciling data captured manually during the disruption. This section is the one most often missing entirely and it is frequently the longest part of the actual event.
Contact information that works
A contact list stored on the file server, in a document that requires the network to open, is not a contact list. Printed copies with named holders, plus an offline copy on nominated devices. Reviewed on a defined cycle, because contact details and responsibilities change constantly and stale contact lists fail at exactly the wrong time.
Testing, which is what separates a plan from a document
An untested plan is a hypothesis. Four exercise types, increasing in cost and in what they prove.
Plan walkthrough
The team reads the plan and confirms the content is accurate and current. Two hours. Catches out-of-date contacts, changed systems and departed staff. Do this quarterly.
Tabletop exercise
A scenario is presented and the team talks through their response. Half a day. Catches unclear decision authority, missing steps and assumptions two people held differently. This is where most of the value sits for the effort involved. Do this twice a year.
Simulation
Partial execution. Restore a system to an isolated environment, run the manual process for a shift, fail over one service. A day or two. Catches the technical assumptions that a tabletop cannot: the restore that takes eleven hours rather than four, the credential that expired, the dependency nobody documented. Do this annually per critical system.
Full failover
The real thing, planned. Expensive, disruptive and the only exercise that proves the recovery actually works end to end. Appropriate where the RTO commitment is contractual or regulatory.
Every exercise produces findings and every finding gets an owner and a date. An exercise that produces no findings was not a real exercise. The purpose is to find the gaps while they are cheap.
What Namandla delivers
Business impact analysis
Facilitated workshops with process owners, dependency mapping, MTPD and MBCO agreed and recorded, RTO and RPO derived per system rather than assumed.
Continuity plan development
Written against the five capability-loss scenarios, with workarounds documented at the level of detail someone can follow who did not write them.
IT disaster recovery design
Recovery architecture matched to the RTO and RPO tiers, backup and replication design, documented recovery runbooks with the sequence and the dependencies.
Exercise programme
Walkthroughs, tabletops and simulations facilitated, with findings tracked to closure.
Plan maintenance
Scheduled review, change-triggered updates, contact verification and version control. A plan that is not maintained is out of date within about eighteen months, and the parts that go out of date first are the parts you need.
Alignment to ISO 22301 where you need it for certification, tender qualification or a customer requirement. We work to the structure whether or not you certify, because the structure is sound.
Onsite work is Gauteng. Facilitation, documentation and review run nationally.
Where this connects to the rest of the estate
Continuity planning produces requirements. Meeting them is engineering work and it sits on other pages.
Backup design and restore testing is on backup and recovery. Recovery infrastructure and replication is on critical infrastructure and cloud architecture. Connectivity resilience and failover is on multi-site connectivity. Security incident response is on cyber resilience. Major incident coordination is on critical incident recovery.
The plan is the specification. Those pages are the build.
Common questions about Business Continuity
What is a business continuity plan?
A business continuity plan documents how an organisation keeps operating when a capability is unavailable. It covers people, premises, suppliers, information and systems, and it defines the workarounds, the recovery sequence, the decision authority and the communication.
It is distinct from an IT disaster recovery plan, which covers only the restoration of systems and data. Disaster recovery is a component of continuity, not a synonym for it. A business that has documented how to restore its servers but not how to dispatch orders while they are down has done half the work, and the half that matters less.
What is the difference between business continuity and disaster recovery?
Business continuity is about keeping the business operating. Disaster recovery is about restoring the technology. Continuity asks how the warehouse dispatches without the system, disaster recovery asks how long until the system is back.
Both are needed and they are built in a specific order. The impact analysis establishes what the business can tolerate, that produces recovery targets and the recovery design is built to meet them. Building the recovery design first means guessing at the targets, which produces either an unaffordable architecture or one that protects the wrong things.
What is a business impact analysis?
A business impact analysis identifies which processes matter, how long each can be unavailable before the consequences become unacceptable, what level of reduced operation is workable, and what each process depends on.
It is the foundation and it is the step most often skipped, usually because it requires time from business managers rather than from IT. Without it, recovery targets are assumptions. With it, you can defend every number in the plan to an auditor, a customer or an insurer, and you can spend the recovery budget where it does the most work.
What are RTO and RPO?
Recovery time objective is how quickly a system must be available again. Recovery point objective is how much data loss is acceptable, expressed as time. An RPO of four hours means accepting the loss of up to four hours of transactions.
Both are business decisions derived from the impact analysis, not technical settings. They drive architecture and cost directly, and the cost curve is steep. Moving a system from a twenty-four hour RTO to a one-hour RTO typically multiplies the cost of protecting it several times over, which is why setting every system to one hour is the fastest way to make a continuity programme unaffordable.
How long does it take to build a business continuity plan?
For a mid-market organisation, six to twelve weeks. The impact analysis takes three to four weeks because it needs time from process owners. Plan development is three to four weeks. The first exercise follows a few weeks after.
The variable is availability of business people rather than consultant effort. An impact analysis workshop needs the person who actually runs the process, not a delegate, and scheduling that across eight or ten process areas is what sets the timeline. Organisations that resource it properly finish faster than ones that try to do it in the margins.
How often should the plan be tested?
Walkthrough quarterly, tabletop twice a year, simulation annually per critical system. Full failover where the recovery commitment is contractual or regulatory.
Testing frequency matters less than testing honestly. An annual tabletop that surfaces real findings is worth more than quarterly walkthroughs that everyone treats as a formality. The measure of a useful exercise is that it produced findings with owners and dates against them.
Do we need ISO 22301 certification?
Only if a customer, a tender or a regulator requires it. The standard is a sound structure and it is worth working to whether or not you certify. Certification adds audit cost and it adds credibility where credibility is being formally assessed.
We build to the ISO 22301 structure by default because it is well designed, without assuming you will certify. If certification becomes a requirement later, the work already done is in the right shape and the gap is audit preparation rather than a rebuild.
Who should own the business continuity plan?
The business, at executive level. IT owns the disaster recovery component. When continuity ownership sits in IT, the plan reliably becomes a systems document and the operational workarounds never get written.
This is the single most reliable predictor of whether a continuity programme produces anything useful. The impact analysis requires business managers to make judgements about their own processes, and those judgements cannot be delegated to a technical function or to an external adviser without the plan losing its authority.
What about load shedding and power continuity?
Power resilience is one dependency among many and it is handled as part of the utilities scenario. UPS sizing for critical equipment, generator integration where it exists, failover connectivity and cloud-hosted workloads that are unaffected by site power all form part of the design.
The reason we treat it as one dependency rather than a headline is that organisations that plan only for power are frequently exposed on things that are more likely to affect them, such as a key supplier failing or a single point of knowledge leaving. The impact analysis ranks dependencies by consequence rather than by familiarity.
Can you work with our existing plan?
Yes, and reviewing an existing plan is usually the better starting point. Most plans we see have sound intent and three specific gaps: no impact analysis behind the numbers, no documented workarounds and no evidence of testing.
A review against those three points takes a few days and it tells you whether the plan needs updating or rebuilding. Where the structure is sound we work with it, because a plan the organisation already recognises has a better chance of being used than a new one that arrives complete.
How do we keep the plan current?
Scheduled review at least annually, change-triggered review whenever a system, site, supplier or key role changes, quarterly contact verification and proper version control with a single controlled copy.
Plan decay is predictable. Contact details go first, then system details, then process descriptions. A plan last reviewed two years ago will name people who have left and systems that have been replaced, which is discovered at the point of use. Maintenance is a small standing commitment and it is what preserves the value of the original work.
When is a full continuity programme more than you need?
When you are a single-site organisation with straightforward operations, no contractual recovery commitments and no regulatory obligation, a focused disaster recovery plan and tested backups will cover most of your realistic exposure at a fraction of the cost.
Not every organisation needs the full apparatus. What everyone needs is tested backups, a documented recovery sequence and a contact list that works offline. If that is where you are, do those three things properly and stop there. We will tell you when that is the right answer rather than scoping a programme around it, and we would rather you spent the difference on the backup testing.