CISA Incident & Vulnerability Response Playbooks

Many organizations maintain their own SOC operating methodology and structure. NIST SP 800-61 Rev.2 outlines the standard process for cybersecurity incident response. However, as NIST revised this material, it announced that the document’s guidance would instead be incorpporated into CSF 2.0, since incident resopnse practices vary as widely as the organizations that implement them. Nonetheless, I believe revisiting this now-superseded revision is still valuable-SOC engineers can use this material to review their own playbooks and processes. Therefore, I will walk through the entire process of each response playbook in this article

Table of contents

Incident Response Playbook (Body Text)

Overview of the Incident Response Process

The incident response process begins with “declaring” an incident. In this context, “declaration” doesn’t mean formally declaring a Major Incident under applicable law — it means identifying the incident and communicating it to CISA and agency network defenders. The subsequent sections are organized by phase of the IR lifecycle, and many activities are iterative, continuing to occur and evolve until the incident is closed out.

Triggers that can initiate incident response are varied: automated detection systems or sensor alerts, agency user reports, contractor or third-party ICT service provider reports, internal or external organizational component incident reports or situational awareness updates, third-party reports of network activity tied to known-compromised infrastructure, and analytics or hunt teams identifying potentially malicious activity.

Scope: Use this playbook for incidents involving confirmed malicious cyber activity where a major incident has been declared, or has not yet been reasonably ruled out. Examples: incidents involving lateral movement, credential access, or data exfiltration; network intrusions involving more than one user or system; compromised administrator accounts. It explicitly does NOT apply to: “spills” of classified information believed to result only from unintentional behavior; users clicking phishing emails where no compromise resulted; or commodity malware on a single machine or lost hardware that isn’t likely to cause demonstrable harm to national security, the economy, or public confidence/safety.

Preparation Phase

The goal is to prepare for major incidents before they occur, to mitigate impact on the organization. Before an incident occurs, organizations should define a baseline for systems and networks to understand what “normal” activity looks like — establishing this baseline is what enables defenders to identify deviations. Preparation also covers infrastructure for handling complex incidents (including classified and out-of-band communications), developing and testing courses of action (COAs) for containment and eradication, and establishing means for collecting digital forensics and other evidence. The stated goal of all this is resilient architectures and systems that can maintain critical operations even in a compromised state, and the document notes that active defense measures — such as redirection and monitoring of adversary activity — may also play a role (citing NIST SP 800-160 Vol. 2’s concept of “deception” in a footnote).

In detail, this phase covers nine areas:

• Policies and Procedures: Document IR plans, including a process for designating a coordination lead (incident manager); policies for escalating and reporting major incidents and those affecting agency mission; contingency plans for additional resourcing and “surge support.” Internal notification requirements explicitly include agency leadership — the agency director, CIO, and CISO — as well as the system owner, public affairs, and legal departments.
• Instrumentation: Implement broad telemetry — AV, EDR, DLP, IDPS, various logs, network flows, PCAP, SIEM — to build an accurate picture of infrastructure. Monitor alerts from CISA’s EINSTEIN intrusion detection system and the CDM (Continuous Diagnostics and Mitigation) program.
• Trained Response Personnel: Ensure staff are trained regardless of whether they’re drawn from in-house capability, a parent agency, a third-party organization, or a combination. Conduct regular recovery exercises to test the full organizational continuity of operations plan (COOP) and failover/backup/recovery systems.
• Cyber Threat Intelligence (CTI): Threat indicators are split into three types — atomic indicators (domains, IPs — detect adversary infrastructure), computed indicators (Yara rules, regex — detect known malicious artifacts), and patterns/behaviors (analytics that detect adversary TTPs). Atomic indicators are noted to have a limited “shelf life” since adversaries frequently change infrastructure between campaigns, so the document explicitly recommends favoring TTP-based detection where possible, citing the MITRE ATT&CK framework directly as the resource for this. The primary sharing channel is CISA’s AIS (Automated Indicator Sharing) program; indicators not suited to AIS go through a separate web-based submission system.
• Active Defense: Agencies with advanced capability and staff may redirect adversaries to a sandbox or honeynet system, or use “dark nets,” and implement honeytokens and fake accounts as canaries — enabling defenders to study adversary behavior and TTPs.
• Communications and Logistics: Establish local and cross-agency communication procedures for coordinating major incidents with CISA, define information sharing protocols, define methods for handling classified data if required, and establish out-of-band coordination channels (chat rooms, phone bridges).
• Operational Security (OPSEC): For pervasive compromises (like ransomware) where an adversary might try to undermine defensive measures, the document is specific: segment and manage SOC systems separately from broader enterprise IT, manage sensors via out-of-band means, notify users of compromised systems by phone rather than email, and use hardened workstations for monitoring/response. It explicitly warns against “tipping off” an attacker — e.g., don’t submit malware samples to a public analysis service.
• Technical Infrastructure: Implement capability to contain, replicate, analyze, reconstitute, and document compromised hosts; means for disk and active memory imaging; means for safely handling malware; and a ticketing/case management system that captures affected systems/applications/users, activity type, specific threat groups, adversary TTPs, and impact.
• Detect Activity: Closes the section by directing organizations to use threat intelligence to build rules and signatures that identify incident-related activity and scope its reach.

Detection & Analysis

Explicitly called out as the most challenging aspect of the incident response process — accurately determining whether an incident occurred and, if so, its type, extent, and magnitude across cloud, OT, hybrid, host, and network systems. The document notes the need for procedures to deconflict a suspected incident from authorized activity (e.g., confirming a suspicious event isn’t just a network admin performing routine software updates). CISA, as the government’s lead for asset response, partners with affected agencies throughout this process.

Detailed activity flow:

• Declare Incident: Report to CISA via us-cert.cisa.gov and alert agency IT leadership. CISA can help determine severity and whether it should be declared major. FCEB agencies must promptly report all cybersecurity incidents to CISA, regardless of severity.
• Determine Investigation Scope: Determine the type of access, extent of affected assets, level of privilege the adversary attained, and operational/informational impact.
• Collect and Preserve Data: Collect data from the perimeter, internal network, and endpoints — audit, transaction, intrusion, connection, system performance, and user activity logs. Capture memory and disk images when endpoint forensics is needed. All of this should be preserved as “best evidence” for potential law enforcement use.
• Perform Technical Analysis: Correlate information and assess anomalous activity against a known baseline to determine root cause. The stated goal is to examine the breadth of available data sources to uncover at least some part of the attack chain, if not all of it.
• Correlate Events and Document Timeline: Correlate logs, use Table 1 (below) as a reference, and build a timeline of all findings.
• Identify Anomalous Activity: Emphasizes that adversaries often use legitimate, native OS utilities and scripting languages once they gain a foothold, to avoid detection — this “living off the land” activity should be identified as a deviation from baseline.
• Identify Root Cause and Enabling Conditions: Identify both the root cause and the conditions that enabled the adversary to access and operate in the environment — this informs triage and post-incident activity.
• Gather Incident Indicators: Document indicators for correlative analysis; notes that indicators as standalone artifacts are especially valuable in the early stages of IR.
• Analyze for Common Adversary TTPs: Explicitly defines TTPs as answering “why” (tactics — the technical objective), “what” (techniques — the mechanisms used), and “how” (procedures — exactly how a specific result is achieved). Responding to TTPs, it notes, lets defenders hypothesize the adversary’s most likely next move.

Table 1 — Example Adversary Tactics, Techniques, and Relevant Log/Event Data

Based on MITRE ATT&CK, mapping Tactic → representative Techniques → relevant Log/Event sources → example Indicators.

• Validate and Refine Investigation Scope: Provides a list of key questions to guide this: What was the initial attack vector? How is the adversary accessing the environment? Are they exploiting vulnerabilities for access/privilege? How is C2 maintained? What persistence mechanism is in use? What accounts/privilege levels are compromised? What reconnaissance method is being used? Is lateral movement suspected, and how? Has data been exfiltrated, and via what mechanism?
• Third-Party Analysis Support: If needed, agencies must first activate the FNA (Federal Network Authorization) they have on file with CISA. NSA’s NSCAP program provides a list of accredited third-party IR providers.
• Adjust Tools: Incorporate IOC signatures into tools, while explicitly acknowledging the limitation that adversaries can introduce new tools or modify existing ones to subvert IOC-centric response.

Containment

Explicitly flagged as a high priority, especially for major incidents. The goal is to remove the adversary’s access to prevent further damage. The document stresses that the containment strategy should match the scenario — containing a sophisticated adversary using fileless malware looks different from containing ransomware.

Considerations: additional adverse impact on mission operations/service availability, the duration/resources/effectiveness of containment (full vs. partial), and impact on evidence collection/preservation. It notes some adversaries actively monitor defensive measures and shift methods to evade detection — so defenders should build as complete a picture as possible before acting, to avoid “tipping off” the adversary.

Key containment activities: isolating systems/network segments (while considering how to keep providing mission-critical services during this phase), capturing forensic images for legal evidence, updating firewall filtering, blocking unauthorized access/malware sources, closing specific ports/mail servers, rotating admin passwords/private keys/service account secrets and revoking privileged access, and — explicitly limited to advanced SOCs — redirecting the adversary to a sandbox to observe them.

If new signs of compromise appear, return to technical analysis; upon successful containment (no new signs), preserve evidence, adjust detection tools, and move to eradication/recovery.

Eradication & Recovery

The goal is to remove artifacts of the incident and mitigate the exploited vulnerabilities or conditions, restoring normal operations. Before moving to eradication, all persistent access must be accounted for, adversary activity sufficiently contained, and evidence collected — the document notes this is often iterative. It also stresses coordinating with ICT providers, commercial vendors, and law enforcement before beginning eradication.

• Execute Eradication Plan: Warns that threat actors often have multiple persistent backdoors and can hop back into “clean” areas if eradication isn’t well orchestrated — so plans must be well formulated before execution. If the adversary exploited a specific vulnerability, the document explicitly directs starting the Vulnerability Response Playbook alongside eradication activities. Activities include remediating all infected environments (cloud/OT/hybrid/host/network), reimaging from gold sources, rebuilding hardware if rootkits were involved, and installing patches.
• Recover System(s) and Services: Explicitly names “confirming remediation was successful” as a main challenge of this phase. Includes reconnecting systems, tightening perimeter security (firewall rulesets, zero trust access rules), thorough testing, and monitoring for abnormal behavior. It emphasizes performing an independent test or review to validate the recovery plan actually succeeded.

Post-Incident Activities

The goal is documentation, informing leadership, hardening the environment, and applying lessons learned.

• Adjust Sensors, Alerts, and Log Collection: Add enterprise-wide detections for the TTPs that succeeded, and close blind spots. Explicitly states that advanced SOCs should emulate adversary TTPs to verify new countermeasures actually work — and adds that this testing should be closely coordinated with the blue team so it isn’t mistaken for real adversary activity.
• Finalize Reports: Provide post-incident updates as required by law/policy.
• Perform Hotwash: A lessons-learned review covering six objectives — confirming root cause was eliminated, identifying infrastructure problems, identifying organizational policy/procedure problems, clarifying roles/responsibilities, identifying training needs, and improving the tools needed for protection/detection/analysis/response.

Coordination

Explicitly framed as foundational to effective incident response. The document acknowledges cyber defense capability varies widely across agencies, so the degree of coordination varies too. As a baseline, every cybersecurity incident must be reported to CISA. Agencies can supplement their own IR capability with CISA services (threat hunting, analytics, malware analysis, CTI, etc.).

For major incidents, CISA is explicitly the “front door” for asset response. At the government-wide level, response splits into four concurrent Lines of Effort (LOEs): Threat Response (DOJ/FBI/NCIJTF), Asset Response (DHS/CISA), Intelligence Support (ODNI/CTIIC), and the affected agency’s own response. It closes by noting CISA, as a single coordination point, eases the burden on FCEB agencies.

Vulnerability Response Playbook (Body Text)

Starts from the premise that focusing on vulnerabilities already actively exploited in the wild is one of the simplest and most effective ways to prioritize vulnerability response. The document explicitly draws a line: this playbook doesn’t replace an agency’s existing vulnerability management program — it builds on top of it. The rationale for standardization is that it lets CISA and other agencies understand the impact of these urgent, high-priority vulnerabilities across the federal government.

Scope: Only vulnerabilities “actively exploited in the wild” — i.e., observed being used by adversaries for unauthorized entry. Most will have a CVE identifier, but new vulnerabilities without one yet (zero-days) or those arising from misconfigurations can also be in scope.

Preparation

States that effective vulnerability response is built on strong vulnerability management. This means robust asset management covering three categories: systems/networks the agency operates directly, systems/networks involving partnerships with other organizations, and systems/networks operated by others (cloud, contractor, and service provider systems). It stresses tracking operating systems and applications across all systems to understand vulnerability relevance in real time.

Vulnerability Response Process

States it follows the four standard phases of a vulnerability management program: Identification, Analysis (Evaluation), Remediation, Reporting.

Identification

Calls for proactively monitoring threat feeds, naming three sources:

• CISA resources: US-CERT’s NCAS (National Cyber Awareness System) weekly bulletins, and the KEV (Known Exploited Vulnerabilities) Catalog, established under BOD 22-01 — a CISA-managed, continuously updated catalog of vulnerabilities carrying significant risk to the federal enterprise.
• External feeds: e.g., NIST’s NVD (National Vulnerability Database) — noted as able to show exploitation happening outside FCEB agencies too.
• Internal SOC monitoring / incident response: the path for detecting exploitation directly within an agency’s own environment. It closes by directing organizations to capture additional detail — severity, susceptible software versions, and IOCs or investigation steps useful for determining exploitation.

Evaluation

First, determine whether the vulnerability exists in the environment and how critical the underlying system is, using a methodology like SSVC (Stakeholder-Specific Vulnerability Categorization). For actively exploited vulnerabilities, use the “rapid response” processes in existing tools (e.g., CDM); rare cases like one-off misconfigurations or zero-days may need manual scans. CISA-issued BODs or EDs (Emergency Directives) may specify particular technical evaluation steps.

If the vulnerability exists, look for signs of exploitation using known-IOC sweeps, investigation of abnormal activity tied to vulnerable systems, completion of any CISA-directive detection processes, or third-party incident responder collaboration. If exploitation is confirmed, immediately begin Incident Response Playbook activities — an explicit hand-off point.

The end goal of this phase is to classify every system into one of three states:

• Not Affected — the system isn’t vulnerable
• Susceptible — vulnerable, but no signs of exploitation, remediation begun
• Compromised — was vulnerable, exploitation signs found, both IR and remediation begun

Remediation

States that actively exploited vulnerabilities must be remediated according to the timeline in the CISA-managed KEV Catalog. Patching is the default approach; alternatives include limiting access, isolating vulnerable assets, or making permanent configuration changes. Where patches don’t exist, haven’t been tested, or can’t be applied promptly, alternative actions include disabling services, reconfiguring firewalls, or increasing monitoring — mitigations are removed once a patch becomes safely applicable.

Systems are tracked in one of three states:

• Remediated — patch/config change applied, no longer vulnerable
• Mitigated — compensating controls in place, reducing risk
• Susceptible/Compromised — no action taken yet

Reporting and Notification

Opens with the logic that sharing information on how vulnerabilities are being exploited helps defenders across the federal government understand which vulnerabilities are most critical to patch. Since CISA is responsible for FCEB’s overall security posture, it needs ongoing awareness of remediation status for actively exploited vulnerabilities — and this awareness, the document states, helps narrow the time between disclosure and exploitation. Agencies must report to CISA per Federal Incident Notification Guidelines, Binding Operational Directives, or as directed in an Emergency Directive.

References

• CISA Cybersecurity Incident and Vulnerability Response Playbook