AU-6(10): Audit Level Adjustment

AU-6(10) Audit Level Adjustment requires you to be able to raise (and, where appropriate, lower) audit logging levels quickly in response to elevated risk, threats, or investigative needs, without breaking systems or drowning teams in noise. Operationalize it by predefining “audit levels,” triggers, approvers, technical mechanisms, and a reversible change workflow with retained evidence. ¹

Key takeaways:

• Define audit “levels” (baseline, heightened, emergency) and map each level to concrete log sources, event types, and retention.
• Implement a controlled, time-bound workflow to change logging levels with approvals, monitoring impact checks, and rollback.
• Keep evidence that proves the capability works: configurations, change records, trigger rationale, and post-change validation results.

AU-6(10): Audit Level Adjustment is a deceptively operational control. It is not satisfied by having logs “on.” Examiners and assessors look for proof that you can change audit verbosity and coverage intentionally when risk changes, then return to normal without losing integrity or availability. That means you need (1) predefined audit levels, (2) technical controls to apply those levels consistently across systems, and (3) a documented process that is fast enough for incident response but still governed.

This requirement shows up most often during incident response, insider threat investigations, suspected account compromise, and production changes that increase the attack surface. It also appears during customer diligence for federal-aligned programs and any environment mapped to NIST SP 800-53 Rev. 5. ²

If you are a CCO, GRC lead, or compliance owner, your job is to translate AU-6(10) into a runbook: who can request an audit level change, who approves, what exactly changes in the logging pipeline, what safety checks prevent outages or runaway costs, and what evidence you can produce on demand. This page gives you that runbook structure.

Regulatory text

Control reference: AU-6(10): Audit Level Adjustment ¹

Provided excerpt: “NIST SP 800-53 control AU-6.10.” ¹

Operator meaning (what you must do):
Because the provided excerpt is an identifier rather than full control language, operationalization should align to the control’s stated intent in NIST SP 800-53 Rev. 5: maintain the ability to adjust audit logging levels to support monitoring, detection, and investigation as conditions change. Build an auditable capability to:

• Increase audit detail/coverage quickly when risk is elevated (for example, suspected compromise, high-risk change windows).
• Apply changes consistently across relevant systems and log sources.
• Keep the change governed (authorized, time-bound, reversible).
• Validate that the new level is producing the intended telemetry and that storage/throughput impacts are controlled. ²

Plain-English interpretation (requirement-level)

AU-6(10) expects a tiered logging posture. You run at a baseline audit level day-to-day, but you can switch to a higher level under defined conditions. “Higher” must be concrete: more event types, lower thresholds, more detailed fields, more systems, tighter correlation rules, or faster forwarding. You also need a path to step back down once the situation stabilizes.

Assessors typically want evidence of two things:

1. Design: You defined levels and triggers ahead of time (not invented during an incident).
2. Operation: You have executed the process (tabletop, test, or real event) and can show change records and resulting telemetry.

Who it applies to (entity and operational context)

Entities

• Federal information systems and programs mapped to NIST SP 800-53 Rev. 5.
• Contractors and service providers handling federal data where NIST 800-53 controls are flowed down contractually. ²

Operational context

• Central logging/SIEM environments, managed detection programs, SOC operations.
• Identity platforms (SSO/MFA), privileged access, key management, cloud control planes, and production workloads where audit trails matter.
• Incident response workflows, insider threat investigations, and high-risk change management windows.

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

Step 1: Create an AU-6(10) control card (owner, scope, triggers)

Write a one-page control card that a SOC lead and an auditor can both follow. Include:

• Control owner: usually Security Operations; co-owners in Cloud/Platform and GRC.
• In-scope systems: SIEM, log forwarders/agents, cloud audit logs, IAM logs, endpoint telemetry, key admin logs.
• Trigger events: define what causes an increase (incident declared, threat intel indicates active exploitation, privileged account anomaly, high-risk deployment, legal hold).
• Exception rules: systems where you cannot increase logging due to performance constraints; require documented compensating controls.

This directly addresses a common risk factor: teams cannot show ownership, cadence, or evidence. ¹

Step 2: Define audit “levels” as enforceable configurations

Define 3–4 levels with precise technical settings. Example structure:

Audit level	Use case	What changes	Guardrails
Baseline	Normal operations	Standard audit sources enabled; standard parsing/correlation	Normal retention and cost profile
Heightened	Credible threat / investigation	Add high-value data sources; increase verbosity on authentication/admin events; expand detections	Monitor ingestion/storage; confirm no PII over-collection beyond policy
Emergency	Active incident / containment	Maximum feasible detail on impacted systems; shorter forwarding latency; temporary targeted logging on suspected hosts/accounts	Time-box; require incident commander approval; rollback plan

Make each “what changes” item link to an actual config artifact: SIEM connector toggles, CloudTrail/Azure activity log settings, Okta/Entra audit event coverage, EDR policy, database audit flags, application audit feature flags.

Step 3: Build the technical mechanism to switch levels safely

Pick a mechanism you can execute quickly and consistently:

• Infrastructure-as-Code / policy-as-code: version-controlled logging settings per environment.
• Centralized SIEM content packs: rule sets and parsing updates tied to an “incident mode.”
• Endpoint/agent policy profiles: baseline vs heightened policy in EDR.
• Feature flags for app audit events: prebuilt toggles for sensitive transactions.

Safety requirements you should engineer in:

• Rollback is defined and tested.
• Time-bound elevation: the request includes a planned end time and review checkpoint.
• Monitoring for impact: ingestion rate, pipeline lag, storage alarms, and downstream alert volume.

Step 4: Add governance: request → approve → implement → validate → revert

Treat audit level adjustment as a controlled change that can be executed on an expedited path.

Minimum workflow:

1. Request (SOC, IR lead, or IAM lead): states trigger, scope, desired level, and duration.
2. Approval (incident commander / security management; involve privacy if expanded fields include personal data).
3. Implementation (platform/logging engineer or on-call SRE): applies changes via the defined mechanism.
4. Validation (SOC): verifies expected event types are arriving, timestamps are correct, correlation works, and alerts behave.
5. Reversion (same workflow): revert to baseline and confirm.

If you use Daydream as your GRC system of record, store the control card, the workflow template, and the evidence bundle in one place and link each execution to the AU-6(10) requirement. That reduces audit prep time and prevents “lost in Slack” approvals.

Step 5: Prove it works with a scheduled test

If you have not had a real incident, run a controlled test:

• Pick one production-like environment.
• Execute the workflow to move from baseline to heightened for a defined scenario.
• Capture evidence (change ticket, screenshots/config diffs, SIEM queries showing new event types).
• Document rollback and the validation outcome.

Step 6: Run control health checks and track remediation

Create a recurring control health check that answers:

• Can we still switch levels on all in-scope systems after platform changes?
• Do connectors and parsers still work?
• Are ingestion/storage guardrails tuned?

Track gaps to closure with owners and due dates. ¹

Required evidence and artifacts to retain

Keep evidence that demonstrates both design and operation:

Design artifacts

• AU-6(10) control card: objective, owner, scope, triggers, exception rules. ¹
• Audit level definitions (baseline/heightened/emergency) with a mapping to log sources and event categories.
• Approved runbook for level change execution and rollback.
• Architecture diagram of logging pipeline (sources → forwarders → SIEM → storage).

Operational evidence ¹

• Request/approval record (ticket, IR record, or change record).
• Configuration diffs or screenshots showing logging policy changes.
• Validation output: SIEM queries, dashboards, sample events, alert tuning notes.
• Reversion record and post-event review notes.
• Evidence retention location and retention period statement (where it’s stored, who can access it). ¹

Common exam/audit questions and hangups

Assessors tend to probe for these specifics:

• “Show me your defined audit levels. What exactly changes?”
• “Who can authorize elevated logging, and under what triggers?”
• “Demonstrate you can do this across cloud control plane logs, IAM, and endpoints.”
• “How do you prevent a cost/performance blowup when you increase verbosity?”
• “Show evidence of a recent execution or a test, including rollback.”

Hangups that slow teams down:

• Logging changes are ad hoc and undocumented.
• No one owns the logging pipeline end-to-end.
• Increased logging collects sensitive fields without review.
• The SIEM receives more logs but detections are not adjusted, so signal quality collapses.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: “Heightened logging” is vague.
   Fix: express each level as an explicit checklist of sources, event types, and fields. Tie it to configs.

2. Mistake: Changes happen only in the SIEM, not at the source.
   Fix: for key systems, enable source-side audit events (cloud audit logs, IAM audit, database audit). SIEM-only tuning cannot capture events that never got emitted.

3. Mistake: No rollback criteria.
   Fix: require a time-box and an explicit “revert to baseline” task in the incident/change workflow.

4. Mistake: Elevated logging breaks pipelines.
   Fix: pre-stage guardrails (ingestion alarms, storage thresholds, queue depth alerts) and test at least once.

5. Mistake: Evidence is scattered.
   Fix: define a minimum evidence bundle and a single retention location. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-6(10), so this page does not cite enforcement outcomes.

Practically, the risk of weak AU-6(10) execution is operational: during an incident you may be unable to reconstruct actions, establish timelines, or attribute activity to users/hosts. That increases containment time, weakens internal investigations, and can complicate contractual or program compliance attestations tied to NIST SP 800-53. ²

Practical 30/60/90-day execution plan

First 30 days (establish the capability)

• Name the AU-6(10) owner and publish the control card (scope, triggers, approvals, exceptions). ¹
• Inventory audit log sources that matter most (cloud control plane, IAM, EDR, key admin, critical apps).
• Define audit levels and map each to specific settings and systems.
• Draft the expedited workflow and identify approvers (SOC lead, incident commander, privacy review path).

Days 31–60 (implement and connect it to operations)

• Implement the mechanism to switch levels (IaC, policy profiles, SIEM content packs).
• Add pipeline guardrails: ingestion/storage monitoring and alert-volume checks.
• Train SOC/on-call teams on the runbook and approval path.
• Define the evidence bundle and store templates in your system of record (Daydream or equivalent). ¹

Days 61–90 (prove operation and harden)

• Run a controlled test of baseline → heightened → baseline; retain full evidence.
• Tune detection logic for heightened mode to manage alert fatigue.
• Add a recurring health check and remediation tracking for drift and new systems. ¹
• Document any exceptions and compensating controls; get them approved.

Frequently Asked Questions

Do we have to support multiple audit levels for every system?

Scope it to systems where audit trails are material (cloud control plane, IAM, endpoints, critical apps). If a system cannot support adjustment, document the exception and compensating controls in the control card.

What counts as “adjustment” in practice?

Any controlled change that increases or decreases audit coverage or verbosity: enabling additional event categories, adding data sources, increasing detail in admin/auth logs, or tightening SIEM correlation and alerting tied to audit events.

Can incident response declare elevated logging without a formal change ticket?

Yes, if you define an expedited emergency workflow with clear approvers and evidence capture. Auditors accept speed when governance exists and you retain the request/approval and validation artifacts.

How do we prevent cost and performance issues when we increase logging?

Build guardrails into the runbook: monitor ingestion rate, pipeline latency, and storage thresholds, and time-box the elevated mode. Prefer targeted elevation (specific hosts/accounts/services) during investigations.

What evidence do auditors ask for most often?

They typically want the level definitions, the runbook, and proof you executed it at least once (test or real event): approvals, config diffs, and SIEM validation queries stored in a durable location.

We outsource the SOC. Who owns AU-6(10)?

You still own the control. The third party can execute parts of the workflow, but you need contractual clarity on who can request/approve changes, how evidence is delivered, and how quickly level changes are applied.

Footnotes

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

2. NIST SP 800-53 Rev. 5