Hack Incident Response Playbook
A security incident compresses a year of reputational decisions into a few days. The technical response — containment, forensics, patching — belongs to your engineers and your auditors. This playbook covers the part teams are least prepared for: how to run communications, community and recovery around an incident without making the damage permanent. It is operational guidance, not legal advice; involve counsel early.
Hour 0 to 4: contain and centralise
Before anything is published, three things need to exist.
- A small response team. Founder or CEO, lead engineer, comms lead, legal counsel. Larger groups leak and move slower.
- One private channel and one decision log. Every decision, who made it and when. The log matters for the post-mortem, for insurers and for counsel.
- A hold on all scheduled content. Queued announcements publishing during an active incident have done real damage to otherwise recoverable situations.
Contact your auditor and, if funds moved, exchanges and analytics providers who can flag addresses. If the protocol has a pause function, the decision to use it belongs to engineering and counsel, not to comms.
The first public statement
Publish something within a couple of hours, even if you know very little. Silence is read as concealment, and the gap gets filled by whoever is watching the mempool.
A serviceable first statement contains four things and nothing else: what you have observed, what you have done so far, what users should or should not do right now, and when the next update will be published. Do not estimate losses before you can support the number, do not name a suspected cause before forensics, and do not say "no user funds are affected" unless you can currently prove it.
| Avoid | Use instead |
|---|---|
| "We are investigating an issue" | "At 14:20 UTC we observed unexpected withdrawals from contract X" |
| "We take security seriously" | "We have paused the vault and engaged [auditor] to review" |
| "Funds are safe" (unverified) | "We are still verifying balances; do not sign new approvals" |
| "More updates soon" | "Next update at 20:00 UTC" |
Days 1 to 3: cadence over content
Once the first statement is out, the job is a promise-and-keep loop. Announce a fixed update time and hit it, even when the update is "no change since the last one". Route everything through one channel and mirror it elsewhere, so there is a single canonical source people can check.
Practical items for this window:
- Tell users the specific protective actions to take — revoking approvals, withdrawing from a specific pool, ignoring impostor "refund" links.
- Expect phishing that impersonates your recovery process; publish your only official channels repeatedly.
- Brief partners, integrators and exchanges directly rather than letting them learn from social media.
- Keep moderators on a rota with a written line on what they may and may not confirm.
Days 4 to 14: post-mortem and visible fix
Two artefacts define how the incident is remembered.
The post-mortem should be technical and specific: timeline in UTC, root cause, why existing controls did not catch it, what changed, and what remains open. Vagueness here is what makes an incident a permanent reputational fact rather than a resolved one.
The visible fix is the shipped change — the patched contract, the new monitoring, the added review step, the re-audit scope. Announce it only after it is live.
If remediation or reimbursement is on the table, say what has been decided and what has not, and avoid promising amounts or dates before they are certain. Missed commitments after an incident compound the original damage.
Rebuilding trust afterwards
Normal marketing should resume only after the post-mortem is published and the fix is shipped; before that it reads as tone-deaf. When you do resume, lead with the security work rather than the roadmap: audit scope and results, monitoring, key management and process changes. The rugpull prevention checklist covers the trust signals users look for, and best crypto audit firms covers how to scope the review that follows.
Longer term, an incident changes what exchange review teams and partners ask about. Being able to point at a public post-mortem, a completed re-audit and a monitoring setup answers most of it — see the CEX listing tiers breakdown for what that diligence looks like.
Prepare before you need it
Most of this is far cheaper to prepare in advance: a named response team, a drafted holding statement, an auditor and counsel on retainer or at least on speed dial, a list of exchange and partner contacts, and a monitoring alert that reaches a human at 3am. Run a tabletop exercise once a quarter; the first time your team writes a public statement about an exploit should not be during one.
Talk it through
If you are preparing an incident response plan, or working through the communications side of one, book a strategy call.
🔗 Related reading from the Metamoonshots Journal
FAQ
How quickly should we make a public statement after an exploit?
Within a few hours, even if the statement only confirms what you have observed and when the next update will come. Silence during an active incident is consistently read as concealment.
Should we pause the protocol?
If funds are actively at risk and a pause function exists, that decision belongs to engineering and counsel and is usually taken immediately. For incidents with no fund risk, a pause signals a larger problem than exists.
What belongs in a post-mortem?
A UTC timeline, the root cause, why existing controls missed it, what has been changed, and what is still open. Technical specificity is what converts an incident from an open question into a closed one.
When can we resume normal marketing?
After the post-mortem is published and the fix is live. Resuming before those two things exist reads as an attempt to move past the incident rather than resolve it.