When the Ronin bridge was drained of $625 million in March 2022, the attack went undetected for five days. Not five minutes, not five hours: five days. By the time Sky Mavis understood what had happened, Lazarus Group had already begun dispersing funds through mixing services and cross-chain bridges. The absence of a functioning incident response plan was not a technical failure. It was an organisational one.
The same pattern appears across the most damaging crypto exploits on record. The Poly Network attack in August 2021 moved $611 million in a single transaction sequence. Bitfinex in 2016. The Bybit hack in February 2025, the largest single cryptocurrency theft ever recorded at approximately $1.5 billion. In each case, the technical vulnerability was the entry point. The scale of loss was determined by the quality, or absence, of an incident response plan.
A standard IT incident response plan, built around the NIST or SANS frameworks, is not sufficient for a crypto or DeFi environment. The assumptions that underpin traditional IR planning do not hold in Web3. This guide sets out what a crypto-specific incident response plan must contain, why the differences matter, and how to build the operational capability to execute it under pressure.
Why Crypto IR is Different
Traditional incident response assumes a set of properties that do not exist in blockchain environments. In a conventional enterprise breach, you can isolate the compromised system, revoke credentials, restore from backup, and recover data that was exfiltrated. The damage may be severe, but the mechanisms for containment and recovery are mature and well-understood.
In a crypto or DeFi incident, three fundamental differences change the calculus entirely.
Irreversibility. A confirmed blockchain transaction cannot be reversed. Once funds have moved to an attacker-controlled address, recovery depends entirely on external co-operation: exchange compliance teams, chain analytics firms flagging addresses, and law enforcement action. None of these are guaranteed. Speed of detection and speed of response are therefore not just performance metrics. They are the primary determinants of how much is lost.
Speed of loss. In a smart contract exploit, the entire treasury of a protocol can be drained in a single block. A block on Ethereum takes approximately twelve seconds. In the Poly Network attack, the attacker manipulated cross-chain message verification and moved over $600 million across three chains in a matter of minutes. In a traditional breach, exfiltrating that volume of value would take hours or days. The compression of time between attack initiation and maximum loss is unlike anything in conventional IT security.
Pseudonymous, borderless attackers. The attacker in a crypto incident is typically operating from a pseudonymous address with no attached identity, using tools designed to obscure the flow of funds. Lazarus Group, attributed to the Democratic People's Republic of Korea, has refined these techniques over years of operation targeting crypto firms. As detailed in our analysis of Lazarus Group's crypto operational security, the group uses cross-chain bridges, mixers, and over-the-counter brokers to convert stolen crypto into fiat within days of an attack. Traditional law enforcement timelines are simply incompatible with this speed.
These three differences mean that the People, Process, and Technology framework for crypto IR must be re-engineered from first principles, not adapted from a standard template.
The Five Phases Adapted for Web3
The five-phase structure from NIST SP 800-61 (Preparation, Detection, Containment, Eradication, Recovery) remains a valid organisational framework. The content of each phase, however, must be rebuilt for the Web3 context.
Phase 1: Preparation
Preparation is the phase that determines everything else. By the time an incident begins, it is too late to establish the capabilities, relationships, and procedures you need. The preparation phase for a crypto protocol must cover:
- Smart contract pause mechanisms: Every protocol holding user funds should have an audited, tested pause mechanism callable by a pre-defined multisig. The signers, their device configurations, and the process for convening a multisig call under time pressure must be documented and rehearsed. Protocols that lack a pause function have no containment option once an exploit is in progress.
- On-chain monitoring: Automated alerting on anomalous transaction volumes, unusual fund flows, governance proposal submissions, and oracle price deviations. Detection must be automated; manual monitoring will never be fast enough.
- IR retainer with a specialist firm: Pre-negotiated access to a Web3 incident response team with chain analytics capability means you are not searching for a provider during a live incident. The retainer should include pre-agreed scope, response time commitments, and established communication channels.
- Relationships with chain analytics firms: Chainalysis, TRM Labs, and Elliptic can flag attacker addresses across exchange networks within hours of notification. These relationships must exist before an incident, not be built during one.
- Exchange notification list: A prepared, up-to-date contact list for compliance teams at major centralised exchanges, including Binance, Coinbase, Kraken, OKX, and regional operators. Exchanges can freeze withdrawals from flagged addresses if notified quickly enough. Every hour of delay reduces the probability of recovery.
- Legal counsel on standby: Pre-engaged legal counsel familiar with crypto asset law, able to advise on disclosure obligations, negotiation with attackers, and cross-jurisdiction law enforcement co-ordination.
Phase 2: Detection
Detection in a DeFi context relies almost entirely on automated tooling. The human review cycles that work in enterprise security are too slow. Your monitoring infrastructure must alert on treasury balance changes exceeding defined thresholds, unusual smart contract interactions, governance attacks, and oracle manipulation events in real time.
A blockchain security audit should include a review of your monitoring configuration as well as your contract code. Many protocols have well-audited contracts but no detection capability: the code is secure until it is not, and when it fails, the team learns about it from Twitter.
Phase 3: Containment
Containment in a DeFi context centres on the pause mechanism. The moment an exploit is confirmed, triggering the pause function is the highest priority action. Everything else is secondary. This requires:
- Pre-assembled multisig quorum able to sign and execute a pause transaction within fifteen minutes of detection, regardless of time zone or hour
- A secure, out-of-band communication channel for the IR team that does not run through potentially compromised corporate systems
- Pre-drafted exchange notification messages ready to send immediately, requiring only the attacker address(es) to be inserted
For centralised exchange operations, containment includes revoking compromised API keys, suspending withdrawals, and isolating affected wallets from hot wallet infrastructure.
Phase 4: Eradication
Eradication means identifying and remediating the root cause. In a smart contract exploit, this typically requires a contract upgrade or redeployment after a thorough code review. In an operational security breach such as the Bybit hack, where the attack involved compromised developer infrastructure, eradication requires a comprehensive review of all systems, credentials, and access controls that may have been touched by the attacker.
Eradication in a Web3 context is complicated by the fact that the attacker may still hold privileged access during the IR process. All developer and administrative credentials, signing keys, and access tokens should be treated as compromised until a forensic investigation confirms otherwise.
Phase 5: Recovery
Recovery covers redeployment of patched contracts, resumption of protocol operations, and, where possible, recovery of stolen funds. User communication, compensation mechanisms, and long-term trust rebuilding are also part of the recovery phase. Protocols that have maintained good documentation and transparent communication throughout an incident recover user confidence significantly faster than those that went silent.
"The five days between the Ronin bridge breach and its discovery did not just cost Sky Mavis $625 million. They cost the entire DeFi industry a year of institutional confidence."
Detection and Monitoring
Detection capability is the component most frequently absent from Web3 protocols and exchanges. Code audits are now standard practice for any serious project. Runtime monitoring is not. The gap between these two is where most avoidable losses occur.
A robust detection architecture for a DeFi protocol should include:
- Transaction volume alerts: Triggered when outflows exceed a defined percentage of total value locked within a single block or rolling window
- Address monitoring: Automated tracking of known attacker and mixer addresses, with alerts on any interaction with protocol contracts or treasury wallets
- Oracle deviation monitoring: Alerts when price oracle feeds deviate significantly from expected ranges or from each other, which is a primary indicator of oracle manipulation attacks
- Governance monitoring: Detection of unusual governance proposal submissions, delegate accumulation, or vote concentration that may indicate a governance attack in preparation
- Infrastructure monitoring: For centralised operations, endpoint detection and response on all developer and administrative machines, integrated with a security information and event management platform
The detection tools should feed into a 24/7 alerting process. Whether this is managed in-house or via a security operations centre depends on the scale of the operation, but the capability must exist around the clock. Attacks do not observe business hours.
Man-in-the-middle attacks represent a specific detection challenge in Web3, as they can intercept signing ceremonies, modify transaction parameters before hardware wallet confirmation, or compromise the front end of a protocol to redirect user funds. Our detailed coverage of MitM attacks in crypto covers the detection signatures specific to this attack class.
Containment in a DeFi Context
The Poly Network incident in August 2021 illustrates what happens when containment options do not exist. The attacker exploited a flaw in cross-chain message verification and removed over $600 million in a single attack sequence. Because the contracts had no pause function, and because no automated monitoring was in place, the team had no containment mechanism to deploy. They could only observe and communicate.
Contrast this with protocols that have responded effectively to exploit attempts. MakerDAO's emergency shutdown mechanism, while a drastic measure, provides a defined containment path for extreme scenarios. Compound, Aave, and other major DeFi protocols have guardian roles and pause functions specifically designed to enable rapid containment.
For protocols that hold significant value, the pause mechanism itself requires security hardening. The multisig controlling pause authority must not be so small that a single compromised key can be exploited, nor so large that convening a quorum under time pressure is impractical. A three-of-five or four-of-seven structure, with geographically and jurisdictionally distributed signers, represents a reasonable balance.
Beyond the pause mechanism, containment in a DeFi incident includes:
- Contacting bridges and cross-chain protocols that the attacker may use to move funds, providing attacker addresses for monitoring or blocking
- Notifying major DeFi lending protocols to monitor or pause interactions from attacker addresses where technically possible
- Alerting the chain analytics community, which can trigger rapid propagation of attacker address labels across the ecosystem
Privileged access management is a precondition for effective containment. If you do not know which accounts have administrative access to your protocol, you cannot execute a controlled pause. A properly documented privileged access management programme for crypto ensures that access rights are inventoried, controlled, and revocable under incident conditions.
Communications and Disclosure
Communications during a crypto incident must balance transparency with operational security. Announcing an exploit publicly before the pause mechanism has been triggered will alert the attacker to accelerate fund movement. Delaying disclosure beyond what regulations require exposes the organisation to regulatory sanction and damages user trust far more than prompt, honest communication would.
The communications sequence for a DeFi incident typically follows this order:
- Internal IR team activation: Secure, out-of-band channels only. No public or corporate communication until the situation is assessed.
- Pause mechanism execution: Contain the bleeding before disclosing. Every minute between detection and pause is additional loss.
- Exchange notifications: Priority communication to centralised exchange compliance teams with attacker addresses. This can happen in parallel with the pause if resources allow.
- Chain analytics firm engagement: Notify your retainer firm and provide all available on-chain data for immediate triage.
- Regulatory notification: Under DORA, major incidents must be reported to the relevant supervisory authority within four hours of classification. The timeline begins from when you classify the incident, not when the attack occurred: but classification must happen promptly.
- Public disclosure: User-facing communication via official channels, confirming the incident, describing current status, and providing guidance on any actions users should take. Avoid speculation about causes or losses until confirmed.
- Ongoing updates: Regular, factual updates as the investigation progresses. Silence during an incident erodes confidence far faster than bad news delivered transparently.
The language of public disclosure matters. Teams that communicate with clarity and accountability tend to recover user confidence. Teams that use obfuscating language, shift blame, or go quiet typically do not. Pre-drafting a disclosure template as part of your incident response plan preparation ensures that communication quality does not degrade under the pressure of a live incident.
Regulatory Requirements for IR
The regulatory framework for crypto incident response has hardened significantly since 2023. Firms operating in the EU, UK, Dubai, or Singapore now face specific, enforceable obligations around incident management.
DORA (Digital Operational Resilience Act): Applicable to all financial entities including crypto-asset service providers in the EU, DORA requires documented ICT incident management procedures, a classification scheme for incidents by severity, and mandatory reporting of major incidents to the relevant competent authority. The initial notification must occur within four hours of major incident classification, with an intermediate report within 72 hours and a final report within one month. Our full analysis of DORA compliance requirements covers these obligations in detail.
MiCA (Markets in Crypto-Assets Regulation): MiCA requires crypto-asset service providers to have operational resilience measures, including incident management procedures that address both technical failures and security incidents. CASPs must notify the competent authority and affected users of significant incidents without undue delay. The MiCA framework aligns with DORA for entities subject to both.
VARA (Virtual Assets Regulatory Authority, Dubai): VARA's operational and technology standards mandate documented incident response capabilities, regular testing, and notification obligations. The framework is less prescriptive on timelines than DORA but requires demonstrated operational readiness.
The practical implication for IR planning is that your plan must be written with regulatory reporting obligations explicitly mapped at each phase. Who is responsible for regulatory notification? What constitutes a "major incident" under the applicable framework? What records must be maintained to demonstrate compliance with reporting timelines? These questions must be answered in advance, not worked out during a live incident.
Building Your IR Plan and Retainer
An incident response plan that exists only as a document is not a plan. It is a compliance artefact. The difference between an IR plan and an IR capability is rehearsal, tooling, and retained specialist access.
The components of a functioning crypto IR capability are:
Documentation
The written IR plan should define: scope and applicability; roles and responsibilities (with named individuals and deputies); contact lists for all internal and external stakeholders; decision trees for common incident types; regulatory notification obligations and timelines; and approved communication templates for users, regulators, and media.
Tooling
On-chain monitoring configured and tested before deployment; hardware security modules for key management; out-of-band communication channels for the IR team; a blockchain explorer and chain analytics tool accessible to IR team members; and endpoint detection and response on all administrative and developer machines.
People and Training
Each person named in the IR plan must understand their role, have access to the tools they need, and have practised the procedures under simulated pressure. Tabletop exercises should be run at minimum annually, and ideally twice yearly, simulating realistic incident scenarios including the Ronin-style delayed detection scenario, a flash loan oracle attack, and a compromised developer machine leading to a supply chain attack.
A zero-trust architecture, as outlined in our piece on zero-trust security for Web3, reduces the blast radius of any single compromised credential or system and is a natural complement to a strong IR capability.
Specialist IR Retainer
A pre-negotiated retainer with a Web3 incident response firm provides access to chain analytics expertise, smart contract forensics capability, and crisis communications support that most protocols cannot maintain in-house. The retainer should include defined response time commitments, agreed scope of services, and tested communication protocols. Engaging a specialist firm for the first time during a live incident is one of the most reliable ways to extend the time to effective response.
Testing and Continuous Improvement
IR plans degrade rapidly as personnel, systems, and protocol architecture change. The plan must be reviewed and updated after every significant change to the protocol, after every significant incident in the broader industry, and on a scheduled basis at minimum every six months. Post-incident reviews, including reviews of incidents at other protocols, provide the most valuable input for improving your own plan.
The organisations that survive major security incidents are not those that avoided all mistakes. They are those that had the detection, containment, and communication capability to limit the damage and communicate with integrity when it mattered.
Frequently Asked Questions
What makes a crypto incident response plan different from a standard IT IR plan?
A crypto incident response plan must account for the irreversibility of on-chain transactions, the speed at which funds can be moved across chains, and the absence of a central authority who can freeze or reverse transfers. Traditional IT IR plans assume you can isolate a compromised system and recover data from backups. In crypto, funds moved in the first few blocks are frequently unrecoverable without coordinated exchange notifications and chain analytics support. The plan must also address smart contract-specific controls such as pause mechanisms and emergency multisig procedures.
How quickly must a DeFi protocol respond to an active exploit?
Response must begin within minutes, not hours. In the Ronin bridge attack, the breach went undetected for five days, allowing $625 million to be moved and partially laundered. In most DeFi exploits, the majority of funds leave the protocol within one to three blocks of the initial attack transaction. Effective detection and automated alerting systems must be in place before an incident occurs, enabling a human response team to act within the first ten to fifteen minutes of suspicious activity.
What is a smart contract pause mechanism and why is it critical for incident response?
A pause mechanism is a function built into a smart contract that allows an authorised address or multisig to halt all deposits, withdrawals, and transfers on the protocol. When an exploit is detected, triggering the pause function is typically the single most effective containment action available to a DeFi team, as it prevents further funds from being drained while the vulnerability is investigated. Protocols without a pause mechanism, like the original Poly Network design, have no containment option once an attack begins and can only watch as funds are removed.
Which regulations require a documented incident response plan for crypto firms?
The EU Digital Operational Resilience Act (DORA) mandates documented incident classification, response procedures, and regulatory reporting timelines for financial entities including crypto-asset service providers. MiCA requires CASPs to have operational resilience measures including incident management procedures. VARA in Dubai and equivalent frameworks in Singapore and the UK impose similar requirements. Firms operating across multiple jurisdictions must ensure their IR plan satisfies the strictest applicable standard.
Should we attempt to negotiate with attackers or offer a bug bounty after a hack?
Post-incident negotiation with attackers has succeeded in a small number of cases: the Poly Network attacker returned funds after communication, and several protocols have offered white-hat bounties to incentivise partial return. However, this approach carries legal risks, requires careful coordination with legal counsel, and cannot be relied upon as a primary recovery strategy. Chain analytics firms can assist in monitoring attacker wallets and flagging funds at exchanges, which provides a more reliable path to partial recovery than negotiation alone. The decision to negotiate must be made with legal advice and documented as part of your IR plan.