How to Run a War Room: A Playbook for Crypto Protocols

An Immunefi field guide to running an effective war room during an active onchain exploit, where billions can hang in the balance and minutes decide outcomes.

Key takeaways

• A war room is solving for two things at once: contain further losses and protect user trust. Lose either, and recovery gets exponentially harder.
• Parallel execution wins. Sequential thinking kills. Forensics, decisions, and communications must run in parallel from minute one.
• Three roles, no more. An Ops Lead to conduct, a Security Analyst to investigate, a Comms Lead to manage trust. Every additional participant slows decisions and raises leak risk.
• Preparation done before the incident determines the outcome. Playbooks, contact lists, role assignments, infrastructure maps, and tabletop exercises are the actual work. Improvising at 3am is how protocols get rekt.
• The postmortem is where trust is rebuilt or permanently lost. Honest accounting beats legal-flavored deflection every time.

War rooms are inevitable for any serious onchain project

If a protocol is worth protecting onchain, a war room is coming for it eventually. The data is unambiguous: across five years of vulnerability research, the longer a project operates, the closer the odds of a serious incident converge toward certainty. The only question is whether the team has built the muscle memory required to respond before the call lands.

This playbook distills what an effective onchain war room actually looks like in practice, drawn from Immunefi's experience supporting dozens of crisis responses across the onchain economy. It is not an academic framework. It is a description of what works when the clock is running and user funds are exposed.

Before the breach: preparation most teams will skip

The single highest-leverage security investment a team can make is the work done before an incident. Almost none of it happens during the incident, because there is no time.

A baseline war room readiness checklist looks like this:

• A written incident response playbook, distributed to every relevant party and stored where it can be accessed under duress. Not a Google Doc that nobody has looked at in eight months.
• Reachability at 3am on a Sunday for every critical contact. Do-not-disturb settings need configured exceptions. Phone numbers, backup channels, and escalation paths all need to be verified live, not assumed.
• Operational roles assigned in advance. Knowing in advance who runs ops, who runs analysis, and who runs comms removes hours of confusion at the worst possible moment.
• A full infrastructure map, covering every deployed contract, every admin key, every signer on every multisig, and every external dependency. Mapping this under fire is a recipe for missing the actual attack surface.
• At least one tabletop exercise or war game. A simulated incident reveals exactly where a team's playbook breaks down, and gives the team a chance to fix it before it matters.

Most teams skip most of this. That is precisely why most teams get rekt when the call comes. The war council needs to exist before the war starts.

What the war room is actually solving for

Every active war room is working on two parallel objectives at once: stop further losses and preserve user trust. These objectives are equally important, and they will pull in opposite directions at almost every decision point.

Pausing contracts may stop the bleeding, but it tends to trigger panic in the community. Going silent while the investigation runs may protect operational security, but it erodes confidence hour by hour. Trust loss can be fatal to a protocol even when funds are eventually recovered. Conversely, protocols with strong communications discipline have survived nine-figure exploits, while smaller incidents have destroyed projects whose teams went dark at the wrong moment.

Both tracks have to run from minute one. Not sequentially. In parallel.

Step 1: Confirm and pause

The first move is verification. As soon as there is any credible indication that an exploit is real, the next move is containment: pause affected contracts, lock down permissions, and cut off every drain vector available.

Speed matters more than certainty at this stage. A false positive costs the team some inconvenience and reputational friction. A slow response costs millions, sometimes more.

The verification-and-pause step assumes the protocol can actually pause itself. Truly decentralized protocols, with no admin keys and no multisig, face a fundamentally different containment problem: the contracts cannot be paused or changed. That constraint shapes every decision that follows, and it is a critical input to the playbook design phase. Knowing in advance whether a protocol has pause authority changes the entire response strategy.

Step 2: Assemble the war room (three roles, no more)

A tight, trusted group will always move faster than a crowd. Each extra person added to the war room slows decision-making and raises the risk of a leak. The right structure is three roles. Not five. Not ten. Three.

The Ops Lead is the conductor. They keep decisions timeboxed, run the workflow, hold the room's composure together, and enforce frequent sync cycles. Without that discipline, the room spirals into haphazard side conversations, arguments metastasize, and recovery stalls. A strong Ops Lead assigns players, divides timezone coverage, allocates responsibilities, and builds the roadmap forward inside the first few minutes. No hesitation. No committee.

The Security Analyst finds the truth. As many analysts as the situation demands should be pulled in to identify the attack vector and its full scope, build mitigations and patches, monitor for secondary attacks, and validate readiness before any unpause. Expect overnight work. Expect no sleep. Expect deep engagement with the protocol's codebase, deployed contracts, and historical transactions.

The Comms Lead owns trust. Clear, calm, factual updates delivered on a predictable cadence. No silence. Poor communication can produce bank-run behavior faster than the original exploit ever could. A single misjudged tweet from the wrong account can wipe out hours of technical progress. The Comms Lead also serves as the firewall between the technical team and the community, so the analysts can stay heads-down on the actual fix.

Step 3: Parallel execution, not sequence

This is the step where most war rooms fail. The instinct is to complete the forensics, then make the decisions, then communicate the outcome. That sequential default is catastrophic in an active incident.

Everything runs in parallel to minimize response time.

A practical comms cheat sheet, all of it prepared as early as possible:

1. Document everything. War room transparency is one of the most important signals a protocol can send. It demonstrates professionalism, supports the eventual postmortem, and proves the team operated in good faith under pressure. AI tools have made real-time documentation easier than ever, so there is no excuse to skip this.

2. Pre-write a "worst case" message track. If everything goes wrong, how does the protocol fastest communicate that it is frozen and protect users? If the protocol cannot be paused, how does it guide users to a near-effortless way to protect their own funds? The clock is ticking; this messaging needs to be ready before it is needed.

3. Pre-write the "happy path" message track. Where the team buys time until a full, transparent postmortem can be published. The starting point is messaging designed to project confidence and request patience. It goes live on socials and community channels, but only after the exploit is confirmed mitigated.

4. Only after the immediate tracks are covered, begin work on long-form deliverables: the postmortem itself (drawing on war room documentation) and the follow-up confidence-rebuilding communications.

The full messaging stack should be ready before the team knows what they actually need to deploy. If the incident resolves cleanly, none of it gets used. If it doesn't, the team is not improvising under fire.

Remain calm, seriously

This sounds obvious. It is not. Staring at potentially millions of dollars in exposed user funds, with no guarantee a whitehack will work, holding composure is the single hardest skill to keep alive in the room.

It is also the non-negotiable one. The right calls cannot be made without it. Composure is what separates teams that lose $10M from teams that lose $100M on the same incident.

The postmortem: 24 to 48 hours after resolution

Within a day or two of incident resolution, the team publishes a full postmortem. At minimum it should include:

• Root cause of the exploit
• Complete attack timeline, down to the minute where possible
• Fix applied and its verification status
• Prevention roadmap for the relevant vulnerability class

The worst postmortems share a common pattern. They are produced by teams unwilling to own their share of responsibility. The timeline gets stripped of context. Blame is offloaded onto "sophisticated attackers," as if that single descriptor erases months of ignored warnings. The document reads more like a legal filing than an honest accounting of what happened.

That pattern destroys communities faster than the original exploit. There is a well-documented track record across the industry of protocols whose postmortem theater, neither side owning the full truth, poisoned community trust for years afterward. There is an equally well-documented pattern of protocols recovering surprisingly well from significant incidents because the team published honestly, named names, credited contributors, laid out the precise timeline, and walked through the vulnerability in full technical depth.

It is acceptable, sometimes even wise, for a project to negotiate with attackers. What is not survivable is gaslighting the community about what actually happened. A postmortem that hides the truth does not protect anyone. It guarantees that when the real story leaks, and it always leaks, the trust damage becomes permanent.

The honest postmortem is uncomfortable to write. It is also the single biggest determinant of whether a protocol comes out of the incident with a community still willing to trust it.

When negotiation with attackers becomes necessary

Not every incident ends with a successful whitehack. In some cases the attacker reaches the funds first. When that happens, the protocol opens communication channels (onchain messages remain a workable medium), offers a safe return path, and structures incentives that make cooperation more attractive than running with the funds.

The Safe Harbor framework, developed through SEAL and supported by Immunefi, was designed specifically to formalize this process and reduce the legal ambiguity that often paralyzes both sides of these conversations.

A few realities worth absorbing about attacker negotiation:

• It works more often than people assume, but fails more often than it succeeds. Some negotiations conclude with the attacker returning funds in exchange for a bounty payment and identity protection. Others stall out entirely, particularly when the attacker makes unreasonable demands that leave no productive path to resolution.
• Leverage matters. Identifying jurisdiction, exchange touchpoints, or operational fingerprints can change the calculus quickly. Negotiators have successfully recovered funds simply by demonstrating that the attacker's identity could be exposed.
• Escalation must be proportional. If negotiation fails, the ladder typically runs: public warnings → forensics firms → exchange freezes → legal action → criminal filings. Each step must be considered carefully. Reckless escalation burns bridges that may be needed later in the process.

The general principle: attackers can be persuaded to return funds. They rarely return funds out of conscience. They return funds when the incentives line up.

What separates successful war rooms from catastrophic ones

The protocols that come out of an active incident with their users protected and their trust intact share a small set of traits:

• They had a written playbook, fresh contacts, and rehearsed roles before the incident began.
• They executed in parallel rather than sequentially.
• They kept the war room small and trusted.
• They communicated early, clearly, and on a predictable cadence.
• They published an honest postmortem within 48 hours.
• They had at least one experienced incident responder in the room who had been through this before.

The protocols that lose users, lose trust, or lose existence as a project tend to fail on the inverse: no playbook, no muscle memory, no comms discipline, no honest accounting after the fact. The difference between the two outcomes is almost never about the severity of the underlying exploit. It is about preparation and execution.

Build the muscle before the call comes

For any team reading this without an incident response playbook in place: write one this week. If key security contacts cannot be reached at 3am, fix that today. If the protocol's infrastructure has not been mapped end to end, that is the next task on the list.

War rooms are inevitable. Survival depends on what was built before the call came.

For more on what hacks actually cost a protocol beyond the headline theft number, see Immunefi's The Real Cost of an Onchain Hack: 2024-2025 Update.

About Immunefi

Immunefi is the leading security platform for crypto, protecting more than $180 billion in user funds, and securing protocols across the full development lifecycle, from pre-deployment through production.