Your Incident Response Plan

The worst time to figure out who to call, what to do, and what to say is when your SIEM is screaming, the CEO is calling, and the attacker is still in your network. Every organization that’s been through a breach says the same thing afterward: “We wish we’d planned for this.” The ones who weathered it best are the ones who had a plan, rehearsed it, and knew their roles before the alarms went off.

An incident response plan isn’t a binder on a shelf. It’s a living playbook that tells your team exactly what to do in the first hour, the first day, and the first week of a security incident. Here’s how to build one that works when everything else is breaking.

DO / DON’T

DO:

• Write the plan before you need it — Plans written during incidents are reactive, incomplete, and panicked.
• Define roles and responsibilities explicitly — Name the incident commander, the communications lead, the technical lead, and the legal contact. Names, not titles.
• Include communication templates — Pre-drafted notifications for executives, customers, regulators, and media. You won’t write well under pressure.
• Preserve evidence first, remediate second — You can’t investigate what you’ve already overwritten. Evidence preservation is step one.
• Run tabletop exercises at least annually — A plan that hasn’t been tested is a guess. Tabletops expose gaps before real incidents do.
• Update the plan after every incident and exercise — Lessons learned that don’t change the plan are lessons ignored.

DON’T:

• Don’t assume it won’t happen to you — Every breached organization assumed the same thing. Plan for when, not if.
• Don’t make the plan so long nobody reads it — If the IR plan is 200 pages, nobody will open it during an incident. Keep the operational playbook concise.
• Don’t let the IR plan live only in your network — If the network is compromised, you can’t access the plan. Print copies. Store copies offline and off-network.
• Don’t communicate incident details over compromised channels — If the attacker is in your email, don’t discuss the investigation over email. Use out-of-band communication.
• Don’t skip the legal team — Breach notification, evidence handling, regulatory reporting, and privilege considerations all require legal guidance.

The Six Phases

NIST SP 800-61 Rev. 2 defines the incident response lifecycle. This is the authoritative framework, and it breaks into six phases.

Phase 1: Preparation

Preparation is everything you do before an incident occurs. It’s the most important phase because it determines how effective every other phase will be.

Team structure:

• Incident Commander (IC) — Owns the overall response. Makes decisions about containment, communication, and escalation. One person, one authority.
• Technical Lead — Directs the technical investigation and remediation. Works with the IR team on forensics, containment, and eradication.
• Communications Lead — Manages all internal and external communications. Coordinates with legal, PR, and executive leadership.
• Legal Counsel — Advises on breach notification, regulatory obligations, evidence preservation, and attorney-client privilege.
• Executive Sponsor — Senior leader with authority to approve spending, authorize system shutdowns, and communicate with the board.

Preparation checklist:

• [ ] IR plan documented and distributed
• [ ] Roles assigned with names and contact information (including personal phone numbers)
• [ ] Out-of-band communication channel established (Signal group, dedicated phone bridge, non-corporate chat)
• [ ] Evidence collection tools ready (forensic imaging tools, write blockers, chain of custody forms)
• [ ] Relationships established with external resources (IR retainer firm, legal counsel, law enforcement contacts)
• [ ] Logging and monitoring in place to detect incidents (see the logging guide)
• [ ] Asset inventory current (you can’t investigate what you don’t know exists)
• [ ] Contact lists for CISA, FBI IC3, sector ISAC, and relevant regulatory bodies

Phase 2: Detection and Analysis

Something triggered the alarm. Now you need to determine if it’s a real incident, how bad it is, and what’s affected.

Initial triage:

• What was the detection source? SIEM alert, endpoint detection, user report, external notification?
• What systems are affected?
• What type of incident? Malware, unauthorized access, data exfiltration, ransomware, denial of service, insider threat?
• What’s the initial scope? Single system, segment, or enterprise-wide?
• What’s the initial severity? Use a predefined severity scale.

Severity levels:

Analysis:

• Collect initial evidence: logs, alerts, network captures, memory images. Document everything with timestamps.
• Determine indicators of compromise (IOCs): IP addresses, domains, file hashes, registry keys, user accounts.
• Cross-reference IOCs against threat intelligence: CISA Alerts, MITRE ATT&CK, VirusTotal, your sector ISAC.
• Determine the attack timeline: when did the compromise start, how did the attacker get in, what have they done since?

Phase 3: Containment

Stop the bleeding without destroying evidence.

Short-term containment (minutes to hours):

• Isolate compromised systems from the network — disable network ports, modify firewall rules, or pull cables. Do not power off systems unless absolutely necessary (powering off destroys volatile memory evidence).
• Block known malicious IPs, domains, and hashes at the firewall and endpoint level.
• Disable compromised accounts. Reset credentials.
• If the attacker is in your email or collaboration tools, move IR communications to the out-of-band channel immediately.

Long-term containment (hours to days):

• Stand up clean systems to replace compromised ones if production must continue during investigation.
• Apply temporary mitigations: additional monitoring, tighter access controls, network segmentation changes.
• Continue monitoring for attacker response to containment — sophisticated attackers may have multiple access paths and will attempt to re-establish access.

Evidence preservation during containment:

• Forensic image compromised systems before any remediation. NIST SP 800-86 provides forensic guidance.
• Maintain chain of custody documentation for all evidence. Date, time, who collected it, where it’s stored, hash values.
• Preserve logs from all relevant systems: SIEM, endpoint, firewall, authentication, DNS, proxy.

Phase 4: Eradication

Remove the attacker’s presence entirely.

• Remove malware, backdoors, and persistence mechanisms from all compromised systems.
• Patch the vulnerability that enabled initial access.
• Reset all potentially compromised credentials — not just the ones you’ve confirmed. If in doubt, reset it.
• Review for additional persistence: scheduled tasks, cron jobs, startup scripts, new accounts, modified configurations, web shells.
• If the level of compromise is uncertain, rebuild systems from known-good images rather than cleaning in place. Cleaning is faster; rebuilding is more certain.

Phase 5: Recovery

Bring systems back to normal operations with confidence that the threat is eliminated.

• Restore from known-good backups or rebuild from images. Verify backup integrity before restoration.
• Re-introduce systems to the network incrementally. Monitor each system closely for signs of reinfection.
• Increase monitoring sensitivity during recovery. Lower alert thresholds temporarily.
• Verify that all patches, configuration changes, and credential resets are in place before returning to normal operations.
• Define “return to normal” criteria — what specific conditions must be met before the incident is considered closed?

Phase 6: Lessons Learned

The most skipped phase and the most valuable one.

Conduct a post-incident review (blameless postmortem) within two weeks of incident closure. Include all parties who participated in the response.

Questions to answer:

• What happened, and when? Build a complete timeline.
• How was the incident detected? Could we have detected it sooner?
• What went well in the response? What should we keep doing?
• What didn’t work? What slowed us down?
• Were roles and responsibilities clear? Did the communication plan work?
• What changes to the IR plan, technical controls, monitoring, or processes are needed?

Document the findings. Update the IR plan. Implement the improvements. If the lessons learned review doesn’t result in changes, you didn’t learn anything — you just held a meeting.

Communication Plan

Internal Communication

• Executive leadership — Notify within one hour for SEV-1/SEV-2. Include: what happened, what’s affected, what we’re doing, what we need. Keep it brief.
• Board of directors — For significant incidents. Legal counsel advises on timing and content.
• All employees — Only what they need to know, when they need to know it. Premature or excessive internal disclosure creates panic and leaks.

External Communication

• Regulators — GDPR: 72 hours to supervisory authority. HIPAA: 60 days to HHS OCR. PCI-DSS: notify your acquiring bank. Know your obligations before the incident.
• Law enforcement — FBI IC3 for cybercrime. CISA for voluntary incident reporting and technical assistance. Your sector ISAC for threat intelligence sharing.
• Customers/affected parties — Legal counsel guides timing and content. Be honest, be specific about what was affected, and tell people what you’re doing to fix it.
• Media — If it’s going to become public (and assume it will), control the narrative with a prepared statement. Communications lead and legal counsel draft together.

Pre-draft notification templates for each audience. During an incident, you’ll fill in specifics — not write from scratch.

Tabletop Exercises

A tabletop exercise walks the IR team through a simulated incident scenario without touching real systems. It’s a discussion-based exercise that tests decision-making, communication, and plan completeness.

How to run one:

1. Define a realistic scenario relevant to your organization (ransomware, data breach, insider threat, supply chain compromise)
2. Assign roles — participants play their real IR roles
3. Present the scenario in stages (inject new information every 15-20 minutes)
4. At each stage, ask: What do we do? Who do we call? What information do we need?
5. Document gaps, disagreements, and unclear responsibilities
6. Conduct a debrief immediately after

Run tabletops at least annually. Quarterly is better. Vary the scenarios. Include executives in at least one per year — they need to practice their decision-making too. CISA provides tabletop exercise packages (CTEPs) that you can use as starting points.

The incident response plan is your playbook for the worst day. Write it now. Assign roles. Draft communication templates. Run a tabletop exercise. Then put the plan somewhere you can reach it when your network is on fire — printed, offline, and in the hands of everyone who needs it. The first hour of an incident determines the outcome. Make sure your team knows what to do before the clock starts.