How Do You Know If You’ve Had a Data Breach?

Think about the last spreadsheet you shared with someone outside your team. Maybe it’s still sitting in OneDrive. Maybe it contains customer email addresses, survey responses, or other bits of personal information from a project everyone has moved on from.

Now imagine that spreadsheet has been accessible for eight months through an “anyone with the link” share setting. How would you know?

For most businesses, there isn’t a warning. Nothing breaks. No notification arrives saying, “This file containing personal information has been publicly accessible since March.” Unless you’re running enterprise-grade data protection controls (and most businesses aren’t) the file just sits there. And if nobody happens to stumble across it, you may never realise it was exposed in the first place.

That’s the thing with data breaches; dealing with one usually isn’t the hardest part. Finding out it happened in the first place is.

Most businesses don’t find their own breach

Most of the signals below could be caught inside your own systems, in your own logs, by your own team. In practice they usually aren’t, because nobody’s actively watching until something forces the issue. So the business ends up finding out from a customer, a bank, a security researcher, or a journalist, often weeks or months after the fact, not because the evidence wasn’t there, but because nobody was looking at it. The gap between the door opening and someone noticing is where a lot of the damage happens.

There are a few places the signal usually comes from, going from bad to worse:

Unusual account or admin activity. Logins from places or times that don’t match normal patterns, a spike in failed login attempts, an admin account doing something nobody on your team remembers doing. These are the signals sitting in your own systems, if anyone’s checking. Most small and mid-sized businesses don’t have anyone checking, which is exactly why this so often gets discovered after the fact, from an audit or a developer poking around for an unrelated reason, rather than in the moment.

A researcher tells you there’s a hole. Someone found a vulnerability, a misconfigured setting, an exposed endpoint, and they’re telling you before it gets exploited, if it hasn’t already. This is a warning, not a confirmation. You still have time to act on it, and whether anything’s actually been taken is exactly what you need to find out next.

Your payment processor or bank flags something. Unusual chargeback patterns, a spike in disputed transactions, a fraud alert tied to your customer base specifically rather than the general noise every business sees. Worth taking seriously rather than assuming it’s unrelated.

A customer tells you something’s wrong. They’re getting phishing emails that reference real details, an order number, a purchase they actually made, information that shouldn’t be guessable.

A criminal tells you they already have your data. This message only exists as leverage: pay to keep it off the market. There’s no ambiguity here. If someone’s telling you they have your data, the exfiltration has already happened, and you’re straight into containment and assessment, not prevention.

None of these arrive with a sign saying “this is a data breach.” They arrive as one odd thing, and the question is what you do with it.

The trap: reacting before you know what happened

This is the part worth slowing down for, because the instinct under pressure is almost always wrong.

One customer complains about a suspicious email. One weird login shows up in the logs. It’s tempting to jump straight to a conclusion, either panicking and telling everyone there’s been a breach, or deciding it’s nothing and moving on, based on a single data point.

The better move, every time, is the same you’d want from anyone diagnosing a serious technical problem: get the full picture before you decide what it means. One log line doesn’t tell you a story. A pattern does. Is this one customer or a hundred? Did the unusual login actually gain access, or was it a failed attempt? Is this new, or has it been happening quietly for months and you’re only noticing it now? You don’t get useful answers from the first signal, you need to pull the data and look for the pattern, not by reasoning forward from the first thing that looked out of place.

Jumping to a fix, or a public statement, based on one alarming report almost always means fixing or announcing the wrong thing.

What Happens During an Assessment?

Once something’s flagged, three questions matter more than any others:

1. Containment. Is the hole still open? If it’s the spreadsheet, is it still shared publicly? Fixing the exposure comes before anything else, including telling anyone what happened, because there’s no point notifying people about a door that’s still swinging open.
2. Scope. What data is actually involved, and how many people does it touch? A breach affecting twelve people is a very different problem to one affecting twelve thousand, and you won’t know which you’re dealing with until you look properly.
3. Timeline. When did this start, and is it still happening right now? A closed incident from three months ago and an open one happening right now call for completely different urgency.

When to bring someone in

If you’ve got IT support, a developer or an agency who knows your systems, this is the moment to loop them in, not after you’ve already decided what happened. They can tell you things you can’t see yourself: what logs actually exist, what they show, whether “unusual” is actually unusual or just unfamiliar. If you don’t have anyone in that seat, that’s worth sorting out before you need them, not while you’re in the middle of an incident.

Once you’ve actually got the picture, and only then, you’re not in “what happened” territory anymore. You’re in “what am I required to do about it” territory, and in Australia that comes with a countdown attached: What To Do If You’ve Had a Data Breach?