AU-6(7): Permitted Actions

AU-6(7) is a deceptively narrow requirement with a broad blast radius. You can be strong on logging (AU family) and still fail AU-6(7) if you can’t answer a basic exam question: “Exactly what is each person allowed to do to audit records while performing review, analysis, and reporting?” The control is not asking you to log more events. It is asking you to constrain and document actions taken on audit record information so log reviewers can do their job without being able to tamper with the evidence they are supposed to evaluate.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to turn AU-6(7) into two artifacts and one enforcement mechanism: (1) a role-based permitted-actions matrix for audit-log handling, (2) a configuration-to-evidence bundle tied to your SIEM/log management stack, and (3) a recurring validation routine that proves permissions stayed correct over time. This page gives you a requirement-level runbook you can assign to Security Operations, IAM, and platform owners and then defend during audits and customer due diligence.

Regulatory text

Requirement (AU-6(7): Permitted Actions): “Specify the permitted actions for each [one or more of: system process; role; user] associated with the review, analysis, and reporting of audit record information.” ¹

What the operator must do

You must do two things, and auditors will look for both:

1. Specify (document) permitted actions for the actors that touch audit records for review/analysis/reporting. Actors can be defined by system process, role, and/or user; most programs use roles plus a small number of privileged users for exceptions. ¹

2. Make the specification real by implementing permissions in the systems where audit records are accessed and worked (SIEM, log storage, SOAR, ticketing attachments, cloud logging consoles). If the matrix says “read-only,” your SIEM role cannot have “delete index,” “edit retention,” or “stop ingestion” privileges.

Plain-English interpretation (what AU-6(7) means)

AU-6(7) is about controlling log-handling actions so the people (and automated processes) who review logs can investigate and report without being able to improperly alter, delete, or suppress audit evidence.

Think of it as: “Define and enforce what log reviewers can do.” For most environments, permitted actions break into four buckets:

• Read / search / view (normal SOC work)
• Analyze / enrich (tagging, adding notes, creating detections, creating cases)
• Report / export (dashboards, scheduled reports, controlled exports)
• Admin / modify pipeline (ingestion rules, retention, deletion, index management, parser changes)

AU-6(7) pushes you to keep these buckets separated, explicitly assigned, and reviewable.

Who it applies to

Entity scope

• Federal information systems and organizations implementing NIST SP 800-53 Rev. 5 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 controls are flowed down contractually or via an authorization boundary. ²

Operational scope (what systems and teams)

Applies anywhere audit record information is reviewed, analyzed, or reported, including:

• SIEM and log analytics platforms
• Central log storage (cloud object storage, logging data lakes)
• Endpoint/network/security tools that provide audit logs and allow log export
• SOAR/case management platforms if they store log excerpts or artifacts
• IAM systems governing access to these tools

Teams typically involved:

• SOC / SecOps (log review)
• Detection engineering (content development)
• IAM (roles, access requests, recertifications)
• Platform/cloud security (logging pipeline owners)
• GRC (control owner, evidence and testing)

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

Step 1: Define the “audit record handling” population

Create an inventory of:

• Tools where audit records live (SIEM, cloud logging, EDR consoles, storage buckets)
• Roles/users/service accounts that can access those records
• Interfaces used (UI, API tokens, service principals)

Output: Audit Log Handling Inventory (system list + access points).

Step 2: Build a permitted-actions matrix (the core AU-6(7) artifact)

Create a table with roles (or processes) on the left and permitted actions on the top. Keep it concrete and tool-relevant.

Minimum columns to include:

• View/search logs
• Create/modify detections or queries
• Add annotations/tags
• Export data (with constraints)
• Manage retention
• Delete data
• Modify ingestion/parsing
• Manage user access/roles
• Approve access requests
• Break-glass use allowed (Y/N) and conditions

Example matrix (simplified):

Role / process	View/search	Annotate	Export	Modify detections	Modify ingestion	Delete/retention admin	Manage access
SOC Analyst	Yes	Yes	Limited (case-by-case)	No	No	No	No
Detection Engineer	Yes	Yes	Limited	Yes (content only)	No	No	No
SIEM Platform Admin	Yes	Limited	Controlled	Yes	Yes	No (separate role)	No
Log Storage Admin	No (default)	No	No	No	No	Yes (retention only)	No
IAM Admin	No	No	No	No	No	No	Yes (role grants only)
Automated alerting process	Yes (API)	N/A	No	N/A	No	No	No

Your matrix is your “specification.” It must be approved and owned.

Step 3: Translate the matrix into enforced RBAC in each tool

For each system in scope:

• Map matrix roles to tool roles (native RBAC groups, IAM roles, custom roles).
• Remove privileges that exceed permitted actions (common offenders: delete indexes, stop collection, edit retention).
• For exports, implement guardrails: approval workflow, limited formats, secure destinations, and logging of export actions.

Output: RBAC mapping worksheet + screenshots/config exports showing role permissions.

Step 4: Control access requests and changes

Implement a standard access workflow:

• Request includes business justification and manager approval.
• GRC/SecOps validates role selection against the matrix.
• IAM provisions to the correct group/role.
• Exceptions require documented approval and expiry.

Trigger events to cover:

• Joiner/mover/leaver
• Tool onboarding or migration
• Incident requiring expanded access
• Role redesign (SOC tiers, MSSP onboarding)

Step 5: Add compensating controls for break-glass and privileged admin work

Some actions will be needed rarely (e.g., retention changes during storage events, emergency ingestion fixes). Handle them with:

• Break-glass accounts with MFA, short-lived access, and ticket linkage
• Time-bound elevation (PAM where available)
• Mandatory logging and post-use review

Step 6: Test and monitor the control (prove it works)

Create a recurring “control health check”:

• Sample users in each role and confirm tool permissions match the matrix.
• Verify no one has both “log reviewer” and “log deletion/retention admin” without an approved exception.
• Verify service accounts are scoped and rotated per your standard.

If you use Daydream, treat this as a requirement control card and evidence bundle that’s scheduled and assignable, so you can produce the matrix, mappings, and validation results quickly during audits.

Required evidence and artifacts to retain

Auditors usually want design evidence (what you intended) plus operating evidence (proof it ran).

Retain:

• Requirement control card / runbook: objective, owner, scope, triggers, steps, exceptions, and how often you validate.
• Permitted-actions matrix approved by control owner (and ideally SecOps/IAM sign-off).
• System-to-role mapping (SIEM roles, cloud IAM roles, groups).
• Access request samples showing approvals and correct role assignment.
• Role/permission configuration exports or screenshots from each in-scope tool.
• Exception register (who, what elevated actions, why, approval, expiry, review results).
• Periodic validation results: test script, sampling list, findings, remediation tickets, closure evidence.

Common exam/audit questions and hangups

Expect questions like:

• “Who can delete audit logs or change retention settings?”
• “Who can stop log ingestion or modify parsing rules?”
• “Show me the documented permitted actions for SOC analysts versus SIEM admins.”
• “How do you prevent a log reviewer from altering the evidence they review?”
• “How do you handle emergency access, and where is it reviewed?”
• “Do service accounts have broader permissions than humans? Why?”

Hangups that cause findings:

• You have RBAC configured, but no written specification that ties permissions to review/analysis/reporting responsibilities.
• Your “SIEM Admin” role has bundled privileges that include retention/deletion without a compensating control.
• Exports are uncontrolled (any analyst can export large datasets to local machines) with no approval or monitoring.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating AU-6(7) as “logging exists.”
   Fix: Keep the scope tight: permitted actions for log review/analysis/reporting. Build the matrix and map it to permissions.

2. Mistake: One mega-role (SOC can do everything).
   Fix: Split “review and investigate” from “administer pipeline and retention.” Use separate roles and require break-glass for rare admin actions.

3. Mistake: Forgetting system processes and API tokens.
   Fix: Include service principals, integrations, and scheduled jobs in the matrix. Constrain API scopes the same way you constrain human roles.

4. Mistake: No operating cadence.
   Fix: Run recurring checks and tie them to evidence retention. Without operating evidence, your matrix reads like a policy statement.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite any. Practically, AU-6(7) failures tend to surface during:

• Authorization/ATO work and annual assessments
• Incident investigations when log integrity is questioned
• Customer diligence where prospects ask who can delete logs or alter retention

Risk implications are straightforward: if the same people who investigate incidents can also delete or suppress audit records, you weaken detective controls and complicate incident response and legal defensibility.

Practical 30/60/90-day execution plan

First 30 days (stabilize and document)

• Name an owner (usually SecOps + IAM + GRC collaboration).
• Inventory systems and actors that touch audit records.
• Draft the permitted-actions matrix and get approvals.
• Identify and document current “too-broad” roles as remediation items.

Days 31–60 (enforce and align tooling)

• Implement RBAC changes in SIEM/log platforms to match the matrix.
• Add export guardrails (approvals, secure destinations, export logging).
• Stand up break-glass and exception workflows with expiry and review steps.
• Write the evidence bundle checklist and store it in a single location.

Days 61–90 (operate and prove)

• Run the first control health check (sampling + findings + remediation).
• Close the highest-risk permission gaps (delete/retention/ingestion privileges).
• Operationalize joiner/mover/leaver triggers tied to the matrix.
• Prepare an audit-ready packet (matrix, mappings, samples, and validation results) you can regenerate on demand in Daydream.

Frequently Asked Questions

Does AU-6(7) require least privilege?

AU-6(7) explicitly requires you to specify permitted actions for log review/analysis/reporting, which is how least privilege becomes testable for this function ¹. Auditors typically expect permissions to match your specification without extra admin capabilities.

Do I have to define permitted actions by user, or is role-based enough?

The control allows you to specify by system process, role, and/or user ¹. Role-based is usually sufficient, with named-user entries for exceptions such as break-glass custodians.

What counts as “reporting of audit record information” in practice?

Scheduled dashboards, emailed reports, ticket attachments containing log excerpts, and ad-hoc exports used for incident reporting all fall into “reporting.” If someone can publish or export audit-derived information, define and control what they are allowed to do.

Our SIEM admins need powerful access. How do we pass AU-6(7)?

Keep “platform administration” separate from “audit review,” and define permitted actions for both roles. Then constrain destructive actions (deletion/retention/ingestion stops) behind break-glass with ticketed approvals and after-action review.

Do service accounts and integrations fall under AU-6(7)?

Yes if they review, analyze, or report audit record information ¹. Treat them like roles: document permitted actions, restrict scopes, and retain evidence of current privileges.

What evidence is fastest to produce during an audit?

The permitted-actions matrix, screenshots/exports of role permissions from the SIEM/log tooling, and a recent access review or validation showing sampled users match the matrix. Bundle these into a repeatable evidence packet so you don’t rebuild it each time.

Footnotes

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

2. NIST SP 800-53 Rev. 5