GDPR 72-Hour Breach Notification: The Process in Practice

The full executive answer

The clock starts at detection, so the first honest thing to say is what detection looks like for us: error monitoring via Sentry, the append-only audit trail with SIEM-exportable severity scoring on anomalous actions, weekly external scans, and platform alerts from our infrastructure providers, who carry their own contractual notification duties to us. On discovery, our incident-response runbook runs: contain (rotate the affected credential — minutes, not days — or disable the affected surface), assess scope using the audit trail (which, being tamper-evident, tells us exactly which organisations and records were touched — this is where the hash chain earns its keep), and classify severity.

Notification is where we've built more than most: incident management with jurisdiction-aware notification deadlines is literally a module in our platform — it tracks per-incident whether notification is required, the deadline, and flags "imminent" and "overdue" states, because we sell this discipline to boards and therefore must live it. As a processor under GDPR Article 33(2), our duty is to notify affected customers as controllers without undue delay so your own 72-hour clock to the supervisory authority starts with maximum runway; the customer-facing channel is direct notification to your named contacts plus our public status page for service-level transparency.

Honest maturity statement: the runbook exists, the tooling exists, but we are pre-launch — this process has never run against a real breach, and there is no incident history to show you, which cuts both ways (nothing to disclose, nothing battle-tested). The compensating commitments are contractual: a defined notification SLA to you in the DPA — we'll commit to 24 hours for confirmed personal-data breaches, well inside the regulatory 72 — and a post-incident report obligation. Tabletop exercises to pressure-test the runbook are scheduled as part of SOC 2 readiness this year.