AU-9(6): Read-only Access

AU-9(6) requires you to formally authorize read-only access to audit information for a defined, limited subset of privileged roles, and to prevent everyone else (including admins who don’t need it) from modifying, deleting, or re-writing audit evidence. Operationalize it by defining eligible roles, enforcing read-only permissions in your logging/SIEM platforms, and retaining reviewable evidence of access approvals and current entitlements.

Key takeaways:

• Define which privileged roles can view audit logs and metadata, then explicitly approve that access.
• Enforce read-only permissions technically (RBAC, immutable storage controls) and validate with periodic access reviews.
• Keep an audit-evidence bundle: role definitions, approvals, entitlement exports, and configuration screenshots or policy-as-code outputs.

AU-9(6) sits inside the NIST SP 800-53 Audit and Accountability (AU) family and targets a common failure mode: treating audit data like any other operational dataset. Audit information is evidence. If too many people can edit it, you lose the ability to rely on it for incident response, internal investigations, eDiscovery, customer assurance, and formal assessments.

For a Compliance Officer, CCO, or GRC lead, the practical goal is simple: ensure the people who need to see audit data can see it, but they can’t change it, and you can prove both facts quickly during an exam. That means you need (1) an explicit authorization decision for who gets read-only audit access, (2) technical enforcement in the systems that store and analyze logs, and (3) repeatable evidence that the control is operating over time.

This page gives requirement-level implementation guidance for AU-9(6) and a concrete operating model you can hand to Security Operations, IAM, and platform owners without turning it into a months-long policy exercise.

Regulatory text

Requirement (AU-9(6)): “Authorize read-only access to audit information to [subset of privileged users or roles].” ¹

What the operator must do

You must do three things that auditors will treat as separate checkpoints:

1. Name the subset: define the privileged roles (not individual people as your primary construct) that require access to audit information.
2. Authorize access: record an approval decision that those roles are allowed read-only access to audit information.
3. Make it real in systems: implement permissions so those roles can view/export/query logs as needed but cannot modify, delete, suppress, or rewrite audit information.

AU-9(6) is not satisfied by “admins can access logs.” It expects you to deliberately constrain and document who can access audit evidence and to enforce read-only as a permission boundary. ²

Plain-English interpretation

Audit information includes security logs, audit trails, SIEM events, identity and access logs, administrative activity logs, and audit metadata (timestamps, source identifiers, integrity checks). AU-9(6) means:

• Most privileged users should not have edit rights to audit logs.
• A smaller set of privileged roles may have view-only rights so they can do monitoring, detection engineering, investigations, and compliance reporting.
• Any access above read-only (delete, modify, disable logging, alter retention, change parsing rules without controls) is a separate risk decision and should be treated as an exception with compensating controls.

If your environment allows someone to cover their tracks by editing logs, your incident investigation can become a trust debate instead of a fact-finding exercise.

Who it applies to

AU-9(6) applies wherever you manage systems aligned to NIST SP 800-53, including:

• Federal information systems and
• Contractor systems handling federal data ¹

Operationally, it applies to:

• SIEM and log analytics platforms (for example, Splunk, Sentinel, Elastic, Chronicle)
• Cloud-native logging stacks (AWS CloudTrail/CloudWatch Logs, Azure Activity Logs/Log Analytics, GCP Cloud Logging)
• EDR/XDR consoles where audit trails are stored
• IAM and PAM systems that generate and store audit data
• Central log archives and object storage buckets used for retention

It also applies to third parties if they host, operate, or can access your audit data (managed SOC, MSSP, hosted SIEM). Treat them as part of the access scope.

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

1) Define “audit information” in scope (tight, system-mapped)

Create a short inventory that maps:

• Systems that generate audit events (cloud control planes, IAM, endpoints, core apps)
• Systems that store/aggregate audit information (SIEM, log archive, ticketing links)
• Systems that administer the logging pipeline (collectors, agents, forwarders)

Deliverable: “Audit Information Data Map” (one page is fine).

2) Define the authorized read-only roles (role-first, not person-first)

Document a role list such as:

• SOC Analyst (Tier 1/2): read-only search + export
• Detection Engineer: read-only search + rule authoring in separate controlled area
• Incident Responder: read-only search + case export
• Internal Audit / Compliance: read-only reporting views
• Platform Reliability (limited): read-only for troubleshooting ingestion, not retention changes

Be explicit about who is not in the subset by default (for example, general SysAdmin, DevOps, app developers) unless you have a justified need.

Deliverable: “AU-9(6) Authorized Roles Matrix.”

3) Implement RBAC that enforces read-only in each log system

For each system that stores audit info:

• Create dedicated RBAC roles (or groups) that have view/query/export but no delete/modify privileges.
• Remove “god mode” access for day-to-day users. Use PAM/JIT elevation for rare admin functions that affect logging.
• Where the platform supports it, separate:
  • Content admin (parsing rules, dashboards)
  • Ingestion admin (forwarders, connectors)
  • Retention/admin (index lifecycle, bucket policies)
  • Read-only analyst (query and export)

Deliverable: screenshots or policy-as-code showing the permissions granted.

4) Put “audit admin” actions behind change control and break-glass

AU-9(6) is read-only authorization, but you will still have a small set of people who can administer logging systems. Control that with:

• Break-glass accounts stored in PAM
• JIT elevation with ticket reference
• Approval workflow for retention changes, disabling sources, index deletion, and pipeline edits

Deliverable: “Logging Administrative Actions” change-control SOP and a sample approved change.

5) Authorize access formally (and make the authorization reviewable)

Authorization can be a control card plus an approval record:

• Control owner: Security Operations or Security Engineering
• Approver: CISO delegate / control owner + Compliance sign-off (your governance call)
• Trigger events: new SIEM, new business unit, onboarding/offboarding, role changes, tool migration

If you use Daydream to manage your control library, capture AU-9(6) as a requirement control card with owner, triggers, execution steps, and exceptions. That turns “we do RBAC” into an auditable control you can test repeatedly.

Deliverable: approved control card + access approval artifact (ticket/workflow export).

6) Validate with recurring access reviews and control health checks

At a cadence you can sustain:

• Export current group membership and role bindings for each logging platform
• Confirm members match the authorized roles matrix
• Confirm “read-only” roles still cannot delete/alter audit data (spot-check permissions)
• Track exceptions to closure with due dates

Deliverable: access review workbook + remediation tickets + closure evidence.

Required evidence and artifacts to retain

Keep an “AU-9(6) evidence bundle” that an auditor can consume in minutes:

1. AU-9(6) control card / runbook (objective, owner, triggers, steps, exceptions)
2. Authorized Roles Matrix (which roles are approved for read-only audit access and why)
3. System-to-role mapping (which groups/roles in each tool implement the matrix)
4. Access approval records (tickets, workflow approvals, or GRC attestations)
5. Entitlement exports (current membership for relevant groups; timestamped)
6. Configuration evidence (RBAC screenshots, IAM policy JSON, Terraform snippets)
7. Periodic review results (completed access review, findings, remediation tracking)

Store evidence in a location with controlled access and retention aligned to your audit/log retention policy.

Common exam/audit questions and hangups

Expect these questions:

• “Show me who can access audit logs today. Is it read-only?”
  Hangup: teams show a policy but can’t produce current entitlements.

• “How do you prevent administrators from altering audit evidence?”
  Hangup: SIEM admins have delete/index management rights without oversight.

• “What’s your definition of ‘audit information’ and where is it stored?”
  Hangup: logs exist across cloud consoles, SIEM, and buckets; no single map.

• “What happens when you onboard a new SOC analyst or change roles?”
  Hangup: no documented trigger-to-authorization process.

• “Do third parties have access to your audit information? Under what permissions?”
  Hangup: MSSP has broad admin access “for support.”

Frequent implementation mistakes and how to avoid them

Mistake 1: Treating “read-only” as “can’t edit dashboards”

Many platforms allow “read-only UI access” while still permitting destructive API actions via inherited permissions.
Avoidance: validate via permission listing or a controlled test account. Confirm no delete, retention, or pipeline-modification rights.

Mistake 2: Leaving audit logs in the same admin domain as the systems being audited

If the same admin group that runs production can delete the logs that record their actions, your audit trail is weak.
Avoidance: split duties. Make read-only access common, admin access rare and controlled.

Mistake 3: No explicit authorization record

Auditors read AU-9(6) as an authorization requirement, not just a technical setting.
Avoidance: keep an approval artifact for the role subset and changes to it.

Mistake 4: Forgetting log archives and object storage

Teams lock down the SIEM but leave the underlying bucket writable by broad engineering roles.
Avoidance: include storage and retention layers in your audit information map and RBAC design.

Mistake 5: Exceptions become the norm

If everyone is an “exception,” the control is effectively not operating.
Avoidance: time-box exceptions, require compensating controls, and track closure.

Risk implications (what can go wrong)

If audit information is not read-only for the approved subset, you face:

• Integrity risk: audit evidence can be altered or deleted.
• Investigation risk: incident response conclusions become disputed.
• Assurance risk: external assessors may scope deeper testing or issue findings tied to audit/logging controls.
• Third-party risk: a managed provider with broad access can become a single point of failure for audit evidence integrity.

AU-9(6) is a “trust anchor” control. When it fails, downstream controls (IR, detection, accountability) become harder to defend.

Practical 30/60/90-day execution plan

First 30 days (get to a defensible baseline)

• Assign a control owner and back-up owner for AU-9(6).
• Draft the Audit Information Data Map (systems that store audit info).
• Define the initial Authorized Roles Matrix (keep it small).
• Implement read-only groups in your primary SIEM and cloud logging consoles.
• Create the evidence bundle structure (folders, naming, retention location).

Next 60 days (close the gaps and make it repeatable)

• Extend RBAC controls to log archives and storage backends.
• Put logging admin permissions behind PAM/JIT and change control.
• Document the runbook: onboarding/offboarding triggers, approval steps, exception path.
• Run your first access review and remediate over-entitled users.

By 90 days (operate it like a control, not a project)

• Run a second access review to prove repeatability.
• Add control health checks: sample permission tests, configuration drift checks.
• Formalize third-party access boundaries (MSSP, managed SIEM) and align contracts/SOWs to read-only where feasible.
• If you manage controls in Daydream, connect AU-9(6) evidence requests to your review cadence so owners get automatic prompts and auditors get a clean packet.

Frequently Asked Questions

Does AU-9(6) mean nobody can ever administer the SIEM or logging pipeline?

No. It means you must authorize read-only access for a defined subset, and you should tightly control any non-read-only admin capabilities through separate roles, approvals, and oversight. Keep admin rights rare and provable.

What counts as “audit information” for AU-9(6)?

Treat audit information as logs and audit trails plus supporting metadata stored in your SIEM, cloud logging, EDR/XDR consoles, and log archives. Your best defense is a simple inventory that maps each storage location to its access model.

We use an MSSP. Can they have access under AU-9(6)?

Yes, but you should scope the MSSP to read-only access for monitoring and investigation where possible, and tightly control any administrative actions through named accounts, PAM/JIT, and change control. Retain evidence of their permissions and approvals like you would for employees.

Is exporting logs considered “read-only”?

Usually yes, if export does not alter, delete, or overwrite the underlying audit records. Control where exports can be stored and who can access exported data, because exports can become a secondary evidence system.

How do we prove “read-only” in an audit without doing a live destructive test?

Provide role definitions and permission listings from the tool (or policy-as-code) that show the absence of delete/modify rights, plus entitlement exports showing who is assigned to those roles. Pair that with your access review results.

What’s the minimum evidence an auditor will accept for AU-9(6)?

A role matrix, an approval record for the authorized subset, current entitlement exports, and configuration evidence that those entitlements are read-only in the systems that store audit information. Add periodic review evidence to show sustained operation.

Footnotes

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

2. NIST SP 800-53 Rev. 5 DOI