Every cybersecurity framework, insurance carrier, and compliance standard requires an incident response plan. So most businesses create one — a 40-page document written by a consultant, reviewed once, filed in a SharePoint folder, and never touched again.
Then an incident happens. The ransomware hits at 11 PM on a Friday. The CEO's email is compromised and has been sending fraudulent invoices for three days. A disgruntled employee downloaded the entire customer database before their last day.
Nobody can find the plan. Nobody remembers what it says. Nobody knows who to call. The response is chaotic, slow, and makes the situation worse.
An incident response plan only works if people can execute it under stress. Here's how to build one that passes that test.
The NIST Incident Response Framework
The NIST Computer Security Incident Handling Guide (SP 800-61) defines four phases of incident response. This framework works for organizations of any size:
Phase 1: Preparation
Preparation is everything you do before an incident to ensure you can respond effectively. This is where most organizations fail — not during the incident, but in the months and years before it.
People:
- Designate an Incident Response Team (IRT) with defined roles. For a small business, this might be 3-5 people, not a dedicated team — but each person must know their role.
- Incident Commander — Makes decisions, coordinates the response, communicates with leadership
- Technical Lead — Manages the technical investigation and containment
- Communications Lead — Handles internal and external communications
- Legal/Compliance — Advises on notification requirements and evidence preservation
Contact Lists: Create a physical (printed) contact card with:
- IRT member names, cell phones, and personal email addresses
- Managed security provider (Layer27) emergency number
- Cyber insurance carrier and policy number
- Legal counsel specializing in data privacy/breach response
- Law enforcement contacts (FBI IC3, local field office)
- Key vendor contacts (cloud providers, critical SaaS platforms)
Why physical? Because if your email is compromised and your file server is encrypted, you can't access a digital contact list.
Technical Preparation:
- Deploy EDR and logging that provide the telemetry needed for investigation
- Ensure backups are immutable, tested, and accessible during a crisis
- Document your network architecture, critical systems, and data flows
- Establish an out-of-band communication channel (e.g., a Signal group or personal email thread) for use when primary systems are compromised
Phase 2: Detection and Analysis
You can't respond to what you can't detect. This phase covers how incidents are identified, verified, and categorized.
Detection Sources:
- MDR/SOC alerts (your most reliable source)
- Employee reports ("I clicked something and now my screen looks weird")
- Vendor notifications ("We detected unauthorized access to your account")
- Automated alerts (failed login attempts, unusual data transfers, antivirus detections)
- External reports (customers receiving phishing from your domain, data found on dark web)
Initial Triage Questions: When a potential incident is reported, the Incident Commander should rapidly determine:
- What happened? — What systems are affected? What was observed?
- When did it start? — Is this ongoing or historical?
- What data could be at risk? — Does this system handle PII, PHI, financial data, CUI?
- Is it contained? — Is the threat still active and spreading?
- Who is affected? — Customers, employees, partners?
Severity Classification:
- Critical — Active data exfiltration, ransomware spreading, business operations halted
- High — Confirmed compromise of systems containing sensitive data, threat contained but not eradicated
- Medium — Suspicious activity detected, investigation underway, no confirmed data impact
- Low — Policy violation, minor malware detection on single endpoint, no data at risk
Phase 3: Containment, Eradication, and Recovery
This is where most plans fail by being too vague. "Contain the threat" isn't actionable under pressure. Specific, step-by-step procedures are essential.
Short-Term Containment (first hour):
- Isolate affected systems from the network (disable network adapter, remove from switch, quarantine via EDR)
- Disable compromised accounts
- Block known malicious IPs and domains at the firewall
- Preserve forensic evidence (do not reboot, wipe, or reinstall yet)
- Activate out-of-band communication channel
Long-Term Containment:
- Rebuild or re-image compromised systems from known-good sources
- Reset credentials for all accounts that may have been exposed (not just the obviously compromised ones)
- Apply patches or configuration changes that address the attack vector
- Increase monitoring on systems adjacent to the compromise
Eradication:
- Remove all attacker access — backdoors, persistence mechanisms, compromised accounts
- Verify no additional systems are compromised through threat hunting
- Address the root cause (patching the vulnerability, closing the phishing gap, fixing the misconfiguration)
Recovery:
- Restore affected systems from verified backups
- Bring systems back online in a controlled sequence, starting with the most critical
- Monitor recovered systems closely for signs of re-infection
- Validate that business operations are functioning normally
Phase 4: Post-Incident Activity
The incident isn't over when systems are restored. Post-incident activity determines whether you learn from the experience or repeat it.
Within 48 hours:
- Conduct a blameless post-mortem with all IRT members
- Document the timeline: when the incident started, when it was detected, when containment began, when it was resolved
- Identify what worked, what didn't, and what needs to change
- Update the incident response plan based on lessons learned
Within 30 days:
- Complete all required notifications (regulatory, contractual, insurance)
- Implement long-term remediation for root causes
- Update security controls, monitoring rules, or training based on findings
- Brief leadership on the incident, response, and improvements
Making the Plan Actionable
The One-Page Quick Reference
Distill your entire plan into a single-page quick reference card that covers:
- Severity classification criteria
- First 5 actions for each severity level
- Contact information for IRT members and key external parties
- Out-of-band communication channel details
Print this card. Distribute it to every IRT member. Post it in the server room. Put it in the IRT members' phone cases. When adrenaline is pumping, nobody is going to read 40 pages — but they will read one.
Tabletop Exercises
Run a tabletop exercise at least twice a year. Present a realistic scenario and walk through the response step by step:
- "It's Friday at 4:45 PM. A staff member reports that their files have been renamed with a .locked extension and a ransom note is on their desktop. What do you do?"
- "Your cloud security tool alerts that an admin account logged in from a foreign country at 3 AM and downloaded 50,000 customer records. What do you do?"
These exercises expose gaps in your plan, build muscle memory for the response team, and satisfy compliance requirements for plan testing.
Layer27's Role in Your Response
For Protect Pro clients, Layer27 serves as an extension of your incident response team:
- Our MDR team provides the detection and initial containment that starts the response process
- Our 24/7/365 SOC ensures incidents are caught immediately, regardless of when they occur
- Our incident response specialists guide containment and eradication
- We provide forensic support and evidence preservation for legal and insurance purposes
- We help prepare regulatory notifications and insurance claims documentation
An incident response plan you can't execute is worse than no plan at all — it creates false confidence. Contact Layer27 to build a practical, tested incident response capability for your organization.