In New Relic research cited by Secureframe, high-impact outages carry a median cost of about US$2 million an hour — roughly $33,000 for every minute systems stay down. Numbers like that are vendor research, not law, but they explain why incident response and business resilience can no longer sit in the “we’ll deal with it if it happens” pile. This guide sets out what a working incident response plan actually needs, how it links to your legal notification duties, and where you can start without buying a bank-sized security program.

Key takeaways
- Do small businesses need an incident response plan? Yes. Government guidance and most contracts now expect one, even without a specific statute naming it.
- Incident response vs business resilience? Incident response stops the bleeding. Business resilience is your ability to keep trading, or recover quickly, while that happens.
- How fast must Australian businesses act on a breach? Assessment within 30 days of becoming aware; notification to the OAIC and affected people “as soon as practicable” after that.
- What must an incident response policy contain? Scope, incident categories, reporting channels, activation authority, roles, severity levels and decision rights.
- Does New Zealand have different rules? Yes. NZ businesses work from the Privacy Act 2020, NotifyUs, and a separate incident response policy framework.
- Fastest low-cost step? Adapt a free data breach response plan template rather than starting from a blank page.
- Is one document enough? No. You need an incident response policy, a data breach response plan and incident management procedures that connect the two.
What is incident response and business resilience — and do you actually need a plan?
Incident response is what you do in the hours after something goes wrong: an intrusion, ransomware, a lost laptop, a supplier compromise. Business resilience is the broader capacity to keep operating, or get back to operating, while that response happens.
No universal Australian law requires every private business to hold a document with this exact title. But government guidance, insurer questionnaires and an increasing number of client contracts now expect a written incident response plan as a baseline, not an extra.
Proportionate security means matching effort to what could genuinely hurt the business: payment fraud, loss of email, exposure of sensitive records, inability to trade, or a critical supplier failure. An incident response and business resilience plan is how you turn that risk list into something your staff can actually follow at 2am on a Saturday.
How this differs by situation
- Sole trader or microbusiness: a one-page plan naming who to call, what to shut down, and how to notify customers is enough to start.
- A$3m or less turnover: add defined severity levels and a basic contain–assess–notify sequence, because you’re still likely to hold personal information covered by notification duties.
- Mid-market with staff and multiple systems: you need named roles, an activation authority, and a tested communications plan — not a document that lives in a drawer.
- Regulated or critical infrastructure entities: obligations under frameworks like the Security of Critical Infrastructure Act add reporting timeframes on top of the general scheme.
The non-negotiable sections of an incident response plan
A usable incident response plan is not a philosophy document. It is an operational script.
At minimum it must define scope, incident categories, reporting channels, activation authority, roles, severity levels, decision rights, and links to the detailed response steps. Leave any of these out and the plan becomes something people admire rather than use.
Put this in your policy (adapt before use): “On detection of a suspected incident, the person who identifies it must notify [role/contact] within [timeframe]. No system, account or evidence may be altered, wiped or reimaged until the incident lead confirms containment steps.”
That single clause stops the most common mistake: well-meaning staff “fixing” the problem before anyone captures the evidence needed for insurance, notification or law enforcement.

The stakes are speed-based — in CrowdStrike research cited in Kroll’s 2026 resilience report, attackers establish a foothold in as little as 29 minutes; Kroll puts the yearly average cost of recovery and downtime from cyber incidents at US$2.2 million.
Security incident plan vs data breach response plan
A security incident plan covers any event that threatens confidentiality, integrity or availability, from a phishing click to a server outage. A data breach response plan is narrower: it activates specifically when personal information may have been accessed, disclosed or lost without authorisation.
Most businesses need both — connected, not separate. The four steps that matter in a data breach response plan are consistent across guidance: contain, assess, notify, review.
- Contain: stop further access or loss without destroying evidence.
- Assess: determine whether the breach is “eligible” under the Notifiable Data Breaches scheme — likely to result in serious harm.
- Notify: tell the OAIC and affected individuals, on the required timeframe, in the required format.
- Review: fix the control gap that allowed it, and update the plan with what you learned.
You can start with the free data breach response template and adapt it to your systems rather than drafting from scratch.
When your incident becomes a legal obligation
An incident stops being purely an operational problem the moment it becomes an eligible data breach under the Notifiable Data Breaches scheme: personal information is accessed, disclosed or lost, and a reasonable person would conclude this is likely to result in serious harm.
You have 30 days from becoming aware of a suspected breach to complete your assessment. Ransomware incidents in particular tend to trigger this clock the moment you discover the intrusion — not once you’ve confirmed exactly what was taken.
Once assessed as eligible, you must notify the OAIC and affected individuals as soon as practicable, using the required statement content. Penalties for serious or repeated interference with privacy have grown sharply since the December 2024 Privacy Act amendments.
Read the full breakdown in our Notifiable Data Breaches scheme guide before you assume “we’re too small to matter.”
Incident management procedures: the first hour, days and weeks
Good incident management procedures break the response into time-bound stages, because different decisions are needed at different points.

The first hour
- Confirm the report and assign an incident lead.
- Isolate affected systems without destroying logs or evidence.
- Activate the communications plan internally — before anything goes to customers or media.
The first days
- Assess scope: what data, which systems, how many people affected.
- Decide whether the Notifiable Data Breaches scheme is triggered.
- Engage external specialists (forensic, legal, insurer) if the severity level requires it.
The following weeks
- Complete notifications where required.
- Run the post-incident review.
- Put owners and dates beside unfinished actions from that review, and check them off before you file the plan away.
Incident management policy vs incident response policy
People use these terms almost interchangeably, but there’s a useful distinction. An incident management policy sets the governance: who has authority, what counts as an incident, how severity is classified, and how decisions escalate.
An incident response policy is the operational layer underneath: the specific reporting channels, activation triggers and role assignments that make the governance real. You need both, and they need to reference each other — or staff will find gaps and either freeze or improvise.
Our incident response policy guide sets out the non-negotiable sections in detail, including why activation authority should be assigned by role rather than by name, so the plan doesn’t break the moment someone changes jobs.
New Zealand businesses: the Privacy Act 2020 path
New Zealand runs a parallel but distinct system. Businesses need a documented process covering detection, immediate escalation, containment, evidence preservation and a serious-harm assessment — aligned to the Privacy Act 2020, not the Australian NDB scheme.
NZ organisations report notifiable privacy breaches through NotifyUs, and the serious-harm assessment uses the Privacy Act 2020’s own factors rather than Australia’s test. Copying an Australian template without adjusting it is one of the most common trans-Tasman mistakes.
Start with the NZ incident response policy template and the related NZ data breach response policy, then check your obligations against the Privacy Act 2020 guide and the notifiable privacy breach guide before you finalise wording.
The human side: why most plans fail before they’re used
A plan is only as good as the people who are supposed to follow it under pressure. Staff must be able to report contradictory, obsolete or impractical requirements without fear — because a policy nobody trusts gets quietly bypassed exactly when you need it most.
The most common failure isn’t a missing document. It’s a plan nobody has read, tested, or been trained against, sitting on a shared drive nobody can find during the actual event.
We cover this in the human side of security policy and its NZ equivalent. Run a tabletop exercise twice a year — it costs an afternoon and it’s the cheapest resilience investment available to you.
Beyond the incident: frameworks and governance
Incident response is one control among many. Business resilience also depends on access control, backup discipline, and governance attention at the leadership level.
If you’re assessing your broader maturity, our Essential Eight guide and ISO 27001 guide explain how the formal frameworks connect back to incident response — both expect a documented, tested response capability as a baseline control, not an optional extra.
New Zealand businesses working through certification options should check the NZ cyber frameworks guide and the NZ management and governance attention guide, which set out what boards and leadership teams are now expected to sign off on.
Start with low-cost controls that reduce common risk, document any gaps you consciously accept, and use staged frameworks rather than attempting everything at once.
Ask your provider this, exactly
If you outsource IT or security to a managed provider, don’t accept “we’ve got it covered.” Ask:

- “What is our documented incident response plan, and when was it last tested?”
- “Who has authority to isolate systems during an incident, and how fast can that happen?”
- “How do you preserve evidence during containment, and who owns that evidence afterward?”
- “What is our current mean time to detect and mean time to contain, based on our last test or real event?”
- “If we had a notifiable data breach tomorrow, what would you send us within the first hour?”
If the answers are vague, treat that as a gap to close — not a detail to revisit “next quarter.”
The bottom line
You do not need a bank-sized manual. You need an incident response plan with clear roles, a data breach response plan aligned to your notification obligations, and incident management procedures your staff have actually practised.
Start with the free templates, adapt them to your business, test them twice a year, and put owners and dates beside anything still unfinished. That’s proportionate incident response and business resilience, built one working document at a time.
Frequently asked questions
Is an incident response plan legally required for small businesses in Australia?
No single law requires the exact document title, but government guidance and most cyber insurance policies now expect a written incident response plan. If you hold personal information, the Notifiable Data Breaches scheme effectively makes a response process mandatory in practice.
What is the difference between a data breach response plan and an incident response plan?
An incident response plan covers any security event that threatens systems or data. A data breach response plan is the narrower process that activates specifically when personal information may have been compromised, following contain, assess, notify and review steps.
How quickly must a business report a data breach in Australia?
You must complete an assessment within 30 days of becoming aware of a suspected eligible data breach. Once confirmed, you must notify the OAIC and affected individuals as soon as practicable.
Do New Zealand businesses follow the same rules as Australia?
No. New Zealand businesses work under the Privacy Act 2020 and report notifiable privacy breaches through NotifyUs, using the Act’s own serious-harm assessment rather than Australia’s NDB test. A separate NZ incident response policy and data breach response policy are needed.
What should be in an incident response policy at minimum?
Scope, incident categories, reporting channels, activation authority, roles, severity levels, decision rights, and links to the detailed response plan. Without these, staff won’t know who is authorised to act during a real event.
Is incident response automation worth it for a smaller business?
In New Relic and PagerDuty research cited by Secureframe, organisations running five or more fully automated response processes resolved customer-impacting incidents about 78 minutes faster than those relying on manual processes. For smaller businesses: get a documented, tested manual process first, and consider automation once volume or complexity justifies the cost.
How often should we test our incident response plan?
Twice a year is a reasonable minimum for most small and mid-sized businesses. A short tabletop exercise — walking through a realistic scenario with your actual team — reveals gaps a written plan alone never will.
Sources
- OAIC — about the Notifiable Data Breaches scheme
- OAIC — when to report a data breach
- OPC — privacy breaches and NotifyUs
- Kroll — cyber resilience report press release (March 2026)
- Secureframe — disaster recovery statistics (citing New Relic and PagerDuty research)
This article is education, not legal advice. Dates and obligations are cited to the official sources above — the linked source is the authoritative wording. See how we verify.