Every post-mortem I read about a breach handled badly has the same sentence in it: "we were focused on containment." The engineers were right to focus there. The problem is that while containment ran, nobody owned the second clock — the notification clock — and by the time anyone picked it up, the regulator deadline was measured in hours, three partners had contract clauses ticking at 48, and the founder was drafting a customer letter at midnight with no idea whether the carrier was supposed to see it first.
Here is the reframe: breach notification is not a writing assignment. It is a legal clock with a routing table, and the routing table has to exist before the attacker does.
The map, drawn in peacetime
Eight rows. Each has an owner, a clock, and a template:
- Regulators and supervisory authorities. GDPR gives you 72 hours from awareness — not from the end of the investigation. "We were still digging" is not an extension. US state breach laws add thresholds and formats that vary by customer residency. If you have EU customers and no EU establishment, decide the lead-supervisory-authority question now.
- Affected customers and users. One named owner, one template, email plus a status-page update. The notice tells them what to do, not just what happened.
- Partners and processors, both directions. Downstream vendors whose systems touched the breach — contract clocks are often 24–48 hours and start on your awareness. Upstream customers with contractual notification windows shorter than the law's. This row is why vendor security reviews should ask for incident-notification terms before signing.
- Insurer and counsel — before any external word. Cyber policies routinely require prompt notice and panel counsel. The sympathetic customer letter sent before the carrier is looped in can void coverage. First call, not last.
- Banks and payment providers. If payment data may be touched, PSPs and acquirers have their own clocks.
- Employees — with a line to hold. One paragraph: what is public, what isn't, all external questions route to one named spokesperson. The engineer's helpful LinkedIn thread is a second incident.
- Status page and support macros. The public source of truth, on a stated update cadence, so support stops improvising.
- The notification log. One row per notice: audience, owner, channel, sent-at, version. This log is the artifact every future questionnaire, audit, and insurer file asks for.
What every notice contains
Four things, and the order matters:
- What happened, in plain language. No topology, no CVEs. Answer the control, not the architecture.
- What data, and when. Categories, not dumps. Honest uncertainty marked as uncertainty — with the date it will be resolved.
- The reader's next action first. Rotate this. Watch that. Call this number.
- A human to reach and a dated next update. "We'll keep you posted" is a shrug with a stamp. "Next update Thursday 17:00" is a commitment.
The five traps
- Waiting for perfect facts. The clock doesn't pause. The second letter — "what we now know" — is normal and expected. The missing first letter is what regulators fine and customers remember.
- One letter for everyone. Regulator needs timeline, customer needs actions, partner needs contract language, insurer needs narrative. Four documents, one fact base — never one text forwarded four times.
- Editing the logs. "Tidying up" the audit trail before sharing converts an incident into spoliation. Preserve everything, document what you touched, let the blameless review sort causes later.
- Customers before the carrier. Empathy says tell everyone immediately. The policy says the carrier approves the words. Empathy loses the coverage.
- One-and-done. The first letter is the contract; the updates are the product. Weekly dated updates until closure — five, in the example below — are where trust actually gets built back.
A worked example
Twelve-person B2B SaaS. A contractor's reused password opens a support mailbox holding exports for ~400 customer records.
- Detection to severity call: 40 minutes. The severity matrix rates it P1 — customer data, external access. The P1 hands off to the notification map.
- Hour 6: counsel and the cyber carrier engaged. Customer words pending carrier approval.
- Hour 41: regulator notice filed with the facts then known, marked preliminary.
- Day 2: customer letters out — what happened, data categories, the window, required rotations, a named contact, a dated next update. Partners notified inside their 48-hour contract lane the same morning. Status page public, support armed with one macro.
- Weeks 1–5: five dated updates, the last carrying the after-action summary and the fixes: mailbox rules, contractor offboarding wired into the offboarding checklist, quarterly access reviews.
The cost: two accounts churned. The return, three months later: a procurement security review asks to "describe your breach-notification process with evidence." The answer is the log, the letters, the timeline — pasted in ten minutes. The deal closes.
The difference between an incident and a liability is usually not the breach. It is whether the map existed before the attacker did.
The metric that matters most
Time from detection to severity call. Target: under an hour. It is the only number on the map that is entirely in your control — the legal clocks start whether you noticed or not.
The full page — the eight-row map, the notice contents, the traps, and the worked example — lives here: Data breach notification checklist for small teams. Related pages: the incident severity matrix that starts the clocks, the ransomware recovery checklist that runs in parallel, and the security questionnaire answer bank where the log and letters become evidence.
If you want the printable versions of the incident kit (checklists, comms templates, post-incident trackers), they're in the Ops Starter Kit — and Vol. 2 covers the communications side specifically.
Top comments (0)