Every New Zealand business eventually meets a day when the office is unreachable, the server is dead or the data is encrypted. A business continuity plan decides in advance how you keep trading through that day. This guide explains what a business continuity plan built for NZ conditions should contain, how RTO and RPO work, and how to test the result.
It is written for owners and operations managers of small and medium businesses. OxygenIT has operated from Christchurch since 2005, which means we ran client IT through the Canterbury earthquakes, and we hold ISO 27001 and ISO 42001 certification. What follows is the approach we use with clients.
What is a business continuity plan?
A business continuity plan, or BCP, is a documented set of procedures that keeps your critical business functions running during and after a disruption. It covers people, premises, technology, suppliers and communication. Disaster recovery and incident response are subsets of it: disaster recovery restores IT systems, and incident response handles security events.
The three terms nest inside each other. Business continuity planning is the outer layer: how the organisation keeps serving clients, paying staff and meeting obligations while something is broken. Disaster recovery is the IT restoration subset, covering how servers, data and applications come back. Incident response is the security event subset, covering how a cyber attack is contained and investigated. A ransomware incident activates all three at once, so the documents must reference each other.
A good plan is short, current and specific. Ten tested pages beat a hundred pages nobody has opened since they were written. We cover the fundamentals in our guide to what business continuity means for NZ business owners; this article deals with building and proving the plan itself.
How do you write a business continuity plan?
You write a business continuity plan by working through six steps: run a business impact analysis, assess your risks, set recovery targets for each system, document runbooks with named roles, arrange alternate ways of working, and test the result. Most NZ SMBs can produce a workable first version in a few focused weeks.
- Run a business impact analysis. List the processes the business cannot function without: taking orders, delivering client work, invoicing, payroll. Record what each depends on, then prioritise by how long each could be down before the damage compounds. That tolerable downtime figure drives everything else.
- Assess your risks. Rank the disruptions most likely to hit you: earthquake, flood, ransomware, a cloud outage, a power cut, the loss of a key person. You are choosing which scenarios the plan must handle, not predicting the future. Business.govt.nz publishes free continuity and emergency planning guidance for small businesses.
- Set RTO and RPO for each system. Decide how quickly each system must be restored and how much data you can afford to lose. The next section explains both with worked examples.
- Document runbooks with named roles. Write the step by step recovery procedure for each scenario, name the owner of each step, and include out of band contact details: personal mobiles, a channel independent of your email platform, and a printed copy at home. A contact list stored only in Microsoft 365 is no use during a Microsoft 365 outage.
- Arrange alternate ways of working. Confirm staff can work from home with secure access, agree where the team assembles if the office is inaccessible, and hold backup connectivity such as a 4G or 5G router.
- Test it. A plan that has never been exercised is a draft. Testing is covered later in this guide.
Our business continuity service runs this process with you, from impact analysis through to the first tabletop exercise.
What are RTO and RPO?
RTO, recovery time objective, is how long you can afford to be without a system before the damage becomes serious. RPO, recovery point objective, is how much data you can afford to lose, measured as time since the last usable backup. Every system in your plan needs both numbers agreed in advance.
A worked example makes it concrete. Backups run nightly at 11pm and the server fails at 4pm: you restore last night’s copy and lose a full day of invoicing, a 24 hour RPO in practice. If that is unacceptable, you need hourly snapshots or replication, a one hour RPO. RTO is the other clock: an eight hour RTO on a file server means hardware or a cloud recovery target must be ready inside a working day, not ordered after the failure.
| System | Example RTO | Example RPO | What that requires |
|---|---|---|---|
| Email and Microsoft 365 | 4 hours | 24 hours | Third party Microsoft 365 backup, emergency admin access, an out of band channel for staff |
| Line of business application | 8 hours | 4 hours | Replicated or cloud hosted instance, vendor support details in the runbook, a tested restore procedure |
| File server | 8 hours | 4 hours | Image based backup with intraday snapshots, an offsite copy, and spare hardware or a cloud recovery target |
| Payroll | 24 hours | 24 hours | Cloud payroll or an offsite backup of pay data, plus a documented manual pay run |
| Phones | 2 hours | Near zero | Cloud hosted phone system with failover to mobiles and a documented carrier divert process |
The pattern to notice is cost. Driving RTO and RPO towards zero is possible for almost any system, but every step down adds real engineering and licensing cost, so set targets per system rather than buying premium recovery for everything. Our data backup and disaster recovery service matches those targets to the right platform at a defensible cost.
For a shorter, provider-comparison view of disaster recovery, covering DRaaS versus self-managed versus fully managed models, SLA red flags, and pricing, see our disaster recovery services guide.
What NZ-specific risks should a BCP cover?
A New Zealand business continuity plan should cover earthquakes, flooding and severe weather, cyber attack including ransomware, cloud and SaaS outages, and power or telecommunications failures. The mix matters because each risk breaks a different assumption: access to premises, the integrity of your data, or the connectivity everything else depends on.
Earthquakes sit at the top of the list for good reason. The February 2011 Christchurch earthquake killed 185 people and closed the central city, with parts of the cordon staying up for years. Businesses lost access to premises, servers and paper records overnight, and some never re-entered their buildings. We were operating in Christchurch then, and the firms that kept trading were the ones whose data and phone systems did not live solely inside the cordon. NEMA, the National Emergency Management Agency, publishes readiness guidance through civildefence.govt.nz, and it is worth reading with commercial eyes as well as household ones.
Flooding earned its place more recently. The Auckland Anniversary weekend floods in late January 2023 put workplaces, stock and ground floor server rooms under water, and Cyclone Gabrielle followed within weeks, bringing widespread power and connectivity outages across the upper North Island. The lesson was about dependencies rather than water: businesses on cloud systems and laptop fleets resumed quickly, while those tied to hardware in a flooded building did not.
Cyber attack is the risk most likely to trigger your plan. Ransomware encrypts production systems and any backups reachable from the same network, which is why an offline or immutable backup copy is non negotiable. CERT NZ, now part of the National Cyber Security Centre, publishes plain language ransomware guidance and reports on incidents affecting New Zealand organisations. Treat ransomware as a full continuity event with the RTO clock running, not a quiet IT problem.
Finally, plan for the mundane outages: a Microsoft 365 or Xero service incident, a cut fibre line, a regional power cut. These happen far more often than disasters and are the cheapest to rehearse. The plan needs a simple answer for what each team does during a two hour outage and a two day one, because the responses differ.
What does business continuity look like for law and accounting firms?
For law and accounting firms, business continuity is a professional obligation as much as an operational one. Trust accounting must stay accurate and auditable through any outage, payroll and filing deadlines do not move, and client files carry confidentiality duties that survive floods, quakes and ransomware alike.
Trust accounting is the sharpest edge. A firm holding client money must be able to receipt, disburse and reconcile accurately while systems are down, and trust account record keeping obligations do not pause because a server failed. Continuity planning here means knowing how you would operate and evidence the trust account if the practice management system were down for several days, and confirming what recovery commitments your software provider makes.
Payroll and statutory deadlines are the second pressure point. Staff must be paid on the usual day and PAYE and GST filings still fall due, so the plan needs a documented and tested manual pay run rather than an assumed one. Client files are the third. Privilege and confidentiality follow the data wherever recovery takes it, so restoring client records onto an unmanaged temporary laptop is a breach waiting to happen. Recovery needs the same access controls as production, and the Privacy Act 2020 makes serious privacy breaches notifiable, which puts sloppy recovery on the compliance register.
The final element is communication. Clients and regulators judge a firm on how it behaves during a disruption, not after it. The plan should name who contacts the professional body, who fronts to clients and what gets said within the first day, because silence reads as disarray even when the recovery is going well.
How do you test and maintain the plan?
You test a business continuity plan with an annual tabletop exercise at minimum, plus scheduled restore tests that produce logged evidence. You maintain it by updating the document after every staff or system change and by assigning a named owner. An untested plan is a guess, and most guesses fail under pressure.
The annual tabletop exercise is the minimum standard. Pick one scenario, put the people named in the plan around a table for two hours, and walk through it step by step using only what the plan says. The exercise finds the same gaps every time: a named person who has left, a phone number that has changed, a recovery step that assumes a system which is itself down.
Restore tests are the technical half of the programme. Backup jobs that report success are not proof you can recover; only a completed restore is. Schedule restores of real data to a real target, record who ran the test, what was recovered, how long it took and whether the RTO and RPO targets were met, then file that evidence where an insurer, auditor or prospective buyer can see it.
Maintenance is triggered, not scheduled. Update the plan whenever a person named in it leaves, a system is replaced or a key supplier changes, and give one senior person ownership of keeping it current. Review the document annually alongside the tabletop exercise, and version it so everyone can recognise the current copy.
Business continuity plan NZ: frequently asked questions
Is insurance a substitute for a business continuity plan?
No. Insurance can reimburse some financial losses after an event, but it does not answer phones, restore data or pay staff on Friday. A business continuity plan keeps the organisation trading while any claim is assessed, which can take months. Insurers also increasingly expect documented continuity and backup arrangements before offering cover at a sensible premium.
How long does it take to write a business continuity plan?
Most small and medium NZ businesses can produce a workable first plan in two to four weeks of part time effort. The business impact analysis and the runbooks take the most time. Working with an experienced IT partner moves things faster because recovery targets can be matched to what the backup platform can actually deliver.
Is a BCP template enough on its own?
A template is a useful starting point and a poor finishing point. Generic documents skip the two things that make a plan work: recovery targets agreed for your specific systems and named people who know their roles. Use a template for structure, then complete a business impact analysis and test the result against a realistic scenario.
How often should we test backup restores?
Test restores at least quarterly for critical systems and after any major change to the backup platform. A restore test should recover real data to a real target and produce logged evidence: who ran it, what was recovered and how long it took. Our data backup and disaster recovery service builds these tests into the schedule.
Who should own the business continuity plan?
One named senior person should own the plan, typically the owner, general manager or operations manager. The owner keeps it current, schedules the tests and holds the out of band contact list. IT providers own the technical recovery steps, but accountability for the whole plan has to sit inside the business, not with a supplier.
What does a tabletop exercise involve?
A tabletop exercise is a structured walkthrough of one scenario, such as ransomware on a Monday morning, run around a table in about two hours. Each person states what they would do next, using only the plan. Gaps get logged and fixed. Contact us if you want an independent facilitator for your first one.
How often should a New Zealand business test its disaster recovery plan?
Run a tabletop exercise at least annually and test backup restores at least quarterly for critical systems, plus after any major change to the backup platform. That is the minimum. A restore test should recover real data to a real target and produce logged evidence: who ran it, what was recovered and how long it took. Update the plan whenever a person named in it leaves, a system is replaced or a key supplier changes, and review the document annually alongside the tabletop exercise. An untested plan is a guess.
Build a tested continuity plan with OxygenIT
OxygenIT is Christchurch based and has operated here since 2005, which includes running client IT through the Canterbury earthquakes, so continuity planning in this part of the country is lived experience rather than theory. We are ISO 27001 and ISO 42001 certified, and we support businesses in Christchurch, Wellington and across New Zealand.
Book a discovery call and we will map your critical systems, agree RTO and RPO targets for each, and leave you with a continuity plan you can test. Or call us on 0800 101 095.
What are RTO and RPO, and what should a New Zealand small business set them to?
Recovery time objective is how long a system may be down. Recovery point objective is how much data you can afford to lose, measured in time. Set them per system rather than for the business as a whole, because the tolerance for the accounting system and for the file share are rarely the same. Agree them in writing with whoever is responsible for the restore.
