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.
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
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:
- Request is submitted specifying which audit management privileges are needed and business justification
- Request is reviewed and approved by [approver: IT Director, Security Officer]
- Access is granted in the SIEM with the minimum privileges required
- 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
- 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:
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.
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.
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.
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.
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. 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. 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.
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.
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.
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.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
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&A: What the assessor asks
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.