A cyber incident response plan for Australian businesses needs to cover six phases: Detect, Contain, Assess, Notify, Recover, and Review. It should name specific roles, define Australian notification obligations including ACSC and OAIC reporting, and be tested at least annually. Most Australian businesses discover they do not have a workable plan at the worst possible moment, when they are already under attack and making decisions under pressure with no documented process to follow.

This guide reflects how we build and deliver incident response plans for clients across Melbourne. It includes the actual template structure we use, the Australian legal obligations that most guides understate, and the common mistakes we see businesses make when an incident occurs. If you already have a plan, use this as a benchmark. If you do not, use it as a starting point.

Why Most Businesses Discover the Gap Too Late

Ransomware encrypts the file server at 11pm on a Wednesday. The MD calls the IT manager. The IT manager calls the MSP. Three different people spend 40 minutes debating whether to pay the ransom before anyone checks whether there is a usable offline backup. The cyber insurer, who should have been notified within the first hour, is called six hours later. The OAIC notification window is already running.

That is not a fictional scenario. It is a close composite of situations we have been brought into as the response team. In every one of them, the absence of a documented, tested incident response plan made a bad situation significantly worse. The decisions that needed to be made in the first 60 minutes were being made for the first time, under pressure, by people who were stressed and without the information they needed.

A cyber incident response plan does not prevent an attack. It ensures that when an attack occurs, your business responds competently rather than chaotically. That difference determines whether an incident becomes a recoverable business disruption or a catastrophic event.

The Six Phases of a Cyber Incident Response Plan Australia

This is the phase structure we use at Otto IT when managing incident response for clients. Each phase has specific activities, owners, and outputs. The phases are sequential but in practice there is overlap, particularly between Detect and Contain.

Phase 1: Detect

Detection is the moment your organisation becomes aware that something is wrong. It might be an alert from your security monitoring tool, a staff member reporting something unusual, an external notification from a third party, or, in the worst case, an attacker making contact directly with a ransom demand. The goal of the Detect phase is to confirm that an incident is occurring and initiate the response process.

Key activities in this phase include confirming the alert is a real incident rather than a false positive, activating the incident response team, assigning an incident commander who owns the response from this point, and opening the incident log. Every action from this point forward should be timestamped and recorded.

Phase 2: Contain

Containment is about stopping the spread. The goal is not to fully understand what happened yet. The goal is to prevent the situation from getting worse while investigation begins. Containment actions may include isolating affected systems from the network, disabling compromised user accounts, blocking malicious IP addresses or domains at the firewall, and suspending automated processes that may be feeding the attacker’s activity.

Critically, containment should preserve forensic evidence wherever possible. This means isolating systems without wiping them, capturing memory dumps before powering down anything, and ensuring that log data is exported and secured before it rolls over or is deleted. Your managed security provider should lead containment. If you are managing this internally, document every action you take.

Phase 3: Assess

Assessment determines the scope and severity of the incident. What systems were affected? What data was potentially accessed or exfiltrated? How did the attacker get in? How long have they had access? The answers to these questions drive every subsequent decision, including what to notify, who to notify, and what recovery looks like.

This phase typically involves forensic analysis of affected systems and logs, review of access logs across email, cloud services, and internal systems, and a clear-eyed assessment of what the attacker could have accessed even if there is no direct evidence they did. The last point matters for notification obligations, as you may be required to notify based on potential access rather than confirmed access.

Phase 4: Notify

Notification is where Australian obligations become specific and time-sensitive. This phase is covered in detail in the Australian legal obligations section below. The key point is that notification decisions should be documented as part of your plan before an incident occurs, not figured out for the first time during one.

Phase 5: Recover

Recovery is the process of restoring systems and operations to normal. This phase begins once containment is confirmed and the scope of the incident is understood. Recovery activities include restoring from clean backups, rebuilding affected systems, re-enabling accounts with new credentials and MFA enforced, and validating that systems are clean before bringing them back online.

Recovery should be sequenced by business priority. The systems that are most critical to operations come back first, but only after they have been verified clean. Rushing to restore without proper validation is one of the most common ways businesses experience a second incident shortly after the first.

Phase 6: Review

The post-incident review is the phase that most businesses skip because they are exhausted and just want to move on. This is a significant mistake. The review should happen within two weeks of the incident closing and should document the root cause, the timeline of events, what worked in the response and what did not, and the specific changes that will be made to reduce the likelihood or impact of a similar incident. This document becomes your most valuable input for improving the plan and your security posture.

Australian Notification Obligations You Cannot Afford to Miss

Australian businesses face specific notification obligations that are time-sensitive and carry meaningful consequences for non-compliance. These obligations should be mapped out in your plan before an incident, not researched during one.

ACSC: Report the Incident

The Australian Cyber Security Centre (ACSC) accepts incident reports via ReportCyber at cyber.gov.au. Reporting to the ACSC is not always legally mandatory but it is strongly encouraged and provides your business with access to government resources and intelligence. For businesses in critical infrastructure sectors, mandatory reporting obligations may apply. Report early and update your report as more information becomes available.

OAIC: Notifiable Data Breaches

If your business is covered by the Privacy Act 1988 and the incident involved unauthorised access to or disclosure of personal information, you must assess whether the breach is an eligible data breach under the Notifiable Data Breaches (NDB) scheme. An eligible data breach is one where a reasonable person would conclude that the individuals whose information was involved are likely to experience serious harm. If it meets this threshold, you must notify the OAIC and affected individuals as soon as practicable. There is no defined time limit in the legislation but “as soon as practicable” is interpreted strictly and delays require justification.

Ransomware Payment Reporting: $3M+ Businesses Have 72 Hours

If your business has an annual turnover of $3 million or more and you make a ransomware payment, you are required to report that payment to the Australian Signals Directorate within 72 hours. This obligation exists under the Security Legislation Amendment (Critical Infrastructure Protection) Act and related amendments. It is not optional and it applies regardless of whether you ultimately recover your data or not. Your incident response plan should include a clear decision tree for ransomware payment scenarios and a pre-assigned person responsible for making this report.

Cyber Insurer: Notify Within Policy Window

Your cyber insurance policy almost certainly contains a notification window, typically 24 to 72 hours from when you became aware of the incident. Notifying late or failing to notify can result in a claim being reduced or denied. Include your insurer’s emergency contact number and the policy reference in your incident response plan, and assign someone to make that call as one of the first actions in the Notify phase.

Affected Individuals and Third Parties

If client data was exposed, your obligations may extend to direct notification of affected individuals, particularly if the data is sensitive. You may also have contractual notification obligations to partners, suppliers, or clients that are separate from your regulatory obligations. Review your contracts as part of the Assess phase to understand what third-party notification may be required.

Otto IT’s managed cyber security services include support for navigating these notification obligations as part of an active incident response engagement.

Common Mistakes Otto IT Sees During Incidents

These are the patterns we see repeatedly when we are brought in to manage or assist with an active incident. Knowing them in advance is the most direct way to avoid them.

Calling IT Before Calling Management

The first call after a serious incident is usually to IT or the MSP. The next call should be to leadership, not one hour later. Management needs to be informed early because they will need to make decisions about client communication, regulatory notification, media management, and business continuity that IT does not have the authority to make. When IT manages the first hour alone and then escalates, critical decision time has been lost.

Paying Ransom Without Telling the Insurer

This happens more frequently than insurers would like businesses to know. A decision is made to pay the ransom, it is paid, and the insurer is informed afterward. Most cyber insurance policies require the insurer’s involvement in or at least advance notification of any ransom payment decision. Paying without notification can void coverage for that payment and potentially for related costs. The insurer may also have access to negotiation resources or intelligence that could reduce the payment or identify a decryption key without payment.

Not Preserving Evidence

Wiping and rebuilding systems is the fastest path back to operation. It is also the action that destroys the forensic evidence you need to understand how the attacker got in, what they did, and what data they accessed. Preserve affected systems before rebuilding them. Take forensic images. Export logs. This evidence is essential for the post-incident review, for any insurance claim, and potentially for any regulatory or legal process that follows.

Not Having Offline Backups

Ransomware targeting Australian businesses frequently includes a stage where cloud-connected backups are encrypted or deleted before the main payload is deployed. We have seen businesses restore their “backup” only to find it was also encrypted. Offline backups, copies that are not accessible from the network at the time of the incident, are the only reliable last line of defence. If your backup is always connected to your network or your cloud environment, it is not truly offline and a sophisticated attacker can reach it.

Cyber Incident Response Plan Template for Australian Businesses

The following template is designed to be adapted to your specific business. It covers the core elements a plan must include. Fill in the bracketed sections with your actual information before an incident occurs.

Section 1: Plan Overview and Scope

Business name: [Your business name]
Plan owner: [Name and role of the person responsible for maintaining this plan]
Last reviewed: [Date]
Next review due: [Date, maximum 12 months from last review]
Scope: This plan applies to all information systems, data, and third-party services used by [business name], including cloud services, on-premise infrastructure, and remote work environments.

Section 2: Incident Response Team

Incident Commander: [Name, direct phone, email] – Owns the response, makes final decisions, communicates with leadership
Technical Lead: [Name or MSP contact, emergency line] – Leads containment and investigation
Communications Lead: [Name, direct phone] – Manages internal and external communication
Legal/Compliance Contact: [Name or firm, emergency number] – Advises on notification obligations
Cyber Insurer Contact: [Insurer name, policy number, emergency claims line]

Section 3: Incident Classification

Priority 1 (Critical): Ransomware, active data exfiltration, complete system outage, confirmed breach of personal data. Response: immediate activation of full team, notify leadership within 30 minutes.
Priority 2 (High): Malware infection without confirmed spread, suspected credential compromise, phishing click with potential access. Response: activate Technical Lead and Incident Commander, assess within two hours.
Priority 3 (Medium): Suspicious activity requiring investigation, failed login attempts at unusual volume, potentially malicious email clicked with no confirmed access. Response: Technical Lead assesses, escalates if scope increases.

Section 4: Notification Checklist

Cyber insurer: [Insurer name] – Notify within [X hours per policy] of becoming aware. Emergency number: [number].
ACSC ReportCyber: cyber.gov.au/report – Report as soon as practicable.
OAIC (if personal data involved): oaic.gov.au – Assess NDB eligibility and notify if threshold met.
ASD ransomware payment reporting (if applicable): Report within 72 hours of payment for businesses with $3M+ turnover.
Affected individuals: Notify as soon as practicable after confirming eligible data breach.
Key clients or partners: [List any contractual notification obligations here].

Section 5: Evidence Preservation Checklist

Before rebuilding or wiping any affected system: take a forensic image of the disk, export available log files including Windows Event Logs, firewall logs, email server logs, and cloud audit logs, capture a memory dump if the system is still running, photograph or screenshot any visible indicators on screen, and record all actions taken with timestamps. Store preserved evidence in a location that is isolated from the affected environment.

Section 6: Recovery Priority List

List your business-critical systems in order of recovery priority:
Tier 1 (restore within 4 hours): [e.g., email, core business application, financial system]
Tier 2 (restore within 24 hours): [e.g., file server, secondary applications]
Tier 3 (restore within 72 hours): [e.g., development environments, archive systems]
Backup location and access: [Where backups are stored, who has access, how to initiate restoration]
Offline backup verification: [Date of last offline backup test, location of offline copies]

Section 7: Post-Incident Review Template

Complete within two weeks of incident close: incident summary and timeline, root cause identified, systems and data affected, notification actions taken and dates, what worked well in the response, what gaps were identified, specific changes to be implemented with owners and deadlines, and updated threat assessment based on the incident.

How to Test Your Cyber Incident Response Plan

A plan that has never been tested is a document that gives you false confidence. Testing reveals gaps that are far cheaper to discover in a controlled exercise than during a real incident.

Tabletop Exercises: What They Are and How to Run One

A tabletop exercise brings the incident response team together to walk through a simulated incident scenario. There is no live system activity. Everyone sits around a table (or a video call) and the facilitator presents the scenario in stages: “It is 9pm on a Monday. Your monitoring tool alerts on unusual outbound data transfer from your file server. What do you do?” Each team member describes their actions. The facilitator probes with follow-up: “Who do you call first? What number do you use? What do you expect the MSP to do in the next 30 minutes?”

A good tabletop takes 90 minutes to two hours and will surface practical gaps including missing contact details, unclear ownership of decisions, and notification obligations no one had actually read. Run at least one tabletop annually. For businesses in regulated industries or those that have experienced an incident, run one quarterly.

What to Test For

Test whether everyone knows their role and can describe their first three actions under the scenario. Test whether the contact information in the plan is current and reachable. Test whether the notification decision tree produces a clear answer for the scenario presented. Test whether the evidence preservation checklist is understood and could be executed by someone who is stressed and under time pressure. Test whether your backup restoration process has been verified and how long it actually takes.

Technical Testing: Verify the Backups Actually Work

Beyond tabletop scenarios, test your backups by actually restoring from them in a test environment, not just confirming the backup job completed successfully. Backup jobs can report success while producing files that do not actually restore correctly. Annual restoration testing is a minimum. If your business has critical data with tight recovery time objectives, test more frequently. The restoration test should confirm that your systems can actually be recovered to a functional state within your documented recovery time objective.

Getting Help Building or Reviewing Your Plan

Building a genuinely useful cyber incident response plan takes time and requires knowledge of your specific environment, your Australian legal obligations, and the realistic threat landscape for your industry. The template above provides a structure, but the value comes from completing it with real names, real contact numbers, real system lists, and real recovery priorities before you need it.

We work with Melbourne professional services firms to build, review, and test incident response plans as part of our managed cyber security services. If your current plan has not been reviewed in the last 12 months, or if you do not have one at all, we can help you understand where the gaps are and what it takes to close them. Reach out to our team or book a time below.

Frequently Asked Questions About Cyber Incident Response Plans in Australia

Is a cyber incident response plan legally required in Australia?

For most businesses it is not strictly legally required to have a documented plan, but having one is increasingly expected as part of demonstrating reasonable security practices. Businesses in critical infrastructure sectors may have more specific obligations. Cyber insurance policies often require evidence of a documented response process as a condition of coverage. And if a breach occurs and you cannot demonstrate that you responded reasonably and promptly, your exposure to regulatory and legal consequences is meaningfully higher.

How often should a cyber incident response plan be updated?

At a minimum, annually. In practice, any significant change to your IT environment, business structure, or the threat landscape should trigger a review. Changes that commonly require plan updates include: adopting new cloud services, significant staff changes in key roles, office relocations, mergers or acquisitions, and experiencing an actual incident. The post-incident review section of the plan should always feed back into an updated version of the document.

Who should own the incident response plan in a small business?

In a small business without a dedicated IT or security function, the plan owner is typically the CEO, COO, or operations manager, not the most technically inclined person in the office. This matters because the plan owner needs authority to make decisions during an incident, access to the organisation’s legal and insurance contacts, and enough business context to make the right calls under pressure. The technical work is handled by the MSP. Leadership owns the plan.

What is the difference between a business continuity plan and an incident response plan?

A cyber incident response plan focuses specifically on how you detect, contain, investigate, and recover from a cyber security event. A business continuity plan is broader and covers how the business maintains operations across a range of disruptive scenarios, including cyber incidents but also physical disasters, staff unavailability, and supplier failures. The two plans should be aligned and reference each other but they serve different purposes. If you have only one, start with the incident response plan as it addresses the most immediate and common threat.

Should you pay ransomware and does paying guarantee recovery?

The Australian government’s position is that paying ransom is discouraged because it funds criminal activity and does not guarantee data recovery. In practice, businesses face genuine operational pressure when facing encryption of critical systems and no viable backup. If payment is being considered, involve your cyber insurer before paying, notify the relevant authorities, get legal advice on your obligations, and understand that decryption tools provided by attackers do not always work correctly or completely. This decision should be made with full information rather than in panic within the first few hours of an attack.

How does an MSP help with incident response compared to handling it internally?

A managed security provider brings three things that internal teams rarely have during an incident: experienced incident commanders who have done this before and know how to prioritise under pressure, the technical tooling to investigate and contain quickly across your environment, and familiarity with your systems that means they are not starting from scratch when the incident occurs. Internal IT teams are valuable but are typically managing a live incident for the first or second time and are simultaneously dealing with pressure from multiple directions. Having a prepared external team with a defined escalation process materially improves outcomes.

---

If you want to review your current incident response plan, build one from scratch, or test whether your team is ready to respond effectively, we would be glad to work through it with you. Book a time with our team here.