AU-12(3): Changes by Authorized Individuals

The au-12(3): changes by authorized individuals requirement is about controlled flexibility. You need the ability to adjust logging quickly when risk changes (for example, an active incident, a new threat pattern, or a high-risk system change), but you cannot allow ad hoc, untracked changes that undermine auditability or create blind spots.

For a Compliance Officer, CCO, or GRC lead, the fastest path to compliance is to treat “logging changes” as a governed configuration item: assign a control owner, restrict who can make changes, require documented rationale tied to defined conditions, and ensure each change is time-bound and validated. The control is also a coordination problem: security operations wants speed, platform teams own tooling, and compliance needs provability.

This page gives requirement-level implementation guidance you can execute: definitions to lock down, a step-by-step operating procedure, the artifacts auditors ask for, common failure modes, and a practical execution plan. Source references are limited to NIST SP 800-53 Rev. 5 materials provided. ¹

Regulatory text

NIST AU-12(3) excerpt: “Provide and implement the capability for {{ insert: param, au-12.03_odp.01 }} to change the logging to be performed on {{ insert: param, au-12.03_odp.02 }} based on {{ insert: param, au-12.03_odp.03 }} within {{ insert: param, au-12.03_odp.04 }}.” ²

Operator translation (what you must implement)

You must implement a real, working capability that:

1. Identifies the authorized individuals allowed to change logging (not “any admin” by default).
2. Defines the logging scope (systems, platforms, applications, cloud services, endpoints) where the requirement applies.
3. Defines the basis/conditions that justify a logging change (for example, incident response, threat intel, audit need, troubleshooting with approvals).
4. Defines the required timeframe in which those authorized individuals can make the change (your parameter; auditors will expect it to be explicit and followed).
5. Proves the change happened as intended with traceable records.

This is not just a policy statement. Assessors will look for a working process and evidence that it is used.

Plain-English interpretation of the requirement

AU-12(3) expects that you can increase, decrease, or modify logging in a controlled way. The control exists because logging requirements are not static. During incidents you may need higher fidelity logs. During normal operations you may tune noisy sources. The risk is that logging gets turned down (or off) without governance, creating detection gaps and complicating investigations.

A practical interpretation:

• Logging is a security control and a configuration item.
• Changes to logging must be role-restricted, approved, tracked, and validated.
• “Within X” is your service level for making logging changes when conditions demand it.

Who it applies to (entity and operational context)

Entities

• Federal information systems and programs aligned to NIST SP 800-53.
• Contractor systems handling Federal data where NIST SP 800-53 controls flow down through contracts, ATO requirements, or agency security requirements. ³

Operational contexts where AU-12(3) becomes “exam material”

Expect scrutiny when you have:

• Central logging/SIEM pipelines (cloud-native logging, syslog aggregators, EDR/XDR telemetry).
• Privileged administrators with access to logging agents, collectors, or SIEM parsing rules.
• Incident response requirements that depend on rapid logging adjustments.
• High-value assets where logging gaps are unacceptable (identity systems, boundary devices, key production workloads).

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

Step 1: Set the control parameters (the placeholders you must fill)

AU-12(3) contains organization-defined parameters. You must define them clearly and publish them in your control narrative/procedure. ²

Create a one-page “AU-12(3) logging change parameters” record:

• Authorized individuals (ODP.01): specific roles (by job function) and named groups (by directory group name).
• Logging targets (ODP.02): in-scope systems and logging layers (app logs, OS logs, cloud audit logs, network telemetry, identity logs).
• Basis (ODP.03): enumerated triggers/conditions that permit change.
• Time window (ODP.04): required time-to-execute, plus any emergency path for active incidents.

Keep it concrete. Auditors reject vague language like “as needed” without triggers and approval rules.

Step 2: Build a controlled change path for logging

Implement a change mechanism that is auditable end-to-end:

• Access control: only authorized roles can change log settings (agents, collectors, pipelines, retention, filters, parsing rules).
• Change management: every change is a ticket or formally recorded request with approvals.
• Segregation of duties where feasible: the person requesting logging changes is not the only person approving them, especially for logging reductions.

Common patterns that work in practice:

• Infrastructure-as-code (IaC) for logging configurations, with protected branches and pull-request approvals.
• Admin consoles with RBAC plus mandatory change tickets referenced in the change description.
• Break-glass accounts for emergency changes, with compensating review.

Step 3: Define “allowed changes” vs “restricted changes”

Not all logging changes carry the same risk. Build a simple decision matrix and attach it to your procedure:

Change type	Examples	Risk level	Approval expectation
Increase logging fidelity	Add new sources, enable additional events	Lower (usually)	Standard change approval
Modify parsing/filters	SIEM rules that drop events, pipeline filters	Medium	Security review required
Reduce logging / disable sources	Turn off audit logs, reduce retention, exclude systems	High	Senior security approval + documented rationale

This avoids the “same approval for everything” trap that causes teams to bypass process.

Step 4: Create an incident fast-path that still produces evidence

During an incident, speed matters. Define an emergency procedure that still meets AU-12(3):

• Who can invoke emergency logging changes.
• What minimum documentation is required at time of change (ticket stub, incident number, rationale).
• A required after-action review to confirm what changed, why, and whether it is reverted or made permanent.

Step 5: Verify and document the logging change outcome

AU-12(3) is not satisfied if you “made the change” but never confirmed telemetry arrived. Add a verification checklist:

• Confirm configuration applied to the right targets.
• Confirm events are arriving in the log platform.
• Confirm alerting/detections (if relevant) still function.
• Confirm retention aligns with policy/requirements (if the change affects retention).

Step 6: Operationalize with ownership and recurring evidence

Assign:

• Control owner: usually Security Engineering or Platform Security (with GRC oversight).
• Operators: SIEM/logging platform team, SRE, cloud platform admins.
• Approvers: Security leadership; optionally Privacy if the change increases personal data collection.

If you use Daydream to run control operations, map AU-12(3) to a named owner, a written implementation procedure, and a recurring evidence list so you can answer assessors quickly without rebuilding the story each audit cycle. ²

Required evidence and artifacts to retain

Auditors typically want proof across design, implementation, and operation. Retain:

Governance artifacts

• AU-12(3) control narrative with filled parameters (authorized individuals, scope, basis, timeframe). ²
• Logging architecture overview (data flow: sources → collectors → storage/SIEM).
• RBAC/authorization design for logging administration.

Operational artifacts (most important)

• Change tickets for logging modifications with:
  • requestor, implementer, approver
  • rationale tied to an allowed “basis”
  • affected systems (targets)
  • timestamps showing change performed within your defined timeframe
• System logs showing the logging configuration was changed (admin activity logs).
• Post-change verification evidence (screenshots, queries, sample events, pipeline health checks).
• Emergency changes register + post-incident review notes.

Access artifacts

• Directory group membership export for “logging admins.”
• Privileged access management (PAM) records if used.
• Quarterly/periodic access reviews for logging-admin roles (keep the review results and remediation notes).

Common exam/audit questions and hangups

Be ready to answer:

1. “Who exactly can change logging?” Provide role names, group names, and membership evidence.
2. “Show me a logging change from the last period.” Have a sample ticket and associated system evidence ready.
3. “How do you prevent an admin from disabling logs to hide activity?” Show RBAC limits, approvals, and monitoring of logging-control-plane activity.
4. “What does ‘within X’ mean here, and do you meet it?” Show your defined timeframe plus timestamps from request to implementation.
5. “How do you validate the change worked?” Demonstrate a repeatable verification checklist and retained outputs.

Frequent implementation mistakes and how to avoid them

• Mistake: “Admins can change anything” with no named authorized individuals. Fix: define a narrow logging-admin role and enforce membership reviews.
• Mistake: No explicit triggers for changing logging. Fix: enumerate allowed bases and require the requester to pick one in the ticket.
• Mistake: Emergency changes happen in chat with no ticket. Fix: require an incident number and create a ticket immediately after containment.
• Mistake: Logging reductions treated like routine tuning. Fix: add heightened approvals and explicit justification for any reduction.
• Mistake: Evidence scattered across tools. Fix: centralize evidence collection in your GRC workflow so you can produce it on demand.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-12(3), so this page does not list case citations. Practically, AU-12(3) failures show up during assessments as:

• inability to prove governance over logging configuration,
• unexplained gaps in telemetry during incident investigations,
• inconsistent logging across in-scope systems.

Those issues can drive audit findings, delay ATO decisions, and increase breach investigation costs because you cannot reconstruct activity reliably.

A practical 30/60/90-day execution plan

First 30 days: Define and constrain

• Name the AU-12(3) control owner and operators.
• Fill the AU-12(3) parameters: authorized individuals, logging targets, bases, timeframe. ²
• Inventory logging control points (agents, collectors, cloud audit logs, SIEM pipelines) and identify where changes occur.
• Create the logging change SOP and a standard ticket template with required fields.

Next 60 days: Implement controls and evidence

• Implement RBAC and restrict logging change permissions to approved groups.
• Put logging config behind change management (tickets + approvals or protected IaC workflow).
• Implement admin activity logging for logging control planes (so changes to logging are themselves logged).
• Run a tabletop: simulate an incident-driven logging increase and collect the evidence package.

By 90 days: Prove operations and tighten

• Perform a targeted access review of logging-admin groups and remediate over-privilege.
• Sample recent logging changes and confirm each has request/approval/implementation/verification evidence.
• Add monitoring or alerts for high-risk logging changes (disablement, retention reductions, filter drops).
• Operationalize recurring evidence capture (for example, monthly change samples and quarterly access reviews) in Daydream or your existing GRC system of record.

Frequently Asked Questions

Does AU-12(3) require that logging changes be automated?

No. It requires a capability for authorized individuals to change logging within your defined timeframe. Automation helps with consistency and evidence, but a controlled manual process can meet the requirement if it is enforced and auditable. ²

Who counts as an “authorized individual” for AU-12(3)?

Define this explicitly as roles and groups, not a vague “admins.” Most programs restrict this to a logging platform admin role with documented membership and periodic reviews. ²

What qualifies as a “basis” for changing logging?

Use a short list of allowed triggers such as incident response, validated threat intel, onboarding a new high-risk system, audit requirement, or approved troubleshooting. The key is that the basis is predefined and recorded on each change. ²

Can we allow emergency logging changes without prior approval?

You can, but define an emergency path with limited authorized users and require prompt documentation and after-the-fact review. Auditors will accept speed during incidents if compensating governance produces a complete record. ²

What evidence is most likely to fail an audit for AU-12(3)?

Missing linkage between the ticket and the actual system change is the common failure. Keep admin activity logs, configuration diffs, and a verification record that proves the change applied to the stated targets.

How should we scope AU-12(3) in a hybrid environment (cloud + on-prem)?

Scope it to the systems/components where security logging matters for detection and investigations, then document that scope. In practice, start with identity, boundary controls, production workloads, and the logging pipeline itself, then expand coverage as you mature.

Footnotes

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

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

3. NIST SP 800-53 Rev. 5