A GDPR personal data breach is a security incident that leads to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. It can affect confidentiality, integrity, availability or more than one of these dimensions.
Examples include misdirected customer information, a lost unencrypted device, exposed cloud records, ransomware-driven unavailability, unauthorised employee access, improper disposal or a processor incident.
The response requirement is risk-based. Under the current Article 33 framework, the controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of awareness unless risk to individuals is unlikely. High-risk cases may also require communication to affected people.
This guide explains how to organise the first 72 hours, make a defensible decision while facts change and preserve accountability evidence.
Distinguish a security incident from a personal data breach#
Not every cyber or operational incident involves personal data, and not every personal data breach is a sophisticated cyberattack.
A security alert becomes a potential personal data breach when personal data may have been destroyed, lost, changed, disclosed or accessed without authorisation. The privacy workflow should therefore integrate with incident management rather than depend on a separate email sent after the security investigation.
Examples:
- A service outage with no loss of access to personal data may be an availability incident but not a personal data breach.
- Ransomware that prevents timely access to patient or payroll records can be a personal data breach even when exfiltration is not confirmed.
- An email sent to the wrong customer may be a confidentiality breach even if the recipient promises deletion.
- Incorrect data written back to many customer records can be an integrity breach.
- An employee viewing records without a business need can be a breach even if no file leaves the organisation.
Front-line staff and processors should report suspected events immediately. They should not wait until impact is proven.
Record the moment of awareness#
The 72-hour period is linked to awareness, so the record needs more than the date the incident ticket was created. The organisation should capture:
- Occurrence and detection times, if known.
- Detector, source and initial escalation.
- The time sufficient certainty existed that personal data was compromised.
- The decision-maker, time zone, rationale and unresolved uncertainty.
The European Data Protection Board considers a controller aware when it has a reasonable degree of certainty that a security incident has occurred and compromised personal data. The exact application depends on the facts, so the organisation should preserve the rationale and obtain legal or DPO input where needed.
A processor must notify the controller without undue delay after becoming aware of a breach. Controller-processor contracts should define an operational target shorter than the controller's external deadline, the minimum information required, escalation contacts and support during investigation.
Activate a cross-functional response#
A personal data breach may require privacy, information security, legal, operations, communications, customer service, HR, procurement, records management and executive management. The incident lead and privacy lead should have distinct but coordinated responsibilities.
The response team should cover:
- Containment, forensics and service restoration.
- Identification of data, systems and affected individuals.
- Legal, regulatory, processor and third-party coordination.
- Regulator and individual communications.
- Evidence, decisions, corrective action and post-incident review.
The application should create a response team, assign tasks and restrict sensitive evidence. Material incidents should have a clear executive escalation route.
The first four hours: contain and establish facts#
Immediate actions should reduce continuing harm without destroying evidence. Depending on the event, teams may revoke credentials, isolate systems, stop an incorrect mailing, recall a message, disable a public link, contact an unintended recipient, preserve logs, block downloads or invoke continuity procedures.
At the same time, establish the initial facts:
- Which controller, systems, locations and processors are involved?
- What data and categories of individuals may be affected?
- Is sensitive, financial, identity, location or children's data involved?
- Were effective protections such as encryption or pseudonymisation in place?
- Are access, exfiltration, alteration, destruction or continuing exposure confirmed?
- Can affected records and people be identified, and are other jurisdictions involved?
Initial records can use clearly labelled estimates and ranges that are updated as investigation progresses.
Hours four to twenty-four: assess likely consequences#
The notification decision should focus on risk to individuals, not only on the organisation's reputational or financial exposure.
Consider potential consequences such as:
- Identity theft, account takeover, fraud or financial loss.
- Discrimination, employment harm or denial of service.
- Exposure of sensitive information, location or vulnerable people.
- Physical safety risk, blackmail, phishing, distress or reputational harm.
- Loss of essential access, incorrect decisions or re-identification.
Assess the nature, sensitivity and volume of data; ease of identification; number and characteristics of individuals; likely threat actor; duration of exposure; containment; protective measures; and possible severity and reversibility of harm.
Use a simple Unlikely Risk, Risk or High Risk scale with a likelihood-and-severity rationale. Encryption is not an automatic exemption; effectiveness depends on implementation, key protection and whether plaintext access occurred.
By hour twenty-four: make a provisional notification decision#
The response team should aim to reach a documented provisional decision well before the deadline. Possible outcomes include:
- No personal data breach: Close the privacy assessment but retain the incident link and rationale.
- Personal data breach, unlikely risk: No supervisory-authority notification under Article 33, but document the breach and decision.
- Personal data breach, likely risk: Notify the competent supervisory authority.
- Personal data breach, likely high risk: Notify the authority and assess communication to affected individuals.
- Insufficient information: Continue urgent investigation and prepare a phased notification if the threshold is met or cannot be resolved in time.
Document every personal data breach, including facts, effects, remedial action and the non-notification rationale where applicable. Record the assessor, reviewer, DPO advice, approver, time and evidence.
Hours twenty-four to seventy-two: prepare and submit notification#
A supervisory-authority notification should be accurate, clear and consistent with the information available. Article 33 requires information including the nature of the breach, categories and approximate numbers of individuals and records, DPO or contact details, likely consequences and measures taken or proposed.
The workflow should support:
- Authority, jurisdiction and cross-border analysis.
- Drafting, review, approval and confidence levels for estimates.
- Submission channel, phased information and any reasons for delay.
- Receipt, reference number, follow-up questions and supplementary notices.
Do not delay solely because investigation is incomplete. Information can be supplied in phases; distinguish confirmed facts, estimates and pending work.
Current-law note: EU proposals have considered changes to the reporting threshold, channel and deadline. At the legal review date of this article, organisations should continue to configure the operative GDPR requirement as 72 hours unless and until an adopted amendment becomes applicable. This position should be reviewed again before publication following any material legal change.
Decide whether to communicate with individuals#
Communication to affected individuals is required where the breach is likely to result in a high risk, subject to the conditions and exceptions in Article 34. The purpose is to help people protect themselves, not merely to protect the organisation's reputation.
A communication should explain in clear language:
- What happened and when.
- What personal data was involved.
- The likely consequences.
- What the organisation has done.
- What the individual should do.
- How to obtain help or contact the DPO or response team.
- Whether further updates will follow.
Advice should be specific to the risk, such as resetting credentials, monitoring accounts, replacing documents or watching for targeted phishing. Define the affected population, channels, approval, accessibility, delivery evidence and follow-up. Obtain legal advice where direct communication may involve disproportionate effort.
Link the breach to the processing inventory#
A reliable RoPA accelerates breach assessment. Once a system, processor or dataset is identified, the team should be able to see associated processing activities, purposes, individuals, data categories, countries, retention rules, controls and owners.
This improves completeness because a processor event may affect several processes and entities, while one processing activity may use several systems. Link the breach to DPIAs, risks, controls, contracts, prior incidents and actions so repeat weaknesses are visible.
Preserve evidence and privilege appropriately#
A breach file may contain forensic reports, legal advice, screenshots, exported records, notification drafts and personal data. Apply strict access control and distinguish factual incident evidence from legally privileged advice according to applicable law.
Important evidence includes:
- Alert, timeline, logs and forensic artefacts.
- Data and population estimates with calculation methods.
- Containment, recovery, risk assessments and decision versions.
- DPO and legal advice.
- Authority and individual communications with delivery evidence.
- Processor communications, corrective actions and closure approval.
The application should record hashes or immutable metadata where appropriate, preserve version history and prevent silent replacement of submitted documents.
Close the incident only after learning is captured#
Notification does not close the breach. The organisation should identify root causes, control failures, missed warning signs and broader lessons.
Corrective actions may include access redesign, data minimisation, retention changes, configuration controls, monitoring, vendor remediation, contract changes, training, secure communication controls, incident-playbook updates or DPIA review.
Closure should require:
- Containment and final affected-person and record estimates.
- Required regulator and individual communications.
- Evidence reconciliation and corrective-action status.
- Updates to RoPA, risks, controls, DPIAs and processor assessments.
- Independent review, residual risk and accountable acceptance for material cases.
Some long-term actions may remain open after the incident record is operationally closed, but they must retain owners, dates and escalation.
Measure breach response performance#
Useful measures include:
- Time from occurrence to detection, escalation, decision and notification.
- Cases assessed after 72 hours.
- Breaches by type, system, processor, business unit and root cause.
- Individuals and records affected.
- Risk and high-risk decisions.
- Repeat incidents, control failures and overdue actions.
- Processor performance and decision-evidence completeness.
A low breach count does not necessarily indicate strong control. It may indicate under-reporting. Compare reporting volume with training, near misses, security events and control findings.
Common breach-response failures#
Common failures include waiting for complete forensic certainty, starting the clock when the DPO opens the case, assessing organisational rather than individual harm, failing to document non-notification, omitting phased updates and closing without fixing the cause. Early escalation, an explicit awareness decision, individual-focused risk assessment and linked remediation address these weaknesses.
Frequently asked questions#
What is a personal data breach under the GDPR?#
It is a security breach leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. It can affect confidentiality, integrity or availability.
Does every personal data breach need to be reported?#
No. Under the current Article 33 framework, supervisory-authority notification is not required where the breach is unlikely to result in risk to individuals. The breach and decision should still be documented.
When does the 72-hour period begin?#
It begins when the controller is aware of the personal data breach. Determining awareness is fact-specific, so the organisation should record the time and rationale.
What if all information is not available within 72 hours?#
A required notification should not be delayed solely for completeness. Information can be provided in phases without undue further delay, and late notification should include reasons for delay.
When must affected individuals be informed?#
Communication is generally required when the breach is likely to result in a high risk to individuals, subject to Article 34 conditions and exceptions. Obtain legal advice for the circumstances.
Should processor contracts contain a breach deadline?#
They should require notification to the controller without undue delay and define an operational target, contacts, minimum information and continuing cooperation that enables the controller to meet its obligations.
Related Vilfora guides#
- GDPR Compliance Management: Build an Evidence-Ready Privacy Programme
- Record of Processing Activities: A Practical RoPA Guide
- Data Subject Request Management: An End-to-End GDPR Workflow
- DPIA Process: How to Assess High-Risk Processing
- Data Privacy Risk Management: From Data Inventory to Breach Response
Authoritative references#
- GDPR Articles 33–34 and full legal text — EUR-Lex
- European Commission: What is a data breach and what to do
- European Data Protection Board: Personal data breach notification guidance
- European Commission: GDPR obligations
This article provides general information and implementation guidance. It is not legal advice. Organisations should obtain advice for their circumstances and verify current EU, national and sector-specific requirements.
