Incident Response Lifecycle
The NIST incident response lifecycle (SP 800-61) defines six phases:
- Preparation: Develop policies, procedures, and tools; train the team; establish communication channels
- Detection and Analysis: Identify and confirm incidents; determine scope and severity; prioritize response
- Containment: Limit the spread and impact of the incident; preserve evidence
- Eradication: Remove the threat from the environment; address root cause
- Recovery: Restore systems to normal operation; verify integrity
- Post-Incident Activity: Document lessons learned; improve processes and controls
The preparation phase is the most important — organizations that invest in preparation respond faster and more effectively to incidents. Incident response capability cannot be built during an incident.
Plan Development
Incident Classification
Define incident severity levels with clear criteria and response requirements:
- Critical (P1): Active breach, ransomware, or significant data exfiltration. Immediate response; executive notification; potential regulatory notification.
- High (P2): Suspected breach, significant malware infection, or major service disruption. Response within 1 hour; management notification.
- Medium (P3): Policy violation, minor malware, or suspicious activity. Response within 4 hours; team lead notification.
- Low (P4): Minor security events, failed login attempts, policy violations. Response within 24 hours; standard ticketing.
Playbooks
Develop specific playbooks for the most likely incident types: ransomware, data breach, DDoS attack, insider threat, physical security incident, and supply chain compromise. Each playbook should include: detection indicators, initial triage steps, containment procedures, eradication steps, recovery procedures, and communication templates.
Communication Plan
Define communication procedures for each severity level: who is notified, when, through what channels, and with what information. Include: internal escalation paths, customer notification procedures, regulatory notification requirements, and media/public relations procedures.
Team Structure
Incident Response Team (IRT)
Core IRT roles:
- Incident Commander: Coordinates the overall response; makes key decisions; manages communication
- Technical Lead: Leads technical investigation and remediation
- Forensics Analyst: Collects and analyzes evidence; maintains chain of custody
- Communications Lead: Manages internal and external communications
- Legal/Compliance: Advises on regulatory requirements and legal obligations
On-Call Rotation
Security incidents occur at any time. Establish an on-call rotation with clear escalation procedures. On-call personnel must be reachable 24/7 and able to respond within defined timeframes.
External Resources
Establish relationships with external resources before incidents occur: incident response retainer (IR firm on standby), legal counsel with cybersecurity expertise, cyber insurance provider, and law enforcement contacts (FBI, CISA).
Ransomware Response
Ransomware is the most common and disruptive cyber incident type. Specific response procedures:
Immediate Actions
- Isolate affected systems from the network immediately — prevent spread
- Preserve evidence — do not power off systems (memory forensics may be needed)
- Identify the ransomware variant and check for known decryptors (No More Ransom project)
- Assess the scope — which systems are affected, what data is at risk
- Notify executive leadership and legal counsel
- Engage IR retainer if needed
Recovery Decision
Evaluate recovery options: restore from offline backups (preferred), use decryptor if available, or negotiate with attackers (last resort, not recommended). Verify backup integrity before beginning recovery — some ransomware variants target backups.
Backup Requirements
Effective ransomware recovery requires: offline or immutable backups that cannot be encrypted by ransomware, regular backup testing to verify recoverability, and documented recovery procedures. The 3-2-1 backup rule: 3 copies, 2 different media types, 1 offsite.
Regulatory Notification Requirements
Many regulations require notification of security incidents within specific timeframes:
- GDPR: 72 hours to supervisory authority for breaches affecting EU residents
- HIPAA: 60 days to HHS and affected individuals for breaches of PHI
- PCI DSS: Immediate notification to card brands and acquiring bank
- SEC (public companies): 4 business days for material cybersecurity incidents
- State breach notification laws: Vary by state; typically 30–90 days
- CISA (critical infrastructure): 72 hours for significant cyber incidents; 24 hours for ransomware payments
Know your notification requirements before an incident. Missed notification deadlines can result in regulatory penalties in addition to the incident itself.
Testing & Exercises
Tabletop Exercises
Tabletop exercises simulate incident scenarios through discussion — no actual systems are affected. The team walks through their response to a hypothetical incident, identifying gaps in procedures, communication, and decision-making. Most cost-effective testing method; should be conducted quarterly.
Functional Exercises
Functional exercises test specific incident response capabilities in a simulated environment. More resource-intensive than tabletop exercises; conducted annually or semi-annually.
Red Team Exercises
Red team exercises simulate real attacks against production systems to test detection and response capabilities. The highest-fidelity test; requires careful scoping to avoid unintended impact. Conducted annually for mature security programs.
Backup Recovery Testing
Test backup recovery procedures quarterly. Verify that backups are complete, uncorrupted, and can be restored within the required RTO. Untested backups are unreliable — many organizations discover backup failures during actual incidents.
Post-Incident Review
Post-incident reviews (also called after-action reviews or lessons learned) are the most valuable improvement activity in incident response. Key questions:
- What happened? (Timeline of events)
- What worked well in the response?
- What could have been done better?
- What was the root cause of the incident?
- What controls failed or were missing?
- What changes will prevent recurrence?
Post-incident reviews must result in specific, assigned action items with deadlines. Reviews that produce observations without action items do not improve security. Track action item completion and report progress to leadership.