Data breach notification for small teams — the 72 hours you spend deciding who to tell

A breach has two clocks running at once: the fix clock and the notification clock. Teams are built for the first and improvise the second — so the engineers contain the incident while the founders draft letters, and the letters go out late, wrong, or to the wrong audiences. Notification is not writing. It is a map with names and clocks on it, drawn in peacetime: who must hear what, within how many hours, from which owner, in which order. Regulators count from awareness, not from certainty; contracts often beat the law; and a notification record done right becomes evidence — in the next deal's questionnaire, the insurer's file, and the customer's trust.

The notification map, drawn before you need it

1. Regulators and supervisory authorities. GDPR: notify within 72 hours of awareness unless the breach is unlikely to risk rights and freedoms; record every breach anyway (the 72-hour clock starts at awareness, and “we were still investigating” is not an extension). US state breach laws: thresholds, formats, and AG-notice rules vary by state of residency — the map names which states your customers live in today. If you serve EU customers without an EU establishment, the lead-supervisory-authority question gets answered now, not during the incident.
2. Affected customers and users. Named owner, template, and channel chosen in peacetime (email plus a status page update beats a blog post nobody reads). The notice says what they should do, not just what happened.
3. Partners and processors, both directions. Downstream: your vendors whose data or systems touched the breach (contract clocks are often 24–48 hours and start on your awareness). Upstream: customers whose contract promises notification on their timetable — usually shorter than the law's. This row is why the vendor security review asks for incident-notification terms before signing.
4. Cyber insurer and counsel — before any external word. Policies routinely require prompt notice and approved counsel; the customer letter sent before the carrier is looped in can void coverage. This is the first call, not the last.
5. Banks and payment providers. If card or payment data may be touched, the PSP and acquiring bank have their own clocks and their own idea of “prompt.”
6. Employees — with a line to hold. Everyone gets one paragraph: what is public, what is not, and that all external questions route to one named spokesperson. The well-meaning engineer's LinkedIn thread is a second incident.
7. Status page and support macros. The public single source of truth, updated on a stated cadence, with support armed to link it instead of improvising.
8. The notification log. One row per notice: audience, owner, channel, sent-at, letter version. This log is the artifact every future questionnaire, audit, and insurer call asks for (the answer bank keeps the freshest answers one folder away).

What every notification contains

• What happened, in plain language. No topology, no CVEs, no internal codenames — answer the control, not the architecture (the same rule the answer bank uses).
• What data and when. Categories (not dumps), the window it was accessible, and honest uncertainty marked as uncertainty with a date it will be resolved.
• What you have done and what they should do. The reader's next action first: rotate this, watch that, call this number.
• How to reach a human and when the next update lands. A dated next-update commitment converts “we'll keep you posted” into something you can be held to — which is the point.

The five traps

• Waiting for perfect facts. The clock does not pause for the investigation to finish. Notice what you know when you know it; 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. The regulator needs facts and timelines, the customer needs actions, the partner needs contract-language, the insurer needs the incident narrative. Four audiences, four documents from one fact base — never one text forwarded four times.
• Editing the logs. The instinct to “tidy up” the audit trail before sharing turns an incident into spoliation. Preserve everything, write down what you changed and why, and let the blameless review sort causes later.
• Customers before insurer and counsel. Empathy says tell everyone immediately; the policy says the carrier approves the words. Empathy loses the coverage; the carrier approves the words.
• Notification as one-and-done. The first letter is the contract; the updates are the product. A breach handled with weekly dated updates ends with more trust than the quiet quarters before it — a breach with one letter and silence ends with churn you cannot measure until renewal.

Worked example

A twelve-person B2B SaaS. A contractor's reused password led to a support mailbox containing exports for ~400 customer records. Detection to severity call: 40 minutes (the severity matrix rated it P1 — customer data, external access). Hour 6: counsel and the cyber carrier engaged, words pending approval. Hour 41: regulator notice filed with the facts then known, marked as preliminary. Day 2: customer notice sent — what happened, what categories of data, the window, the rotations required, a named contact, and a dated next update; partners notified inside their 48-hour contract lane the same morning; status page carried the public version, support armed with one macro. Weekly dated updates until closure, five in total; the final one carried the after-action summary and the fixes (mailbox rule changes, contractor offboarding wired into the offboarding checklist, a quarterly access review).

The cost: two accounts churned. The return: three months later a procurement security review asked “describe your breach-notification process with evidence” — the answer was the log, the letters, and the timeline, pasted in ten minutes. The deal closed. The difference between an incident and a liability is usually not the breach; it is whether the notification map existed before the attacker did.

Metrics (for the notification program itself)

• Time from detection to severity call (target: under one hour — the clock starts here, and it is the only number fully in your control).
• Time from awareness to regulator notice where required (median, and 100% inside the legal window; near-misses logged as process gaps, not luck).
• Notification log completeness: 100% of notices have an audience, an owner, a channel, a timestamp, and a version.
• Next-update commitment met rate: 100% — a missed dated update costs more trust than the breach itself.
• Contract-notification adherence: zero partners learning about your incident from the news or from their own logs.

From the HIVE80lab kit

• The First 30 Minutes — free incident quick-start checklist
• Ops Starter Kit — incident response for small teams — $14
• Ops Starter Kit Vol. 2 — advanced incident response & communications — $27
• Ops Mega Bundle — all 5 kits in one download — $49

Related: the incident severity matrix is what decides when the notification clocks start; the ransomware recovery checklist runs in parallel — fix and notify are two tracks with one command; the phishing response checklist is the runbook for the credential-theft breaches behind most notifications; and the security questionnaire answer bank is where the notification log and letters live as evidence for the next deal.and the cyber insurance claim checklist is why the insurer is row four — the notification record and the cost ledger become the claim.