Ransomware First 24 Hours: What to Do If You Are Hit

Encryption is usually the last thing a ransomware attacker does, not the first. By the time a ransom note appears, the attacker has typically been inside the network long enough to find the backups, collect credentials and, increasingly, copy data out. The note is the moment the attack becomes visible to you. It is rarely the moment it began.

That changes what the first 24 hours are for. The aim is not to resolve the attack in a day. It is to stop it spreading, make a small number of decisions properly, and meet obligations that start running whether or not the business is ready. One of those obligations is newer than most people realise. Under the Cyber Security Act 2024, many Australian businesses must report a ransomware payment to the government within 72 hours of making it.

What follows is the order we would work in. The technical steps are covered briefly, because we have set them out in our step-by-step guide to responding to a cyberattack or data breach. The calls, decisions and legal duties get more space, because they are what tend to catch businesses out.

The first hour: contain it and keep the evidence

Disconnect the affected devices from the network by unplugging the cable and turning off Wi-Fi. If you have endpoint detection and response (EDR) software, which watches devices for attacks and can isolate them remotely, use it to isolate the devices from the console.

One point deserves care. The Australian Signals Directorate’s published guidance for businesses tells people to turn off an infected device, then their other devices, to stop the spread. Many incident responders prefer to disconnect a device and leave it powered on, because shutting it down erases the contents of its memory, which can show how the attacker got in. If encryption is still spreading and nobody qualified is available, stopping it matters more than preserving evidence. If someone qualified is on the phone, ask which they want before anyone pulls a plug.

Do not wipe, reimage or restore anything yet, and do not delete the ransom note. Photograph it. Start a written log of when the attack was noticed, who noticed it, what is affected and every action taken from this point. Assume the attacker may be able to read your email and chat until you know otherwise, and hold incident conversations by phone or on a channel outside your normal systems.

Hours one to four: declare the incident and make the calls

Someone with the authority to do so needs to formally declare an incident. This step starts insurance and reporting clocks, and it is the one most often delayed in the hope the problem turns out smaller than it looks. Who holds that authority should already be settled. Our piece on incident response accountability covers how to decide.

Then make the calls, roughly in this order:

• Your cyber insurer. Many policies require prompt notification, and many require the insurer’s approval before a response firm is engaged, negotiations begin or any payment is made. Read the wording now rather than after the first call to a responder. Our piece on what cyber insurers are now asking explains why the policy and the actual setup need to match.
• Your IT provider or security team, including whoever monitors your endpoint protection. They hold the logs, and logs are the first thing an investigation needs.
• Legal counsel with cyber and privacy experience. Many insurers provide access to this as part of the policy. Advice at the start shapes how the investigation is run and recorded, which matters if the incident later becomes a dispute or a regulatory matter.
• The Australian Cyber Security Centre. Its hotline, 1300 CYBER1 (1300 292 371), operates 24 hours a day, and incidents can be reported through ReportCyber at cyber.gov.au.

Hours four to twelve: work out what was taken and what still works

Two questions decide most of what happens next. What data left the business, and can it recover without the attacker’s help?

Many ransomware attacks now involve theft as well as encryption. The attacker copies data first, then threatens to publish it. Restoring from backup therefore does not always end the matter. The investigation needs to establish which systems and accounts were affected, and whether there is any sign of data leaving.

Backups need to be checked rather than assumed. That means confirming they exist, that the attacker could not reach them, and that they restore cleanly. Backups that were not immutable, meaning locked against change or deletion for a set period, are a common casualty. We explain what qualifies in our piece on immutable backups.

If personal information may be involved and the business is covered by the Privacy Act 1988, the Notifiable Data Breaches scheme applies. The business has up to 30 days to assess whether an eligible data breach has occurred, but that assessment is expected to be prompt. Where serious harm is likely, the Office of the Australian Information Commissioner and affected individuals must be notified as soon as practicable. This is a different test and a different clock from the ransom payment report described below, and one does not replace the other. Customer contracts may set their own notification windows, and critical infrastructure operators have separate incident reporting duties.

Hours twelve to twenty-four: decide, communicate and keep records

By now the business will usually be facing the question of payment. The government’s position is clear. It strongly discourages paying, because payment does not guarantee data will be decrypted, does not prevent it being published or sold, and does not stop another attack.

Paying a ransom is not generally illegal in Australia, but certain payments can be. Payments to sanctioned individuals or entities may breach sanctions law and attract criminal penalties, and payments can also raise obligations under anti-money laundering and counter-terrorism financing law. That is why the decision belongs with leadership, legal counsel and the insurer, and not with IT alone.

In our view, a business decides from a stronger position once it knows what it can recover without paying. A backup that has been verified as clean and restorable is the strongest argument against payment, and by this point in the day it should be possible to say whether the business has one.

Tell staff first, in plain terms, what is known, what is not, and who the single contact is for questions. Then tell the customers and suppliers who are affected, using only the facts established so far. Avoid speculating about cause or scale. If your usual channels are down, decide what replaces them.

Keep a record of every contact with the attacker: when it happened, what was said, what was demanded and what was offered. If a payment is made, the report asks for it.

If a payment is made: the 72-hour reporting rule

Since 30 May 2025, Part 3 of the Cyber Security Act 2024 has required certain businesses to report ransomware and cyber extortion payments to the Australian Government. The Department of Home Affairs ran the first six months, to 31 December 2025, as an education-first period. From 1 January 2026 it moved to a more active compliance focus. Home Affairs administers the obligation. The Australian Signals Directorate receives the reports but is not the regulator.

Who it applies to. A business carrying on business in Australia with annual turnover above $3 million in the previous financial year, or the responsible entity for a critical infrastructure asset under the Security of Critical Infrastructure Act 2018, whatever its turnover. A business that operated for only part of the year pro-rates the threshold using a formula in the rules. Not-for-profits are not explicitly exempt. Commonwealth and state bodies are excluded.

What counts as a payment. Money, and also non-monetary benefits such as services or gifts given to the extorting party in response to the demand. A demand that is refused, with nothing paid, does not trigger the report. Scams and physical extortion fall outside the obligation.

When the 72 hours starts. From the moment the payment is made, or from the moment the business becomes aware that a payment was made on its behalf. It does not start when the attack begins. A negotiator, response firm, insurer or parent company may make the payment, and the business remains responsible for the report.

How to report. Through the reporting form on the ASD website at cyber.gov.au. A unique reference number is generated, but a copy of the report is not provided, so save your own as you complete it.

What the report asks for, where the information is known or can be found through reasonable inquiry:

• the business’s contact details and ABN, and those of whoever paid if it was not the business
• when the incident occurred, when the business became aware of it, and its impact on the business and its customers
• the ransomware variant and any vulnerabilities exploited, if known
• the amount and method of payment demanded, and the amount and method of payment made
• a description of communications with the attacker, including any negotiation before payment

If you do not report. A civil penalty of up to 60 penalty units may apply. A Commonwealth penalty unit has been $364 since 1 July 2026, which puts 60 units at $21,840.

How the information is protected. Home Affairs states that information in a report may be used only for limited purposes, such as helping the business respond to the incident. It is generally not admissible against the business in most court proceedings, and reporting does not affect legal professional privilege. There are exceptions, including proceedings about a failure to report or about false or misleading information. Telling the National Cyber Security Coordinator about an incident voluntarily is a separate process and does not satisfy the mandatory requirement. Home Affairs sets all of this out in its ransomware payment reporting factsheet.

Because the clock runs from the payment, the practical risk is not that businesses will ignore the rule. It is that nobody will own it in the middle of a response. The details the report asks for are mostly the ones a good incident log already holds.

Where the first 24 hours tend to go wrong

The plan sits on the systems that are down. An incident response plan stored on a file server that is now encrypted is of little use at six in the morning. A printed copy, or one held outside the business’s own systems, with the insurer’s claims number, key contacts and the name of the person who decides, is one of the cheapest preparations available.

Attacks do not keep business hours. Attackers often launch encryption in the evening, over weekends and on public holidays, when fewer people are watching. The first hours of the 24 may fall when nobody senior is at a desk. Someone has to be able to take the first call and know what to do with it. We explain how that works in our piece on what a 24/7 SOC actually does.

The person who pays is not always the person who reports. In our experience, the party arranging a payment is often not the party responsible for filing the report. Unless the plan names who confirms that a payment happened and who lodges the report, each side can reasonably assume the other has it.

The reporting step rarely appears in exercises. Tabletop exercises, where a team walks through a simulated incident, tend to focus on containment and recovery. Adding a scenario in which a payment is made, and asking who files what within 72 hours, takes little time and tests a step with legal consequences.