1Overview
AC.L2-3.1.7 does two things at once, which is unusual for a single requirement. It prevents non-privileged users from executing privileged functions, and it requires that when privileged functions are executed, the fact is captured in the audit logs. The first half is a barrier; the second is a witness. Together they ensure that privileged actions are performed only by those authorized and that every such action leaves a record.
The control completes the arc that runs through this part of the family. Least privilege limits who holds elevated rights, the non-privileged-account requirement keeps privilege out of daily work, and 3.1.7 both blocks the unauthorized use of privileged functions and makes sure the authorized use is recorded. That recording matters because privileged functions are precisely the actions most capable of harm and most worth concealing, so an unwitnessed privileged action is the one an assessor and an investigator most want to see and most often cannot.
Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs.
A privileged function is an action that manages the system or its protections: creating accounts, changing configurations, altering audit settings, modifying security controls. The requirement is that a user without privilege cannot perform these actions, and that when a user with privilege does perform them, the action is logged. The second clause makes this one of several access controls that reach directly into the audit family, because the barrier and the record are both required and are assessed together.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.1.7 into four objectives: define privileged functions, define non-privileged users, prevent the latter from executing the former, and capture the execution of privileged functions in the audit logs.
Privileged functions are defined. The organization has identified the actions that count as privileged, the ones that manage the system or its security.
Non-privileged users are defined. The organization has identified which users lack privilege, so the prevention has a clear subject.
Non-privileged users are prevented from executing privileged functions. The barrier is enforced by the system, so a standard user cannot perform a privileged action.
The execution of privileged functions is captured in audit logs. When a privileged function is performed, the event is recorded, so the action can be attributed and reviewed.
The first two objectives are definitions, and the second two are the barrier and the witness. Objective [c] depends entirely on the least-privilege work of the preceding controls, because a barrier cannot exist where every user is already an administrator, and objective [d] depends on the audit configuration, which is why this control is where the access and audit families meet.
3Failure Patterns
The failures fall on either side of the control: the barrier that does not exist because privilege is universal, and the record that does not exist because logging was never configured for privileged actions.
Universal administrator rights defeat the barrier
Where standard users hold local or domain administrator rights, objective [c] fails outright, because there is no privileged function a user is prevented from executing. This is the same flat-privilege model that undermines several controls, and it defeats the barrier half of 3.1.7 completely, since prevention requires that some users genuinely lack the power the control is meant to withhold.
Privileged actions that leave no trace
A shop may enforce the barrier correctly and still fail objective [d] because the audit configuration was never set to record privileged actions. Account creation, group changes, and security-setting modifications pass without a log entry, so even authorized privileged use cannot be attributed after the fact. The barrier without the witness is only half the control.
Logs exist but are not retained
Privileged actions may be logged locally and then overwritten within days as the log fills, so that by the time anyone looks, the record is gone. Objective [d] requires that the capture be durable enough to serve review, which connects to the retention requirements of the audit family and is a common gap where logging is enabled but never forwarded or retained.
Privileged functions never defined
Objectives [a] and [b] are definitional, and shops that never drew the line between privileged and non-privileged functions have no basis for either prevention or targeted logging. Without the definition, the barrier is accidental and the logging is generic, and the assessor has nothing specific to verify against.
4Ownership
This control sits across the access and audit functions, so its ownership spans the people who arrange privilege and the people who configure and review logging. Neither half is sufficient alone.
| Role | Responsibility for this control |
|---|---|
| IT lead or system administrator | Enforces the barrier by ensuring standard users cannot execute privileged functions, and configures the system to log privileged actions. Owns the technical evidence for both halves. |
| Security or compliance lead | Defines which functions are privileged and which users are non-privileged, giving objectives [a] and [b] their content, and confirms the logging captures the defined privileged functions. |
| Log reviewer | Reviews the captured privileged-function events, ideally a person separated from the administrators whose actions the log records, connecting this control to separation of duties. |
| Program lead | Ensures privileged-action logs are retained long enough to serve review and are included in the periodic audit review, and keeps the records. |
5Tooling
The control is built with the access model on one side and audit configuration on the other, both native to a Windows environment. The work is enforcing the boundary and turning on the right logging.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a], [b] | Access model documentation, privileged-function and user definitions | The written definitions that give the barrier and the logging a specific target, maintained alongside the access design. |
| [c] | Standard user accounts, restricted administrative groups, User Account Control | Removing administrative rights from standard users enforces the barrier, so privileged functions are unavailable to those without the role. This is the same least-privilege configuration built for earlier controls. |
| [d] | Windows advanced audit policy, Security event log, log forwarding to a SIEM | Audit policy for account management, privilege use, and policy change records privileged actions (events such as 4720, 4728, 4732, 4670, 4719), and forwarding to a central store keeps them beyond the reach of local overwrite. |
| Retention | Central log storage, defined retention period | Retaining the privileged-action record for the required period makes objective [d] durable, connecting to the audit family's retention requirements. |
The caveat spans both halves. The barrier fails if the least-privilege work was skipped, and the witness fails if audit policy defaults were never changed, since a fresh Windows install does not record all of these events by default. The assessor tests objective [c] by having a standard user attempt a privileged action, and objective [d] by asking to see the log entry for a privileged action that was performed, so both the enforcement and the record must be real and retrievable.
6Evidence
The satisfied version of 3.1.7 shows the privilege boundary enforced and the privileged actions recorded and kept.
| Evidence | What it demonstrates |
|---|---|
| Privileged-function and user definitions | Objectives [a], [b]. The documented set of privileged functions and the distinction of non-privileged users. |
| Access configuration showing the barrier | Objective [c]. Standard users lacking administrative rights, demonstrated by group membership and a denied privileged action. |
| Audit policy configuration | Objective [d]. The settings that cause privileged functions to be logged, covering account management, privilege use, and policy change. |
| Sample privileged-action log entries | Objective [d]. Actual records of privileged functions performed, with the user, the action, and the time. |
| Log retention configuration | Objective [d]. Central storage and retention showing the records persist long enough to serve review. |
The evidence must show both halves working together, because a barrier without a record or a record without a barrier each fails the control. The assessor will ask to trace a specific privileged action from occurrence to log entry, so the capture must be real and retrievable rather than merely enabled. This control also feeds the audit family directly, since the privileged-function events it requires are among the most important entries the audit review examines.
The barrier and the record are built together
Getting 3.1.7 right means both enforcing a real privilege boundary and configuring the logging that witnesses privileged use, then keeping those records long enough to matter. Setting up the audit policy so the right events are captured and retained, alongside the least-privilege boundary that makes the barrier real, is part of the onsite readiness work this practice does.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.1.7. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.1.7[a] through 3.1.7[d]. csrc.nist.gov
- 32 CFR 170.21, Plan of Action and Milestones Requirements, governing which requirements may remain open at a Level 2 assessment. ecfr.gov