GDPR Data Breach Notification: Timeline and Steps

When a personal data breach occurs, GDPR gives you 72 hours to notify your supervisory authority. Not 72 business hours — 72 actual hours, weekends and holidays included. That’s from the moment you become “aware” of the breach, which the European Data Protection Board defines as when you have a reasonable degree of certainty that a security incident has compromised personal data.

This isn’t a generous timeline. It means your breach response process can’t start with “let’s figure out who handles this” or “let’s schedule a meeting for Monday.” It needs to be a well-rehearsed playbook that your team can execute under pressure, at any hour, with clear roles and predefined communication channels.

This guide covers the legal requirements, the practical steps, and the documentation that SaaS companies need to have ready before a breach occurs.

What Counts as a Personal Data Breach?

GDPR defines a personal data breach as “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data.” This is broader than most people assume. It’s not limited to hacking incidents or external attacks.

Confidentiality breaches — Unauthorized access to or disclosure of personal data. An employee accessing customer records without a business justification. An email with personal data sent to the wrong recipient. A misconfigured API endpoint that exposes user data.

Integrity breaches — Unauthorized alteration of personal data. A database corruption that changes customer records. A software bug that overwrites user settings with another user’s data.

Availability breaches — Loss of access to personal data. A ransomware attack that encrypts your database. A failed migration that makes customer data inaccessible for an extended period. A hardware failure that destroys backups.

Not every security incident is a personal data breach. A DDoS attack that causes downtime but doesn’t affect personal data isn’t a breach. A failed login attempt isn’t a breach. But the line can be subtle — if a DDoS attack causes your monitoring systems to fail, and during that window an unauthorized access goes undetected, you may have a breach on your hands.

The Notification Framework

GDPR creates a two-tier notification system. Not every breach triggers both tiers.

Tier 1: Notify the Supervisory Authority (Article 33)

When required: For any personal data breach, unless the breach is “unlikely to result in a risk to the rights and freedoms of natural persons.”

In practice: The threshold is low. If personal data was exposed, accessed, or lost, and there’s any realistic scenario where a data subject could be harmed (identity theft, discrimination, financial loss, reputational damage, loss of confidentiality), you need to notify. The default should be to notify; only skip notification when you can genuinely demonstrate minimal risk.

Timeline: Within 72 hours of becoming aware of the breach. If you can’t provide full details within 72 hours (which is common for complex incidents), you can submit an initial notification and follow up with additional information in phases.

What to include in the notification:

1. The nature of the breach, including the approximate number of data subjects and data records affected
2. The name and contact details of your DPO or other contact point
3. A description of the likely consequences of the breach
4. A description of the measures taken or proposed to address the breach, including mitigation measures

How to notify: Each EU member state’s Data Protection Authority has its own notification mechanism — typically an online form on the DPA’s website. If you operate across multiple member states, notify the DPA in the country where your lead establishment is located. If you’re uncertain which DPA to contact, notify the DPA in the country where the most affected data subjects are located.

Tier 2: Notify Affected Data Subjects (Article 34)

When required: When the breach is “likely to result in a high risk to the rights and freedoms of natural persons.” This is a higher threshold than Tier 1. Not every breach reported to the DPA requires individual notification.

High risk scenarios include:

• Exposure of financial data (bank details, payment card numbers)
• Exposure of authentication credentials (passwords, security questions)
• Exposure of identity documents or national identification numbers
• Exposure of health or biometric data
• Exposure of data that could lead to discrimination (racial, political, religious data)
• Large-scale exposure of data that, in combination, enables identity theft

You don’t need to notify data subjects if:

• You had appropriate encryption or other protections in place that render the data unintelligible (e.g., the breached data was encrypted with a key that wasn’t compromised)
• You’ve taken subsequent measures that ensure the high risk is no longer likely to materialize
• Individual notification would involve disproportionate effort (in which case, make a public communication instead)

What to include: The notification must use clear, plain language and include:

• The nature of the breach
• The DPO’s or contact point’s details
• The likely consequences
• The measures taken or proposed, including steps the data subject can take to protect themselves

Building a Breach Response Plan

The 72-hour clock makes advance preparation essential. Here’s how to structure your breach response plan:

Define Roles and Responsibilities

Breach coordinator: A named individual (typically the DPO, CISO, or Head of Security) who owns the response process from detection to resolution.

Incident response team: Define who needs to be involved:

• Security/engineering team (investigation and containment)
• Legal counsel (notification obligations, liability assessment)
• Communications (data subject notifications, public statements)
• Management (strategic decisions, resource allocation)
• Customer success (if customer data is affected)

Escalation paths: Define how to reach each team member outside business hours. A breach at 11 PM on Friday can’t wait until Monday’s standup.

Establish Detection and Reporting Channels

Internal reporting: Every employee should know how to report a suspected breach. Create a dedicated channel — a Slack channel, an email alias, or an incident management form — and ensure it’s monitored continuously.

External reporting: Your vendors and processors should notify you promptly when they experience a breach that affects your data. Review your DPAs to ensure breach notification clauses include specific timeframes.

Automated detection: Implement monitoring for anomalous access patterns, unusual data exports, failed authentication spikes, and unauthorized configuration changes.

Create Response Templates

Prepare templates in advance for:

• Supervisory authority notification (following the DPA’s form format)
• Data subject notification email (plain language, no jargon)
• Internal status update format
• Press statement (for high-profile breaches)

Draft these when you’re calm and can think clearly — not during the chaos of an active incident.

Practice the Process

Run tabletop exercises at least annually. Present a realistic breach scenario and walk through the response process:

• Who gets notified first?
• How do you assess the scope?
• Who drafts the DPA notification?
• How do you determine if data subjects need to be notified?
• What if the breach involves a processor, not your own systems?

These exercises expose gaps in your plan before a real breach does.

The Breach Response Timeline

Hour 0–4: Detection and Initial Assessment

• Confirm that a personal data breach has occurred (vs. a security incident that doesn’t involve personal data)
• Identify the type of breach (confidentiality, integrity, availability)
• Begin containment measures immediately
• Activate the incident response team
• Start the breach log

Hour 4–24: Investigation and Scoping

• Determine what data was affected (types, volume, categories of data subjects)
• Identify how the breach occurred
• Assess whether the breach is contained or ongoing
• Evaluate the risk to data subjects
• Begin preparing the DPA notification

Hour 24–48: Decision and Drafting

• Decide whether DPA notification is required (when in doubt, notify)
• Decide whether data subject notification is required
• Draft the DPA notification with all required elements
• Prepare data subject notification if needed
• Brief senior management

Hour 48–72: Notification

• Submit the DPA notification (even if incomplete — you can supplement later)
• Send data subject notifications if required
• Document all actions taken and decisions made
• Continue investigation and remediation

Post-Incident: Resolution and Review

• Complete the investigation
• Implement measures to prevent recurrence
• Submit supplementary information to the DPA if the initial notification was incomplete
• Conduct a post-incident review
• Update your breach response plan based on lessons learned
• Update your breach register

The Breach Register

Article 33(5) requires you to document all personal data breaches — not just those you reported to the DPA. Your breach register should record:

• The facts of the breach (what happened, when, how)
• The effects (what data was affected, how many data subjects)
• The remedial actions taken
• Your risk assessment and notification decisions (including the reasoning if you decided not to notify)

This register serves as evidence of your accountability. When a supervisory authority audits your breach handling, they’ll want to see this record.

Processor Breach Obligations

If you’re a processor and you discover a breach affecting controller data, Article 33(2) requires you to notify the controller “without undue delay.” Your DPA should specify a more precise timeframe.

As a processor, you don’t typically notify the DPA directly — that’s the controller’s responsibility. But you must:

• Inform the controller promptly
• Provide all information the controller needs for their notification
• Assist with investigation and remediation
• Document the breach in your own records

How GRCTrail Helps with Breach Response

GRCTrail provides the infrastructure for organized, documented breach response:

Incident tracking. Log breaches with structured data — type, scope, timeline, affected data categories — and track them through investigation, notification, and resolution.

Evidence management. Every action during breach response is timestamped and logged. Build an auditable record of your response without scrambling for emails and chat messages after the fact.

Audit trail. Demonstrate to supervisory authorities exactly what you did, when you did it, and why you made the decisions you did. The accountability principle demands documented evidence, not just good intentions.

Connected to your compliance program. Your breach response connects to your ROPA, your DPAs, and your risk assessments. Understanding which processing activities and vendors are involved in a breach is immediate.

Build your breach response capability →

Related Guides

• GDPR Compliance Checklist — The full compliance framework
• GDPR Fines and Penalties — What non-compliance costs
• Data Protection Impact Assessment (DPIA) — Identifying risks before breaches occur
• Data Processing Agreements (DPA) — Vendor breach notification obligations
• ISO 27001 Incident Management: Requirements and Response Framework — Aligning breach response with ISO 27001

Get started with GRCTrail →