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.