This guide explains how to implement NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control IR.L2-3.6.2 — tracking, documenting, and reporting incidents — with practical steps, templates, and small-business examples so you can produce auditable evidence and meet contractual reporting obligations.
What IR.L2-3.6.2 requires and key objectives
At its core IR.L2-3.6.2 mandates that organizations establish processes and capabilities to track incidents from detection through closure, document the investigation and remediation actions, and report incidents as required by contract or law (for example, DFARS/NIST-related reporting for CUI). Key objectives are: (1) create a consistent incident record for every event, (2) preserve and secure evidence, (3) meet internal and external reporting timelines, and (4) provide auditable documentation for compliance assessments. For a compliance framework-focused implementation, your documentation must map to NIST SP 800-171 evidence requirements and CMMC practice objectives.
Step-by-step implementation
1) Prepare — policies, roles, and tools (baseline the program)
Start by defining an incident response policy and a playbook that includes roles (Incident Response Lead, System Owner, Legal/Privacy, Communications, and the Prime Contractor or CSM if applicable). Inventory your log sources (Windows Event/ Sysmon, EDR telemetry, firewall, VPN, cloud logs such as AWS CloudTrail/CloudWatch, Office 365 audit logs) and ensure central collection to a SIEM or log store (Splunk, Elastic, Azure Sentinel, or a managed SIEM) with TLS-secured transport. For a small business (10–50 employees) that uses AWS and Microsoft 365, set up CloudTrail, GuardDuty, Defender for Office 365, and a lightweight SIEM ingest (e.g., Elastic Cloud) to ensure events are captured centrally. Enforce NTP time sync (UTC standard) on all hosts to make timelines reliable.
2) Detect and record — how to capture the incident correctly
When an alert fires, create an incident ticket (Jira, ServiceNow, or a secure spreadsheet for very small shops) and assign a unique incident ID. Log the detection source, time (UTC), affected assets, and initial classification (e.g., potential data exfiltration of CUI, malware, insider). Capture volatile data where appropriate (memory images via fast forensic tools, running processes, network captures) and make forensic disk images (FTK Imager, dd) before remediation. Preserve logs in immutable storage where possible — S3 with Object Lock, WORM for on-prem log archives, or write-once backups. Hash artifacts (SHA-256) at collection time and include hashes in the incident record so future investigators can validate integrity.
3) Analyze, track, and document — required fields and chain of custody
Your incident record must contain the facts auditors and assessors expect: incident ID, detection timestamp, detection source, impacted systems and owners, indicator of compromise (IOCs), CUI involvement (yes/no/unknown), containment steps, eradication steps, recovery actions, evidence artifacts (with hash and storage location), timeline of events, root cause analysis, and lessons learned. Establish and record chain-of-custody for every artifact: who collected it, when, how it was stored, and who accessed it. Map attacker behavior to MITRE ATT&CK techniques in your report to show analytical rigor. For small businesses outsourcing detection to an MSSP, capture and store MSSP reports, raw alerts, and any live-session recordings as part of the record.
4) Report and escalate — internal and external reporting requirements
Build a reporting checklist that triggers on classification and CUI involvement. For DoD contracts and CUI, DFARS-based requirements typically mandate reporting cyber incidents within 72 hours of discovery; confirm the exact contractual requirement and the DoD-prescribed submission method (contract or DFARS guidance often references secure submission portals). Your report package should include the incident record, affected system inventory, examples of logs/IOCs, actions taken, and whether CUI or FCI was exfiltrated. Internally, use an escalation matrix (who to call within 15 minutes, hour, 24 hours) and prepare templated notifications for executives, legal counsel, prime contractors, and customers. For small business scenario: if ransomware encrypts a server containing CUI, immediate notifications go to the prime contractor and the DoD contact per contract; preserve evidence before paying ransom and document the decision chain.
5) Post-incident review, retention, and continuous improvement
After containment and recovery, run a structured after-action review and produce a CAPA (corrective and preventive actions) plan and timeline. Retain incident records and forensic artifacts for the period required by contract or policy (commonly 1–3 years for audit evidence; adjust per contract and legal counsel). Maintain metrics for continuous improvement: mean time to detection (MTTD), mean time to containment (MTTC), time to report (to external parties), and number of repeat incidents. Update playbooks with specific technical remediation steps (e.g., patching sequence, password resets, certificate rotations) and document verification steps used to validate eradication.
Risk of not implementing IR.L2-3.6.2 and compliance tips
Failing to track, document, and report incidents exposes you to regulatory penalties, contract termination, loss of DIB (Defense Industrial Base) work, and missed opportunities to contain incidents quickly. Lack of evidence and poor chain-of-custody undermines investigations and can void insurance claims. Compliance tips: enforce centralized immutable logging, standardize an incident record template (CSV/JSON exportable for assessors), sync clocks to UTC, pre-authorize forensic vendors and third parties in your contingency plan, and practice tabletop exercises quarterly. For small businesses with limited budgets, prioritize EDR + centralized cloud logs, use managed forensic partners on retainer, and keep clear documented escalation paths to the prime contractor and DoD contacts.
Summary: Implementing IR.L2-3.6.2 is a pragmatic combination of policy, people, and technical controls: establish roles and playbooks, centralize and preserve logs, collect and hash evidence, maintain thorough incident records and chain-of-custody, and meet contractual reporting timelines; doing these things consistently will produce the auditable artifacts and rapid response capability required for NIST SP 800-171 / CMMC 2.0 compliance and will materially reduce business and regulatory risk.
