After Mercer: Why breach reporting is now a governance, systems and evidence problem

Mercer should not be treated as a superannuation-only story. ASIC’s action against Mercer Super alleged failures to report internal investigations into serious member service issues, including multiple unreported investigations and one reported more than a year late. The reported issues included deceased-member insurance premium refunds, default insurance allocation and member information updates; ASIC also alleged false or misleading information about affected member numbers.

For AFSL holders, responsible managers and authorised representatives, the sharper point is not the product vertical. It is the control question: can the business prove how an issue moved from incident, to investigation, to materiality assessment, to reportability decision, to ASIC lodgement or closure?

Breach reporting is no longer just a legal call

Breach reporting is now an evidence problem. ASIC’s RG 78 describes breach reporting as a cornerstone of the financial services regulatory structure because it lets ASIC detect significant non-compliance early and identify industry trends. It also makes clear that robust breach reporting systems are a critical part of a licensee’s compliance and risk management framework, and that failure to report may itself indicate inadequate compliance arrangements.

That matters because many breach-reporting failures do not start with a lawyer making the wrong call on section 912D. They start earlier: an incident is logged without enough detail, an operational team treats remediation as the whole answer, a compliance review has no clear owner, or a materiality assessment happens informally and is never evidenced. By the time legal is asked whether a report is required, the clock may already be running and the record may already be thin.

The timing risk is often misunderstood

Current RG 78 guidance states that investigations into whether a significant breach or likely significant breach of a core obligation has occurred become reportable if they continue for more than 60 days, with lodgement required within 30 days from day 61. Separately, where there are reasonable grounds to believe a reportable situation has arisen, the standard lodgement period is 30 days.

The distinction is important. A firm that only diarises “breach report due dates” may miss the earlier governance work required to determine when an investigation began, who owned it and what evidence supported the reportability conclusion.

The risk is heightened in fragmented control environments: licensees with multiple business lines, outsourced service providers, manual remediation processes, inherited books, decentralised adviser networks, CAR models or weak Line 1/Line 2 handoffs. RG 78 also expects robust arrangements for authorised representatives and credit representatives so possible breaches are identified, recorded and escalated.

What an ASIC-defensible model looks like

An ASIC-defensible breach-reporting model should do more than maintain a register. It should map the control pathway from the first detective control — complaint, audit issue, exception report, whistleblower disclosure, remediation project or regulator query — through to a documented decision.

At minimum, firms should be able to show:

• when the issue was first identified and by whom;

• when any investigation commenced as a matter of fact;

• the core obligation and potential client impact considered;

• who made the significance or reportability assessment;

• what legal or compliance advice was obtained;

• why the issue was reported, not reported, grouped or updated; and

• how the board, compliance committee or responsible managers were informed.

The board-reporting piece is not cosmetic. If the board only receives breach volumes and closure rates, it may not see the real risk: aged investigations, repeat root causes, delayed escalations, incomplete remediation data or unsupported “not reportable” decisions. A useful breach dashboard should show velocity, ageing, legal thresholds, customer impact, remediation status and repeat control failures.

ABML perspective

Breach reporting should be designed as an operating model, not a policy. A good policy tells staff what the law requires. A defensible operating model shows how the organisation actually detects, escalates, investigates, decides, reports and learns.

That means testing the breach register against live workflow, reviewing reportable-situations decision records, checking CAR and outsourced-provider escalation pathways, setting legal-review triggers for sensitive categories, and ensuring responsible managers have enough visibility to challenge delay or under-classification.

The closing lesson from Mercer is practical. If a licensee cannot evidence how an issue moved from incident to investigation to reportability decision, it does not just have an ASIC breach reporting systems problem. It has a governance problem.