Five ways a practice can tip off without anyone saying a word

Here is something almost nobody knows.

When a business suffers a data breach, it normally has to tell two parties: the Office of the Australian Information Commissioner, and the people whose information was exposed. The OAIC's guidance for businesses with obligations under the AML/CTF Act sets out an exception. The duty to notify, it says, "does not apply where that notification would be inconsistent with a secrecy provision".

Then it gives an example. "If providing a statement to the OAIC would not be inconsistent with a secrecy provision, but notifying the individual would be, the entity would only be required to notify the OAIC."

Read that twice. There are circumstances in which a practice must tell the regulator that a client's information has been exposed, and must not tell the client.

Why a system can break this rule with nobody saying a word

The rule is section 123 of the AML/CTF Act. Most people meet it for the first time buried in a compliance document.

Under the AML/CTF Act, a business providing certain services has to report to AUSTRAC when it forms a suspicion about a customer or a transaction. That report is called a suspicious matter report. Section 123 is the provision that stops the business letting the customer know one has been made. If the customer found out, they could move money, destroy records or simply leave, which is the reason the provision exists at all.

Until recently it worked roughly as anyone would expect. MinterEllison's Tony Coburn, Prayas Pradhan, Malcolm Shackell and Wesley Lalich described the earlier version as making it a criminal offence "to disclose information from which it could be inferred that a reporting entity has lodged a suspicious matter report with AUSTRAC concerning a person".

That version has gone. Since 31 March 2025, a year ahead of most of the rest of the amending legislation, section 123 prohibits disclosure "where this would or could reasonably be expected to prejudice an investigation".

The difference is easy to miss. The old wording is close to a rule about telling. The new wording is a test about consequence. It does not ask who said what, or whether anybody meant to say anything at all. It asks what the disclosure would be expected to do.

A person can produce that consequence by talking. So can an export, an invoice, a folder name or a calendar entry, and none of those has the faintest idea what it is disclosing.

Below are five ordinary parts of a practice where that happens, why each one happens on its own, and what your systems have to be able to do about it.

1. An access request

A client asks what personal information the practice holds about them. Australian Privacy Principle 12 gives them that right and the practice has to respond.

The OAIC's guidance is direct about the collision. "You must not provide access to personal information or explain why you are denying access if it would breach the tipping off offence in section 123 of the AML/CTF Act." And on the refusal notice itself: "your written notice must not explain why you have refused access."

Why it happens on its own. The disclosure is made by the export, not by a person. Whoever runs it is doing their job correctly, and the file that comes out contains whatever the system was able to find.

What your systems need to do. Produce everything held about a client except specified records, without the omission being visible in what is handed over.

2. A breach notification

Notification processes are usually built to be thorough, which means telling everyone affected. That is the right setting almost every time.

The exception is the one this guide opened on. Where notifying an individual would be inconsistent with a secrecy provision, the OAIC's guidance says the entity would only be required to notify the regulator.

Why it happens on its own. The notice goes out because the process is set to notify everyone on the list. Nobody chose to tell that particular person, and by the time anyone reads the list the message has usually gone.

What your systems need to do. Stop, and wait for a person to decide individual by individual, before anything is sent.

3. The matter or client file

Correspondence about a reportable matter has to be kept somewhere. If it goes into the client file, everybody with access to that file can read it, and in most practices that is more people than anyone would choose deliberately.

Folder and file names do the same work without anybody opening anything. A folder named after the regulator, sitting inside a client matter, tells the story to whoever glances at the directory.

Why it happens on its own. Access to that file was granted a long time ago, to a group, for good reasons. Nobody went back and reconsidered it on the day this particular record arrived.

What your systems need to do. Hold the record in restricted storage, with a defined list of who can open it, under a name that carries no information.

4. Time entries and invoices

This is the one least often mentioned, and it is the one most likely to reach the client directly.

Time is recorded with a narration, and the narration is generally what appears on the client's bill. A line reading attend to AUSTRAC reporting matter is a disclosure to the one person it must be kept from, delivered by the practice, on its own letterhead, at the end of the month.

Why it happens on its own. Billing is a production run. The narration was written for the file, not for the client, and nothing between the timesheet and the envelope reads it again.

What your systems need to do. Restrict the narration on the relevant entries, or hold it back from the bill, and put the bill in front of somebody before it leaves.

5. Calendars, tasks and client portals

A meeting in a shared diary carries a title. A task assigned in the practice system carries a description and the name of whoever it went to. A client portal synchronises whichever folders it has been told to synchronise.

None of these is thought of as communication. All of them display text to people, and a portal displays it to the client.

Why it happens on its own. A portal synchronises because synchronising is what it does. Nobody instructed it to share that folder this morning. Somebody set it up once, correctly, for a different purpose.

What your systems need to do. Scope access to the people who must see it, on every system rather than only the main one, and synchronise a folder to a portal only where somebody has decided it should be there.

What this is not

Nothing here is about whether a report should be made, or about what to do once one exists. Those questions belong to a practice and its own advisers, and for law firms they interact with legal professional privilege in ways no systems guide should go near. Anton Moiseienko, Associate Professor of Law at the Australian National University, has noted that "the obligation to file a suspicious matter report might conflict with legal professional privilege".

This is about one thing. The places information can surface without anybody choosing to disclose it.

Where this leaves a practice

All five resolve to the same question, and it is not a legal one. Can this practice restrict a specific record, from specific people, across every system it uses, and demonstrate that it did.

Most practices have never had cause to ask. The answer is not obvious from the inside, because the systems holding client information were configured for the opposite purpose. They were built so that colleagues could find things.

At efex we work on that layer: restricting particular records rather than whole files, scoping access across every system, and keeping the systems configured to keep people out, because a restriction only holds for as long as the system holding it does.

A reasonable place to start is knowing where you stand today.

Back to News and Resources

These articles explain what the regulators have published and what it commonly means in practice. General information only, not legal or compliance advice.