Jul 23, 2025
Incident Response Plan
No matter how secure your Web3 protocol is or how many security audits it has undergone, only one document truly separates projects that take security seriously from those that don't: an Incident Response Plan.
An Incident Response Plan is a set of pre-prepared instructions and scripts to follow in the event of a protocol security incident. When such an event occurs, having a clear action plan reduces stress and saves precious time during and immediately after a hack.
The purpose of an Incident Response Plan is to ensure effective action in response to a hack and to minimize potential damage.
Below, we'll explore the essential elements that should be included in a high-quality Incident Response Plan.
Scope Definition
First and foremost, your Incident Response Plan should catalog the key elements of your protocol. This includes critical smart contracts, oracle dependencies, governance contracts, treasury addresses, and frontend and backend infrastructure.
The description should highlight security-sensitive areas and potential attack vectors. This detailed overview will help you avoid overlooking crucial aspects of the protocol during a hack, especially when stress is high and focus is vital for an effective response.
A good starting point for this section is the document generated during the Threat Modeling phase. Utilize the Web3 Security Roadmap for a comprehensive approach to developing your response plan.
Roles
An Incident Response Plan necessitates forming a Computer Security Incident Response Team (CSIRT). The plan doesn't specify the team's quantitative composition but outlines three primary roles that must be filled during a response.
Strategic Manager
This role leads the incident response process. The Strategic Manager focuses on orchestrating team actions, including coordinating with decision-makers to gain approval for actions requiring stakeholder consent. These actions typically include migrating funds, releasing patched versions, or negotiating terms with attackers.
Technical Manager
The Technical Manager oversees all processes directly related to the technical aspects. This includes analyzing code vulnerabilities, developing fixes, initiating transactions, and interacting with external security experts. The Technical Manager can perform these actions personally or act as a coordinator for their subordinates.
Communication Manager
The Communication Manager is the sole point of contact between the protocol team and the external community. They manage the flow of information to users, including its content and timing. The Communication Manager can delegate tasks related to direct publishing and feedback processing to their subordinates.
During incident simulations, it's beneficial to involve small teams with the minimum number of people needed to cover these essential roles. Each new simulation should engage team members who haven't yet participated in the exercise. This approach ensures that, during a real incident, a larger portion of your team will be prepared to handle a wide range of tasks within the response team.
External Experts
A good practice in securing a Web3 project is to have a pre-existing agreement with external experts in blockchain incident investigations. Such arrangements will prevent you from wasting critical time searching for specialists to assist your team. External experts can help you pinpoint the cause of the hack and provide a platform for tracking stolen funds.
The collected evidence and money laundering trails are essential for filing a report with law enforcement to initiate legal proceedings against the hackers.
The act of filing a case and commencing an investigation is a strong argument during negotiations with attackers, aiming to persuade them to return most of the stolen assets in exchange for dropping charges and a 10% reward.
A pre-prepared and well-rehearsed procedure for filing a report with law enforcement is also an integral part of a robust Incident Response Plan.
War Room
The Incident Response Plan must include a clear protocol for activating a War Room. This protocol should detail the algorithm for establishing a communication channel between incident response team members and external experts. This channel can be a secure chat or video conference.
Since information disclosed within this room may be sensitive, the protocol should include pre-established terms of interaction, such as Non-Disclosure Agreements (NDAs) or rules for information disclosure to external experts.
Communications
This section provides detailed guidelines for establishing internal and external communication channels.
Internal communication guidelines should cover the tools used for communication within the response team, their administrators, and access levels for different team members.
External communication guidelines describe the format of public updates regarding the incident's progress. This includes specifying the channels used and identifying the responsible party (the Communication Manager).
Playbook
The incident response playbook contains specific, practical steps the team takes in response to an attack. While other sections of the Incident Response Plan provide descriptive information, the playbook should be viewed as a strict algorithm.
The playbook outlines a set of actions divided into three groups, with actions from each group intended to be performed in parallel.
The actions in the playbook should be clear, concise, and rehearsed. Any discussion of execution nuances should be strictly avoided to ensure timely implementation.
Contain and Mitigate Damage
This group includes actions aimed at stopping the attack and minimizing damage.
Pause smart contracts
Block frontend functionalities
Blacklist attacker addresses
Rotate keys
Other actions aimed at stopping the outflow of stolen funds
These actions should be automated as much as possible, and their activation should not be hindered by bureaucracy.
Remediation
Actions in the Remediation group focus on identifying and fixing the vulnerability that led to the hack.
Identify the root cause (core vulnerability)
Develop a fix
Ensure its viability
Migrate to a new version
Restore user access to the protocol's functionality
This group of actions requires the involvement of security specialists, whether internal or external.
When performing actions in this group, it's crucial to balance speed and reliability. While it's vital to detect and fix the vulnerability as early as possible, it's equally important not to hastily restore access with an unverified fix.
Fund Recovery
The actions in this group aim to recover stolen funds.
Negotiate with attackers for the return of stolen assets in exchange for a reward and dropping charges
Engage ethical hackers to intercept stolen funds
These actions should be prepared and rehearsed in advance to save time when needed.
Lessons Learned
The final stage of incident response is analyzing the incident itself and the response to it. The data gathered during the investigation into the causes of the hack, as well as a retrospective of the response process, holds significant value for improving both protocol security and the response process itself.
The Lessons Learned document should contain a detailed breakdown of the incident's causes, a step-by-step description of the hack procedure, and a report on the effectiveness of the response process. The document should answer the following questions:
Why did the error appear in the code?
Why wasn't the error identified during development and testing?
Why didn't the audit detect the error?
Why didn't the monitoring system raise an alarm sooner?
Answers to these questions, along with a detailed description of the attack disclosed publicly, help other protocols defend against similar attacks. Transparent "post-mortem" reports contribute to the overall knowledge base of security in decentralized solutions.
Training
The Incident Response Plan should be regularly used in simulations and training exercises. A well-developed plan without proper practical training from the team will prove ineffective. Regular drills and "War Games" help the team develop automatic responses and, more importantly, identify weaknesses in the response plan itself.
Every training incident should be accompanied by an evaluation of the plan's effectiveness and a subsequent process of making corrections as needed.
The Web3 space is dynamic and evolving, with new approaches and technologies replacing outdated versions. This evolution of solutions should also be considered when reviewing and updating the Incident Response Plan.
Threat Modeling and Audits
To build a high-quality Incident Response Plan, it must be preceded by activities such as Threat Modeling and thorough Security Audits of smart contracts and infrastructure.
Threat Modeling involves inventorying critical protocol elements: smart contracts, oracles, multisig wallets, governance modules, and off-chain elements. Building a value map of these elements and their interdependencies allows team members to assess the protocol's architecture from a security perspective. The resulting Threat Modeling document serves as the basis for building the Incident Response Plan.
Comprehensive security audits, formal verification, and economic risk analysis are designed to enhance protocol security by detecting vulnerabilities in the code and protocol logic before deployment in a live environment. Thorough work in the early stages significantly reduces the likelihood of a crisis.
Monitoring
Setting up a monitoring and early threat detection system is a necessary prerequisite for building an effective Incident Response Plan.
The monitoring system is designed to detect incidents as early as possible and alert the team to what's happening. A successful incident response begins precisely with an alarm raised by the monitoring system. If you learn about an attack from the media or social networks, you're already in serious trouble.
In addition to alerting the team, the monitoring system performs another critically important function: automatic containment actions. In this context, containment refers to actions automatically executed in response to signals from the monitoring system. For example, pausing smart contracts upon detecting behavior unequivocally identified as preparation for an attack.
Building an early detection and automated threat response system requires considerable effort, but such a system is critical in crisis situations. For a holistic approach to protocol security, use the Web3 Security Roadmap.
NIST and SANS
In cybersecurity, there are established incident response frameworks: NIST (U.S. National Institute of Standards and Technology) and SANS (SysAdmin, Audit, Network and Security Institute). They share a common essence and differ only in detail. Combining these two frameworks yields a 6-stage template:
Preparation
Detection
Containment
Eradication
Recovery
Post-Analysis
Since we're operating in a decentralized environment, Web2 approaches must be adapted to Web3 realities.
In our case, the Preparation stage is implemented outside the Incident Response Plan during Threat Modeling and comprehensive security audits.
Detection is realized through monitoring initiatives for early threat detection and automated response.
Containment, Eradication, and Recovery are implemented within the Incident Response Plan's Playbook section.
Post-Analysis is carried out as an activity to prepare the "Lessons Learned" report.
Conclusion
An Incident Response Plan in Web3 is fundamentally an act of proactive effort. Developing the plan isn't just about writing a document, it's a continuous initiative that spans many stages of protocol development - from assessing business logic and adding safeguards to smart contract architecture to setting up a monitoring system, automated response, and ongoing team training.
