What To Do If You’ve Had a Data Breach?

There are two ways to go wrong in the first 24 hours of a data breach.

One is freezing, where nobody wants to be the person who says the wrong thing, so nothing gets said and nothing gets fixed, and the gap between finding out and actually doing something ends up becoming a bigger story than the breach itself.

The other is overcorrecting in the opposite direction, notifying everyone immediately because it feels like the responsible thing to do, before you actually know what happened. It isn’t responsible, though can feel that way in the moment.

Telling people the wrong thing, or telling them before you’ve closed the hole that caused the problem, tends to make things worse rather than better.

There’s a right order to work through, and it’s better to know this before you’re in the middle of a breach trying to figure it out under pressure.

Step 1: Contain, then assess

Before anything else gets written or sent, stop the bleeding.

If it’s a spreadsheet that’s still sitting public, restrict it. In some businesses, IT will need be called in to disable compromised accounts, or block an active intrusion. Whatever form it takes, the first goal is containment. Notifications about a problem that’s still actively unfolding don’t help anyone.

Once the exposure itself is dealt with, you can move on to working out exactly what happened. And once you’ve got that picture, you’ll move onto what you’re now required to do about it.

Step 2: Are you covered by the NDB scheme?

Australia’s Notifiable Data Breaches scheme sits under the Privacy Act, and you should work out if it applies to you rather than assuming either way. It applies to APP (Australian Privacy Principles) entities, which covers Australian Government agencies along with private sector and not-for-profit organisations with an annual turnover of more than $3 million, so the first question is simply knowing if you fall inside that definition.

If you’re under the threshold, it’s still worth reading on, because certain obligations apply regardless of size, particularly where you’re holding specific categories of information like tax file numbers. Plenty of smaller businesses also choose to follow the same standard voluntarily on the basis that going quiet after a breach and hoping nobody notices tends to cost more in trust than the notification itself would have.

Step 3: What actually counts as notifiable

Not every incident triggers the scheme, which is where a lot of the anxiety around this turns out to be misplaced. An eligible data breach requires unauthorised access to or disclosure of personal information that’s likely to result in serious harm to the people it relates to, and where the business hasn’t already been able to prevent that harm through remedial action.

That last part matters more than most people expect; if you catch something quickly and fix it before any real harm becomes likely, that changes the picture considerably, which is exactly why containing the problem in Step 1 comes before working out your obligations in Step 2. A breach that’s been contained quickly and one that’s still wide open aren’t the same conversation, even if they started out looking the same.

What does this look like in practice?

A spreadsheet is sent to an external address and the business can’t recover or delete it. If the information could be used for identity theft, fraud, or other significant harm, and there is no way to reduce that risk, the breach is much more likely to be considered an eligible data breach that must be assessed and potentially notified.

Another common example is a lost device. A phone or laptop containing personal information that is protected by strong encryption may present a very different level of risk from an unencrypted device containing the same data. If the information remains inaccessible to unauthorised people, serious harm may be unlikely. If it can be accessed, the organisation may have notification obligations.

Step 4: The 30 day deadline people get wrong

This is the most common misunderstanding that causes problems:

Businesses have 30 days to assess whether a data breach is likely to result in serious harm - not 30 days to decide whether to tell anyone about it.

Treating those as the same thing tends to push organisations in one of two unhelpful directions. Some panic and start talking about notification before they’ve properly established what happened. Others assume they have a month to sit on the issue before taking any action at all.

Both are wrong.

The 30-day period exists to allow a reasonable and expeditious assessment of the incident. It is a window for working out what you’re dealing with, not a grace period before you have to act. If that assessment confirms an eligible data breach, notification must then occur as soon as possible.

This isn’t just a technical distinction. In October 2025, the Federal Court ordered Australian Clinical Labs to pay $5.8 million in penalties, the first civil penalty imposed under the Privacy Act in relation to a data breach. A significant portion of that penalty related to failures around timing, including missing the 30-day assessment requirement and not notifying affected individuals and the regulator as soon as possible once the breach had been confirmed. The timing obligations are not administrative formalities; they are independently enforceable legal requirements.

There is a cruel irony here. Australian Clinical Labs is commonly abbreviated to ACL — the same acronym used for Access Control Lists, a security mechanism specifically designed for controlling access to information.

Step 5: Who you tell, and how

Once you’ve determined a breach is notifiable, both the affected individuals and the OAIC need to be told, and the notification itself can go out by email, text message, or phone call. It needs to cover four things specifically: your organisation’s identity and contact details, a description of what actually happened, the kind of information involved, not the specific data itself, and clear recommendations about what people should do in response. A vague “something happened, sorry” doesn’t meet the requirement.

If you can’t reach everyone directly, there’s a fallback; you’re required to publish the notification on your website and actively promote it through channels like social media, news, or advertising. This rules out the option of deciding some people just won’t hear about it. Not being able to reach everyone means going louder about it, not quieter.

Step 6: The insurance fine print

If you’re carrying IT liability or professional indemnity cover, it’s very likely written on a claims-made basis, which generally means you’re required to notify your insurer as soon as reasonably possible once you become aware of circumstances that could give rise to a claim, rather than waiting until an actual claim lands on your desk. A breach you’re still investigating, one you merely suspect might eventually cause someone a loss, can already count as a circumstance you’re obliged to notify, and waiting to see how bad things get before telling your insurer is exactly the kind of delay that gives them grounds to reduce or refuse cover later, even on a breach that would otherwise have been covered without issue.

It’s also worth checking that a standard professional indemnity policy doesn’t automatically come with cyber cover attached, since some exclude it outright. Read the policy properly, or better, call your broker before you need to rather than in the middle of dealing with all this.

This isn’t legal advice, and it shouldn’t be treated as such

Everything above sketches the general shape of the obligations rather than advice on your specific situation, so it’s worth reading the OAIC’s own guidance on assessing and responding to breaches. Your broker or insurer can tell you exactly what your policy requires and by when.

• How to Avoid a Data Breach Without Hiring a Security Team
• How Do You Know If You’ve Had a Data Breach?

The pattern across all of these cases is surprisingly simple: security works best when it’s boring. The businesses that fare best are usually the ones that make secure data handling the default, not the exception. Because the easiest breach to manage is the one that never happens in the first place.