Ransom Paid? Tell the Government in 72 Hours

The first sign is never the ransom note. It is the printer. Somebody in accounts presses print at 7.42 on a Monday morning, and the printer, which has never once in its life worked first time, refuses to do anything at all. Then the shared drive will not open. Then every file on it has a new last name: invoices_march.xlsx.akira, staff_rosters.docx.akira, the_good_biscuit_recipe.pdf.akira. Somewhere in the root of the drive sits a small text file called fn.txt. It is very polite. It contains a unique code, an address that ends in .onion, and the cheerful suggestion that you get in touch.

By nine o'clock the tearoom has become a war room. The owner is on speaker from the car. The IT contractor is on speaker from a different car. Someone has found the cyber insurance policy in a ring binder labelled "IMPORTANT (MISC)". By ten, a negotiator you have never met is talking about "proof of life" for your payroll files, and someone from the warehouse, who has watched a documentary, asks whether you can pay in Bitcoin from the servo on the highway. By eleven, a figure with a lot of zeros is on the whiteboard, and the question in the room is no longer "how did this happen?" It is "do we pay?"

Hold that question for a moment, because from today there is a second question attached to it, and almost nobody in that tearoom has heard of it yet.

From Friday 30 May 2025, if your business turned over more than $3 million last financial year and you pay a ransom, you have 72 hours to tell the Australian Signals Directorate. Not your lawyer. Not your insurer. The government. That is Part 3 of the Cyber Security Act 2024, and the rules that switch it on start today.¹ Miss the deadline and you face a civil penalty of 60 penalty units, which Information Age puts at $19,800. That is the figure for a person. For a company, a court can order up to five times as much: $99,000.

None of this is a reason to panic. The new law does not ban paying, and it does not punish you for being a victim. It asks one thing: if you pay, say so. The stakes behind that one thing are real, though. ASD responded to 121 ransomware incidents in 2023–24, and those are only the ones that were reported to it. The government's own strategy says ransomware costs the economy up to $3 billion a year, and in the same breath admits that "ransomware incidents are under-reported". The new rule is the government's attempt to fix the second sentence so it can do something about the first.

So here is my plan. First, what a ransom actually buys, down to the two kinds of key that lock your files, because you cannot judge a payment you do not understand. Then why Canberra wants a receipt. Then the rule itself, clause by clause, including the bits the summaries skip. Then a worked example of the 72-hour clock, and a list of things to put in your incident plan before you need them.

Let's get into it.

Part 1: What a Ransom Actually Buys

Before we talk about telling anyone you paid, it is worth being precise about what you would be paying for. Most people picture ransomware as a kind of digital kidnapping: the files have been taken somewhere, and the money brings them home. That is not what happens. Your files have not gone anywhere. They are sitting exactly where you left them, on your own disks. You simply cannot read them anymore, and the reason you cannot is a piece of mathematics that is very good at its job.

Two kinds of lock you already use

Start with your front door. You lock it with a key, and you unlock it with the same key. Anyone who has a copy of that key can do both. That is fine for a house, because you choose who gets a copy.

Now think about a padlock. A padlock is a stranger thing than it looks. Anyone can close it: you just push the shackle down, and it clicks. No key needed. But only the person with the key can open it again. If I posted you an open padlock, you could lock a box with it and send the box back to me, and nobody on the way, not even you, could open the box again. Only I could.

Cryptographers have names for both. The front door is symmetric encryption: one secret key does the locking and the unlocking. The padlock is public-key (asymmetric) encryption: there are two keys, a public key that anyone can use to lock, and a private key, kept secret, that alone can unlock. You use both every day without noticing. When your browser shows the little padlock in the address bar, it has used public-key encryption to agree a secret with the website, and then switched to fast symmetric encryption for everything after that. (The padlock icon is, for once, an honest metaphor.)

How the machine does it

The two kinds have different strengths. Symmetric ciphers are fast. A modern stream cipher such as ChaCha20 takes a key and produces a long stream of random-looking bytes, which it mixes into the file one byte at a time. It can get through gigabytes in moments. Public-key systems such as RSA rest on maths that is easy one way and very hard the other way (multiplying two huge prime numbers is easy; finding them again from the result is not). That makes RSA excellent for locking small secrets, and slow and clumsy for locking large files.

So ransomware does what your browser does, but with a cruel twist. It uses both.

Here is how the US Cybersecurity and Infrastructure Security Agency (CISA) and its partners described the encryption used by Akira, one of the busiest groups of the last two years, in a joint advisory from April 2024: a "sophisticated hybrid encryption scheme … combining a ChaCha20 stream cipher with an RSA public-key cryptosystem for speed and secure key exchange". In plain terms, the malware arrives already carrying the attacker's open padlock (the RSA public key). It makes up a fresh random key, uses ChaCha20 to scramble your file with it at full speed, then snaps the padlock shut on that random key and throws away the unlocked copy. What is left on your disk is a scrambled file and a locked box containing the only key that could unscramble it.²

Now put the two together and the reason you cannot "just crack it" becomes obvious. The file key is random, so there is nothing to guess. The padlock is RSA, so there is nothing to pick. And the one thing that opens the padlock, the attacker's private key, was never on your network in the first place. It is sitting on a computer somewhere else, owned by someone who would like to discuss a fee.

max_tokensPOST./v1/messages

Why your backups go missing too

If that were the whole story, the answer would be simple: restore from backup and send the attackers a postcard. The attackers know this, so they go after the backups first. The same CISA advisory says Akira's encryptor uses PowerShell to delete Windows' volume shadow copies, the snapshots that power the "restore previous versions" option you may have used to rescue a document you saved over. Any backup the attackers can reach with the admin password they have just stolen is at risk too. The backups that survive are the ones they cannot reach: offline, or held under separate credentials.

How did they get in? For Akira, CISA lists the usual suspects, and the first one is depressingly familiar: a VPN with no two-factor authentication switched on, mostly through known flaws in Cisco VPN products. With no second factor, a working username and password is enough to get them onto your network. The same advisory says Akira had hit more than 250 organisations, in North America, Europe and Australia, and claimed about US$42 million in ransom by the start of 2024.

The second ransom: your data

There is one more turn of the screw, and it is the one that makes backups only half an answer. Before modern gangs encrypt anything, they copy it out. CISA calls Akira's approach a "double-extortion model": encrypt your systems, and threaten to publish what was taken. The incident response firm Coveware saw data exfiltration in 87% of the cases it handled in the last quarter of 2024, and ASD's threat report notes a rise in "data theft extortion", where attackers skip the encryption altogether and just threaten to leak.

So when the figure goes on the tearoom whiteboard, it can buy two very different things. The first is a private key. That is maths: if the decryptor works, your files come back (eventually, and often with bugs). The second is a promise not to publish or sell the copy. That is not maths. It is the word of someone whose job is extortion. When Medibank refused to pay in 2022, its chief executive said the advice was that there was "only a limited chance paying a ransom would ensure the return of our customers' data", and that paying "could have the opposite effect and encourage the criminal to directly extort our customers". Coveware puts the same idea in market terms: victims are walking away from the table because of "faulty decryption tools" and "mounting distrust" in attackers' promises.

Hold onto that distinction between the key and the promise. It matters again when we get to why the government wants your receipt.

Part 2: Why Canberra Wants a Receipt

stop_reasoneval:.pass

Imagine trying to forecast the weather with one rain gauge. You would know, with great precision, that it rained on your back step. You would know nothing about where the storm came from, where it is going, or whether the town over the hill is about to flood. Now put a gauge on every roof in the district and have everyone call in their reading. Each reading is boring. Together they draw the storm.

That is the whole argument for this law, and the government says so plainly. The 2023–2030 Cyber Security Strategy puts it in a few short sentences: ransomware is "under-reported", which limits "our national understanding"; the business model "is fuelled by payments made to cybercriminals"; and cryptocurrency lets attackers "anonymously profit". Its answer was to "co-design with industry options to legislate a no-fault, no-liability ransomware reporting obligation for businesses". The Home Affairs factsheet on the new rule says the point is to "build a more informed picture" and give "tailored advice and support". In other words: more rain gauges.

The ledger is public. The names are not.

Here is the part that took me a while to appreciate. Most ransoms are paid in cryptocurrency, usually Bitcoin; Akira, for example, asks for Bitcoin sent to wallet addresses it provides. People tend to think of crypto as invisible money. It is close to the opposite. A blockchain is a public ledger: every transfer, from every address to every other address, is written down for anyone to read, forever. It is less like a suitcase of cash and more like a bank statement pinned to the town noticeboard, with the account names left blank.

That blank is the problem. A Bitcoin address is just a long string of characters. The ledger can show you that one address sent 63.7 bitcoins to another, but not that the first address belonged to a pipeline company and the second to a gang. Once somebody fills in a single name, though, the rest of the statement starts to talk. In June 2021, the US Department of Justice took back 63.7 bitcoins of the ransom Colonial Pipeline had paid. It did so, in its own words, "by reviewing the Bitcoin public ledger" and following the transfers until they landed at an address the FBI could unlock. "Following the money remains one of the most basic, yet powerful tools we have", said the Deputy Attorney General. To follow the money, though, you have to know where it started.

A ransomware payment report fills in that first name. The amount, the time and the method of payment are exactly what an analyst needs to find your transfer on the ledger and follow it: to an exchange that knows its customers, to a wallet that also took money from another victim, to a group that was sanctioned last year. The blockchain analysis firm Chainalysis already does this from the outside. Its count for 2024 was about US$813.55 million paid to ransomware attackers, down 35% from US$1.25 billion in 2023, with the money flowing out through exchanges, personal wallets and bridges between blockchains. That is the storm seen from orbit. Reports from victims are the rain gauges on the ground.

Fewer people are paying, but enough still do

The trend is going in the right direction. Coveware says the share of its cases where the victim paid fell to an all-time low of 25% at the end of 2024, and the median payment dropped 45% to US$110,890.³ The government would like that number to keep falling. The Minister for Cyber Security, Tony Burke, has been blunt about it: "No business or individual should ever pay a ransom to cybercriminals", he said in October, as Information Age reported.

But the law that starts today is deliberately not a ban, and I think that is the right call. A ban pushes payments underground, and underground is exactly where the government cannot see them. A reporting duty keeps the rain gauges on the roof. You can still decide, with your board and your advisers, that paying is the least bad option for your business. You just cannot do it in silence anymore.

Other countries are trying stricter versions. The UK Home Office has consulted on a payment ban for the public sector and critical infrastructure, plus mandatory reporting of attacks within 72 hours, whether or not the victim pays. Australia's version is narrower: it bites only when money, or something else of value, actually changes hands.⁴

Part 3: The Rule, Clause by Clause

Summaries of this law tend to fit on a postcard: "$3 million, 72 hours, report to ASD". That is right as far as it goes. The detail matters, though, because the edge cases are where a stressed finance manager at two in the morning will get it wrong. So let us read the Act the way a lawyer would, and then translate.

When the law switches on

Section 26 of the Act says Part 3 applies when five things are all true:

1. an incident has happened, is happening or is about to happen;
2. it is a cyber security incident;
3. it has had, or could reasonably be expected to have, a direct or indirect impact on a "reporting business entity" (more on who that is in a moment);
4. someone, the "extorting entity", makes a demand of that business, or of anyone else, to benefit from the incident; and
5. the business provides, or knows that someone else has provided on its behalf, a payment or benefit to the extorting entity that is directly related to the demand.

Three words in there carry most of the weight.

"Benefit". The Act defines it in section 8 as including "any advantage", and it "is not limited to property". The December factsheet gives the examples: an attacker may want "cryptocurrency, a service or information". If you hand over a password list, or agree to do something in exchange for silence, that can be a ransomware payment too.

"Demand". The law is about extortion, not only about encryption. The factsheet says the duty is "not restricted to only ransomware incidents in the technical sense" and can extend to "data exfiltration accompanied by a demand and subsequent payment". The person demanding does not even have to be the person who broke in. If a second criminal finds your stolen data on a forum and asks you to pay to keep it quiet, and you pay, that counts.

"On their behalf". This is the clause I would underline twice. In real incidents, the victim often does not press the button. An incident response firm or a specialist negotiator handles the conversation, and sometimes the money moves through them, with the insurer reimbursing. The Act still treats that as your payment. The factsheet's own example is a business that "engages a third party service provider to negotiate and provide a payment … on its behalf".

Who has to report

The Act calls the businesses that must report "reporting business entities". Under section 26(2), you are one if, at the time of the payment, you are carrying on a business in Australia, your annual turnover for the previous financial year exceeds the turnover threshold, and you are not a Commonwealth or State body. Separately, you are one if you are the responsible entity for a critical infrastructure asset to which Part 2B of the Security of Critical Infrastructure Act 2018 applies. For those critical infrastructure operators, turnover does not matter.

The threshold itself is in the Cyber Security (Ransomware Payment Reporting) Rules 2025, at section 6: $3 million.⁵ The government chose that figure, in its own words, "to avoid imposing regulatory burden on small businesses", as Information Age reports.

There is a wrinkle for new businesses. If you only traded for part of the previous financial year, the threshold shrinks in proportion. The Rules give the formula: $3 million × (days you traded in the previous financial year ÷ days in that financial year). So a business that opened its doors 146 days before 30 June last year has a threshold of $3 million × 146 ÷ 366 (2023–24 was a leap year), which is about $1.2 million. If it turned over more than that in its short first year, it is in.

Notice that the test is "the previous financial year" at the time of the payment. If you pay in June 2025, you look at your turnover for 2023–24. If you pay in August, you look at 2024–25. A business that grows past $3 million this year will not be covered until the new financial year starts.

page_viewtool_use

What starts the clock

Here is the one-line version that I would like every incident plan in the country to carry: the clock starts at the payment, not at the demand.

Section 27(1) says the business "must give the designated Commonwealth body a report … within 72 hours of making the ransomware payment or becoming aware that the ransomware payment has been made (whichever is applicable)". A demand you refuse creates no duty under this law. A demand you are still thinking about creates no duty either. The moment the money (or the benefit) goes, the 72 hours begin. If someone else paid for you, the 72 hours begin when you find out.

Two smaller points, both easy to miss. The Act says 72 hours, not three business days, so a payment at 4pm on a Friday is due by 4pm on the Monday. And the Act says "designated Commonwealth body", which, until the Rules name someone else, means the Department of Home Affairs and ASD. In practice, the factsheet says reports go through a portal on ASD's cyber.gov.au.

Put those together and the test fits on one page. If it helps, print it and stick it inside the cover of the ring binder labelled "IMPORTANT (MISC)".

utm_source=SELECT

What goes in the report

Section 27(2) lists the headings, and section 7 of the Rules fills them in. You need to give what you know, or can find out "by reasonable search or enquiry":

• Who you are: your contact and business details, including your ABN and address. If someone else paid, theirs too.
• The incident: when it happened (or your best estimate), when you became aware of it, its impact on your infrastructure and on your customers, the ransomware or other malware used, and the vulnerabilities exploited.
• The demand: how much was demanded (or a description, if it was not money) and how they wanted it paid.
• The payment: how much was paid (or what was given) and how.
• The conversation: the nature and timing of your communications with the extorting entity, a brief description of them, and a brief description of any negotiation before payment.
• Anything that could help a government body respond to, mitigate or resolve the incident.

The Rules add a note that is a small mercy: you only have to give information you know, or can find out, within the 72-hour window. If you do not know the initial access point by Monday afternoon, you say so. Nobody expects a finished forensic report.

Read that list again with the rain gauges in mind. Amount, method, timing, the variant, the conversation: almost every field is something an analyst can use to find your transaction on the public ledger, link it to other victims and recognise the group. The form is the rain gauge.

The penalty, and what "education first" means

If a business that must report does not report within the 72 hours, section 27(5) sets a civil penalty of 60 penalty units. A Commonwealth penalty unit has been $330 since 7 November 2024, which is how the $19,800 figure is worked out. That is the maximum for an individual. Civil penalties under the Act are enforced through the Regulatory Powers Act, and section 82(5) of that Act lets a court order a body corporate to pay up to five times the stated penalty. For a company, that is up to $99,000 for each payment it fails to report.

The government has also said how it intends to start. The December factsheet says Home Affairs "is committed to an education first approach to regulation", and will "prioritise warnings, meetings and engagements, before pursuing civil penalties, especially in respect of small and medium enterprises". Information Age reports that this approach covers "the first six months of the regulation". That is a statement of intent, not a promise written into the Act. The penalty is live from today. I would plan as if it applies, and treat any leniency as a bonus.⁶

Part 4: What Happens to Your Report

aria-labelgtm.js

The obvious worry with any reporting duty is that you are writing your own charge sheet. You have just been attacked, you have paid criminals, and now you must explain in writing exactly what happened, including the vulnerability you had not patched. Who else gets to read that?

The Act's answer is what the government calls "limited use", and it is worth understanding properly, because it is good but not unlimited. Think of the report as a sealed letter handed to the watchman in a tower. The watchman can use it to keep watch. A rope keeps most of the town's magistrates away from it. But the rope has gaps, and you should know where they are.

Inside the rope

Section 29 lists what ASD and the Department can use the report for. Most of the list is about the incident itself: helping you respond to it and recover; their own functions under this Part; other Commonwealth and State bodies responding to cyber incidents; the National Cyber Security Coordinator; briefing ministers; and the functions of the intelligence agencies.

Then comes the rope. Section 29(2) says the report must not be used to investigate or enforce any breach by you of a Commonwealth, State or Territory law, with two exceptions: a breach of this Part (for example, a late report), and a breach of a law that carries a criminal penalty. Section 30 carries the same limits to anyone the report is passed on to. So a regulator cannot pick up your ransomware report and use it to build a civil case about something else, such as your security practices.

Section 32 adds a second layer: the information in the report is not admissible as evidence against you in most proceedings: criminal proceedings (other than for giving false information or obstructing officials), civil penalty proceedings (other than under this Part), other proceedings for breach of any law, including the common law, and tribunal proceedings. Coronial inquiries and Royal Commissions are carved out. Section 31 says handing information over in the report does not, by itself, waive legal professional privilege. And section 28 protects you from being sued for damages for something done in good faith to comply.

Where the rope has gaps

Two gaps matter.

The first is criminal law. The limit in section 29(2) does not cover breaches of laws with a criminal penalty. Section 32 still keeps the report itself out of most criminal trials as evidence, but the information can be used in a criminal investigation. Which brings us to sanctions. In January 2024, Australia used its cyber sanctions powers for the first time, against the Russian national it linked to the Medibank attack. The joint ministerial release was explicit: it is now "a criminal offence, punishable by up to 10 years' imprisonment and heavy fines, to provide assets to Aleksandr Ermakov … including through cryptocurrency wallets or ransomware payments". Nothing in the Cyber Security Act makes paying unlawful. Paying a sanctioned person is unlawful under a different law, and this Act does not change that. Check before you pay, not after.

The second gap is that this is one report, not the report. If personal information was taken, the Privacy Act's Notifiable Data Breaches scheme may still require you to notify the people affected and the OAIC when the breach is likely to result in serious harm.⁷ Critical infrastructure operators have their own incident reporting under the SOCI Act. Your insurer will have its own notice clauses, and listed companies have their own disclosure rules. The ransomware report does not replace any of them. It sits next to them, with its own 72-hour clock.

I think the design is sensible. Reporting should not make your position worse with a civil regulator, and the gaps are where you would expect them. But "no-fault, no-liability" describes the intent, not a free pass. Be accurate in what you file: the false-information exception is the one place the report can be used against you directly.

Part 5: Seventy-Two Hours With Tamsin

GPC:.1await

Rules are easier to see with a person in them. So meet Tamsin. Tamsin is not real, and neither is her employer; she is a worked example, so we can watch the clock run. She is finance manager at a made-up seed and nursery wholesaler in Launceston, which turned over $4.6 million in 2023–24. It has a cyber insurance policy, a part-time IT contractor and, until recently, a VPN that only asked for a password.

Thursday, 11.10pm. Someone logs in to the VPN with a password bought from a broker. By 3am they have an admin account. By 4am they have copied the customer database and the payroll folder to a cloud storage service. At 5.30am the encryptor runs, and the shadow copies vanish. Nobody is awake.

Friday, 7.42am. The printer refuses. The files are all .akira. Tamsin finds fn.txt. She calls the IT contractor, who calls the insurer's 24-hour line. The insurer appoints an incident response firm, which tells everyone to stop touching things.

Friday, 2pm. The response firm contacts the attackers through the .onion address, using the unique code. A demand arrives: a large sum in Bitcoin, for a decryptor and for "deletion" of the stolen data. No duty to report yet. A demand is not a payment.

Saturday and Sunday. Two of the three backup copies are encrypted. The third, an older offline copy, is intact but six weeks out of date. The owners, the insurer and the response firm discuss whether to pay. Someone, sensibly, asks a lawyer to check that the group is not sanctioned. Still no duty to report.

Monday, 3.40pm. The negotiator, acting for the business with the insurer's approval, sends Bitcoin from the negotiator's own wallet to the address the attackers gave. Tamsin is in a meeting with the bank. Has the clock started? For the business, the relevant moment is when it becomes aware that a payment has been made on its behalf.

Monday, 5.15pm. The negotiator emails Tamsin: payment sent, decryptor promised. The clock starts now, and runs to 5.15pm on Thursday. Seventy-two hours, not three business days.

Tuesday. The decryptor arrives. It works on most files, slowly, and corrupts some of the large spreadsheets. (Coveware's "faulty decryption tools", in person.) Tamsin opens the incident plan, finds the page headed "Ransomware payment report", and starts filling in the list from Part 3.

Wednesday, 4pm. Tamsin files the report on ASD's portal with what she knows: the ABN and address; the negotiator's business details; when the intrusion started (the response firm's best estimate, from the VPN logs); when the business found out; the impact on its systems and on its customers, whose data was copied; the variant; the likely entry point (the VPN with no second factor); the amount demanded and paid, and in what; and a summary of the contact with the attackers. She notes what is still unknown. A day early. She makes herself a cup of tea.⁸

Now look at what each system has recorded by Thursday:

• The blockchain shows a transfer from the negotiator's wallet to an address, at 3.40pm on Monday. It does not show who either party is.
• The negotiator's file shows who paid, for whom, and why.
• The insurer's claim file shows the reimbursement.
• ASD's form shows the link that none of the others shows to government: this address is a ransom, paid by this business, to this group, using this entry point.

And there is a second notification running in parallel. The copied customer database is very likely an eligible data breach, so Tamsin's business has a separate duty to the people affected and to the OAIC. If you have been following this blog for a while, you will know that Australia's privacy rules are getting stricter, not looser. The ransomware report does not tick that box.

Two variations

Change one fact and the answer changes.

If the business had turned over $2.9 million in 2023–24, it would not be a reporting business entity, and there would be no legal duty to report the payment. ASD would still want to hear about it, and the government's standing advice to anyone asked to pay a ransom is to call the Australian Cyber Security Hotline on 1300 CYBER1 and report it at cyber.gov.au.

If Tamsin's company had refused to pay, there would be no ransomware payment report at all. The privacy notification would still apply, because that duty turns on the data, not the money.

What to Do Before Anything Happens

Seventy-two hours sounds generous until you spend them restoring payroll from a six-week-old backup. The time to get ready is now, while the printer still works. Here is what I would do this week.

1. Work out whether you are covered, and write it down. Find your turnover for 2023–24. If you run a group of companies, check each entity that could plausibly make or authorise a payment, not only the parent. Check whether any of your assets fall under Part 2B of the SOCI Act; if they do, turnover does not matter. Put the answer, with the date you checked, in your incident plan. Set a reminder to check it again each July, because the test moves with the financial year.

2. Add the report to your incident response plan. Name the person who files it, and a deputy for when that person is on leave or asleep. Copy the list of fields from the Rules into a template so that, on day three, someone is filling in blanks rather than reading legislation. Make sure your plan says, in bold, that the clock starts at payment or at awareness of a payment made for you.

3. Fix the "on their behalf" gap with your insurer and responders. If an insurer, a response firm or a negotiator could pay for you, ask them now how and when they will tell you that a payment has been made. Put it in writing: who notifies, by what channel, within how long, with the amount, the method and the time. Your 72 hours start when you know, so you want to know quickly and in a form you can copy into the report.

4. Make a sanctions check part of the payment decision. Before anyone pays, someone with the right advice should check the attackers against Australia's sanctions lists. The reporting law does not make it lawful to pay a sanctioned person, and the report itself can be used in a criminal investigation.

5. Line up your other notifications. Next to the ransomware report, list the other clocks that might start in the same incident: the Notifiable Data Breaches scheme, SOCI incident reporting if it applies, your insurer's notice clauses, and any market disclosure. Different laws, different recipients, different triggers.

6. Decide your position on paying before you are under pressure. The worst time to form a view on paying criminals is eleven on a Monday morning with the figure on the whiteboard. Have the board discuss it now, and write down who can approve a payment.

7. Make paying less likely in the first place. The cheapest ransomware report is the one you never have to file. Put two-factor authentication on every remote access path, starting with the VPN. Keep at least one copy of your backups offline or under separate credentials, and test a restore. Coveware still lists phishing as a primary way in, so a little time on email security goes a long way.

If you only do one thing on that list this week, do number three. My bet is that the gap between "the payment was made" and "the person who has to report it found out" is where good intentions go to die.

Final Thoughts

Go back to the tearoom on Monday morning, with the figure on the whiteboard and the negotiator on speaker. Nothing in the new law tells the people in that room what to decide. It does not ban paying. It does not fine them for being attacked. It adds one line to their to-do list: if you pay, tell ASD within 72 hours, and give enough detail that someone can follow the money.

That is the takeaway. The law does not stop you paying. It stops you paying quietly. The clock starts at the payment, or when you learn that someone paid for you, and it runs through the weekend. The report gets strong protection from civil and regulatory use, but not from sanctions law, and it does not replace your privacy duties.

So, this week: confirm whether you are covered, put a report template in your incident plan, and ask your insurer how fast they will tell you about a payment made in your name. Then go and check that your VPN asks for more than a password.

And if, one day, it is your printer that refuses to print, remember that a decision made in panic at the whiteboard is still a decision you will have to explain in writing within 72 hours. Better to make it with a clear head and a hot cup of tea. Speaking of which, mine has gone cold while I was reading section 32, and I think I have earned a fresh one.

Notes

1. Section 2 of the Act starts Part 3 on a day fixed by Proclamation or, failing that, on the day after six months from Royal Assent (29 November 2024). Count those six months strictly and you can arrive at 29 May 2025. Home Affairs has consistently said the reporting rules start on 30 May 2025, so that is the date used here. If a payment on 29 May keeps you awake, ask a lawyer. ↩

2. CISA's Akira advisory says the group tailors its encryption to the size and type of each file and can encrypt files fully or only in part. Partial encryption is a speed trick: scramble enough of a large file to make it useless, skip the rest, and move on to the next machine before anyone notices. ↩

3. Talking does not mean paying. An incident responder quoted by Chainalysis, Kivu Consulting's Dan Saunders, estimates that only around 30% of ransom negotiations end in a payment. Negotiation often buys time to restore from backups, or to find out what was actually taken. ↩

4. The UK consultation ran from 14 January to 8 April 2025 and also floated a rule that other victims tell the government before they pay. In the US, CISA has proposed that critical infrastructure operators report ransom payments within 24 hours, although that rule is not in force yet. ↩

5. The Act says the turnover must exceed the threshold, so a turnover of exactly $3,000,000.00 is, on a strict reading, not covered. Some summaries, including Information Age's, say "$3 million or more". If your turnover is close enough to $3 million for the difference to matter, you are close enough to get advice. ↩

6. Today also brings a second change under the Cyber Security Act: the rules for the new Cyber Incident Review Board start on the same day. The Board will review significant incidents after the fact, on a no-fault basis, which is a different job from collecting payment reports. ↩

7. The test under the Notifiable Data Breaches scheme is about likely serious harm to individuals, not about whether you paid. A ransom paid for "deletion" of stolen data does not make the breach go away, because you have no way to check that the deletion happened. ↩

8. Making the tea is the only step in the whole incident plan that nobody had to be reminded about. Some controls are simply better embedded than others. ↩