The Cyber Security Act 2024: Ransomware Payment Reporting Obligations

A ransomware payment is now a reportable event in Australia, and the clock starts the moment the money moves. If your incident-response runbook does not already name who files the report, to whom, and inside what window, you will be working that out during the worst 72 hours your organisation has had.

Part 3 of the Cyber Security Act 2024 introduced Australia’s first mandatory reporting obligation for ransomware and cyber-extortion payments. The obligation commenced on 30 May 2025. It does not ban paying a ransom, and it does not make the decision to pay any easier. What it does is add a fixed, short reporting duty on top of a payment decision that was already fraught, and it lands that duty at precisely the moment your response team has the least spare capacity. This is a playbook for wiring the reporting path in advance, not a summary of the statute.

What the obligation actually says

Strip it to the mechanics. A reporting business entity that makes a ransomware payment, or becomes aware that a payment has been made on its behalf, must report it to the Australian Signals Directorate within 72 hours. The report goes through the form on cyber.gov.au. The Cyber Security (Ransomware Payment Reporting) Rules 2025 set out what the report must contain, and it is more than a one-line notification.

Who is caught? Two groups. First, entities carrying on business in Australia with an annual turnover above AUD 3 million in the previous financial year. Second, responsible entities for critical infrastructure assets under the Security of Critical Infrastructure Act 2018, regardless of turnover. If you sit in either group, this applies to you the moment a payment is made, whether you made it directly or an insurer, incident-response firm, or negotiator made it for you.

The penalty for failing to report is civil: up to 60 penalty units, which at the current Commonwealth penalty unit value is roughly AUD 19,800. That figure is deliberately modest. The point of this regime is not to punish; it is to give the government visibility into a payment economy that has been almost entirely dark. Treat the small penalty as a signal about intent, not as a reason to deprioritise. The reputational and supervisory consequences of being seen to duck a reporting duty dwarf the fine.

The 72 hours is not the problem — the trigger is

Seventy-two hours sounds generous next to the tighter clocks in other regimes. It is not the duration that catches firms out; it is knowing when the clock started. The trigger is the payment, or your awareness of a payment made on your behalf. In a real incident, the payment is rarely made by the person who owns the reporting obligation. It is made by a specialist negotiator, funded through a cyber-insurance policy, executed in cryptocurrency by a third party, at an hour when your internal chain of command is stretched thin.

So the awareness event and the reporting duty can sit in two different organisations. If your contract with the incident-response firm or insurer does not require them to tell you, in writing and immediately, the precise moment a payment settles, you can breach the 72-hour window without anyone inside your business ever having touched the transaction. Fix this in the contract, not in the incident. The single most useful clause you can add to an incident-response retainer this quarter is one that obliges the provider to notify you of any payment at the moment it is made.

Anyone who has run the NYDFS equivalent will recognise the shape of this. The 24-hour payment-reporting playbook under NYDFS Part 500 forces the same discipline on a much tighter clock; the Australian version simply gives you a little more room and a lower bar for who is caught.

Privilege and limited use: read this before you draft anything

The Act carries a limited-use protection. Information given in a ransomware payment report is restricted in how it can be used and, broadly, is not admissible against the reporting entity in most proceedings, subject to exceptions — chief among them, giving false or misleading information. This is a protection worth having, but it is narrower than legal professional privilege and it is easy to squander.

The failure mode is straightforward. Your team, under pressure, drafts the regulatory report and the internal post-incident analysis in the same document, or copies raw investigative notes straight into the ASD form. Now material you would have wanted to keep under privilege has been folded into a report with only limited-use protection, and the line between the two is blurred. Decide the boundary in advance: who drafts the report, what goes in it, what stays in privileged legal channels, and who reviews the wording before it is submitted. The reporting form asks for incident detail, the demand, the payment amount and method, and your communications with the threat actor. Deciding how each of those is handled mid-crisis is how privileged material leaks. The payment-and-disclosure dilemma is now a documented, filed decision — treat the drafting of that filing with the same care as the decision to pay.

Wire it into the runbook now

The whole obligation reduces to a handful of decisions that cost nothing to make while calm and a great deal to make under fire:

  • Name the owner. One accountable person, with a named deputy, who is responsible for filing within 72 hours. Not a team, not a function — a person.
  • Pin the trigger. Contractually require every party who might make a payment on your behalf — insurer, negotiator, IR firm — to notify you at the instant of payment, in writing.
  • Separate the channels. Decide up front what goes in the ASD report versus what stays in privileged legal advice, and who signs off the wording.
  • Pre-fill the static fields. ABN, entity details, key contacts and turnover status can be drafted into a template today. Only the incident-specific facts should be written on the day.
  • Rehearse it. Put a ransom-payment branch into your next tabletop exercise, with the reporting step timed against the 72-hour clock.

This duty does not sit in isolation. Australian firms are already navigating the OAIC’s sharper enforcement posture on reasonable-steps security, and multinationals are mapping this obligation against a thickening set of overlapping regimes. If you operate across jurisdictions, fold the Australian trigger into the same view you use for the rest — the kind of single, board-level cyber-incident reporting map that stops each new duty being discovered the hard way. And read it alongside the OAIC’s expanded enforcement reach, because a ransomware event usually engages both at once.

The early enforcement posture was education-first, running through to the end of 2025. That window has closed. The reporting path is now something a supervisor can reasonably expect you to have rehearsed — and the day you need it is the one day you will have no time to build it.

Free interactive tool

Website compliance checklist

What your site has to do, based on what it actually does

Answer as much or as little as you like — the list builds as you go. Nothing is stored against your name and no email is required.

Free interactive tool

Interactive deadline calculator

Check which regulations apply to you and when

Regulation across the EU, UK, US and Asia-Pacific has moved considerably in the past eighteen months, and several headline dates have shifted more than once. Twelve questions, about three minutes.

Results are shown on screen — no email required. A dated summary is available to download, and can be sent on if that's more useful. What we do with your answers.

Most technology problems are not technology problems. They are control problems.

The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.

Full Governance by Sixteen Pillars

Govern your business. Prove your compliance.

A board assurance cockpit for EU-regulated financial firms — tamper-evident, hash-chained proof of governance across DORA, GDPR, NIS2, ISO 27001, the EU AI Act and MiCA. In development.

See what's coming