Incident Response Lifecycle

A Structured Approach to Chaos

Incident response is inherently chaotic — an active breach generates pressure, confusion, and conflicting priorities. The NIST framework (SP 800-61) provides a structured lifecycle that ensures nothing is forgotten and every action is deliberate. The six phases are not strictly linear; they overlap and iterate, but each has distinct objectives and outputs.

Phase 1: Preparation

Preparation is the phase that determines whether the response succeeds or fails. It includes:

• Incident response plan — documented procedures for each incident type
• Communication plan — who is notified, when, and through what channel
• Roles and responsibilities — incident commander, technical lead, communications lead, scribe
• Tooling — forensic tools, communication platforms, case management system
• Training — tabletop exercises, red team simulations, and cross-functional drills
• Contact lists — internal teams, external partners, law enforcement, cyber insurance

The preparation phase is measured by readiness, not activity. A team that has never tested its plan is not prepared.

Phase 2: Detection and Analysis

This phase begins when an alert is generated and ends when the incident is confirmed and scoped. Key activities:

• Triage — is this a true positive? (Covered in Alert Triage and Escalation)
• Scope assessment — which systems are affected? What data is at risk?
• Classification — what type of incident is this? (malware, data breach, insider threat, DDoS)
• Severity assignment — what is the business impact?
• Evidence preservation — ensure logs, memory, and disk images are captured before they are lost

The output of this phase is a confirmed incident with an initial scope assessment and severity rating.

Phase 3: Containment

Containment stops the attack from spreading and limits damage. The strategy depends on the incident type:

• Short-term containment — isolate affected hosts from the network, block malicious IPs at the firewall, disable compromised accounts
• Long-term containment — apply temporary fixes that allow business operations to continue while eradication is planned
• Evidence preservation — containment must not destroy evidence. Isolating a host preserves disk state; shutting it down destroys memory.

# Containment actions
# Isolate a host from the network (Linux)
ip link set eth0 down

# Block a malicious IP at the firewall
iptables -A INPUT -s 185.220.101.4 -j DROP

# Disable a compromised account
usermod -L compromised_user

The containment decision is a trade-off between business impact and security. Isolating a critical production server stops the attack but also stops business operations. The incident commander must weigh these factors with input from business stakeholders.

Phase 4: Eradication

Eradication removes the attacker's presence from the environment:

• Remove malware — delete malicious files, remove persistence mechanisms (registry keys, cron jobs, startup items)
• Patch vulnerabilities — close the hole the attacker exploited
• Reset credentials — rotate all potentially compromised passwords, API keys, and tokens
• Rebuild affected systems — in some cases, the only way to ensure complete eradication is to rebuild from known-good images

Eradication must be thorough. A single surviving persistence mechanism allows the attacker to regain access.

Phase 5: Recovery

Recovery restores normal operations:

• Restore systems — bring cleaned or rebuilt systems back online
• Monitor — enhanced monitoring for signs of re-compromise
• Validate — verify that systems are functioning correctly and the attacker is gone
• Communicate — notify stakeholders that the incident is resolved

Recovery is not complete until the system has been monitored for a defined period (typically 14–30 days) with no signs of re-compromise.

Phase 6: Lessons Learned

The lessons learned phase converts the incident into improvement:

• Timeline review — reconstruct the full attack timeline
• What worked — which detections, tools, and processes performed well?
• What failed — where were the gaps? What was missed?
• Action items — specific improvements with owners and due dates
• Plan updates — revise the incident response plan based on lessons learned

This phase is the most commonly skipped and the most valuable. Without it, the same incident will happen again.

Driving Decisions with Objective Criteria

Severity scoring determines the scale of the response — who is notified, how fast they are notified, and what resources are allocated. A severity scoring matrix uses objective criteria so that any assessor reaches the same conclusion.

Severity Criteria

Critical (P1)

• Active data breach involving PII, PHI, or financial data
• Ransomware on any production system
• Confirmed compromise of domain controllers or other critical infrastructure
• Active data exfiltration detected
• Threat to life safety (OT/ICS environments)

High (P2)

• Confirmed malware execution on production systems
• Compromise of user credentials with administrative access
• Unauthorized access to sensitive data (not yet exfiltrated)
• Persistent attacker presence (backdoors, C2 communication)

Medium (P3)

• Suspicious activity that may indicate reconnaissance or initial access
• Phishing emails reported by multiple users
• Policy violations with security implications
• Vulnerability exploitation attempts (not confirmed)

Low (P4)

• Single phishing email reported
• Failed attack attempts blocked by security controls
• Informational alerts with no confirmed impact

The Scoring Matrix

A scoring matrix combines multiple factors to produce a severity rating:

The weighted score determines the severity. This removes subjectivity — two assessors using the same matrix will reach the same severity rating.

Communication Plans

The communication plan defines who is notified at each severity level, through what channel, and within what timeframe:

Critical (P1)

• Within 15 minutes: Incident commander, SOC manager, CISO
• Within 30 minutes: Legal counsel, cyber insurance carrier
• Within 1 hour: Executive leadership, board notification (if data breach)
• Within 4 hours: Affected customers (if PII breach), regulators (if required by law)
• Within 72 hours: Public disclosure (if required by regulation)

High (P2)

• Within 30 minutes: Incident commander, SOC manager
• Within 1 hour: CISO, legal counsel
• Within 4 hours: Affected business unit leaders

Medium (P3)

• Within 4 hours: SOC manager
• Within 24 hours: CISO (summary)

Low (P4)

• Next business day: SOC team (batch summary)

Regulatory Notification Requirements

Different regulations impose different notification timelines:

• GDPR — 72 hours to the supervisory authority if the breach is likely to result in risk to individuals
• HIPAA — 60 days to affected individuals, HHS, and media (if 500+ individuals affected)
• PCI DSS — Immediately to the payment brands and acquiring bank
• SEC — 4 business days to the SEC for material cybersecurity incidents (new rule, 2023)
• State laws — vary by state; most require notification within 30–60 days

The communication plan must account for these requirements and include pre-drafted notification templates that can be customized quickly.

Communication Principles

1. Accuracy over speed — it is better to communicate later with correct information than immediately with wrong information
2. Need to know — share details only with those who need them; avoid unnecessary disclosure
3. Consistent messaging — all external communications should be coordinated through a single channel (typically the communications lead)
4. Document everything — all communications are logged for legal and regulatory purposes
5. No speculation — communicate what is known, what is suspected, and what is being investigated. Do not speculate about causes or blame.

From Plan to Action

The incident response plan is a document. The response is an execution. The gap between the two is where incidents are won or lost. Effective execution requires clear roles, disciplined communication, and real-time documentation.

The Incident Command Structure

Incident Commander (IC)

The single person responsible for the overall response. The IC does not investigate — they coordinate. Their responsibilities:

• Set the response strategy and priorities
• Assign roles and tasks
• Communicate with stakeholders
• Make go/no-go decisions (e.g., isolate a critical server)
• Ensure documentation is maintained

Technical Lead

Directs the technical investigation and containment. The technical lead:

• Determines the attack vector and scope
• Directs containment actions
• Coordinates forensic analysis
• Recommends eradication and recovery steps

Communications Lead

Manages all internal and external communications. The communications lead:

• Drafts stakeholder notifications
• Coordinates with legal on regulatory notifications
• Manages media inquiries (if applicable)
• Ensures consistent messaging

Scribe

Documents everything in real time. The scribe:

• Maintains the incident timeline
• Records all decisions and their rationale
• Logs all actions taken
• Captures meeting notes

The First 30 Minutes

The first 30 minutes of an incident response set the trajectory. A structured approach:

1. 0–5 min: Confirm and declare — confirm the incident, assign the incident commander, declare the severity
2. 5–10 min: Assemble — activate the response team, open the case management system, establish communication channels
3. 10–15 min: Initial scope — what is affected? What is the attack vector? What data is at risk?
4. 15–20 min: Contain — implement short-term containment (isolate hosts, block IPs, disable accounts)
5. 20–30 min: Communicate — notify stakeholders per the communication plan, engage legal if needed

Evidence Preservation

Evidence preservation is critical for both investigation and potential legal proceedings:

• Memory capture — volatile evidence (running processes, network connections, encryption keys) is lost when the host is powered off
• Disk imaging — create a bit-for-bit copy of affected drives before any remediation
• Log collection — preserve all relevant logs (authentication, application, network, security)
• Chain of custody — document who handled evidence, when, and what was done with it

# Memory capture on Linux (using LiME)
insmod lime.ko "path=/mnt/evidence/memdump.lime format=lime"

# Disk imaging (using dd)
dd if=/dev/sda of=/mnt/evidence/diskimage.dd bs=4M conv=noerror,sync

# Calculate hash for integrity verification
sha256sum /mnt/evidence/diskimage.dd > /mnt/evidence/diskimage.dd.sha256

Common Mistakes

1. Destroying evidence — shutting down a host instead of isolating it, deleting logs, or reimaging before capture
2. No clear command — multiple people giving conflicting directions, no single incident commander
3. Poor communication — stakeholders learning about the incident from rumors or media instead of official channels
4. Skipping containment — jumping to eradication without containing first, allowing the attack to spread
5. No documentation — actions taken without recording, making post-incident analysis impossible
6. Premature recovery — bringing systems back online before the attacker is fully eradicated

Tabletop Exercises

The best way to prepare for an incident is to practice. A tabletop exercise walks the team through a simulated incident scenario:

1. Scenario — a realistic attack scenario (e.g., ransomware on a file server, phishing leading to credential compromise)
2. Roles — participants are assigned IR roles (IC, technical lead, communications lead, scribe)
3. Walkthrough — the facilitator presents the scenario in stages; participants discuss what they would do
4. Evaluation — after the exercise, identify gaps in the plan, tooling, and training
5. Improvement — update the plan and schedule follow-up training

Tabletop exercises should be conducted at least quarterly and should cover different incident types to ensure broad preparedness.