AU.L2-3.3.2 User accountability: requirements and evidence

What AU.L2-3.3.2 user accountability requires of your audit records

AU.L2-3.3.2 requires that every action on a system holding CUI can be traced to one individual, and that the audit records prove it. If a Level 2 assessment is coming, the question an assessor will ask is simple: for any change, login or data access in the log, can you name the person who did it? The requirement is met only when the records themselves carry enough identity detail to answer that question without guesswork. It is a 3-point requirement, so it must be MET. It cannot go on a plan of action and milestones (POA&M), and an unmet result pulls the score down from the maximum of 110. In plain terms, the requirement addresses three CUI risks: shared or generic accounts where several people use one login, actions that cannot be attributed to anyone, and privileged misuse that goes unnoticed because the administrator's activity looks like everyone else's. NIST SP 800-171A breaks the requirement into two assessment objectives. The first is defining the audit record content needed to trace users uniquely to their actions. The second is confirming that the records actually created contain that content. An assessor will test both, so a written logging standard with no sample records behind it will not pass.

The difficulty is in the details. Each system may name the same person differently, such as a directory username, a local account, an email address and a service account. Source addresses are often missing from application logs, and clocks on separate servers drift, which makes the event order unreliable. Before the assessment, pick one identifier per user and confirm it appears in every relevant log, record the source and destination addresses for sessions, and verify that time stamps are consistent across systems. Pull a few records for privileged actions and check that each one resolves to a single named person. Ask your implementation partner or assessor to walk through that test with you, and confirm the logging settings in each system's own documentation, since the exact fields depend on the product and version you run.

Which systems, accounts and teams fall under user accountability

Scope for AU.L2-3.3.2 starts with every system that stores, processes or transmits CUI, then extends to the accounts that act on those systems. Each card below is a decision that changes how much logging work follows and who must sign off on it.

In-scope CUI systems and their boundary

Start with the assets inside the CUI boundary: servers, endpoints, email, collaboration tools and databases that hold or move CUI. Any system that can reach them with user credentials can affect accountability, so confirm whether jump hosts, directory servers and management consoles sit inside the boundary. Document the boundary in the system security plan so assessors can trace every in-scope system to its audit records.

Human and privileged user accounts

Every person who signs in must map to one identifiable account, and privileged accounts such as administrators need the same traceability with more detail. Confirm that administrators do not share a root or domain admin login and that elevated actions record the individual who performed them. Privileged activity also supports the logging of privileged functions tied to AC.L2-3.1.7.

Shared and service accounts

Shared accounts, break-glass logins and service accounts break the link between a person and an action unless they are controlled. Inventory each one, name a responsible owner, and record which person checked out the credential or invoked the service. Where a process runs under a service identity, the audit record should still show the human or change request that triggered it.

Third-party and cloud services

SaaS platforms, cloud control planes and hosted identity services generate user activity outside your servers. Decide which of them process CUI, request their audit logs or exports, and confirm that the records include user identifiers, source addresses and time stamps. A service whose logs you cannot obtain is a gap you must document or remove from the CUI scope.

Teams and responsibilities

IT operates the systems and account lifecycle, security operations reviews the records, and system owners decide which accounts and data their applications need. Assign each party a written role in the logging design, so a missing identifier is traced to a named owner. Assessors will ask who approved the audit record content, not only what it contains.

Managed service provider logs

When a managed service provider administers in-scope systems, its operators are users whose actions must be traceable. Their logs are in scope when they touch CUI systems or their accounts, and the contract should require access to those records on request. Confirm that the provider's personnel use individual accounts rather than a shared operations login.

How an assessor tests user accountability

This table maps the two NIST SP 800-171A assessment objectives for AU.L2-3.3.2 to the test an assessor runs, the evidence they request and the findings that most often cause a requirement to be scored NOT MET. Read each row as a step in the assessment: the first objective is about what your audit records must contain, and the second is about whether the records you actually created prove it. Because this requirement is worth 3 points and cannot go on a POA&M, a single gap here can block Conditional or Final Level 2 status.

Assessment step	What the assessor does	Evidence requested	Common findings
Objective 1: Audit record content defined	Reviews the documented audit record content and confirms it identifies individual users, such as user IDs, source and destination addresses and time stamps	Audit logging standard or configuration showing required fields, system audit policy exports and the system security plan entry	No written definition of required fields, or fields defined only for some systems
Objective 2: Created records contain the content	Samples audit records from in-scope systems and checks that each record carries the defined user identity, source address and time stamp	Raw log extracts for a sampled period, with the assessor choosing the sample and the organization providing unaltered records	Records missing source addresses, or user fields that show a service account or group instead of a person
Traceability of individual users	Selects users and traces their sign-ins and actions through the logs to confirm each action maps to one person	Identity provider logs, directory account records and a mapping from account to named individual	Shared accounts, generic admin IDs such as root or administrator, or accounts whose owner cannot be identified
Privileged function logging (linked to AC.L2-3.1.7)	Tests whether privileged actions such as role changes, configuration edits and security setting changes are recorded with the acting user	Privileged function list, logs of a privileged session and the link between the privileged role and the logged event	Privileged commands run through sudo or a shared administrator login that hide the individual actor
Test of the logging mechanism	Generates a controlled test event under a known user and checks that the record appears with the right identity and time	Test plan, test results and screenshots or exports showing the test event	Logging disabled on some hosts, or logs that stop when a service restarts
Reports and findings from audit review	Checks whether audit findings and reviews name the responsible user when an event is investigated	Audit review reports, incident tickets that cite user IDs and the review schedule	Investigations that cannot be tied to a single account because the record lacked identity data
Evidence in final form	Confirms the evidence is final and current, not a draft or an unsigned procedure	Approved, dated versions of the logging standard, configuration baselines and procedures	Drafted policies, undated screenshots or evidence from a test environment instead of the assessed system

Implementing user accountability in audit records, step by step

This sequence takes a system from an unclear logging picture to a documented definition of user-traceable audit records that an assessor can test against AU.L2-3.3.2. Each step produces an artifact that feeds the next, so the final evidence matches what the systems actually write.

Inventory the in-scope systems and accounts
The organization lists every system that stores, processes or transmits CUI, along with each application, administrative console and service that authenticates users. An implementation partner can help map these, but the organization owns the list and must confirm it against its system security plan. The output is a system inventory that names each component, its owner and how users reach it, including shared or generic accounts that will need attention in later steps.
Define the required audit record content
The team writes down the fields every audit record must carry so a single user action can be traced to one person. The CMMC Assessment Guide Level 2 points to user IDs, source and destination addresses and time stamps, and the team should add the event outcome (success or failure) so records show what happened. The output is a written audit record content standard, approved by the security owner, that defines each field and the systems it applies to. This document is the first item an assessor will ask for.
Enforce unique individual accounts through the identity provider
Applications should delegate sign-in to a central identity provider so each person authenticates with a unique identifier rather than sharing credentials. Open-source options such as authentik, which supports OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, or FreeIPA for Linux and UNIX environments, can serve this role, but the organization should confirm which protocols each application supports. The team then disables or documents any shared accounts. The output is a list of applications bound to the identity provider and a record of every exception with its compensating control.
Configure each application's audit output
For each in-scope application, an administrator turns on audit logging and confirms that the output includes the fields from the content standard. 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, and OpenBao audit devices produce a JSON log of API requests and responses with most sensitive values hashed. Where an application cannot log the required fields, the team records the gap for a fix or a compensating control. The output is a configuration record for each application, showing the setting, file path or device and the person who made the change.
Validate sample records against the content standard
The team generates test events by signing in with known individual accounts, performing a defined set of actions and failing a login on purpose. It then pulls the resulting records and checks each one for the required fields, confirming that the user ID maps to exactly one person and that time stamps and addresses are present. Any record missing a field goes back to the configuration step. The output is a validation report with sample records, the test steps used, the pass or fail result for each system and the fixes applied. This is the evidence that the configuration works in practice, not only on paper.
Document the definition for the assessor
The organization updates its system security plan and supporting procedures to describe the audit record content standard, the systems in scope, the identity provider arrangement, the validation results and the owner of each control. Assessors test against the assessment objectives in NIST SP 800-171A, which ask whether the audit record content needed to trace users is defined and whether created records contain it, so the documentation must answer both questions directly. The output is a final, dated document set in its finished form, because only final evidence counts toward a MET result. An independent assessor, not the implementation partner, decides whether the requirement is met.

How identity and audit tools make each action traceable to one person

An identity provider gives each person one identity, but the application still has to record it. In a typical design, an identity provider such as authentik, or a directory service such as FreeIPA, holds the user account and handles sign-in, and applications delegate authentication to it through protocols like OpenID Connect, SAML or LDAP. This matters for AU.L2-3.3.2 because it stops people from sharing accounts and gives every application the same identifier for the same person. Your team should confirm which identity source each in-scope system uses, whether any system still relies on local or shared accounts, and whether service accounts are named and owned by a specific person or team.

Single sign-on alone does not satisfy the requirement. Sign-in events from the identity provider show that a person authenticated, but they do not show what that person did inside a file store, a secrets manager or an administrative console. Each application or platform must write the authenticated user identity into its own audit records, along with the time stamp and, where relevant, source and destination addresses. For example, Nextcloud's admin_audit app writes additional event information to audit.log, and OpenBao's audit devices record each API request and response in JSON with most sensitive values hashed. Whether a given application captures the user ID for every event type is a configuration and testing question, not something the identity layer can settle, so confirm it per application against the events you have defined under AU.L2-3.3.1.

Assessors test this requirement by examining audit records, not configuration screenshots. Your evidence should show, for each in-scope system, a sample of audit records for real actions in which the user ID, the action, the time stamp and the source address can be read, and in which a shared or generic account would be visible as a problem. Test privileged actions in particular, since the CMMC Assessment Guide ties this requirement to logging of privileged functions under AC.L2-3.1.7. If a record shows only an application-level service account for an action a person took, the trace is broken and the requirement is not met. Plan for that gap before the assessment, because a NOT MET result on a 3-point requirement cannot be carried on a POA&M.

Which evidence shows that each action traces to a user

An assessor testing AU.L2-3.3.2 looks for proof at two levels: the rule that defines what each audit record must contain, and records that prove the rule works in practice. The cards below cover the artifacts that carry that proof and the routines that keep them current between assessments.

Written audit record content definition

This is the document that answers the first assessment objective: it defines the record content needed to trace each user uniquely to their actions. It should name the required fields, such as the user identifier, source and destination addresses, the event type, the outcome and the time stamp, and state which system produces each field. Check that the definition is approved, dated and version controlled, and that it matches the logging configuration actually deployed. A draft or an unapproved template will not carry a requirement to MET.

Sample audit records with user identity

Assessors test the second objective by pulling real records and checking that each one carries the defined content. Pull samples across several systems and event types, including logins, failed logins, privileged actions and data access, then confirm each record names a specific individual rather than a shared or generic identifier. Keep the sample set and the query used to produce it, so the same test can be repeated. Records with blank user fields or service accounts acting for people are common findings to resolve before assessment.

Account inventory showing unique individuals

An account inventory lists every account on each in-scope system, with its owner, type (named user, administrator, service or shared) and status. For AU.L2-3.3.2 the question is whether each interactive account maps to one person, so an inventory that shows a shared login cannot be reconciled with the audit trail. Reconcile the inventory against the identity directory and the HR joiner, mover and leaver list. Explain how each service account is controlled, since its activity must still be attributable to the team or process responsible for it.

Identity provider configuration exports

Exports from the identity provider show how users authenticate and how their identifiers flow into applications. For a self-hosted stack, this can include the provider's application and provider definitions and the directory source it draws from. Assessors use these exports to confirm that applications delegate sign-in to one directory and that the user identifier in an application record matches the identifier in the directory. Export on a schedule and store exports with a change record, because a configuration drift can break attribution without any visible error.

Scheduled sample pulls between assessments

Evidence goes stale quickly, so set a recurring routine that repeats the sample test and saves the results. Each pull should record the date, the system, the query, the reviewer and the count of records that failed the user-identity check. Store the output in a location with access controls, and track each failed record to a fix. Ask your assessor or consultant which sample size and frequency they expect, because the approach should be agreed before the assessment rather than discovered during it.

Change records for logging and identity settings

Any change to what is logged, how user identifiers are generated or which applications use the directory can break traceability. Route these changes through a change record that states the reason, the approver, the test performed and the rollback plan, and attach the before and after configuration. Compare each change with the written content definition and update that document when the required fields change. Assessors reading these records can confirm that the evidence in use reflects the current state of the system.

What meeting user accountability costs in money and effort

This table breaks down the cost components of meeting AU.L2-3.3.2 by who is paid, whether the cost is one-time or recurring, and what drives it up. Use it to build a written scope and to ask for line-item quotes, since no supplied figures give dollar amounts. The main takeaway is that per-application configuration and per-account log handling drive most of the effort, while open-source platforms mainly remove license spend.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it
Application audit configuration	Implementation partner or internal engineers enabling user-attributed event output per application	One-time, with rework after upgrades	Number of applications and how many event types each must record user IDs for
Identity integration	Engineers wiring applications to a central identity provider so each action maps to one account	One-time, with ongoing changes as users and applications change	Number of sign-in paths, shared or service accounts, and protocols in use
Log storage for user-attributed records	Infrastructure team, through cloud or data center storage	Recurring, growing with activity	Volume of events per user, retention period set under AU.L2-3.3.1, and whether records are duplicated
Privileged account attribution	Administrators and engineers reviewing how privileged actions are tied to named accounts	One-time setup, recurring review	Number of privileged accounts and whether shared administrator logins still exist
Evidence upkeep	Compliance lead or internal staff keeping sample records, configuration exports and access lists current	Recurring, tied to assessment cycles	Frequency of configuration changes and how well evidence is collected automatically
External review and assessor sampling	Independent assessor (C3PAO for Level 2 certification, where applicable) and any outside readiness reviewer	Recurring per assessment cycle	Number of systems in scope and how many sample records the assessor selects. Ask the assessor how they sample.
Software licenses	Commercial logging, identity or audit tooling vendors	Recurring license fees where commercial products are chosen	Self-hosted open-source platforms such as Nextcloud, OpenBao, authentik and FreeIPA avoid per-seat license fees for those components, though support and hosting costs remain
Quote checklist	Requesting party to the implementation partner	Applies at quote time	Ask for each application listed separately, the audit fields captured, the storage sizing assumption, and who performs evidence collection

Who owns user accountability: your team, a partner and the assessor

Your organization owns AU.L2-3.3.2. That means deciding which audit record content identifies each user uniquely, writing the account policy that makes every login traceable to one person, and signing off on the final definitions that the assessment will test. Those decisions belong to accountable staff, and they cannot be delegated to a vendor or consultant without losing the ownership an assessor looks for.

Audit record content: Define the fields each record must carry, such as the user ID, source and destination addresses and time stamp, and document why those fields make actions attributable to one person.
Account policy: Prohibit shared and generic accounts for interactive use, and define how service accounts are named, owned and tied to a responsible person.
Final definitions: Approve the written definitions for the two assessment objectives in NIST SP 800-171A, so the scope and wording are yours.
Operating records: Keep the approvals, exception records and review history that show the definitions were applied and maintained over time.
Scoping decisions: Decide which systems that handle CUI are in scope for accountability logging.

Before any assessment, confirm that a named owner can explain the definitions without the partner in the room.

Common gaps that fail user accountability and how to close them

Why do shared administrator accounts fail user accountability?

Shared administrator accounts fail because an audit record that shows the account name cannot tell an assessor which person performed an action. AU.L2-3.3.2 expects each action to trace uniquely to one user, so a shared login breaks the chain at the first step. To close the gap, give every administrator a named account, disable or restrict the generic root or admin logins, and require individuals to escalate privileges under their own identity. Use sudo with logging on Linux hosts, or the equivalent elevation mechanism on other platforms, so that privileged commands record the invoking user. Confirm with your assessor how they expect break-glass accounts to be handled, and document any exception with its compensating controls.

What happens when application logs record a service account instead of the person?

If an application writes every action under a single service account, the log shows that the software acted but not which person asked it to. Assessors look for the individual's identifier on the record, so a service account name alone does not satisfy the requirement. Close the gap by passing the authenticated user's identity through to the application audit trail. For example, an identity provider such as authentik can delegate sign-in to applications over OpenID Connect or SAML, and the application can then record the user's identifier with each event. Where an application cannot do this, record the requesting user in a separate upstream log, such as a reverse proxy, and make sure the two logs can be joined by time stamp and session.

How do missing source addresses weaken user accountability records?

A record that names a user but omits the source address leaves an investigator unable to tell where the session came from, which weakens the link between a person and an action. The CMMC Assessment Guide for Level 2 suggests capturing user IDs, source and destination addresses and time stamps together. Review each audit source and confirm it writes the client IP address, or the address seen by the last trusted proxy, on every authentication and privileged event. Behind a load balancer or reverse proxy, configure the proxy to forward the original client address and confirm the application reads it correctly. Test by performing a known login from a known address and checking that the address appears in the record.

Why do inconsistent user identifiers across systems break traceability?

When one person appears as a different username in the directory, the application, the database and the cloud console, an investigator cannot easily prove that these records describe the same individual. Traceability depends on a stable identifier that every system records. Pick one authoritative identity source, such as FreeIPA for Linux and UNIX environments, and make other systems authenticate against it. Map local account names to that identifier in your identity management process, and document the mapping. Review orphaned accounts and accounts that use a different naming pattern during each access review so the identifiers stay aligned.

What audit record content should be defined before assessment?

Undefined record content is the gap most often found when an organization cannot show what its logs must contain. NIST SP 800-171A breaks this requirement into two assessment objectives: defining the audit record content needed to trace users uniquely to their actions, and confirming that the created records actually contain that content. Write a short standard that lists, for each system in scope, the mandatory fields: user identifier, source address, destination address where relevant, event type, outcome and time stamp. Then sample real records from each system and check them against the list. Keep the standard under configuration control so that changes are reviewed. The organization owns this definition, and an implementation partner can help draft and test it.

Can an internal team close these gaps without outside help?

Many organizations can close these gaps internally if they have engineers who understand their systems and time to test them. The work usually breaks into three parts: changing account practices, reconfiguring applications and logging, and writing and testing the record standard. Account practices are often the simplest to fix and the most important to document. Application changes depend on what each product supports, so confirm the logging options in each vendor's documentation before estimating effort. An implementation partner such as DeployOpen can plan, configure and document these changes in your own environment under a written scope, but the organization still owns the controls and the assessor makes the determination.

Where an implementation partner adds value on this requirement

An implementation partner can prepare the systems and evidence that let the organization meet AU.L2-3.3.2, but the organization still owns the control and an independent assessor still decides whether it is MET. In practice, DeployOpen's work on this requirement covers configuring the self-hosted platforms that produce user-attributable records: enabling the admin_audit app in Nextcloud and setting logfile_audit so records land where the organization expects, turning on OpenBao audit devices so every API request is logged with the caller's identity, and making sure authentik and FreeIPA send a single, consistent user identifier to each application so one person cannot appear under several names. Partner work also includes building the evidence pack, such as the defined audit record content, sample records showing user ID, source address and time stamp for representative actions, and a short record of who owns each log source.

Sample validation is where partner effort is most useful and most often underestimated. A consultant can pull records for privileged and ordinary actions, confirm that each one traces to a single named person, and flag shared accounts, generic service identities or gaps where a source address is missing. Because the assessment objectives in NIST SP 800-171A ask whether the created records contain the required content, the partner should test the records themselves rather than only describe the settings. Before work starts, ask the partner to state in writing which platforms, log sources and sample sizes are in scope, who approves the final evidence, and whether any remediation is included or billed separately.

DeployOpen does not perform the CMMC assessment, issue a report or grant a status. Level 2 certification assessments are performed by C3PAOs authorized or accredited by The Cyber AB, and self-assessments are carried out and affirmed by the organization itself. The organization should confirm with its assessor or sponsoring contract office which evidence form is accepted and whether a self-assessment or certification assessment applies to its contracts, since the current schedule for Phase II has been suspended. Keeping preparation and assessment separate protects the assessor's independence and gives the organization a clear record of which party did what.

How DeployOpen prepares user accountability evidence

DeployOpen plans, implements and documents the self-hosted open-source platforms that produce user-attributable audit records for AU.L2-3.3.2. The organization owns its controls and its assessment decision, while DeployOpen prepares the systems, configuration and evidence that an independent assessor reviews.

How we scope

The written scope lists which systems must record user IDs, source addresses, destination addresses and time stamps.
Scope names the platforms, identity sources and privileged functions that feed user-attributable audit records.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.

How we build

We configure audit content on each in-scope platform so every record ties an action to one individual account.
We integrate applications with a single identity provider so users sign in under their own identities, not shared accounts.
We test generated records against the 3.3.2 assessment objectives to confirm the required content appears in practice.

How we hand over

We document the audit record content, logging settings and identity mappings the organization needs to show an assessor.
We deliver evidence packages with sample records, configuration exports and test results, labeled by assessment objective.
We walk the organization's staff through the evidence so they can explain and reproduce it during an assessment.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Retainers can cover re-checking user attribution after platform upgrades, new applications or identity changes.
Assessment decisions, reports and any certification remain with the organization and its independent assessor.

AU.L2-3.3.2 User accountability