What a CIRP Is, and What It Isn’t
A cyber incident response plan is not a general IT disaster recovery plan. A disaster recovery plan focuses on restoring operations after any disruption: power failure, hardware fault, natural disaster. A CIRP is specifically about security incidents: breaches, ransomware, insider threats, supply chain compromises.
The CIRP defines roles, escalation paths, communication protocols, evidence preservation requirements, and notification timelines. It tells your team what to do, in what order, and who has authority to make decisions under pressure.
A Business Continuity Plan (BCP) is also different. The BCP is about keeping operations running through a disruption. The CIRP is about containing and eradicating a security threat and preserving evidence for legal and regulatory purposes. In a serious incident you’ll run both, but they serve different purposes and should be maintained separately.
The ACSC Framework: Six Phases
ASD’s December 2024 Cyber Security Incident Response Planning practitioner guidance aligns with a six-phase model. Your plan should address all six.
1. Preparation
This is everything you do before an incident occurs. It includes building the plan itself, defining roles, establishing communication trees, ensuring logging is configured correctly, maintaining an up-to-date asset register, and running tabletop exercises to test whether the plan actually works. Preparation is where most organisations underinvest, and it’s the phase that determines how badly an incident hurts.
2. Identification
Detection and confirmation. Not every alert is an incident. The identification phase involves confirming that what you’re seeing is a genuine security incident, establishing its scope, and triggering the formal incident response process. Speed matters here. The longer an attacker is undetected, the more damage is done.
3. Containment
Stop the spread. Containment typically involves isolating affected systems from the broader network, disabling compromised accounts (disabling, not deleting, to preserve logs), and cutting off the attacker’s access paths. Short-term containment stops the bleeding. Long-term containment prepares the environment for eradication.
4. Eradication
Remove the threat from your environment entirely. This means identifying the root cause, removing malicious code or compromised credentials, patching the vulnerability that was exploited, and confirming the threat has been cleared. Reimaging machines without first understanding the initial access vector is a common mistake: the attacker may have multiple footholds.
5. Recovery
Restore systems and validate integrity. Don’t restore from backups until you’ve confirmed the backups are clean and the initial vector has been closed. Monitor restored systems closely for any signs of re-compromise in the days following recovery.
6. Lessons Learned
Conduct a post-incident review. What was the initial vector? How long was the attacker present before detection? What did the response get right and where did it break down? Update the plan accordingly. This phase is where the plan improves. Organisations that skip it are more likely to face the same incident twice.
Roles and Responsibilities to Define in Your Plan
A plan is only useful if people know their role before the incident starts. At minimum, your plan should define:
- Incident Commander: The person with overall authority and accountability during an incident.
- Technical Lead: The person responsible for technical investigation, containment, and eradication.
- Communications Lead: Manages both internal communications (staff, board) and external communications (customers, media, regulators).
- Legal Counsel: Needs to be contacted early. Legal privilege considerations apply to communications about the incident, and your legal team will guide notification decisions.
- Executive Sponsor: A senior leader with authority to approve major decisions, such as taking systems offline or authorising significant remediation spend.
The ACSC recommends rehearsing these roles through tabletop exercises at least annually. Cyber insurers are increasingly requiring documented roles and evidence of testing as a condition of coverage.
Australian Notification Obligations
This is the area most CIRPs get wrong or underspecify. Australian businesses have multiple, overlapping notification obligations depending on the nature of the incident and the sector they operate in.
Notifiable Data Breaches (NDB) scheme: Under the Privacy Act, organisations must notify the OAIC and affected individuals when a data breach is likely to result in serious harm. You have 30 days from becoming aware of a suspected breach to assess whether it is notifiable. The OAIC has been explicit that the 30-day assessment period is not a 30-day delay before notification.
Mandatory ransomware reporting: From 30 May 2025, businesses with annual turnover above $3 million must report ransomware payments to the ASD within 72 hours of making or becoming aware of the payment. This is a new obligation under the Australian Cyber Security Act 2024.
APRA CPS 234 (financial services): APRA-regulated entities must notify APRA within 72 hours of becoming aware of a material cyber security incident. This applies to banks, insurers, and superannuation funds regulated under APRA.
Security of Critical Infrastructure Act (SOCI): Operators of critical infrastructure assets have mandatory reporting obligations for cyber incidents. The specific requirements depend on the sector and the asset classification.
Check the most current OAIC and ASD guidance at time of publication for exact thresholds and current requirements. Notification obligations are an active area of regulatory development.
Testing and Keeping the Plan Current
A plan that’s never been tested will fail under pressure. The roles are unfamiliar, the escalation paths unclear, and the first real incident becomes a discovery exercise rather than a response.
Run a tabletop exercise at least annually. Walk the relevant team through a realistic scenario: a ransomware notification appearing on a workstation, or a call from a supplier saying their systems have been compromised and they access your environment. Work through the plan step by step and identify where it breaks down.
Review the plan after any near-miss, and update it whenever the business changes materially: new systems deployed, significant new third-party access granted, key role changes. A plan built around your environment from two years ago may not accurately reflect your current exposure.
Regulators and courts are now factoring in not just whether a plan existed, but whether it was actively maintained and tested. The question isn’t only ‘did you have a plan?’ It’s ‘was it current and had you practised it?’
Conclusion
An incident response plan that was written once and never revisited isn’t a plan. It’s documentation. The difference between the two shows up when something goes wrong at 11pm on a Friday. If your plan needs updating or building from scratch, Gridware’s incident response team can help.
Frequently asked questions
What is a cyber incident response plan?
A cyber incident response plan (CIRP) is a documented set of procedures for how your organisation responds to a security incident. It defines roles, escalation paths, communication protocols, evidence preservation requirements, and notification timelines. The goal is to ensure your team knows exactly what to do, who has authority to decide, and what your legal obligations are, before an incident happens rather than during one.
What are the six phases of incident response?
The ACSC framework covers six phases: Preparation (building the plan, defining roles, testing); Identification (detecting and confirming an incident); Containment (stopping the spread, isolating affected systems); Eradication (removing the threat from the environment); Recovery (restoring systems and validating integrity); and Lessons Learned (post-incident review and plan update).
Is a cyber incident response plan legally required in Australia?
Not explicitly required for most businesses as a standalone obligation. However, under Australia’s Privacy Act, organisations must take ‘reasonable steps’ to protect personal information and respond to breaches. The October 2025 Federal Court ruling confirmed that reasonable steps are assessed against the known threat environment. Not having a documented, tested plan is increasingly difficult to defend as reasonable in that context. APRA-regulated entities have specific response obligations under CPS 234.
When do I need to notify the OAIC after a data breach?
Under the Notifiable Data Breaches scheme, if a breach is likely to result in serious harm to any affected individual, you must notify the OAIC and affected individuals. You have 30 days from becoming aware of a suspected breach to complete your assessment. Don’t treat that as a delay period. Start the assessment immediately. Check oaic.gov.au for current requirements.
What is the mandatory ransomware reporting requirement in Australia?
From 30 May 2025, businesses with annual turnover above $3 million must report ransomware payments to the ASD within 72 hours of making or becoming aware of the payment. This is a requirement under the Australian Cyber Security Act 2024. Verify current requirements at cyber.gov.au.
How often should I update my incident response plan?
Update it after any near-miss or incident, after any material change to your business (new systems, significant new third-party access, key role changes), and at least annually regardless of whether those triggers occur. Test it through a tabletop exercise at least once a year.
What’s the difference between a cyber incident response plan and a business continuity plan?
A Business Continuity Plan (BCP) focuses on keeping operations running through any kind of disruption. A CIRP focuses specifically on security incidents: containing the threat, preserving evidence, meeting notification obligations, and eradicating the attacker. In a serious incident you’ll run both, but they serve different purposes and should be maintained separately.
