| 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. Most businesses that have one have never tested it. |
Most NZ businesses believe they are prepared for a major disruption.
The national numbers suggest otherwise. In its Cyber Security Insights report for the third quarter of 2025, the National Cyber Security Centre recorded 1,249 incident reports and NZ$12.4 million in direct financial losses, a 118 percent increase on the $5.7 million reported the previous quarter. The NCSC attributed the jump to a small number of high-value reports involving the unauthorised or falsified transfer of money, and named business email compromise as the driver.
This guide covers what a business continuity plan needs to contain, why testing decides whether it works, and how to build one that holds up when disruption arrives.
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.
| BCP Component | What It Covers | Why It Matters |
|---|---|---|
| Risk Assessment | Identify the threats most likely to disrupt operations: cyber attacks, natural disasters, power failures, supplier loss, staff unavailability | Attack timelines have compressed from weeks to hours. A risk assessment has to reflect how fast things move now, not how they moved when it was written |
| Business Impact Analysis | Define which systems and functions are critical, and set Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for each | Downtime costs mount from the first hour. Knowing your RTO before an incident removes guesswork at the worst possible moment |
| Recovery Procedures | Step-by-step instructions for restoring critical systems, prioritised by business impact | Ransomware now targets backups first. Recovery procedures have to account for compromised backups and staged restoration |
| Communication Plan | Who contacts staff, clients, suppliers, regulators and insurers, in what order and through what channels | When primary systems are down, your usual communication channels may be down with them. Off-system contact lists and pre-drafted notices are essential |
| Roles and Responsibilities | Named individuals responsible for each recovery function, with named alternates for key roles | Staff changes make responsibility maps go stale. Plans need reviewing whenever key people join or leave |
| Tested Restore Procedures | Regular tests confirming that backup data can actually be restored within the RTO | A backup nobody has ever restored from is an assumption. Quarterly restore tests are what turn it into a capability |
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. Actually restore data from your backups quarterly, instead of only confirming the backup job ran. Check the restored data is complete, uncorrupted and recoverable inside your RTO
- 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 target your backups first
Ransomware operators commonly spend weeks inside a network before triggering encryption. During that time they locate your backup systems and either encrypt them alongside everything else or delete them to remove your recovery options. A business continuity plan that assumes backups will be available and clean after an attack rests on the exact assumption attackers work to destroy.
The answer is immutable and air-gapped backups: copies that cannot be altered or deleted through compromised credentials, and offline copies out of reach of network-level attacks. Businesses whose backup copies survive intact recover materially faster than those whose backups are encrypted with everything else. Our cyber resilience guide covers how backup strategy fits the broader resilience picture.
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.
Step 1: 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.
Step 2: 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.
Step 3: Build your recovery procedures around worst-case scenarios
Most BCPs are built around optimistic scenarios where the attack is caught early, backups are clean and key staff are available. Build yours around the awkward version: backups compromised, decision-maker unreachable, primary communications offline. A plan that works in the worst case works in all of them.
Step 4: 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. Named individuals with documented alternates are the only way to guarantee cover.
Step 5: Test quarterly, review annually
Run backup restore tests every quarter. Run tabletop exercises every six months. Run a full simulation at least once a year. Review the whole plan annually, and again after any significant change to your systems, staff or threat environment. A plan last reviewed three years ago describes a business you no longer run.
Step 6: Align with NZ Privacy Act obligations
If a disruption causes a privacy breach that is likely to cause serious harm, the Privacy Act 2020 requires you to notify the Office of the Privacy Commissioner. 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 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 your actual restore capacity takes 72 gives you false confidence, not protection. Recovery targets have to be based on tested restore times.
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 helps South Island businesses build, test and maintain business continuity plans that perform under real conditions. Our teams in Christchurch and Dunedin integrate continuity planning 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 offer a no-obligation review 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.
Why do so many businesses skip business continuity planning?
The gap is rarely awareness. Most owners know the risk exists. Continuity planning gets deprioritised because it competes with prevention and detection spending, produces nothing visible while everything is working, and has no deadline attached until an incident supplies one.
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?
Backup restore tests should run quarterly. Tabletop exercises should run every six months. Full simulations should run at least annually. 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 are copies that cannot be altered, encrypted or deleted, even by a compromised administrator account. They matter because ransomware operators specifically seek out and destroy reachable backups before launching an attack. Businesses whose backup copies survive intact recover materially faster, which is why immutable and air-gapped copies are now a standard part of a workable plan.
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 works with South Island businesses from offices in Christchurch and Dunedin to build, test and maintain continuity plans integrated with managed IT, cloud infrastructure and cyber security. That includes backup architecture review, recovery procedure documentation, tabletop exercise facilitation and Privacy Act compliance support, so continuity planning is part of your IT environment rather than a one-off project.
