AU-6(10): Audit Level Adjustment

CCOs and GRC leads usually inherit logging that is either “log everything forever” or “log almost nothing because cost.” AU-6(10): audit level adjustment requirement is the control that forces a third path: logging becomes a managed capability with pre-defined audit levels that can be increased or tuned when risk changes, an incident starts, new threats emerge, or audit findings demand more telemetry.

For operators, the difference between “we have logging” and “we meet AU-6(10)” is governance and repeatability. You need a documented method to adjust audit verbosity (and scope), a restricted set of authorized roles who can execute changes, and evidence that each adjustment was intentional, justified, and verified. AU-6(10) sits in the AU (Audit and Accountability) family, so assessors expect tight linkage to monitoring, incident response, and configuration/change management, even if those are separate programs.

This page gives you requirement-level steps, an evidence checklist, and audit-ready talking points you can put in place quickly for systems aligned to NIST SP 800-53 Rev. 5. ¹

What AU-6(10) means in plain English

AU-6(10): audit level adjustment requirement expects your organization to increase, decrease, or otherwise tune auditing in a controlled way as conditions change, rather than keeping a single static logging posture. The intent is practical: during elevated risk (active incident, suspicious activity, high-value change windows), you should be able to collect more detailed audit data fast, without improvising or granting broad, permanent permissions.

In practice, assessors look for three outcomes:

1. Defined audit levels that map to concrete log sources and event categories.
2. A controlled mechanism to change levels (authorization, change recording, and technical enforcement).
3. Evidence that changes happened when needed, were reviewed, and did not break storage, privacy, or system performance obligations.

Reference: AU-6(10) in NIST SP 800-53 Rev. 5. ²

Regulatory text

The provided excerpt is: “NIST SP 800-53 control AU-6.10.” ²

Operator interpretation: You must implement AU-6 enhancement (10) under AU-6 (Audit Record Review, Analysis, and Reporting) by establishing a governed capability to adjust audit/logging levels. The requirement is satisfied only when you can show (a) what “audit levels” mean for your environment, (b) who can change them and under what conditions, and (c) that level changes are recorded and reviewed as part of normal operations. ¹

Who this applies to (entity + operational context)

Entities

• Federal information systems and programs aligned to NIST SP 800-53 Rev. 5. ¹
• Contractors and third parties operating systems that handle federal data where NIST SP 800-53 is contractually required or flowed down.

Operational contexts where AU-6(10) is commonly tested

• Central logging/SIEM and any systems feeding it (cloud audit logs, endpoint logs, network/security devices, IAM).
• High-impact systems and regulated workloads where incident response and monitoring depend on reliable audit trails.
• Hybrid environments where teams adjust logging in multiple places (cloud-native logging plus on-prem collectors).

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

1) Declare your audit levels (make them testable)

Create a short standard that defines 2–4 audit levels. Keep it simple and measurable:

Audit level	Purpose	Example scope changes	Guardrails
Baseline	Normal operations	Standard auth, admin actions, system errors, key app events	Cost and privacy controls apply
Elevated	Heightened risk / investigation	Add verbose auth telemetry, detailed admin command logs, expanded network/security events	Time-boxed; requires approval
Emergency/Forensic	Confirmed incident	Maximum useful telemetry, tighter correlation, faster forwarding	Strict access; documented justification

Make “scope changes” explicit per platform:

• Cloud: which audit services (e.g., control plane), which trails, which data events.
• Endpoints: which security log channels, command-line logging, EDR verbosity.
• Applications: which audit events and fields; correlation IDs; privileged functions.

2) Define triggers that justify an audit level change

Write a trigger list that a SOC lead, IR lead, or platform owner can recognize quickly. Examples:

• Confirmed or suspected incident (IR declared).
• Detection rule indicates credential compromise or privilege escalation attempts.
• High-risk change window (identity provider config, key management, firewall).
• Audit finding: insufficient telemetry for a critical control test.

Keep triggers aligned to your existing programs (incident response, vulnerability management, change management). Assessors want consistency.

3) Assign authority and separation of duties

Document roles and who can:

• Request an audit level change (SOC, IR, system owner).
• Approve it (security leadership or delegated authority).
• Implement it (platform engineering, SIEM team).
• Review it after the fact (security governance/compliance or independent reviewer).

Add a hard rule: audit level changes are privileged actions and must be logged and reviewable.

4) Implement the adjustment mechanism (technical control)

Pick the mechanism you can enforce reliably:

• Policy-as-code / configuration management: pre-approved logging profiles that can be applied via controlled pipelines.
• SIEM/logging platform controls: switch parsers, collectors, filters, and routing based on environment tags.
• Cloud logging controls: enable higher-detail event categories in a controlled way.

Minimum expectation: you can show that a change is not ad hoc and that access to change is restricted.

5) Treat audit level changes as change management events

For each change, capture:

• Ticket/approval record with trigger and expected duration/rollback condition.
• Exact configuration delta (before/after).
• Risk notes (storage impact, privacy/PII exposure, performance).
• Validation results (see next step).

If your environment has emergency change procedures, align audit level changes to those rules.

6) Validate after change (and document the validation)

Create a quick validation checklist that an engineer can complete:

• Logs are being generated from required sources.
• Logs are being forwarded successfully to central storage/SIEM.
• Alerts/detections still function (no parser breakage).
• Storage/throughput within acceptable limits (or documented exception).
• Access controls on logs remain intact.

7) Review and rollback

Define when to revert to baseline:

• Incident closed.
• Investigation completed.
• Change window ends.
• Exception expires.

Then prove rollback happened, or document why it didn’t.

Required evidence and artifacts to retain

Build an “AU-6(10) evidence packet” that survives staff turnover:

1. Audit Level Standard / Logging Profiles
   • Definitions of each level, per system category.
2. Role-based access control evidence
   • List of authorized roles/groups that can adjust logging.
3. Procedures (runbook)
   • How to request/approve/implement/validate/rollback.
4. Change records
   • Tickets, approvals, and configuration diffs for a sample of changes.
5. System-generated proof
   • Screenshots or exports showing audit settings at each level.
6. Review evidence
   • Periodic review notes confirming the mechanism still works and is used appropriately.
7. Mapping to control ownership
   • Named control owner and recurring evidence cadence (a common gap in practice). ²

Daydream fit (earned mention): teams often fail AU-6(10) because evidence is scattered across SIEM, cloud consoles, and tickets. Daydream can centralize control ownership, procedures, and recurring evidence requests so you can produce an assessor-ready packet without rework.

Common exam/audit questions and hangups

Expect these questions (and prep the exact artifacts above):

• “Show me your defined audit levels and what changes between them.”
• “Who can change logging verbosity in production? How is access approved and reviewed?”
• “Give me an example where you increased audit logging due to an event, and show the ticket plus the config change.”
• “How do you prevent someone from turning logging down to hide activity?”
• “What’s your rollback procedure, and how do you validate logs after changes?”
• “How do you handle increased collection of sensitive fields during elevated logging?”

Hangups that slow audits:

• No formal definition of audit levels; only tribal knowledge.
• Changes made directly in consoles with no ticket and no captured diffs.
• Elevated logging breaks pipelines, so teams avoid doing it.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: One “global toggle” with no scope definition.
   Fix: define levels per platform and per data source, not just “on/off.”

2. Mistake: Elevating logs requires broad admin permissions.
   Fix: create controlled logging profiles and delegate only what’s needed to apply them.

3. Mistake: No record that a change happened.
   Fix: require a ticket and export/screenshot the setting change plus a config diff.

4. Mistake: Elevated logs create privacy exposure.
   Fix: document which fields become available at elevated levels and require approval that includes privacy review where applicable.

5. Mistake: “We could do it if we needed to,” but you never do.
   Fix: schedule a tabletop or operational drill where you raise audit levels for a benign test event and retain the evidence.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific cases.

Risk-wise, AU-6(10) gaps show up as:

• Inability to reconstruct attack paths during incidents.
• Over-collection in steady state because teams fear losing visibility, which increases cost and data handling risk.
• Under-collection because “baseline” is too minimal, forcing guesswork during investigations.

A practical 30/60/90-day execution plan

First 30 days (foundation)

• Name a control owner and backups for AU-6(10).
• Inventory current log sources and identify where “audit level” settings exist.
• Draft audit level definitions (baseline/elevated/emergency) and map each to specific source settings.
• Decide the change path: ticketing + pipeline/config management or controlled console changes with mandatory evidence capture.

Days 31–60 (mechanism + governance)

• Implement RBAC for audit level changes and remove informal admin access.
• Publish the runbook: triggers, approvals, implementation steps, validation, rollback.
• Add required fields to the change ticket template (trigger, scope, duration/rollback condition, validation results).
• Run a test: elevate logging for a non-production environment or a controlled production window; retain the full evidence packet.

Days 61–90 (operationalize)

• Integrate with incident response: IR playbooks include “raise audit level” steps.
• Add a recurring review: verify authorized access list, confirm profiles still match your environment, sample test a level change.
• Build an assessor packet in Daydream (or your GRC system): control narrative, runbook, sample tickets, RBAC evidence, and validation outputs.

Frequently Asked Questions

What counts as an “audit level” for AU-6(10)?

A defined, repeatable logging profile that changes specific sources, event categories, or verbosity in a controlled way. Assessors want it written down and tied to technical settings, not an informal “we log more during incidents.”

Do we need to support both increasing and decreasing logging?

You need a governed ability to adjust audit levels. In practice, increasing logging during elevated risk is the common focus, but you should also control reductions so nobody can suppress audit trails without approval and traceability.

Can we meet AU-6(10) if we only change settings in the cloud console?

Yes, if you control access, require tickets/approvals, capture the exact configuration delta, and validate after the change. Console-only changes fail when they are undocumented or performed by overly broad admin roles.

How do we prove an audit level change happened?

Keep the change ticket, approval, and a time-stamped export or screenshot of the before/after settings, plus a configuration diff where possible. Add validation evidence showing logs flowed to your central logging destination.

How does AU-6(10) interact with incident response?

Treat “raise audit level” as a standard IR action, with pre-approved triggers and a runbook. That removes debate during an incident and improves your ability to reconstruct events.

Our teams worry elevated logging will increase sensitive data collection. What do we do?

Document which additional fields appear at elevated levels and add an approval checkpoint for privacy/data handling. Also restrict access to elevated logs and time-box the elevated setting with a clear rollback condition.

Footnotes

1. NIST SP 800-53 Rev. 5

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