If You Pay a Ransom, You Now Have to Report It. Do You Know the Process?

---

What the obligation actually is

If your organisation (or an entity within a defined turnover/threshold scope) makes a payment in response to a ransomware or cyber extortion demand, there’s now a mandatory requirement to report that payment to the relevant government body. This is separate from — and in addition to — any existing obligation to notify the OAIC of an eligible data breach if personal information was also involved.

The obligation doesn’t ask whether paying was the right call. It exists regardless of that judgement. What it requires is that the payment gets reported, on time, with the right details, by someone in your organisation who actually knows the obligation exists at the moment a ransom demand lands on someone’s desk.

---

Why most businesses aren’t ready for this

Three gaps show up consistently when we look at incident response plans against this specific requirement:

Nobody in the decision chain knows the obligation exists. A ransomware incident is chaotic. The people making the payment decision — usually a small group under significant time pressure — are focused on business continuity, not compliance obligations they’ve never had reason to think about before.

There’s no defined reporting owner. “Someone will handle it” is not a process. If the obligation isn’t assigned to a named role in advance, it gets missed in the same way any unassigned task gets missed during a crisis.

Legal and compliance aren’t looped in early enough. By the time most businesses think to check what they’re legally required to report, the payment has often already happened. The reporting clock doesn’t wait for that realisation.

---

What a defensible process actually looks like

This doesn’t need to be complicated, but it does need to exist before an incident, not during one:

1. A named decision-maker with authority to approve (or refuse) a ransom payment, documented in your incident response plan.
2. A defined reporting trigger — the moment a payment decision is made, the reporting clock starts, and someone specific is responsible for it.
3. A pre-drafted reporting template — knowing what information needs to be captured (amount, method, threat actor details where known, systems affected) before you’re trying to reconstruct it under pressure.
4. A tested tabletop exercise that includes the reporting step, not just detection and recovery — most incident response drills stop at “systems restored” and never rehearse the compliance obligation that follows.

---

Why this pairs naturally with Essential Eight

The strongest defence against ever facing this obligation is not being ransomed in the first place — which is exactly what an Essential Eight uplift is built to reduce the likelihood of. Application control, patching, MFA and regular tested backups are the controls that most directly cut ransomware risk and recovery time.

But Essential Eight reduces the probability of an incident; it doesn’t remove the obligation to have a reporting process ready if one happens anyway. We now build ransomware payment-reporting readiness — the decision authority, the reporting template, the tabletop exercise — as a standard add-on to Essential Eight engagements, because the two are naturally the same conversation: reduce the risk, and be ready if it happens regardless.