Most organizations that have an incident response plan have a document. Whether they have a plan is a different question.

The difference shows up during an actual incident. A document tells you what should happen. A plan tells your specific people what to do right now, with the contacts they need, in a format they can use when systems are down and everyone is stressed. Those aren't the same thing, and the gap between them is where most organizations discover what they're actually working with.

What Most Companies Have

The typical IRP at a small or mid-size organization is a PDF that was written once, during a compliance initiative or a vendor recommendation, and has lived in a shared drive since. It contains:

A statement that the organization takes security seriously
A list of phases ("Preparation, Detection, Containment, Recovery") that mirrors the NIST framework without operationalizing any of them
References to "the IT team" or "the security team" as if those are single people with defined roles and clear authority
A phone number list that includes the CTO's work email and a help desk ticket system
No definition of what constitutes an "incident" versus a "security event"
No pre-drafted communications
No reference to cyber insurance, legal counsel, or external forensics
No evidence it has ever been reviewed, tested, or updated

This document satisfies a checkbox on an audit questionnaire. It doesn't help anyone during an actual breach.

What a Functional Plan Contains

A Definition of "Incident"

Without a clear definition, every phishing email becomes a potential all-hands emergency, and a real breach can go unrecognized because it doesn't fit anyone's mental model. Your plan needs to define:

What constitutes a security event (something that gets logged and monitored)
What constitutes a security incident (something that triggers a response)
What triggers escalation to leadership and external notification

Examples that belong in this section: unauthorized access to a system containing customer data is an incident. An employee clicking a phishing link is an event that may escalate to an incident based on what they entered. A failed login attempt is neither.

Roles with Names, Not Titles

"IT will handle containment" tells you nothing during an incident. Your plan needs named roles with specific responsibilities and — critically — backups for each role:

Incident Commander: Decision authority during the incident. Owns the response timeline, approves communications, decides when to bring in external help. Not necessarily the most technical person — the person with the authority to make calls.

Technical Lead: Owns containment and eradication. Coordinates with forensics if external help is brought in.

Communications Lead: Owns internal and external communications. Drafts notifications. Manages the relationship with your PR/communications firm if you have one.

Legal Liaison: Engages counsel early, manages attorney-client privilege on investigation communications, advises on notification obligations.

Each role needs a primary and a backup. Incidents don't wait for the right person to be available.

A Contact List That Works Offline

When your email system is compromised and your VPN is down, how do you reach the people you need? Your contact list needs to be maintained in a form that survives a systems outage — printed and physically stored, or in a system that doesn't depend on your primary infrastructure.

Contacts that belong on this list, with current information verified at least annually:

All members of your IR team (cell phone, not work email)
Your cyber insurance carrier and your specific policy number (call them early — they often have forensics and legal resources they'll deploy on your behalf)
Your retained legal counsel or the firm you'll call for breach response
Your forensics retainer, if you have one — or two or three firms you've pre-qualified
Your cloud and SaaS providers' security and incident contacts
Your internet service provider's security contact
For regulated organizations: OCR, your state AG's office, or other regulatory contacts you may need to notify

The contact list that exists only in your ticketing system is the one you won't be able to access when you need it.

Escalation Thresholds

Your plan needs to define, specifically, what triggers each level of escalation:

When does an event get escalated from IT to the IR team?
When does the Incident Commander notify leadership?
When do you engage external forensics?
When do you call legal counsel?
When do you notify your cyber insurance carrier?
When do you notify customers, regulators, or the public?

These thresholds should be defined in advance, not decided under pressure. "When it feels serious enough" is not a threshold.

Containment Strategies by Incident Type

Different incidents require different containment approaches, and the right action in one scenario can destroy evidence in another. Your plan should include guidance, at least at a high level, for the incident types most relevant to your environment:

Ransomware: Isolate affected systems immediately. Do not reboot or wipe — preserve evidence for forensics. Check whether backups are also affected before assuming you can restore. Engage forensics before attempting recovery.

Credential compromise: Revoke compromised credentials immediately. Audit what the compromised account had access to and for how long. Check for persistence mechanisms (additional accounts created, forwarding rules set in email).

Data exfiltration: Preserve logs before taking containment action. Determine what data was accessed and from where. Exfiltration is often discovered late — the attacker may have been in the environment for weeks.

Insider threat: Evidence preservation is critical and legally sensitive. Involve legal counsel before taking action. Chain of custody on collected evidence matters.

Pre-Drafted Communication Templates

Writing communications during an incident takes three times longer than you expect. Under pressure, with legal exposure, with customers calling, is not when you want to be writing from scratch.

Your plan should include draft templates for:

Internal all-staff notification ("we are investigating a security incident")
Customer notification (adaptable for different breach types)
Regulatory notification where required by your industry
Media statement if the incident becomes public

These templates don't need to be final — they need to be 80% complete, requiring only the specific facts to be filled in. Getting the structure and legal review done in advance means the only work left is filling in the specifics.

Post-Incident Review Process

The incident ends when the technical response is complete. The review process follows within two weeks and covers:

Timeline reconstruction: what happened, when, and in what sequence
Detection gap analysis: how long was the attacker present before detection?
Response effectiveness: what worked, what didn't, what took longer than it should have
Root cause identification: what allowed this to happen?
Action items with owners and deadlines: what changes will prevent or limit the impact of a similar incident?

The post-incident review is where the IRP improves. An organization that goes through a significant incident and emerges with no documented lessons learned has spent the money and the pain without getting the benefit.

NIST SP 800-61 as a Framework

The NIST Computer Security Incident Handling Guide (SP 800-61 Rev. 2) defines the four-phase IR lifecycle that underlies most IRP frameworks: Preparation, Detection and Analysis, Containment/Eradication/Recovery, and Post-Incident Activity. It's free, it's well-structured, and it's a reasonable starting template for any organization building an IRP from scratch.

The document is a guide, not a template. What it gives you is a framework and a vocabulary. What it doesn't give you is the specific contacts, thresholds, roles, and communication templates that make a plan functional for your organization. That work is yours.

SOURCES

NIST SP 800-61 Rev. 2, Computer Security Incident Handling Guide: csrc.nist.gov/publications/detail/sp/800-61/rev-2/final
CISA, "Incident Response Plan Basics": cisa.gov
SANS Institute, Incident Handler's Handbook: sans.org/reading-room

Want a review of your current incident response plan, or help building one that will actually work when you need it? Schedule a consultation to talk through what your plan needs to include.

What a Real Incident Response Plan Looks Like