AU.L2-3.3.9

AU.L2-3.3.9: Audit Management

Limit audit log management functions (configuration, deletion, archival) to authorized individuals to prevent tampering.

Audit management is the most sensitive security privilege. The person who can turn off logging, delete logs, or change what gets logged has the power to hide their own activity. AU.L2-3.3.9 requires you to severely restrict who has these capabilities and document the decisions.

This is distinct from reading logs (AU.L2-3.3.8) and analyzing them (AU.L2-3.3.3). An analyst might read hundreds of logs daily. A SIEM administrator might configure what gets logged. Those are different privilege levels, and you need to keep them separate. The goal is to prevent the person administering your logging from also being able to hide their own actions.

Family Audit and Accountability
Practice AU.L2-3.3.9
Difficulty Medium
Key evidence Authorization list, SIEM role configuration, privilege grant documentation, management action audit logs

What the assessor is actually evaluating

The assessor is checking two main things. First: “Who can manage the audit system?” They want a list of authorized individuals with specific roles that allow them to change logging configuration, delete logs, or archive them. “Only the IT director and the SIEM administrator” is acceptable. “Everyone on the IT team” is not.

Second: “How are those privileges granted and monitored?” They want evidence that privileges aren’t just sitting there indefinitely. Is there a formal request and approval process? How often are privileges reviewed? Do you monitor when someone with audit management privileges makes changes? The assessor wants to see that you treat this as a high-control activity.

The third element, implied: Separation of duties. The SIEM administrator should not be the only person reading and analyzing logs. Ideally, different people have different roles. One person or team manages the system. Another analyzes logs. A third reviews findings. This separation prevents one person from hiding activity while also managing the system.

What a realistic SSP definition looks like

Example SSP Language: AU.L2-3.3.9
"Our organization restricts audit log management functions to authorized personnel only. Audit management includes configuration of what is logged, deletion or archival of logs, changes to retention settings, and management of user access to the audit system.

Authorized personnel and their roles:

  • [Name/Title]: SIEM Administrator - responsible for SIEM platform management, user access control, log collection configuration
  • [Name/Title]: Information Security Officer - authorized to approve log retention and deletion requests, review audit management actions
  • [Title if applicable]: IT Director - secondary authorization for critical audit management decisions

Privilege granting process:

  1. Request is submitted specifying which audit management privileges are needed and business justification
  2. Request is reviewed and approved by [approver: IT Director, Security Officer]
  3. Access is granted in the SIEM with the minimum privileges required
  4. The approval record is retained for [X years]

Privilege review and revocation:

  • Audit management privileges are reviewed [quarterly/semi-annually]
  • [Named person] confirms that each authorized person still needs their privileges
  • Privileges are revoked immediately when a person changes roles
  • Unused or unnecessary privileges are removed

Monitoring of audit management:

  • All configuration changes to the SIEM are logged
  • All user additions, deletions, or privilege changes are logged
  • Logs are deleted or archived only by [authorized person/role]
  • All audit management actions are reviewed [monthly/quarterly] for anomalies

Separation of duties:

  • The SIEM administrator configures logging but does not conduct routine log analysis
  • Log analysis is performed by [separate team: security operations center, security analysts]
  • The IT director approves major configuration changes but does not have day-to-day administrative access"

This level of detail demonstrates you’ve thought through who needs what access and why.

How to present your evidence

Evidence checklist
  • Authorization list showing who has audit management privileges
  • SIEM role configuration showing role-based access control
  • Privilege grant approval process with recent examples
  • Audit management action logs showing configuration changes

Build evidence across four dimensions:

  1. Authorization list. A document listing who has audit management privileges, what those privileges are, and the authorization date. For example:

    • John Smith, SIEM Administrator, configuration rights, approved 1/15/2025
    • Jane Doe, Security Officer, deletion/archival rights, approved 1/15/2025

    Include the authorization approver and date.

  2. SIEM role configuration. Screenshot or export from your SIEM showing the roles defined and their associated permissions. Show that only authorized individuals have administrative or privileged access. Show that analyst roles have read-only access.

  3. Privilege grant approval process. Documentation of how new audit management privileges are requested and approved. This might be an email, a ticket system entry, or a formal approval form. Include at least one example from the past 12 months showing a request, justification, and approval.

  4. Audit management action logs. Evidence that you log and review when audit management actions occur. Pull a recent list of configuration changes in your SIEM. Show who made them, when, and what was changed. Include your review documentation.

Get assessment room tips in your inbox

Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.

Assessment room tips

Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.

Q: "Who can configure what gets logged and delete logs? Why only those people?"
Name two or three specific people/roles. Explain the separation. "The SIEM administrator configures logging. The security officer approves log deletion or archival. The IT director approves major configuration changes. This ensures no single person can unilaterally change logging or hide activity."
Q: "How do you grant these privileges? Show me an example."
Pull up a recent privilege grant (or describe a recent example). "When we hired a new SIEM administrator, they submitted a request, it was approved by the IT director, and we documented the approval. Access was provisioned with only the necessary roles, and the approval is retained in our records."
Q: "Do you monitor when these privileged people make changes? What's an example?"
Pull your SIEM audit log showing administrative actions. "Every configuration change is logged here with who made it, what changed, and when. Our security officer reviews these monthly. Here's an example from last month where we added a new data source to logging."

Common failures

Too many people with administrative access: Half the IT team has SIEM administrator credentials. There's no documented authorization process. No one monitors what they do with their access. This fails the practice immediately. Restrict privileges tightly and document who has them.
No documented authorization or approval: You can name the SIEM administrator but can't produce an authorization memo or approval record. The assessor questions how they were assigned. Document the approval process and retain records.
No separation of duties: The same person configures logging, analyzes logs, and approves log deletion. They could silently disable logging, do something, turn it back on, and delete evidence. Separate these functions across at least two people.
Privilege review and revocation process: You conduct periodic reviews (quarterly is good) of who has audit management privileges. When people change roles, privileges are revoked within days. When people leave the organization, access is removed immediately. Document these reviews.
Audit management action monitoring: All changes to audit system configuration are logged and someone reviews them regularly. You can show a pattern of who changes what and when. This creates accountability.

If you use an MSSP

Your MSSP should have a limited number of authorized personnel with access to your audit systems. These individuals should be named and documented. You should have contracts or agreements covering their access and responsibilities. You should be able to request that specific MSSP staff members be removed from your systems if needed.

Your MSSP is responsible for limiting their own staff access to your audit environment and monitoring their administrative actions. You’re responsible for authorizing which MSSP personnel have access to your data and approving access changes. Both of you together maintain accountability. A good MSSP provides regular documentation of who has access to your audit logs and what administrative actions they’ve taken.

Document MSSP privileged access to your audit systems

Request a list of MSSP personnel who have administrative access to your audit logs. Ask how they control that access and monitor their administrative actions. Request a sample of their audit logs showing administrative actions taken on your account. In the assessment room, ask your MSSP to explain their privilege model and how they restrict access to your data. They should be able to name who has access and show evidence of monitoring their own privileged users.

Disclaimer: This guide is educational and not official CMMC documentation. Always refer to NIST SP 800-171 and the official CMMC Assessment Guide for authoritative requirements. Individual assessment results depend on implementation details specific to your organization.

New practice breakdowns and assessment tips every week. Follow on Substack to stay current as the November 2026 deadline gets closer.

← CM.L2-3.4.1: Baseline Configurations All Practices AU.L2-3.3.8: Audit Protection →