What does CMMC 3.14.6 require?

Monitor the system, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks. In practice: a SIEM (or equivalent) with active detection rules, alerts that go to a human, and demonstrable response.

How is 3.14.6 different from 3.3.1 (audit logging)?

3.3.1 is create and retain audit records. 3.14.6 is actively monitor for attacks. You can satisfy 3.3.1 by storing logs no one reads — that fails 3.14.6. 3.14.6 demands detection and alerting, not just retention.

Does a managed SOC count as evidence for 3.14.6?

Yes, if you can show the SOC contract, the log feeds in scope, the active detection ruleset, sample alerts they raised on your environment, and your response to them. A contract alone isn't evidence — operational artifacts are.

CMMC 3.14.6 (System Monitoring): SIEM Evidence & What Assessors Actually Check

Control: NIST SP 800-171 Rev. 2 §3.14.6 · CMMC Practice: SI.L2-3.14.6 · Updated June 2026

Plain-English answer

3.14.6 says: monitor the system — including inbound and outbound traffic — to detect attacks and indicators of potential attacks. The bar isn't "we collect logs." It's "something is actively watching, something raises an alert, and a human responds."

3.14.6 vs. 3.3.1 — the line assessors draw

3.3.1 is create and retain audit records. 3.14.6 is actively detect attacks. You can fully satisfy 3.3.1 by storing logs no one reads — that will fail 3.14.6. The two controls are paired but not redundant.

Control lineage

CMMC Practice: SI.L2-3.14.6
NIST 800-171 Rev. 2: §3.14.6 — monitor the system, including inbound and outbound communications traffic, to detect attacks and indicators of potential attacks.
NIST 800-171A objectives: [a] the system is monitored to detect attacks and indicators of potential attacks; [b] inbound communications traffic is monitored to detect attacks and indicators of potential attacks; [c] outbound communications traffic is monitored to detect attacks and indicators of potential attacks.

What the assessor will EXAMINE

SIEM (or equivalent) architecture diagram showing all CUI-relevant log sources feeding in.
Active detection ruleset / use-case catalog (not vendor defaults left untuned).
Sample alerts from the last 30–90 days with the triage notes attached.
Network monitoring evidence for both inbound and outbound traffic — outbound is the most-missed half.
On-call / escalation procedure tying alerts to a named responder.
SSP narrative for 3.14.6 referencing the SIEM, rules, and response process.

What the assessor will INTERVIEW

"Walk me through the last alert this SIEM raised." — open the ticket, show the triage, name the responder.
"How would you know if a CUI workstation started beaconing outbound to an unknown host?" — point to the detection that would fire.
"Who watches this overnight and on weekends?" — name the SOC or on-call rotation.

What the assessor will TEST

Verify a representative CUI host is sending logs by searching for it live in the SIEM.
Sample the detection ruleset for tuning (not just out-of-the-box rules in "report" mode).
Trace one historical alert from generation → notification → response → closure.

Evidence examples (produce these)

SIEM data-source inventory: endpoints, servers, firewall, DNS, identity provider, cloud control plane.
Detection-rule catalog with MITRE ATT&CK coverage notes.
5–10 sample alerts (recent) with triage timestamps and responder names.
Firewall/IDS configuration showing inbound and outbound inspection.
SOC contract + monthly report (if managed), or on-call rotation if in-house.
Incident response procedure tying detection to containment.
SSP §3.14.6 referencing the SIEM, rules, and response.

Platform-specific

Microsoft GCC High: Microsoft Sentinel with Defender XDR feeds, Entra sign-in logs, and Defender for Cloud alerts — show analytics rules, automation rules, and a triaged incident.
Google Workspace: Workspace logs → Chronicle SIEM (or Splunk/Sentinel via export), with detections covering Workspace admin actions, OAuth grants, and data exfiltration patterns.
Athena: SIEM Sync + Live Telemetry auto-correlates SI/AU telemetry to control coverage and surfaces 3.14.6 gaps as evidence requests rather than after-the-fact findings.

Common failure patterns

"We have logs" — but nothing reads them. Retention ≠ monitoring.
Inbound monitored, outbound ignored. Objective [c] fails.
SIEM exists but uses only vendor-default rules in "report" mode, no alerts ever fired.
Alerts fire but route to a shared inbox no one owns — no responder, no response.
CUI-handling endpoints aren't actually forwarding logs (assessor searches and the host is silent).

SPRS impact & POA&M

SPRS: not meeting 3.14.6 is a 5-point deduction. POA&M: POA&M eligibility for individual requirements is restricted under CMMC — confirm 3.14.6's eligibility against current rules before assuming it can be deferred.

Assessor-ready summary

You're good on 3.14.6 when CUI-relevant systems are feeding a SIEM, tuned detections fire alerts on both inbound and outbound traffic, a named responder closes them, and the SSP narrates the same picture.

Turn your SIEM into 3.14.6 evidence — not just data retention. Get a monitoring evidence map →

Athena prepares organizations for CMMC Level 2; certification rests with C3PAOs/DIBCAC. Verify all control facts against NIST SP 800-171 Rev. 2, NIST SP 800-171A, and current CMMC rules.