User Accountability

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

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.3.2.Source

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

1. [a]

   the content of the audit records needed to support the ability to uniquely trace users to their actions is defined; and

   1 example covers this

2. [b]

   audit records, once created, contain the defined content.

   1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

• addresses[a][b]

  AU.L2-3.3.2 · User Accountability

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

  • [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.

  Retiring the shared itadmin account so every action names a human

  CCControlVerdict Corpus@cv-corpusOSCJul 31, 2026

  Community is just starting — add yours. No verdicts yet.

  Implementation

  AO coverage. Addresses both User Accountability objectives: the record content needed to trace actions to a user is defined, and created records actually contain it.

  Defined record content [a]. For every in-scope source, an audit record must carry: UTC timestamp, actor identifier (UPN plus immutable object ID, because display names change), source address and device object ID where the platform provides one, action performed, target object, outcome, and a session or correlation ID. The immutable object ID is what lets a record from two years ago still resolve to a person after a name change.

  Removing the ambiguity. The shared administrative account was replaced by individually named accounts, including one per provider engineer as a guest identity in our tenant with its own privileged role eligibility. The shared account is disabled and alerted on, not deleted, so any attempt to use it is visible. Contract language obliges the provider to keep engineer-to-account mapping current.

  Verifying content [b]. A monthly query samples records from each source and asserts the required fields are populated. Sources that cannot populate the actor field are treated as findings, not accepted quietly. Automation runs under registered service identities whose owner is recorded, so a workload action resolves to an accountable person even though no human was at a keyboard.

  Maintenance. Monthly field-completeness sample. Quarterly reconciliation of provider guest accounts against the provider's current staff roster; departures are removed the same week. Any new log source must demonstrate actor attribution before it is accepted as evidence.

  Accepted gap. A network appliance writes admin in its local log regardless of who authenticated. Administration of it is only possible through the jump host, whose session records identify the operator, so attribution comes from correlating the two. The dependency is written down rather than glossed over.

  What the evidence looks like

  • Audit record content standard listing required fields per source
  • Monthly field-completeness query output
  • Provider guest account list mapped to named engineers, with the contract clause
  • Alert rule and history for use of the disabled shared account
  • Correlated jump-host session and appliance log pair for one recent change

  Environment

  OSC whose tenant is co-administered by an outsourced IT provider. Until last year both sides signed in as a shared `itadmin` account, which made attribution impossible.

  Tools

  • Cloud IdP
  • SIEM

  Edit history

  · No edits yet