This post shows how to build concise, testable incident response playbooks that meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 Control IR.L2-3.6.1 by walking through each phase (Preparation → Detection → Analysis → Containment → Recovery → Notification) with practical templates, small-business examples, and explicit technical steps you can implement right away.
Why IR.L2-3.6.1 matters and the risk of not having playbooks
IR.L2-3.6.1 requires that organizations have procedures to respond to cybersecurity incidents, covering detection through notification. Without formal, phase-specific playbooks you risk slow detection, missed containment opportunities, loss of Controlled Unclassified Information (CUI), contract breaches (for DoD contractors), regulatory fines, and expensive recoveries. Real-world consequences include lateral movement allowing exfiltration, missed 72-hour reporting windows on DoD contracts, and loss of customer trust — outcomes that are especially painful for small businesses with limited margins.
Playbook structure: a reusable template mapped to compliance
Build each playbook from a common header and six phase sections so auditors can map artifacts to IR.L2-3.6.1 quickly. Header metadata: playbook name, version, last test date, owner (CISO/IR lead), scope (systems, CUI type), triggers (e.g., EDR alert ID, SIEM rule), and required evidence (logs, hashes, screenshots). Include Roles & Responsibilities (Who: IR lead, IT admin, legal, PR), Communication channels (out-of-band phone, encrypted email), and Escalation matrix. Store playbooks in a version-controlled, access-restricted location (e.g., Confluence + Git + ACLs). This structure provides auditable evidence that you followed NIST/CMMC processes.
Preparation phase: what to document and implement now
Preparation playbooks are the most operational: asset inventory (with CUI owners), baseline images (golden builds), backup/restore procedures (immutable backups, restoration test logs), and toolkits (EDR, SIEM, MFA, logging). For a small business: deploy a managed EDR (CrowdStrike/Carbon Black/Microsoft Defender for Endpoint) with automatic isolation, use Wazuh/OSSIM or a cloud SIEM for correlating logs, ensure nightly immutable backups (object storage with versioning), and maintain offline admin credentials stored in a vault (HashiCorp Vault or hardware tokens). Document exact configuration: e.g., Windows Sysmon enabled with Event IDs 1,3,8,11, and logging forwarded via NXLog to SIEM; Linux hosts forward /var/log/auth and auditd logs. Preparation also includes tabletop scripts — schedule quarterly exercises and log the minutes as compliance artifacts.
Detect & Analyze phases: practical detection rules and triage steps
Detection playbooks list the data sources and sample detection rules: failed-auth anomaly (>= 5 failed logins then success from new IP), unusual data transfer spikes on firewall/cloud egress, EDR rule for cmd.exe spawning from outlook.exe, or creation of new service binaries. Implement concrete SIEM rules: e.g., Elastic query for Windows: "event.id:4625 AND event.outcome:failure | stats count() by source.ip, user.name" and alert when count > 5 in 10 minutes. Analysis runbook: capture host context (IP, hostname, logged-on users), pull recent EDR telemetry, query Sysmon (Event ID 1/11/22) for process trees, and collect network session data. Useful triage commands: on Windows use "wevtutil qe Security /rd:true /f:text /c:50", "tasklist /v", and "netstat -bn". On Linux use "ss -tupn", "ps aux --forest", "journalctl -u sshd --since '1 hour ago'". Preserve volatile evidence: memory capture with DumpIt (Windows) or "sudo gcore -o /tmp/memdump $(pidof
Containment: short-term and long-term actions with technical examples
Containment playbooks must separate short-term (stop bleeding) from long-term (prevent recurrence). Short-term actions: isolate the host (EDR isolate command or remove from network via NAC), block malicious IPs (firewall rule or cloud security group — e.g., AWS: aws ec2 revoke-security-group-ingress / update NACL), disable compromised accounts (AD: dsmod user / disable or Azure AD: Set-MsolUser -UserPrincipalName user@example.com -BlockCredential $true), and revoke active sessions (kill RDP/SSH sessions). Long-term containment might require reimaging the host, rotating service credentials, and applying patches. Example commands: on a Linux gateway, block IP with iptables -I INPUT -s 203.0.113.45 -j DROP; on Windows Server, use "Remove-NetFirewallRule -DisplayName 'BlockBadIP'". If you must preserve a machine for forensic imaging, snapshot the VM before taking the endpoint offline and record the exact time and method in the chain-of-custody log.
Recovery: validate restoration and prevent reinfection
Recovery playbooks should specify restoration sources (golden images, known-good backups with backup IDs and checksums), validation steps (integrity checks, patching, AV/EDR scans), and credential sanitation. A sample recovery sequence: 1) Confirm no ongoing active compromise using SIEM/EDR telemetry, 2) Rebuild from golden image (document build ID and applied patches), 3) Restore CUI from backups and validate with checksums, 4) Reset all affected credentials (force password resets and rotate API keys), 5) Monitor restored systems with elevated logging for 14 days. For ransomware, recovery must include offline backups validation (test restores) and a domain-wide password rotation script for service accounts. Capture artifacts: restored backup IDs, restore logs, and post-restore vulnerability scan results as compliance evidence.
Notification: templates, timelines, and evidence to include
Notification playbooks list who to notify (internal leadership, contracting officer, CISO, legal, HR, third-party forensics, PR) and the required content. For DoD contractors, be prepared for contractual obligations such as DFARS reporting windows (commonly referenced 72-hour notification requirement) — confirm specific contract clauses. Notifications should include incident description, systems affected, CUI impact, initial mitigation steps, evidence collected (hashes, logs, timeline), and point of contact. Use templated messages for speed: an initial 72-hour-ish "situation report" and a later "technical findings" report. Keep an auditable trail of timestamps and the person who approved each notification. For small businesses with limited legal capacity, pre-arrange counsel and an external incident response retainer to meet reporting requirements quickly.
Implementation tips and best practices: keep playbooks short (one page per scenario with an expanded appendix), version-control them, and tag them to evidence artifacts (logs, test results). Run annual or post-change tabletop exercises and at least one live drill a year (e.g., simulated phishing leading to a containment exercise). Use managed services (MSSP/MDR) if 24/7 coverage is unaffordable in-house; ensure contracts require log access and joint handling procedures. Retain incident evidence per your policy and contractual requirements (commonly 1–3 years for DoD-related work) and ensure chain-of-custody forms are used for forensic data.
Summary: To meet IR.L2-3.6.1 you must produce phase-specific, testable playbooks that map detection through notification, include concrete technical steps (commands, logs, and artifacts), and are exercised regularly. For small businesses, focus on pragmatic controls—managed EDR, immutable backups, clear escalation paths, and templated notifications—so you can detect, contain, recover, and comply quickly when an incident occurs. Implement these playbooks, document each exercise and real incident, and keep evidence handy for audits and contractual reporting obligations.
