GDPR Art. 33 requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach — a hard deadline that cannot be met without a pre-existing response plan. Art. 34 requires notification to affected individuals when the breach is likely to result in high risk. NIST CSF 2.0 RS.RP-01 and ISO-27001:2022 A.5.26 both mandate documented incident response procedures. In practice, the 72-hour GDPR window passes faster than teams without a plan expect: stakeholder identification, breach scoping, legal review, and regulatory filing all compete for the same hours. Discovering the playbook gap in the middle of an incident guarantees regulatory notification failure.
Low severity at detection time, but the absence of a plan converts any future breach into a near-certain regulatory notification failure with enforceable consequences under GDPR Art. 83.
Create INCIDENT_RESPONSE.md at the project root with at minimum the detection method, internal escalation chain, the 72-hour regulatory notification target, and the user notification template.
# INCIDENT_RESPONSE.md
## Detection
- Automated: Sentry error alerts, unusual DB query spikes, auth failure bursts
- Manual: User reports, security researcher disclosure, third-party notification
## Triage (within 1 hour)
- Incident owner: [Engineering Lead]
- Assess: what data, how many users, how accessed
- Contain: rotate compromised credentials, revoke tokens, isolate affected services
## Regulatory Notification (GDPR: within 72 hours)
- Authority: national supervisory authority (e.g., ico.org.uk for UK)
- Report: breach nature, data categories, estimated user count, consequences, measures taken
## User Notification (within 72 hours when high risk)
- Channel: email from support@example.com
- Content: what happened, what data, what we have done, what users should do
## Post-Incident
- Root cause analysis within 5 business days
- Update controls; document in incident log
ID: data-protection.compliance-documentation.incident-response-plan
Severity: low
What to look for: Enumerate every relevant item. Look for an incident response plan or breach notification procedure. It may live in security documentation, an INCIDENT_RESPONSE.md, a runbook, a Notion page referenced from the README, or embedded within a broader security policy document. At minimum, the plan should specify: how a breach is detected (monitoring, alerts, user reports), the internal escalation process (who gets notified first), the regulatory notification requirement (72 hours for GDPR supervisory authorities), the user notification method and template, and who is responsible for each step.
Pass criteria: At least 1 of the following conditions is met. A documented incident response plan exists specifying: detection process, internal escalation (who to notify, in what order), regulatory notification (72 hours for GDPR, or as required by applicable law), user notification method, and designated incident owner or role.
Fail criteria: No incident response plan documented anywhere in the project.
Skip (N/A) when: Application is not subject to any privacy regulation and processes no personal data (extremely rare).
Detail on fail: Example: "No incident response plan found. No documentation of how a data breach would be detected, escalated, or reported to regulators or users.".
Remediation: Create a minimal but actionable incident response plan. A one-page document is better than nothing:
# INCIDENT_RESPONSE.md
## Data Breach Response Plan
### Detection
- Automated: Sentry error alerts, unusual DB query patterns, auth failure spikes
- Manual: User reports, security researcher disclosure, third-party notification
### Triage (within 1 hour)
- Incident owner: [Engineering Lead name/role]
- Assess scope: what data, how many users, how accessed
- Contain: rotate compromised credentials, revoke tokens, isolate affected services
### Notification: Regulators (within 72 hours if GDPR applies)
- EU Supervisory Authority: [ico.org.uk for UK; your national DPA for EU]
- Report: nature of breach, categories of data, approx number of users affected,
likely consequences, measures taken
### Notification: Affected Users
- Send email from support@example.com within 72 hours
- Include: what happened, what data was affected, what we've done, what users should do
### Post-Incident
- Root cause analysis within 5 business days
- Update security controls to prevent recurrence
- Document in incident log