7.3 Incident Handling, Breach Response & Records
Key Takeaways
- An incident is any observed event that may compromise the confidentiality, integrity, or availability of personal data; a breach is an incident that results in unlawful or unauthorized access to, or loss of, personal data — every breach is an incident, but not every incident is a breach
- GDPR Article 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach, and Article 34 requires notification to affected data subjects without undue delay where the breach is likely to result in a high risk to their rights and freedoms
- HIPAA requires covered entities to notify affected individuals within 60 days of discovery of a breach of unsecured PHI, with notification to HHS OCR (and to prominent media outlets for breaches affecting 500+ residents of a state or jurisdiction)
- US state breach-notification laws vary by state in their definitions of personal information, harm thresholds, and timelines, but most require notice 'in the most expedient time possible and without unreasonable delay,' often within 30-90 days
- An incident register and contemporaneous records are the evidence regulators expect; the absence of documented containment, remediation, and notification steps is itself a compliance defect under the accountability principle
Incident vs. Breach — The Foundational Distinction
A security incident is any observed or suspected event that may compromise the confidentiality, integrity, or availability of personal data or information systems. A personal data breach (the GDPR term) or breach of security (the HIPAA and state-law term) is an incident that results in unlawful or unauthorized access to, acquisition of, use of, disclosure of, or loss of personal data.
The distinction is operational, not semantic. A phishing email that an employee reports but does not click is an incident — it may warrant investigation and awareness follow-up, but no personal data was accessed. A phishing email that the employee clicks, leading an attacker to exfiltrate a customer database, is a breach that triggers notification obligations. Misclassifying a breach as a non-breach incident is one of the most consequential errors a privacy program can make.
Incident-Response Phases
CIPM BoK competency VI.B expects the privacy manager to follow the organization's incident handling and response procedures. The phases below align with the NIST SP 800-61 incident-handling lifecycle, adapted to privacy operations.
| Phase | Privacy-Program Activities | Key Records to Maintain |
|---|---|---|
| 1. Detection & Reporting | Monitor logs, alarms, employee reports, vendor notices; intake through a single security/privacy incident channel | Incident ticket, source, reporter, time detected |
| 2. Triage & Risk Assessment | Engage the privacy team to review facts; assess scope, data types affected, number of individuals, jurisdictions involved, and risk to data subjects | Risk-assessment record, classification (incident vs. breach), preliminary scope |
| 3. Containment | Isolate affected systems, revoke credentials, block exfiltration paths, suspend compromised accounts | Containment actions taken, timestamps, who authorized each action |
| 4. Eradication & Remediation | Remove malicious artifacts, patch the vulnerability, reset affected credentials, implement compensating controls | Remediation steps, verification that the threat is removed |
| 5. Notification Decision & Execution | Determine notification obligations across all applicable jurisdictions; notify regulators, affected individuals, business partners, and (where required) law enforcement and media | Notification decisions, recipients, content, dates, and the legal basis for each decision to notify or not notify |
| 6. Recovery | Restore systems from known-good backups, validate integrity, resume normal operations | Recovery timeline, integrity checks, residual risk acceptance |
| 7. Post-Incident Review | Conduct a blameless retrospective; capture lessons learned and feed them back into the IR plan and controls (covered in Section 7.4) | Post-incident report, action items, owners, due dates |
The Privacy Team's Role
Under VI.B, the privacy team is engaged to review the facts, determine actions, and execute plans. This is more than being informed — the privacy team owns:
- The incident-vs-breach classification decision (with security and legal)
- The notification-trigger analysis across all jurisdictions where affected individuals reside and where the controller is established
- The risk assessment that drives the GDPR Article 34 'high risk' decision and the HIPAA 'risk of harm' assessment that can justify not notifying individuals for low-risk breaches of unsecured PHI
- Coordination with DPO, legal, communications/PR, customer support, and senior management
- The incident register entry and retention of all associated records
Breach Notification Triggers by Regime
| Regime | Notify Regulator | Notify Affected Individuals | Notable Mechanics |
|---|---|---|---|
| GDPR | Yes — supervisory authority within 72 hours of becoming aware (Art. 33), unless the breach is unlikely to result in a risk to data subjects' rights and freedoms | Yes — without undue delay where the breach is likely to result in a high risk to rights and freedoms (Art. 34); a public communication may substitute where individual notice is disproportionately burdensome | DPO is the contact point for the supervisory authority (Art. 37(1)(b)); records of all breaches must be maintained in an internal breach register (Art. 33(5)) regardless of notification |
| HIPAA | Yes — HHS OCR annually for breaches affecting fewer than 500 individuals; within 60 days for breaches affecting 500+ | Yes — within 60 days of discovery of a breach of unsecured PHI; for breaches affecting 500+ residents of a state, also notify prominent media outlets serving that state or jurisdiction | A breach of 'secured' PHI (encrypted to NIST standards or destroyed) is not a reportable breach; a risk-of-harm assessment may justify substituting notice in low-risk cases |
| US state breach laws | Variable — many states require AG notification (e.g., for breaches affecting a threshold number of residents) | Yes — 'in the most expedient time possible and without unreasonable delay'; many states specify outer limits (commonly 30-90 days; California requires 'most expedient time possible, without unreasonable delay') | Definitions of 'personal information' vary (some include biometric, health, login credentials); some states require credit-monitoring offers for breaches involving SSN |
| CCPA (data broker breaches) | CPPA and AG | Affected consumers | CCPA creates a private right of action for breaches of non-encrypted/non-redacted personal information attributable to a business's failure to implement reasonable security (Cal. Civ. Code 1798.150) |
The Internal Breach Register
GDPR Article 33(5) requires controllers to maintain a record of all personal data breaches, including the facts, effects, and remedial action taken — including breaches that are not notified to the supervisory authority. This internal register is the evidence an auditor or regulator will request. Best practice is to record every incident (not only confirmed breaches) in the same or a linked register, with the classification decision and rationale documented contemporaneously.
graph TD
A["1. Detect / Report"] --> B["2. Triage & Classify<br/>(incident vs. breach)"]
B --> C{"Personal data<br/>breach?"}
C -- "No: incident only" --> D["Contain, remediate,<br/>record in incident log"]
C -- "Yes: breach" --> E["3. Risk assessment<br/>(risk to data subjects?)"]
E --> F["4. Notify supervisory<br/>authority within 72h<br/>(unless unlikely to risk rights)"]
E --> G["5. Notify affected<br/>individuals if high risk<br/>(without undue delay)"]
F --> H["6. Record in internal<br/>breach register (Art. 33(5))"]
G --> H
D --> H
H --> I["7. Post-incident review<br/>(Section 7.4)"]
style A fill:#1e3a5f,color:#fff
style B fill:#2d5a87,color:#fff
style E fill:#c9a227,color:#1e3a5f
style F fill:#2d5a87,color:#fff
style G fill:#2d5a87,color:#fff
style H fill:#1e3a5f,color:#fff
style I fill:#2d5a87,color:#fff
Stakeholder Communication
Under VI.B, communication must comply with jurisdictional, global, and business requirements. Stakeholders may include:
- Affected individuals — clear, plain-language notice describing what happened, what data, what the organization is doing, and what the individual can do
- Supervisory authorities / regulators — formal notification within statutory deadlines
- Senior management and the board — especially for material incidents (SEC public-company disclosure rules apply to material cybersecurity incidents under Item 1.05 of Form 8-K)
- Business partners, processors, and sub-processors — contract flow-down obligations
- Law enforcement — where criminal activity is suspected
- Media — where required (HIPAA 500+ resident rule; some state laws)
- Customer support and sales teams — so they can respond consistently and not improvise statements that create legal exposure
A pre-approved breach-communication playbook with template notices (regulator, individual, partner, internal) reduces the risk of inconsistent or premature statements during the pressure of an active breach.
Worked Scenario
A SaaS company discovers on a Tuesday at 9:00 AM UTC that an exposed S3 bucket has been downloading customer records — names, emails, and hashed passwords — for an estimated 11 days. The cloud security team confirms exfiltration at 11:00 AM UTC on Tuesday. The company's main establishment is in the EU.
Correct handling: The 'became aware' moment for GDPR Article 33 starts when the controller has a reasonable degree of certainty that a breach has occurred — here, the 11:00 AM confirmation, not the earlier vague alert. The 72-hour clock for notifying the supervisory authority runs from that point, expiring Friday at 11:00 AM UTC. The privacy team performs the risk assessment: hashed passwords (depending on algorithm and salting) plus emails and names create a risk of credential stuffing and phishing; for a high-risk determination under Article 34, the team assesses whether individuals are likely to suffer harm. The team notifies the lead supervisory authority within 72 hours, prepares individual notifications (without undue delay) because the risk is likely high, mandates a password reset as a remediation step, and records the entire sequence in the internal breach register — including the facts, the timeline, the remediation, and the notification decisions and rationale.
What would be wrong: Waiting a week to 'fully investigate' before notifying the DPA (the 72-hour clock does not wait for a complete investigation — Article 33(4) allows phased notification); deciding not to notify individuals without documenting a documented risk assessment justifying non-notification; or failing to record the breach in the internal register because 'it was contained quickly.'
A controller becomes aware at noon on Monday that a personal data breach has occurred affecting EU customers. When is the latest the controller may notify the supervisory authority under GDPR Article 33, and what is the consequence of missing it?
A US hospital discovers on June 1 that an unencrypted laptop containing PHI of 700 patients was stolen on May 20. Under the HIPAA Breach Notification Rule, which notification obligation is correct?