Cyber Security (Ransomware Payment Reporting) Rules 2025

The instrument relies on, and operationalises, several core concepts drawn from the Cyber Security Act 2024. Those concepts determine who must report, what triggers the obligation, the temporal reporting constraint, and the scope of information required.

Reporting business entity. The rules do not attempt a standalone definition. They reiterate that the Act defines reporting business entity, then specify two principal ways a business will generally qualify as one: being the responsible entity for a critical infrastructure asset to which Part 2B of the Security of Critical Infrastructure Act 2018 applies, or carrying on a business in Australia whose previous financial year turnover exceeds the turnover threshold (s 5). The rules therefore fold in concepts from the Security of Critical Infrastructure Act 2018 and the Act’s own definitions.

Ransomware payment and cyber security incident. Both expressions are defined in the Act and are referenced repeatedly in the instrument (s 4, note). The trigger for a reporting obligation is that the reporting business entity is impacted by a cyber security incident and has provided, or is aware that another entity has provided on its behalf, a ransomware payment to an extorting entity (s 5). The instrument thus focuses on payments intended to benefit the extorting entity as part of a cyber security incident.

Turnover threshold and prorating. The rules fix the numerical turnover threshold at $3 million for the previous financial year (s 6(1)). If a business was carried on for only part of the previous year, the instrument prescribes working out the threshold by pro rata days: $3 million multiplied by the fraction of days the business was carried on in the part over days in the financial year (s 6(2), formula).

Temporal constraint and reasonable search. The instrument applies a knowledge limitation. Information must be provided only to the extent the reporting business entity knows it, or is able to find it by reasonable search or enquiry, within the 72 hour period for giving the report (note in s 7(1)). That ties the substantive list of required fields to what is reasonably discoverable within the 72 hour window established in the Act.

Prescribed content fields. Section 7 prescribes discrete categories of information: contact and business details (own and other entity’s, with ABN and address) (s 7(2)-(3)); detailed incident information including timing, awareness, infrastructure and customer impacts, malware variants, exploited vulnerabilities, and information that could assist Commonwealth or State response (s 7(4)); details of the extortion demand (amount/description, method) (s 7(5)); details of the ransomware payment made (amount/description, method) (s 7(6)); and communications and negotiation history with the extorting entity (s 7(7)). The rules therefore convert the Act’s broader reporting requirement into specific data fields.

Permitted use and disclosure constraints. The instrument expressly notes that ransomware payment reports may only be used or disclosed for permitted purposes, including response, mitigation, or resolution of the incident, and that disclosure to a State body requires consent from a State or Territory Minister (note in s 7(4), referencing s 11 of the Act). That places a statutory limitation on downstream sharing.

Form versus substance. The instrument is concerned with the content and with the threshold mechanics. It does not prescribe a specific form, template, or transmission channel in the text supplied. It also does not specify enforcement measures or penalties; those are left to the Act. The rules therefore operate as content standards that interact with separate procedural and enforcement provisions in the Cyber Security Act 2024.

The instrument affects three overlapping groups of entities.

Reporting business entities. The primary burden falls on entities that meet the Act’s definition of reporting business entity. The rules make clear that this class normally comprises two subgroups. First, responsible entities for critical infrastructure assets to which Part 2B of the Security of Critical Infrastructure Act 2018 applies are generally reporting business entities (s 5). Second, businesses carrying on operations in Australia whose previous financial year turnover exceeds the $3 million threshold are generally reporting business entities (s 5 and s 6). Therefore, both larger private sector businesses and certain regulated critical infrastructure entities are within scope.

Other entities whose actions trigger the reporting obligation. The instrument requires reporting where the reporting business entity has provided, or is aware that another entity has provided on their behalf, a ransomware payment to an extorting entity (s 5). That means an entity need not itself have made the payment to trigger the reporting duty; awareness that another actor paid on its behalf is sufficient. The rules therefore reach intermediary or outsourced payments where the covered business is aware of them.

Commonwealth and State bodies as recipients. The rules are framed to enable Commonwealth authorities to receive detailed information about incidents, demands and payments (s 7(4) note). They also limit disclosure to State bodies unless a State or Territory Minister consents (s 7(4) note, referencing s 11 of the Act). The instrument therefore affects how Commonwealth agencies, and potentially State agencies (but only with ministerial consent), may access information reported under the Act.

Indirectly affected parties. Customers and infrastructure users will be affected indirectly because the reporting content requires details about impact on infrastructure and customers (s 7(4)(c)-(d)). The instrument compels covered entities to collect and report information about customer impacts, which may involve coordinating with third parties, service providers, and incident responders.

Who does not appear to be covered. Entities below the turnover threshold, and businesses not responsible for Part 2B critical infrastructure, are not generally reporting business entities under the simplified outline in s 5, unless otherwise defined in the Act. The rules make no provision for voluntary reporting by out-of-scope entities, and do not create secondary reporting duties for, for example, upstream payment processors unless the Act imposes those duties elsewhere. The instrument does require the ABN and address of “the other entity” if known (s 7(3)), but does not make that other entity a reporting obligation holder under the rules.

Geographic scope. The turnover test applies to businesses “carrying on a business in Australia” and uses the previous financial year as the reference period (s 5 and s 6). The instrument therefore targets businesses operating in Australia, and the pro rata rule in s 6(2) covers businesses operating for only part of the year.

Who pays and who decides. Practically, the compliance cost is borne by reporting business entities that must gather, verify and report the prescribed information within the statutory timeframe (s 7 and note). Decision-making about what constitutes “reasonable search or enquiry” within the 72 hour window, and what level of detail can be provided within that time, rests with the reporting business entity, subject to subsequent scrutiny under the Act.

Duties

Make a ransomware payment report when triggered. A reporting business entity must provide a ransomware payment report where it is impacted by a cyber security incident and has provided, or is aware that another entity has provided on their behalf, a ransomware payment to the extorting entity (s 5). The Act (Part 3) is the primary source of the obligation; the rules prescribe the information that the report must contain (s 7(1)).

Provide specified contact and business details. The reporting business entity must include its contact and business details in the report, specifically including its ABN if any and its address (s 7(2)). The reporting entity must also provide the other entity’s contact and business details, likewise with ABN if any and address (s 7(3)).

Provide detailed incident information. The report must contain substantive details about the cyber security incident, including when it occurred or is estimated to have occurred, when the reporting entity became aware of it, its impact on the reporting entity’s infrastructure and customers, what variants of ransomware or other malware were used, what vulnerabilities were exploited, and information that could assist Commonwealth or State bodies in response, mitigation or resolution (s 7(4)(a)-(g)).

Provide details of demand and payment. The report must state the amount or description and method of provision of the ransomware payment demanded by the extorting entity (s 7(5)), and the amount or description and method of the ransomware payment actually made (s 7(6)).

Provide communications and negotiation history. The report must include the nature and timing of communications with the extorting entity, brief descriptions of those communications, and a brief description of any pre‑payment negotiations undertaken (s 7(7)).

Comply within the statutory timeframe to the extent information is known or reasonably discoverable. The instrument ties required content to the 72 hour reporting period mentioned in the Act, stating that information is required only to the extent the reporting business entity knows it, or can find it through reasonable search or enquiry, within that 72 hour period (s 7(1) note).

Rights and constraints

Limits on downstream disclosure. The instrument notes that ransomware payment reports may be used or disclosed only for permitted purposes, including response, mitigation or resolution of the incident, and that disclosure to a State body requires a State or Territory Minister’s consent (s 7(4) note, cross-referencing s 11 of the Act). That constrains secondary dissemination outside Commonwealth permitted purposes.

Knowledge limitation as a de facto compliance protection. The rule that requires only information the entity knows or can reasonably discover within the 72 hour window functions as a temporal limitation on the duty. It is a compliance protection, in the sense that the entity is not required to include later-discovered information after the reporting deadline, although the Act may require updates or further reporting consistent with its provisions.

Interaction with critical infrastructure obligations. Where an entity is a responsible entity for a critical infrastructure asset to which Part 2B of the Security of Critical Infrastructure Act 2018 applies, the entity will generally be a reporting business entity and therefore subject to the reporting duties under the Act and rules (s 5). The instrument thus aligns the reporting duty with existing obligations under the SOCI Act framework.

Recordkeeping and internal processes implied. Although the instrument does not impose explicit recordkeeping clauses beyond the content required in the report, the specificity of the fields , including exploited vulnerabilities, malware variants, customer impacts, communications and negotiation summaries , creates an implicit duty for entities to collect and preserve relevant incident records to satisfy reporting (s 7(4)-(7)).

Discretionary elements requiring judgement. Several elements require judgement by the reporting entity, including determining whether it is aware that another entity has provided a payment on its behalf, what is discoverable by reasonable search or enquiry within 72 hours, and what information “could assist” a Commonwealth or State response (s 5 and s 7(1) and s 7(4)(g)). These items create compliance discretion that entities must document and justify.

This instrument does not itself specify sanctions, penalty amounts, or enforcement procedures. Enforcement mechanisms and any penalties for non‑compliance with the reporting obligation are matters in the Cyber Security Act 2024, which is the statutory authority for these rules (s 3, and the instrument repeatedly cross-references Part 3 of the Act as imposing the obligation, s 5). The instrument therefore serves as a content schedule and threshold mechanic; the Act contains the operative enforcement architecture.

What the instrument does specify that bears on enforcement

Temporal scope of required information. The rules make explicit that the required information need only be supplied to the extent that the reporting business entity knows it, or can find it by reasonable search or enquiry, within the 72 hour period for giving the report (s 7(1) note). That temporal limitation is relevant to any enforcement assessment of whether an entity complied in good faith with the reporting content requirements.

Disclosure constraints. The instrument reiterates legal limits on further disclosure and use of the report, including that the information must not be disclosed to a State body without a State or Territory Minister’s consent (s 7(4) note, referencing s 11 of the Act). These constraints could shape enforcement priorities and authorised recipients of reports.

Cross-references relevant to enforcement. The instrument cites the Act’s paragraphs that the rules operationalise. For example, the turnover threshold is set “for the purposes of paragraph 26(3)(b) of the Act” (s 6(1)), and the content requirements are prescribed “for the purposes of subsection 27(2) of the Act” (s 7(1)). Enforcement of the reporting duty, including any remedies, penalties or injunctions for breach, remains governed by the Act’s Part 3 provisions.

Practical enforcement considerations for regulated entities

Documentation of decision-making. Because the instrument permits reliance on what is known or discoverable by reasonable search or enquiry within 72 hours (s 7(1) note), enforcement or remedial action by authorities will likely examine whether the entity undertook a reasonable search and how it determined what to include. Entities should therefore document the searches and enquiries made, time stamps, and the basis for any omission.

Potential follow-up reporting or investigations. The instrument contemplates that reports could include information “that could assist” incident response by Commonwealth or State bodies (s 7(4)(g)). That suggests reports may trigger follow-up inquiries, audits or requests for further information by authorised agencies under the Act. Enforcement mechanisms in the Act may therefore be exercised after initial reporting if authorities are unsatisfied or need more detail.

No new criminality or civil penalty in these rules. The rules themselves do not create criminal or civil offences, nor do they set pecuniary penalty levels. Those matters are reserved to the underlying Act. Entities must consult the Cyber Security Act 2024 for the exact enforcement regime and penalties that apply for breaches of the reporting obligation.

The instrument explicitly situates itself within a small matrix of existing Commonwealth enactments and statutes by reference. The rules do not stand alone; they operationalise specified provisions of the Cyber Security Act 2024 and reference the Security of Critical Infrastructure Act 2018.

Primary interaction with the Cyber Security Act 2024. The instrument is made under the Cyber Security Act 2024 (s 3), and the reporting duty it implements is contained in Part 3 of that Act (s 5). The content requirements are prescribed for the purposes of subsection 27(2) of the Act (s 7(1)). The turnover threshold is prescribed for the purposes of paragraph 26(3)(b) of the Act (s 6(1)). Several notes in the instrument reiterate statutory constraints in the Act, for example limits on disclosure to State bodies referencing s 11 of the Act (s 7(4) note). Consequently, the rules are tightly bound to the Act and operate as subordinate legislative detail for the Act’s Part 3.

Linkage to the Security of Critical Infrastructure Act 2018. The instrument identifies a class of entities that will generally be reporting business entities by reference to responsible entities for critical infrastructure assets to which Part 2B of the Security of Critical Infrastructure Act 2018 applies (s 5). That draws critical infrastructure regulatory status into the definition of reporting entities. The instrument therefore creates an intersection where entities subject to obligations under the SOCI Act’s Part 2B will also be subject to the ransomware payment reporting duties under the Cyber Security Act 2024 and these rules.

ABN and business identification. The instrument requires inclusion of the reporting entity’s ABN if any, and the other entity’s ABN if any, in the ransomware payment report (s 7(2)-(3)). That connects the reporting process to the Australian Business Register framework and means ABNs, where held, must be used to identify parties in reports.

Interplay with State/Territory powers. The instrument reiterates that the information in reports must not be disclosed to a State body unless a State or Territory Minister has consented (s 7(4) note, referencing s 11 of the Act). That clause affects intergovernmental information sharing and preserves a ministerial gate for releasing reports to State actors. The rules therefore modulate Commonwealth‑to‑State sharing consistent with the Act.

No explicit conflict or exclusion clauses. The instrument does not include express saving clauses or specify how these rules interact with other Commonwealth confidentiality, privacy, or intelligence statutes. The only explicit downstream disclosure limitation in the rules is the State consent requirement and the permitted purposes limitation noted in s 7(4). Any interaction with privacy laws, telecommunications interception or intelligence collection statutes is therefore a matter for the Act or other statutes, not these rules.

Operational interaction with incident response protocols. The rules require reporting of information that could “assist the response to, mitigation or resolution” of an incident by a Commonwealth or State body (s 7(4)(g)). This creates a practical linkage between the report data fields and existing or future incident response activities performed by authorised Commonwealth agencies under other legal frameworks or policies.

Original instrument and commencement. The instrument records that it is made by the Minister for Home Affairs, Tony Burke, and is dated 27 February 2025. The commencement provision uses a table specifying that the whole instrument commences at the later of registration and the commencement of Part 3 of the Cyber Security Act 2024 (commencement table, s 2). The instrument includes a note that the commencement table relates only to the provisions as originally made and will not be amended in the instrument to reflect later amendments (s 2(2)).

No amendments recorded within the text. The instrument contains no amendment entries, amendment dates, or history of changes within the body of the instrument provided. The “Note” in s 2(2) identifies that additional editorial information may be inserted in published versions, but that such insertion does not form part of the instrument. There are therefore no internal signs of later modifications or replacement provisions in the supplied text.

Mechanics for future amendment implicit. The rules are subordinate to the Cyber Security Act 2024, and as such any formal amendment process for the rules would be governed by the Act and the legislative instruments framework. The instrument itself does not set an expiry, sunsetting provision, or automatic review clause.

Provisionality relative to Act commencement. Because the instrument’s operation is linked to the commencement of Part 3 of the Cyber Security Act 2024 (s 2), any changes to the Act’s commencement timetable, or to the Act’s content, could affect the operative date or administrative context in which these rules apply. The instrument’s commencement mechanics therefore make its real world effect conditional on the Act’s timeline.

Record of original provisions. The instrument contains a short list of rules , definitions, turnover threshold, and content requirements , and includes the embedded prorating formula graphic for partial-year turnover calculations (s 6(2)). Those provisions represent the instrument as originally made and form the baseline for any future amendments.

No retrospective amendments indicated. The instrument includes a standard note that the commencement table relates only to provisions as originally made and will not be amended in the instrument itself to reflect later amendments (s 2(2)). That does not, however, preclude amendment by later legislative instruments or ministerial rules made under the Act. The supplied text does not contain any retrospective operation clause.

The instrument text supplied contains no litigation history, case citations, or references to judicial interpretation. It is a newly made instrument dated 27 February 2025, and the text does not record any legal challenges, interlocutory proceedings, or judicial consideration.

Implication for practitioners. Because there is no litigation history in the instrument, there is no judicial construction available to clarify ambiguous phrases in these rules, such as what constitutes “reasonable search or enquiry” within the 72 hour reporting period, or how the Act interacts with State consent in practice (s 7(1) note and s 7(4) note referencing s 11 of the Act). Practitioners will therefore need to rely on the plain language of the instrument and the Cyber Security Act 2024 until (and if) a court provides authoritative interpretation.

Anticipate scope for interpretive disputes. Several provisions leave room for factual adjudication. Examples include whether an entity “is aware that another entity has provided on their behalf a ransomware payment” (s 5), what information “could assist” Commonwealth or State incident response (s 7(4)(g)), and the measurement of turnover for entities operating part of a financial year (s 6(2)). Those questions are fact sensitive and could be the subject of future litigation or administrative review, but the instrument itself records no such history.

No administrative determinations recorded. The instrument does not include examples, guidance, or determinations by an administrative agency illustrating how it will be applied. All operational guidance would therefore be prospective, and any binding interpretations would ultimately come from the Act’s administrators or, absent that, tribunals or courts.

This section flags concrete traps and practical friction points explicitly created by the instrument’s wording and structure, with citations.

72 hour reporting window and reasonable search carve-out. The instrument ties required content to what the reporting business entity knows, or can find by reasonable search or enquiry, within the 72 hour period for giving the report (s 7(1) note). Gotcha: the instrument does not define “reasonable search or enquiry”, so the onus is on the entity to justify what it did within 72 hours. Failure to document searches, timelines, and enquiries will expose the entity to questions about compliance credibility.

Awareness of third‑party payments triggers obligation. The reporting obligation is triggered not only when the entity itself supplies the payment, but also when the entity “is aware that another entity has provided on their behalf, a ransomware payment” (s 5). Gotcha: entities that outsource incident response or engage third‑party negotiators need to track whether a third party made a payment, because mere awareness of such a payment triggers reporting duties. That extends the compliance perimeter to contract counter‑parties and service providers where knowledge is shared.

ABN and address requirement. The rules require the reporting business entity’s ABN if any and address, and the other entity’s ABN if any and address (s 7(2)-(3)). Gotcha: where the extorting entity is anonymous or uses intermediaries, the reporting entity may not have an ABN for that party, but must still provide anything it does know. Conversely, where payments were made via crypto or intermediated services, the practical ability to identify the receiving party and the ABN may be limited; entities must therefore explicitly document attempts to identify that information within 72 hours.

Detailed technical fields within short period. The instrument requires reporting of exploited vulnerabilities and malware variants (s 7(4)(e)-(f)). Gotcha: forensic confirmation of exploited vulnerabilities and malware variants often takes longer than 72 hours. The reasonable search caveat in s 7(1) mitigates this, but entities must be careful to document the basis of any preliminary forensic statements and to retain evidence for subsequent follow-up.

Reportable communications and negotiation summaries. The rules require brief descriptions of communications and any pre‑payment negotiations with the extorting entity (s 7(7)). Gotcha: negotiation records may contain privileged legal communications or sensitive crisis management strategy. The instrument does not provide privilege protections; the report will be furnished to Commonwealth bodies and may be disclosed for permitted purposes. Entities should therefore coordinate with legal counsel about what to include in early reports and preserve full privileged records separately.

Method of provision fields for demand and payment. The rules require the method of provision for both the demanded payment and the payment made (s 7(5)(b) and s 7(6)(b)). Gotcha: extorting entities commonly demand cryptocurrencies, third‑party transfers, or non‑monetary benefits. Reporting entities must be prepared to state these methods quickly. Where the method was through a third party or an opaque channel, the reporting entity should record the level of certainty it has when providing the method.

Interplay with State consent for disclosure. The rules note that information must not be disclosed to a State body unless a State or Territory Minister has consented (s 7(4) note referencing s 11 of the Act). Gotcha: where an incident affects State-level services or customers, the need for ministerial consent to share report details with State agencies may delay coordinated responses. Entities should be aware that Commonwealth agencies may have legal constraints in sharing information with State actors.

Turnover threshold calculation. The turnover threshold is $3 million for the previous financial year (s 6(1)). If the business was carried on for only part of that year, the threshold is prorated by days (s 6(2)). Gotcha: businesses that started or ceased trading within the last financial year must calculate the prorated threshold using a specific day-count formula embedded in the instrument. Incorrect calculation may lead to misclassification as in or out of scope.

No template, no transmission channel specified. The rules prescribe content but do not set a form, template, or method of submission in the text supplied. Gotcha: expect administrative guidance from the responsible agency to specify how to file reports; in the absence of that guidance, choose a secure channel and retain proof of submission. Entities should monitor agency communications for a mandated portal, form, or encryption standards.

No penalty detail in the rules. The instrument does not set penalties or enforcement mechanisms (see Penalties and enforcement). Gotcha: compliance costs and risks are driven by the Act. Entities should review the Cyber Security Act 2024 to understand sanctions and any notification obligations beyond the initial 72 hour report.

This section translates the instrument’s text into a practical compliance checklist and evidentiary habits. All items are rooted in the rules’ provisions.

Immediate incident triage and 72 hour plan. The instrument ties required report content to a 72 hour reporting period in the Act and clarifies that information is required only to the extent it is known or discoverable by reasonable search or enquiry within that window (s 7(1) note). Compliance action: create an incident triage workflow that allocates responsibilities for a rapid reasonable search and enquiry, with timestamps. The workflow should identify personnel authorised to assemble the initial report, to liaise with forensic teams, and to coordinate legal counsel.

Document searches and enquiries. Because what is required turns on what is known or can be found by reasonable search or enquiry within 72 hours (s 7(1) note), maintain a contemporaneous log of searches, enquiries, vendors contacted, forensic tasks initiated, and results. Record search scopes and limiting assumptions so that any subsequent administrative review can evaluate whether the entity acted reasonably.

Collect and preserve the minimum required fields. The rules list discrete data fields (s 7(2)-(7)). Ensure you can produce, within 72 hours:

• Reporting entity contact and business details including ABN if any and address (s 7(2)).
• Other entity contact and business details including ABN if any and address, if known (s 7(3)).
• When the incident occurred or is estimated to have occurred, and when you became aware (s 7(4)(a)-(b)).
• Impact on your infrastructure and customers (s 7(4)(c)-(d)).
• Variants of ransomware or other malware used and vulnerabilities exploited, where known (s 7(4)(e)-(f)).
• Any information that could assist Commonwealth or State response (s 7(4)(g)).
• Amount or description and method of the demand (s 7(5)).
• Amount or description and method of the ransomware payment made (s 7(6)).
• Nature, timing and brief descriptions of communications with the extorting entity and brief summaries of any pre‑payment negotiations (s 7(7)).

Coordinate legal privilege and disclosure strategy. Because the initial report must include brief descriptions of communications and negotiation summaries (s 7(7)), coordinate with legal counsel to identify where privilege, confidentiality, or law enforcement sensitivities require protective approaches. Document any decisions to omit privileged material, and record the basis for that omission.

Identify and monitor third‑party service providers. The reporting duty is triggered by awareness that another entity has provided a ransomware payment on your behalf (s 5). Ensure contracts with incident response firms, negotiators, insurers, and payment intermediaries include clauses requiring prompt notice to the principal and cooperation with reporting obligations. Build a notification cascade so that third-party payments are reported immediately to the reporting business entity.

Prepare a template checklist aligned to s 7. Although the instrument does not supply a template, prepare an internal form that maps directly to s 7(2)-(7). Use the form for initial reports and to capture updates. The form should include fields for documenting the scope of the reasonable search or enquiry performed.

Establish forensic timelines and provisional statements. Because technical findings about exploited vulnerabilities and malware variants may lag beyond 72 hours, prepare provisional technical statements qualified by the limits of the initial forensic effort, and commit to supplying updates if required under the Act. Ensure forensic vendors understand the tight timing so they can prioritise preliminary triage tasks useful for the 72 hour report.

Secure reporting and retention. Preserve full incident records, communications logs, forensic outputs, and payment records in secure storage. The instrument emphasises that the information may be used for permitted purposes including incident response (s 7(4) note). Retain full documentation even where only brief descriptions are included in the 72 hour report.

Plan for intergovernmental information sharing constraints. If State-level agencies will need access to incident information, plan for potential delays because disclosure to a State body requires a State or Territory Minister’s consent (s 7(4) note referencing s 11 of the Act). Maintain a point of contact for Commonwealth agencies and coordinate with State counterparts to facilitate any ministerial consent processes where that will be necessary.

Train incident response and corporate teams. Provide training to IT, security, legal, compliance, and executive teams on the specific content required by s 7, the 72 hour timeframe, and documentation standards for reasonable search or enquiry. Include exercises that rehearse assembling the required fields under time pressure.

Recalculate turnover classification annually and when starting or stopping business activity. The $3 million threshold applies to the previous financial year, with a pro rata formula for partial-year activity (s 6(1)-(2)). Ensure finance and legal teams calculate whether the business was carrying on a business for the whole or part of the previous financial year and apply the prorating formula where needed. Where corporate structures change, verify which entity is the “reporting business entity” under the Act.

Monitor agency guidance and templates. The instrument does not prescribe a submission channel. Expect an authorised Commonwealth agency to publish a portal, template or secure transmission standard. Monitor official communications after the instrument’s commencement date, and align internal templates to any official form when published.

Review insurance, contracts and payment policies. Because the instrument reaches payments made by third parties on a covered entity’s behalf (s 5), review insurance policies, incident response agreements, and third-party contractual terms to ensure clarity on who notifies whom and how payments will be reported.

Plan for post‑report follow up. The rules create a likely expectation of further interaction with Commonwealth agencies since reports may contain information that could assist incident response (s 7(4)(g)). Establish a workflow to respond promptly to follow-up agency requests, supply additional materials, and manage any regulatory or enforcement processes arising from the initial report.

Document governance decisions about the reporting obligation. Because several terms are fact dependent and discretionary (for example what constitutes “reasonable search or enquiry” and what information “could assist”), record governance decisions, delegated authorities and escalation criteria so that any external review of compliance can be assessed against documented internal policies and contemporaneous actions.