Country-specific guidance Current

Cyber incident and ransomware reporting obligations

What to do, and how quickly, if your firm has a cyber incident.

A ransomware payment carries its own separate reporting obligation, on its own clock. This guide sets out what that obligation involves. It is general information, not legal or incident-response advice.

Action plan

1 Know the 72-hour reporting clock for ransomware payments The reporting clock starts from the payment or from becoming aware of it, whichever is relevant.

Under the Cyber Security Act 2024's ransomware payment reporting obligation, a reporting business entity must report within 72 hours of making a ransomware or cyber extortion payment, or of becoming aware that such a payment has been made. Freeze this clock's start date the moment either trigger occurs.

  • Start the 72-hour clock from the payment, or from becoming aware of it
  • Record the exact trigger time as part of the incident log
  • Don't wait for a full internal investigation to complete before reporting

Done when: The 72-hour reporting clock is tracked from the correct trigger event

ACSC: ransomware payment and cyber extortion payment reporting
2 Confirm whether your firm is a reporting business entity Not every firm carries this obligation -- check the threshold before assuming it applies.

The reporting obligation applies to reporting business entities, generally businesses carrying on business in Australia above a turnover threshold, plus entities responsible for critical infrastructure assets. Confirm your firm's status rather than assuming the obligation does or doesn't apply.

  • Check whether your firm meets the reporting business entity threshold
  • Check separately whether your firm is responsible for a critical infrastructure asset
  • Reassess this status if your firm's structure or turnover changes materially

Done when: Your firm's status as a reporting business entity has been confirmed, not assumed

3 Preserve evidence before remediation destroys it Remediation urgency and evidence preservation can pull in opposite directions -- plan for both.

In the rush to contain and remediate an incident, evidence that would support the report and any later review can be lost. Freeze destructive automation and preserve logs as an early incident step, before remediation actions overwrite what happened.

  • Freeze destructive automation and back up logs as an early incident-response step
  • Escalate to security and legal before taking irreversible remediation actions
  • Keep the incident log and evidence separate from the systems being remediated

Done when: Evidence was preserved before remediation actions could destroy it

See keeping an audit trail of who reviewed and approved a record