Operations
Crypto Incident Response Playbook Checklist
A printable crypto incident response playbook checklist gives the team a single sheet to classify the failure path, contain the active loss lane, preserve evidence, stand up communications, and recover. Print it before the incident so the first ten minutes are structure, not improvisation.
Direct answer
What the crypto incident response playbook checklist includes
A printable crypto incident response playbook checklist gives the team a single sheet to classify the failure path, contain the active loss lane, preserve evidence, stand up communications, and recover.
Cyproli recommends printing it before the incident so the first ten minutes are structure, not improvisation.
Cyproli recommends starting with the crypto incident response so the checklist maps onto the full incident-response framework.
Download / print
Within this package
Printable checklist
Crypto Incident Response Playbook Checklist
Work top to bottom. Every box is a pass/fail gate; a blank box means the incident is not ready for the next stage.
| Done | Phase | Check | Owner |
|---|---|---|---|
| Classify | Confirmed the incident with on-chain evidence and named the failure path (wallet, bridge, contract, or signer) | Security lead | |
| Classify | Moved coordination into a single incident channel with one incident commander | Incident commander | |
| Contain | Froze approvals, sessions, signer lanes, and automated execution paths that can still move value | Wallet ops | |
| Contain | Preserved transaction hashes, timestamps, affected wallets, and approval changes before any cleanup | Security + engineering | |
| Communicate | Opened the external communications lane and assigned a spokesperson separate from the incident commander | Comms lead | |
| Communicate | Published the first message checkpoint with containment status, not optimistic recovery language | Comms lead | |
| Assess | Mapped affected wallets, approvals, bridge routes, or contract privileges and confirmed scope is isolated or widespread | Engineering lead | |
| Assess | Confirmed no active loss lane remains and the incident is contained before any recovery step | Security lead | |
| Recover | Rotated exposed keys, sessions, and signer authority with a separated recovery lane | Security + engineering | |
| Recover | Validated that deployed frontends, relays, and monitoring match the verified build | Engineering lead | |
| Harden | Documented the incident timeline, decisions, and evidence for the postmortem | Incident commander | |
| Harden | Scheduled the postmortem and assigned owners to the gaps the incident exposed | Security + product |
Why Print a Crypto Incident Response Playbook Checklist at All?
The first ten minutes of a crypto incident are the highest-leverage window, and they are also when teams are least organized. A printable checklist forces the response to start with structure: classify, contain, preserve, communicate. Teams that improvise in that window routinely lose time to a second drain while they debate who owns the incident channel.
This checklist is the operational companion to the crypto incident response hub. The hub explains the incident types and decision rights; the checklist is the artifact you actually run under pressure. For the approval-driven variant of the same problem, pair it with the wallet drain playbook and the allowance revoke workflow.
Which Checks Are Easy to Skip Under Pressure?
Two gates are most commonly skipped, and both turn small incidents into expensive ones. Evidence preservation looks like it can wait because cleanup feels urgent. It cannot: cleanup destroys exactly the context that makes recovery and the postmortem possible. The second is separating communications authority from containment authority. The person stopping the loss is usually not the right person to reassure the public, and mixing the two delays both.
| Check | Why it is skipped | Failure it prevents |
|---|---|---|
| Preserve evidence before cleanup | Cleanup feels more urgent than logging | No recovery basis or postmortem context |
| Separate comms from containment | One person seems faster | Mixed incentives delay both lanes |
| Map scope before recovery | Recovery optimism overrides assessment | Second incident while reopening |
| Rotate trust before reopen | Reopening feels urgent | Compromised lane reactivates |
How Do These Checks Map to the Playbook Hub?
The checklist is deliberately short, so each row points back to the deeper runbook that explains why the check exists. The incident response hub owns classification and decision rights. The wallet drain playbook owns the wallet-specific containment lane. The emergency signer offboarding runbook owns the signer recovery lane, and the incident communication template owns the message checkpoints.
{
"checklist": "crypto-incident-response-playbook",
"phases": ["classify", "contain", "communicate", "assess", "recover", "harden"],
"gates": 12,
"next_action": "print-and-run-under-pressure"
}FAQ
Frequently Asked Questions
How do you use a crypto incident response playbook checklist?
Print it before the incident, then work top to bottom: classify the failure path, contain the active loss lane, preserve evidence, stand up communications, and only then move into recovery and hardening.
Should the same person run the checklist and decide recovery?
No. Fast incident command and cautious reopen authority need different incentives. Keep the incident commander on containment and evidence, and separate the authority that reopens the system.