Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
Brilliant at the BasicsDIB Resource Center
3.3.2OFFICIAL STATEMENT BELOWBASIC REQUIREMENTPENDING NIST SME REVIEW

3.3.2 — Individual accountability

3.3 Audit and Accountability · NIST SP 800-171 Rev. 2 · The heading label is this site's navigational shorthand; the official language is the statement below.

Official requirement statement (verbatim)

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

NIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A — Assessing Security Requirements for CUI ↗
Independent interpretation

What this requirement is after

Every logged action must trace to one specific person. Shared logins and generic admin accounts are where this requirement dies: if three people know the password, the log line proves nothing about any of them.

Across revisions

Rev. 3 carries individual accountability through Audit Record Content (03.03.02), which makes the identity of the individual an explicit required element of the records themselves.

Mapped practices

Brilliant at the Basics practices that support this requirement

DependencyModerate confidence

Why: Tracing actions to individuals presumes the account list is clean, and the practice's monthly reconciliation is what finds the orphaned accounts and unowned logins that break attribution — an account with no matching employee can never be traced to anyone.

What this does not claim: The inventory attributes nothing at logging time: unique accounts, shared-account elimination, and identity captured in the records are separate work implemented in the systems doing the logging. Absent those, a perfectly reconciled account list still leaves this requirement unimplemented.

Practice-side activities
  • Reconcile active accounts against current employees and approved service purposes monthly
  • Flag and resolve shared and ownerless accounts surfaced by the reconciliation
Evidence this produces
  • Monthly orphaned-account reconciliation results
  • The account-to-owner register the attribution chain rests on

Review status: Pending NIST SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Give every person a unique account in every system that touches CUI, including the appliances and line-of-business tools that ship with a single built-in admin login.
  • Where a shared account genuinely cannot be eliminated — a shop-floor kiosk, a legacy machine tool — document it, name an owner, and add a compensating record of who used it when.
  • Check that identity actually lands in the records: a system can require unique logins and still write logs that omit the username.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • An account listing demonstrating one-person-one-account across in-scope systems
  • Log samples showing individual identity captured in the records
  • A register of surviving shared accounts with owners and compensating attribution

Suggested owners, derived from the mapped practices and artifacts: IT leader. Ownership is a named person in your organization, not a role on a website.

Artifacts

Templates and worksheets with a mapped relationship

No artifact in the library names this requirement yet. The library index groups everything by category and practice.

The other revision

Where this lands in Rev. 3

Provenance

Sources and review status

Primary sourcesNIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A — Assessing Security Requirements for CUI
Review statusPending NIST SME review
Content version1.0
Updated