Incident Response Planning: From Zero to Board-Ready in 90 Days

Most Incident Response Plans Fail Before the Incident Starts

Here is the uncomfortable truth about incident response: the plan you wrote two years ago and filed in a shared drive is not going to save you when ransomware locks your production database at 3 AM on a Saturday. Every organization we assess has some version of an IR plan. Almost none of them have one that would actually work under pressure.

The gap between having a plan and having a functional, tested, board-reportable incident response capability is where most organizations live. That gap is where breaches escalate from containable events into business-ending catastrophes. The 2025 IBM Cost of a Data Breach report found that organizations with tested IR plans spent an average of $1.49 million less per breach than those without one.

This guide walks you through building a real incident response program in 90 days -- one grounded in the NIST framework, tested through tabletop exercises, and structured to give your board and your customers confidence that you can handle whatever comes next.

The NIST Incident Response Framework: What It Actually Requires

NIST SP 800-61 (Computer Security Incident Handling Guide) defines the standard framework that most compliance regimes -- SOC 2, ISO 27001, PCI DSS, and HIPAA -- either directly reference or map to. Understanding these four phases is not optional. It is the vocabulary your auditors, insurers, and legal counsel will use.

Phase 1: Preparation

Preparation is everything that happens before an incident occurs. This is where 90% of your IR program investment goes, and it is where most organizations under-invest. Preparation includes:

• Establishing an incident response team with defined roles and 24/7 contact information
• Deploying and configuring detection tools -- SIEM, EDR, network monitoring, attack surface monitoring
• Creating and maintaining the incident response plan document itself
• Building communication templates for internal stakeholders, customers, regulators, and media
• Establishing relationships with external resources -- forensic firms, legal counsel, law enforcement contacts
• Conducting regular training and tabletop exercises
• Maintaining an asset inventory so you know what you are defending

The preparation phase never ends. It is a continuous cycle of improvement driven by lessons learned from exercises and real incidents. Organizations that treat preparation as a one-time project end up with stale plans that fail under pressure.

Phase 2: Detection and Analysis

Detection is where your continuous monitoring program meets your IR plan. When an alert fires, someone needs to determine whether it is noise, an event worth tracking, or an active incident requiring response. This phase covers:

• Initial detection through automated alerts, user reports, or external notification
• Validation to confirm the event is real and not a false positive
• Classification using your severity matrix to determine priority and response level
• Scoping to understand what systems, data, and users are affected
• Documentation of everything from the moment the incident is declared

The biggest failure mode in this phase is slow escalation. Teams that spend hours investigating before declaring an incident lose containment time they cannot get back. Your plan should define clear thresholds: if you see X, escalate immediately. Do not wait for certainty.

Phase 3: Containment, Eradication, and Recovery

Once an incident is confirmed, the priority shifts to stopping the damage, removing the threat, and restoring normal operations. NIST breaks this into three sub-phases, but in practice they often overlap:

• Short-term containment -- Isolate affected systems to prevent lateral movement. This might mean network segmentation, disabling compromised accounts, or blocking malicious IPs
• Long-term containment -- Implement temporary fixes that allow business operations to continue while you prepare for full eradication
• Eradication -- Remove the root cause. Patch the vulnerability, eliminate malware, close the access vector
• Recovery -- Restore systems from clean backups, validate integrity, and gradually return to normal operations with enhanced monitoring

Phase 4: Post-Incident Activity

The most neglected phase. After the adrenaline fades and systems are restored, teams want to move on. But post-incident activity is where your IR program actually improves. This phase requires:

• A formal post-incident review meeting within 5 business days of incident closure
• A written report documenting timeline, root cause, impact, response actions, and lessons learned
• Specific, assigned action items to prevent recurrence -- new detection rules, architecture changes, policy updates
• Updates to the IR plan itself based on what worked and what did not
• Board-level reporting for significant incidents

Building Your IR Team: Roles That Matter

An incident response plan without clear role assignments is a document, not a capability. Every organization -- regardless of size -- needs these roles defined. In smaller companies, one person may fill multiple roles. The important thing is that everyone knows their responsibilities before an incident occurs.

For startups and smaller organizations that cannot staff all these roles internally, the answer is not to skip them. It is to establish external relationships in advance. A startup IR playbook needs to account for the reality that your security team might be one person -- or zero people.

Communication Templates: What to Have Ready Before You Need Them

During an active incident, nobody writes well. Stress, time pressure, and legal anxiety combine to produce either over-sharing that creates liability or under-sharing that erodes trust. The solution is pre-approved templates that your legal and communications team have reviewed before any incident occurs.

Templates You Need on Day One

• Internal escalation notification -- Notifying leadership that an incident has been declared, with severity, known scope, and next update time
• Customer notification (confirmed breach) -- Clear, factual communication about what happened, what data was affected, and what you are doing about it
• Customer notification (precautionary) -- For incidents where customer data may have been exposed but is not confirmed
• Regulatory notification -- Templates for GDPR (72-hour window), state breach notification laws, and industry-specific requirements
• Employee communication -- Internal messaging to prevent rumor spread and provide action items like password resets
• Board briefing -- Executive summary format with business impact, response status, and recommended actions

Each template should include placeholders for incident-specific details, a review/approval workflow, and guidance on which communication channels to use. Do not send breach notifications over the same email system that may be compromised.

Tabletop Exercises: How to Test Without Breaking Anything

A tabletop exercise is a discussion-based simulation where your IR team walks through a hypothetical incident scenario. No systems are touched. No production workloads are affected. The value comes from forcing your team to think through decisions, identify gaps in the plan, and practice coordination under simulated pressure.

Running an Effective Tabletop Exercise

The exercise facilitator presents a scenario in stages, with each stage introducing new information or complications. After each stage, the team discusses what they would do, who they would contact, and what decisions they would make. A good exercise takes 90 to 120 minutes and covers:

1. Initial detection -- An alert fires or a report comes in. Who gets notified? How quickly?
2. Escalation and classification -- Is this an incident? What severity? Who makes that call?
3. Containment decisions -- The scope expands. Do you take production offline? Who authorizes that?
4. External communication -- A journalist calls. A customer asks about the outage on social media. What do you say?
5. Recovery and closure -- Systems are restored. What happens next? Who writes the report?

Scenario Ideas for Different Threat Types

Document the findings from every exercise. The gaps you identify become the improvements that make your next exercise -- and your next real incident -- go better.

IR Retainers: When to Bring in External Help

An incident response retainer is a pre-negotiated contract with a security firm that guarantees availability and response times when you need forensic investigation, malware analysis, or additional incident handling capacity. Think of it as insurance for your incident response capability.

When a Retainer Makes Sense

• Your team lacks forensic expertise -- Most internal security teams can detect and contain, but digital forensics and evidence preservation require specialized skills and tools
• Your cyber insurance requires it -- Many policies either require a pre-approved IR firm or offer premium discounts for having a retainer in place
• You handle regulated data -- Healthcare, financial services, and government contractors face strict investigation requirements that demand forensic rigor
• You need surge capacity -- Even large security teams can be overwhelmed by a major incident that spans multiple systems and business units

What to Look for in a Retainer

• Guaranteed response time -- 2 to 4 hours for critical incidents, not "best effort"
• Named responders who have been briefed on your environment, not a random analyst from a call center
• Unused hours that roll over or convert to proactive services like risk assessments or threat modeling
• Clear scope of services -- forensics, malware analysis, containment support, legal testimony
• Compatibility with your cyber insurance panel requirements

The 90-Day Implementation Roadmap

Here is the concrete plan for going from zero to a board-ready IR program in 90 days. This assumes you have at least one person who can dedicate 40% of their time to this effort, plus executive sponsorship to unblock decisions.

Days 1-30: Foundation

• Assign an IR program owner with executive sponsorship
• Complete an asset inventory of all systems that store, process, or transmit sensitive data
• Define your incident severity classification matrix (P1 through P4)
• Draft the initial IR plan document covering all four NIST phases
• Identify and assign IR team roles -- fill gaps with external relationships
• Build your contact list: IR team, legal counsel, insurance carrier, forensic firm, law enforcement
• Draft initial communication templates and get legal review started

Days 31-60: Operationalization

• Finalize the IR plan with legal and executive review and formal approval
• Establish or validate your incident response retainer agreement
• Create response runbooks for your top 5 incident scenarios
• Configure your incident management tooling -- ticketing, communication channels, war room setup
• Train all IR team members on their roles and the plan
• Verify detection capabilities align with the scenarios in your plan
• Establish metrics and reporting framework for board-level IR updates

Days 61-90: Validation and Board Readiness

• Conduct your first tabletop exercise with full IR team participation
• Document exercise findings and create an improvement action plan
• Prepare your first board-level IR readiness briefing
• Update the IR plan based on tabletop findings
• Establish a quarterly review cadence for the IR plan and exercise schedule
• Create an evidence repository for compliance audits -- SOC 2 readiness, ISO 27001, or PCI DSS
• File the plan with your cyber insurance carrier if required by your policy

Board Reporting: Translating Technical Readiness Into Business Confidence

Your board does not care about YARA rules or memory forensics tools. They care about three questions: Are we prepared? How fast can we respond? What is our exposure? Your IR reporting to the board should answer those questions concisely.

Quarterly Board IR Metrics

• IR plan status -- Current, tested, and approved (with last review date and next exercise date)
• Mean time to detect (MTTD) -- How long from compromise to detection, based on exercises and real incidents
• Mean time to contain (MTTC) -- How long from detection to containment
• Tabletop exercise results -- Summary of last exercise, key findings, and remediation status
• External readiness -- Status of retainer agreements, insurance coverage, and legal counsel engagement
• Incident summary -- Number of incidents by severity, with trends over time

Present this as a one-page dashboard, not a 30-page report. Boards that receive clear, consistent security reporting make better risk decisions and provide stronger support when you need budget for improvements.

Common Mistakes That Undermine IR Programs

• Plan exists but nobody knows where it is -- Your IR plan must be accessible offline. If your document management system is compromised, can the team still access the plan?
• Contact information is outdated -- People change roles and phone numbers. Verify your contact list quarterly. An IR plan that calls a disconnected number is useless
• No executive authority defined -- When the incident commander says "take production offline," who has the authority to approve that? Define this before the crisis
• Treating the plan as a compliance artifact -- An IR plan written solely to pass audit and never exercised will fail when tested by a real attacker
• Skipping legal involvement -- Your legal team must be part of IR planning from day one. Notification obligations, privilege considerations, and regulatory requirements shape every aspect of response
• No plan for internal communications -- Employees will talk. If they do not hear from leadership, they will fill the vacuum with speculation. Have an internal messaging plan ready

How This Connects to Your Broader Security Program

Incident response does not exist in isolation. It connects to every other security capability in your organization. Your zero trust architecture limits blast radius. Your vulnerability management program reduces the attack surface. Your access management processes ensure compromised credentials have limited reach.

For organizations building their security program holistically, Lorikeet Security's Defensive Security Bundle ($39,500/yr) includes IR planning, SOC-as-a-Service for continuous monitoring and detection, and threat intelligence to inform your preparation efforts. It is designed for organizations that need detection-through-response capability without building a full internal SOC.

If you need offensive validation alongside your defensive program -- penetration testing to verify your detection rules actually fire, social engineering assessments to test your human response, and red team exercises to probe your perimeter -- the Full Stack Bundle ($99,000/yr) combines offensive and defensive capabilities with compliance support.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.