Meet CMMC logging requirements with audit evidence for every session.
CMMC logging requirements are the nine Audit and Accountability (AU) controls of NIST SP 800-171, required at CMMC Level 2. This page explains what to log, how syslog and network traffic logs fit, how long to keep logs, and the evidence Access Gate produces for each control.
Last updated:
What CMMC requires you to log.
CMMC Level 2 requires the nine AU controls, 3.3.1 to 3.3.9 of NIST SP 800-171 r2. You must log enough activity to investigate unauthorized access to CUI. Each logged action must trace to one named user. Clocks must sync to an authoritative time source. Logs must be protected, reviewed and correlated, and you must get an alert when logging fails.
In practice that means three things. Collect events from every system in the CUI boundary, including the network. Centralize them, usually over syslog into a SIEM. Retain them for the period your System Security Plan (SSP) defines.
CMMC Phase II assessments were suspended on 13 July 2026. Audits are paused. The AU controls are still required, and your SSP must still describe how you meet them.
Why CMMC logging often falls short at audit.
Most contractors already collect logs. The gap is usually in what those logs can prove. A firewall log shows that two IP addresses talked. An assessor asks which person reached which machine, when, and what they did.
The AU domain asks for per-user, per-session records that are tamper-evident and retained. Access Gate logs every session at the proxy with user identity, timestamp, asset, protocol and full session replay. Hash chaining and FIPS-validated signing make the logs tamper-evident. You can export them to your SIEM or to air-gapped storage.
What logs does CMMC require?
NIST SP 800-171 does not publish a fixed event list. Control 3.3.1 asks you to log what you need to investigate unauthorized activity, and 3.3.3 asks you to review that list over time. Assessors expect these event types at a minimum:
- Logons, logoffs and failed authentication to CUI systems
- Privileged actions and changes to accounts, configuration and audit policy
- Remote and vendor sessions into the CUI enclave
- Network connections that cross the CUI boundary
Each record needs a timestamp, the user, the source and destination, and the outcome. Write your event list into the SSP and date each review.
Network traffic logs for CMMC compliance.
Network traffic logs record the connections that cross your network: source and destination address, port, protocol, time and volume. They are the evidence that segmentation and access rules work as written.
For CMMC they support three families. Access Control (3.1): logs show that only allowed users reached CUI systems. Audit and Accountability (3.3): logs are part of the audit trail. Incident Response (3.6): logs let you rebuild what an attacker touched.
A flow record alone names addresses. It becomes accountable evidence when it is tied to an authenticated user. Access Gate logs each flow it brokers with the user, asset and enclave. It also logs every flow that crosses a network zone boundary you define, and raises an alert when a flow crosses a boundary that should be isolated.
The role of syslog in CMMC logging.
Syslog is the standard protocol for sending log messages from devices and applications to a central server. Firewalls, switches, servers and most OT gateways can emit it. That makes it the usual way to centralize logs for CMMC.
A central syslog server or SIEM supports several AU controls. It keeps one retained record (3.3.1). It lets you correlate events across systems (3.3.5). It produces reports on demand (3.3.6). It can alert when a source goes silent (3.3.4).
Configure it with care. Classic syslog over UDP can drop messages and sends them in clear text. Use TCP, and TLS where the receiver supports it, so records arrive complete and protected in transit (3.3.8). Restrict who can read and change the syslog server (3.3.9).
Access Gate forwards its alerts, flows and audit events over syslog via TCP, in structured RFC 5424 format. Splunk, Elastic, QRadar, Microsoft Sentinel and Wazuh ingest it without custom integration. See the log forwarding guide.
How long to retain CMMC logs.
NIST SP 800-171 sets no fixed retention period. Control 3.3.1 says to retain logs "to the extent needed" to investigate unauthorized activity. You choose the period, write it in your SSP, and show the assessor logs that cover it.
One contract clause sets a floor. DFARS 252.204-7012 requires you to preserve relevant monitoring and packet capture data for at least 90 days after you report a cyber incident. Your retention must reach back far enough to cover the activity before the incident.
Keep recent logs on the system that wrote them for quick review. Forward everything to your SIEM or write-once storage for long-term retention, and protect that copy from deletion.
How to set up CMMC logging.
- 01
Define the logged events
List the events each CUI system must log. Record the list in your SSP and review it on a schedule (3.3.1, 3.3.3).
- 02
Send every source to one place
Point servers, firewalls, switches and OT gateways at a central syslog server or SIEM over TCP (3.3.5).
- 03
Sync every clock
Point all log sources at the same NTP time source so events line up across systems (3.3.7).
- 04
Set and enforce retention
Configure retention to match your SSP. Keep a protected copy that cannot be silently deleted (3.3.1, 3.3.8).
- 05
Limit who manages logs
Give log administration to a small, named group. Log every change to the logging setup itself (3.3.9).
- 06
Alert on failure and test
Alert when a source stops sending. Generate a test event and confirm it arrives, is searchable and is retained (3.3.4).
AU.L2-3.3.1 to 3.3.9, mapped to evidence.
Each control below quotes the NIST SP 800-171 r2 requirement and lists the evidence Access Gate produces for your C3PAO to review.
Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
Access Gate logs every proxied session with user, timestamp, source/destination, protocol, and full session payload (when enabled). Logs are written to an append-only store with hash chaining; tampering breaks the chain and is flagged on read.
Ensure that the actions of individual system users can be uniquely traced to those users, so they can be held accountable for their actions.
Every session is bound to an authenticated identity at the proxy boundary. Service accounts and shared credentials are blocked by policy. The audit record names the human user who initiated the session, even when the underlying asset uses a shared credential.
Review and update logged events.
Access Gate's logged event taxonomy is policy-driven and version-controlled. Updates ship with each release with a documented changelog you can use in your periodic review of logged events and cite in your SSP.
Alert in the event of an audit logging process failure.
Access Gate self-monitors the log pipeline. Failure to write to the store, exhaustion of disk space, or loss of connection to a forwarded SIEM all generate immediate alerts via syslog, webhook, or email.
Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity.
Access Gate exports normalized, structured logs (CEF, JSON, syslog) suitable for SIEM correlation. Built-in dashboards group sessions by user, asset, and time window for in-tool review when no external SIEM is deployed.
Provide audit record reduction and report generation to support on-demand analysis and reporting.
Access Gate generates pre-built C3PAO evidence packages on demand: per-user activity reports, per-asset access histories, and policy-violation summaries. Output formats are CSV, PDF, and structured JSON.
Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.
Access Gate runs NTP synchronization against operator-configured time sources by default. Time drift exceeding policy thresholds is logged and alerted.
Protect audit information and audit logging tools from unauthorized access, modification, and deletion.
Audit storage is segregated from operational data and access-controlled by RBAC. Hash-chained records prevent silent modification. Logs can be FIPS-signed and forwarded to write-once storage for jurisdictions that require it.
Limit management of audit logging functionality to a subset of privileged users.
Audit configuration is gated behind a dedicated 'audit-admin' role distinct from system administration. Changes to audit policy themselves generate audit records, providing accountability for the auditors.
How CMMC logging maps to IEC 62443.
Plants that also follow IEC 62443 can use the same logs for both. The system requirements in IEC 62443-3-3 cover the same ground as the AU family.
| CMMC AU control | IEC 62443-3-3 system requirement |
|---|---|
| 3.3.1 System Auditing | SR 2.8 Auditable events, SR 2.9 Audit storage capacity |
| 3.3.4 Audit Failure Alerting | SR 2.10 Response to audit processing failures |
| 3.3.5 Audit Correlation | SR 6.1 Audit log accessibility, SR 6.2 Continuous monitoring |
| 3.3.7 Authoritative Time Source | SR 2.11 Timestamps |
| 3.3.8 Audit Protection | SR 3.9 Protection of audit information |
For zones, conduits and security levels, see the IEC 62443 guide.
Questions about CMMC logging.
CMMC Level 2 requires the nine Audit and Accountability controls of NIST SP 800-171 r2, AU.L2-3.3.1 to 3.3.9. You must create and retain audit logs, trace actions to individual users, review logged events, alert on logging failures, correlate and report on logs, sync clocks to an authoritative source, protect logs, and limit who manages them.
NIST SP 800-171 has no fixed event list. Log what you need to investigate unauthorized access to CUI: logons and failed authentication, privileged actions, changes to accounts and configuration, remote and vendor sessions, and network connections that cross the CUI boundary. Each record needs a timestamp, the user, the source and destination, and the outcome.
NIST SP 800-171 sets no fixed period. You define retention in your SSP and must be able to show logs that cover it. DFARS 252.204-7012 requires you to preserve relevant monitoring and packet capture data for at least 90 days after reporting a cyber incident.
Syslog is the usual way to centralize logs for CMMC. A central syslog server or SIEM supports retention (3.3.1), correlation (3.3.5), reporting (3.3.6) and failure alerting (3.3.4). Send syslog over TCP, with TLS where supported, and restrict who can manage the server (3.3.8, 3.3.9).
Yes. Network traffic logs show which systems connected, when and over which protocol. They support Access Control, Audit and Accountability, and Incident Response. They are strongest when each connection is tied to an authenticated user, which 3.3.2 requires.
It requires you to review the list of events you log and update it as systems and threats change. Keep the event list in your SSP and record the date and outcome of each review.
You need log sources that record per-user activity, a central syslog server or SIEM to collect and correlate them, a common NTP time source, and protected storage for retention. Access Gate adds per-user session and flow logs at the network layer and forwards them to the SIEM over syslog.
Largely, yes. The AU controls cover the same ground as IEC 62443-3-3 SR 2.8 to SR 2.11, SR 3.9 and SR 6.1 to SR 6.2: auditable events, storage capacity, failure response, timestamps, protection of audit information, log access and continuous monitoring.
See your AU domain evidence in 30 minutes.
Request a working session with our compliance team. We will show the audit packages we have generated for current customers preparing for C3PAO assessment.
Request a demo