User Accountability

Official Source Material

Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.

Determine if:

[a] the content of the audit records needed to support the ability to uniquely trace users to their actions is defined; and
[b] audit records, once created, contain the defined content.

Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024

Practitioner Guidance

How to meet it

Meet this requirement by pointing at work you already did for AU.L2-3.3.1.

Objective [a] asks you to define the record content that ties an action to a person, and [b] asks for records that contain it. When your AU.L2-3.3.1 record content already includes a user identifier, a time stamp, a source address, the action, and the outcome, name those fields as your traceability content. Show sample records. There is no separate logging system to build.

Shared accounts are how this requirement fails.

A record that names admin or scanner traces to no individual. Give every person a named account, and keep privileged accounts personal. Where a service account cannot be eliminated, restrict who can use it and log the use so a person can still be identified.

Evidence is a configuration plus a sample.

Show how the audit system is configured to capture user identity, then pull a sample record and point to the identity field. A policy that lists the required fields without records demonstrating them leaves [b] unproven.

In a cloud tenant the identity is already in every record.

The Microsoft 365 unified audit log and the Microsoft Entra ID sign-in log stamp each entry with the acting account. Your work is the mapping from account to person: one account per person, no sharing, and a record of who holds each privileged account.

What falls short

A shared administrator password used by everyone in IT. Actions taken with it cannot be traced to an individual, so the records cannot supply the traceability [a] defines.
A policy that lists required record fields with no sample records behind it. Objective [b] is about the records, not the policy.

Edge cases

Break glass accounts, the emergency credentials kept for when normal access fails, survive this requirement when you document them, seal the credentials, and alert on every use. The alert plus the access record identifies who used the account and when.