AU-12(3): Changes by Authorized Individuals

AU-12(3) requires you to give specific authorized roles the technical ability to change what gets logged on defined system components, using selectable event criteria, and to do it within a defined time threshold. Operationalize it by tightly scoping who can change logging, standardizing how changes are requested/approved, and proving every change is controlled, tested, and auditable. ¹

Key takeaways:

• Define “who, what, how fast”: authorized roles, in-scope components, selectable event criteria, and time thresholds. ¹
• Implement a controlled “logging change” pathway (RBAC + change management + break-glass) with audit trails for every change.
• Retain evidence that shows capability, authorization, and time-to-implement for each logging change.

AU-12(3) is an operations control dressed as an audit control. Examiners and customer assessors expect you to show that logging is not a static configuration that only works “when engineering has time,” and not an ad hoc activity that any admin can tweak without oversight. The requirement is explicit: you must provide and implement a capability for authorized individuals or roles to change the logging performed on specific system components, based on selectable event criteria, within defined time thresholds. ¹

For a CCO, GRC lead, or security compliance owner, the fastest path is to treat AU-12(3) as a bounded change-control use case: “logging coverage must be adjustable quickly and safely.” That means (1) predefining the knobs teams are allowed to turn (event criteria and components), (2) restricting who can turn them, (3) enforcing workflow and approvals appropriate to risk, and (4) keeping durable evidence that you can respond within your stated time thresholds.

This page gives requirement-level implementation guidance you can hand to Security Operations, Platform/SRE, and IAM, then measure with artifacts that stand up in audits.

Regulatory text

Requirement (verbatim): “Provide and implement the capability for [individuals or roles] to change the logging to be performed on [system components] based on [selectable event criteria] within [time thresholds].” ¹

Operator interpretation: what you must do

You must:

1. Name the authorized individuals or roles who can change logging (not “admins generally”).
2. Define the system components in scope (e.g., SIEM, EDR, identity provider, critical application clusters, cloud audit logs, databases).
3. Define selectable event criteria (what types of events can be enabled/disabled or tuned: authentication events, privilege changes, network flows, admin actions, specific application audit events, severity thresholds).
4. Define time thresholds for making those changes (how quickly you can increase logging when risk changes).
5. Implement the technical capability and governance workflow that makes the above real, repeatable, and auditable. ¹

Plain-English requirement (what AU-12(3) is really asking)

Your organization must be able to turn logging up or down on purpose, quickly, and only through authorized hands. You need to prove two things:

• Governance: Only designated roles can change logging, and those changes follow a controlled process.
• Operations: The environment supports timely logging changes based on defined criteria (for example: “enable additional authentication and admin-action logging on identity systems during an incident”).

Who it applies to

Entity scope

AU-12(3) is part of NIST SP 800-53 Rev. 5 and commonly applies to:

• Federal information systems
• Contractor systems handling federal data (including many environments aligned to NIST-based requirements) ²

Operational context (where this shows up in real life)

You should expect AU-12(3) to be tested where:

• You operate a SIEM or centralized logging pipeline.
• You rely on cloud-native audit logging (e.g., control plane logs) and must tune categories or sinks.
• Your applications produce audit logs that can be configured (feature flags, verbosity, event selection).
• Incident response requires rapid expansion of telemetry without waiting for a major release window.

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

1) Write a “logging change control card” (one page)

Treat AU-12(3) like a runbook-backed control, not a policy statement.

Minimum fields:

• Control objective: Authorized roles can change logging on defined components by event criteria within defined time thresholds. ¹
• Control owner: Named team (often SecOps or Platform) and named executive sponsor.
• In-scope components: A list with system owner per component.
• Authorized roles: e.g., “SecOps Logging Engineer,” “SRE On-Call,” “Incident Commander” (break-glass only).
• Selectable event criteria: A menu of allowable changes (examples below).
• Time thresholds: Your declared targets (be realistic and measurable).
• Triggers: Incident, threat advisory, audit finding, new system go-live, major control failure.
• Exceptions: Emergency changes and retroactive approval rules.

2) Define “selectable event criteria” as a menu (not free-form)

Auditors struggle with vague statements like “we can change logging when needed.” Give engineering a controlled set of knobs, such as:

• Enable/disable categories: authentication, authorization failures, privilege escalation, configuration changes, data access to sensitive objects.
• Adjust verbosity levels for specific services (e.g., WARN → INFO for auth modules).
• Add/remove log sources for specific components (e.g., enable database audit extension).
• Change filters (include/exclude patterns) and routing (send to SIEM index X).

Document which are allowed under standard change vs emergency change.

3) Implement tight authorization (RBAC) for logging configuration

Map AU-12(3) “authorized individuals or roles” to enforceable access controls:

• Restrict write access to logging policies/configs (SIEM collectors, cloud audit sinks, agent policies, app config repos).
• Require separate roles for “request,” “approve,” and “implement” where feasible.
• Use MFA and privileged access management patterns for the roles that can change logging configs.
• For break-glass: create a named emergency role with session recording and short-lived access, then require after-action review.

4) Put logging changes through change management (with a fast lane)

Define two paths:

Standard path (planned):

• Ticket created with reason, scope, event criteria, rollback plan.
• Approval by service owner + security owner (or a defined approver group).
• Implementation via infrastructure-as-code or controlled admin console steps.
• Post-change validation checklist.

Emergency path (incident/threat):

• Incident Commander authorizes.
• Implement immediately via pre-approved procedure.
• Retroactive ticket and approval within your internal threshold.

AU-12(3) cares that changes happen within your stated time thresholds, so your workflow must support a “fast lane” that still leaves an audit trail. ¹

5) Make “time thresholds” measurable

Define time thresholds in operational terms you can prove, for example:

• Time from incident declaration to enabling additional logging on identity and perimeter systems.
• Time from approved ticket to production deployment of updated logging configuration.

Do not pick a number you cannot evidence. Your evidence should show timestamps from ticketing, incident tooling, and config change logs.

6) Validate and monitor the logging change capability

Add control health checks:

• Quarterly (or your chosen cadence) test a logging change in a non-production environment and record results.
• Confirm that the RBAC roles still exist and are staffed.
• Verify that changes generate their own audit trail (who changed what, when).

If you use Daydream to manage control operations, set AU-12(3) up as a recurring control with an evidence bundle checklist and ownership routing, so you can produce the same artifacts every cycle without scrambling.

Required evidence and artifacts to retain

Use an “evidence bundle” approach: one folder per change (or per test), plus a periodic access review pack.

Per logging change (standard or emergency):

• Change ticket / incident record with business justification and scope.
• Approval record (who approved, when).
• Configuration delta (IaC pull request, policy diff, or console export before/after).
• Implementation logs (CI/CD pipeline logs, admin console audit event, PAM session record).
• Validation output (sample logs showing new events arriving; SIEM query screenshots; parsing/normalization checks).
• Rollback plan and rollback confirmation if used.

Periodic evidence (control operation):

• List of in-scope components and owners.
• List of authorized roles and current assignees.
• Access reviews for those roles (including break-glass access).
• Control health check results and remediation tracking to closure.

Common exam/audit questions and hangups

Auditors and assessors usually press on these points:

1. “Who exactly is authorized?”
   Expect requests for role definitions, current membership, and approval authority.

2. “Show me you can change logging quickly.”
   They will ask for an example from an incident or a test, with timestamps.

3. “What prevents an admin from disabling logs?”
   You need compensating controls: RBAC, separation of duties, approvals, alerting on logging configuration changes.

4. “What is ‘selectable event criteria’ in your environment?”
   If you cannot enumerate criteria, the control looks aspirational.

5. “Which components are in scope?”
   If scope is unclear, teams cannot prove coverage.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails in audits	Fix
“SecOps can change logging” with no named roles	“Authorized individuals or roles” is undefined	Define roles, map to IAM groups, document membership process.
Console-only changes with no durable trace	Weak evidence; hard to prove what changed	Prefer IaC + PR review; export console audit logs to SIEM.
Time thresholds stated but not measurable	You cannot prove compliance	Tie thresholds to ticket/incident timestamps and config change timestamps.
Break-glass exists but no guardrails	Creates a log-tampering story	Time-bound access, session logging, mandatory post-incident review.
Scope excludes “messy” systems	Gaps show up during incidents	Start with high-risk components, then expand scope with a roadmap.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-12(3), so you should frame risk in audit and operational terms rather than enforcement precedent.

Operationally, weak AU-12(3) implementation increases:

• Detection risk: you cannot increase telemetry when threat conditions change.
• Investigation risk: incomplete logs slow containment and root cause analysis.
• Integrity risk: uncontrolled logging changes enable tampering narratives (internal or external).

For regulated environments and federal-aligned customers, failure often appears as an assessment finding: “logging changes are not controlled,” or “organization cannot demonstrate timely adjustments to audit logging.”

Practical 30/60/90-day execution plan

First 30 days (baseline the requirement)

• Assign an owner and publish the AU-12(3) control card with placeholders for roles, components, event criteria, and time thresholds. ¹
• Inventory current logging control points (SIEM configs, cloud audit sinks, EDR policies, app audit settings).
• Identify the minimum set of “in-scope components” you can defend (start with identity, endpoint, cloud control plane, and critical apps).
• Define authorized roles and implement IAM groups for them (even if membership is small at first).

By 60 days (implement the controlled change pathway)

• Stand up the standard change workflow (ticket template, approvals, validation checklist, rollback).
• Implement emergency/break-glass with guardrails and after-action review requirements.
• Choose at least one system component and move logging changes to IaC + PR review to generate strong evidence quickly.
• Define a measurement method for time thresholds (what timestamps you will collect and from where).

By 90 days (prove it works, then scale)

• Run a tabletop-driven logging change test: simulate a threat trigger, execute the change path, and capture the full evidence bundle.
• Add monitoring/alerting for logging configuration changes (at minimum: alert when audit sinks/agents/policies change).
• Expand scope to additional components based on risk, then bake this into onboarding for new systems.
• Schedule recurring control health checks and track remediation items to closure.

Frequently Asked Questions

Does AU-12(3) require that we allow engineers to change logging on demand?

It requires a defined capability for authorized roles to change logging based on selectable criteria within defined thresholds. You can centralize the capability in SecOps or Platform, but you still need a controlled mechanism that works on schedule. ¹

What counts as “system components” for AU-12(3)?

Any component where changing logging meaningfully affects detection and investigations can be in scope, including cloud audit logs, SIEM collectors, EDR policies, identity providers, and critical applications. Your scope must be explicit and owned. ¹

What are examples of “selectable event criteria” that auditors accept?

Auditors look for a defined menu such as authentication events, privilege changes, admin actions, sensitive data access, and configuration changes. The key is that criteria are documented and mapped to how logging is configured in your tools. ¹

Can we meet AU-12(3) if logging changes are only done through a SIEM admin console?

Yes, if you can prove authorization, approvals, and a durable audit trail of the change, plus validation that the new events are collected. IaC and PR-based workflows usually produce cleaner evidence, but console workflows can pass if controlled.

How do we set “time thresholds” without overcommitting?

Define thresholds that match how your teams actually respond under standard and emergency conditions, then design your workflow to reliably hit those targets. Make sure you can produce timestamps from tickets/incidents and system audit logs to prove performance.

What evidence is most often missing during audits?

Teams often have policies but cannot show a full “change packet” that includes approvals, config diffs, and proof that the new logs arrived. Build a standard evidence bundle checklist and require it for every logging change and periodic test.

Footnotes

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

2. NIST SP 800-53 Rev. 5