What is a data breach under GDPR?

Understanding GDPR Data Breach Definition

Under GDPR (Article 4(12)), a personal data breach is any breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. That definition is deliberately broad: it covers a hacked database, a laptop stolen from a car, ransomware that locks your own files, an email sent to the wrong list, and an employee who reads records they have no business reason to see. Intent is irrelevant — an accident triggers the same obligations as an attack. If the breach is likely to risk people's rights and freedoms, you must notify your supervisory authority within 72 hours; if the risk is high, you must also tell the affected individuals.

That is the summary an AI Overview will hand you. What it can't show you is where the real decisions get made: the difference between a breach you must report and one you only log, why an encrypted lost drive is often a non-event, and how the 72-hour clock actually starts. The rest of this page is built around those judgment calls — a decision-flow diagram for the 72-hour question, a table that maps common incidents to whether they're reportable, and the risk factors regulators actually weigh.

Understanding precisely what constitutes a breach under GDPR is essential because the consequences are severe: regulatory fines up to 4% of global revenue or 20 million EUR (whichever is higher) for the worst violations, notification obligations to affected individuals, mandatory regulatory reporting, and lasting damage to organizational reputation.

GDPR Definition of Personal Data Breach

Legal Definition

GDPR Article 4(12) defines a personal data breach as:

"a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed."

Breaking this down into components:

1. "Breach of Security"

A failure of security measures protecting personal data. This includes:

Technical breaches:

• Hacking attacks exploiting security vulnerabilities
• Malware infection compromising data integrity
• Ransomware encrypting personal data
• SQL injection attacks accessing databases
• Exploitation of unpatched systems
• Man-in-the-middle attacks intercepting data transmission

Physical breaches:

• Theft of devices containing personal data
• Unauthorized physical access to servers or data centers
• Loss of backup tapes or external drives
• Theft of paper records
• Unattended devices left in public spaces

Administrative breaches:

• Failure to implement access controls
• Sharing credentials inappropriately
• Failure to encrypt data
• Inadequate IT security practices
• Lack of secure deletion procedures
• Failure to segment networks

Human error breaches:

• Sending emails to wrong recipients
• Misconfiguring cloud storage (leaving buckets public)
• Accidental deletion of data
• Unauthorized access by employees
• Improper disposal of documents
• Uploading files to wrong location

2. "Accidental or Unlawful"

The breach can result from:

• Intentional wrongdoing: Deliberate misuse by employees, competitors, or attackers
• Negligence: Failure to implement reasonable security measures
• Accident: Unforeseeable incidents like natural disasters
• Incompetence: Well-intentioned but careless actions

Important: Intent doesn't matter. Even accidental breaches trigger GDPR obligations.

3. "Destruction, Loss, Alteration, Unauthorised Disclosure, or Access"

The breach involves one or more of these impacts:

Destruction: Data is deleted or rendered inaccessible

• Example: Ransomware deleting backup data
• Example: System administrator mistakenly deleting customer database
• Impact: Data no longer available for recovery

Loss: Data goes missing or cannot be recovered

• Example: Lost external hard drive containing unencrypted customer data
• Example: Laptop stolen with personal data on unencrypted drive
• Impact: Data presumed in unauthorized possession

Alteration: Data is modified without authorization

• Example: Hacker modifies customer account information
• Example: Ransomware corrupts data before encryption
• Impact: Data integrity compromised, cannot be trusted

Unauthorised Disclosure: Data is revealed to unauthorized parties

• Example: Hacker gains access to customer database and copies it
• Example: Email sent to wrong recipient containing personal data
• Example: Customer service representative improperly sharing data
• Example: Cloud storage misconfiguration exposing data publicly
• Impact: Individuals' personal information accessible to third parties

Unauthorised Access: Data is accessed by those without permission

• Example: Hacker accessing but not copying data
• Example: Employee accessing customer data without business need
• Example: Former employee retaining access to data after departure
• Impact: Even without copying, access is a breach

4. "Personal Data Transmitted, Stored or Otherwise Processed"

The breach must involve personal data. This includes:

Personal data types:

• Names, email addresses, phone numbers
• Identification numbers (SSN, ID card numbers)
• Location data and IP addresses
• Financial information (bank accounts, credit cards)
• Medical and health information
• Biometric data
• Genetic information
• Religious, political, sexual orientation information
• Any data allowing individual identification

Processing contexts:

• Data in use (actively being processed)
• Data at rest (stored on servers, backups, devices)
• Data in transit (being transmitted across networks)

When Is a Breach NOT a Breach?

Important clarifications about what does NOT constitute a GDPR breach:

1. Loss of Control Without Actual Breach

If an organization loses control of data but there's no evidence of access or misuse:

Example: A backup tape is lost in transit, but:

• Data is encrypted with keys organization retains
• No evidence of access or unauthorized disclosure
• Organization proves data couldn't be accessed without decryption keys
• Encryption is sufficiently strong

Assessment: This might not require notification if encryption proves data remains secure.

2. Access by Authorized Personnel for Improper Purpose

If an employee accesses data they're authorized to see but uses it improperly:

Example: HR employee accessing employee salary data for personal blackmail

• Employee was authorized to access payroll data
• Action is unauthorized use, not unauthorized access
• Still a breach because data was processed unlawfully

Assessment: This IS a breach (unlawful processing), though perhaps with lower risk to individuals if data wasn't disclosed.

3. Anonymous Data

If data is properly anonymized (cannot be linked to individuals):

Example: Statistical analysis showing that "95% of users in age group 25-30 prefer product A"

• No way to identify specific individuals
• GDPR doesn't apply to anonymous data

Assessment: NOT a breach, though anonymization must be genuine and irreversible.

4. Pseudo-Anonymous Data

If data is pseudonymized (linked to identifiers but not individual names):

Example: Data processed using only user IDs without name/contact info

• If re-identification is not practically feasible
• If encryption keys are stored separately and secured
• Data remains pseudonymous

Assessment: May not be a reportable breach if technical and organizational safeguards prevent re-identification, but security standards must be very high.

Quick reference: is this incident reportable?

Use this as a first pass, not a final ruling — every case turns on the specific data and the realistic risk. The "which threshold" column shows how far up the notification ladder a typical version of each incident climbs.

Incident	Breach type	Likely reportable to regulator?	Notify individuals too?
Laptop stolen, full-disk encrypted, keys secure	Confidentiality	Usually no — log only	No
Laptop stolen, unencrypted, holds customer records	Confidentiality	Yes	Likely yes (high risk)
Ransomware encrypts records, clean backups restore fast, no exfiltration	Availability	Often yes (assess risk)	Usually no
Ransomware with data exfiltration ("double extortion")	Confidentiality + Availability	Yes	Likely yes (high risk)
Email with a client list sent to the wrong external recipient	Confidentiality	Yes	Depends on data sensitivity
Misconfigured cloud bucket exposing personal data publicly	Confidentiality	Yes	Likely yes if sensitive/large
Employee reads records without a business reason, no disclosure	Confidentiality (unlawful processing)	Often yes	Usually no unless disclosed
Genuinely anonymised dataset exposed	Not personal data	No — GDPR does not apply	No
Which should I use as the default?	Treat every incident as reportable until a documented risk assessment says otherwise	Log everything; report on risk	Reserve individual notice for HIGH risk

Categories of Breaches and Examples

Category 1: Hacking and Cyber Attacks

Characteristics:

• External attacker exploiting security vulnerabilities
• Often involves unauthorized database access
• Typically affects many individuals
• Usually requires notification

Real examples:

• Social media platform hacked, user data compromised
• Retailer's payment system compromised through SQL injection
• Ransomware attacking healthcare provider's patient database
• Botnet targeting customer databases

Notification likelihood: Very high

Category 2: Insider Threats and Employee Misuse

Characteristics:

• Authorized employee accessing data improperly
• Could involve theft or competitive espionage
• Scope varies from single to many individuals
• High reputational risk

Real examples:

• Employee stealing customer database for competing company
• HR staff accessing employee data for personal purposes
• Customer service representative selling customer information
• Finance employee accessing salary data inappropriately

Notification likelihood: High (especially if data was disclosed)

Category 3: Lost or Stolen Devices

Characteristics:

• Physical loss of device containing personal data
• Risk depends on whether data is encrypted
• Organizations often assume worst-case scenario
• Scope depends on device and data it contained

Real examples:

• Laptop stolen with unencrypted customer database
• USB drive with personal data lost by employee
• External hard drive misplaced containing backup data
• Smartphone with access to personal data applications

Notification likelihood: Medium to high (depends on encryption and content)

Category 4: Misconfiguration and Exposure

Characteristics:

• Accidental exposure, usually through configuration errors
• Cloud storage, databases, or servers left publicly accessible
• Often discovered by security researchers
• Growing category with cloud computing expansion

Real examples:

• Amazon S3 bucket left public, exposing millions of records
• Elasticsearch database exposed on internet without authentication
• Cloud database misconfigured allowing unauthorized access
• FTP server left accessible without proper credentials

Notification likelihood: High (often affects many individuals)

Category 5: Misdirection and Human Error

Characteristics:

• Data sent to wrong recipient
• Unauthorized disclosure without malicious intent
• Often involves email, printing, or filing errors
• Can affect small or large numbers depending on recipient

Real examples:

• Email sent to wrong recipient containing personal data
• Printout of sensitive data left unattended
• Document uploaded to wrong cloud folder
• Fax sent to wrong number containing personal data
• Hard copy of records misfiled or delivered to wrong address

Notification likelihood: Depends on likelihood of access/disclosure

Category 6: Third-Party Breaches

Characteristics:

• Breach originates with a processor or vendor
• Organization (controller) must respond despite not being direct cause
• Requires contractual notification from processors
• Damage control and notification still organization's responsibility

Real examples:

• Cloud service provider breached
• Email marketing vendor compromised
• IT support company providing unauthorized access
• HR software provider hacked
• Payroll processing company breached

Notification likelihood: High (though responsibility may be shared)

Risk Assessment: When Notification is Required

Not every breach goes to the regulator, and not every reportable breach goes to individuals. GDPR sets two separate thresholds. The diagram below walks a confirmed breach through both decisions and the 72-hour clock.

NO Log in breach register no notification required

YES

Notify supervisory authority within 72 hours (Art. 33) HIGH risk? Notify affected individuals without undue delay (Art. 34) YES

Threshold Question: Risk to Individual Rights and Freedoms

GDPR Article 33 requires notification to the supervisory authority (data protection authority) "without undue delay" when:

The breach creates "a risk to the rights and freedoms of natural persons."

Key factors in assessing risk:

1. Type of personal data compromised:

   • Special categories (health, genetic, biometric): HIGH RISK
   • Financial data (bank account, credit card): HIGH RISK
   • Contact information alone (name, phone): LOW RISK
   • Mixed data: MEDIUM to HIGH RISK

2. Number of individuals affected:

   • Thousands or millions: HIGH RISK
   • Hundreds: MEDIUM RISK
   • Tens: LOW RISK

3. Likelihood of unauthorized access or use:

   • High likelihood: HIGH RISK
   • Possible but unlikely: MEDIUM RISK
   • Unlikely: LOW RISK

4. Severity of potential harm to individuals:

   • Financial loss, identity theft: HIGH RISK
   • Embarrassment, discrimination: MEDIUM RISK
   • Minor inconvenience: LOW RISK

5. Evidence of misuse:

   • Data was actually disclosed: HIGH RISK
   • Data access confirmed: HIGH RISK
   • Data lost but no evidence of access: MEDIUM to HIGH RISK
   • Data secure despite breach incident: LOW RISK

Notification Timeline

To Supervisory Authority:

• "Without undue delay" and
• "Not later than 72 hours" after becoming aware of breach
• If delay is necessary for investigation, document the reason

To Affected Individuals (if high risk):

• "Without undue delay"
• "In clear and plain language"
• Contact details: email, phone, postal mail, or other means
• Individualized communication where practical (not just press releases)

What Organizations Must Do After Discovering a Breach

Immediate Actions (First 24 hours)

1. Identify and isolate: Stop the breach if ongoing
2. Assess scope: How many individuals affected? What data?
3. Preserve evidence: Don't destroy potential forensic evidence
4. Notify leadership: Alert executive management and board
5. Engage counsel: Involve legal team and privacy counsel
6. Consider law enforcement: Contact police for criminal breaches

Short-term Actions (Days 1-72)

1. Investigate thoroughly: Determine what happened and how
2. Risk assessment: Evaluate risk to affected individuals
3. Notification decision: Determine if notification required
4. Prepare notification: Draft communication to individuals
5. Notify regulators: File with supervisory authority if required
6. Notify individuals: Send breach notification to affected people
7. Document all actions: Create detailed incident file

Medium-term Actions (Weeks to Months)

1. Remediation: Fix the security vulnerability
2. Enhanced monitoring: Monitor for unauthorized use of data
3. Credit protection: Consider offering credit monitoring
4. Communication: Respond to individual inquiries
5. Investigation completion: Finalize forensic investigation
6. Regulatory cooperation: Respond to authority inquiries
7. Preventive measures: Implement changes to prevent recurrence

Documentation Requirements

Organizations must document:

1. Incident discovery: Date and time breach discovered
2. Investigation findings: What was accessed/disclosed/lost
3. Risk assessment: Evaluation of risk to individuals
4. Notification decision: Why notification was or wasn't required
5. Remediation actions: Steps taken to fix vulnerability
6. Individual communications: What was communicated to affected people
7. Regulatory notification: Evidence of reporting to authorities
8. Timeline: Detailed chronology of all actions taken

This documentation proves regulatory compliance and helps defense if enforcement action occurs.

Common Breach Notification Mistakes

Mistake 1: Delayed Notification

Error: Not notifying within 72 hours to authority or promptly to individuals Consequence: GDPR Article 83 fines up to 4% of global revenue Prevention: Establish clear notification procedures; include timelines in incident response plan

Mistake 2: Insufficient Risk Assessment

Error: Notifying for low-risk breaches or failing to notify high-risk breaches Consequence: Regulatory criticism either way; failure to protect individuals Prevention: Develop detailed risk assessment framework; consult external experts

Mistake 3: Vague or Unclear Notification

Error: Notifying individuals in technical jargon or unclear language Consequence: Individuals don't understand impact; regulatory criticism Prevention: Use plain language; focus on what individuals should do

Mistake 4: Incomplete Communication

Error: Notification doesn't include what organizations should do to help Consequence: Individuals don't know how to protect themselves Prevention: Include credit monitoring details, contact information, prevention steps

Conclusion

Under GDPR, a data breach is any unauthorized access, disclosure, loss, alteration, or destruction of personal data. The definition is broad, encompassing hacking, human error, insider threats, and misconfiguration. When a breach poses a risk to individual rights and freedoms, organizations must notify supervisory authorities within 72 hours and individuals without undue delay.

The key to effective breach management is understanding the definition clearly, developing robust incident response procedures with clear timelines, conducting thorough risk assessments, and communicating transparently with both regulators and affected individuals. Organizations that take these responsibilities seriously demonstrate GDPR commitment and significantly reduce regulatory penalties and reputational damage when breaches occur.