Building an Incident Response Plan in 30 Days
The best incident response plan is the one you can actually execute at 2am on a Sunday. Here is how to build one in four weeks without hiring a consulting firm.

Building an Incident Response Plan in 30 Days
The best incident response plan (IRP) is not the most comprehensive document, but rather the one your team can actually execute effectively at 2 AM on a Sunday. Many organizations find themselves overwhelmed by the perceived complexity and cost of developing a robust IRP, often leading to paralysis or reliance on expensive external consultants. However, a highly functional, actionable plan can be developed internally within a focused four-week period by prioritizing practicality and immediate utility. This article outlines a streamlined approach to building such a plan, emphasizing critical decision-making, asset understanding, actionable procedures, and essential rehearsal.
Week 1, Decide Who Decides
A common pitfall during an incident is the lack of clear authority, leading to indecision and wasted time. The first week is dedicated to establishing a clear command structure for critical incident decisions. This isn't about lengthy organizational charts, but rather pinpointing the individuals empowered to make high-stakes choices under pressure.
To achieve this, identify and assign ownership for the five most critical decisions that invariably arise during a cybersecurity incident:
- Declare: The authority to formally declare an incident, triggering the full response protocol and notifying relevant stakeholders. This individual must understand the thresholds for escalation.
- Contain: The person who can authorize disruptive actions to stop an attack's spread, such as taking systems offline or blocking network traffic, balancing urgency with potential business impact.
- Communicate: The designated spokesperson responsible for internal and external communications, ensuring consistent messaging and managing reputational risks. This usually involves legal and public relations expertise.
- Pay: The individual with the authority to negotiate or approve payments, particularly relevant in ransomware scenarios, requiring financial and legal clearance.
- Disclose: The legal and regulatory expert who determines if and when public or regulatory disclosure is required, navigating compliance obligations and legal ramifications.
For each of these critical decision points, name a primary owner and at least one backup owner. The goal is to ensure that no critical decision is ever stalled by a single point of failure or an individual's unavailability. This concise list of roles and responsibilities can literally fit on an index card, making it incredibly accessible and easy to reference during chaotic moments.
Week 2, Map Your Blast Radius
Understanding the critical assets within your environment is paramount to effective incident response. You cannot protect what you don't know you have, nor can you effectively contain an incident if you don't understand its potential impact. Week two focuses on identifying these high-value targets and mapping their support structures.
Document the systems that house your organization's most sensitive data and critical operations, as these are invariably the targets attackers care most about. This includes, but is not limited to:
- Email Systems: Often a primary vector for initial compromise and a trove of sensitive communications.
- Identity Management Systems: Such as Active Directory or Okta, which control access to nearly all other resources.
- Financial Systems: Applications and databases handling monetary transactions, payroll, and billing information.
- Customer Data Platforms: Any system storing personally identifiable information (PII) or protected health information (PHI) of your customers.
- Source Code Repositories: Intellectual property that, if compromised, could have significant competitive and security implications.
- Build Infrastructure: Tools and systems used to compile and deploy applications, a potential vector for supply chain attacks.
For each identified critical system, meticulously record the primary on-call owner or team responsible for its immediate support. Crucially, also document their off-hours phone number and an alternative contact. It is imperative that these contact numbers and backup procedures have been actually tested recently to ensure their validity and responsiveness outside of business hours. This granular understanding of critical systems and their support personnel forms the foundation for rapid containment and recovery efforts.
Week 3, Write the Runbooks
While comprehensive binders often go unread during a crisis, concise, actionable runbooks are invaluable. Week three is dedicated to developing these practical, one-page checklists designed for immediate use under duress. The principle here is practicality over exhaustive detail; if it's too long, it won't be used.
Focus initial efforts on three high-impact, common incident scenarios your organization is likely to face:
- Suspected Account Compromise: This runbook should detail immediate steps when an employee's account is suspected of compromise. Key actions include disabling the account, forcing a password rotation, logging out all active sessions, and hunting for suspicious email forwarding rules or mailbox delegation changes. The emphasis is on swift isolation and preventing further lateral movement using compromised credentials.
- Endpoint Detection and Response (EDR) Alert: This runbook provides a playbook for responding to a critical alert from an endpoint security solution. Steps should include isolating the affected endpoint from the network, initiating a forensic image of the device, and proactive containment measures to prevent an attacker from moving through the network from that host.
- Ransomware Indicators: Given the prevalent threat of ransomware, this runbook is critical. Initial steps involve immediate physical or logical disconnection of the affected network segment to halt encryption, followed by an immediate declaration of the incident (referencing Week 1's decision-makers), and prompt engagement with legal counsel and cyber insurance providers.
Each of these runbooks must be designed as a single-page checklist. The constraint of a single page forces conciseness and highlights only the most essential, sequential actions. If detailed diagnostic commands or complex tools are required, the runbook should simply direct the responder to the relevant, pre-approved documentation or team. This approach ensures responders can quickly grasp and execute the necessary steps without being bogged down by unnecessary information.
Week 4, Rehearse
The final and arguably most critical step is to rehearse the plan. An IRP, no matter how well-written, is merely theoretical until it's put to the test. Week four is dedicated to conducting a focused tabletop exercise.
Organize a 60-minute tabletop session involving all the named owners from Week 1 and key personnel identified in Week 2 and 3. The exercise should simulate a realistic incident scenario pertinent to your industry and organization's threat landscape. For instance, a simulated phishing attack leading to account compromise and potential lateral movement might be highly relevant.
During the exercise, the primary objective is to identify friction points and areas where the plan is unclear or impractical. Crucially, resist the urge to "fix the plan" in real-time during the tabletop. The exercise is for observation and learning. Instead, meticulously document all issues, ambiguities, and procedural breakdowns as they arise. This includes areas where decision-makers hesitated, where contact information was outdated, or where runbook steps were unclear.
After the exercise concludes, dedicate the following day to reviewing the documented friction points and making targeted revisions to the IRP. This iterative process of testing and refining ensures that the plan becomes progressively more robust and genuinely executable.
After 30 days of dedicated effort following this structure, you will not have a hypothetically perfect incident response plan. What you will have, however, is a used plan, a living document that has been built, tested, and iterated upon by the very people who will execute it. This practical, battle-ready plan is far rarer and infinitely more valuable than any shelf-ware document.