| A business continuity plan, or BCP, is a documented and tested framework setting out how a business keeps operating and recovers when something significant goes wrong, from a ransomware attack to a power failure or the loss of a key supplier. |
If your main systems were unavailable tomorrow, could your staff still take orders, contact customers and organise the day’s work?
Those are the questions a continuity plan exists to answer, and testing is what shows whether the answers hold. The plan sets out what has to keep moving, who decides what, how people work while systems are down, and what has to be restored in which order.
This guide covers what the plan needs to contain, how to keep working while systems are down, how to set recovery priorities, and what testing has to demonstrate before you can rely on it.
What Is a Business Continuity Plan and What Should It Cover?
A business continuity plan is not a backup strategy. Backups protect your data. A BCP protects the whole business: your people, your communication channels, your suppliers, your systems, and your ability to serve customers during and after a disruption.
The distinction matters because most NZ businesses that have invested in backup think they have continuity covered. They do not. A backup tells you where your data is. A BCP tells you what your finance manager does on day one of a ransomware attack, who speaks to your clients, which systems get restored first, and how you notify the Office of the Privacy Commissioner if personal data has been exposed. For how backups fit inside a wider continuity framework, our data backup strategy guide covers the technical foundation in detail.
1 Risk assessment
The threats most likely to disrupt you: cyber attacks, natural disasters, power failures, supplier loss and staff unavailability.
Threats and the business both change. An assessment from three years ago describes a business you may no longer run.
2 Business impact analysis
Which systems and functions are critical, with a recovery time objective (RTO) and recovery point objective (RPO) for each.
Knowing your RTO before an incident removes guesswork at the worst possible moment.
3 Recovery procedures
Step-by-step instructions for restoring critical systems, in order of business impact.
They must allow for backups being hit too, and for restoring in stages rather than all at once.
4 Communication plan
Who contacts staff, clients, suppliers, regulators and insurers, in what order and by which channel.
Your usual channels may be down with your systems, so keep contact lists and draft notices off-system.
5 Roles and responsibilities
A named person for each recovery function, with a named alternate for key roles.
Responsibility maps go stale as staff change. Review the plan whenever key people join or leave.
6 Tested restore procedures
Regular tests confirming that backup data can actually be restored within the RTO.
A backup nobody has restored from is an assumption. Quarterly restore tests turn it into a capability.
How Do You Keep Operating While Systems Are Unavailable?
Recovery gets the systems back. Continuity is what the business does in the meantime, and it is the half most plans leave thin. Work out which activities cannot simply stop, then decide how each one runs without the system it normally depends on. Business.govt.nz continuity guidance covers the same ground across people, suppliers, equipment, premises and data.
| Essential activity | Temporary arrangement to plan and test | What needs checking |
|---|---|---|
| Taking orders | An approved offline order form | Access, secure storage and reconciliation once systems return |
| Contacting customers | An alternative phone and contact-list arrangement | Availability if normal email and identity services are down too |
| Scheduling work | A controlled copy of the latest schedule | How staff record changes, and how duplicate jobs are prevented |
| Working from another location | Agreed premises, devices and connectivity | Capacity, access permissions and who is actually able to travel |
Those are illustrations rather than instructions, because the activities that matter depend on what the business does. For each arrangement you settle on, name an owner, decide how long it can reasonably run, and be honest about the point where it stops being adequate.
Three questions belong in the plan alongside them. Who decides the plan is active. Who can authorise emergency spending, and up to what limit. And where the plan itself can be read when the normal systems are the thing that is down.
Why Does a Tested Plan Matter More Than a Written One?
Because until you test it, you have no idea which of its assumptions are wrong.
Owners consistently expect to recover faster than they actually can. The plan assumes backups are clean, the key decision-maker is reachable, and the phones work. Real incidents rarely arrive that tidily, and the first time a business discovers which of those assumptions was wrong should not be during the incident itself.
Testing exposes the gaps that paperwork hides: backup systems that are corrupted, communication channels that go down alongside primary systems, staff who do not know their roles, and recovery procedures that depend on tools or people no longer available. Our BCDR guide covers the difference between having a recovery plan and having one that performs under pressure.
What effective testing looks like
- Tabletop exercises. Walk your response team through a realistic scenario, such as ransomware hitting the file server at 9am on a Monday, and find the decision points, gaps and communication failures in a low-stakes setting
- Backup restore tests. Restore data from your backups on a set cycle, rather than only confirming the backup job ran. Check the restored data is complete, uncorrupted and recoverable inside your RTO. A restored file demonstrates something different from a working application, which is different again from a staff member completing a real customer transaction, so be clear which of the three a test proved
- Communication drills. Test your off-system contact lists and notification procedures without relying on systems that may be offline during a real incident
- Full simulations. At least annually, run a realistic disruption scenario across multiple functions to see how the plan holds up organisation-wide
How Does Ransomware Change Business Continuity Planning?
It changes the central assumption, because attackers now go after the thing your recovery depends on. Understanding how modern ransomware operates is essential to building a BCP that addresses the actual threat.
Attackers may go after your backups
Attackers who reach a network often look for the backup systems, and where they can reach them they may encrypt or delete those copies to remove the recovery option. How long they are inside before that happens varies: some intrusions run for weeks and give a business time to notice, others move within hours. Plan for both, and do not assume you will have weeks of warning.
What follows is that a continuity plan which assumes backups will be available and clean after an attack rests on an assumption an attacker may have worked to remove. Check it rather than inherit it.
The usual answers are immutable and air-gapped copies. Immutable backups protect retained copies against alteration or deletion for a defined retention period, subject to the technology and how it is configured, and they still need protected access, a suitable retention period and restore testing behind them. Air-gapped copies sit out of reach of network-level attacks. Businesses whose backup copies survive intact recover faster than those whose backups are encrypted with everything else. Our guide to the wider resilience picture covers how backup sits alongside the decisions that follow an attack.
Recovery takes longer than most businesses expect
Full recovery from a serious ransomware incident is commonly measured in weeks, not the days most owners assume. Restoring systems is only part of it. Rebuilding clean, verifying data integrity, reconnecting integrations and working through the backlog that piled up while you were down all take time nobody budgets for.
Realistic recovery targets and tested restore procedures are the only reliable foundation for continuity planning. A plan built on hoped-for timelines is a plan that will disappoint you on the day.
How Do You Build a Business Continuity Plan?
Every business continuity plan looks different depending on the size, industry and risk profile of the organisation. This framework applies across all of them.
Identify your critical functions and systems
Start with a question: if everything went offline right now, what would you need back first to operate at all? For most NZ businesses that means financial systems, customer records, email and core operational software. Rank them by impact, then build your RTO and RPO around those rankings.
Assess your realistic threats
NZ businesses face a particular threat profile. Ransomware and cyber attacks lead, followed by power and connectivity failures, extreme weather, and the loss of a supplier or a key person. Weight these proportionally instead of treating every threat as equally likely.
Build your recovery procedures around worst-case scenarios
Plans are often built around the tidy version, where the problem is caught early, backups are clean and the right people are available. Test yours against the awkward version as well: backups unavailable, the decision-maker unreachable, primary communications offline. Covering the harder case does not guarantee every scenario, because real incidents combine failures in ways nobody scripted, but it does expose the assumptions the tidy version hides.
Document roles, not just procedures
Every procedure in your BCP needs a named person responsible for carrying it out, and a named alternate. A recovery procedure that says “IT will restore the file server” fails the week your IT person is on leave. Naming an alternate improves the odds of cover rather than guaranteeing it, because that person still needs the access, the training and the availability to step in, so check all three when you write the name down.
Set a testing programme and stick to it
Build the programme around the activities the business depends on rather than around a fixed calendar. Agree the scope and frequency of restore tests, scenario exercises and communication checks, re-test whatever a significant change affects, and record what each exercise actually demonstrated.
As a starting point to adjust from, quarterly restore tests, six-monthly tabletop exercises and an annual full simulation suit most small businesses. Business.govt.nz recommends exercising a continuity plan at least once a year, which is the floor rather than the target. Review the whole plan annually and after any significant change to systems, staff or the threat environment, because a plan last reviewed three years ago describes a business you no longer run.
Align with NZ Privacy Act obligations
Your plan should say who assesses whether a disruption has caused a privacy breach, who coordinates advice, and who handles any notification. Where a breach has caused or is likely to cause serious harm, the Privacy Act 2020 requires notification to the Office of the Privacy Commissioner and to the people affected, as soon as you are practicably able, subject to the exceptions the Act allows. Section 118 of the Act makes it an offence for an agency to fail to notify without reasonable excuse, with a fine on conviction of up to $10,000.
Your BCP needs a clear notification protocol, a designated contact for regulatory communication, and pre-drafted templates. Building that in beforehand means you are not drafting a regulator notice while the business is down. Our cybersecurity risk assessment guide covers the compliance landscape in more detail.
What Should You Receive After a Continuity Test?
A test that leaves no record proves nothing a month later. Whoever runs it, ask for these five things in writing.
- Test scope and scenario. What was tested, under which conditions, and what was deliberately excluded.
- Recovery results. The required recovery time against the time the test actually took.
- Data recovery point. How current the restored data was.
- Business validation. Whether a staff member could complete the agreed essential task, not only whether a system came back up.
- Issues and actions. Each gap, its owner, a due date, and whether a retest is needed.
The last item is what separates testing as a habit from testing as a formality. A gap with no owner and no date is a note, not an action.
What Makes a Business Continuity Plan Fail?
Confusing a backup with a BCP
Backups are one component of a business continuity plan. They protect your data. They do not tell your team who makes decisions during an outage, how you communicate with clients, which systems come back first, or what your regulatory obligations are. Treating the two as equivalent leaves critical gaps.
Building the plan and never testing it
Documentation is not readiness. A business continuity plan that has never been tested will fail in ways testing would have exposed: corrupted backups, stale contact lists, staff who do not know their roles, procedures referencing tools or people that no longer exist.
Setting unrealistic recovery targets
A plan promising recovery in 24 hours when the tested restore takes 72 gives false confidence rather than protection. The fix is not to move the target to 72 hours and call it solved.
The business requirement sets the target: how quickly each critical activity needs to resume, and how much data loss is tolerable. Testing establishes whether the current arrangements meet it. Where the two do not match, record the gap, its business impact, and which of the three answers you are choosing: improve the recovery capability, put a workable alternative in place for the interval, or accept the impact deliberately and write down that you have.
Failing to update after changes
A BCP written when you had 10 staff, on-premises systems and one office is not fit for purpose at 40 staff with cloud infrastructure and remote workers. Major changes to people, systems or locations should trigger an immediate review instead of waiting for the annual cycle.
Does Your Business Continuity Plan Actually Work?
Exodesk covers the technology half of continuity for New Zealand businesses: the recovery arrangements, the restore testing and the evidence that comes out of it. The business side, which activities matter most, what disruption the business can absorb and which risks it accepts, stays with management, because those are commercial decisions rather than technical ones. From offices in Christchurch and Dunedin we join continuity planning up with your managed IT services, cloud infrastructure and cyber security, so your BCP stays current with the systems it is meant to protect.
If your plan has not been tested in the past 12 months, it may no longer reflect your current systems or the current threat environment. We are happy to look at it with you to identify what needs updating.
Contact us today to discuss how we can help your business or connect with us on LinkedIn to stay updated with more insights.
Frequently Asked Questions
What is a business continuity plan?
A business continuity plan is a documented, tested framework defining how an organisation keeps operating and recovers after a significant disruption. It covers people, communication, systems, suppliers and regulatory obligations, not only technology. A backup strategy protects data; a BCP protects the whole operation and sets out the order of restoration.
What is the difference between a business continuity plan and a disaster recovery plan?
A disaster recovery plan focuses on restoring IT systems and data after a disruption. A business continuity plan is broader, covering how the whole organisation keeps functioning, including staff responsibilities, client communication, supplier relationships and regulatory duties. Most NZ businesses need both, integrated into one operational framework.
Who should own the business continuity plan?
A named person in the business, usually an owner, general manager or operations manager, rather than the IT provider. The owner decides which activities matter most, approves what disruption the business can absorb, and calls the plan active when something happens. Your IT provider owns the technology parts inside it and the evidence that they work. A plan owned by nobody in the business is the one that goes stale.
Can we use a business continuity plan template?
A template is a reasonable starting structure and a poor finished plan. It gives you the headings and reminds you of things you would forget, which is worth having. What it cannot supply is which of your activities cannot stop, how long each one can run on a workaround, who decides what, and whether your recovery arrangements actually meet those requirements. Fill it in against your own operation and then test it, because an untested template is a document about somebody else’s business.
What should a business continuity plan include?
A complete plan should include a risk assessment, a business impact analysis with RTO and RPO targets, recovery procedures prioritised by business impact, a communication plan covering staff, clients and regulators, named roles with alternates for every recovery function, tested backup restore procedures, and a Privacy Act notification protocol for breach scenarios.
How often should a business continuity plan be tested?
Set the frequency against the activities the business depends on rather than a fixed rule. As a starting point, quarterly restore tests, six-monthly tabletop exercises and an annual full simulation suit most small businesses, and Business.govt.nz recommends exercising a plan at least once a year as a floor. Review the whole plan every year and immediately after significant changes to systems, staff or the threat environment.
How does ransomware affect business continuity planning?
Ransomware changed continuity planning because attackers now target and destroy backup systems before triggering encryption. A BCP assuming backups will be clean and available afterwards rests on a false premise. Effective planning requires immutable and air-gapped backups, staged recovery procedures, and recovery timelines built on worst-case rather than best-case assumptions.
What is an RTO and RPO in a business continuity plan?
RTO, or Recovery Time Objective, is the maximum acceptable time to restore a system or function after a disruption. RPO, or Recovery Point Objective, is the maximum acceptable data loss measured in time. An RPO of four hours means you can accept losing up to four hours of data. Both should be set for every critical system and proven through testing.
What are immutable backups and why do they matter for business continuity?
Immutable backups protect retained copies against alteration or deletion for a defined retention period. How strong that protection is depends on the technology and the configuration: some implementations let an authorised administrator shorten or bypass the retention, others do not, so check which one you have. They matter because attackers who reach a network often look for the backups, and copies that survive intact recover faster. Immutability still needs protected access, a suitable retention period and restore testing behind it.
Do NZ businesses have legal obligations under the Privacy Act after a disruption?
Yes. If a disruption causes a privacy breach likely to cause serious harm, the Privacy Act 2020 requires notification to the Office of the Privacy Commissioner and, in most cases, to the people affected. Section 118 of the Act makes failing to notify without reasonable excuse an offence. Your plan should include pre-drafted templates, a designated regulatory contact and clear triggers for when the duty applies.
How does Exodesk help NZ businesses with business continuity planning?
Exodesk covers the technology half, from offices in Christchurch and Dunedin, for businesses across New Zealand. That means reviewing how backups are architected and protected, documenting the recovery procedures, running restore tests and handing you the evidence they produce, so continuity is part of how the IT environment is run rather than a one-off project. Deciding which activities matter most, and what disruption the business can absorb, stays with management
Would the plan hold if you needed it on Monday?
A plan nobody has tested is a document rather than a capability. A free IT assessment looks at the parts continuity depends on, including how your backups are configured and protected and what would have to come back first.
Or read more about IT consulting.
