This post explains how to build a repeatable, auditable test plan to validate your incident response capability for NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control IR.L2-3.6.3, with practical steps, technical details, and small-business scenarios to ensure you can detect, contain, eradicate, and recover from incidents affecting Controlled Unclassified Information (CUI).
Why IR.L2-3.6.3 matters (risk if not implemented)
IR.L2-3.6.3 requires organizations to validate their incident response processes; failing to do so increases the risk of undetected compromises, prolonged downtime, uncontrolled data exfiltration of CUI, contract loss with DoD customers, and regulatory or contractual penalties. For a small business, an untested IR program can mean weeks of recovery, reputational harm, and potential exclusion from future federal contracting opportunities.
Step-by-step test-plan overview (what your plan must include)
A complete test plan should be a written document that includes scope/objectives, stakeholders and roles, test scenarios, technical resources and evidence collection procedures, success criteria and metrics (MTTD/MTTR), a communications and escalation matrix, safety and legal constraints, and a post-test after-action and POA&M process. Map each test element to the specific control language of IR.L2-3.6.3 and to any CUI handling procedures you maintain.
Pre-test: scope, approvals, and safety controls
Start with a Pre-test checklist: identify systems in-scope (e.g., mail server, endpoint fleet, cloud file storage), decide whether tests will run in production or a lab, obtain sign-offs from executive leadership and IT, notify legal/HR if simulations involve employee behavior (phishing), and prepare a backout and safety plan (e.g., network ACL templates, snapshot/backup IDs). For small businesses, prefer a staged approach: tabletop exercises first, then limited functional tests in a segregated environment, and finally controlled production validation during maintenance windows.
Test execution: scenarios, technical steps, and evidence collection
Define 3–5 core scenarios that reflect realistic threats to your environment and CUI, for example: (1) targeted phishing leading to credential theft and cloud exfiltration, (2) endpoint ransomware encryption, (3) compromised third-party VPN access. For each scenario provide a timeline and script (who simulates the attacker, which systems are affected). Technical details to include: required logs (endpoint EDR, Windows Event Logs, syslog, firewall logs, cloud access logs), SIEM/alert searches (example Splunk-style query: index=network dest_port=443 | stats sum(bytes) by src_ip to spot large uploads), forensic capture procedures (use EDR live response, disk imaging with dd or FTK Imager, memory capture with Magnet RAM Capture), containment actions (isolate VLAN, disable AD account, revoke API keys), and recovery steps (restore from known-good snapshots, rebuild from golden images). Record evidence artifacts with timestamps and chain-of-custody notes so they are admissible for compliance audits.
Post-test: analysis, metrics, and remediation
After the exercise, run an After Action Review (AAR) with stakeholders within 48–72 hours. Produce a metrics-driven report showing MTTD (mean time to detect), time to contain, time to recover, number of systems isolated, and gaps found (e.g., missing EDR on 15% of endpoints, no MFA on service accounts). Convert findings into a prioritized POA&M with owners and target completion dates; update IR playbooks and runbooks, and schedule retests for high-risk findings within 30–90 days. For CMMC evidence, retain the test report, logs, and POA&M items with timestamps in your compliance evidence repository.
Small-business, real-world example: phishing -> cloud exfiltration
Scenario: a staff member at a 25-person engineering firm opens a spear-phish containing a malicious link; attacker obtains credentials and uploads design documents to a personal cloud account. Test plan steps: (1) Tabletop—walk through the scenario with execs and IT to confirm roles. (2) Technical simulation—use GoPhish to simulate the phishing email (with prior consent) and a test VM seeded with a fake "CUI" file. (3) Detection validation—verify the SIEM alert is generated using a search for abnormal cloud uploads (e.g., CloudTrail or Google Workspace Drive logs showing large file creates by non-standard IP). (4) Containment—disable the compromised account in AD/Azure AD, revoke OAuth tokens, and block the external IP at perimeter firewall (pfSense or cloud ACL). (5) Forensics—capture endpoint artifacts via the deployed EDR (CrowdStrike, SentinelOne, or Microsoft Defender for Endpoint) and preserve cloud logs. (6) Recovery—restore the user mailbox from backup and require password reset + MFA enrollment. Capture time stamps for each step and include screenshots/log extracts as evidence.
Compliance tips and best practices
Keep the following practical tips in mind: (1) Use synthetic data in tests to avoid exposing real CUI—if you must use CUI, isolate the test to a controlled lab and get legal approval. (2) Maintain a documented mapping from each exercise to IR.L2-3.6.3 and to NIST 800-171 requirement IDs so auditors can trace coverage. (3) Automate evidence collection where possible—use SOAR playbooks to capture logs and generate reports. (4) Involve third parties (cloud providers, MSSPs) in scenario planning; ensure contracts require cooperation during tests and incidents. (5) Run at least annual tests and after major changes (new cloud migrations, M&A, significant hires) and document all tests in your compliance repository with dates, participants, and lessons learned.
In summary, IR.L2-3.6.3 is about proving your organization can respond to incidents affecting CUI; a practical test plan includes pre-test approvals, realistic scenarios, clear technical execution steps (detection, containment, forensics, recovery), evidence capture, and a formal post-test remediation process. For small businesses, start with tabletop exercises, use synthetic data and managed services where appropriate, document everything, and iterate—this approach reduces real-world risk, demonstrates compliance, and shortens recovery time when an actual incident occurs.
