← All policies

Incident Response Runbook

Owner: Lauren ten Hoor (Founder, sole director, designated Data Protection Officer) Last reviewed: 2026-04-30 Next review: 2026-10-30 (every 6 months) Test cadence: annual tabletop walkthrough

Scope

Covers any security incident affecting Cadences.work systems or customer data, including but not limited to:

• Unauthorized access to or disclosure of customer personal data
• Loss of integrity (tampering, ransomware) of customer data
• Loss of availability (>1 hour outage of the production environment)
• Compromise of an admin credential (Vercel, Supabase, GitLab, domain registrar, email, Postmark, OpenAI)
• Compromise of a sub-processor that affects Cadences customer data (notified to us)
• Lost or stolen device with persistent access to production systems
• Confirmed exploitation of a vulnerability in our codebase

Severity classification

Roles (single-person org)

Lauren holds all roles. When applicable, an external advisor (legal counsel and/or fractional CISO) may be engaged on retainer.

Phases

1. Detection & triage (target: <1 hour from first signal)

Detection sources:

• Monitoring alerts (Vercel, Supabase, Sentry/equivalent)
• Customer report (security@cadences.work)
• Researcher / external disclosure (SECURITY.md)
• Sub-processor breach notification
• Personal observation (suspicious login, unusual log entries)

Initial actions:

1. Open an incident record (docs/compliance/incidents/<YYYY-MM-DD>-<short-name>.md) — copy the template at docs/compliance/incidents/_template.md.
2. Assign severity (above).
3. Note the time of first signal — this starts the 72-hour GDPR notification clock.
4. Notify any external advisor on retainer.

2. Containment (target: <4 hours for SEV-1/SEV-2)

Goal: stop the bleeding. May not be the permanent fix.

Containment patterns:

• Compromised admin account: force password reset; rotate API keys for all services that account had access to; revoke active sessions; review audit logs for actions taken under that account.
• Suspected database compromise: capture a forensic snapshot; consider read-only mode (Supabase: revoke service role keys, set RLS to deny); isolate from external networks if possible.
• Vulnerable dependency in production: roll back to last known-good deployment; or hotfix-deploy a patched version.
• Sub-processor breach: assume customer data may be exposed via that processor's blast radius; notify customers per §4 once scope is clear.

3. Eradication & recovery

• Patch the root cause.
• Rotate all credentials potentially exposed.
• Restore from clean backup if data integrity is in doubt (Supabase PITR — RPO 2 minutes, RTO ~30 minutes; documented in BCP).
• Verify service is functioning end-to-end before opening to traffic.

4. Notification

4a. To customers (if their data is affected)

Sent without undue delay after the breach is confirmed. Channel: email to the primary admin contact + status banner in-app. Use the template at docs/compliance/templates/customer-breach-notification.md. Must include:

• Nature of the incident (categories of data, approximate volume)
• Likely consequences
• Measures we are taking
• Recommendation for customer actions
• Contact for questions

4b. To EU supervisory authorities (GDPR Art. 33)

Required within 72 hours of becoming aware, unless the breach is unlikely to result in risk to individuals' rights and freedoms.

Lead supervisory authority: determined by the customer's location. Most likely the customer's local DPA (e.g. Autoriteit Persoonsgegevens in NL, CNIL in FR). The EU representative (once appointed) coordinates this.

Use the EDPB notification template or the relevant DPA's online form.

4c. To Singapore PDPC (PDPA s.26B/D)

Required within 72 hours if the breach affects ≥500 individuals OR is likely to result in significant harm. Submit via the PDPC data breach notification form.

4d. To affected individuals (GDPR Art. 34)

Required if the breach is likely to result in high risk to their rights and freedoms — unless we have implemented measures that render the data unintelligible (e.g. encryption with keys not exposed). Channel: email or in-app notification.

5. Post-incident review (within 14 days of resolution)

• Write a post-mortem in the incident record. Blameless format: timeline, root cause, what worked, what didn't, action items.
• Update this runbook if any procedural gap surfaced.
• Update the risk register.
• File the resolved incident in docs/compliance/incidents/.

Notification timeline cheatsheet

Contact log

Pre-populated contacts to call/email during an incident.

Tabletop exercise

Conducted annually. Suggested 2026 scenario: "An attacker phishes Lauren's GitLab credentials, MFA is bypassed via a session-token theft, and an unauthorized commit deploys malicious code to production." Walk through detection, containment, customer notification, and post-mortem. Record findings in docs/compliance/incidents/exercises/.