AU.L2-3.3.9 Audit management: requirements and evidence

What AU.L2-3.3.9 audit management requires in plain terms

AU.L2-3.3.9 requires you to limit management of audit logging functionality to a defined subset of privileged users. When an assessor asks who can change logging, the answer must be a named, bounded group, and that group must be the only people able to turn logging on or off, change what is recorded, or alter where logs go. NIST SP 800-171A splits this into two assessment objectives: first, the organization defines the subset of privileged users allowed to manage audit logging; second, it actually limits audit logging management to that subset. Both must be satisfied with evidence before the requirement is MET.

The risk is concrete. An administrator who can disable a logging agent, edit a configuration file or change the retention setting can perform misuse and then remove the trace of it. That is why the requirement sits apart from general privilege management: every system administrator may need broad rights, but only a small group should hold the rights that control the audit trail. Privileged users often hold wide rights by default, inherited from operating system groups, cloud roles or application admin accounts, so the work is usually to find those inherited paths and remove or separate them, not to create a new role on paper. Confirm with your own environment which accounts can change logging settings across servers, cloud tenants, identity systems and the SIEM.

This is a 1-point requirement under 32 CFR 170.24, so it carries less weight in the score than many others, but it is not on the exclusion list in 32 CFR 170.21, which means it can sit on a POA&M if the overall score allows conditional status. Do not treat the low point value as a reason to skip it, because assessors test it with the same evidence rigor. Ask your assessor or consultant which evidence they expect, such as a system-generated list of privileged users with audit management rights, access control lists and tests showing that non-designated users cannot change logging. The NIST SP 800-171A assessment guidance is the natural reference for those objectives.

Which systems, accounts and teams fall under the audit management scope

AU.L2-3.3.9 is only as strong as the boundary drawn around it. The systems that write logs, the stores that hold them, the accounts that can change logging settings and the outside providers with administrative reach all belong inside the assessed scope, or the subset of people who manage logging will be defined on paper only.

Systems that generate audit logs

Every CUI system, identity provider, firewall, server, database and application that writes audit records is in scope for 3.3.9 because each one has a logging configuration someone can change. Build an inventory of log sources from the system security plan boundary, then record where each source's logging is switched on, off or tuned. Ask whether any source keeps its own local logging control that sits outside the central administrative model, since those settings are the ones a privileged user could alter unseen.

Centralized log stores and SIEM

Whether logs are centralized changes the work more than any other scoping decision. A SIEM or central repository concentrates the logging management plane, so administrators of that platform become the subset to define and restrict. If logs stay on each system, the subset spans many administrators and the evidence of who changed what must be gathered from each host. Document the choice, because it determines where access lists and change records must be produced.

Privileged accounts and groups

Scope every account and group that can alter audit settings, including domain administrators, cloud global administrators, root or sudo users on log hosts, and service accounts with write access to logging configuration. Export a system-generated list of these holders, since the assessment objectives for 3.3.9 call for one as evidence. Flag shared or dormant accounts, because an identity that cannot be traced to a person weakens the separation the requirement intends.

Audit management roles and teams

Name the people who are permitted to manage audit logging, and separate them from teams that administer the systems being logged. The CMMC Assessment Guide expects all audit managers to be privileged users, but only a small subset of privileged users should manage logging. Identify which teams, such as security operations, platform engineering or help desk, currently hold logging rights they do not need, and confirm that their duties are kept apart from logging management.

Managed service providers with admin access

A managed service provider with administrative access to the CUI environment is inside the audit management scope when it can change logging settings or reach log stores. Confirm in the contract and the provider's access records whether its engineers hold audit management rights, how those rights are granted and reviewed, and whether provider staff are members of the defined subset. Your organization still owns the control, so the provider's access must be evidenced in your records as well as theirs.

Hosted and self-hosted logging tools

Logging functions inside open-source platforms need their own boundary decision. Nextcloud's admin_audit app writes to audit.log in the data directory, or to a path set with logfile_audit, so filesystem permissions and the configuration keys controlling that path belong in scope. OpenBao audit devices record every API request and response, so administrators of the secrets platform may also hold audit management rights. Confirm each platform's logging controls against its current documentation before finalizing the boundary.

How to implement audit management limits step by step

This sequence narrows who can turn audit logging on, off or change its settings, and leaves a record that the restriction works. Each step produces an artifact an assessor can examine, from the inventory of logging controls to the tests that confirm only the approved subset can change them.

Inventory every audit logging control point
List each place where audit logging can be configured, enabled, disabled or redirected. This includes operating system audit policies, the logging settings of applications such as Nextcloud, audit device settings in secrets management tools such as OpenBao, SIEM collectors, log forwarders and the cloud provider's audit trail settings. The IT or platform engineering lead owns this step, usually with the system administrators who run each component. The output is a register that names each system, the setting or file that controls logging, and the account types that can currently change it. You know it is done when someone who did not build the inventory can find every logging control point from the register.
Define the approved audit administrators
Decide which named individuals may manage audit logging functionality, and keep the group as small as operations allow. The security owner approves the list, and each person is named by account, not by role alone. The CMMC Assessment Guide expects all audit managers to be privileged users, while only a small subset of privileged users should manage logging, so this list is a subset of the privileged user population. The output is a signed approval record with the defined subset, the justification for each member and the date it was approved. Ask your assessor what level of approval evidence they expect before you finalize the format.
Separate audit duties from other privileged functions
Confirm that the approved audit administrators do not also hold the duties they would need to hide misuse, such as account administration for the systems they audit or the authority to delete or alter the log store. Where one person must hold both kinds of access during a small team's operation, document the compensating controls, such as independent review of changes to logging settings by someone outside the audit group. The security owner and the HR or IT administrator who assigns roles carry out this step. The output is a separation matrix that lists each privileged function against the audit group and marks conflicts. It is complete when every conflict is either removed or documented with an approved compensating control.
Restrict permissions and group membership
Translate the approved list into technical limits. Remove audit logging management rights from other administrator groups, lock the configuration files for logging, and restrict membership in the directory groups that map to audit management. For Nextcloud, this covers the admin_audit app and the audit.log location and logfile_audit path. For OpenBao, it covers the permission to enable or disable audit devices. The platform team performs the changes and records the commands or policy objects used. The output is a set of configuration exports and group membership reports. The step is done when a fresh membership report shows only the approved accounts.
Record the approved list and change process
Store the approved subset, the separation matrix and the permission configuration in the system security documentation, and state how a change to membership is requested, approved and recorded. Link the list to the account review process so departures and role changes remove access promptly. The compliance lead and the system owner maintain this record. The output is a versioned document, usually kept with the system security plan, that an assessor can read without help from the people who wrote it. Confirm with your assessor which artifacts they will request so the record matches what they test.
Test that only the subset can change logging
Test the restriction the way an assessor would. Attempt logging configuration changes with accounts outside the approved group and confirm they are refused. Attempt the same changes with an approved account and confirm the change is permitted and recorded. Review the system-generated list of users with audit management access against the approved list, and check that the access control lists for the logging configuration match the approved group. Test the mechanisms that grant the access, not only the settings they produce. The tester is someone independent of the administrators who configured the controls. The output is a dated test log with each test, the account used, the expected result and the actual result. The step is complete when every test matches expectation or has an open finding recorded in the plan of action.

How an assessor tests the 3.3.9 limit on audit management

This table maps the two SP 800-171A assessment objectives for AU.L2-3.3.9 to the test an assessor runs, the evidence requested and the findings that usually cause a requirement to fail. Read each row as a question the assessor asks: first whether the subset is defined, then whether the subset is the only group that can change audit logging.

Assessment step	What the assessor does	Evidence requested and common findings
Objective 1: subset defined	Confirms the organization has defined which privileged users may manage audit logging, and that the definition is current and approved.	Access authorizations and a documented list of named audit managers. Finding: no written subset, or a subset that exists only as a group name with no defined members.
Objective 1: system-generated list	Compares the defined subset against a list pulled from the system showing who holds audit logging management rights.	Export of role or group membership from the logging platform and the directory. Finding: members in the system that are absent from the approved list.
Objective 2: access control lists	Reviews the permissions on audit logging functions, configuration files and log storage to see who can change them.	Access control lists, role definitions and policy files. Finding: general administrator roles that inherit the right to disable or reconfigure audit logging.
Objective 2: separation of duties	Checks whether audit managers also hold other privileged functions, such as system administration or security operations, that could let them alter their own activity.	Role assignments showing which accounts hold both audit and other administrative rights. Finding: one account holding audit management and general root or domain administrator rights.
Negative test	Signs in as a privileged user outside the defined subset and attempts to change audit settings, disable a log source or alter retention.	Recorded attempt and denial in the logs, plus the access decision. Finding: the attempt succeeds, or the denial is not itself logged.
Positive test	Has a designated audit manager make a configuration change and confirms the change is authorized and recorded.	Change record and the audit entry for that change. Finding: no record can be tied to a named subset member because shared accounts are used.
Undocumented subsets	Looks for audit management rights granted through ad hoc tickets, service accounts or inherited roles that are not in the approved subset.	Ticket history, service account inventory and role change logs. Finding: service accounts able to change logging settings with no owner or documented purpose.

Evidence that passes an AU.L2-3.3.9 review

An assessor testing AU.L2-3.3.9 Audit management checks two things: who is defined as allowed to manage audit logging, and whether that limit is enforced in the systems. The cards below cover the documents, system lists and test records that show both, and how to keep them current between reviews.

Access authorizations for audit management

Written approvals that name each person allowed to change audit logging settings, with the date granted and the approver. Assessors compare these approvals against the accounts that actually hold audit management rights. Any account with rights but no approval is a finding. Keep the approvals tied to a role rather than to a person's name alone, so reassignments leave a trail.

System-generated list of audit managers

An export taken directly from the identity provider, the logging platform or the directory, showing every account that can manage audit logging, with its group memberships. A list typed by hand carries less weight than an export. Confirm the export shows nested group membership, because a user added through a group can hold rights that a flat list hides. Date the export and record who ran it.

Access control lists on logging configuration

The permissions on the files, settings and APIs that control audit logging, such as the logging configuration and the log store. Assessors look for write access limited to the defined subset and read access for everyone else who needs it. Capture the ACL output itself, not a summary of it. Note any inherited permissions, since they often grant more access than the owner intended.

Role definitions separating audit duties

Written role descriptions showing that audit managers hold a narrow set of logging duties and do not also hold other privileged functions such as system administration or account provisioning. The CMMC Assessment Guide expects these duties to be kept separate. Include the role matrix that maps each privileged role to its permitted actions, and state where an individual holds more than one role.

Test records of the access mechanisms

Dated records showing that someone tested whether a non-authorized privileged user can change audit logging settings and that the attempt is blocked or logged. Test records prove the limit works, not only that it is written down. Keep the test steps, the account used, the result and the name of the tester. Repeat the test after any change to identity groups or logging platform permissions.

Final evidence and refresh cycle

Assessors accept only evidence in final form. Drafts, unsigned approvals and exports marked as work in progress do not satisfy an objective, which can leave AU.L2-3.3.9 unmet. Set a fixed review date for the authorization list, ACL exports and role matrix, and regenerate the system lists whenever group membership changes. Confirm with your assessor or C3PAO how far back they expect evidence to reach, since that depends on the assessment type.

Using Nextcloud and OpenBao audit logs to support the control

The admin_audit app in Nextcloud records additional event information about server activity. Its output is written to a file named audit.log in the Nextcloud data directory, unless an administrator sets a different location with the logfile_audit configuration key. For AU.L2-3.3.9, the relevant point is that the log exists and that its location and settings are known and documented, so an assessor can see what is being recorded and where it lives.

Enabling the app: Confirm that admin_audit is installed and enabled in each environment, and keep the enabled state in the configuration baseline.
Log location: Record whether audit.log sits in the default data directory or at a path set with logfile_audit, and document that path in the system security plan.
Event scope: List which event types the app captures in your version, since coverage depends on the release you run.
Change tracking: Keep a record of who edited the app settings and when, because changing the audit configuration is itself a privileged action.
Log handling: Confirm that the file permissions on audit.log limit reads and writes to the designated audit managers.

Check that the documented log path, the enabled state and the file permissions match what the environment actually does.

What meeting AU.L2-3.3.9 costs in money and effort

Most of the cost of AU.L2-3.3.9 is people time, not software. The organization pays for the work of deciding who may manage audit logging, configuring the systems so that only those people can do it, and proving the arrangement works year after year. The largest one-time item is role design: naming the small subset of privileged users who may change audit settings, confirming that their other administrative duties are kept separate, and getting that decision approved and written into the system security plan. Expect security, system owners and the people who sign off access to be involved. Configuration follows, covering who can change logging settings, who can read or delete audit files, and how changes to those settings are themselves recorded. Ask any implementation partner to price these as separate line items with named deliverables.

Recurring cost sits in evidence upkeep and review. Access to audit logging management has to be re-checked on a schedule the organization defines, and each review produces a system-generated list of privileged users with audit management rights, approvals for any changes, and access control lists that match the approved roles. Someone must own that cycle, and the list must stay current when staff join, move or leave. The cost rises with the number of systems that feed logs into the audit function, the number of administrators, and how often roles change. Open-source logging tools remove license spend, but they do not remove this engineering and review time, and they still need hardening, upgrades and documentation. Ask vendors and partners to state which of these items are included in a fixed-scope quote and which are retainer work.

External review is the final cost. An independent assessor will test whether the subset is defined and whether access to audit logging management is limited to it, using the evidence described above. Ask the assessor or Registered Practitioner Organization to confirm in writing what evidence they will request, so the organization does not pay to rebuild records at the assessment. Where Level 2 status depends on this requirement, check the current status of the CMMC phase schedule and the rules for POA&M items before budgeting, since the CMMC Program rule and the current Department of War guidance on implementation should be read together.

Who owns audit management limits and what partners can take on

The organization owns the requirement itself. Leadership and the security function must decide which people count as privileged users, which of them may manage audit logging, and what approval is needed to add or remove someone from that subset. The assessment objectives in NIST SP 800-171A ask for a defined subset and for audit logging management limited to that subset, so a documented, current decision is the first piece of evidence an assessor will look for. No partner can make this decision on the organization's behalf.

Defining the subset: Name the individuals or roles that may change audit logging settings, rotate log storage, or change retention.
Approval rules: Write who approves additions and removals, and how quickly removals happen when someone changes jobs or leaves.
Separation of duties: Decide which privileged functions must stay with other people, so audit managers do not also administer the systems they log.
Review cadence: Set how often the subset is reviewed and who signs off.
Ownership of exceptions: Name an accountable owner for any emergency or break-glass access to audit logging.

Confirm with your assessor which records they expect to see for the subset, such as a system-generated list of privileged users and the access authorizations behind it.

Common gaps that fail audit management reviews

Assessors testing AU.L2-3.3.9 look for two things: a defined, documented subset of privileged users, and proof that audit logging management stays inside that subset. The gaps below are the ones that most often break one of those two tests. Each one has a closing action an organization can take before an assessment.

Approvers who can also edit logs

When one administrator can approve a change to the logging configuration and also edit the logging settings or the audit records themselves, the separation the requirement expects does not exist. Assessors look for the duties to sit with different people or, at minimum, for a documented reason and compensating review. Check who holds write access to the logging configuration and who holds approval rights over it, then compare the two lists. Action: split approval and administration of audit logging into separate roles and document the split.

No documented privileged subset

The first assessment objective requires the organization to define which privileged users may manage audit logging. Many environments grant audit rights implicitly through broad administrator groups, so no one can produce a list that matches the definition. Without a written definition, the subset cannot be tested. Action: write the subset definition, name the roles it includes, and tie it to the system security plan.

Shared administrator accounts

A shared administrative login makes it impossible to tell which person changed a logging setting or cleared a log. This undermines the subset requirement and the accountability requirements that depend on it. Review the administrator accounts on the logging platform, the operating system and the cloud tenant for generic or shared names. Action: replace shared logins with named accounts for each member of the subset, and record who holds each one.

Stale access lists

Access lists drift as people change roles or leave. A former engineer who still appears in the audit management group is a finding even if that person never used the access. Assessors compare a system-generated list of privileged users against the documented subset and the personnel records. Action: run a recurring export of audit management group members and reconcile it against the documented subset and HR changes.

Logs alterable by the users they record

If the same administrators who generate activity can also modify or delete the audit trail, misuse by a privileged user can be hidden. This is the core risk the requirement addresses. Test whether a privileged user with general administrative rights can change the audit device settings, rotate or truncate files, or disable forwarding without anyone else seeing it. Action: confirm that changes to audit logging are themselves logged to a store the subset cannot edit, and test that the log captures its own configuration changes.

Questions buyers ask about AU.L2-3.3.9 audit management

What drives the cost of meeting AU.L2-3.3.9?

The cost depends mostly on how many people and systems touch audit logging today and how much of the access model needs to change. The requirement is worth 1 point, but the work is rarely that small: you must define a narrow group of privileged users allowed to manage audit logging, then restrict those duties in each system that holds audit records. Cost rises with the number of log sources, the number of administrators who currently hold broad rights, and the amount of documentation missing from the system security plan. Ask any partner to price the work from a written scope that lists each system in the boundary and who administers it. No public figure exists for this requirement alone, so compare quotes against that scope rather than a headline number.

How long does it take to implement AU.L2-3.3.9?

Timing depends on the state of your privileged access model, not on the requirement's point value. Many organizations can define the privileged subset quickly if roles are already documented, but removing audit management rights from administrators who also run other systems can require change tickets, approvals and testing. Build time for evidence collection, such as system-generated lists of privileged users and access control lists, is often overlooked. Confirm the duration in writing with your implementation partner and ask which steps depend on your change board or on a systems owner's availability.

What does the work need from our internal team?

The work needs decisions and access from people who own the systems. Your team must name the systems that generate or store audit records, agree which roles should manage audit logging, and approve the removal of conflicting rights. Security engineers and system administrators must confirm how each platform stores its logs and who can change retention or delete records. A compliance lead should own the written definition of the privileged subset and the evidence index. Plan for these people to review changes and sign off on evidence in final form, because an assessor will only accept finished records.

Can we implement AU.L2-3.3.9 in-house without outside help?

Yes, an organization can implement this requirement in-house if it has administrators who understand its logging platforms and a compliance owner who can write the evidence. The assessment objectives in NIST SP 800-171A are clear: define the subset of privileged users allowed to manage audit logging, and limit that management to the subset. The practical risk is that internal administrators often hold overlapping roles, so separating duties can be politically difficult. An outside partner can prepare systems and evidence, but it cannot decide your risk tolerance or certify your environment. Only an independent assessor performs the assessment, so use outside help only where it clearly reduces effort.

How do POA&M rules apply to AU.L2-3.3.9?

AU.L2-3.3.9 can be placed on a plan of action and milestones if your score allows it. Under 32 CFR 170.24 it is worth 1 point, and it is not on the exclusion list in 32 CFR 170.21, so it may be included in a POA&M for Conditional Level 2 status when the score is at least 88 of 110. Closeout is due within 180 days. Treat that as a deadline to plan against, not a reason to defer. A POA&M item must describe the gap and the remediation, and the Affirming Official must still stand behind the posted status. Confirm current eligibility rules against the eCFR text and the DoW CIO's current guidance before relying on them.

What does DeployOpen do and what does the assessor do?

DeployOpen prepares systems and evidence. Under a fixed-scope engagement, we can review how audit logging is administered, help define the privileged subset, configure separation of duties on self-hosted open-source platforms in your own infrastructure, and document the evidence your team will present. We do not issue assessment results, reports or certifications. Your organization owns its controls and the Affirming Official makes the attestation. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB, and the scope and deliverables should be agreed in writing before work starts.

How can open-source platforms show AU.L2-3.3.9 evidence?

Open-source platforms can produce evidence if their audit functions are configured and their access is documented. For example, Nextcloud's admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit, so you can show who has rights to change that configuration. OpenBao audit devices keep a detailed JSON log of every API request and response, with most sensitive values hashed with HMAC-SHA256. Confirm each platform's role model and whether audit management can be separated from other administration in your version. Evidence to collect includes the privileged user list, access control lists, and tests showing that non-subset administrators cannot change audit settings.

How DeployOpen scopes and prepares AU.L2-3.3.9 evidence

DeployOpen works on AU.L2-3.3.9 by first agreeing in writing which audit logging tools, administrator roles and privileged accounts are in scope, then building the role separation and access records an assessor will examine. The organization keeps ownership of its controls, and an independent assessor makes the determination.

How we scope

Inventory every system that generates, stores or manages audit logs within the CUI boundary.
Identify the privileged accounts that currently hold audit logging management rights and the roles they also hold.
Record the agreed scope, deliverables and timeline in writing before any configuration work begins.

How we build

Create a defined subset of privileged users authorized to manage audit logging, separate from general administrators.
Restrict audit logging configuration rights through role-based access controls and documented approval paths.
Configure audit devices and admin logging so changes to logging settings are themselves recorded and attributable.

How we hand over

Deliver a system-generated list of users with audit logging management access, along with access control lists.
Document the access authorizations and the test steps used to confirm logging management is limited to that subset.
Provide evidence in final form, with a note on which assessment objectives each artifact supports.

How we support

Review role assignments and logging permissions on the schedule the organization defines after handover.
Offer ongoing support, upgrades and continuous testing as a retainer, sized to the agreed scope.
Confirm with your assessor which evidence format and retention period they will accept before finalizing artifacts.