3.2 Technical Support for Privacy Incident and Breach Response
Key Takeaways
A GDPR personal data breach is a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data; it can affect confidentiality, integrity, or availability.
Controllers must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals (GDPR Article 33).
Individuals must be told without undue delay when a breach is likely to result in a high risk, unless, for example, the data was rendered unintelligible by encryption whose key was not compromised (Article 34).
NIST SP 800-61 Revision 3 (April 2025) frames incident response through the NIST Cybersecurity Framework 2.0 functions rather than the older four-phase life cycle.
Scoping depends on the data inventory: without knowing which fields, people, and jurisdictions a system holds, teams cannot meet notification deadlines accurately.
3.2 Technical Support for Privacy Incident and Breach Response
Quick Summary: Legal teams decide whether and whom to notify; privacy technologists supply the facts those decisions depend on. That means detecting the incident, preserving evidence, containing the damage, working out exactly which data elements and which individuals were affected, and checking whether safeguards such as encryption make notification unnecessary. The clock starts when the organization becomes aware, so preparation decides the outcome.
The BoK asks technologists to "provide technical privacy support to identify and respond to privacy breaches and other types of incidents." That support begins long before an incident, with logging, inventories, and rehearsed runbooks.
Incidents, Breaches, and Privacy Events
Not every incident is a breach, and not every privacy incident involves an attacker.
- Security incident: an occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of a system or its data.
- Personal data breach (GDPR Article 4(12)): "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." European guidance classifies breaches as confidentiality breaches (unauthorized disclosure or access), integrity breaches (unauthorized alteration), and availability breaches (loss of access or destruction, such as ransomware that encrypts the only copy).
- Privacy incidents without an external attacker: an email sent to the wrong recipients, a misconfigured storage bucket, an employee browsing records without a business need, or an analytics SDK collecting data the notice never mentioned. Many of these still meet the breach definition because they are accidental disclosures.
The Incident Response Life Cycle
NIST SP 800-61 Revision 3, published in April 2025, replaced the 2012 Revision 2. Instead of the older four-phase cycle (preparation; detection and analysis; containment, eradication, and recovery; post-incident activity), Revision 3 presents incident response as a Community Profile of the NIST Cybersecurity Framework (CSF) 2.0, spreading activities across the functions Govern, Identify, Protect, Detect, Respond, and Recover. The practical steps for a privacy technologist remain recognizable:
1. Prepare
- Maintain a data inventory and lineage so you can answer "what was in that system?" within hours.
- Keep logs that show who accessed what and when, retained long enough to investigate (but minimized and protected, because logs are personal data too).
- Write runbooks for common scenarios: misdirected email, exposed bucket, compromised credentials, ransomware, vendor breach.
- Run tabletop exercises that include legal, communications, and the DPO, and time how long scoping takes.
2. Detect and Analyze
Detection sources include intrusion detection and data loss prevention alerts, anomaly detection on query volumes, vendor notices, bug bounty reports, and complaints from customers. Confirm the facts quickly but carefully; the GDPR clock runs from when the controller has a reasonable degree of certainty that a breach occurred.
3. Contain and Preserve Evidence
Containment steps include rotating credentials and keys, disabling a leaking API, making a public bucket private, revoking OAuth tokens, and asking an unintended recipient to delete an email and confirm in writing. Preserve evidence before wiping systems: snapshot affected hosts, export logs, and record a chain of custody so investigators and regulators can rely on the findings.
4. Scope the Personal Data
This is where privacy technologists add the most value. For each affected system, determine:
- Data elements: names, contact details, government identifiers, financial account numbers, health data, credentials, precise location, children's data.
- Population: the number of individuals, de-duplicated across systems, and their jurisdictions (which determine which laws apply).
- Protection status: was the data encrypted at rest, and was the key also exposed? Was it pseudonymized, and was the mapping table safe?
- Exposure: was the data actually accessed or exfiltrated, or only exposed? Access logs can sometimes prove no one downloaded an exposed file.
5. Support the Notification Decision
Counsel weighs the risk to individuals. European guidance lists factors such as the type of breach, the nature, sensitivity, and volume of data, how easily people can be identified, the severity and permanence of consequences, special characteristics of the individuals (for example, children), and the number affected.
6. Recover and Learn
Fix the root cause, verify the fix, update risk registers and DPIAs, and feed lessons into standards and training. Under GDPR Article 33(5), controllers must document every personal data breach, including ones they decide not to notify.
Notification Timelines Technologists Must Know
| Regime | Who Must Be Told | Deadline |
|---|---|---|
| GDPR Article 33 | Supervisory authority | Without undue delay and, where feasible, within 72 hours of becoming aware, unless unlikely to result in a risk; reasons for any delay must accompany a late notice |
| GDPR Article 33(2) | Processor to controller | Without undue delay after the processor becomes aware |
| GDPR Article 34 | Affected individuals | Without undue delay when the breach is likely to result in a high risk; not required if data was unintelligible (for example, strongly encrypted with an uncompromised key), if later measures removed the high risk, or (with a public notice instead) if individual notice would involve disproportionate effort |
| NIS2 Directive (EU) | National authority or CSIRT, for essential and important entities | Early warning within 24 hours of becoming aware of a significant incident, notification within 72 hours, final report within one month |
| U.S. state breach laws | Residents, and often the state attorney general | All 50 states have laws; deadlines range from "most expedient time possible" to fixed limits such as 30, 45, or 60 days; most exempt encrypted data if the key was not compromised |
| HIPAA Breach Notification Rule | Individuals; HHS; media for large breaches | Individuals without unreasonable delay and no later than 60 days after discovery; breaches affecting 500 or more residents of a state also require media notice |
| SEC Form 8-K Item 1.05 | Investors (public companies) | Within four business days after determining a cybersecurity incident is material |
Why Encryption Changes the Outcome
If stolen data was encrypted with a strong algorithm and the key was stored separately and not compromised, GDPR Article 34(3)(a) relieves the controller of notifying individuals, and most US state laws exclude encrypted data from their breach definitions. This "safe harbor" disappears if the key was on the same compromised server. Recording key custody in the inventory lets responders answer this question in minutes.
A hospital's ransomware attack encrypts its only copy of a patient scheduling database for two days. No data appears to have been copied out. Under GDPR, how is this best classified?
As a breach only if the attackers publish the data on a leak site
As an integrity breach only, because the files were altered by encryption
As an availability breach, since personal data became unavailable through a security breach
Not a breach, because a personal data breach requires that an unauthorized person view or copy the data
A processor's engineer discovers on Monday morning that a misconfigured storage bucket exposed a controller's customer files. What is the processor's obligation under GDPR Article 33?
Wait until forensic analysis confirms whether files were downloaded before telling anyone.
Notify the controller without undue delay so that the controller can assess and make its own notifications.
Notify the affected customers first, then tell the controller once the customers have been informed within 72 hours.
Notify the lead supervisory authority directly within 72 hours on the controller's behalf.
A laptop containing a customer export is stolen. Which fact would most strongly support a conclusion that individual notification is not required under GDPR Article 34?
Investigators believe the thief is interested only in reselling the hardware and will wipe the disk.
Strong full-disk encryption protected it, and the key was not with the device.
The company has cyber insurance that covers notification costs.
The export contained only 900 customers rather than tens of thousands, so the overall risk is limited.
Sections you finish are checked off in the contents.