Understanding GDPR Data Breach Definition
A data breach is one of the most critical events an organization must manage under GDPR. The regulation defines a breach specifically and imposes strict requirements for notification, investigation, and remediation. However, the definition is broader than many organizations realize—it goes beyond just hacking incidents to include any unauthorized processing of personal data.
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), notification obligations to affected individuals, mandatory regulatory reporting, and 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.
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
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:
-
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
-
Number of individuals affected:
- Thousands or millions: HIGH RISK
- Hundreds: MEDIUM RISK
- Tens: LOW RISK
-
Likelihood of unauthorized access or use:
- High likelihood: HIGH RISK
- Possible but unlikely: MEDIUM RISK
- Unlikely: LOW RISK
-
Severity of potential harm to individuals:
- Financial loss, identity theft: HIGH RISK
- Embarrassment, discrimination: MEDIUM RISK
- Minor inconvenience: LOW RISK
-
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)
- Identify and isolate: Stop the breach if ongoing
- Assess scope: How many individuals affected? What data?
- Preserve evidence: Don't destroy potential forensic evidence
- Notify leadership: Alert executive management and board
- Engage counsel: Involve legal team and privacy counsel
- Consider law enforcement: Contact police for criminal breaches
Short-term Actions (Days 1-72)
- Investigate thoroughly: Determine what happened and how
- Risk assessment: Evaluate risk to affected individuals
- Notification decision: Determine if notification required
- Prepare notification: Draft communication to individuals
- Notify regulators: File with supervisory authority if required
- Notify individuals: Send breach notification to affected people
- Document all actions: Create detailed incident file
Medium-term Actions (Weeks to Months)
- Remediation: Fix the security vulnerability
- Enhanced monitoring: Monitor for unauthorized use of data
- Credit protection: Consider offering credit monitoring
- Communication: Respond to individual inquiries
- Investigation completion: Finalize forensic investigation
- Regulatory cooperation: Respond to authority inquiries
- Preventive measures: Implement changes to prevent recurrence
Documentation Requirements
Organizations must document:
- Incident discovery: Date and time breach discovered
- Investigation findings: What was accessed/disclosed/lost
- Risk assessment: Evaluation of risk to individuals
- Notification decision: Why notification was or wasn't required
- Remediation actions: Steps taken to fix vulnerability
- Individual communications: What was communicated to affected people
- Regulatory notification: Evidence of reporting to authorities
- 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.



