How to Actually Implement CMMC Level 2 Audit & Accountability: A Practitioner's Guide

Turn on the right log sources. Keep the logs long enough to be useful.

This practice requires creating and retaining audit logs sufficient to enable monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity. The two components are collection and retention.

What to log on in-scope systems:

• Successful and failed login attempts (local and remote)
• Account lockouts and password changes
• Privilege escalation and use of administrative accounts
• Account creation, modification, and deletion
• Access to CUI repositories (file shares, SharePoint sites, databases)
• System startup and shutdown
• Security policy changes
• Application errors and crashes on critical systems
• Network connection events on perimeter devices (firewall allow/deny)

Retention guidance:

NIST 800-171 does not prescribe a specific retention period, but 90 days of online retention and 12 months total (online plus archive) is a widely accepted and defensible standard. Document your retention period in your audit policy and configure log storage accordingly. Logs that age out before you need them are logs that never existed.

Windows implementation: Configure Advanced Audit Policy via Group Policy (Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration). Enable at minimum: Account Logon, Account Management, Logon/Logoff, Object Access (for CUI file shares), Policy Change, and Privilege Use categories.

Microsoft 365 / Entra ID: Enable Unified Audit Logging in the Microsoft 365 compliance portal. Audit log retention defaults to 90 days; Microsoft 365 E3 provides 180 days, E5 provides one year. Verify retention is set to match your documented policy.

Common mistake: Leaving Windows audit policy at defaults. Default audit settings capture almost nothing useful. After enabling Advanced Audit Policy, verify logs are actually being generated by checking Event Viewer on a sample of systems.

Every action in the system must be attributable to a specific user. Shared accounts break this.

This practice requires that the actions of individual users can be uniquely traced back to those users. It is the accountability half of "audit and accountability." If two people share a login, you cannot determine which person performed a given action, and the entire audit trail for that account becomes unreliable.

Implementation requirements:

• Every user must have a unique account. No shared service accounts used by humans, no shared admin credentials, no group passwords
• Shared service accounts used by applications (not humans) must have their use logged and the account must be managed under a service account policy
• When privileged actions are required, users must authenticate with their own privileged account, not a shared admin account. In Microsoft environments, this means individual accounts in the Domain Admins or equivalent group, not a shared "administrator" credential
• Remote access must use individual credentials. VPN accounts, RDP access, and jump server access must all be individually attributed

This practice connects directly to the IA domain. Practices 3.5.1 and 3.5.2 require identifying and authenticating users before granting system access. If authentication is done properly with individual accounts, traceability follows naturally.

Common mistake: A shared "admin" local account on servers that multiple IT staff use. Even if domain accounts are individual, any use of the shared local admin account breaks traceability for those sessions. Use LAPS (Local Administrator Password Solution) to manage unique local admin passwords per machine, and disable or rename the default Administrator account.

What you log should be deliberately chosen and periodically reviewed for relevance.

This practice requires reviewing and updating the list of events being logged. It is a governance practice: logging is not a "set it and forget it" configuration. As systems change, new applications are added, and the threat landscape evolves, the set of auditable events should be reviewed and updated to remain relevant.

Implementation:

• Document the categories of events you log and the rationale for each. This can be a section in your AU policy or a separate log configuration document
• Schedule an annual review of logged events. The review should assess whether current log sources and event types remain appropriate for your environment and whether new systems have been added to scope that require logging configuration
• When significant changes occur (new application deployed, cloud migration, new CUI workflow), update the logged event list as part of the change management process
• Document reviews and updates with dates and what changed. An entry in a change log or the AU policy revision history satisfies the evidence requirement

Common mistake: Having no documentation of what is being logged or why. If an assessor asks "how did you decide what to log?", the answer needs to be more than "we turned on what was available." A brief justification document tied to your AU policy demonstrates intentionality.

If logging stops working, someone needs to know about it immediately.

Audit logging failures are an attacker's best friend. A sophisticated adversary will attempt to disable or overflow logs before taking high-risk actions. This practice requires alerting the appropriate personnel when the audit logging process fails, so the failure can be investigated and corrected.

Implementation approaches:

• Windows Event Log monitoring: Configure alerts for Event ID 1102 (Audit log cleared) and Event ID 1100 (Event logging service shut down). These events in the Security log indicate either an attack or a misconfiguration that destroys evidence
• Log volume anomaly detection: A sudden drop in log volume from a system is a signal that logging has stopped or been disrupted. SIEM tools can alert on this pattern
• Log storage capacity monitoring: Logs that can't be written because storage is full are effectively lost. Monitor log storage utilization and alert before capacity is exhausted
• Microsoft Sentinel / Azure Monitor: Create alert rules for log ingestion gaps. If a data connector stops sending data, Sentinel can be configured to alert after a defined quiet period
• Defender for Endpoint: MDE generates alerts when security log clearing is detected on onboarded endpoints

Common mistake: Having logging configured but no alerting on logging failures. An attacker who disables logging on a workstation before exfiltrating data can complete the action before anyone notices. The alert on logging failure is as important as the log itself.

Logs from individual systems only tell part of the story. Correlation reveals the full picture.

This practice requires correlating audit record review, analysis, and reporting processes to support investigation and response to unusual or suspicious activity. A login failure on a workstation means little in isolation. That same failure, correlated with a spike in outbound traffic from the same IP ten minutes later, is an incident.

Implementation:

• Centralize log collection so logs from multiple systems can be queried and correlated together. This is the core function of a SIEM or log management platform
• For Microsoft environments, Microsoft Sentinel is the native SIEM with built-in connectors for Entra ID, Defender for Endpoint, Azure services, and Windows Event Forwarding. The free tier of Sentinel includes 10 GB/day ingestion
• Define correlation rules or saved queries for the attack patterns most relevant to your environment: brute force attempts, impossible travel (login from two geographically distant locations within minutes), lateral movement patterns, and data staging/exfiltration indicators
• Document your correlation approach. Assessors may ask how you identify suspicious activity across systems. Having named detection rules or documented query logic is concrete evidence

Common mistake: Forwarding logs to a central location but performing no actual correlation. Centralized storage is not correlation. Correlation requires that someone or something is actively looking across log sources for patterns that span multiple systems or time periods.

You need the ability to filter, query, and generate reports from your logs on demand.

This practice requires providing audit record reduction and report generation to support on-demand analysis and reporting. Raw logs are millions of events. The capability to reduce those to relevant records and generate actionable reports is what makes logs usable during an investigation or assessment.

Implementation:

• Any SIEM or log management tool with search and reporting functionality satisfies this practice. Microsoft Sentinel (KQL queries), Elastic SIEM, Splunk, and even Azure Monitor Logs all provide this capability natively
• Create saved queries or reports for your most common analysis needs: all privileged account activity over a time period, all failed login attempts for a specific user, all access events on a CUI file share
• Demonstrate the capability during an assessment by running a sample query. "Show me all logins to the file server between June 1 and June 10" is a reasonable assessor request
• Audit record reduction does not mean deleting logs. It means the ability to filter and present a relevant subset of records for analysis without requiring raw log review

Common mistake: Logging to flat files with no query capability. Terabytes of .log files on a server satisfy 3.3.1 (barely) but do not satisfy 3.3.6. The capability to produce reports and filter records is a distinct requirement.

If your system clocks aren't synchronized, your logs can't be correlated accurately.

This practice requires providing a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records. This is one of the least controversial CMMC practices to implement and one of the most damaging to ignore.

Implementation:

• Active Directory environments: Domain-joined Windows machines automatically sync to the domain controller via the Windows Time Service (W32tm). Configure the PDC Emulator (the authoritative DC) to sync to an external NTP source such as time.windows.com or pool.ntp.org. Verify the hierarchy is working: check W32tm /query /status on a sample of workstations and servers
• Non-domain devices: Configure NTP settings directly on each device, pointing to your internal NTP server or an external source. Include NTP configuration in your device build standards so new devices are configured correctly from day one
• Network infrastructure: Firewalls, switches, and other network devices should sync to the same NTP source. Misaligned firewall timestamps are a common source of correlation failures during investigations
• Cloud resources: Azure VMs sync to the Microsoft Azure time service by default. Verify this is not overridden and that the Azure time service is treated as a trusted source in your documentation
• Document your NTP configuration: what source systems sync to, how the sync is validated, and what the monitoring looks like for NTP failures

Common mistake: Configuring NTP on servers but not workstations. If a threat actor operates on a workstation and the workstation clock is drifted by 30 minutes, correlating workstation events with server logs during an investigation will produce misleading timelines.

Logs must be protected from the very accounts they're monitoring.

This practice requires protecting audit information and audit tools from unauthorized access, modification, and deletion. An adversary who gains admin access to a system will attempt to cover their tracks by clearing or modifying logs. The audit system must be hardened against this.

Implementation:

• Forward logs to a centralized platform with access controls that are separate from the systems being logged. A server admin who can clear local event logs should not have the ability to delete forwarded logs in the SIEM
• Enable log immutability where available. Azure Monitor Logs supports immutable storage. Microsoft Sentinel workspace data can be protected against deletion using retention locks
• Use Windows Event Forwarding to push logs from endpoints to a dedicated collector before they can be cleared locally. Once forwarded, local clearing doesn't affect the centralized copy
• Restrict access to audit tools (SIEM consoles, log management platforms) to a small group of security personnel using role-based access control. Not everyone who monitors systems needs the ability to delete log data
• Enable auditing on the audit system itself. Log access and configuration changes to the SIEM or log management platform

Common mistake: Server administrators having full control over the log management system. The person whose actions are being logged should not be able to delete those logs. Separation of duties between IT administration and log management is the control.

Restrict who can configure, clear, or manage the audit logging system.

This practice requires limiting the management of audit logging to a subset of privileged users. It is the access control companion to 3.3.8. Where 3.3.8 is about protecting audit data technically, 3.3.9 is about restricting who has the administrative rights to manage it.

Implementation:

• Identify who in your organization has the ability to manage audit logging: configure audit policies, clear event logs, manage SIEM connectors, and delete log data. This should be a small, named group
• In Active Directory, the "Manage auditing and security log" User Right Assignment (found in Group Policy under Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment) controls who can clear the Security log. Restrict this to security administrators, not general IT staff
• In Microsoft Sentinel, use Azure RBAC to separate the Log Analytics Contributor role (can manage workspace configuration) from the Log Analytics Reader role (read-only access). Assign the Contributor role only to the small group responsible for audit log management
• Document the named individuals or groups who hold audit management privileges. This document is part of your evidence package and will be referenced by an assessor reviewing the AU domain

Common mistake: Every IT admin having the ability to clear event logs. In many small organizations, the default Domain Admins group has this right, which means every admin can cover their tracks. Restrict the "Manage auditing and security log" right to a dedicated security role.