55% of Web3 Teams Have No Incident Response Playbook (Here's Yours)

TL;DR

• 55% of Web3 teams have no incident response playbook, or have never rehearsed the one they have (eMBA Module 3 Lesson 8). The remaining 45% have plans of varying quality, and only ~10% have practiced them under simulated stress.
• During an active exploit, every minute matters. Teams without a playbook spend the first hour figuring out who decides what, while the attacker moves funds.
• A working playbook has five sections: classification, decision tree, communication plan, war-room roles, post-mortem template.
• Practice cadence: a 2-hour tabletop exercise per quarter. Cost: minimal. Reward: 6-8x faster response when an incident actually happens.
• The canonical recovery case is Euler ($197M exploited in March 2023, fully recovered through community pressure plus hacker negotiation, 23 days from exploit to recovery). It set the operational bar for what good IR looks like.

Why this matters

When a smart contract gets exploited, the first 15 minutes determine whether the protocol recovers $200M, $50M, or zero. Whoever has a paused contract and a clear public statement at minute 15 has a chance. Whoever is still figuring out who can pause and which channels to post on at minute 60 has lost.

Most teams discover their IR gap during the incident itself. The CTO is on a flight. The multisig signer who can pause is asleep. The "incident commander" role doesn't exist; everyone is shouting in the same Discord channel. The hacker withdraws to Tornado Cash while the team posts conflicting updates on Twitter.

This is not theoretical. It's the documented pattern across most Web3 exploits. The exceptions are protocols that prepared in advance.

If you're a founder shipping anything that holds user funds, the IR playbook is one of the cheapest pieces of insurance you can buy. It's also one of the most under-built.

The 5 sections

A working IR playbook is short. Mine is roughly 8 pages. The sections, in order:

1. Classification

Define severity tiers and what triggers each. Example:

The playbook should be specific about what each tier looks like. "Funds actively being drained" is concrete; "something bad" is not.

2. Decision tree

Once classified, the playbook tells you who decides what. The two highest-leverage decisions:

Pause decision:

Is the protocol pausable?
├── Yes → Who has pause authority?
│   ├── Multisig with 2-of-N → who's on call? quorum reachable?
│   └── Admin EOA → who has the key? where's the hardware wallet?
└── No → flag operational risk in post-mortem; cannot pause this incident

Communication decision:

Confirmed exploit?
├── Yes
│   ├── Funds drained > $100K → public Twitter within 30 min, deferred details
│   ├── Funds < $100K → public statement when full picture available, ~2 hours
│   └── No funds drained but exposure existed → internal-only initially, public after fix
└── Suspected only → internal investigation; no public comms until confirmed

The decision tree saves you the cost of arguing about each decision during the incident itself. The arguments happen in advance, in calmer conditions.

3. Communication plan

Pre-written templates, with blanks. The blanks are filled in during the incident; the structure isn't debated.

Templates needed:

• Internal announcement (team Slack/Discord). "Incident declared. Severity: __. Lead: __. War-room link: __. Comms freeze on social until next update."
• Public Twitter (initial). "We are aware of __. Investigating now. Will update within __ hours. Funds are __ [paused/safe/at risk]."
• Discord/Telegram community update. Slightly longer, more details. Pinned by community manager.
• Exchange/partner notification. Email + DM template for major exchanges (Coinbase, Binance, Kraken) and large integrators. They need to know to pause deposits.
• Regulatory notification (if applicable). Some jurisdictions require notification of breaches affecting user funds within 24-72 hours. Pre-write the lawyer-vetted version.

The internal announcement enforces a comms freeze on the rest of the team's social media until the incident commander authorizes outbound posting. Without this, multiple team members post conflicting updates and the attacker gains time during the confusion.

4. War-room roles

Pre-defined roles, names attached. Bench depth: at least one backup per role.

• Incident commander. Single person responsible for all decisions during the incident. Usually CTO or head of security. Backup: senior engineer with security context.
• Comms lead. Owns external communication. Usually head of marketing or community manager. Backup: another senior team member.
• Technical lead. Owns reverse-engineering the exploit and proposing fixes. Usually a security-focused engineer. Backup: another engineer.
• Treasury lead. If funds need to be moved (e.g., to a safe vault, to compensate users, to negotiate with the hacker), this person executes. Usually the CFO or treasury operator. Backup: another multisig signer.
• External coordinator. Liaison to audit firms, IR retainer firms, exchanges. Usually a senior team member with industry relationships.

The names matter. "The CTO will be incident commander" is not a plan if the CTO is on a flight. The plan must specify "Alice as incident commander, Bob as backup, Carol as second backup". When the incident hits, the first available person up the chain takes the role.

5. Post-mortem template

Pre-written structure for the post-mortem document. Filled in within 7-14 days of the incident.

• Executive summary. 1-2 paragraphs. What happened, what was lost, what was recovered.
• Timeline. Minute-by-minute or hour-by-hour for the active phase. Include both attacker actions and team response.
• Root cause. The bug or operational gap that enabled the incident.
• What worked. Honest list of what the playbook caught.
• What didn't work. Honest list of where the playbook had gaps.
• Remediation. What changes are being made to code, ops, or process.
• Compensation plan (if applicable). How affected users will be made whole.
• Acknowledgments. Researchers, partners, exchanges who helped.

The post-mortem is public when the incident affected user funds. Privacy concerns about specific exploit details (e.g., do you publish the exact attack path?) are handled in the playbook's pre-written guidance.

Practice cadence

A playbook on paper is half the work. The other half is rehearsal.

Run a 2-hour tabletop exercise per quarter. Format:

1. Setup (15 min). The incident commander or external facilitator describes a hypothetical scenario. "It's 3am UTC. Twitter is on fire. Someone exploited the lending pool for $50M. The attacker's address is __. What do you do?"
2. Response (60 min). The team works through the playbook in real time. Pause decision. Comms drafts. War-room formation. Treasury action. External outreach.
3. Debrief (45 min). Identify gaps. Update the playbook. Schedule any code changes.

Cost: 8 person-hours per quarter. Roughly $4-8K in labor for a 4-person team. Same as a small audit fee.

Return: when a real incident happens, response time drops from "hours of confusion" to "minutes of executing the script". The dollar value of those saved minutes can be measured directly: at $50K/minute of unmitigated drainage, every minute saved is real treasury.

Euler as gold standard

Euler Finance was exploited for $197M in March 2023. Bug class: a flash-loan-amplified accounting issue in a multi-step lending interaction. Funds were fully drained within minutes; the attacker had control of $197M of user assets.

What happened next is the canonical Web3 IR success story:

1. Hour 0-4: Euler team identified the exploit, paused remaining contracts, engaged audit firms and law enforcement.
2. Day 1-7: Public communication, on-chain messages to the attacker, white-hat negotiation framework established.
3. Day 8-14: The attacker began returning funds in tranches, motivated by community pressure and a documented framework for white-hat treatment.
4. Day 15-23: All funds returned. Users reimbursed at near-100% of pre-exploit value.

What made it work:

• Existing relationships with law enforcement and audit firms. Pre-established channels for sanctions threats and forensic support.
• Pre-rehearsed response structure. Euler had a playbook. They knew who would lead negotiation.
• Transparent communication. Daily public updates kept community pressure on the attacker without inflaming panic.
• Negotiation framework. Pre-agreed terms for white-hat treatment (10% bounty, immunity from criminal referral) gave the attacker an off-ramp.

The Euler recovery is held up in the eMBA Module 3 Lesson 8 as the operational benchmark. Other recoveries (Beanstalk, partial; Wormhole, paid by parent company) are case studies in alternative resolutions, not full white-hat returns.

Related questions

What's the difference between IR for code exploits vs operational incidents? Operational incidents (key compromise, social engineering) have different decision trees but the same five-section structure. IR is a general framework; you customize the trees per incident class.

How fast does the playbook need to be available? When an incident is declared. Most teams keep it in a shared Notion or Google Doc, with a backup PDF. Some store the contracts and addresses in the doc itself; others reference them by name with the actual values in a separate operational repository.

What if my team is too small to fill all the war-room roles? Roles can stack. A 3-person team might have one person as incident commander + comms, another as technical + treasury, a third as external coordinator. The playbook should be honest about this and pre-define the fallback role-stacking.

Should the post-mortem name the attacker? Depends. If the attacker has been doxxed publicly, naming them is fine. If not, the post-mortem describes the attacker by behavior and address only. Doxxing decisions are legal and ethical, not technical.

Do I need an IR retainer firm? For protocols with $10M+ TVL, recommend yes. Firms like Chainalysis, TRM, Halborn IR, Spearbit Forensics offer hourly engagement. Pre-arrange the contract before the incident; don't try to onboard a new firm during the active phase.

What about regulatory notification timing? Varies by jurisdiction. EU MiCA: 72 hours from incident detection. Singapore MAS: similar. US: state-by-state, increasingly converging on 72-hour windows. Pre-vet the lawyer-approved templates per jurisdiction you operate in.

Where to see this in Academy

eMBA Module 3 Lesson 8 (Incident Response) walks through the five sections in detail with templates, real Web3 case studies (Euler, Wormhole, Ronin), and a tabletop exercise framework you can run with your own team.

Module 3 Lesson 7 (Post-Deployment Monitoring), covered in the eMBA monitoring lesson, connects to this directly: monitoring tells you an incident is happening; the IR playbook tells you what to do about it. Without both, you're either blind or paralyzed when something goes wrong.

The 55% statistic is from a 2024 survey of Web3 protocol teams. The number is appalling but consistent with audit firm experience: most teams encounter their first real incident response during their first real incident. Don't be in that 55%.