AU-9(6): Read-only Access

AU-9(6): read-only access requirement means you must explicitly authorize who can view audit logs and related audit records, and ensure those authorized users cannot modify or delete that audit information through their access path. Operationalize it by defining eligible roles, enforcing read-only permissions in every logging tool and storage layer, and retaining proof that access is restricted and reviewed. ¹

Key takeaways:

• You need an authorization decision (who gets read-only access) plus technical enforcement (permissions that prevent modification).
• The control fails most often at the storage layer (object storage, SIEM indexes, database tables) where “viewer” still implies write privileges.
• Evidence wins audits: role mappings, permission screenshots/exports, and access review records tied to log repositories. ²

AU-9 focuses on protecting audit information so logs remain trustworthy for incident response, investigations, and compliance reporting. AU-9(6) narrows that into a simple operator mandate: if someone only needs to read audit information, authorize them as read-only and prevent changes through that access. The point is not to block administrators from managing platforms; it is to prevent routine consumers of logs (developers, analysts, help desk, app owners, third parties supporting operations) from having any ability to alter what the organization may later rely on as evidence.

For a CCO, GRC lead, or Compliance Officer, the fastest way to implement AU-9(6) is to treat audit information as a distinct data class with a defined access model: specific roles, specific systems of record (SIEM, log archive, cloud logging, endpoint logging, audit database tables), and a default rule that “readers can’t write.” Then you validate the control end-to-end: from the SIEM UI to the underlying storage and pipelines.

This page translates the au-9(6): read-only access requirement into concrete steps, artifacts to retain, and audit-ready talking points using NIST SP 800-53 Rev. 5 as the authoritative source. ²

Requirement: AU-9(6) Read-only Access (what it really means)

Plain-English interpretation

You must:

1. decide who is allowed to view audit information, and
2. ensure their access is technically constrained to read-only so they cannot alter, delete, overwrite, or “fix” audit logs through the same privileges.

This applies to audit information broadly: security logs, system logs, application audit trails, admin activity logs, SIEM events, and log archives. “Authorize” means you can point to an approval rule (policy, role standard, ticket workflow, or access control decision record) that governs who can access audit information. ¹

Why auditors care

If a user can modify audit records, you lose integrity. That undermines investigations, incident timelines, eDiscovery holds, and regulatory reporting. AU-9(6) is one of the controls assessors use to test whether logs are treated as evidentiary records rather than just operational telemetry. ²

Regulatory text

“Authorize read-only access to audit information to {{ insert: param, au-09.06_odp }}.” ¹

Operator translation: define the population (the organization-defined parameter) that is allowed to view audit information, then implement access controls so that population’s access path is read-only. In practice, you fill the parameter with role types (for example, Security Operations analysts, auditors, incident responders) and exclude roles that do not need log access by default. ¹

Who it applies to (entity + operational context)

Entities

• Federal information systems implementing NIST SP 800-53 controls.
• Contractor systems handling federal data where NIST SP 800-53 is flowed down contractually. ¹

Operational contexts where AU-9(6) shows up

• SIEM and log analytics platforms (Splunk, Sentinel, Elastic, etc.).
• Cloud-native logging (AWS CloudTrail/CloudWatch Logs, Azure Activity Logs, Google Cloud Logging).
• Endpoint detection and response consoles.
• Centralized syslog, log forwarders, collectors, and message buses.
• Log archives in object storage and immutable storage tiers.
• Database-backed audit trails in business applications (ERP, IAM, HRIS) where audit tables exist.

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

Step 1: Inventory “audit information” systems of record

Create a short list of where audit information lives and where it can be accessed:

• Primary viewing layer (SIEM UI, dashboards, query consoles)
• Storage layer (indexes, buckets, databases, archives)
• Administration layer (platform admin console, API keys, service principals)

Deliverable: “Audit Information Repositories Register” (a table is fine) with owner, platform, environment, and access method.

Step 2: Define authorized read-only populations (the ODP)

Decide and document:

• Allowed roles (job functions) that can read audit information.
• Conditions (on-call only, incident-only, audit window, break-glass).
• Prohibited roles by default (developers without on-call duty, general IT staff, third-party support unless contracted and approved).

Keep this tight. Broad access increases insider risk and makes reviews fail due to sprawl.

Deliverable: “AU-9(6) Authorized Read-Only Roles Standard” with role names and rationale. ¹

Step 3: Implement read-only enforcement at every layer

This is where teams miss the requirement. You need read-only at the UI, API, and storage.

Minimum technical checks:

• SIEM roles: confirm “can search/view” without “can delete events,” “can edit pipelines,” “can manage indexes,” “can change retention,” or “can disable data sources.”
• Cloud logs: confirm the viewer role cannot stop logging, change log sinks, or modify retention settings.
• Object storage archives: ensure read-only principals lack write, delete, lifecycle-management, and versioning changes.
• Databases: ensure read-only roles have SELECT only (no INSERT/UPDATE/DELETE/DDL) on audit tables.

Deliverable: role/permission exports (or screenshots) for each platform showing the read-only role definition and assignments.

Step 4: Separate duties for “log readers” vs “log administrators”

You will have some users who administer logging platforms. That’s normal. AU-9(6) is satisfied by ensuring typical consumers are read-only, and admin privileges are limited, controlled, and monitored.

Practical pattern:

• Reader role: most users.
• Content author role: a small group who can build dashboards/queries but still cannot delete raw events or change retention.
• Platform admin role: very small group; require MFA, privileged access management, and break-glass where possible.

Deliverable: RACI for audit information access (who reads, who administers, who approves).

Step 5: Build an approval and provisioning workflow

“Authorize” means you can show how access is granted:

• Request ticket with business justification and manager approval.
• Security approval (or audit/compliance approval) for new reader access.
• Time-bounded access for third parties and non-standard roles.

Daydream (or any GRC system you already run) becomes useful here because you can map AU-9(6) to a named control owner, attach the access standard, and schedule recurring evidence collection so you do not rebuild this each audit cycle. ²

Step 6: Run access reviews focused on audit information

Set a review cadence that matches your environment risk. The key is consistency and proof:

• Review group membership for “Audit Log Readers.”
• Review any “exceptions” (people with write/admin capabilities).
• Confirm departures and role changes are reflected.

Deliverable: access review sign-off records, remediation tickets, and completion evidence.

Step 7: Test the control like an auditor would

Pick one platform and validate:

• A read-only user cannot delete logs.
• A read-only user cannot alter retention.
• A read-only user cannot disable log sources or collectors.
• API tokens for read-only users cannot perform write actions.

Deliverable: test script + results (screenshots or exported logs of denied actions).

Required evidence and artifacts to retain

Use an evidence pack that maps cleanly to the au-9(6): read-only access requirement:

Evidence item	What it proves	Owner
AU-9(6) access standard (authorized roles + conditions)	“Authorize” decision exists	GRC / Security
Audit Information Repositories Register	Scope completeness	Security Engineering
RBAC exports / role definition screenshots	Read-only is enforced	SIEM/Cloud owners
Group membership export for reader roles	Only authorized users have access	IAM
Access request tickets/approvals	Access was granted via authorization	ITSM / GRC
Access review records + remediation tickets	Ongoing governance	Control owner
Exception register for admin/write access	Controlled deviations	GRC

Common exam/audit questions and hangups

1. “Show me who can access audit logs and what they can do.”
   Have a single export per system: role definitions and role assignments.

2. “Is access read-only all the way down to storage?”
   Expect follow-ups. Auditors often ask about S3 permissions, SIEM index controls, or database privileges.

3. “Who approved these users?”
   If approvals are informal (Slack, email), the control looks weak. Route through your ticketing system and attach approvals.

4. “How do you prevent a reader from modifying log pipelines or parsers?”
   Many tools bundle “content editing” with “admin.” Create custom roles or separate workspaces.

Frequent implementation mistakes (and how to avoid them)

• Mistake: “Viewer” role can still delete or purge data.
  Fix: test destructive actions under a viewer account; remove delete/purge permissions explicitly.

• Mistake: UI is read-only, but API keys can write.
  Fix: review API scopes for service accounts and user tokens tied to log access.

• Mistake: Developers have broad log admin because “they need troubleshooting.”
  Fix: provide read-only search access; use break-glass for rare admin tasks with approvals and monitoring.

• Mistake: No written authorization rule (ODP is undefined).
  Fix: publish a one-page standard listing eligible roles and conditions. ¹

Risk implications (what goes wrong if you miss this)

• Investigation risk: altered logs damage root-cause analysis and containment decisions.
• Regulatory and contractual risk: inability to demonstrate integrity of audit records during assessments.
• Insider threat exposure: a user with write access can cover tracks by editing or deleting events.

Even if you have other AU-9 protections in place, assessors can still write a finding if you cannot show explicit authorization and enforced read-only access for audit information consumers. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and policy)

• Name a control owner for AU-9(6) and identify system owners for each log platform.
• Build the Audit Information Repositories Register.
• Draft and approve the AU-9(6) Authorized Read-Only Roles Standard (the ODP content).
• Pull current role definitions and assignments from the SIEM and cloud logging platforms.

Days 31–60 (fix permissions and separate duties)

• Implement or tighten read-only roles across platforms.
• Remove write/admin permissions from general “reader” groups.
• Create a break-glass path for temporary admin access with documented approval steps.
• Establish the access request workflow in ITSM, and link it to the AU-9(6) standard (Daydream is a clean place to store the mapping and evidence expectations).

Days 61–90 (prove operation and get audit-ready)

• Run an access review cycle for audit information reader groups; remediate exceptions.
• Execute the “auditor test” for at least one representative platform and archive the results.
• Finalize the evidence pack structure and assign recurring evidence owners (exports, screenshots, review sign-offs).
• Add AU-9(6) to your continuous control monitoring calendar so evidence collection is routine, not a scramble.

Frequently Asked Questions

Does AU-9(6) require that no one can ever write or delete audit logs?

No. It requires you to authorize read-only access for the defined population and enforce read-only for that access path. Admin functions can exist, but they should be limited, approved, and separable from general log consumption. ¹

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

Treat any log or audit trail used for security monitoring, incident response, investigations, or compliance evidence as audit information. Scope SIEM events, cloud activity logs, OS logs, application audit tables, and archived logs. ²

Is read-only in the SIEM UI sufficient?

Often no. Confirm permissions at the storage and API layers too, because users may bypass the UI with direct object storage access, index management rights, or API scopes.

How do we handle third-party support engineers who need log access?

Put them into a dedicated read-only role, time-bound the access, and require an approved request ticket. Retain the approval and the deprovisioning record as evidence.

What evidence is fastest to produce during an audit?

A role-to-permission export from each logging platform plus an IAM group membership export for the read-only groups. Pair that with your written authorization standard so the assessor can see both the decision and enforcement. ¹

How should we document the “authorize” part if our access is managed through IAM groups?

Document the rule that governs who can be added to those groups (eligible roles, approvers, and required justification), then retain tickets showing that workflow was followed. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5