This post explains how to implement IR.L2-3.6.2 — the requirement to track, document, and report incidents — by integrating a SIEM and a ticketing system to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 expectations, with practical steps, concrete configurations, and small-business scenarios you can implement today.
What IR.L2-3.6.2 requires (quick summary)
At a high level, IR.L2-3.6.2 expects organizations to have a demonstrable process for tracking incident lifecycle events, preserving records, and reporting incidents to the appropriate parties. For contractors handling Controlled Unclassified Information (CUI), that typically means: detect and log incidents; create and maintain an auditable incident record; and report to the contracting authority/DoD or other designated recipients per contractual and regulatory timelines.
Design the data flow: SIEM → Ticketing → Reporting
Start by designing an incident data flow. A recommended pipeline for small businesses: collect logs from endpoints (EDR/sysmon/Windows Event Forwarding), servers (syslog/auditd), perimeter devices (firewalls, proxy), and cloud services (AWS CloudTrail/CloudWatch, Azure Diagnostic). Feed those into a SIEM (commercial like Splunk/QRadar, cloud-native like SumoLogic/Elastic Cloud, or OSS options like Wazuh + Elasticsearch). Configure the SIEM to generate normalized alerts and then use webhook/API plugins to automatically create tickets in your ticketing system (Jira Service Management, ServiceNow, Freshservice, or a lightweight option like osTicket) with a standardized incident schema.
Minimum incident ticket schema
To meet compliance expectations, ensure each ticket contains: unique incident_id, detection_time (UTC), reported_by/source (SIEM rule ID and sensor), affected_assets (hostname/IP/asset tag), CUI_impact (Yes/No + data types), severity/classification, IOC list (hashes, IPs, domains), containment_actions, evidence_location (read-only S3 or NAS path + hash), timeline entries (detection, containment, eradication, recovery timestamps), and root_cause_summary. Automate population of as many fields as possible from SIEM alert context to reduce human error.
Practical SIEM rules and technical settings
For small businesses with limited staff, focus on high-value detections: anomalous outbound traffic (large POSTs, unusual DNS TXT/HTTP), privilege escalation (sudden domain admin activity from workstation), suspicious process creation (ransomware patterns via Sysmon process_create), and data access anomalies (bulk read of file shares containing CUI). Configure retention and immutability: ensure log retention aligns with contract (commonly minimum 90 days, often 1 year for audits), enable immutable storage (WORM S3 buckets or an append-only SIEM index), and enforce strict clock sync across sources (NTP) so timestamps are defensible in investigations.
Ticketing integration and playbooks
Integrate SIEM alerts with your ticketing system via API so alerts spawn tickets with appropriate priority mapping. Use automation to add enrichment: reverse DNS, geolocation, threat intel lookups, and asset owner lookup (from CMDB). Create runbook-driven tasks inside the ticket: isolation via EDR API, credential resets, patching, forensic image collection (use scripts to snapshot disk to read-only storage), and stakeholder notifications. For CMMC/NIST compliance, include a mandatory field for "CUI impact assessment" and "reporting decision" so auditors can see why a report was or wasn't sent.
Real-world small-business scenario
Example: An employee opens a phishing attachment; a new process spawns with a known ransomware hash detected by EDR. The EDR sends an event to the SIEM, which matches a correlation rule and creates a High-priority ticket with pre-filled fields and an attached IOC list. The ticket's runbook triggers EDR automation to isolate the host, captures a memory image to an immutable storage location, and updates the ticket timestamps for containment. If CUI is present on the host or exfil is suspected, the incident owner selects "CUI impacted = Yes" which triggers the "reporting" sub-workflow (compile timeline, package evidence references, notify the DIB/DoD/primes per contract). This chain is auditable: SIEM alert ID → ticket ID → evidence hashes → exported incident report.
Compliance tips and best practices
Maintain auditability: store tickets and SIEM alerts as long-term evidence, keep ticket change-history intact (no deletions), and restrict permissions so only authorized personnel can modify critical fields. Run quarterly tabletop exercises that follow the ticketing workflow from detection to reporting and capture time-to-detect and time-to-contain metrics. Document reporting timelines in your incident response policy—verify contract-specific obligations (some prime contracts expect 72-hour notification windows) and codify who signs and sends reports. Use immutable evidence stores (WORM S3, write-once SAN) and hash all collected artifacts using SHA-256, logging the hash into the ticket and SIEM for chain-of-custody.
Risks of not implementing IR.L2-3.6.2 correctly
Failure to track, document, and report incidents exposes a small business to expanded breach impact (longer dwell time), contractual penalties, loss of prime contracts, regulatory investigations, and reputational harm. Lack of auditable timelines or missing evidence can prevent demonstrating compliance during a CMMC assessment or DoD inquiry and may lead to fines or removal from DoD supplier lists. Operationally, poor integration increases time-to-contain and the likelihood of uncontrolled data exfiltration.
In summary, meet IR.L2-3.6.2 by building an auditable pipeline from sensors → SIEM → ticketing system, automating enrichment and runbooks, enforcing immutable evidence handling, and documenting reporting decisions and timelines; for small businesses this means focusing on high-value logs, practical automation (EDR/Firewall → SIEM → webhook → ticket), and routine validation exercises so when an incident occurs you have defensible records and a repeatable reporting process.
