Data breach
Data you were trusted with gets seen, taken, altered, or destroyed by someone who should not have touched it, whether by an attacker or by accident.
See it
What it is
A data breach is a security failure involving data you were trusted with, and the legal definition is wider than most people assume. GDPR counts accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data, so deleting a production table with no backup or letting a bad migration corrupt customer records counts too, even though nobody took anything. Note that it does not require a hacker either. The most common causes are boring: a public S3 bucket, an unauthenticated database left on the open internet, an API key committed to a repo, an IDOR that let anyone increment an ID, a support tool with no tenant scoping, or an employee laptop. 'Nobody broke in' is not a defense if the door was open.
Vocabulary matters here because the law uses it. An incident is anything suspicious. A breach is a confirmed one, and it starts a clock: under GDPR, where the breach is likely to risk people's rights and freedoms you have 72 hours from awareness to notify the supervisory authority. That likelihood test is the trigger, not the breach itself, so not every breach gets reported, but you still have to document the ones you decided not to report and why. US state laws add their own notification duties. Which is why the practical question during an investigation is not 'were we hacked' but 'can we prove what was and was not accessed', and that answer comes entirely from logs you set up months earlier.
Reputational damage comes from two places, and you only control one of them. What was actually exposed sets the floor: passport scans and health records land harder than a list of email addresses, and no statement fixes that. The handling sets the rest. Sitting on it, minimizing it ('a small number of accounts'), or letting a journalist break the news for you is what turns a bad week into the thing people remember about the company. Two more traps: 'our vendor was breached, not us' means nothing to your users or to a regulator, and credential stuffing attacks against your login are downstream of somebody else's breach, which is why password reuse makes their bad day yours.
Ask AI for it
Run a breach exposure review of this codebase and infrastructure. Enumerate every place user data lives (databases, object storage, caches, logs, analytics, third-party vendors, backups) and for each one tell me: what personal data it holds, who or what can read it, whether it is encrypted at rest, and whether access is logged. Then flag the specific paths that would turn into a breach: object storage with public or overly broad access, endpoints returning records without an ownership check, credentials in the repo or in environment dumps, log lines printing tokens or full request bodies, and long-lived keys with no rotation. Output a table sorted by how much data one failure would expose.