Build Your 72-Hour Breach Response System

Your security team discovers unauthorized access to customer records at 9pm on a Friday. The clock starts. Under Article 33, you have 72 hours to notify your supervisory authority. What you do in those 72 hours determines whether you're demonstrating accountability or scrambling to explain why you're late.

After a full year of mandatory personal data breach reporting under GDPR, the pattern is clear: organizations that treat breach notification as an ad-hoc crisis response fail. Those that succeed have built repeatable systems before the breach happens.

This playbook walks you through building that system.

What You Need Before Starting

Team roles defined in writing:

• Breach coordinator (typically your data protection officer or designated privacy lead)
• Technical investigator (security engineer who can scope the incident)
• Legal reviewer (in-house counsel or external advisor familiar with Article 33/34)
• Communications lead (for external notifications if Article 34 applies)

Documentation templates ready:

• Breach notification form for your supervisory authority (most provide their own format)
• Internal breach log template (Article 33(5) requires you to document all breaches, even those you don't report)
• Data subject notification template (for Article 34 scenarios)
• Stakeholder communication template (board, executives, affected processors)

Technical access:

• Log aggregation system with at least 90 days retention
• Inventory of all processing activities (Article 30 records)
• List of processors with contact details and contractual breach notification obligations
• Encryption status for each data category (determines risk assessment)

Decision tree printed and posted: Create a one-page flowchart answering: Does this meet the Article 4(12) definition? Is there likely risk to rights and freedoms? Is there high risk requiring Article 34 notification?

Step-by-Step Implementation

Hour 0-2: Containment and Initial Assessment

Immediate actions:

1. Isolate affected systems (disconnect from network if necessary)
2. Preserve logs and forensic evidence before they rotate
3. Open your breach log entry with timestamp and initial reporter
4. Notify your breach coordinator

Document in parallel:

• What happened (initial description, no root cause yet)
• What data categories are involved (names, email, financial, health, etc.)
• Approximate number of data subjects affected
• Whether data was encrypted or pseudonymized

Don't wait for complete information. Your 72-hour clock started when you became aware of the breach, not when you finished investigating.

Hour 2-24: Investigation and Risk Assessment

Determine scope: Run queries against your processing records to identify:

• Which controllers are affected (if you're a processor, Article 33(2) requires you to notify the controller without undue delay)
• Which data subjects by jurisdiction (different supervisory authorities if you operate cross-border)
• What processing purposes were compromised

Assess the risk: Article 33(1) requires notification when there's "likely risk to rights and freedoms." Consider:

• Identity theft potential (credentials, financial data, identity documents)
• Discrimination or reputational damage (health records, political opinions, trade union membership)
• Financial loss (payment card data, bank details)
• Loss of confidentiality for pseudonymized data

If your assessment shows high risk, Article 34 requires direct notification to affected data subjects. High risk typically means: large-scale breach of sensitive data categories (Article 9), or breach enabling identity theft or fraud.

Check your mitigation factors:

• Was the data encrypted with keys stored separately? This often eliminates the need to notify.
• Have you taken measures that make misuse impossible (e.g., revoked all compromised credentials)?
• Would notification require disproportionate effort? (Article 34(3)(c) allows public communication instead)

Hour 24-48: Documentation and Notification Preparation

Complete your Article 33(3) notification:

Your supervisory authority notification must include:

1. Nature of the breach (unauthorized access, ransomware, misconfigured database, etc.)
2. Name and contact details of your DPO or breach coordinator
3. Likely consequences (be specific: credential stuffing risk, potential for phishing, etc.)
4. Measures taken or proposed (password resets, system hardening, monitoring)

If you don't have all information at hour 48, submit what you have and note that you'll provide additional details under Article 33(4). It's better to notify on time with partial information than to miss the deadline.

Draft data subject notifications if required:

Article 34 notifications must use "clear and plain language" and include the same elements as supervisory authority notifications, plus practical advice (change your password, monitor your credit report, enable two-factor authentication).

Hour 48-72: Submission and Stakeholder Communication

Submit to your supervisory authority:

• Use their online portal if available (most have dedicated breach notification systems)
• Keep confirmation receipt with timestamp
• Update your internal breach log with submission timestamp

Notify affected processors or controllers: If you're a processor, notify your controller clients immediately. If you're a controller using processors whose systems were breached, verify they've notified you per their Article 28(3)(f) obligation.

Brief your executive team: Provide a one-page summary covering: what happened, how many people affected, what you've notified, what comes next. Avoid technical jargon.

Validation: How to Verify It Works

Run a tabletop exercise quarterly: Give your team a realistic scenario (phishing compromise, ransomware, misconfigured S3 bucket). Walk through your playbook in real time. Can you complete the notification form in under 60 minutes?

Check your documentation:

• Review your Article 30 processing records monthly. If you can't identify affected data subjects quickly, your records aren't adequate.
• Verify processor contact details quarterly (email addresses change, security teams reorganize)
• Test your log retention (can you actually pull 90 days of access logs when you need them?)

Measure your response time: Track from detection to breach coordinator notification. If it's consistently over 4 hours, you need better alerting.

Maintenance and Ongoing Tasks

Update your breach log: Article 33(5) requires documentation of all breaches, even those below the notification threshold. Review monthly to identify patterns (repeated phishing success suggests training gaps, multiple access control failures suggest technical debt).

Refine your risk assessment: After each breach (yours or a peer's that's been made public), revisit your decision tree. Did your risk assessment hold up? Would you make the same notification decision?

Train new team members: Anyone in your breach response chain needs to know their role before the incident. Run a 30-minute orientation within their first week.

Review processor contracts annually: Verify Article 28(3)(f) breach notification obligations are specific (24-hour notification window, required information elements). Generic "without undue delay" clauses don't give you enough time to meet your own 72-hour deadline.

Track supervisory authority guidance: Notification requirements evolve. Subscribe to your supervisory authority's updates and adjust your templates accordingly.

The 72-hour deadline isn't negotiable, but it's achievable when you've built the system before you need it. Your breach response quality reflects your broader accountability posture. Get this right, and you're demonstrating the Article 5(2) accountability principle in action.