Workflow GuideAustraliaRansomware Payment Reports

Cyber Security Act 2024 ransomware payment reporting workflow

Start this workflow after a ransomware or cyber extortion payment to decide whether Part 3 applies, start the 72-hour report clock, collect the required report fields, and preserve the evidence behind the submission.

The workflow is based on the Cyber Security Act 2024 and the Cyber Security (Ransomware Payment Reporting) Rules 2025. It supports operational planning but does not replace case-specific legal, contractual, insurer, sanctions, or law-enforcement advice.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Sections
4

Structured answer sets in this page tree.

Primary sources
9

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 24, 2026
Overview

Australia's reporting regime became operational at the end of May 2025. The Federal Register commencement table lists 29 May 2025 for Part 3, while Home Affairs guidance describes mandatory reporting as active from 30 May 2025. A must give a ransomware payment report within 72 hours after making the payment or becoming aware that the payment has been made, whichever applies. Identify the trigger, confirm scope, gather information the entity knows or can find by within the reporting window, file through the Australian Government form on cyber.gov.au, and preserve the submitted record.

Section 1

Start with the payment trigger and scope test

Open Part 3 triage only when all five conditions are present. An incident has occurred, is occurring, or is imminent; it is a ; it has had or could reasonably be expected to have a direct or indirect impact on the entity; an has made a demand to benefit from the incident or its impact; and a payment or benefit directly related to that demand has been provided. Include ransom, cyber extortion, and non-monetary benefits because the Act covers benefits as well as money.

Confirm the Act's test instead of relying on the incident label. Section 9 requires an event covered by the SOCI Act meaning or an unauthorised impairment of electronic communications to or from a computer, plus a listed constitutional connection. For incidents outside the critical-infrastructure-asset and constitutional-corporation limbs, section 26 presumes the event is a cyber security incident if it was probably internet-enabled, probably impaired a computer's connection, or probably seriously prejudiced specified Australian interests. The presumption cannot support civil-penalty liability if the relevant condition did not exist in fact.

The incident commander and legal or compliance lead should first confirm whether the affected entity is a at the time the payment is made. The Act covers responsible entities for critical infrastructure assets to which of the Security of Critical Infrastructure Act 2018 applies, and qualifying businesses carried on in Australia whose previous-financial-year annual turnover exceeds the prescribed threshold.

The Act uses "exceeds" and the Rules prescribe a $3 million threshold, while the current cyber.gov.au form describes the turnover option as "equal to or exceeds $3 million." Treat an exact-$3 million case as a filing-instruction discrepancy that needs prompt case-specific confirmation; do not let it delay triage or deadline tracking.

If no payment or benefit was provided, section 27 does not require a report. Keep the incident in the organisation's other reporting workflows because duties under the Security of Critical Infrastructure Act, privacy law, prudential standards, law-enforcement arrangements, insurance, or contracts may still apply.

  • Record the incident identifier, affected legal entity, payment-maker, payment date and time, and the time the reporting entity became aware that payment had been made.
  • Record the scope basis: responsible entity for a critical infrastructure asset, business carried on in Australia above the turnover threshold, or out of scope with the reason.
  • For the turnover path, record previous-financial-year turnover, whether the part-year formula in the Rules is relevant, and any exact-$3 million advice or official direction.
  • If another entity paid on behalf of the reporting entity, capture that entity's contact and business details because the Act and Rules require those details in the report.
Section 2

Run the 72-hour report clock from payment or awareness

If the made the , the workflow clock starts when it made the payment. If another entity paid on its behalf, the clock starts when the reporting business entity became aware that the payment had been made. Log the payment and awareness timestamps even when only one starts the statutory clock, then record the basis for the deadline.

Do not wait for perfect attribution or full forensic certainty. The Rules state that information is only required to the extent the knows it or can find it by within the 72-hour period. Keep a timestamped evidence log showing what was known, who searched for missing information, and which fields remained unknown at submission time.

  • Incident commander: confirms the payment or awareness trigger and keeps the incident timeline.
  • Legal or compliance lead: confirms the reporting entity, deadline, report approval path, and any privilege handling.
  • Finance or treasury owner: provides payment amount, payment method, wallet or payment-route details where known, and payment approval evidence.
  • Security operations and forensics owner: provides incident timing, ransomware or malware variant, exploited vulnerabilities where known, infrastructure impact, and customer impact.
  • Communications or negotiator owner: provides the nature, timing, and brief description of communications and any pre-payment negotiations with the .
Section 3

Build the report from statutory and Rules fields

Use the Act's six field groups as the report structure, then add the fields prescribed by the Rules. Record who is reporting, who paid if different, what happened, what was demanded, what was provided, and what communications occurred with the .

Section 27 requires the report to be given to the . The Australian Government currently directs reporting entities to the and cyber extortion payment reporting form on cyber.gov.au. The compliance owner should confirm that the live form remains the approved filing route at submission time and preserve its confirmation page or transmission record.

A third party may use the live form on behalf of the , but the statutory duty remains the reporting business entity's. Keep the submitter's authority, the reporting entity's approval, and the final submission confirmation together; a report made only in the third party's own name may not establish that the required entity reported.

Do not assume the live form's "Additional information" field is entirely optional. Rule 7(4)(g) requires information known or reasonably discoverable within the reporting window that could assist a Commonwealth or State body to respond to, mitigate, or resolve the incident. Keep that required information separate from other incident information the entity chooses to add under subsection 27(3).

  • Reporting entity details: contact and business details, if any, and address.
  • Payment-maker details: if another entity paid, its contact and business details, if any, and address.
  • Incident details: when the incident occurred or is estimated to have occurred, when the reporting entity became aware, infrastructure impact, customer impact, ransomware or malware variant if any, exploited vulnerabilities if any, and information that could assist Commonwealth or State response, mitigation, or resolution.
  • Demand details: amount or quantum demanded, or a description if the demanded was a non-monetary benefit, plus the method of provision demanded.
  • Payment details: amount or quantum actually provided, or a description if the was a non-monetary benefit, plus the method of provision.
  • Communications details: nature and timing of communications with the , a brief description of those communications, and a brief description of any pre-payment negotiations.
Section 4

Approve, submit, and preserve the evidence record

Before submission, run a short approval checkpoint that checks scope, deadline, field completeness, the source of each fact, and whether any unknown field has a reasonable-search note. Section 27 permits other information about the incident, so distinguish required fields from optional additional information and confirm the report is consistent with any parallel incident-reporting obligations.

The reporting duty does not authorise or recommend making a . Payment legality, sanctions exposure, anti-money-laundering controls, insurer consent, law-enforcement engagement, and corporate approval remain separate questions that should be addressed before payment where time and circumstances allow.

An entity that fails to give the required report is liable to a civil penalty of 60 penalty units. The report does not itself discharge any other applicable statutory, regulatory, contractual, or insurance reporting duty; assess each duty on its own terms.

After submission, retain the report package as an incident evidence record. Include the submitted report, timestamped approval, submission confirmation, source artifacts used for each field, unresolved information notes, and follow-up tasks. Also retain a privilege note where legal counsel has assessed privileged material, because the Act states that providing information in a report does not otherwise affect a claim of legal professional privilege.

The Act's use and admissibility protections are limited. They do not cover information obtained independently or information already lawfully public. The Act also allows use for action over a breach of Part 3 and for the specified criminal-law purposes. Do not describe the report as immune from all regulatory, civil, or criminal use.

  • Keep a field-by-field evidence index that links each report answer to the incident ticket, finance record, forensic note, communication log, or counsel-approved summary that supports it.
  • Keep a clock record showing the payment or awareness event, the 72-hour deadline, approval timestamp, and submission timestamp.
  • Keep a reasonable-search record for fields that were unknown, including who searched, what systems or people were checked, and when the search closed for reporting purposes.
  • Keep a distribution and use-control note for the report package, because the Act limits use and disclosure of information provided in reports and includes admissibility protections for the .
Primary sources

References and citations

legislation.gov.au
Referenced sections
  • Rules source for the $3 million turnover threshold, part-year turnover formula, and detailed report-content requirements.
"Information is only required to be given to the extent that the reporting business entity knows or is able"
legislation.gov.au
Referenced sections
  • Supports the specific report fields for ABN, address, incident timing, impacts, malware, vulnerabilities, demand, payment, and extorting-entity communications.
"the nature and timing of any communications between the entity and the extorting entity"
legislation.gov.au
Referenced sections
  • Primary Act source for the Part 3 ransomware payment reporting trigger, 72-hour deadline, report categories, civil penalty, privilege, admissibility, and use or disclosure protections.
"within 72 hours of making the ransomware payment or becoming aware"
legislation.gov.au
Referenced sections
  • Supports the six mandatory categories of ransomware payment report information in the workflow.
"the cyber security incident, including its impact on the reporting business entity"
legislation.gov.au
Referenced sections
  • Sections 27 to 32 support the 60-penalty-unit civil penalty, good-faith liability protection, legal professional privilege, admissibility protections, and the permitted-purpose limits on using or disclosing ransomware payment report information.
"does not otherwise affect a claim of legal professional privilege"
legislation.gov.au
Referenced sections
  • Supports the cyber-security-incident test and limited presumption, plus the Part 3 trigger: an affected reporting business entity, an extorting demand, and a payment or benefit provided by the entity or on its behalf.
"provides, or is aware that another entity has provided on their behalf, a payment or benefit"
Related guides

Explore more topics

Australia Compliance Statement Evidence Workflow
Evidence workflow for preparing, supplying, and retaining statements of compliance under Australia's Cyber Security Act 2024 and Smart Devices Rules.
Australia Cyber Security Act 2024 scope and definitions
Official source scope guide for Australia's Cyber Security Act 2024: relevant connectable products, consumer-grade smart devices, reporting business entities, ransomware payment reports, and SOCI overlap.
Australia Cyber Security Act and SOCI Act overlap
How the Australia Cyber Security Act overlaps with the Security of Critical Infrastructure Act for responsible entities, ransomware payment reporting, smart devices, and evidence records.
Australia Cyber Security Act Applicability Test
Decide whether the Australia Cyber Security Act 2024 applies to a smart-device product, supplier, manufacturer, or ransomware payment reporting scenario.
Australia Cyber Security Act Commencement Timeline
Cyber Security Act 2024 commencement timeline for ransomware reporting, CIRB reviews, smart-device duties, statement retention, and statutory review.
Australia Cyber Security Act Compliance Checklist
Concrete checklist items for Australian Cyber Security Act smart-device and ransomware duties, with SOCI and APRA CPS 234 evidence checks.
Australia Cyber Security Act Compliance Guide
A cited compliance guide for Australia Cyber Security Act smart-device statements, ransomware payment reporting, incident coordination, and review-board readiness.
Australia Cyber Security Act Deadlines and Calendar
Cyber Security Act 2024 dates and event-driven deadlines for ransomware payment reports, smart-device duties, records, notices, and statutory review.
Australia Cyber Security Act FAQ
Answers to Australia Cyber Security Act questions on smart device scope, statements of compliance, ransomware reports, enforcement notices, and incident review.
Australia Cyber Security Act penalties and fines
Cyber Security Act 2024 civil penalties explained by section, including ransomware reports, protected information, CIRB notices, and smart-device enforcement.
Australia Cyber Security Act recordkeeping FAQ
What records to keep for Cyber Security Act 2024 smart-device statements, ransomware payment reports, and supported SOCI or APRA overlap checks.
Australia Cyber Security Act Requirements
Australia Cyber Security Act requirements for smart-device security standards, statements of compliance, ransomware payment reports, notices, and evidence records.
Australia Cyber Security Act Statement of Compliance Evidence
Evidence guide for Australia Cyber Security Act smart-device statements of compliance: required fields, manufacturer and supplier records, five-year retention, and examination readiness.
Australia Cyber Security Act templates
Source-backed field lists for Australia Cyber Security Act smart-device scope, statements of compliance, ransomware reports, notices, SOCI overlap, and records.
Australia Cyber Security Act vs EU Cyber Resilience Act
Compare Australia's Cyber Security Act 2024 with the EU Cyber Resilience Act across smart-device duties, ransomware reporting, product-with-digital-elements scope, actors, records, and enforcement routes.
Australia Cyber Security Act vs UK PSTI Act Guide
Compare Australia's Cyber Security Act 2024 smart-device, ransomware, and SOCI-adjacent obligations with the UK's PSTI connected-product regime.
Australia ransomware payment reporting 72-hour duty
Explain when Australia's Cyber Security Act 2024 requires a ransomware payment report, when the 72-hour clock starts, and what information the report must contain.
Australia Ransomware Payment Reporting: Threshold and Report Content
FAQ answer on Australia's Cyber Security Act ransomware payment reporting scope, $3 million turnover threshold, 72-hour trigger, report fields, and evidence.
Australia Smart Device Applicability Workflow
Decide whether Australia's mandatory smart-device security standard applies, including commencement, connectivity, consumer use, exclusions, roles, and evidence.
Australia Smart Device Compliance Statement
What a smart-device statement of compliance must contain under Australia's Cyber Security Act 2024 and Smart Devices Rules, who prepares and supplies it, how long to retain it, and how to prepare for examination.
Australia Smart Device Security Standards under the Cyber Security Act
Plain-English guide to Australia's Cyber Security (Security Standards for Smart Devices) Rules 2025: scope, passwords, vulnerability reporting, support periods, statements of compliance, and evidence records.
CSA 2024 Smart Device Applicability Test
Check whether a smart device is a consumer-grade relevant connectable product under Australia's Cyber Security Act and Smart Devices Rules.
Cyber Security Act 2024 Smart Device Compliance Checklist
Checklist for Australia Cyber Security Act 2024 smart-device scope, password controls, vulnerability reporting, security-update support periods, statements of compliance, retention, and evidence.
Cyber Security Act 2024 Statements of Compliance FAQ
Australian smart-device statements of compliance: covered products, responsible actors, required contents, supporting evidence, and five-year retention.
Cyber Security Act vs EU CRA: scope and obligations comparison
Compare Australia's Cyber Security Act 2024 with the EU Cyber Resilience Act across smart-device duties, ransomware reporting, product-with-digital-elements scope, actors, records, and enforcement routes.
Cyber Security Act vs UK PSTI Act: device security obligations compared
Compare Australia's Cyber Security Act 2024 smart-device, ransomware, and SOCI-adjacent obligations with the UK's PSTI connected-product regime.
How do notices and recalls work under the Australia Cyber Security Act?
FAQ on Australia Cyber Security Act compliance notices, stop notices, recall notices, public notifications, owners, evidence fields, and cited timing.
How does the Australia Cyber Security Act overlap with the SOCI Act?
FAQ on when Australia Cyber Security Act ransomware reporting overlaps with SOCI critical infrastructure assets, responsible entities, and smart-device duties.
Manufacturer, Importer, and Supplier Duties under Australia's Cyber Security Act 2024
Cyber Security Act 2024 smart-device duties for manufacturers, importers, and suppliers, including role tests, scope, statements, and records.
SOCI overlap triage workflow for Australia Cyber Security Act
Triage SOCI Act overlap with Australia Cyber Security Act ransomware reporting and smart-device standards using separate owners, evidence, and cited scope checks.
Which smart devices are in scope under Australia's Cyber Security Act 2024?
FAQ on Cyber Security Act 2024 smart-device scope: relevant connectable products, consumer-grade criteria, exclusions, Australian consumer acquisition, and records to keep.