72-hour breach notification process documented

GDPR Art. 33 requires that a personal data breach be notified to the competent supervisory authority within 72 hours of the controller becoming aware of it — not 72 hours after they feel ready, not 72 hours after legal review, 72 hours flat. Without a documented breach notification procedure specifying who is responsible, what constitutes 'becoming aware,' and which supervisory authority is relevant, this deadline is structurally unachievable. Art. 34 separately requires notifying affected individuals without undue delay when the breach poses high risk to their rights. An organization that discovers a breach and has no runbook will spend the 72 hours figuring out process instead of executing it.

Create INCIDENT_RESPONSE.md at the repo root with a breach notification runbook that covers detection, containment, regulatory notification, and user notification.

# Data Breach Response — INCIDENT_RESPONSE.md

## Designated Incident Owner
Role: [Engineering Lead / CTO]
Contact: [email / Slack handle]

## Hour 0-1: Detect and Contain
- Assess scope: what data, how many users, attack vector
- Contain: rotate credentials, revoke tokens, isolate affected services

## Hour 1-72: Regulatory Notification (GDPR Art. 33)
- If breach "likely to result in risk" to data subjects: notify supervisory authority
  - UK: ico.org.uk/make-a-complaint/data-security-and-protection/report-a-breach
  - EU: find national DPA at edpb.europa.eu/about-edpb/members
- Required: data categories, approx. number of subjects, likely consequences, measures taken

## User Notification (GDPR Art. 34)
- Required when high risk to individuals' rights
- Email within 72 hours: describe what happened, data affected, actions taken, user steps

## Post-Incident
- Root cause analysis within 5 business days
- Document in incident log: date, scope, notifications sent, remediation

Ensure every team member knows who the incident owner is and how to reach them at any hour.

• ID: gdpr-readiness.breach-accountability.breach-notification

• Severity: low

• What to look for: Look for a data breach notification procedure or incident response plan. It may live in INCIDENT_RESPONSE.md, SECURITY.md, docs/breach-response.md, a Notion runbook, or be embedded in a broader security policy. At minimum, the procedure must specify: how a breach is detected, the internal escalation path (who is notified first and in what order), the regulatory notification requirement (GDPR Article 33: notify the competent supervisory authority within 72 hours of becoming aware of a breach), the user notification requirement (GDPR Article 34: notify affected individuals without undue delay when a breach poses high risk), and the designated person responsible for breach response. Count every required element of a breach notification plan (detection, assessment, DPA notification within 72 hours, data subject notification, documentation) and enumerate which are present.

• Pass criteria: A documented breach notification procedure exists covering: detection mechanism, internal escalation path, 72-hour regulatory notification (to the relevant supervisory authority), user notification requirements, notification content template, and a designated breach response owner. The privacy policy or security documentation provides a contact for reporting security issues. Report even on pass: "Breach notification plan covers X of Y required elements. DPA notification timeline: within 72 hours." At least 1 implementation must be confirmed.

• Fail criteria: No breach notification procedure documented anywhere. No defined escalation path. No indication of who is responsible for GDPR breach notifications or which supervisory authority is relevant.

• Skip (N/A) when: Application processes no personal data and is not subject to any privacy regulation (document this assessment explicitly).

• Cross-reference: The records-of-processing check verifies the processing records that inform breach impact assessment.

• Detail on fail: Example: "No breach notification procedure found. No documentation of who to contact, regulatory notification timeline, or user notification process in the event of a data breach.".

• Remediation: Create a minimal but complete breach notification runbook:

  # INCIDENT_RESPONSE.md — Data Breach Response
  
  ## Designated Incident Owner
  Role: [Engineering Lead / CTO / DPO]
  Contact: [email / Slack handle]
  
  ## Detection Sources
  - Sentry alerts (unusual error patterns, auth failures)
  - Database monitoring (unusual query volumes)
  - User reports (privacy@example.com)
  - Third-party vendor breach notifications
  
  ## Response Timeline
  
  ### Hour 0-1: Detect and Contain
  - Assess scope: what data, how many users, attack vector
  - Contain: rotate credentials, revoke tokens, isolate affected services
  - Notify incident owner immediately
  
  ### Hour 1-72: Regulatory Notification (GDPR Art. 33)
  - Determine if breach "likely to result in risk" to data subjects
  - If yes: notify relevant supervisory authority within 72 hours
    - UK: ico.org.uk/make-a-complaint/data-security-and-protection/report-a-breach
    - EU: edpb.europa.eu/about-edpb/about-edpb/members_en (find your national DPA)
  - Required details: data categories, approximate number of data subjects,
    likely consequences, measures taken to address the breach
  
  ### User Notification (GDPR Art. 34)
  - Required when breach poses high risk to individuals' rights
  - Email from privacy@example.com within 72 hours:
    "On [date], we discovered [description]. Your [data types] may have been accessed.
    We have [actions taken]. We recommend [user actions]. Contact privacy@example.com."
  
  ## Post-Incident
  - Root cause analysis within 5 business days
  - Update security controls to prevent recurrence
  - Document in incident log (date, scope, notifications sent, remediation)