After the Breach Notice — A Practical First 72 Hours

Breach notices arrive at inconvenient hours. Slack lights up. Executives want certainty you do not have yet. The teams that fare best are not the ones with the flashiest SOAR dashboards — they are the ones with a boring, rehearsed first-72-hours script.

Hour 0–6: Stabilize without destroying evidence

Priorities, in order:

1. Identify the blast radius hypothesis — what systems might be involved, not what you wish were true.
2. Preserve volatile evidence — logs, memory snapshots, access tokens in flight.
3. Contain carefully — rotate keys, isolate hosts, revoke sessions. Avoid mass reimaging before forensics says so.

Hour 6–24: One narrative, many audiences

Appoint a single communications owner. Engineering updates feed that owner; they do not tweet independently.

Draft three parallel briefs:

• Internal eng — technical facts, open questions, owners
• Executive — customer impact, regulatory clock, decision asks
• Customer-facing — what happened, what you are doing, what they should do

Accuracy beats speed, but silence past a clear deadline becomes its own incident.

Hour 24–72: Hardening and follow-through

• Patch the root cause path, not just the symptom CVE
• Expand detection for related TTPs
• Start the post-incident timeline while memories are fresh
• Schedule the blameless review before people context-switch away

Day 0: contain + preserve
Day 1: communicate + deepen scope
Day 2: harden + document
Day 3: customer actions + regulatory path

Closing

Incidents reward preparation. Rehearse the first 72 hours when nothing is on fire — so that when something is, you are executing a playbook, not inventing one.