AC-6(9): Log Use of Privileged Functions

AC-6(9) sits under the NIST 800-53 Access Control family and is simple in wording but easy to fail in practice: “Log the execution of privileged functions.” ¹ Most organizations already collect some admin activity logs, yet gaps show up where privileged actions occur outside the “usual” places: cloud control planes, SaaS admin consoles, CI/CD pipelines, identity providers, endpoint management tools, and break-glass accounts.

A CCO or GRC lead usually doesn’t configure auditd, CloudTrail, or M365 Unified Audit Log. Your job is to translate this requirement into a control operators can run, and to make the control auditable: clear ownership, defined scope, logging standards, and evidence that the logging is both enabled and working. The fastest path is to treat AC-6(9) as a coverage exercise (what privileged actions exist), a telemetry exercise (are those actions logged at the source), and an operations exercise (are the logs centralized, protected, and reviewed for misuse).

This page gives you requirement-level implementation guidance you can hand to Security Engineering and IAM, plus the evidence bundle you need for assessments mapped to NIST SP 800-53 Rev. 5. ²

Regulatory text

Requirement (AC-6(9)): “Log the execution of privileged functions.” ¹

Operator interpretation (what you must do):

1. Identify what your organization considers “privileged functions” across systems in scope.
2. Configure each system so those functions generate audit records.
3. Send those audit records to a centralized logging platform where they are protected from tampering and are searchable for investigations.
4. Run the control continuously: verify log flow, alert on key events, and retain evidence that the control operates.

NIST’s text is concise. Auditors will still expect specificity from you: which functions, which systems, which log sources, and how you confirm completeness. ¹

Plain-English interpretation

A privileged function is any action that can change access, change security settings, affect auditability, or materially alter system behavior. AC-6(9) means: if someone performs that action, your systems must record it in a way you can later prove happened, attribute to an identity, and investigate.

A practical test: if an attacker or disgruntled admin did this action, would you need an audit trail to understand impact and scope? If yes, it belongs in the privileged function list.

Who it applies to

Entity types

• Federal information systems and programs using NIST SP 800-53 Rev. 5 controls. ²
• Contractors and service providers handling federal data where NIST 800-53 controls are flowed down contractually or through an authority to operate boundary. ²

Operational context

• Systems where privileged actions exist: infrastructure, platforms, applications, databases, identity systems, endpoints, security tooling, and key SaaS admin consoles.
• Third parties: if a third party administers your environment (MSP, managed security provider, SaaS provider with delegated admin), AC-6(9) becomes a shared-responsibility control. You still need evidence that privileged actions are logged and accessible to you for investigations.

What you actually need to do (step-by-step)

Step 1: Assign ownership and define the control “runbook”

Create a control card that answers, in one page:

• Control objective: log execution of privileged functions across in-scope systems. ¹
• Owner: usually Security Operations or Platform Security; GRC is accountable for evidence quality.
• In-scope systems: a living inventory tied to your asset register and SaaS catalog.
• Cadence: continuous logging; periodic validation and review (define the frequency your team can sustain).
• Exceptions: how you handle legacy systems, segmented networks, or third-party managed platforms.

This is the fastest way to avoid the common audit failure: “we log admin activity” with no named owner, no coverage statement, and no repeatable evidence.

Step 2: Build your privileged function taxonomy (what must be logged)

Create a list of privileged functions by category. Keep it short enough to maintain, but concrete enough to test.

Common privileged function categories (examples):

• Identity and access: create/delete users; assign roles; change MFA; modify conditional access; create API keys/service principals; change password policies.
• Authorization changes: grant database admin; add to privileged groups; change RBAC policies; modify IAM trust relationships.
• Security configuration: disable logging; change audit policies; modify firewall rules/security groups; change encryption/KMS settings; rotate keys; change EDR policies.
• Privileged execution: sudo/root actions; run-as/admin actions; remote management sessions; privileged commands via automation.
• Data-plane “dangerous” actions: exfil pathways (export buckets, snapshot/copy databases), mass delete, disable backups.

Map each function category to at least one log source. If you can’t name the telemetry source for a function, treat that as a gap that must be tracked to closure.

Step 3: Turn on logging at the source (system-by-system)

Logging is not a SIEM feature; it starts at the control plane and host/application layer.

Minimum expectations you should set for engineering teams:

• Enable native audit logs for each platform (cloud provider audit trails, OS auditing, database audit logs, directory service audit logs, SaaS admin audit logs).
• Ensure events include attribution: who performed the action (user/service identity), what action, target object, timestamp, source IP/device, and result (success/failure) where available.
• Protect against “silent admin” paths: break-glass accounts, local accounts, emergency access, and automation identities must generate the same level of auditability.

Deliverable: a “log source coverage matrix” showing each in-scope system, the privileged functions it supports, and the audit log mechanism used.

Step 4: Centralize, protect, and retain logs

To make AC-6(9) auditable, you need centralized collection and tamper resistance.

• Centralize privileged-function logs into your SIEM/log analytics platform.
• Restrict access so admins cannot easily delete or edit logs without detection (separation of duties matters in practice).
• Set retention aligned to your investigation and contractual requirements. If you have multiple retention drivers (regulatory, customer, IR), document the “highest requirement wins” rule and apply it consistently.

Deliverable: documented log routing (architecture diagram or data flow) plus access control settings for the logging platform.

Step 5: Detect and review (prove it operates)

AC-6(9) is “log,” but auditors will still ask: “So what?” Your control should include operational checks:

• Alerting for high-risk privileged functions, such as disabling logging, granting admin roles, changing MFA, key management changes, and privilege escalation.
• Control health checks: confirm logs are arriving from each source, parse correctly, and are time-synchronized enough for investigations.
• Review workflow: tickets/incidents generated from alerts, triage notes, and closure outcomes.

If your organization struggles to keep this consistent, Daydream can help by turning AC-6(9) into an operator-owned control card with a required evidence bundle and recurring health checks, so you can show sustained operation instead of one-time configuration.

Required evidence and artifacts to retain

Keep evidence focused on “coverage + operation + integrity.”

Design evidence (what you built)

• Control card/runbook: objective, owner, scope, exceptions.
• Privileged function taxonomy (approved list).
• Log source coverage matrix (system → privileged functions → log source).
• Logging architecture/data flow (source → collector → SIEM).

Operating evidence (proof it works)

• Screenshots or exported settings showing audit logging enabled for representative platforms (cloud, IdP, endpoints, key SaaS).
• Sample log events demonstrating privileged function execution (redact sensitive fields, keep structure).
• SIEM ingestion proof: index/query results showing events over time for each key source.
• Alert rules or detection use-cases tied to privileged actions, plus recent alert/ticket examples.
• Control health check records and remediation tickets for gaps, tracked to validated closure.

Integrity evidence

• Role-based access list for who can access/modify logging configurations and who can administer the SIEM.
• Evidence of immutable storage or compensating controls (write-once settings, separate admin roles, change control logs).

Common exam/audit questions and hangups

Auditors and assessors tend to ask the same questions because this control fails in predictable ways:

1. “Define privileged functions for your environment.” If you answer with “anything admins do,” you will get follow-up questions until you produce a list.
2. “Show me evidence that privileged functions are logged.” Expect a request for raw event examples.
3. “Is logging enabled everywhere?” They will probe high-risk areas: IdP, cloud control plane, CI/CD, and endpoints.
4. “Can an admin delete or alter the logs?” They will ask about separation of duties and immutable retention.
5. “Who reviews the logs and what happens on alerts?” They want operational proof: tickets, triage notes, outcomes.

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Logging only “admin logins,” not admin actions.
Fix: require event coverage for permission changes, security configuration changes, and privileged execution.

Mistake 2: Relying on a SIEM contract as “compliance.”
Fix: document log sources and show real events flowing; a tool purchase is not control operation.

Mistake 3: Excluding SaaS admin consoles.
Fix: treat SaaS as in-scope where business-critical data or identity control exists; require admin audit logs contractually with third parties.

Mistake 4: No ownership, no cadence, no evidence bundle.
Fix: create the control card, define minimum evidence, and run recurring health checks. ¹

Mistake 5: Admins can tamper with audit trails.
Fix: split duties between system admins and log platform admins; restrict delete privileges; monitor changes to logging configuration as privileged events themselves.

Risk implications (why operators care)

If privileged functions are not logged, you lose three capabilities:

• Attribution: you cannot reliably tie impactful changes to a human or service identity.
• Containment: you cannot quickly identify what changed during an incident.
• Assurance: you cannot demonstrate to customers, assessors, or authorizing officials that administrative power is controlled and observable.

That creates practical business risk: longer investigations, weaker incident reports, and failed audits that trigger remediation plans.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and telemetry)

• Name the control owner and publish the AC-6(9) control card (objective, scope, exceptions). ¹
• Build the privileged function taxonomy and get sign-off from Security + IAM.
• Inventory in-scope systems and third parties with admin access.
• Enable/confirm audit logging for the top-priority systems: identity provider, primary cloud account(s), endpoint management, and key SaaS with privileged roles.
• Stand up a basic SIEM dashboard/search that can retrieve privileged-function events by user and time window.

By 60 days (close coverage gaps and add detection)

• Complete the log source coverage matrix for all in-scope systems.
• Centralize remaining log sources; standardize parsing/fields where possible.
• Implement alerting for your “critical privileged functions” list (disable logging, role grants, key management changes, MFA changes).
• Define and test the response workflow: where alerts go, who triages, what evidence is captured in tickets.
• Start control health checks and track issues to closure with due dates. ¹

By 90 days (make it auditable and repeatable)

• Demonstrate end-to-end evidence: a privileged action occurs → event appears in SIEM → alert triggers (if applicable) → ticket closed with analysis.
• Validate log integrity controls: access restrictions, deletion protections, change tracking for logging configuration.
• Formalize third-party requirements: contracts/SOWs require privileged admin audit logs and timely access for investigations (or compensating reports).
• Package the minimum evidence bundle in a single repository location so audits do not become a scavenger hunt. ¹

Frequently Asked Questions

What counts as a “privileged function” for AC-6(9)?

Treat it as any action that changes access, security configuration, auditability, or system behavior in a material way. Start with IAM role changes, logging configuration changes, key management actions, and privileged command execution. ¹

Do we need to log successful actions only, or failures too?

The requirement says to log execution of privileged functions, which in practice includes both successful and attempted actions where the platform provides that telemetry. Capturing failures improves detection of brute force or misuse attempts, and it strengthens incident reconstruction. ¹

Is centralized logging required, or can we keep logs on each system?

AC-6(9) focuses on logging execution, but audits commonly expect you to be able to retrieve and investigate across systems without relying on local access that admins could tamper with. Centralization is the practical way to prove availability and integrity of audit records.

How do we handle privileged actions performed by a third party?

Treat third-party admin activity as in-scope privileged functions. Require audit logging and access to those logs (or equivalent reports) in contracts, and confirm the logging exists during due diligence and periodic reviews.

What evidence is “enough” for an assessor?

Provide (1) your privileged function list, (2) a log source coverage matrix, (3) proof logging is enabled in representative systems, and (4) sample events and review/alert tickets showing ongoing operation. Keep it consistent and repeatable.

We have legacy systems that can’t generate detailed privileged-function logs. What do we do?

Document the exception, implement compensating controls (restricted admin access paths, jump hosts, session recording, stronger change control), and create a remediation plan with ownership. Auditors usually accept constrained exceptions when they are explicit and managed.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5