What a small business disaster recovery plan should contain

Keep it short and usable

A disaster recovery plan is not a policy document for a shelf. It is the set of instructions someone will open on their phone in a stressful moment, perhaps standing outside a building with smoke damage or on a call at 6am after discovering every file is encrypted. Long paragraphs of theory will not be read. Short sections, checklists and named people will.

For a business of five to fifty staff, aim for a document of a few pages plus appendices for technical details. If it takes longer than ten minutes to read through, it is probably trying to do too much. Anything that does not help someone act in the first few days can move to an appendix or a separate document, such as long-term premises planning or detailed network diagrams.

People, roles and contacts

Start with who decides. Name the person who declares a disaster and leads the response, and a deputy if they are unavailable. Name who contacts staff, who talks to clients and suppliers, who deals with the insurer, and who works with IT on the technical recovery. In a small business one person may have several roles, which is fine as long as it is written down.

List contact details for staff, your IT provider, internet and phone providers, key software vendors, the insurer and broker, the landlord or building manager, and your bank. Include account numbers or customer references where you will need them. Personal mobile numbers matter here, because work phones may be among the things that are lost.

Systems and priorities

List each important system: email, phones, file storage, accounting, practice or job management, line-of-business apps, website, and anything else the business relies on. For each, record where it runs, where it is backed up, who supports it, and the agreed recovery targets: how much data you can lose and how long you can be without it.

Then set a restore order. A common pattern is communication first, then the system that generates revenue, then everything else. Decide this calmly in advance. In the middle of a crisis everyone will believe their own system is the most urgent, and an agreed order avoids that argument. Note any dependencies too, such as a job management app that cannot run until the database server is restored.

Recovery steps and where things are

For each critical system, write the high-level recovery steps: where the backup is, how to log in to the backup service, what hardware or cloud resources are needed, and roughly how long it takes. Detailed technical runbooks can live in an appendix or with your IT provider, but the main plan should show the shape of the recovery so a business owner can follow progress.

Include where licence keys, installation files, network diagrams, router and firewall settings, and admin credentials are kept. Credentials themselves should be in a secure password manager or sealed offline record, not pasted into the plan, but the plan should say exactly where to find them and who has access. Check that at least two people can reach every critical credential, because a plan that depends on one person being available will fail on the day they are overseas.

Specific scenarios

Add short notes for the scenarios you are most likely to face. Ransomware needs isolation of affected machines, early contact with your insurer and possibly CERT NZ (now part of the NCSC), and a check that backups are clean before restoring. Fire or flood needs a temporary workspace, replacement devices and access to cloud services from elsewhere. Theft needs remote wiping of devices, a police report and password changes. A long internet outage needs a mobile or satellite fallback.

These notes do not need to be long. A handful of bullet-style sentences for each scenario is enough to point people in the right direction while the detailed work happens. Over time, add notes from any real incidents and rehearsals, because they show what actually caused delays. Lessons written down are lessons the next person does not have to learn the hard way.

Storing, testing and updating the plan

Store copies where you can reach them without the office network: a printed copy at the owner's home, a copy in a personal cloud account with multi-factor sign-in, and a copy with your IT provider. If the only copy sits on the server that has just been encrypted, the plan has failed before it starts.

Test the plan at least once a year with a tabletop exercise: sit down for an hour, pick a scenario and walk through what each person would do. Update contacts, systems and steps whenever something changes, such as a new provider, a new key system or a staff member leaving. Date every version so you know it is current.