How to write a business continuity plan: a guide for Australian SMEs

A business continuity plan (BCP) is the document an Australian SME refers to when something stops the business operating normally: a cyber attack, a major IT outage, a key supplier failure, a fire in the office, or any other event that disrupts revenue and operations. The plan answers three questions: what do we do in the first hours, what do we do for the days that follow, and how do we eventually return to normal operations.

Most Australian SMEs we work with don't have a BCP. The ones that do often have a 60-page document drafted by a consultant five years ago that nobody has read since. Neither extreme is useful. This guide walks through a practical approach for Sydney SMEs: a BCP that's short enough to actually be used in an incident, focused on the events that genuinely threaten the business, and revisited annually rather than written once and forgotten.

Key facts

• A business continuity plan is the operational playbook for keeping the business running through a disruption. Disaster recovery (DR) is a subset focused specifically on restoring IT systems.
• For Australian SMEs, the most common disruptions that justify a BCP are cyber attacks (especially ransomware), major IT vendor outages, and key staff departures, in roughly that order.
• A useful SME BCP is typically 5 to 15 pages, not 60. It must be readable under pressure.
• The five core sections every BCP needs are: critical business functions, recovery time and recovery point objectives, incident response roles, communication plan, and a tested recovery procedure.
• Cyber insurance underwriters in 2026 commonly ask for a current BCP as part of policy applications. A document that hasn't been tested in 24 months may be treated as not having one at all.
• A BCP that has never been tested is closer to fiction than fact. Annual desktop walkthrough is the minimum, with at least one full restore test per year.

What is a business continuity plan (and how does it differ from disaster recovery)?

A business continuity plan addresses the question "how does the business keep operating when something goes wrong". Disaster recovery is the narrower question "how do we restore our IT systems after they've been damaged or compromised". DR is a component of BCP, not a synonym for it.

The distinction matters because a working DR plan does not, by itself, deliver business continuity. An accounting firm that can restore its servers in six hours still cannot operate during those six hours. Staff are sitting at desks unable to access client files. Phone calls aren't being made. Invoices aren't going out. A BCP addresses what happens during those six hours, not just what happens at the end of them.

For an Australian SME, the practical scope of a BCP usually covers four event types: cyber incidents (ransomware, data breach, account compromise), IT infrastructure failure (server down, internet outage, Microsoft 365 outage), physical events (office inaccessible due to fire, flood, or security incident), and key person events (sudden loss of a critical staff member through illness, accident, or departure). Each event type has its own response patterns, but the underlying framework is the same: identify what's at stake, prepare the response, document the roles, test the plan.

What are the five core sections every BCP needs?

A working SME BCP has five sections. Anything else is useful supporting material; these five are non-negotiable.

1. Critical business functions. The short list of activities the business must be able to perform to remain viable. For a 30-person law firm, this might be "respond to existing client matters, meet court deadlines, produce invoices, accept new client enquiries". For a manufacturing SME, it's "fulfil existing customer orders, accept new orders, pay suppliers". For a recruitment firm, "candidate sourcing, client communication, placement processing". The list should fit on a single page. If it doesn't, the team hasn't really decided what's critical.

2. Recovery time objectives (RTO) and recovery point objectives (RPO). For each critical function, how quickly does it need to be running again (RTO) and how much data loss is acceptable (RPO). RTO answers "after a major disruption, how long can the business survive without this function". RPO answers "if we have to restore from backup, how much recent work can we afford to lose". Both are business decisions, not IT decisions. A 4-hour RTO costs more to deliver than a 24-hour RTO, and that cost should be a conscious choice.

3. Incident response roles. Who decides what during an incident. The temptation is to centralise everything on the business owner, but in practice the owner is often unavailable (in a meeting, on a plane, on holiday) at exactly the wrong moment. A working BCP names three roles: incident commander (decides), communications lead (informs internal and external stakeholders), and IT lead (executes technical response). Each role has a primary and a backup, with contact details that are kept current.

4. Communication plan. Who needs to be told what, in what order. Internal: staff need to know whether to come into the office, whether systems are available, how to contact clients. Clients: existing clients need to know whether their matters are affected and what the response is. Suppliers: critical suppliers may need to be paused or accelerated. Regulators: if customer data is involved, the Notifiable Data Breaches scheme requires notification to OAIC within 30 days of assessment, and an APRA-regulated entity has a 72-hour clock under CPS 234. The communication plan documents the messages, the channels, and the timeframes.

5. Tested recovery procedure. The step-by-step instructions for restoring operations, written specifically for the people who will actually execute them under stress. Not an architectural diagram; a checklist. "Confirm backup integrity. Initiate restore on system X. Verify restore completion. Re-enable user access. Verify business function Y." Tested means actually run, not theoretically possible.

How do you identify your critical business functions?

The exercise is harder than it sounds. The temptation is to call everything critical because every function feels important to the people who run it. The discipline is to ask which functions, if unavailable for a week, would put the business at existential risk.

A useful heuristic: rank every business function on two dimensions, and only the top right quadrant is critical for BCP purposes. The two dimensions are: how quickly does the absence of this function start causing serious problems, and how serious are those problems. Production line stops within hours and seriously damages the business: critical. Marketing campaigns pause for a week and recover with minor impact: not critical for BCP purposes. New product development is on hold for two weeks with no immediate revenue impact: not critical for BCP, though it matters for other planning.

The output is typically a list of 5 to 12 truly critical functions for an Australian SME. More than that and the team hasn't done the discipline. Less than that and the team may have missed something. The functions get the RTO/RPO analysis; the rest get a "best effort recovery" treatment that doesn't drive infrastructure investment.

How do you set RTO and RPO targets?

RTO (recovery time objective) is the maximum time the function can be unavailable before the business takes serious damage. RPO (recovery point objective) is the maximum amount of data loss that's tolerable if restoration requires going back to a backup. Both are business judgments, but they're informed by what's technically and commercially feasible.

For a typical Australian SME, RTO/RPO targets by function might look like:

Function	Indicative RTO	Indicative RPO
Email and calendaring	4 hours	1 hour
Client document access	4 hours	4 hours
Accounting / invoicing system	1 business day	1 business day
Line-of-business application (CRM, practice management)	1 business day	4 hours
Phone system	4 hours	n/a
Internal collaboration (Teams, SharePoint)	1 business day	4 hours
Website and customer-facing services	4 hours	1 hour

These are starting points, not gospel. A medical practice might need a tighter RTO on patient record access because of clinical safety. A law firm with court deadlines might tighten the document access RTO. A retail business might tighten the website RTO during sale periods. The exercise is to make the trade-offs explicit and budgeted.

The RPO target drives backup frequency. A 1-hour RPO means backups must run hourly or use continuous replication. A 4-hour RPO allows for less frequent backups. A 1-business-day RPO is the loosest commonly-used target and is sufficient for many functions. Tightening RPO costs more in infrastructure and licensing. The right number is the loosest target the business can genuinely tolerate, not the tightest target IT can deliver.

How often should a BCP be tested?

The minimum credible cadence is annual desktop testing plus annual full restore testing. Anything less and the plan should be treated as untested.

A desktop test is a 90-minute walkthrough with the incident response team. Someone reads a scenario aloud ("at 9am Tuesday, ransomware encrypts the file server and several workstations"). The team walks through the BCP step by step. Gaps are identified, ownership is assigned, the plan is updated. Desktop tests catch the obvious problems: contact details that are out of date, roles that no longer exist, assumed capabilities that have been removed.

A full restore test actually restores from backup into an isolated environment and verifies that critical functions can operate. This catches the non-obvious problems: backups that have been failing silently for six months, restore procedures that take much longer than the RTO assumes, dependencies between systems that haven't been documented. Most failed restores at the moment of incident trace back to never having attempted a real restore. Quarterly restore testing of specific systems on a rotation is the gold standard. Annual full restore testing is the credible minimum.

A BCP that has been tested becomes meaningfully different from one that has not. Cyber insurance underwriters increasingly ask about testing cadence as part of policy applications. Customer security questionnaires include the same question. The shift from "do you have a BCP" to "when was it last tested" reflects the regulatory recognition that untested plans frequently don't work.

Frequently asked questions

How long should a BCP actually be?

For an Australian SME, 5 to 15 pages is the right range. The constraint is readability under stress. A 60-page BCP that nobody can find the right page in during an incident is worse than a 5-page BCP that fits on a clipboard. Detailed technical recovery procedures can sit in appendices or in IT documentation; the BCP itself should be the operational playbook that an incident commander reads and uses.

Should we hire a consultant to write our BCP?

For Australian SMEs above 50 staff or in regulated industries, a one-off consulting engagement to establish the BCP can deliver real value. For smaller businesses, an internal effort with input from the IT provider is usually sufficient and produces a plan the team will actually own. Consultant-written plans that aren't actively owned by the business often become shelfware.

How does BCP fit with cyber insurance?

Cyber insurance policies in 2026 commonly require evidence of a current BCP as part of policy application or renewal. Some policies provide breach response services that work in conjunction with the insured's BCP. The BCP and the cyber insurance policy should be reviewed together annually to ensure they remain compatible and that the BCP reflects what the insurer expects in an incident.

What about ASD's "Business Continuity in a Box"?

Business Continuity in a Box is a guide published by the ASD (cyber.gov.au) specifically for cyber incident continuity. It focuses on the immediate operational continuity questions during a cyber incident: how to maintain communications, how to operate without IT systems, how to protect remaining infrastructure. It's a useful complement to a full BCP, particularly for the cyber incident response section, and is freely available.

Do small businesses really need a BCP?

For Australian businesses above 10 staff, yes. The question is depth, not whether. A 5-person consultancy with cloud-only systems and one critical application can document its BCP in 3 pages and meet its obligations. A 50-person manufacturer with on-premise systems, line-of-business software, and supply chain dependencies needs a substantially more developed document. The size scales with the complexity, not with headcount alone.

What's the difference between BCP and crisis management?

BCP is about keeping the business operating through disruption. Crisis management is the broader discipline of handling events that threaten the organisation's existence, reputation, or stakeholder relationships, even when business operations themselves continue. A data breach is a crisis (reputational, regulatory) even if operations continue normally. A ransomware event is both a crisis and a continuity event. For SMEs, the two often blur together; for larger organisations they're managed by distinct functions.

If your business doesn't currently have a tested BCP, or the one you have was written by a consultant five years ago, it's worth a 15-minute conversation. We can talk through what a fit-for-purpose plan looks like for your business size and stack, and what testing it actually involves.