Cyber Incident Response Planning for Australian Businesses: Roles, Steps and Reporting
How Australian businesses plan for cyber incidents: roles, escalation, backups, communications, evidence, recovery, lessons learned and reporting obligations.
What should an Australian incident response plan cover?
An incident response plan should say who leads and decides, how incidents are detected and escalated, how to contain damage while preserving evidence, how to restore from backups, how to communicate with staff, customers and partners, which reporting obligations to check, and how to learn from what happened. In Australia, those checks typically include the Notifiable Data Breaches scheme, ransomware payment reporting for larger businesses, sector rules such as the SOCI Act, and contacting ASD's ACSC for help.
This guide is for owners and managers of Australian small and medium businesses, and for the IT and software providers who support them. It covers preparation, roles, escalation, backups, communications, evidence, recovery and lessons learned. Every incident is different; use this as a planning framework and verify obligations with official sources or qualified advisers.
ASD publishes cyber incident response plan guidance and a template that this article complements (ASD's ACSC). For preventive controls, see website security for Australian small businesses and secure web application development.
Key takeaways
- Write the plan before you need it, and keep a printed or offline copy.
- Name an incident lead, a decision-maker and deputies, with out-of-hours contacts.
- Define what counts as an incident and when to escalate.
- Contain without destroying evidence; keep a timeline of actions.
- Keep backups separate from production and test restores regularly.
- Know your possible reporting obligations: NDB, ransomware payments, sector rules.
- Practise with tabletop exercises and update the plan afterwards.
Preparation: the plan and the people
| Role | Responsibilities |
|---|---|
| Incident lead | Coordinates the response, keeps the timeline, calls meetings |
| Decision-maker | Approves major decisions: shutdowns, notifications, external help, payments |
| Technical lead | Investigation, containment and recovery, with internal IT or providers |
| Communications lead | Staff, customer, partner and media messages, approved by the decision-maker |
| Privacy and legal | Assess breach obligations; engage lawyers and insurers |
| Providers | Hosting, software, managed IT and payment providers, with contacts and contract terms |
Detection and escalation
Define what staff should report and how: suspicious emails clicked, unexpected password resets, unusual payments, ransom notes, customer reports of strange messages, security alerts from tools or providers. Make reporting easy and blame-free.
Set escalation triggers: for example, any suspected access to personal information, any ransomware, any payment redirection, or any system outage with an unknown cause goes to the incident lead immediately. Classify incidents by severity so the response matches the impact.
Containment, evidence and eradication
- Isolate affected devices or accounts from the network rather than wiping them.
- Reset compromised credentials and revoke sessions and API keys, starting with administrators.
- Preserve logs, emails, ransom notes and system images where possible, and record who did what and when.
- Use a separate, trusted communication channel if email or chat may be compromised.
- Check suppliers and integrations that could be affected or be the source.
- Remove the attacker's access and the cause (for example, an unpatched system) before restoring.
- Get specialist incident response help for anything beyond your team's experience.
Pro tip
Our recommendation: keep a simple incident log template ready (time, action, person, outcome). In the first hours people forget what they did, and that record matters for investigation, insurers and regulators.
Backups and recovery
Recovery depends on backups that attackers cannot reach and that you have restored before. Keep backups separate from production (offline or immutable where possible), protect backup accounts with MFA, and test restores regularly against agreed recovery objectives. During recovery, restore from known-good backups, rebuild compromised systems rather than cleaning them where possible, patch the entry point, and monitor closely for the attacker returning. Backups are one of ASD's Essential Eight strategies.
Communications
Prepare holding statements in advance for staff, customers and partners (an AI-drafted statement still needs human approval; see AI governance). Communicate facts you have verified, what you are doing and what people should do (for example, watch for phishing that uses their details). Do not speculate. Coordinate with legal advisers and insurers before public statements. If customer data is involved, notifications under the NDB scheme have specific content requirements.
Reporting obligations to check
Obligations depend on your business and the incident. Check each, and get advice.
| Obligation | Who it applies to | Key requirement |
|---|---|---|
| Notifiable Data Breaches | Organisations covered by the Privacy Act | Assess suspected eligible breaches (generally within 30 days); notify the OAIC and affected individuals if serious harm is likely (OAIC) |
| Ransomware payment reporting | Businesses with turnover over A$3 million; critical infrastructure entities | Report a ransomware or extortion payment to ASD within 72 hours (Home Affairs) |
| SOCI Act incident reporting | Responsible entities for critical infrastructure assets | Report critical incidents with a significant impact within 12 hours, and other incidents with a relevant impact within 72 hours |
| Sector and contract rules | For example, financial services, health, government suppliers | Regulator notifications, customer contract notices, insurer conditions |
| Reporting to ASD | Anyone | Voluntary reporting and free advice via cyber.gov.au/report or 1300 CYBER1 (ASD's ACSC) |
Worth noting
This table summarises obligations for planning purposes as at October 2026. It is not legal advice. Thresholds, timeframes and exemptions matter, so confirm your position with the OAIC, Home Affairs, CISC, your regulator and your lawyers.
Lessons learned
After every significant incident, and after exercises, hold a blameless review: what happened, what worked, what did not, and what will change. Turn findings into tracked actions with owners and dates (a penetration test can verify fixes for application weaknesses), such as enabling MFA on a missed system, improving logging or updating supplier contracts. Update the plan, contacts and playbooks.
Practising: tabletop exercises
- Ransomware encrypts the file server on a Friday evening.
- A staff email account is compromised and sends fake invoices to customers.
- A supplier tells you a database containing your customers' details was exposed.
- Your website is defaced or redirects to a scam page.
- An AI tool or agent takes an unintended action with customer data; see AI agent incident response.
Software and supplier readiness
Your software and IT providers are part of the response. Make sure contracts state incident notification timeframes, cooperation, access to logs and support hours; that your business owns admin accounts and can revoke supplier access; and that applications produce the logs investigators need. See software maintenance contracts and application monitoring and observability.
Common mistakes
- No plan, or a plan nobody has read.
- Contacts that are out of date or only stored on the systems that are down.
- Wiping systems before preserving evidence.
- Backups on the same network and credentials as production.
- Public statements before facts are known.
- No review afterwards, so the same gaps remain.
Sources
ASD: ASD's ACSC, cyber incident response plan guidance; ASD's ACSC, contact and reporting.
Obligations: OAIC, about the NDB scheme; Home Affairs, ransomware payment reporting factsheet; Cyber and Infrastructure Security Centre.
SOCI timeframes and some ASD details were confirmed via search summaries of official pages. Tables, checklists and scenarios are ours. Nothing here is legal advice or ZSpace client data.
Conclusion
Good incident response is mostly preparation: a short plan people know, clear roles, tested backups, ready communications and a list of obligations to check. When something happens, contain carefully, preserve evidence, get help early, including from ASD, and learn from it afterwards. Verify your reporting obligations with official sources or advisers rather than assuming.
Want your applications ready for an incident?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on secure, well-logged web applications. We are not an incident response provider, but we can help make your software easier to investigate and recover.
Common questions.
A cyber incident response plan sets out how your organisation will prepare for, detect, respond to and recover from cyber security incidents: who decides, who does what, how you escalate, how you communicate, how you preserve evidence, and which reporting obligations you check. ASD publishes guidance and a template that small and medium businesses can adapt.