All posts

May 7, 2026 · 4 min read

"Data Breach" and "Data Exposure" Aren't Interchangeable, and the Difference Matters to Customers

A founder asked me how to describe a security issue he'd just fixed, to his own team and eventually to customers: was it a "breach"? The word choice matters more than it might seem, and it's worth understanding the actual distinction before deciding how to talk about something that's gone wrong.

What each term actually implies

A data breach generally implies unauthorized access actually occurred, someone got in and took or viewed something they shouldn't have, whether through hacking, stolen credentials, or another active intrusion. A data exposure means something was reachable, discoverable, or improperly accessible, without necessarily any confirmed evidence that anyone besides the person who found and reported it actually accessed it. An exposed database found by a researcher who immediately reported it, with no other access logged, is a real exposure. Whether it's accurately called a breach depends on whether there's actual evidence someone else got in and took something.

Why conflating the two causes real problems

Calling something a "breach" when it was actually an exposure with no confirmed unauthorized access overstates what happened, potentially triggering unnecessary alarm, or in some jurisdictions, specific legal notification obligations tied to confirmed breaches rather than exposures. Calling an actual breach a mere "exposure" understates it and can look, in hindsight, like minimizing something more serious than it was described as. Neither direction serves you well, and both come from not being precise about what's actually known.

How to actually figure out which one you're dealing with

  • Check what logs actually exist. Do you have access logs showing who queried the affected data, and when, or is that information simply not tracked?
  • If logs exist, look specifically for access from anything other than the reporting researcher or your own team's testing.
  • If no logs exist at all, that's itself important information: you may not be able to confirm or rule out unauthorized access, and honesty about that uncertainty is better than guessing in either direction.
  • When in doubt, or when logs don't exist to check, describe precisely what's actually known: 'we found data was reachable without proper authorization' is accurate and doesn't overstate what you can't confirm.

What this means for how you communicate, regardless of the exact term

Whatever term ends up being accurate, the actual content of the communication matters more than the label: what was exposed, for how long, what you can and can't confirm about whether it was accessed by anyone else, and what's changed to prevent it happening again. Getting the terminology right is part of being precise and trustworthy in that conversation, not a technicality to hide behind or to overstate for dramatic effect in either direction.

If you're ever in a position where this distinction actually matters for a real incident, particularly anything with potential legal notification requirements, that's a moment worth involving someone qualified to advise on the specific language and obligations for your situation, not something to resolve purely by reading a blog post.

Related reading

Harbova is a security service for apps built with AI tools. Start with a free scan, and if it finds something serious, we can fix it and prove it is closed.