A privacy incident is any suspected or confirmed event that compromises the confidentiality, integrity, or availability of personal information, including unauthorized access, use, disclosure, loss, or destruction of PII or PHI.
An analytics pixel sending sensitive data from your website, an email sent to the wrong person, or a vendor reporting that their subcontractor was breached are all legally considered privacy incidents. Many teams only recognize the one that qualifies as a breach.
Mixing up “incident” and “breach” can lead to mistakes in how you respond. The law treats them differently, and the definitions vary across GDPR, HIPAA, US federal rules, state laws, and your contracts.
Key takeaways
- An incident is any personal-data event; a breach is the legal subset. Every breach is an incident; most incidents never become breaches.
- The exposure runs through five actors, not just fines: regulators, the plaintiff bar, affected individuals, and contractual counterparties each hold a lever.
- Reportability turns on four questions: personal data? Actually acquired? Harm likely and severe? exceptions? Then the jurisdiction’s clock starts.
- Third parties are involved in 48% of all breaches, up 60% (Verizon 2026 DBIR). That category rarely announces itself.
- Document every decision, including “no.” An undocumented non-report reads to a regulator like no assessment at all.
- The hardest class to catch is the one your security tools don’t see: client-side transmissions from your own tags, pixels, and embedded AI features.
This guide gives you a complete overview. It includes a definition you can use in your policy, explains the difference between incidents and breaches, outlines the risks, covers incident forms, and highlights the types of incidents your security tools may miss.
This guide isn’t about privacy risk. Risk is what could happen. An incident is what has already happened. If nothing has happened yet, start with data privacy risk instead.
What is a privacy incident?
A privacy incident is any event, accidental or intentional, malicious or not, that puts personal data where it should not be. This includes data that is exposed, accessed, used, shared, kept, or destroyed without permission, or in violation of law, policy, or promises to the people the data is about.
Two main ideas in that definition are especially important.
First, an incident does not need to involve an attacker. A mistyped address, a misconfigured form, or a tag collecting more data than promised all count. Even processing that was intended but turned out to be unlawful is included.
Second, an “incident” is a broader category than a “breach.” Every breach is an incident, but most incidents do not become breaches. Here is how they relate:
An event becomes a security incident when it jeopardizes the confidentiality, integrity, or availability of information or systems, or violates security policy. This is the definition US federal law uses (44 U.S.C. § 3552(b)(2), adopted by NIST SP 800-61 Rev. 3). It becomes a privacy incident the moment personal data is involved, a breach when it crosses a legal definition, and a reportable breach when the jurisdiction’s harm threshold and clock attach.
For example, if a DDoS attack takes your brochure site offline for an hour, it is a security incident but not a privacy incident, because no personal data was accessed. The privacy rules do not apply in this case.
How the law defines it
No single law defines the term, which is why teams often misunderstand each other. Here is how each major framework defines the line between an incident and a breach. Notification triggers and deadlines are explained in the determination section.
| Framework | Term used | Core definition (paraphrased) |
| GDPR (EU) | “Personal data breach” (Art. 4(12)) | A breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data – loss of access included, not just disclosure |
| HIPAA (US healthcare) | “Breach” (45 CFR § 164.402) | Impermissible acquisition, access, use, or disclosure of protected health information (PHI) – presumed a breach unless low probability of compromise is shown |
| OMB M-17-12 / FISMA (US federal) | “Incident” vs “breach” (OMB M-17-12) | Incident: jeopardizes confidentiality/integrity/availability or violates policy. Breach: loss of control, compromise, or unauthorized disclosure/acquisition of personally identifiable information (PII) – including potential access |
| Canada – TBS (federal institutions) | “Privacy breach” (TBS guidance) | Improper or unauthorized access to, creation, collection, use, disclosure, retention, or disposal of personal information |
| New Zealand (Privacy Act 2020) | “Notifiable privacy breach” (OPC) | Unauthorized or accidental access, disclosure, alteration, loss, or destruction – or loss of access, e.g., ransomware encryption – causing or likely to cause serious harm |
| Australia (Privacy Act 1988, NDB scheme) | “Eligible data breach” (OAIC) | Unauthorized access or disclosure – or a loss likely to lead to it – that is likely to result in serious harm and isn’t prevented by remedial action |
| US state statutes (all 50 states) | “Breach of the security of the system” (typical phrasing) | Unauthorized acquisition of computerized personal information |
| Contracts & business associate agreements (BAAs) | “Privacy incident” (defined per agreement) | Often broader than any statute – public-sector contracts, for example, define it as any violation of data-practices law or duty to protect state data (see Minnesota Statutes ch. 13) |
A common terminology issue: Canadian guidance uses “privacy breach” for what US practice calls a “privacy incident,” and uses “material breach” for the reportable level. If you use policies from other countries, check what each term means in that context.
Why “no hacker” doesn’t mean “no incident”
Many privacy incidents do not involve any intrusion. Regulatory agencies have demonstrated this through enforcement actions. For example, the FTC took action against GoodRx and BetterHelp because advertising pixels sent data they should not have.
Nothing was “hacked,” yet the conduct was treated as unauthorized disclosure of health information and, in GoodRx’s case, as a breach-notification failure under the Health Breach Notification Rule.
Privacy incident vs. security incident vs. data breach vs. privacy violation
There are four terms, each with its own owners, responsibilities, and timelines. They are related but not interchangeable, and there are two important exceptions to how they fit together.
| Security incident | Privacy incident | Reportable data breach | Privacy violation | |
| What it is | An event compromising the confidentiality, integrity, or availability of a system or its data | A suspected or confirmed compromise of personal information | A privacy incident meeting a statutory notification threshold | Personal data handled contrary to law, consent, or your own privacy notice |
| Personal data involved? | No | Yes | Yes | Yes |
| System involved? | Yes | No | No | No |
| Did something go wrong? | Yes | Yes | Yes | Not necessarily. The system may be working as designed |
| Typical owner | Security / SOC | Privacy, legal, compliance | Privacy + legal + executive | Privacy + legal + product |
| Triggers external notification? | Usually not by itself | Not by itself | Yes | Depends on regime; often surfaces via regulator or litigation |
| Documentation required? | Per internal policy | Yes, see below | Yes | Yes |
The cost of calling a breach an incident
Under-classification is the expensive direction. Notification duties attach to the breach tier, and missing them is a violation. Under GDPR, late notification infringes Art. 33 alone and must be accompanied by reasons for the delay (EDPB Guidelines 9/2022).
Both GDPR and HIPAA put the documentation burden on the organization, as detailed in “Document the ‘no'” below. Scale adds weight: IBM’s 2026 Cost of a Data Breach Report says the global average is now USD 4.99 million. For more details, see our data privacy risk guide.
What are examples of a privacy incident?
Privacy incidents are common, and most do not involve an attacker. Of the eight categories listed below, AI and vendor disclosure are rarely mentioned in standard guides. These two types also tend to go undetected the longest.
| # | Category | Examples | Usually detected by | Typical time undetected |
| 1 | Misdirection and human error | Email to the wrong recipient; cc instead of bcc; wrong attachment; letter to a superseded address | Self-report, or the recipient tells you | Immediate to days |
| 2 | Unauthorized internal access | Viewing a record with no business reason; access retained after a role change; permissions broader than the job needs | Access log review, audit, complaint | Weeks to indefinite |
| 3 | Loss and theft | Lost phone or laptop; stolen bag; misplaced paper file; unencrypted USB drive | Self-report | Immediate to days |
| 4 | Improper disposal | Records in general waste; drives not wiped; office move leaves files behind | Third-party discovery, often public | Indefinite |
| 5 | Security-originated | Phishing leading to mailbox access; ransomware touching personal data; misconfigured storage bucket | Security tooling, threat intel, extortion demand | Days to months |
| 6 | Wrongful collection, over-collection, and purpose drift | You collect or transmit data you had no right to touch, form collecting more than the notice discloses; support data reused for marketing; location captured without a basis | Audit, DSAR, regulator, complaint | Months to indefinite |
| 7 | AI and shadow AI disclosure | Personal data pasted into a public chatbot; an approved tool’s new AI feature routing content to an undisclosed model provider | Rarely detected by conventional controls | Indefinite |
| 8 | Vendor and fourth-party disclosure | Vendor receives more than the contract permits; approved vendor forwards data downstream; a marketing tag transmits identifiers to undisclosed parties | Rarely detected by conventional controls | Indefinite |
Most of the above assumes the incident announces itself. There’s a whole class where nothing does.
Vendor and fourth-party disclosure
You share customer data with an approved vendor. The contract is signed, the DPA is in place, and the questionnaire is complete. But the vendor uses a downstream service you did not know about, and your data ends up there. Nothing was broken, no system was compromised, and no policy was bypassed. There are no alerts, tickets, self-reports, or calls from recipients.
Personal data still reached a recipient you never disclosed or authorized. According to NIST, this is a loss of control. If an approved vendor sends personal data to an undisclosed recipient, it is an unauthorized disclosure and a privacy incident, no matter how legitimate the relationship or how careful the contract.
→ Read the complete guide to third-party privacy risk
AI and Shadow AI disclosure
Shadow AI and unapproved data flows are the newest types and the least settled. An employee pastes customer records into an unapproved chatbot. A SaaS tool could enable an AI feature that sends your data to a model provider, or an “AI-powered” vendor might add a downstream processor without telling you. These are similar to vendor incidents, but they bypass procurement and are not covered by questionnaires.
Verizon’s 2026 DBIR found that frequent employee use of AI tools jumped from 15% to 45% in one year, making shadow AI the third most common non-malicious data leak (Verizon). The main issue is not whether the tool is useful, but whether personal data left your control and reached an undisclosed recipient, possibly for training.
Wrongful collection and consent failures
An incident can occur without a malicious actor when your own website, application, or web form collects or transmits personal information without a proper legal basis. The FTC’s 2023 health-tracking actions are landmark examples: GoodRx (February 2023, $1.5 million civil penalty, the first Health Breach Notification Rule action) and BetterHelp (March 2023, $7.8 million in consumer refunds) both involved sharing health-related data with advertising platforms through ordinary website tracking.
Opt-outs count too: under the Colorado Privacy Act, controllers must honor universal opt-out mechanisms (since July 1, 2024), and selling a consumer’s data or using it for targeted advertising after they opt out is a violation enforceable by the attorney general (§ 6-1-1311).
In healthcare, HHS’s online-tracking bulletin (2022, revised March 2024) pushed the same logic at HIPAA-covered websites. A federal court later vacated the portion treating IP-plus-visit data on unauthenticated pages as automatic PHI (AHA v. Becerra, June 2024). Our HIPAA-compliant tracking guide covers the contested perimeter in depth.
In California, plaintiffs route the same conduct through the wiretap-era CIPA statute. We covered that litigation wave in our CIPA guide, as well as the pen-register theory behind it.
What mishandling a privacy incident costs
A slow or disorganized response is not just a compliance problem. It is a cost line. Consequences run through four channels: regulatory fines, notification and remediation costs, lawsuits, and damage to your business and reputation, including higher insurance costs. Incidents are, to a degree, inevitable. Silence and missing records are choices.
| Who shows up | What they can do |
| EU supervisory authorities | Fines in two tiers: up to €10M or 2% of global turnover for breach-of-obligation failures – including Art. 33–34 notification – and up to €20M or 4% for infringing the processing principles themselves (Art. 83(4)–(5)) |
| US regulators | HHS OCR: civil penalties across four culpability tiers, 2026 schedule topping at $73,011 per violation and $2,190,294 per provision per year for uncorrected willful neglect (45 CFR § 160.404; amounts as adjusted in 45 CFR 102.3). FTC: civil penalties for health-data notification failures. State AGs enforce state breach statutes |
| The plaintiff bar | Statutory damages without proving individual loss: CIPA runs $5,000 per violation; CCPA § 1798.150 allows $100–$750 per consumer per incident (adjusted periodically for inflation). 23andMe’s incident ended in a $46.75 million class settlement |
| Affected individuals | Complaints that trigger investigations – and, under GDPR, compensation claims for material and non-material damage (Art. 82). The Meta Pixel hospital cases began as patients’ browser activity |
| Contractual counterparties | Indemnity claims, audit rights, termination – on clocks shorter than any statute. MOVEit is the canonical example |
Whether an incident supports a class action turns on the specific statute, whether it provides a private right of action, and whether individuals can establish standing. It varies too much for a general answer.
When does a privacy incident become a reportable breach?
Many explanations just say, “a risk assessment decides if notification is needed,” but that is not enough. The real test is a documented legal assessment based on specific legal factors, and the deadline often starts before your investigation is finished.
Is it reportable?
This is the question that matters, and it has a method. Strip away the jurisdictional surface differences and the regimes converge on four questions, even if not every regime asks all four:
The 4-question determination
Q1. Was personal data involved, and what kind?
Sending an org chart to the wrong person and sending a list of chemotherapy appointments by mistake are similar mistakes, but the impact is very different. Sensitive data like PHI, credentials, children’s data, and government IDs increase the risk. If no personal data was involved, it is just a security incident, and you can stop there.
Q2. Was the data actually acquired, disclosed, or used, or only potentially?
Federal guidance counts even potential access by an unauthorized person as a breach (OMB M-17-12); HIPAA’s four-factor test asks “whether the protected health information was actually acquired or viewed.” Forensics showing that data was encrypted, unreadable, or never touched de-escalates the answer.
Q3. What is the likelihood and severity of harm to individuals?
This is the key question in every framework. GDPR looks at risks to people’s rights and freedoms. Canada’s TBS asks if the breach could reasonably cause real harm, such as embarrassment, damage to reputation, identity theft, or financial loss.
HIPAA requires you to score a four-factor risk assessment: the type and amount of PHI, who the unauthorized person is, whether the PHI was actually acquired or viewed, and how much the risk has been reduced.
Q4. Do any exceptions or safe harbors apply?
HIPAA excludes three narrow situations: good-faith, unintentional acquisition by a workforce member acting within authority; inadvertent disclosure between two people authorized to access the same PHI; and disclosures the recipient could not reasonably retain (§ 164.402).
Many state statutes ignore incidents involving encrypted data. Know your exceptions before the incident, not during it.
What “harm” actually means
“Harm” in breach of law means concrete damage to the person the data describes, such as financial, reputational, emotional, or physical harm. GDPR’s own list (Recital 85) runs from loss of control over personal data to discrimination, identity theft or fraud, financial loss, damage to reputation, breach of professional secrecy, and “any other significant economic or social disadvantage.” The ICO’s breach guide walks through the same assessment. In practice, the scenarios cluster:
- Financial. Exposed credentials or account data enable fraud and account takeover – measurable, fast-moving harm.
- Reputational and emotional. Health, relationship, or location details become known to people who shouldn’t know them; distress and stigma are recognized as non-material damage (Art. 82).
- Physical safety. A home address or daily routine exposed to the wrong person.
Who the data is about is just as important as what the data is. Children, patients, and people in financial hardship face elevated stakes from the same exposure, and frameworks treat special-category data as higher risk.
When the clock actually starts
Not when you finish investigating. Not when you confirm the incident, and not when legal signs off. Under HIPAA, knowledge is imputed to the entity if the breach was known, or would have been known through reasonable diligence, to any workforce member or agent other than the person who committed it (§ 164.404(a)(2)).
If a helpdesk technician knew about a breach three weeks ago but did not report it, your 60-day deadline may have already started. Whether an unexplained issue counts depends on the facts. The risk of missing the deadline is on the organization, not the individual who stayed quiet.
| Regime | Notify whom | Deadline |
| GDPR | Supervisory authority | Without undue delay; where feasible within 72 hours of awareness, unless unlikely to pose risk (Art. 33); individuals without undue delay if high risk (Art. 34) |
| HIPAA | Individuals | Without unreasonable delay, ≤ 60 calendar days from discovery (§ 164.404) |
| HHS | Same 60-day window if 500 or more individuals are affected; otherwise, logged and reported annually, within 60 days of calendar year-end (§ 164.408) | |
| Media | If more than 500 residents of a single state or jurisdiction are affected (§ 164.406) | |
| US states | Individuals / AG | Codified caps: 30 days in California (§ 1798.82, as amended by SB 446, eff. Jan 1, 2026 – plus a sample notice to the AG within 15 days when more than 500 California residents are affected), Colorado, Florida, Washington; 45 days in Maryland. All 50 states have breach-notification laws. |
| Australia | OAIC + individuals | “As soon as practicable”; suspected-breach assessment – take all reasonable steps to complete it within 30 calendar days (s 26WH(2)(b)) |
| Contractual obligations / BAAs | Counterparty | Often shorter than any statute. Check the agreement first. |
What you must document even when you decide not to report
The determination itself is a compliance artifact. GDPR requires the controller to document any personal data breach – its facts, effects, and the remedial action taken (Art. 33(5)) precisely so a supervisory authority can verify the decision later. HIPAA places the burden on the organization to demonstrate a low probability of compromise (45 CFR §§ 164.402(2), 164.414(b)).
A “we decided not to report” that exists only in someone’s memory is indistinguishable to a regulator from “we never assessed it.”
Simply put, a regulator can ask to see the incidents you chose not to report and your reasons for each one. If you did not write down those decisions, you cannot prove you made them.
| Field | Why |
| Incident reference and date discovered | Establishes the clock |
| Date occurred, or best estimate | Distinguishes occurrence from discovery |
| How discovered, and by whom | Evidence detection capability |
| The facts of the incident | Required, Art. 33(5) |
| Categories and approximate number of data subjects and records | Art. 33(3)(a) |
| The effects of the incident | Required, Art. 33(5) |
| Incident category (see taxonomy) | Enables trend analysis |
| Notification assessment: factors applied, outcome | The rebuttal evidence |
| Decision, and reasoning where you did not notify | The entry a regulator will ask about |
| Who decided, and when | Accountability |
| Remedial action taken | Required, Art. 33(5) |
| Root cause and control changes | Turns a log into a program |
The privacy incidents nobody detects: the client-side blind spot
The hardest privacy incidents to catch are those that no standard tool detects, like wrongful data collection, tracker transmissions, and shadow AI flows running in the browser. The four key questions only help with incidents you know about. Security tools catch intrusions, misdirected emails are usually reported, and lost laptops are noticed. But client-side incidents do not trigger alerts or show up as malware. In server logs, these transmissions look like normal traffic.
How undetected incidents get discovered
So these privacy incidents get discovered by outsiders instead:
- A regulator. The FTC’s health-tracking enforcement made ad-pixel sharing of health data a seven-figure problem.
- A plaintiff firm. Hospital websites’ Meta Pixel use is the subject of consolidated federal litigation (In re Meta Pixel Healthcare Litigation, N.D. Cal.), and California’s CIPA bar has industrialized the demand letter. Our Vivek Shah case study shows what it looks like to learn about your own site from a demand letter.
- A journalist or outside researcher. Whose story becomes your incident notification.
The main problem is a gap in monitoring. Contracts and vendor questionnaires show what third parties promised, but not what is actually happening on your site, what data tags are sending, or which fourth parties are involved. Attestations show intent, but incidents are about what really happens.
What continuous client-side observation changes
MELURNA monitors what your website or app actually sends from the client side: which pixels, tags, and SDKs are active, what data they carry (for example, an email address captured at form entry and transmitted to an advertising platform), who receives it, including third- and fourth parties past the processor you vetted, and what has changed since the last scan.
Find out what your site is really sending. Reserve a review slot today.
Privacy incident response fundamentals
What you do in the first 24 hours comes down to six fundamentals. The complete response plan (templates, tabletop exercises, notification letter walkthroughs) is in a separate playbook:
- Report and log everything. Near misses included. Give people a channel they can actually use (manager, privacy office, hotline) and a standing rule that if uncertain, report anyway: a false alarm costs minutes, a missed report burns the clock.
- Contain. Recall the email and ask the recipient to delete it. Revoke the access. Pull the tag. Disable the flow. Remote-wipe the laptop. Containment verbs are boring and fast, and every hour they save shrinks the harm assessment.
- Assemble the incident response team. Privacy, security, legal, communications, and whoever owns the vendor relationship. “Named” matters: an incident is the wrong time to discover nobody knows who decides.
- Assess with the four questions. The determination method from the previous section, now run under clock pressure, with whoever owns the evidence in the room.
- Decide, document, notify. Written determination either way, then the notifications the clocks demand. Preserve the evidence behind the decision (logs, forensic notes, the assessment itself) the way you’d present it to a regulator.
- Learn. Root cause, control change, log review on a cadence. Plans that aren’t drilled fail on contact.
FAQs
Is a privacy incident the same as a data breach?
No. A data breach is a subset of privacy incidents that meets a legal notification threshold. Every reportable breach is a privacy incident. Most privacy incidents are not reportable breaches.
Can something be a privacy incident and not a security incident?
Yes, and it’s common. A letter to the wrong address, a file left in a printer tray, or a verbal disclosure all compromise sensitive information without compromising any system. Most security tooling isn’t built to detect these.
Do I have to document an incident I decided not to report?
Yes. GDPR Article 33(5) requires controllers to document any personal data breach, including those that are never notified, recording the facts, the effects, and the remedial action taken, so that a supervisory authority can verify compliance.
Who is responsible for investigating a privacy incident?
Typically, privacy, legal, or compliance work with security when a system is involved. Security, privacy, and legal determine reportability; an accountable executive decides on notification; and a named owner maintains the register. The discovering employee’s only job is to report it.
How is a privacy incident different from a HIPAA breach?
A HIPAA breach is a specific determination about unsecured protected health information under 45 CFR § 164.402. A privacy incident is the broader category. It may involve PII rather than PHI, fall under GDPR or state law, and may meet no notification threshold at all.
What is privacy incident risk management?
The program through which an organization detects, classifies, assesses, reports, documents, and remediates events involving personal data, spanning detection, the notification determination, the Article 33(5) register, and root-cause remediation.
When must a privacy incident be reported?
Only when it meets the legal breach threshold. Then the clocks start: GDPR gives 72 hours to the supervisory authority where feasible; HIPAA gives 60 days to individuals; US states say “without unreasonable delay,” with several codifying 30- or 45-day caps; contracts are often the shortest of all.
DISCLAIMER: This article is for general informational purposes only and does not constitute legal advice. While we strive for accuracy, we make no warranties about the completeness or reliability of this information, and are not liable for any errors, omissions, or actions taken based on its contents. Consult a licensed attorney for guidance specific to your business.
