| BCDR — business continuity and disaster recovery — is the combined strategy that keeps your business operating during a disruption and restores it fully after one. Backup is one component of that strategy. It protects copies of your data. BCDR protects your entire operation: your people, your systems, your communication, your clients, and your ability to generate revenue when everything goes wrong. |
Most NZ businesses believe they are protected because they have a backup. The research tells a different story.
More than 60% of organisations believe they could recover from a major disruption in under a day. In practice, only 35% achieve that. Less than 7% recover from a ransomware attack within 24 hours. More than a third take longer than a month. And NZ geography adds a layer of risk that many businesses have not built into their recovery planning at all — a South Island hospital IT outage caused by third-party hardware failure left staff working on pen and paper for 36 hours in 2025.
This guide explains the difference between backup and BCDR, why that difference matters more in 2026 than it ever has, and what a BCDR strategy for a NZ business actually needs to include.
| 2026 research: 60% of organisations believed they could recover from a disruption within a day. Only 35% achieved that. Less than 7% recover from ransomware within 24 hours. More than a third take over a month. NZ downtime costs up to NZ$13,000 per minute for critical operations. |
What Is the Difference Between Backup and BCDR?
Backup and BCDR are related but they solve different problems. Understanding the distinction is the starting point for building genuine resilience rather than the illusion of it.
| Backup | BCDR | |
| What it does | Stores copies of your data at a point in time | Keeps your business operating during a disruption and restores it fully afterwards |
| What it protects | Data — files, databases, emails, documents | The entire operation — data, systems, people, communication, suppliers, clients |
| Primary use case | Recovering lost or corrupted data | Surviving ransomware, hardware failure, natural disaster, power outage, or supplier loss |
| Recovery scope | Files and data | Critical systems, staff roles, client communication, regulatory obligations, and revenue continuity |
| Tested regularly? | Often not — 58% of backups fail during a real recovery event | Must be tested quarterly through tabletop exercises and actual restore simulations |
| Ransomware answer | Partial — if backups are clean and accessible | Complete — immutable and air-gapped backups plus failover, roles, and communication |
The clearest way to understand the difference is this: a backup tells you where your data is. BCDR tells you what your finance manager does on hour one of a ransomware attack, how you communicate with clients when your email is offline, which systems come back first, and how you notify the Privacy Commissioner if personal data has been compromised.
Backups are essential but they are not a BCDR strategy. For a deeper look at how backup fits within a broader recovery framework, our data backup strategy guide covers the technical foundation in detail.
Why BCDR Has Changed in 2026
The original logic of backup-as-protection made sense when the primary threats were hardware failure and accidental deletion. That threat environment no longer exists.
Ransomware now specifically targets your backups
This is the most important shift in the BCDR landscape since 2023. Modern ransomware operators spend weeks inside a network before triggering encryption. During that time, their primary objective is locating and destroying your backup systems — either encrypting them alongside everything else or deleting them to remove your recovery options.
Research shows that organisations with uncompromised backups recover within a week 46% of the time. When backups are compromised, that falls to 25%. The gap between those two numbers — 46% versus 25% — represents the difference between a serious but contained incident and a potentially business-ending one.
Standard cloud backups stored in the same environment as your production systems are accessible to attackers who have compromised your credentials. Network-connected backup devices are encrypted alongside everything else. A backup strategy that does not account for this attack pattern is not providing the protection you think it is.
AI has compressed attack timelines
AI-powered attacks now compress the timeline from initial access to full encryption from weeks to hours in some cases. The window for detection and containment has narrowed significantly. A BCDR strategy built around a 24-hour detection window may not be adequate for the speed of current attacks. Our cyber resilience guide covers how detection capability fits within the broader resilience framework.
NZ-specific risks require NZ-specific planning
New Zealand’s geography creates disruption risks that generic BCDR frameworks do not address. Earthquakes and flooding have disrupted data centres in multiple NZ regions. A South Island hospital experienced a 36-hour IT outage from third-party hardware failure in 2025, forcing staff to revert to manual processes. Regional connectivity loss from a single infrastructure point of failure has isolated entire communities.
A BCDR strategy for a NZ business must account for physical infrastructure risks alongside cyber threats — including what happens when your cloud provider’s NZ connectivity is affected, not just your own systems.
What a Complete BCDR Strategy Must Include in 2026
A genuine BCDR strategy in 2026 requires components that were optional or theoretical three years ago. The following elements are now baseline requirements.
Immutable and air-gapped backups
Immutable backups cannot be altered, encrypted, or deleted — even by a compromised administrator account. Air-gapped backups are physically or logically disconnected from your network, inaccessible to an attacker who has compromised your environment. The 3-2-1-1 rule defines the minimum standard: three copies of your data, on two different media types, with one offsite and one offline.
Without immutable and air-gapped copies, your backup strategy is vulnerable to exactly the attack pattern that ransomware operators now deploy as standard. This is not a premium option — it is the baseline for any NZ business that wants a reliable recovery option when ransomware strikes.
Tested restore procedures with realistic RTOs and RPOs
Recovery Time Objective (RTO) defines how long you can afford to be without a system. Recovery Point Objective (RPO) defines how much data loss is acceptable. Both must be defined for every critical system — and both must be tested, not assumed.
More than 60% of organisations believed they could recover within a day. Only 35% achieved it in practice. The gap exists because RTOs were set aspirationally rather than tested under realistic conditions. A restore test that takes 14 hours in practice cannot be planned around a 4-hour RTO.
Defined roles and decision authority
A BCDR plan without named individuals responsible for each recovery function is not a plan. Every procedure must have a named owner and a named backup. Who declares the incident? Who contacts clients? Who makes the call to restore from backup versus failover? Who notifies the Privacy Commissioner? These decisions made in the middle of a crisis will be slower, more error-prone, and more expensive than the same decisions made in a documented plan before anything goes wrong.
Failover capability for critical systems
Failover means switching automatically or rapidly to a secondary system when a primary system fails. For NZ businesses on cloud infrastructure, this typically means geographic redundancy — your workloads can run from a different region if your primary environment is unavailable. For businesses with on-premises infrastructure, this requires secondary hardware or cloud-based failover capability.
Failover is what separates a business that stays operational during a disruption from one that goes dark. Backup alone cannot provide this — you cannot run your business from a backup file while your systems are unavailable.
Communication protocols for clients, staff, and regulators
When your primary communication systems go offline, how do you contact your clients? How do you coordinate your recovery team? Who has the list of key contacts that is not stored on a system that is currently encrypted?
A BCDR plan must include off-system contact lists, pre-drafted client notification templates, and a clear escalation path for regulatory notification under the NZ Privacy Act 2020. These are not details to work out under pressure — they are decisions that must be made in advance and documented where they can be accessed when primary systems are unavailable.
Regular testing and annual review
A BCDR plan that has never been tested is a document, not a capability. Tabletop exercises should run every six months. Backup restore tests should run quarterly. Full simulations should run annually. The plan should be reviewed and updated after every significant change to systems, staff, or the threat environment. Our business continuity planning guide covers what effective testing looks like and how to run it.
The NZ-Specific Disruption Scenarios Your BCDR Must Address
Generic BCDR frameworks are built for generic businesses. NZ businesses operate in a specific environment with specific risks. A BCDR strategy that does not address the following scenarios is incomplete.
Ransomware attack with backup targeting
Attackers encrypt production systems and have already deleted or encrypted backup copies. Your BCDR response activates your immutable and air-gapped backups, isolates affected systems, initiates failover for critical services, and follows your pre-defined roles and communication plan. Without each of these elements in place before the attack, the response degrades into improvisation.
NZ natural disaster — earthquake or flooding
Physical infrastructure is destroyed or inaccessible. Staff cannot reach the office. Your BCDR response activates cloud-based recovery from a geographically separate environment, enables remote working capability for staff, and initiates your client communication protocol. A backup stored on-premises in a building that is physically inaccessible provides no recovery capability.
Regional connectivity or power failure
South Island connectivity failures are not hypothetical — they have occurred repeatedly. A single fibre cut or a regional power event can disconnect entire operations. Your BCDR response activates secondary connectivity options and local cache capability for critical systems. A BCDR plan for a South Island NZ business must account for regional infrastructure dependencies, not just cyber threats.
Supplier or cloud provider failure
Cloud sprawl means most NZ businesses now depend on multiple SaaS platforms. If a critical supplier experiences an outage or a cloud provider has a regional failure, your BCDR plan must define how you operate in that scenario. This includes knowing which systems are critical, which have alternatives, and what manual fallback processes exist for each.
How to Assess Whether Your Current BCDR is Adequate
Answer these questions honestly. Each one represents a gap that attackers will find before you do if it exists.
- Are your backups immutable — can they be altered or deleted by a compromised account?
- Are you storing a backup copy offline and air-gapped from your network environment?
- When did you last actually restore data from your backups? Not check that the backup ran — actually restore?
- Do you have documented RTOs and RPOs for every critical system that have been tested under realistic conditions?
- Does every recovery procedure in your plan have a named person responsible and a named backup?
- Does your plan include a client communication protocol using off-system contact information?
- Does your plan address what happens if your primary cloud provider’s NZ region is unavailable?
- Has your plan been tested in the past six months in any form?
If you answered no to two or more of those questions, your BCDR has gaps that represent real operational risk. Our cybersecurity risk assessment service can identify specific gaps before a disruption forces them into the open.
Does Your Business Have BCDR — or Just Backup?
Exodesk works with South Island businesses in Christchurch and Dunedin to build BCDR strategies that go beyond backup — including immutable backup architecture, failover capability, tested restore procedures, and incident response planning integrated with your managed IT environment.
If your current recovery strategy has not been tested in the past 12 months, or if it was built before ransomware backup targeting became standard, it may not provide the protection you think it does. We offer an honest, no-obligation review of your current BCDR posture.
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 About BCDR
What does BCDR stand for?
BCDR stands for business continuity and disaster recovery. Business continuity covers how your organisation keeps operating during a disruption. Disaster recovery covers how IT systems and data are restored after one. Together they form a single integrated strategy that determines whether your business survives a serious incident or collapses under it.
What is the difference between backup and BCDR?
Backup stores copies of your data at a point in time. BCDR is the broader strategy that keeps your business operational during a disruption and restores it fully afterwards. A backup is one component of BCDR. Without the rest — failover, tested recovery procedures, defined roles, and communication protocols — backup alone will not keep your business running when systems are unavailable.
Why is backup alone not enough in 2026?
Modern ransomware operators specifically target and destroy backup systems before triggering encryption. Standard cloud backups accessible via compromised credentials and network-connected backup devices are frequently encrypted alongside production systems. Additionally, more than 58% of backups fail during a real recovery event. A backup strategy that does not include immutable and air-gapped copies, tested restore procedures, and failover capability is not providing reliable protection against the current threat landscape.
What are immutable backups and why are they essential for BCDR?
Immutable backups are backup copies stored in a write-once, read-many format that cannot be altered, encrypted, or deleted — even by a compromised administrator account. They are essential because ransomware operators now routinely target and destroy accessible backups before triggering encryption. Research shows organisations with uncompromised backups recover within a week 46% of the time, compared to just 25% when backups are compromised. Immutable and air-gapped backups are the non-negotiable foundation of any BCDR strategy in 2026.
What is the 3-2-1-1 backup rule?
The 3-2-1-1 rule specifies three copies of your data, stored on two different media types, with one copy offsite and one copy offline or air-gapped. The fourth element — the offline copy — is the critical addition for 2026. It ensures that even if an attacker compromises every network-accessible system including cloud backups, an offline copy remains available for recovery. The 3-2-1-1 rule is now the baseline standard for any BCDR strategy that accounts for ransomware backup targeting.
What is an RTO and RPO in the context of BCDR?
RTO — Recovery Time Objective — is the maximum acceptable time for restoring a system or function after a disruption. RPO — Recovery Point Objective — is the maximum acceptable data loss, measured in time. For example, an RPO of four hours means you can accept losing up to four hours of data. Both must be defined for every critical system and validated through actual restore testing, not assumed. More than 60% of organisations believe they can recover within a day — only 35% achieve it in practice because RTOs are set aspirationally rather than tested.
How does BCDR address ransomware specifically?
A complete BCDR strategy addresses ransomware through multiple layers: immutable and air-gapped backups that attackers cannot reach or destroy, endpoint detection to identify unusual file encryption behaviour early, network segmentation to limit lateral movement, failover to clean systems that were not affected, and a tested incident response plan that defines exactly who does what from the moment an attack is detected. Backup alone addresses none of these except the last restore point — and only if the backup itself was not compromised.
What NZ-specific risks should a BCDR strategy cover?
NZ businesses face specific risks that generic frameworks do not address: earthquakes and flooding that can physically destroy or make inaccessible on-premises infrastructure, regional connectivity failures from single points of failure in South Island fibre networks, regional power events that disconnect entire communities, and cloud provider outages affecting NZ-region availability. A BCDR strategy for a NZ business must address physical infrastructure risks alongside cyber threats and account for geographic and connectivity dependencies.
How often should a BCDR plan be tested?
Backup restore tests should run quarterly — actually restoring data and verifying it is complete and usable within the defined RTO. Tabletop exercises should run every six months, walking the response team through a realistic scenario to identify gaps and communication failures in a low-stakes environment. Full simulations should run annually. The plan should be reviewed and updated after any significant change to systems, staff, or the threat environment.
What is failover and why does BCDR require it?
Failover is the automatic or rapid switching to a secondary system when a primary system fails or is unavailable. It is what allows a business to keep operating while recovery is underway, rather than going dark entirely. Backup alone cannot provide failover — you cannot run your business from a backup file while your systems are offline. BCDR requires failover capability for critical systems so that operations continue even when primary infrastructure is unavailable.
What are the NZ Privacy Act obligations in a BCDR scenario?
If a disruption results in a data breach involving personal information that is likely to cause serious harm, the NZ Privacy Act 2020 requires notification to the Office of the Privacy Commissioner and, in most cases, to affected individuals. A BCDR plan must include pre-drafted notification templates, a designated regulatory contact, clear triggers for when notification obligations apply, and an off-system record of key regulatory contact details accessible when primary systems are unavailable.
How does Exodesk help NZ businesses build BCDR?
Exodesk works with South Island businesses in Christchurch and Dunedin to build BCDR strategies integrated with managed IT services and cyber security. This includes immutable backup architecture design, cloud-based failover capability, tested restore procedures, incident response planning, Privacy Act compliance support, and regular tabletop exercises. Our fixed-price managed IT model means BCDR planning is an embedded, maintained capability rather than a one-off project that goes stale.
