AI Can Sort the Breach Queue. It Cannot Stop the 30-Day Clock.

AI can assemble evidence, connect similar incidents and challenge a preliminary assessment. It cannot decide when your licensee knew enough, whether a breach is significant or whether a report is due. Build the workflow around the clock, not the model.

The dangerous AI error in breach reporting is not always a false answer. It is a tidy summary that makes the team treat the date compliance opened the file as the date the clock started.

For Australian financial services and credit licensees, the ordinary period is 30 days after the licensee first knows that, or is reckless with respect to whether, there are reasonable grounds to believe a reportable situation has arisen. That rule sits in section 912DAA of the Corporations Act 2001 and section 50B of the National Consumer Credit Protection Act 2009. It is not a 30-day period that begins when a breach committee reaches a final view.

This is the licensee reporting clock under the ASIC reportable situations regime. It is not the separate 30-day assessment window for eligible data breaches under the Privacy Act; that clock, and what a vendor incident does to it, is covered in an AI vendor breach starts your clock.

ASIC has already identified the operational weakness. In its December 2024 review of 14 licensees, 31 per cent of reported breaches took more than one year to identify, while the average time from the first occurrence to reporting was 534 days. ASIC traced much of the delay to weak incident identification, escalation and recording, not to the final portal submission (ASIC, 4 December 2024). AI should shorten that journey. It must not obscure the legal judgement within it.

What actually starts the 30-day clock?

Start with two different time controls. The first is the notification period. RG 78.83 explains the 30-day rule and ties it to knowledge or recklessness about reasonable grounds, not completion of an investigation. RG 78 also explains that whether reasonable grounds exist is objective.

The second control concerns an investigation into whether there is a significant breach or likely breach of a core obligation. The current Corporations Act and National Credit Act still print a 30-day threshold for that category, but section 6A of the in-force ASIC Corporations and Credit (Breach Reporting - Reportable Situations) Instrument 2024/620 modifies both regimes by substituting 60 days. The amendment commenced on 27 June 2025, when ASIC published its relief update.

There is a source trap in the February 2026 RG 78 PDF. Figure 1, the Example 11 heading and Table 8 retain old 30-day investigation references. For the current position, use section 6A of the instrument and RG 78.26, RG 78.48 to RG 78.49 and RG 78.102 to RG 78.106, which apply the 60-day threshold.

That 60-day threshold is not a new general reporting period. If facts establish reasonable grounds for a reportable situation before day 60, RG 78.106 says the licensee must not wait for the investigation to finish. Conversely, an investigation that passes 60 days can itself become reportable even before the underlying question is resolved. Its eventual outcome may also need to be reported.

The attribution issue is equally important. RG 78.92 to RG 78.96 explains that knowledge acquired by an employee or agent within the scope of actual or apparent authority can be attributed to the licensee. A workflow cannot hold every possible issue outside the breach function and assume the clock is dormant. Your triage record should therefore capture the earliest plausible trigger date and the evidence for it, not merely the date of formal escalation.

There is limited 90-day relief for a further reportable situation whose underlying circumstances are the same as, or substantially similar to, a previously reported situation. Section 7 of ASIC Instrument 2024/620 sets the conditions. RG 78.110 to RG 78.113 says professional judgement is still required when deciding whether matters are similar and whether they can be grouped. An AI-generated cluster is an investigative lead, not the legal conclusion that the relief applies.

Where should AI sit in breach triage?

Put AI in the evidence lane. Keep people in the decision lane.

In the evidence lane, an approved AI tool, or equivalent, can structure de-identified incident reports, complaints, quality-assurance findings and remediation records. It can extract dates, identify contradictions, surface apparently similar events and show which source supports each statement. Those tasks help a reviewer see the file sooner, and they pair naturally with the evidence-preservation discipline in the AI incident response evidence pack.

In the decision lane, a named breach specialist and the authorised governance path determine the relevant core obligation, significance, knowledge or recklessness, establish from the evidence when an investigation began, decide whether grouping is available and decide whether a report should be lodged. The model should never be authorised to close an incident, assign a final non-reportable status or calculate the official clock start without human approval.

Use this prompt to build a source-linked chronology from approved, de-identified records. A human breach specialist must check every source reference and determine its legal significance before the output is used.

You are assisting with evidence assembly for incident [INCIDENT_ID]. Do not decide whether a breach or reportable situation exists.

Using only the supplied de-identified records, return a table with:
1. event or assertion
2. exact date and time stated
3. source document and page or record ID
4. people or functions that received the information, using role labels only
5. confidence: explicit, inferred or unknown
6. contradictions or missing evidence

List the earliest facts that could require a human reviewer to assess knowledge, recklessness, significance or the start of an investigation. Write UNKNOWN where the records do not answer the question. Do not fill gaps.

Design the output so confidence cannot masquerade as authority. "Explicit", "inferred" and "unknown" are useful evidence labels. "Reportable" and "not reportable" are reserved human decisions.

What belongs in a clock-first triage record?

ASIC says a breach register is not expressly required by the Corporations Act or National Credit Act. It nevertheless considers one practically necessary and says it should contain the information in the prescribed form (RG 78.144 to RG 78.146). That gives you a sound base, but an AI-assisted process needs a stronger timing layer.

Use this checklist for each issue:

• Record the occurrence window, detection date and every material escalation timestamp.
• Record the earliest plausible knowledge or recklessness date, the supporting evidence and the role that held it.
• Record the trigger date adopted in the human legal assessment, the due date, decision maker and reasons. Approval records the conclusion. It cannot alter when the statutory period began. Preserve any earlier alternative date considered.
• Record the objective investigation start, the Day 61 date on which an in-scope prolonged investigation becomes reportable, and the lodgement due date for that reportable situation.
• Map candidate obligations, significance factors, affected products, consumer impact and remediation without allowing the model to resolve them.
• Search for similar incidents using nature, provision, root cause, controls and client impact, the factors ASIC identifies in RG 78.160.
• Link every conclusion to native evidence and retain model input, output, version and reviewer changes as supporting working papers.

The fresh control is the clock divergence field. It displays the difference between the earliest plausible trigger date found in the evidence and the trigger date recorded in the human legal assessment. It does not second-guess the assessment or change the statutory test. It forces an unresolved timing gap into view before the file is closed or reported.

Fictional worked example: At [LICENSEE_NAME], a complaint tagged to [INCIDENT_ID] is recorded on [DATE_1] as an isolated fee error. A later quality review begins on [DATE_2]. An approved AI-assisted search then groups 17 de-identified records with the same apparent system rule and surfaces an email sent to [ROLE_TITLE] on [DATE_3].

The model may assemble that chronology and identify the apparent pattern. It cannot decide that [DATE_2], [DATE_3] or the later clustering date started the reporting period. A human reviewer must examine what information was available on each date, whose knowledge may be attributed to the licensee, whether reasonable grounds existed, whether the breach was significant or deemed significant, and whether the matters truly share underlying circumstances.

Use this prompt to challenge a preliminary human assessment. The accountable human reviewer must resolve each challenge and retain the final reasoning.

Red-team the preliminary breach assessment for [INCIDENT_ID]. Do not make the final legal or reporting decision.

Using the verified chronology and the human draft assessment, identify:
1. evidence supporting an earlier knowledge or recklessness date
2. facts that could change the significance assessment
3. similar incidents or systemic indicators that may have been missed
4. reasons the proposed grouping may be too broad or too narrow
5. open facts that could change the 30-day reporting date, Day 61 reportable-situation date or associated lodgement date

For every challenge, cite the supplied record ID. If there is no evidence, say so.

Do this Monday

1. Add the clock fields. Put the earliest plausible trigger, assessed trigger date, reporting due date, objective investigation start, Day 61 reportable-situation date and associated lodgement due date into the existing incident record.
2. Select a controlled pilot. Test the extraction workflow on closed, de-identified cases. Do not let the model change statuses or send reports.
3. Separate permissions. Allow the assistant to read approved evidence and draft working papers. Reserve closure, reportability, grouping and portal submission for authorised people.
4. Test attribution. Take recent incidents and ask whether information sat with complaints, operations, audit or a representative before it reached compliance. Document how those facts were considered.
5. Install challenge, not concurrence. Use AI to test the human view for an earlier trigger, missed similar matters and incomplete evidence. Require the human reviewer to accept or reject each point.
6. Set a failure rule. Suspend AI assistance if source citations cannot be reproduced, protected data appears outside the approved environment or reviewers begin copying conclusions without checking the evidence.

Bottom line

AI can make a breach queue faster and more searchable. It cannot determine the legal state of mind attributed to a licensee, make the objective significance assessment or authorise a report. Build a clock-first record that exposes timing uncertainty and keeps every decisive judgement with an accountable person. The control objective is not faster classification at any cost. It is earlier, better-evidenced human judgement while the statutory time remains available.

This article is general information and education only. It is not legal, compliance, financial or professional advice. Obligations vary by organisation and circumstance. Verify current requirements against the primary sources cited and seek advice specific to your situation.

References

1. Australian Securities and Investments Commission, Regulatory Guide 78: Breach reporting by AFS licensees and credit licensees, issued 19 December 2023, updated February 2026. https://download.asic.gov.au/media/2wxlpkr0/rg78-published-19-december-2023-20260216.pdf
2. Federal Register of Legislation, Corporations Act 2001, compilation C2026C00339, 1 July 2026. https://www.legislation.gov.au/C2004A00818/latest
3. Federal Register of Legislation, National Consumer Credit Protection Act 2009, compilation C2026C00340, 1 July 2026. https://www.legislation.gov.au/C2009A00134/latest
4. Federal Register of Legislation, ASIC Corporations and Credit (Breach Reporting - Reportable Situations) Instrument 2024/620, compilation F2025C00891, 12 September 2025. https://www.legislation.gov.au/F2024L01202/latest
5. Australian Securities and Investments Commission, ASIC gives further relief for licensees under the reportable situations regime, 27 June 2025. https://www.asic.gov.au/about-asic/news-centre/news-items/asic-gives-further-relief-for-licensees-under-the-reportable-situations-regime/
6. Australian Securities and Investments Commission, Reportable situations: Findings of ASIC's review and how licensees can improve compliance with the regime, 4 December 2024. https://www.asic.gov.au/about-asic/news-centre/news-items/reportable-situations-findings-of-asic-s-review-and-how-licensees-can-improve-compliance-with-the-regime/