| A disaster recovery plan is a documented set of procedures and resources that lets a business restore its IT systems, data and operations after an unplanned event such as a cyber attack, hardware failure, natural disaster or major outage. It names what comes back first, who does it, and how long each step should take. |
What would happen to your business if every server, application and file became unavailable for three days? For most New Zealand businesses the honest answer is uncomfortable, and it gets worse the longer the outage runs.
You will find plenty of articles quoting a cost of downtime per hour. Be careful with those numbers. The two most widely repeated figures both trace back to studies of large United States data centres, one of which has since been deleted by its publisher, and neither measured anything resembling a New Zealand small business. Nobody has credibly costed an hour of downtime for a firm your size.
What has been measured, here, is what recovery actually looks like. Resilient Organisations surveyed 541 Canterbury businesses more than two years after the earthquakes. Almost all of them, 99%, had reopened. But 38% still described themselves as recovering or in survival mode, and the researchers found that organisations without good ICT backups faced a much longer road, because losing the customer and accounting databases became a problem that dragged on for years. Reopening the doors is not the same as recovering.
A disaster recovery plan is what shortens that tail. This guide covers what your plan should contain, how to build one, and how to test it. There is a free template below to start from.
Free disaster recovery plan template
Download a fill-in disaster recovery plan template built for New Zealand small and medium businesses. No email address required, no form, no follow-up call. It is a Word document, six pages, and you can have the first version of a real plan finished this afternoon.
- System inventory with a tier, a recovery time objective and a recovery point objective for each system.
- Named roles with deputies for declaring the incident, leading recovery, authorising spend and handling communications.
- A first-hour checklist written so a non-technical person can follow it before anyone senior arrives.
- Recovery order and dependencies, so you do not restore an application before the database it reads from.
- Backup detail, including the two lines most businesses cannot fill in: the date of the last tested restore, and how long it took.
- Contacts, communications, and test and review logs, including who notifies the Privacy Commissioner and when.
Download the template (Word, free)
Print it once it is filled in. A plan that only exists on the file server is no plan on the day the file server is encrypted.
What is a disaster recovery plan?
A disaster recovery plan is a written document that defines how an organisation will respond to and recover from events that disrupt its IT systems and data. It covers the technology, the people and the processes needed to bring critical operations back online within a defined timeframe.
The plan is not a document for cyber attacks alone. A well-built disaster recovery plan covers any scenario that takes systems offline, including fire, flood, power failure, ransomware, hardware faults, supplier outages and human error.
It sits inside a broader resilience picture. If you are not yet sure which document you need, our backup and recovery plan guide sets out the difference between the four, and a business continuity plan covers keeping the business trading while the technology is still down.
How does a disaster recovery plan differ from business continuity?
A disaster recovery plan focuses on the technology. A business continuity plan focuses on the whole organisation. One asks how we get our systems back, the other asks how we keep operating while those systems are down.
In practice the two work together. Your plan might commit to restoring the customer database within four hours, while the continuity plan defines how the customer service team handles enquiries during that window using printed lists and manual processes.
Is a disaster recovery plan legally required in New Zealand?
No. There is no New Zealand law requiring a business to hold a disaster recovery plan or a continuity plan, and business.govt.nz says so plainly. What does apply is the Privacy Act 2020, which requires reasonable steps to protect personal information, and being unable to recover information you were responsible for is difficult to defend as reasonable.
Insurers ask about it directly. Chubb’s current New Zealand cyber proposal form asks, as a separate yes or no question, whether you hold a formal disaster recovery plan that addresses cyber scenarios and is tested annually, and warns that inaccurate answers can let an insurer reduce a claim, refuse it, or treat the policy as though it never existed. That particular form is written for businesses turning over $50 million to $700 million, so treat it as a signal of what the market now asks rather than proof of what your own insurer requires. Our guide to what insurers look for before they pay covers the evidence side.
What should a disaster recovery plan include?
A disaster recovery plan should include recovery objectives for every system, an inventory of what you are protecting, named roles with deputies, your backup arrangements, communication protocols and tested procedures. The test of a good one is whether somebody reading it for the first time, under pressure, could still follow it.
Recovery objectives are where most plans start. Recovery Time Objective is the longest a system can acceptably be down. Recovery Point Objective is the most data you can afford to lose, measured in time. Every system gets its own pair, and the pair drives what you spend.
| Tier | What sits here | Typical RTO | What that costs you |
|---|---|---|---|
| Tier 1 | Revenue stops without it: ordering, point of sale, production | Under 4 hours | Replication or hot standby. The expensive tier. |
| Tier 2 | Disruptive but survivable for a day: email, accounting, CRM | 8 to 24 hours | Standard backups restored to replacement hardware. |
| Tier 3 | Can wait: archives, historical records, reporting | 2 to 5 days | Little beyond a reliable backup and a restore procedure. |
If everything in your business lands in Tier 1, the tiering has not been done honestly. The point of the exercise is to decide what waits, because trying to recover everything at once stretches the same few people across too many jobs and delays the systems that actually pay the bills.
What roles and responsibilities should be defined?
Name people, not job titles, and give every role a deputy. Someone declares the incident, someone authorises spending, someone communicates with staff and customers, and someone leads the technical recovery.
People take leave, get sick, or are themselves caught up in the event. If only one person knows the recovery procedures, the disaster recovery plan has a single point of failure written into it from day one.
How do you build a disaster recovery plan?
Building a disaster recovery plan starts with an inventory, because you cannot recover what you have never listed and you cannot prioritise without knowing which systems generate revenue, hold sensitive data or sit at the centre of daily work.
The work runs in four stages: assess the risks and the business impact, tier the systems, design the recovery strategy against those tiers, then document it. Skipping to the documentation produces something that looks complete and fails the first real test.
How long a disaster recovery plan takes to build depends entirely on how complicated your systems are and how quickly people can get in a room. A single site business running everything in Microsoft 365 can get a workable first version down in a few sessions. A business with on-premises servers, industry software and several locations will take longer, and the first version will not be the last.
How do you prioritise systems for recovery?
Group systems into the tiers above based on how quickly the business genuinely needs them back, then map the dependencies. Restoring a customer-facing application achieves nothing if the database behind it is still offline or the authentication service has not come back first.
Cost rises sharply as recovery targets tighten, so the strategy has to be honest about trade-offs. Near-zero downtime is achievable and expensive, and very few systems in a small business justify it. The exercise is matching the cost of recovery infrastructure to the cost of the downtime it prevents, one system at a time.
How do backups fit into the plan?
Backups are the foundation, and a backup on its own is not a recovery strategy. The plan needs to define what is backed up, how often, where the copies sit and how long a restore actually takes in practice rather than in theory.
The standard worth holding to is 3-2-1-1: three copies of the data, on two different media types, one kept offsite and one kept offline or air-gapped. The offline copy carries most of the weight, because attackers go for the backups they can reach over the network first. Our data backup strategy guide sets out how to build it.
How do you test a disaster recovery plan?
Test it three ways, at three intervals. A tabletop exercise walks the team through a scenario verbally. A partial test recovers a single system to an isolated environment. A full test brings services back end to end.
The NCSC’s guidance for New Zealand businesses suggests running through a practice scenario every six months, and makes a point most plans miss: keep a hard copy and make sure everyone knows where it is. It also recommends keeping a written record during an incident, because that record is what your insurer and any investigator will ask for afterwards.
Testing finds the things a paper review never does. Expired credentials. Missing dependencies. Backup files that will not restore. Contact lists pointing at people who left two years ago. Procedures that assume access to a system which is itself offline. Each test should produce a short written note of what failed and who is fixing it, tracked to completion.
What common mistakes undermine a disaster recovery plan?
The most common mistake is treating the disaster recovery plan as a compliance document. Written once and filed, it is inaccurate within months as systems, suppliers and staff change. The second is never testing it, which means the first full run-through happens during a real incident.
Two more catch businesses out repeatedly. Storing the plan only on the systems it is meant to recover, so it disappears exactly when it is needed. And setting recovery targets nobody has funded the infrastructure to meet, which commits the business on paper to outcomes it cannot deliver.
There is a wider pattern behind all of this. MBIE research covering 2,278 New Zealand small businesses in late 2023 found that firms rate themselves well on resilience, scoring 71% on a resilience scale, while only 27% had taken out contents or business continuity insurance. Most owners feel prepared. Rather fewer have done the things that make preparation real.
How often should the plan be reviewed?
At least every six months, and after any significant change: new systems, new people in key roles, a change of supplier, upgraded infrastructure. Test outcomes drive updates too. If an exercise shows recovery takes twice as long as the document claims, either fix the procedure or change the target, but do not leave the fiction in place.
Frequently Asked Questions
What is a disaster recovery plan?
A documented set of procedures defining how a business restores its IT systems, data and operations after an unplanned disruption. It covers recovery targets, named responsibilities, communication and the technical steps themselves. Every system in the plan should have a stated recovery time and a stated tolerance for data loss.
Is there a free disaster recovery plan template?
Yes. There is one on this page, free, with no email address required. It is a six page Word document built for New Zealand small and medium businesses, covering the system inventory with recovery objectives, named roles and deputies, a first hour checklist, recovery order, backups, contacts, communications, and test and review logs.
What is the difference between disaster recovery and business continuity?
Disaster recovery restores the IT systems and data. Business continuity keeps the whole organisation operating, including the non-technical parts, while that recovery happens. The two work together: continuity provides the workarounds and the disaster recovery plan brings the technology back.
What are RTO and RPO?
Recovery Time Objective is the maximum time a system can acceptably be offline. Recovery Point Objective is the maximum data loss the business can absorb, measured in time. Together they say how fast you must recover and how recent your last usable copy must be, and they are what decide how much recovery infrastructure is worth buying.
How often should a disaster recovery plan be tested?
A tabletop walkthrough every six months, a partial recovery test at least twice a year, and a full end to end test annually if the business can support one. The NCSC suggests running a practice scenario every six months. Every test should produce a short written note of what failed and who is fixing it.
How long does it take to build a disaster recovery plan?
It depends on how complicated your systems are and how quickly the right people can get in a room. A single site business running everything in Microsoft 365 can produce a workable first version in a few sessions. A business with on-premises servers and several locations will take longer, and the first version will not be the last.
What does an hour of downtime actually cost?
Nobody has credibly measured this for a small business. The two figures quoted everywhere both trace to studies of large United States data centres, one of which has been deleted by its publisher, and the more rigorous of the two says in its own text that confidence intervals cannot be applied to it. Work out your own exposure instead: wages you keep paying while nobody can work, jobs you cannot invoice, and customers who go elsewhere.
Is a disaster recovery plan legally required in New Zealand?
No. There is no New Zealand law requiring one, and business.govt.nz states that continuity planning is not a legal obligation. The Privacy Act 2020 does require reasonable steps to protect personal information, and cyber insurers ask directly on their proposal forms whether you hold a tested plan, so the practical pressure comes from those two directions rather than from a statute.
Who is responsible for the disaster recovery plan?
Overall ownership sits with the business, usually with an owner, general manager or operations lead, with day to day work delegated to the IT team or provider. Each role inside the plan needs a named individual and a named deputy. Without clear ownership the plan drifts out of date, which is the most common way it fails.
Does a small business really need one?
Yes, and often more than a large one, because there are fewer people to absorb the disruption and fewer redundant systems to fall back on. A disaster recovery plan does not need to be long. It needs to cover the critical systems, the recovery order, who does what, and where the hard copy is kept.
Where should the disaster recovery plan be stored?
Somewhere reachable when your systems are not. The NCSC’s guidance is to keep a hard copy and make sure everyone knows where it is. Storing the only version on the file server it is meant to recover is one of the most common and most avoidable mistakes in this whole subject.
How does cloud computing change disaster recovery planning?
Cloud services shift part of the burden to the provider without removing the need for a plan. You still manage data backup, user access, configuration and the joins between cloud and on-premises systems. A current plan covers cloud, hybrid and whatever remains on your own hardware.
NEXT STEP
Would your plan survive contact with a real Monday?
Download the template and fill it in, and you will find the gaps yourself. If you would rather someone pressure-tested it with you, or you want to know whether your backups would actually restore, an IT assessment answers both. Christchurch, Dunedin and across the South Island.
Or read more about our managed IT services.
