| BCDR, business continuity and disaster recovery, is the combined strategy that keeps your business operating during a disruption and restores it fully afterwards. Backup is one component of it. Backup protects copies of your data. BCDR protects the operation: your people, your systems, your communication, your clients, and your ability to earn while everything is broken. |
Plenty of businesses treat a backup as the whole answer. Survey evidence suggests confidence tends to run ahead of capability.
In Unitrends’ State of Backup and Recovery Report 2025, a global survey of more than 3,000 IT professionals, over 60% of organisations believed they could recover from a downtime event within hours. Only 35% actually could.
Local dependencies add their own layer. In January 2026 a third-party hardware failure disrupted clinical systems across the lower South Island for 36 hours, from the early hours of the 13th to the afternoon of the 14th, with systems progressively restored and staff at Dunedin, Invercargill and Lakes hospitals working on pen and paper in the meantime. Nothing was hacked. A supplier’s hardware failed.
This guide covers what separates backup from a BCDR strategy, what has changed in the threat that made the distinction urgent, and what a BCDR strategy for a New Zealand business has to contain.
What Is the Difference Between Backup and BCDR?
Backup stores copies of your data, and BCDR keeps the business running while those copies are being used. They are related but they answer different questions, and confusing them is how a business ends up calling a storage arrangement a BCDR plan.
| Backup | BCDR | |
|---|---|---|
| What it does | Stores copies of your data at a point in time | Keeps the business operating during a disruption and restores it fully afterwards |
| What it protects | Data: files, databases, emails, documents | The whole operation: data, systems, people, communication, suppliers, clients |
| Primary use | Recovering lost or corrupted data | Surviving ransomware, hardware failure, natural disaster, power loss or supplier failure |
| Recovery scope | Files and data | Critical systems, staff roles, client communication, regulatory obligations, revenue |
| Testing | Restore checks for completeness and usability, since a backup nobody has restored is an assumption rather than a capability | Technical recovery tests plus exercises for people, decisions and workarounds |
| Against ransomware | Protected recovery copies, subject to clean restore points and access controls | Containment, safe recovery, business decisions, communications and continuing operations |
The clearest way to put it: a backup tells you where your data is. BCDR tells you what your finance manager does in hour one of a ransomware attack, how you reach clients when email is down, which systems come back first, and how you notify the Privacy Commissioner if personal information has been exposed.
Backups are necessary and they are not a strategy. Our data backup strategy guide covers the technical foundation in detail.
Why Has BCDR Changed?
Because deliberate attacks now sit alongside the accidental failures, and they behave differently. Backup-as-protection was designed around hardware failure and someone deleting the wrong folder. Those causes are still with us, as the hospital outage shows, but they are not the ones that go looking for the backups.
Ransomware now targets the backups first
Ransomware operators frequently spend time inside a network before triggering encryption, and finding the backup systems is part of what that time is for, either encrypting them alongside everything else or deleting them outright to remove your options. How much warning a business gets varies considerably.
Sophos measured what that does to outcomes in The Impact of Compromised Backups on Ransomware Outcomes, based on 2,974 organisations of 100 to 5,000 staff across 14 countries that had been hit by ransomware in the previous year. Among victims whose backups survived, 46% were fully recovered within a week. Where the backups had been compromised, that fell to 26%. New Zealand was not one of the countries surveyed, so read it as the shape of the problem rather than a local measurement.
Cloud backups sitting in the same environment as your production systems can be reachable with the same credentials, depending on how accounts and permissions are separated. Network-connected backup appliances can be encrypted along with everything else. Whether either happens turns on the access controls in place, which is the thing worth establishing rather than assuming.
Plan without assuming a warning period
An attack can progress a long way before the business recognises it. Plan for protected recovery copies, containment and a safe restoration process rather than for a detection window you can count on. Our guide to cyber resilience covers what to plan for once detection stops being the deciding factor.
New Zealand risks need New Zealand planning
A plan bought off the shelf still has to be tested against where you actually operate. Earthquakes and flooding have disrupted data centres in multiple regions. In January 2026 a supplier hardware failure disrupted clinical systems at Dunedin, Invercargill and Lakes hospitals for 36 hours. Regional connectivity loss from a single point of failure has isolated whole communities.
A BCDR plan for a New Zealand business has to cover physical infrastructure alongside cyber threats, including what happens when your cloud provider’s local connectivity is affected rather than your own systems.
What Must a Complete BCDR Strategy Include?
Six areas to work through: protected backup copies, tested recovery objectives, named roles, a recovery approach for each critical activity, communication protocols, and a testing schedule that actually runs. How far you take each one depends on what the business can afford to lose and for how long.
- Protected backup copies. Immutable storage can prevent copies being changed or deleted for a defined retention period, though how strong that is depends on the product, the mode and the configuration, and some modes can be overridden by an account holding the right permission. Isolating backup access and keeping an offline copy are separate controls that reduce exposure further. Immutable, offline and air-gapped are not interchangeable terms. The 3-2-1-1 pattern is useful shorthand: three copies, two media types, one offsite, one offline.
- Tested restore procedures with real RTOs and RPOs. Recovery Time Objective is how long you can be without a system. Recovery Point Objective is how much data you can afford to lose. Both need defining for every critical system, and both need testing rather than assuming.
- Named roles and decision authority. Every procedure needs an owner and a deputy. Who declares the incident? Who calls clients? Who decides between restoring and failing over? Who notifies the Privacy Commissioner?
- A recovery approach for each critical activity. Where waiting for a restore would exceed the downtime the business can carry, failover or another operating arrangement may be needed. Where a tested workaround holds the essential work, restoring within an agreed period may be enough. Check what your cloud provider supports and what stays your responsibility.
- Communication protocols held off-system. Contact lists, client notification templates and the regulatory escalation path under the Privacy Act 2020, stored somewhere reachable when your systems are not.
- A testing schedule that runs. Set the frequency around criticality, system changes and any contractual obligations. A starting point might be quarterly restore tests, six-monthly tabletop exercises and a wider annual exercise, adjusted to the business and repeated after significant changes to systems, staff or threat.
The recovery objectives are where plans most often come apart. A restore that takes fourteen hours in practice cannot be planned around a four-hour RTO, and you only find that out by running it. The gap between expectation and result in the Unitrends figures above is the same shape of problem.
Continuing to operate during the recovery is the part businesses most often skip, usually because backup feels like it covers the same ground. Some backup platforms do support instant recovery, running a workload from backup storage while the full restoration continues, which needs suitable infrastructure, capacity and testing rather than a stored copy alone. Where that is unavailable or not fast enough, failover to a secondary environment is the alternative, and on cloud infrastructure that usually means another region, though not every SaaS customer can choose or operate that themselves. On-premises it means secondary hardware or a cloud failover target standing ready.
The communication protocol is the item most often written and then stored in the worst possible place. Contact lists, client notification templates and the regulatory escalation path are worth nothing if they live on the file server that is currently encrypted. A BCDR plan needs them held somewhere reachable when nothing else is, and it needs someone to have checked in the last six months that the phone numbers still work.
Which Disruption Scenarios Must a New Zealand BCDR Plan Cover?
Four worth testing a plan against, as examples rather than a complete list. Loss of a key person, or of the identity service everything signs in through, belongs on the same list for most businesses.
Ransomware that has already reached the backups
Production systems are encrypted and the reachable backup copies are gone. The response draws on whatever copies were out of reach, isolates affected systems, moves critical work to the alternative that was planned for it, and follows the roles and communication plan already written down. Recovery copies and any failover target both need checking before use, because replication can carry corruption and malicious changes across with it. Without any of this in place beforehand, the response is improvisation under pressure.
Earthquake or flooding
Physical infrastructure is destroyed or unreachable and staff cannot get to the office. The BCDR response runs recovery from a geographically separate environment, enables remote working and starts the client communication protocol. A backup held on-premises in a building nobody can enter may be unavailable exactly when it is wanted, without being permanently lost.
Regional connectivity or power failure
South Island connectivity failures are not hypothetical and have happened repeatedly. A single fibre cut or a regional power event can disconnect an entire operation. The response calls on secondary connectivity, which only helps if it avoids the failed dependency, and on local cache for the applications that support it. This is the scenario most often missing from a plan written elsewhere.
Supplier or cloud provider failure
Most businesses now depend on several SaaS platforms, and the January 2026 hospital outage is the local reminder that a supplier’s hardware is your single point of failure too. The BCDR plan needs to say which systems are critical, which have alternatives, and what the manual fallback is for each.
How Do You Check Whether Your BCDR Plan Will Work?
Start with the activities the business cannot afford to lose. For each one, work through these questions and record what is still unresolved.
- What has to keep operating, and how long can it pause before the impact becomes unacceptable?
- How much recent data can you afford to lose, and does the backup arrangement actually support that recovery point?
- Could an attacker using a compromised production or administrator account alter or delete every usable copy?
- When was a real system or dataset last restored, and did the result meet the recovery time and data-loss objectives on paper?
- What will staff do while systems are unavailable, including when the office, the connection or the cloud service cannot be used?
- Who can declare an incident, approve recovery decisions, and act if the primary contact is unavailable?
- Can you reach the plan, the recovery credentials and the key contacts securely when normal systems are down?
- Who owns each unresolved gap, when will it be addressed, and when will the arrangements next be tested?
A single critical gap can stop a recovery, so prioritise what you find by its effect on essential work rather than by counting unanswered questions. Our cybersecurity risk assessment finds the specific ones before a disruption does it for you, and our business continuity planning guide covers what good testing looks like.
Frequently Asked Questions
What does BCDR stand for?
BCDR stands for business continuity and disaster recovery. Business continuity covers how the organisation keeps operating during a disruption. Disaster recovery covers how IT systems and data are restored afterwards. They work as one strategy and need to be coordinated, because a business can otherwise end up able to restore its data but unable to trade.
What is the difference between backup and BCDR?
Backup stores copies of your data at a point in time. BCDR is the wider strategy that keeps the business operating during a disruption and restores it fully afterwards. Backup is one component. Without tested recovery procedures, named roles, communication protocols and a way of continuing essential work, backup alone will not keep a business running while its systems are unavailable.
Is backup on its own still enough?
Usually not on its own. Ransomware operators commonly look for backup systems before triggering encryption, and copies reachable with the same credentials as production can be encrypted or deleted alongside it, depending on how access is separated. Backup also says nothing about how the business keeps working while systems are down. A backup that has never been restored is an assumption rather than a capability, and the difference only becomes visible on the day it matters.
What are immutable backups and why do they matter?
Immutable storage prevents protected copies being changed or deleted for a defined retention period. How strong that protection is depends on the product, the mode and the configuration, and some modes can be overridden by an account holding the right permission, so it is worth establishing which you have. Immutability also does not prove a copy is clean, complete or restorable. It matters because looking for reachable backups is now a common step in a ransomware attack. Sophos found that among ransomware victims whose backups survived, 46% were fully recovered within a week, against 26% where the backups had been compromised.
What is the 3-2-1-1 backup rule?
Three copies of your data, on two different media types, with one offsite and one offline or air-gapped. The fourth element is the one that matters most now: a copy that is not reachable from the network an attacker is operating on. It is a design pattern rather than a test of whether a business has met its own recovery needs, and the version being used is worth stating, because offline, air-gapped and immutable describe different things.
What are RTO and RPO?
Recovery Time Objective is the maximum acceptable time to restore a system after a disruption. Recovery Point Objective is the maximum acceptable data loss, measured in time, so an RPO of four hours means losing up to four hours of work is tolerable. Both need defining per critical system and validating by actual restore testing, because an objective is a target rather than a guarantee and only a test shows whether it is achievable. Unitrends found more than 60% of organisations believed they could recover within hours and only 35% could.
How does BCDR deal with ransomware specifically?
It prepares the business to continue priority work and to recover safely afterwards. The response involves isolating affected systems, checking the recovery copies and the environment being restored into, restoring in priority order, and communicating with staff, customers and the relevant authorities. A failover target needs checking too, because replication can carry corruption or malicious changes across. Backup supports the restoration part; it is not the response plan, and restoring data does not undo information theft.
How often should a BCDR plan be tested?
Set the frequency around how critical the system is, how often it changes, and any contractual or regulatory requirements. A reasonable starting schedule is quarterly restore tests, six-monthly tabletop exercises and a wider recovery exercise annually, adjusted to the business rather than treated as an obligation that applies to everyone. Retest affected arrangements after significant changes, and check that staff can actually use the recovered service rather than only that the restore job finished.
Does every business need failover?
No. Failover is switching to a secondary system when the primary one fails, and it earns its cost where the business cannot tolerate the time a restore would take. Other activities may continue through a tested manual process or tolerate an agreed outage. Some backup platforms also support instant recovery, running a workload from backup storage while the full restore continues, which needs suitable infrastructure and testing. Choose the approach around business impact, recovery targets and what each system actually supports.
What does the Privacy Act require during a disruption?
If a privacy 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 affected people as soon as practicable, subject to the exceptions in the Act. An outage does not automatically trigger that, and the assessment is not limited to information being exposed. The plan should name who assesses the breach and manages notification, and hold the templates, the regulatory contact and the triggers somewhere reachable when systems are down.
What should a New Zealand plan cover that a generic one does not?
Earthquake and flooding risk to on-premises infrastructure, regional connectivity failures from single points of failure in South Island fibre, regional power events, and cloud provider outages affecting local availability. A plan bought off the shelf tends to be strong on cyber and light on the physical dependencies of wherever it is actually being used, which is the part worth adding rather than assuming.
How does Exodesk help with BCDR?
Backup architecture, cloud failover, restore testing, incident response and Privacy Act steps, and tabletop exercises, scoped to what a business needs rather than included automatically, working from our Christchurch and Dunedin offices. Where a plan already exists, the most useful first exercise is usually restoring something real and timing it against the RTO on paper.
NEXT STEP
When did you last restore something, and how long did it take?
If nobody can answer that, you have a backup rather than a recovery capability. We review what New Zealand businesses actually have, test it, and tell you plainly where the gaps are.
Or read more about our managed IT services.
