03.01.07 Least privilege: privileged functions, evidence and audit

What 03.01.07 least privilege for privileged functions requires

If a contract or CUI obligation now asks you for NIST SP 800-171 evidence, 03.01.07 is one of the requirements you will be asked to prove. In plain terms, it asks for two things: prevent non-privileged users from executing privileged functions, and log the execution of privileged functions. Both halves matter. Restricting administrator actions without recording them leaves you unable to show who did what, and recording them without restricting access leaves the actions open to anyone who can reach them.

Administrator actions carry the highest impact in any system holding CUI. A single privileged function, such as changing audit settings, disabling an encryption control, creating an account with elevated rights or altering firewall rules, can affect every user and every record. The requirement is hard in practice for two reasons. First, privileges accumulate: roles are granted for a project, a migration or an emergency and are never removed, so non-privileged accounts quietly gain functions they should not hold. Second, the logging half is often missing on business applications, where administrative screens write no audit record for the functions that matter most. Your assessor will look for both gaps.

03.01.07 is a Rev. 3 requirement that carries forward Rev. 2 requirement 3.1.7. NIST classifies that change as editorial only, so an organization already assessed against Rev. 2 has a head start, but the assessment procedures in SP 800-171A Rev. 3 are the ones to plan against. It is one of several least privilege requirements. 03.01.05 covers granting users only the access their tasks need and reviewing those roles, and 03.01.06 covers restricting privileged accounts to defined personnel and separating administrator accounts from everyday ones. 03.01.07 is the control that tests whether those restrictions hold for actual privileged functions and whether the activity leaves a trail.

Which systems and privileged functions fall in scope for 03.01.07

Requirement 03.01.07 applies to every system that holds or processes CUI and to every function that changes how those systems are secured or monitored. The cards below cover the decisions an assessor will trace back to your system security plan, so confirm each one with the people who own the system.

CUI systems and their boundary

Start with the systems that store, process or transmit CUI, then add the components that protect them: identity providers, directories, logging servers and jump hosts. Requirement 03.01.07 governs administrators of these components, not only of the CUI application itself. Record the boundary in the system security plan, and confirm that each supporting component is either inside it or formally connected to it.

Privileged functions defined in writing

The organization defines which functions count as privileged, and the assessor will test against that list. Typical entries include changing audit configuration, creating or altering user accounts and roles, changing security settings, and disabling or clearing logs. Write each function down with the system and role that performs it, and confirm the list against your system security plan.

Teams and third parties who administer

List every group that can run privileged functions, including internal platform, network and security teams, managed service providers and vendor support staff with remote sessions. Each group needs a documented role, a non-privileged account for everyday work, and logged execution of privileged actions. Ask managed service providers how their administrator sessions are recorded and where those records are kept.

Cloud consoles and hypervisors

Cloud provider consoles, hypervisor management interfaces and infrastructure APIs often grant control over every workload beneath them. Decide whether these administrative planes fall inside the boundary, and if they are provided by a third party, confirm what the provider logs and what you can export. Gaps here are common because the platform team may treat these interfaces as outside the application scope.

SaaS admin panels and connected tools

SaaS administrator panels can change access, export data and alter security settings for systems that handle CUI. If a service connected to the CUI environment has its own administrator role, treat that role as privileged, document who holds it, and determine whether its actions reach your audit records. Confirm these tools in the system security plan instead of assuming a vendor's default logging meets the requirement.

Audit and logging administrators

People who can change logging settings or delete audit records hold some of the most sensitive privileges in the environment. Identify them separately, confirm that their actions create records outside their own control, and check whether the logging platform itself is in scope. Ask the assessor how they expect you to show that administrators cannot silence their own activity.

How an assessor tests 03.01.07 and what they ask for

This table maps the two SP 800-171A Rev. 3 determination statements for 03.01.07 to the examine, interview and test methods, and lists the objects an assessor will request. Read each row as a question the assessor will ask, then check that your system can answer it with records rather than descriptions.

Assessment element	What the assessor checks	Evidence to prepare	Where it usually fails
Determination statement 1: privileged functions	Non-privileged users are prevented from executing privileged functions, and the mechanism that enforces this is identified in design and configuration.	Access control policy, least privilege procedures, a list of privileged functions, role-to-function mappings and configuration settings showing the restriction.	Administrative tools, scripts or API endpoints remain callable from standard accounts because the restriction was applied only to the user interface.
Determination statement 2: logging privileged execution	Each execution of a privileged function is logged, so the assessor can trace who ran it, when and on which system.	System audit records for privileged actions, audit configuration showing which events are captured, and a sample of entries tied to named accounts.	Logs record that a service started but not which privileged function ran, or privileged activity is logged on some hosts and not others.
Examine: policy and procedures	The access control policy and least privilege procedures define which functions are privileged and how non-privileged access is blocked and logged.	Approved policy and procedure documents with version history, owners and review dates.	Procedures describe intent but do not name the functions, roles or systems they cover.
Examine: design and configuration	System design documentation and configuration settings show how privileged functions are separated and which audit settings are active.	Architecture diagrams, role definitions, permission exports and audit configuration files or screenshots dated to the assessment.	Configuration drifts from the documented design, and no one can show the settings in effect today.
Examine: system audit records	Audit records for privileged function execution exist, are complete and are readable enough to support review.	Sample audit records covering administrative actions, with the audit log retention setting and an example of a review.	Records exist but are never reviewed, or the sample the organization holds does not cover the period the assessor selects.
Interview: personnel reviewing least privileges	Reviewers explain how they confirm that privileges match tasks and how privileged execution is checked.	Review schedule, sign-off records and the reviewer's own description of the steps they follow.	Reviewers cannot describe the process consistently, or the review checks account membership but not function-level execution.
Interview: security staff and system developers	Security staff and developers explain how privileged functions are restricted in code, deployment and operations, and how their activity is logged.	Design notes for role checks, deployment runbooks and a description of how developer and break-glass access is handled.	Developers grant privileged functions to service accounts for convenience, and security staff are unaware of it.
Test: mechanisms that audit privileged execution	The assessor runs or observes a privileged function and confirms that an audit record is generated with the account, function and outcome.	A test script or documented test run showing a privileged action and the matching log entry.	A privileged action produces no entry, or the entry omits the account that performed it.
Test: mechanisms that block non-privileged users	The assessor attempts a privileged function from a non-privileged account and confirms it is denied.	Test accounts with defined roles, recorded denial results and the configuration that caused each denial.	Denial works in the console but a direct API call or command line path succeeds for the standard account.

Implementing 03.01.07 in sequence

This sequence turns the privileged function requirement into a working control: each privileged function is inventoried, restricted to privileged roles, configured so non-privileged users are refused, logged on every execution, and tested so the organization can show an assessor both the restriction and the record of it.

Inventory privileged functions for each system
The system owner, with the security team and the people who administer the system, lists every function that changes security settings, manages accounts, alters audit configuration, or otherwise acts beyond what a standard user does. Include functions in operating systems, applications, databases, cloud consoles and security tools. Record the function, the system it runs on, and the role that should hold it. The output is a privileged function inventory per system, approved by the system owner and kept with the system security plan, because the assessor will compare it against what the configuration actually allows.
Separate privileged roles from standard accounts
Map each inventoried function to a defined privileged role, then assign that role only to named personnel. Administrators should hold a separate account for privileged work and use their everyday account for ordinary tasks. This step connects to 03.01.05 and 03.01.06, which govern role privileges and privileged accounts. The output is a role-to-function matrix and a list of who holds each privileged role, which you can file as evidence of the restriction.
Enforce restrictions in system configuration
Configure each system so that only the privileged roles can run the inventoried functions. Use the native role, group or policy settings of the operating system, application or identity provider, and remove privileged rights from general user groups. Where a platform offers a default that grants broad rights, document the change and the reason for it. The output is exported configuration evidence, such as role definitions, group memberships and policy files, that shows the restriction exists in the running system, not only on paper.
Enable audit logging for each privileged execution
Turn on logging for the privileged functions themselves, not just for logons. The log entry should identify who executed the function, what was executed, the target, the result and the time. Confirm the logging setting is active on every system in scope, including the audit configuration itself. The output is a logging configuration record per system and a sample of log entries showing privileged executions. Where a platform logs administrative actions only when a specific module or setting is enabled, confirm that behavior with the vendor and your own testing before you rely on it.
Route privileged logs to a reviewed store
Send the privileged execution logs to a central store that privileged users cannot edit, and assign a named reviewer and review method. Forward alerts on privileged activity to the people who respond to them. Monitoring platforms such as Wazuh or OpenSearch Security Analytics can match ingested logs against rules and record matches as alerts or findings, but you must write or select rules for privileged activity and confirm the platform behavior in your environment. The output is a log forwarding configuration, a review procedure with a named reviewer, and a sample alert or finding that shows the review path works.
Test refusal and recording with a non-privileged account
Sign in with a standard, non-privileged account and attempt each inventoried privileged function. Confirm the attempt is refused, then confirm the refused attempt appears in the logs with the account, function and outcome. Repeat the test with a privileged account to confirm it succeeds and is logged. Record the test date, the tester, the accounts used and the results. The output is a signed test record, which is the evidence that matches the assessor's test method for 03.01.07, and any failed test becomes a finding to fix and retest before the control is claimed as implemented.

Where open-source platforms produce the logging evidence

Nextcloud's admin_audit app records additional event information for administrative activity and writes it to audit.log in the data directory, or to a path you set with logfile_audit. This is the most direct source for showing that a privileged function, such as changing system-wide settings, managing other users' rights or altering sharing policy, was executed and by whom. The log proves that administrator actions happen in an application that is itself traceable, but it only covers what the app is configured to capture.

Log location: Confirm where audit.log is written and that the path is on storage with restricted access and retention.
Logfile override: If logfile_audit is set, verify the configured path and that the web server user can write to it.
Event coverage: Check the admin_audit event list against the privileged functions defined in your system security plan.
Tamper resistance: Confirm who can read or edit the file and whether copies leave the host.
Time and identity: Confirm each entry carries the acting account and a consistent time source.

Confirm the admin_audit app is enabled in your deployed version and that a test administrative action appears in the log before you cite it as evidence.

Evidence that passes 03.01.07 and how to keep it current

An assessor testing 03.01.07 looks for proof that privileged functions are restricted and that their execution is recorded. The artifacts below connect policy, configuration, logs and test results, and each one goes stale unless it is refreshed on a schedule. Confirm the exact review cadence against your own system security plan.

Privileged function inventory

A written list of every function on the system that only privileged users should run, such as changing security settings, creating accounts, altering audit configuration and installing software. The list is the baseline that every other artifact is measured against, so an assessor will ask how it was derived from the system design documentation. Keep it under version control, and re-baseline it whenever a component, plugin or administrative console is added or upgraded. Note who approved each change and when.

Role and permission configuration exports

Dated exports of role definitions, group memberships and the permissions bound to each role, taken from the identity provider and from each application's own admin settings. Each export shows whether a non-privileged role can reach a privileged function, which is the core test of the requirement. Schedule the export, store it with a timestamp, and diff it against the previous one so that unexpected grants are visible. Include applications that keep their own roles, not only the central directory.

Audit log samples of privileged executions

Extracts from system audit records showing that each privileged function was executed and attributed to a named administrator, with time, source and outcome. Nextcloud's admin_audit app writes these events to audit.log in the data directory, or to a path set with logfile_audit, and OpenBao's audit devices record every API request and response. Confirm that the sampled entries include the fields your assessor needs, and that log integrity controls cover the files you export.

Denial records for non-privileged attempts

Evidence that the system refused privileged functions when a non-privileged account tried to run them. Pull denied-request entries from application logs, authorization service decisions and failed-permission events, and keep a dated set from scheduled negative tests. Without denials, an assessor cannot see enforcement in operation. Test with a standard user account at each privileged function on the inventory, and record the result against the function name.

Log review and alert records

Dated records showing that someone reviewed privileged-function activity at a defined frequency and acted on anything unusual. Detection tools such as Wazuh write matching alerts to alerts.log and alerts.json, and OpenSearch Security Analytics records Sigma rule matches as findings. Keep the review sign-off, the reviewer's name, the scope reviewed and any tickets raised. A review with no record of who did it and when will not satisfy the requirement.

Test results and change-driven retests

Records from the test method SP 800-171A Rev. 3 uses for 03.01.07, which checks the mechanisms that restrict and audit privileged functions for non-privileged users. Store each test run with its date, tester, environment and results, and rerun the suite after role changes, upgrades or new administrative tools. Keep failed tests and their remediation alongside passes, since a clean history with no failures often prompts follow-up questions. Confirm the test cadence with your assessor before the assessment.

What meeting 03.01.07 costs in money and effort

This table lists the cost components of meeting 03.01.07, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No prices or durations are supplied for this requirement, so use the drivers to scope quotes and compare them against a written scope.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it up or down
Defining privileged functions	Internal security and platform staff, with an implementation partner if engaged	One-time, revisited on role or system change	Number of administrative functions per system and how well roles are already documented
Configuring enforcement for non-privileged users	Platform engineers, application owners, identity administrators	One-time, plus effort on each new system or upgrade	Number of systems, whether roles are centralized in one identity source, and how many apps have their own admin models
Audit logging configuration	Platform engineers; open-source audit features such as Nextcloud admin_audit or OpenBao audit devices carry no license fee	One-time setup, recurring tuning	Number of platforms that must log privileged execution and whether logs go to one destination
Log storage and retention	Infrastructure owners; storage is paid to the cloud or data center provider	Recurring	Log volume, retention period set by the organization, and whether logs are protected from alteration
Log review and alert handling	Security operations staff; an indexer or SIEM such as OpenSearch Security Analytics or Wazuh reduces manual searching but still needs people	Recurring	Alert volume, quality of detection rules, and whether reviews are scheduled and recorded
Independent testing or review	External testers or assessors, paid under a written scope	Periodic, often tied to each assessment cycle	Number of systems tested, whether privilege escalation is in scope, and how much evidence is prepared beforehand
Assessor time	The independent assessor or certification body, not the organization or DeployOpen	Per assessment cycle	Quality of evidence, clarity of the system security plan, and how many interviews and system walkthroughs are needed
Ongoing support and retainers	Implementation partner or internal team, if a retainer is agreed	Recurring, if chosen	Upgrade frequency, number of platforms, and how often role models change

Which parts of 03.01.07 cost the most and why

The logging half of 03.01.07 is usually the larger effort. Preventing non-privileged users from running privileged functions is mostly a matter of configuring access control, sudo or equivalent policy, and application roles that already exist in most environments. Logging every execution of a privileged function is different, because it depends on each system's audit capability. Every operating system, database, application, hypervisor and cloud control plane that an administrator can touch must record privileged executions, keep those records with enough detail to be useful, and retain them for the period your contract and system security plan set. Where a platform cannot produce the record, the fix may be a configuration change, a vendor feature, a forwarding agent or a compensating control, and each option carries its own engineering and testing work. Ask your implementation partner to inventory audit capability system by system before estimating the effort, and to state which retention period they have assumed.

The NIST Rev. 2 to Rev. 3 change analysis classifies the change to 03.01.07 as editorial only, traced to Rev. 2 requirement 3.1.7. Existing CMMC Level 2 work on AC.L2-3.1.7 therefore carries over, and the evidence you already gathered for that practice is a sound starting point rather than a cost to repeat. The revision question matters more for budget than the requirement text does. A FAR overhaul proposed rule published 23 June 2026 would require contractors handling CUI to comply with SP 800-171 Rev. 3 using organization-defined parameter values published by the DoW CIO, but the rule was not final as of October 2026. Meanwhile, DoW Class Deviation 2026-O0025, Revision 3, has contracting officers use a DFARS 252.204-7012 that names Rev. 2 explicitly. Confirm with your contracting officer which revision each contract and subcontract names, and whether any ODP values have been published for it, before you commit funds.

Who does what: your team, a partner and the auditor

Your organization owns the control. Under the system security plan, leadership must decide which functions count as privileged, who may perform them, and how often those grants are reviewed. Those decisions cannot be delegated to a vendor, because the assessor will ask the organization, not the partner, to explain why a given administrator holds a given privilege.

Privileged function list: Maintain a written inventory of privileged functions across operating systems, applications, identity providers, databases and cloud consoles, tied to the roles allowed to use them.
Authorization decisions: Record who approved each privileged role, the business reason, and the date of the last review.
Policy and procedures: Own the access control policy and the procedure for granting, changing and removing privileged functions.
Log review: Assign a named person or team to review logged privileged executions and to act on exceptions.
Interview readiness: Make sure the people who review privileges and the system developers can explain the control in their own words, since the assessment includes interviews.

Before the assessment, confirm that the privileged function list matches what the systems actually allow, and that the review owner can show a recent review record.

Common gaps that fail 03.01.07 and how to close them

Assessors testing 03.01.07 usually find the same few weaknesses: administrators working from shared or standard accounts, privileged functions nobody wrote down, and logs that prove a login happened without showing what the administrator did. The cards below pair each gap with a fix that an assessor can verify from documentation, configuration and audit records.

Privileged work on shared or standard accounts

Administrators often run privileged commands from a shared root login or from an everyday account that also reads email and browses the web. Under 03.01.07, the restriction only holds if non-privileged users cannot reach privileged functions and each privileged action traces to a named person. Check whether every privileged session can be tied to one individual, and whether the same account is used for security work and for ordinary tasks. Separate administrative accounts, with privileges granted through roles, close the gap.

Privileged functions left undocumented

Assessors examine the access control policy, least privilege procedures and system design documentation to see which functions are privileged. If a system has no list of privileged functions, no one can show that non-privileged users are blocked from them. Build an inventory of privileged functions per system, such as user administration, configuration changes, key management and audit log configuration, and map each one to the roles allowed to run it. Review the inventory whenever the system design changes.

Logins logged but not function execution

Many systems record that an administrator signed in but not which privileged function ran afterward. The requirement covers logging the execution of privileged functions, so a login record alone leaves the central question unanswered. Confirm that audit settings capture the function, the actor, the target and the outcome. Test this by performing a privileged change in a non-production environment and checking that the audit record shows the change.

Audit logs stored only locally

When audit records sit only on the host where the privileged action happened, an administrator with root access can alter or delete them. Forward privileged function logs to a separate store that administrators cannot edit, and restrict who can read or change that store. Confirm the retention period and the forwarding path with the assessor before fieldwork, since both appear in the evidence they will request.

Denied privileged attempts never reviewed

A non-privileged user who tries a privileged function and is refused generates evidence that enforcement is working, but only if someone reads it. Set alerts for repeated denials of privileged functions and assign a named owner to review them on a defined schedule. Keep a record of each review and of any follow-up. Assessors who ask how the organization knows restrictions are effective will expect to see this review trail.

How long and how much effort does 03.01.07 take to meet?

Is 03.01.07 a large piece of work or a small configuration task?

For most environments it is a focused task rather than a program of its own, because the requirement is narrow: stop non-privileged users from running privileged functions and log every time privileged functions run. The effort sits in finding out which functions count as privileged, confirming that the operating systems, applications and platforms enforce the split, and proving the audit trail exists. Its size depends far more on how many systems and administrative tools the boundary contains than on the wording of the requirement itself.

What does the team need to supply before the work can start?

The work needs people who can name the privileged functions in each system, usually system administrators, application owners and whoever maintains the access control policy and procedures. It also needs access to design documentation, system configuration settings and audit records, because the assessment examines these directly. Engineers who understand how privilege is granted in each platform must be available for hands-on checks, since the test method for this requirement looks at the mechanisms themselves.

What drives the effort up or down for 03.01.07?

The main drivers are the number of systems inside the CUI boundary, how many distinct platforms and admin consoles exist, and whether privilege is managed centrally or configured by hand on each host. Mature role-based access and existing audit logging shorten the work, while undocumented local administrator rights, shared administrative accounts and custom applications with their own privilege models lengthen it. Gaps found during testing often cost more than the original design work, so the state of current configuration is the biggest variable.

Can an organization meet 03.01.07 in-house?

Yes, many organizations can, provided they have staff who know their platforms well and can document the results in a form an assessor will accept. The requirement itself is not the hard part; the difficulty is consistency. Internal teams often lack time to build repeatable evidence, to test each mechanism independently, or to keep configuration records current after changes. The organization owns its controls either way, so the question is whether its own people can sustain that ownership across the system security plan and assessment cycle.

When does a partner help with 03.01.07, and what do they actually do?

A partner is most useful when privilege is spread across many platforms, when logging has to be added to tools that do not produce usable records, or when the team needs an independent check before an assessment. DeployOpen plans, implements and hardens self-hosted open-source platforms inside the client's own infrastructure and prepares the configuration and evidence for the assessment. It does not assess the requirement or issue any report, which remains the job of the assessing body the contracting agency or DCMA relies on.

What should a written scope for 03.01.07 include?

A useful written scope names the systems and privileged functions in boundary, the platforms whose privilege mechanisms will be configured or verified, and the audit records that will be produced and retained. It should list deliverables such as configuration evidence, test results and updated procedures, state who owns each control after handover, and set out what the partner will not do, including the assessment itself. Ask for the timeline, the assumptions about existing configuration, and the process for handling gaps found during testing, since these determine the final cost.

Which costs recur after the first implementation?

Some effort is one-time, such as the initial inventory of privileged functions, configuration changes and first round of evidence collection. Other effort recurs: reviewing privileged function assignments, checking that audit records keep flowing, updating documentation after platform upgrades and reviewing logs for activity that should not happen. Ask any provider to separate these two categories in the quote so the ongoing operating cost of keeping 03.01.07 true is visible before the engagement is signed.

How DeployOpen prepares 03.01.07 evidence

DeployOpen works on 03.01.07 by making privileged functions restricted to the right people and every privileged execution traceable in the systems the organization already runs. The organization owns the control and its policy, DeployOpen prepares the configuration, logging and evidence, and an independent assessor reviews the result.

How we scope

Agree in writing which systems, administrative functions and audit mechanisms fall inside the 03.01.07 scope.
Map the privileged functions on each in-scope platform, such as administrative consoles, key management and security tooling.
Confirm which party owns the access control policy, the least privilege procedures and the review of privileged functions.

How we build

Configure role-based access so non-privileged users cannot execute privileged functions on the self-hosted platforms.
Enable audit logging for privileged executions, such as the Nextcloud admin_audit app where it fits the deployment.
Route audit records to a central store, such as OpenSearch or Wazuh, with alert rules for privileged activity.

How we hand over

Document each privileged function, the role allowed to run it and the log source that records its execution.
Deliver test records showing a non-privileged attempt is blocked and a privileged execution is logged and searchable.
Provide the configuration baselines and procedure notes an assessor would examine and the operator would interview on.

How we support

Scope ongoing support as a retainer covering role reviews, log source changes and platform upgrades.
Re-test privileged function restrictions and logging after changes to the platforms, roles or ruleset.
Ask your assessor which evidence format and sampling they expect before the work starts, and confirm it in the written scope.