Privileged Functions

Define privileged functions as categories, not a command inventory.

Objective [a] is satisfied by categories: establishing accounts, configuring access authorizations, setting events to be audited, patching, administering security tooling, and managing cryptographic keys. Enumerating every individual command produces an unmaintainable list and no additional compliance.

Objective [b] is one sentence, and [c] is your standard user build.

Define non-privileged users as everyone not on the privileged account list from AC.L2-3.1.5. Prevention under [c] is what a correctly configured standard account already does: no administrator rights, elevation prompts the user cannot satisfy, installs blocked. The evidence is the central configuration that builds those accounts, a group policy or a mobile device management profile, plus a demonstration that a standard user cannot execute an administrative action.

Objective [d] asks for capture, not review.

Configure logging so privileged operations land in the audit log, and be ready to say which events you capture and why. There is no mandated list of event IDs. A reasoned selection with a recorded rationale is sufficient. Keep the specific event IDs in your configuration baselines, not in policy, so the policy states the expectation and the baseline carries the detail. Reviewing what you captured belongs to the Audit and Accountability requirements, not here.

Log privileged use even where prevention is airtight.

Objective [d] covers the privileged users themselves, not just blocked attempts by everyone else. The guide's own example is an accidental privilege grant that surfaced only because privileged activity was being logged and an unexpected actor appeared in it.