Meeting NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 Control IR.L2-3.6.1 requires a practical, tested incident response playbook that covers detection, analysis, containment and recovery — this post walks you through building one with concrete steps, technical examples, and small-business scenarios so you can implement and demonstrate compliance.
What IR.L2-3.6.1 Requires (high level)
IR.L2-3.6.1 is focused on timely detection, proper analysis, effective containment, and reliable recovery from cybersecurity incidents that could affect Controlled Unclassified Information (CUI). Practically this means you must have documented procedures and runbooks that: 1) use monitoring sources to detect anomalies, 2) provide a triage and analysis workflow, 3) define containment actions that limit damage, and 4) ensure validated recovery and lessons-learned processes. For compliance evidence, map playbook steps to the control and retain artifacts (logs, tickets, screenshots) demonstrating execution.
Building the Playbook: Detection, Analysis, Containment, Recovery
Detection — data sources, rules, and alerts
Detection begins with instrumenting the environment: forward Windows Event logs, Linux syslogs, EDR telemetry (e.g., CrowdStrike, SentinelOne), DNS logs, proxy/URL logs, and cloud-native feeds (AWS GuardDuty, Azure Sentinel, Google Chronicle). Create a prioritized set of detection use-cases relevant to CUI exposure: credential theft, privilege escalation, lateral movement, exfiltration. Example SIEM rule (pseudo-SPL): "index=wineventd EventID=4648 OR 4672 | stats count by Account, Host | where count > 50" to detect abnormal logons. For small businesses without a full SIEM, enable cloud tools (GuardDuty/CloudWatch, Microsoft Defender for Cloud) and forward critical alerts to your ticketing system or an MSP via webhook. Define alert severity (High/Medium/Low) and required response SLAs — e.g., High: initial investigation within 30 minutes, containment decision within 2 hours.
Analysis — triage, enrichment, and forensic basics
Analysis organizes evidence and determines scope. Build a triage checklist: collect full host EDR snapshot, capture memory if lateral movement suspected, pull relevant logs (authentication, sysmon, web proxy), and gather network flow data. Use IOC enrichment: pivot on IPs/domains/hashes against VirusTotal, MISP, or your threat intel feeds. For small businesses, document exact commands and automated scripts to collect artifacts — e.g., Windows: powershell -Command "Get-WinEvent -FilterHashtable @{LogName='Security'; StartTime='$Start'} | Export-Csv C:\IR\security.csv"; Linux: tar czf /tmp/syslogs.tgz /var/log/*. Use EDR APIs to pull process trees and binaries (sample API call pattern: GET /api/alerts/{id}/artifacts). Maintain chain-of-custody notes: who collected, when, and where artifacts are stored (encrypted share with ACLs).
Containment — isolation, blocking, and temporary fixes
Containment should be tiered: short-term (immediate actions to stop active harm), and long-term (remediation while preserving evidence). Short-term playbook actions might include EDR “quarantine” via API, disabling compromised AD accounts (dsmod user /disable or via PowerShell: Disable-ADAccount -Identity "user"), applying temporary firewall rules to block malicious IP ranges, or isolating VLAN/port using network controller CLI (Cisco example: interface gi1/0/5 shutdown). Document who can approve each action — for instance, only the IR lead or authorized SOC analyst may isolate production servers. Include rollback steps and note evidence preservation: if you snapshot a VM before remediation, store the snapshot ID and a hash of the image for auditability.
Recovery — restoration, validation and hardening
Recovery is more than restoring services; it's restoring securely. Define acceptable recovery methods for each asset class: 1) rebuild from golden image (recommended for suspected host compromise), 2) clean and patch if forensics indicates non-persistence, 3) restore from verified backup for data loss. Provide concrete recovery runbook steps: verify backups (hash compare and test boot), rotate keys/passwords for affected accounts, re-image endpoints using MDT/Intune or cloud instance templates, then validate via endpoint scans and red-team checks. Enforce prerequisites before reconnecting to production: EDR active, all patches applied, MFA enforced on privileged accounts, and a closure checklist completed with sign-off from IT security and business owner.
Implementation details for small businesses
Small businesses often lack 24/7 SOCs; build a playbook that uses automation and managed services to compensate. Practical setup: enable cloud-native detection (GuardDuty/Defender), deploy lightweight EDR agents (free or low-cost tiers), configure syslog forwarding to a managed SIEM or MSSP, and use a ticketing system (Jira Service Desk, ServiceNow, Zendesk) with an incident template capturing required evidence fields. Create simple scripts for containment — a PowerShell script to disable accounts plus a logfile, or a bash wrapper to call your firewall API to add a deny rule. Document escalation paths to your MSP or legal counsel for DFARS/DoD reporting obligations (if applicable). Keep a single-page runbook for business leaders summarizing who to call, what systems may be taken offline, and communication templates for customers and the DoD contracting officer.
Testing, evidence and metrics
Test your playbook with quarterly tabletop exercises and at least one full technical incident simulation annually. Tabletop scenarios should include detection gaps: e.g., an employee opens a phishing attachment that deploys a C2 beacon; simulate detection failures and see if the playbook leads to proper containment. Preserve evidence during tests to validate chain-of-custody processes. Track metrics tied to IR.L2-3.6.1 compliance: Mean Time to Detect (MTTD), Mean Time to Contain (MTTC), and Mean Time to Recover (MTTR), percentage of incidents with documented root cause and remediation, and log retention compliance (document retention periods and verify backups). For audit readiness, retain incident packages (ticket, timelines, artifacts, signatures) for the period required by contract or policy — commonly 1 year or longer for CUI-related incidents.
Compliance tips, best practices and the risk of not implementing
Best practices: map each playbook step to the IR.L2-3.6.1 control in a compliance matrix, use versioned playbooks in a secure repository (e.g., Git with branch protection), maintain role-based access to containment actions, and automate evidence capture where possible (scripts that zip logs and push to an encrypted bucket). Make sure training is role-specific (SOC, IT ops, executive) and include legal/privacy counsel for breach notifications. The risk of not implementing this requirement includes loss or exfiltration of CUI, contract penalties, suspension from DoD contracting, delayed detection leading to larger breaches, and reputational and financial damage. Practically, lacking a tested playbook means slower response, loss of evidentiary chains, and potential non-compliance findings during audits.
Summary
To meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 IR.L2-3.6.1 you need a concise, actionable playbook that covers detection, analysis, containment, and recovery with mapped evidence and roles. Implement instrumented detection, scripted analysis and collection steps, tiered containment actions with approvals, and validated recovery procedures; test these regularly, retain artifacts, and measure performance. For small businesses, leverage cloud-native tools and MSSPs to fill capability gaps but maintain documented ownership, escalation, and evidence handling so you can demonstrate compliance and recover your environment quickly and defensibly.
