CMMC · Rev 2.13L2AU · Audit & Accountability

AU.L2-3.3.9

Audit Management

Requirement

Limit management of audit logging functionality to a subset of privileged users.

Assessment objectives

An assessor checks each lettered objective separately. The letters in brackets elsewhere on this page, such as [a] or [b,c], refer to these.

Determine if:

aa subset of privileged users granted access to manage audit logging functionality is defined; and
bmanagement of audit logging functionality is limited to the defined subset of privileged users.

From the CMMC Level 2 Assessment Guide v2.13 · publisher approved 2026-10-31.

How to implement

Only a small, named subset of your privileged users should be able to change audit settings, stop logging, or manage the log store; general administrators should not. The goal is that an administrator who misuses their rights cannot also hide it. In a very small company where one person does everything, put audit management with a separate party such as an MSP or MDR provider, or at least alert a second person on every audit-setting change.

1
PolicyDefine the audit managers: the named people or roles (for example the security lead and the SOC provider) allowed to change audit policy, logging configuration, retention and the SIEM. Keep them a subset of privileged users, and where possible separate from those who administer the systems being logged.[a]
2
TechnicalImplement it in each platform: assign the Purview 'Audit Logs' role and the rights to change Entra diagnostic settings only to audit managers; restrict the Windows 'Manage auditing and security log' user right and audit-policy Group Policy objects to an audit-admin group; limit SIEM administrator roles and log-forwarding configuration on firewalls to the same group.[b]
3
TechnicalAlert a second person on audit-management actions: audit policy changed (event 4719), security log cleared (1102), Purview auditing turned off, diagnostic settings deleted, SIEM retention or rule changes.[b]
4
ProcessReview the audit manager list and the actual role assignments quarterly, as part of the privileged access review, and record the result.[a][b]

Evidence to collect

Artifacts that show the practice is implemented and operating. Tags show which assessment objectives each one supports.

Defined audit manager list[a]

record · reviewed quarterly

Named list of people or roles allowed to manage audit logging, with approval and the reason each needs it.

Role assignment exports for audit functions[b]

configuration export · dated within 90 days

Purview role group membership, Entra role or Azure RBAC assignments for diagnostic settings, SIEM admin users, Group Policy showing the 'Manage auditing and security log' assignment.

Audit-management change alerts[b]

configuration export · current configuration

Alert rules for audit policy and logging configuration changes and their recipients.

Quarterly audit-manager access review[a][b]

record · most recent four quarters

Dated review notes comparing the defined list with actual assignments.

How assessors check

Examine: Audit and accountability policy, access control policy, list of privileged users with audit management access, system configuration, audit records of audit-setting changes.
Interview: Personnel with audit management responsibilities and system administrators.
Test: With a privileged account that is not an audit manager, attempt to change audit policy, turn off auditing or delete logs and show it is denied; show the role assignment list matches the defined list.

Tools and products

Named options a contractor can adopt, with an honest cost tier. The industry standard is listed even when it is expensive, alongside what is free and acceptable for a very small shop.

Microsoft Entra Privileged Identity ManagementJust-in-time role activationPaidWorkable for a small shop

Requires Entra ID P2 (or E5/G5); makes audit roles time-bound and approved.

Group Policy user rights assignmentWindows audit rights restrictionFreeGood fit for a small shop

Built in; restrict 'Manage auditing and security log' to a dedicated group.

Managed SOC or MDR provider (for example Huntress, Arctic Wolf)Separation of audit managementPaidGood fit for a small shop

An outside party running the SIEM gives a small shop real separation between system admins and audit managers.

Editorial mentions, not endorsements. Pricing and tiers change; confirm with the vendor and check FedRAMP or GCC High availability where CUI is involved.

Common pitfalls

Every Global or Domain Administrator can turn off auditing, so the 'subset' is everyone.
No defined list, only 'IT manages logging'.
In a one-person IT shop, no separate party is alerted when audit settings change.

Platform notes

Microsoft 365 (GCC / GCC High)

Global Administrators can always reach audit settings, so keep Global Admin to two or three accounts and alert on changes. Use the Purview 'Audit Logs' role for audit managers, scope Azure RBAC on Log Analytics and Sentinel workspaces, and use PIM (Entra ID P2) for just-in-time access to these roles. Same approach in GCC and GCC High.

Google Workspace

Create a custom admin role for reports and audit access and limit Super Admin accounts; manage log export settings (BigQuery, SIEM) with dedicated IAM roles.

On-premises or MSP-managed

A dedicated audit-admin group holding the 'Manage auditing and security log' right and edit rights on audit Group Policy objects; an MDR or SOC provider owning the SIEM so internal admins cannot alter it.

Related practices: AU.L2-3.3.8, AC.L2-3.1.4, AC.L2-3.1.5, AC.L2-3.1.7

Editorial implementation guidance published November 2, 2026. It is not part of the official requirement and does not replace the assessment guide.

Crosswalk

Full crosswalk

The NIST requirements this practice is built on, what NIST made of each in the newer edition, and the SP 800-53 controls behind them, each from an official NIST or DoD table. Open any one to read it and see every CMMC practice it supports.

NIST SP 800-171 Rev 2SP 800-171 Rev 3SP 800-53 Rev 4SP 800-53 Rev 5

NIST SP 800-171 Rev 2

3.3.9

SP 800-171 Rev 3

03.03.0803.03.09 withdrawn; incorporated into

SP 800-53 Rev 4

AU-9 (4)

SP 800-53 Rev 5

AU-9S AU-9(4)DS

How these were reached

AU-9 · Protection of Audit Information
- S source control of the SP 800-171 Rev 3 or SP 800-172 Rev 3 requirement (NIST OSCAL) · via 800-171 Rev 3 03.03.08 → 800-53 Rev 5 AU-9
AU-9(4) · Protection of Audit Information | Access by Subset of Privileged Users
- D SP 800-171 Rev 2 Appendix D → SP 800-53 Rev 4 control → NIST's Rev 4 → Rev 5 comparison · via 800-53 Rev 4 AU-9 (4) → 800-53 Rev 5 AU-9(4)
- S source control of the SP 800-171 Rev 3 or SP 800-172 Rev 3 requirement (NIST OSCAL) · via 800-171 Rev 3 03.03.08 → 800-53 Rev 5 AU-9(4)

Rev 5 paths: D SP 800-171 Rev 2 Appendix D → SP 800-53 Rev 4 control → NIST's Rev 4 → Rev 5 comparison; S source control of the SP 800-171 Rev 3 or SP 800-172 Rev 3 requirement (NIST OSCAL); C SP 800-172 (Feb 2021) Appendix C. NIST also names this Rev 3 requirement as the successor of other withdrawn requirements: open “How these were reached” under the Rev 5 controls for which, in NIST's words.

Where each link comes from (7 links from 5 official documents)

32 CFR Part 170 Office of the Federal Register / GPO

AU.L2-3.3.9 → 3.3.9“Level 2 security requirement”32 CFR 170.14(c)(1) numbering (REQ is the NIST SP 800-171 R2 requirement number) and 170.14(c)(3)

NIST SP 800-171 Rev 2 → Rev 3 change analysis NIST

3.3.9 → 03.03.09“Withdrawn”sheet "Change Analysis 800-171 R2-R3" row 35

NIST SP 800-171 Rev 3 (OSCAL) NIST

03.03.09 → 03.03.08“Incorporated into”control 03.03.09 link rel=incorporated_into
03.03.08 → AU-9“Source control”control 03.03.08 link rel=reference (AU-09)
03.03.08 → AU-9(4)“Source control”control 03.03.08 link rel=reference (AU-09(04))

NIST SP 800-171 Rev 2 NIST

3.3.9 → AU-9 (4)“Appendix D mapping”p.80 Table D-3

NIST SP 800-53 Rev 4 → Rev 5 comparison NIST

AU-9 (4) → AU-9(4)“Changes control text Changes discussion”sheet "Rev4 Rev5 Compared" row 206

Further discussion

Companies should restrict access to audit logging functions to a limited number of privileged users who can modify audit logs and audit settings. General users should not be granted permissions to perform audit management. All audit managers should be privileged users, but only a small subset of privileged users will be given audit management responsibilities. Functions performed by privileged users must be distinctly separate from the functions performed by users who have audit-related responsibilities to reduce the potential of fraudulent activities by privileged users not being detected or reported. When possible, individuals who manage audit logs should not have access to other privileged functions. Example You are responsible for the administration of select company infrastructure that contains CUI, but you are not responsible for managing audit information. You are not permitted to review audit logs, delete audit logs, or modify audit log settings [b]. Full control of audit logging functions has been given to senior system administrators [a,b]. This separation of system administration duties from audit logging management is necessary to prevent possible log file tampering. Potential Assessment Considerations • Are audit records of nonlocal accesses to privileged accounts and the execution of privileged functions protected [b]?

Practice guide notes

Implementation guidance

Editorial examples to help you plan. Adapt them to your environment; the official requirement and objectives remain authoritative.

In plain language

Restrict audit-logging management to an appropriate subset of privileged users.

Implementation example

Example from the source assessment guide (not a mandatory implementation): You are responsible for the administration of select company infrastructure that contains CUI, but you are not responsible for managing audit information. You are not permitted to review audit logs, delete audit logs, or modify audit log settings [b]. Full control of audit logging functions has been given to senior system administrators [a,b]. This separation of system administration duties from audit logging management is necessary to prevent possible log file tampering.

Evidence examples

Examples suggested by the source guide (not an exhaustive or mandatory checklist): Audit and accountability policy; access control policy and procedures; procedures addressing protection of audit information; system security plan; system design documentation; system configuration setting s and associated documentation; access authorizations; system-generated list of privileged users with access to management of audit logging functionality; access control list; system audit logs and records; other relevant documents or records

Common mistakes

Giving every administrator unrestricted control over logging functions.

Track this in a workspace

The compliance workspace tracks each objective, its evidence and the tasks to close gaps. It is open to invited contractors while in pilot: request access below.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Source: DoD CIO · https://dodcio.defense.gov/CMMC/