GDPR Incident Response Plan Template

Standard Operating Procedure: GDPR Personal Data Breach Incident Response Plan

1. Document Control Block

---

2. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the operational, technical, and legal protocols for detecting, containing, assessing, and notifying personal data breaches pursuant to Regulation (EU) 2016/679 (General Data Protection Regulation - GDPR).

The purpose of this document is to establish a rigorous, repeatable framework that ensures compliance with Article 33 (Notification of a personal data breach to the supervisory authority) and Article 34 (Communication of a personal data breach to the data subject). Adherence to this SOP minimizes regulatory exposure, mitigates organizational risk, and preserves data subject rights.

---

3. Scope & Prerequisites

Scope

• Applicability: All systems, environments, third-party processors, and personnel handling European Union (EU) resident personal data within the operational jurisdiction of Template Registry.
• Trigger Events: Any unauthorized access, exfiltration, alteration, destruction, or loss of availability of personal data processed by or on behalf of Template Registry.

Prerequisites & Required Tools

• Incident Management Platform: PagerDuty / Jira Service Management.
• Forensic & Logging Tooling: Datadog, AWS CloudTrail, Splunk Enterprise Security, or equivalent SIEM.
• Communication Channels: Out-of-band encrypted messaging (Signal / PGP-encrypted email) for crisis leadership.
• Legal Framework Access: DPO contact matrix, template notification portals for relevant Supervisory Authorities (SAs).

---

4. Roles & Responsibilities

---

5. Step-by-Step Procedure

Phase 1: Detection, Triage, and Verification (0–1 Hour)

• Receive telemetry alert, vulnerability report, or whistle-blower notification indicating a potential data exposure.
• Open a high-priority incident ticket in the secure ticketing system and page the on-call Incident Commander (IC).
• Verify the authenticity of the alert and determine whether personal data (Art. 4(1) GDPR) was impacted.
• Isolate affected network segments, revoke compromised IAM credentials, or spin down compromised microservices to halt ongoing exfiltration.

Phase 2: Containment and Eradication (1–4 Hours)

• Preserve forensic integrity: Capture memory dumps, ephemeral container logs, and block-level storage snapshots of compromised systems.
• Execute containment playbooks (e.g., firewall rule enforcement, egress traffic blocking, API rate-limiting).
• Identify the vector of compromise and patch underlying infrastructure vulnerabilities.
• Verify that unauthorized access vectors have been fully severed and internal integrity checks pass.

Phase 3: Risk Assessment and DPO Escalation (4–12 Hours)

• Compile the Initial Assessment Report detailing:
  • Nature and categories of personal data affected (e.g., financial, medical, PII).
  • Approximate volume of data subjects impacted.
  • Likely consequences of the breach (e.g., identity theft, financial loss, reputational damage).
• Convene the Incident Response Team (IRT) and formally brief the Data Protection Officer (DPO).
• Evaluate the risk threshold: Determine if the breach poses a "risk to the rights and freedoms of natural persons."

Phase 4: Regulatory Notification & Data Subject Communication (12–72 Hours)

• If risk threshold is met: Draft the Article 33 notification for submission to the Lead Supervisory Authority within the mandatory 72-hour window.
• Ensure the supervisory authority notification contains, at a minimum:
  • Description of the nature of the personal data breach.
  • Name and contact details of the DPO.
  • Likely consequences of the breach.
  • Measures taken or proposed to mitigate the breach.
• If "high risk" to data subjects is determined (Art. 34): Prepare direct, clear, and plain-language communications to affected data subjects without undue delay.

Phase 5: Post-Incident Review and Remediation (T+72 Hours onward)

• Conduct a blameless Post-Mortem / Root Cause Analysis (RCA) with engineering and security stakeholders.
• Implement architectural hardening recommendations issued during the RCA.
• Update internal registers of processing activities and document the incident in the internal Data Breach Log (mandatory under GDPR accountability principle, Art. 5(2)).
• Close the incident ticket and archive all forensic artifacts in secure, access-controlled cold storage.

---

6. Quality Assurance & Pro-Tips

Best Practices

• Never Delay Containment for Forensics: While data preservation is critical, real-time containment takes precedence to prevent continuous data loss.
• Clock Management: Treat the 72-hour GDPR clock as starting the exact moment an indicator of compromise (IoC) is verified as a personal data breach, not when the investigation concludes.

Common Pitfalls

• Underestimating Scope: Assuming a compromised database contains only test data without validating production staging environments.
• Premature Public Disclosure: Releasing external statements before the DPO and legal counsel have validated the technical facts against jurisdictional notification thresholds.

Metric Thresholds

• Mean Time to Detect (MTTD): < 15 minutes for critical infrastructure anomalies.
• Mean Time to Contain (MTTC): < 60 minutes from verification of a data breach.
• Regulatory Notification Compliance: 100% of qualifying breaches notified to the SA within < 72 hours.

---

7. Frequently Asked Questions

Q: What constitutes a "risk to the rights and freedoms" requiring notification to the Supervisory Authority?
A: A risk exists if the breach may result in physical, material, or non-material damage to the data subjects, such as discrimination, identity theft, financial loss, damage to reputation, or loss of confidentiality protected by professional secrecy. If there is any reasonable probability of such harm, err on the side of notification.

Q: Does every security incident involving our infrastructure trigger a GDPR notification?
A: No. If the incident involves data that is robustly encrypted (utilizing state-of-the-art cryptographic standards with keys stored completely isolated from the ciphertext) and the encryption keys remain uncompromised, the data is rendered unintelligible, and it does not legally constitute a reportable personal data breach under GDPR Article 34(3)(a).