Cyber Incident Response for Australian Businesses: A Practical Checklist for What to Do When You're Attacked

A cyber incident is one of the few business emergencies where the decisions you make in the first hour can either contain the damage or dramatically worsen it. Unlike a burst pipe or a power outage, a cyber attack is invisible in its early stages, tends to spread the longer it goes unaddressed, and often involves an active adversary who is watching what you do and adapting accordingly.

Most Australian small and medium businesses will face some form of cyber incident in their lifetime — whether that is a ransomware deployment, a business email compromise, a credential theft, or an accidental data exposure. The difference between a contained, recoverable incident and a catastrophic one almost always comes down to preparation and the quality of the response in those first critical hours.

This article is designed to serve two purposes. If you are reading this because something is happening right now, jump to the immediate response section. If you are reading this to prepare, start from the beginning.

Why Preparation Is the Only Competitive Advantage in a Cyber Incident

Most cyber incidents are chaotic. Staff do not know what to do. Decision-makers are out of contact or panicking. Time is lost arguing about whether the situation is serious enough to escalate. Meanwhile, the attacker is moving laterally through the network, escalating privileges, and exfiltrating data.

The businesses that recover fastest from cyber incidents are not necessarily the ones with the most sophisticated security tools. They are the ones that had a documented plan, knew who to call, and knew what not to do. A well-rehearsed response team can contain an incident in hours that might otherwise take days to address.

The Australian Signals Directorate (ASD) and the Australian Cyber Security Centre (ACSC) publish Cyber Security Incident Response Plan Guidance specifically to help organisations of all sizes build this capability before they need it. The guidance acknowledges that even a simple, documented plan provides significant advantages over improvising under pressure.

Every hour of delay during an incident allows an attacker to go deeper into your environment, access more systems, and exfiltrate more data. In a ransomware attack, lateral movement can result in entire backup environments being encrypted alongside production systems — eliminating your recovery options. In a data breach, the attacker may be extracting customer records in the background while your team debates whether the situation warrants escalation.

This article gives you both: a preparation framework and an immediate response checklist.

Before the Incident — What to Prepare Now

The single most effective thing an Australian SMB can do to improve its cyber resilience is spend two or three hours building a basic incident response plan and rehearsing it. This is not a complex document — it is a set of contacts, roles, and agreed actions that your team can execute under pressure.

Build a contact list and keep it offline

Your incident response contact list is useless if it only exists in a system that could be compromised. If your email server is down, your internal wiki is encrypted, or your phone system is offline, where do your staff go to find the incident response contacts?

Print the contact list. Store a copy on personal phones. Keep a laminated card in the server room.

The list should include, at a minimum:

The reason finance is on this list is that ransomware incidents sometimes escalate to urgent requests to transfer funds or purchase cryptocurrency — your finance team needs to be part of the incident chain and aware of the risk.

Know what data you hold and where

You cannot assess the impact of a breach if you do not know what data you hold or where it lives. A basic data inventory does not need to be comprehensive on day one, but it should answer three questions: what categories of personal information do we hold (names, health records, financial details, identity documents), where is that data stored (cloud systems, local servers, third-party platforms, staff laptops), and who has access to it.

This inventory is the foundation of both effective breach detection and the Notifiable Data Breaches (NDB) assessment process. When a potential breach occurs, you will need to quickly determine whether personal information was involved — and that determination is almost impossible without a prior inventory.

Assign incident response roles

Incidents generate competing demands: someone needs to make decisions, someone needs to lead the technical investigation, someone needs to handle communications, and someone needs to coordinate with external parties. If these roles are not assigned in advance, they will be contested in real time — and that contest will cost you time you do not have.

Define these roles before you need them:

• Incident commander. The person who makes final decisions and coordinates the overall response. This is usually the CEO or a senior operations manager, not the most technical person in the room.
• Technical lead. The person responsible for investigating the incident, isolating affected systems, and directing remediation. This may be your MSP.
• Communications lead. The person responsible for internal communications to staff and, where required, external communications to clients, regulators, and media.
• Legal / compliance contact. The person responsible for assessing NDB obligations and coordinating with legal counsel.

Establish an out-of-band communication channel

If your email and internal messaging systems are compromised, your incident response team needs a way to communicate that does not rely on the affected infrastructure. A WhatsApp group or Signal group using personal mobile numbers is sufficient for most SMBs. The critical thing is to agree on the channel in advance so that when it is needed, no one is debating which app to use.

The Immediate Response — First 60 Minutes

The first 60 minutes of a cyber incident are the most consequential. The decisions made in this window shape everything that follows. Here is the sequence.

Step 1 — Stay calm and do not act hastily

The instinct in a crisis is to do something immediately. In a cyber incident, some immediate actions — restarting systems, deleting files, wiping devices — destroy forensic evidence and make recovery harder. Before you do anything, take a breath and call your IT provider.

Step 2 — Isolate affected systems immediately

If you suspect a device is compromised, disconnect it from the network. Unplug the ethernet cable. Turn off Wi-Fi on the device. If multiple devices appear affected, segment or disable the affected network segment entirely.

This is the single most important action to stop lateral spread. An attacker who cannot reach other systems via the network cannot continue to expand their foothold.

Critical point: do not shut the device down. Leave it running but disconnected. Shutting down a compromised device may destroy volatile memory evidence — the kind of forensic data that can reveal what the attacker did, how they got in, and what they accessed. A running-but-isolated device preserves that evidence.

Step 3 — Assess scope quickly

Before calling anyone, take two minutes to assess what you are dealing with. Is this one device or multiple? Are you still observing active suspicious activity (files encrypting, unusual logins, data being moved)? Do you have systems that are still clean and operational?

This assessment does not need to be comprehensive — your IT provider will do the detailed investigation. But a basic picture helps you communicate what is happening and prioritise the next steps.

Step 4 — Call your IT provider or MSP emergency line now

Do not attempt to investigate or remediate a cyber incident yourself unless you have trained security staff. The risk of destroying evidence, missing persistence mechanisms, or inadvertently alerting the attacker to your response is significant.

Your managed IT provider or MSP needs to be involved immediately. They know your environment, know your systems, and can begin remote triage. If you do not have an MSP, call a specialist cyber incident response firm — your cyber insurer can recommend one.

Step 5 — Call your cyber insurer

Before doing anything else externally — before paying any ransom, before engaging a forensics firm, before making any public statement — call your cyber insurer.

This step is non-negotiable for businesses with cyber insurance. Most policies require pre-approval for external forensics spend. Engaging a firm without pre-approval can void the coverage for that cost. Policies also typically have specific requirements around ransom payments and public communications.

Have your policy number ready and ask for the 24/7 claims line. This call should happen within the first hour.

Step 6 — Preserve evidence

Take screenshots of what you are seeing. Write down a timestamped log of what was observed and when — this is your incident timeline, and it will be needed for forensics, insurance, and any law enforcement involvement.

Do not delete emails, logs, or files — even if they appear to be part of the attack. Evidence preservation is critical. Your IT provider and any forensics firm will tell you specifically what to capture and retain.

The First 24 Hours — Containment and Assessment

Once immediate isolation is in place and your IT provider is engaged, the focus shifts to understanding the full scope of the incident and beginning systematic containment.

Scope the compromise. Work with your IT provider to identify which systems have been accessed, which accounts have been compromised, what data may have been accessed or exfiltrated, and how the attacker gained initial access. This is not a quick process — a thorough scope assessment can take hours — but it is necessary before you can make informed decisions about remediation.

Change credentials from a clean device. Passwords for all potentially compromised accounts should be changed immediately — but this must be done from a device that was not connected to the affected network during the incident. Changing passwords from a compromised device is counterproductive. Prioritise administrative accounts, email accounts, and any accounts with access to financial systems or sensitive data.

Revoke and re-issue service account credentials. Service accounts and API keys are frequently targeted because they have broad access and are often not monitored. If your environment has been significantly compromised, assume all service account credentials are known to the attacker and revoke them.

Begin the NDB assessment. The Notifiable Data Breaches scheme requires organisations covered by the Privacy Act to notify the Office of the Australian Information Commissioner (OAIC) and affected individuals if they experience an eligible data breach. An eligible data breach is one where there has been unauthorised access to or disclosure of personal information, and a reasonable person would conclude that the access or disclosure is likely to result in serious harm.

You have 30 days from becoming aware of a potential eligible data breach to complete your assessment. Start documenting your assessment process now — note the date and time you became aware of the potential breach, what personal information appears to have been involved, and what harm could result. This documentation protects you if the assessment timeline is later questioned.

Determine whether to report to law enforcement. The primary channel for reporting cyber incidents in Australia is ACSC ReportCyber at reportcyber.gov.au. Reporting is not always mandatory, but it contributes to national threat intelligence and may be required by your insurer or advisors. Serious cybercrime — including ransomware attacks and business email compromise — can also be reported to the Australian Federal Police or your state police, but ReportCyber is the primary and most appropriate first point of contact.

Assess whether to engage a specialist incident response firm. Depending on the severity of the incident, your IT provider may recommend engaging a specialist cyber incident response firm for forensic analysis. Your insurer can recommend firms that are approved under your policy, and many cyber insurance policies cover this cost in full or in part.

Ransomware Specifically — Additional Considerations

Ransomware requires some specific additional steps beyond the standard incident response process. If you have confirmed a ransomware deployment, read this section carefully.

Do not restart encrypted devices. Unlike other incidents where device behaviour is a concern, ransomware-encrypted devices should not be restarted. In some ransomware variants, a restart triggers additional encryption stages or deletes shadow copies that could be used for partial recovery.

Do not pay the ransom without legal and insurer advice. Paying a ransom does not guarantee decryption. Many ransomware groups provide a decryption tool that partially works, or does not work at all. Payment also does not prevent the attacker from publishing exfiltrated data or returning with a further attack. There can also be legal implications to paying ransoms to certain groups — your legal counsel and insurer need to be involved in any ransom decision. For further context on avoiding ransomware in the first place, see our guide on ransomware prevention.

Check for a free decryption tool. The No More Ransom project (nomoreransom.org) maintains a library of free decryption tools for known ransomware strains. Before considering payment, check whether your ransomware variant is covered. Identifying the specific ransomware strain (your IT provider can assist) is the first step.

Identify and close the attack vector before restoring from backup. Recovery from clean backups is the correct path for most ransomware incidents — but restoring before the attack vector is identified and closed will result in reinfection. The attacker's access method is still present in your environment. Your IT provider must identify how the ransomware was deployed before restoration begins.

Treat double extortion as an NDB trigger. Many modern ransomware groups engage in double extortion — they encrypt your data and also exfiltrate a copy, threatening to publish it if you do not pay. If the attacker claims to have exfiltrated data, treat this as a potential NDB trigger regardless of whether you choose to pay. The exfiltration itself constitutes unauthorised access to personal information.

Communication During an Incident

Communication during a cyber incident is one of the areas where businesses most commonly make errors — either by communicating too little, too late, or by communicating prematurely in ways that create additional legal and reputational risk.

Internal communication

Staff need clear, factual guidance during an incident. They need to know what not to do (do not use affected systems, do not attempt to fix it themselves, do not discuss the incident on personal social media), what is happening at a high level, and what the plan is.

Communicate through your out-of-band channel. Keep messages brief and factual. Avoid speculation about cause, extent, or timeline — you likely do not know these things with certainty in the first hours, and inaccurate internal communications have a way of becoming inaccurate public communications.

Client and customer communication

If client or customer data may have been affected by the incident, you will eventually need to communicate this. But this communication should not happen under pressure, without legal advice, and should not happen before you have a reasonable picture of what was actually compromised.

Premature or inaccurate communication can create additional legal liability — particularly if you communicate that data was accessed and it subsequently turns out it was not, or communicate that data was not accessed and it later emerges that it was. Work with your legal counsel to determine the correct timing and content of any external communications.

Regulatory notification

If the breach is determined to be an eligible data breach under the NDB scheme, you are required to notify the OAIC and affected individuals. The notification to affected individuals must include what happened, what personal information was involved, what steps the individual should take to protect themselves, and your contact details.

The content, timing, and format of this notification should be developed with legal counsel. Your insurer may also have requirements around regulatory notifications.

Media

If the incident becomes public — whether through your own disclosure or through external reporting — your communications should be factual, acknowledge the situation, describe what you are doing to respond, and avoid speculation. Do not use corporate social media accounts for incident communications during an active incident. Prepare a holding statement in advance if you have time; if you do not, keep any statement short and factual.

Recovery — Getting Systems Back Online

Recovery from a cyber incident is not simply a matter of restoring from backup and resuming operations. Done incorrectly, recovery can reintroduce the attacker into your environment.

Restore from clean, verified backups. Not all backups are clean after an incident. If your backup systems were connected to the network during the attack, they may also be compromised or encrypted. Verify the integrity of your backups before restoring — and check that the backup predates the initial compromise, not just the discovery of the incident. Attackers often persist in environments for weeks or months before deploying ransomware.

For a detailed framework on recovery planning, including RTO and RPO targets, see our guide on disaster recovery.

Harden before restoring. The vulnerability or misconfiguration that allowed the attacker in must be identified and remediated before restored systems are reconnected to the network. If you restore systems to a network that still has the same attack vector, reinfection is not a possibility — it is a near-certainty.

Verify integrity of restored systems before going live. Once systems are restored, run integrity checks before reconnecting them to production environments. Your IT provider should conduct a review of restored systems to confirm they are clean.

Monitor carefully in the weeks following recovery. Attackers frequently leave persistence mechanisms — backdoors, malicious scheduled tasks, modified configuration files — that survive a partial recovery. Enhanced monitoring in the four to six weeks following a cyber incident is essential. Alert thresholds should be lowered, log review should be increased, and any anomalous activity should be investigated promptly.

Post-Incident — Learning and Improving

A cyber incident, handled well, can become the foundation for significantly improved security posture. The post-incident review is where that improvement happens.

Conduct a post-incident review within two to four weeks. Do this while the details are still fresh. Bring together the incident commander, technical lead, communications lead, and any other key participants. The goal is not to assign blame — it is to understand what happened and improve.

Document comprehensively. The post-incident report should cover what happened and when, how the attacker gained initial access, how the incident was detected, what the response timeline looked like, what worked in the response, and what did not. This document is valuable for your own improvement, for insurance purposes, and potentially for regulatory purposes.

Identify and address root causes. Was there an unpatched vulnerability that the attacker exploited? Did a staff member respond to a phishing email? Was there a lack of multi-factor authentication on a critical account? Did your backup system fail to protect against encryption? Each root cause identified is a specific, actionable improvement.

If the root cause analysis reveals gaps in your foundational security controls, the ACSC's Essential Eight framework is the benchmark for Australian businesses. It covers the eight most effective controls for preventing and containing cyber incidents, including application patching, multi-factor authentication, and backup integrity.

Update your incident response plan. The plan you had going into the incident almost certainly has gaps that the incident revealed. Update it with what you learned — new contacts, revised procedures, additional steps.

Brief your board or management. The board or senior management team should receive a factual summary of the incident, the response, the impact, and the improvements being made. This is not a blame exercise — it is part of governance. Boards that understand the cyber threat landscape make better investment decisions about security.

ACSC Resources for Australian Businesses

The Australian Cyber Security Centre publishes a range of practical resources specifically for Australian businesses. These are free and do not require registration.

The ACSC's incident response guidance is particularly useful for building or updating your incident response plan. It covers the core phases of response — preparation, detection, containment, eradication, and recovery — and includes templates and checklists that can be adapted for businesses of any size.

The ACSC also operates the Australian Cyber Security Hotline at 1300 CYBER1 (1300 292 371), which can provide guidance during an active incident.

How Pickle Supports Cyber Incident Response

For businesses without in-house IT security resources, the speed and quality of incident response depends entirely on who you can call and how well they know your environment.

Pickle provides 24/7 monitoring, incident response coordination, and post-incident remediation for managed IT clients across Australia. Our team monitors client environments for indicators of compromise in real time — which means that in many cases, we detect an incident before the client does, and we are already investigating before the first call is made.

Having a managed IT services provider means you have an emergency contact who already knows your environment, your systems, your backups, and your users before the incident occurs. That prior knowledge is the difference between a two-hour containment and a two-day investigation.

For managed IT clients, Pickle can assist with initial isolation and triage, liaison with cyber insurers and forensics firms, NDB assessment support in coordination with your legal counsel, and post-incident hardening and remediation.

To discuss incident response planning or managed IT services, call 1300 688 588 or email [email protected].

Frequently Asked Questions

Q: Should I shut down my computer immediately if I think I have been hacked?

A: No — in most cases you should not shut the device down. Shutting down a compromised device destroys volatile memory evidence that forensic investigators use to understand what the attacker did and how they got in. The correct action is to disconnect the device from the network (unplug the ethernet cable, turn off Wi-Fi) while leaving it powered on. Then call your IT provider before taking any further action.

Q: Do I have to report a cyber attack to the police in Australia?

A: There is no legal requirement for most businesses to report a cyber attack to police. However, reporting to the ACSC via ReportCyber (reportcyber.gov.au) is strongly recommended — it contributes to national threat intelligence and may assist in coordinating a response. Serious cybercrime can also be reported to the Australian Federal Police or state police. Your cyber insurer may have specific requirements around reporting, so check your policy.

Q: How long do I have to notify customers of a data breach?

A: Under the Notifiable Data Breaches (NDB) scheme, organisations covered by the Privacy Act have 30 days from becoming aware of a potential eligible data breach to complete their assessment. If the breach is determined to be eligible — meaning personal information was accessed or disclosed and a reasonable person would conclude serious harm is likely — you must notify the OAIC and affected individuals as soon as practicable. The 30 days is an assessment window, not a notification deadline. If you already know the breach is serious, notification should happen well within that window.

Q: What is the first thing to do if ransomware is deployed on our systems?

A: Isolate affected systems immediately by disconnecting them from the network — do not shut them down. Then call your IT provider and your cyber insurer. Do not attempt to decrypt files yourself, do not restart encrypted devices, and do not pay any ransom without legal and insurer advice. Check nomoreransom.org to determine whether a free decryption tool exists for the ransomware variant affecting your systems.

Q: Can my business recover from a cyber attack without paying the ransom?

A: In most cases, yes — provided you have clean, verified backups that predate the initial compromise. Recovery from backups is the preferred path because it does not fund criminal activity, does not guarantee decryption if you do pay, and does not prevent the attacker from publishing exfiltrated data even after payment. The critical prerequisites are that your backups are intact and not also encrypted, and that the attack vector is identified and closed before restoration. This is why regular, tested, offline or immutable backups are one of the most important cybersecurity investments a business can make.