AU-6(7): Permitted Actions

The au-6(7): permitted actions requirement is about decision rights around audit data: who is allowed to do what during audit log review, analysis, and reporting. Most teams document “log access” and stop there. AU-6(7) expects more operational specificity: it pushes you to define permitted actions per role (for example, view-only vs. create detections vs. close an alert vs. export logs vs. file an incident report), and to align those permissions across systems that touch audit information.

This matters because audit records are both sensitive and powerful. They can contain user identifiers, system internals, security findings, and investigative context. Overly broad permissions can enable data exposure, tampering risk, or uncontrolled dissemination of incident details. Overly restrictive permissions can slow response, create shadow workflows, and break your audit trail.

If you need to operationalize quickly, treat AU-6(7) as an access-and-workflow control: define permitted actions by role, implement them with role-based access control (RBAC) and workflow gates, then prove it works through periodic access reviews and sample-based testing. The goal is simple: the right people can take the right actions on audit information, and everyone else cannot.

Regulatory text

Requirement (verbatim): “Specify the permitted actions for each {{ insert: param, au-06.07_odp }} associated with the review, analysis, and reporting of audit record information.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator interpretation: You must (1) identify the roles or individuals involved in audit record review, analysis, and reporting, (2) explicitly define which actions each is allowed to perform, and (3) make those rules real in day-to-day operations through system permissions and documented procedures. (NIST SP 800-53 Rev. 5)

What “permitted actions” means in practice

“Permitted actions” are not generic job responsibilities. They are concrete operations a person can perform on audit data and audit-driven work, such as:

• Access actions: view, search, correlate, export, download, API access to logs.
• Content actions: create/edit detection rules, tune alerts, suppress alerts, annotate events, tag assets/users, add investigative notes.
• Workflow actions: open/assign/close alerts, escalate to incident, create an exception request, approve an exception, publish a report.
• Reporting actions: generate scheduled reports, distribute reports externally, brief executives, notify customers or regulators (if applicable to your program).

AU-6(7) expects you to specify these actions for each relevant role and ensure the specification matches what the tools allow.

Plain-English requirement interpretation

Define “who can do what” with audit logs and audit-derived outputs, by role, for the full lifecycle of review, analysis, and reporting. Then enforce it through RBAC and workflow controls, and keep evidence that permissions are configured and periodically validated. (NIST SP 800-53 Rev. 5)

Who it applies to (entity and operational context)

AU-6(7) is commonly applied in:

• Federal information systems and contractor systems handling federal data where NIST SP 800-53 is in scope (NIST SP 800-53 Rev. 5).
• Environments with centralized logging (SIEM), endpoint detection, cloud logging, identity logs, database audit logs, and ticketing/incident platforms that manage audit-driven work.

Operationally, it applies wherever personnel interact with audit record information, including:

• Security Operations (SOC), Detection Engineering, Incident Response (IR)
• IT Operations / SRE teams with log access
• GRC/compliance teams receiving audit reports
• Privacy or Legal teams who may receive incident or audit summaries
• Third parties (MSSPs, incident response retainers) with access to your logs or reporting outputs

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

Step 1: Define the scope of “audit record information”

Create a scoped inventory of audit record sources and destinations:

• Sources: OS logs, application logs, cloud control plane logs, IAM logs, database audit logs, EDR telemetry
• Destinations: SIEM, log archive, case management, incident tickets, reporting dashboards

Deliverable: Audit Record Information Scope Statement (1–2 pages) that names the systems and data flows.

Step 2: Identify roles that touch audit review, analysis, and reporting

List roles by function, not by person. Typical roles:

• SOC Analyst (Tier 1/2), SOC Lead
• Detection Engineer / SIEM Admin
• Incident Commander / IR Lead
• System Owner / Application Owner
• GRC Analyst / CCO delegate
• Auditor/Assessor (internal), Read-only stakeholder
• Third-party MSSP analyst (if applicable)

Deliverable: Role inventory tied to HR/IdP groups.

Step 3: Build a “Permitted Actions Matrix” (the core AU-6(7) artifact)

Use a table that maps role → permitted actions, and add constraints. Keep it specific and testable.

Example matrix structure:

Role	Review actions	Analysis actions	Reporting actions	Explicitly prohibited
SOC Analyst	View/search logs; open alerts	Add case notes; attach evidence	Draft internal report	Export raw logs off-platform; change retention
Detection Engineer	View/search logs	Create/edit detection rules; tune alerts	Publish detection change notes	Close incidents; approve exceptions
IR Lead	View/search logs	Declare incident; request containment	Publish incident report internally	Disable audit logging; delete events

Add columns for:

• Approval required? (yes/no; who approves)
• Data handling constraints (masking, redaction, approved export paths)
• Tool enforcement points (SIEM RBAC, ticket workflow, DLP rules)

Deliverable: AU-6(7) Permitted Actions Matrix approved by Security leadership and GRC.

Step 4: Implement permissions in systems (RBAC + workflow gates)

Translate the matrix into enforceable controls:

• Identity provider groups aligned to roles
• SIEM/log platform roles (read-only vs. admin vs. content author)
• Case management/ticketing permissions (who can close, who can escalate, who can publish reports)
• Export controls (restrict export, require approval, log export events)
• Separation of duties where it reduces risk (for example, detection authors cannot unilaterally suppress high-severity alerts)

Deliverable: Configuration snapshots (screenshots or exports) showing role definitions and assignments.

Step 5: Write the procedure for review, analysis, and reporting actions

Document how audit information is handled in practice:

• How alerts are reviewed and triaged
• When and how investigations are opened
• Who can declare an incident and publish a report
• What requires approvals (log export, external sharing, major detection changes)
• How actions are logged (audit trails for admin actions)

Deliverable: Audit Review/Analysis/Reporting SOP mapped to the matrix.

Step 6: Validate operation (prove permissions match the spec)

Run a lightweight control test:

• Pick sample users in each role and confirm they can perform permitted actions
• Confirm they cannot perform prohibited actions
• Confirm admin actions and exports generate audit events

Deliverable: Access validation test record with results and remediation notes.

Step 7: Operationalize recurring governance (keep it from drifting)

Set an operating cadence that matches your risk profile:

• Update matrix when roles/tools change
• Review role memberships and privileged assignments
• Re-test after SIEM migrations or major permission model changes
• Ensure third-party access is time-bound and monitored

Deliverable: Recurring access review record and change logs for the matrix.

Required evidence and artifacts to retain

Assessors look for traceability: requirement → defined rule → implemented configuration → proof it works.

Minimum evidence set:

• Approved AU-6(7) Permitted Actions Matrix
• Role definitions and mapping to IdP groups
• SIEM/log platform RBAC configuration export/screenshots
• Ticketing/case workflow permissions export/screenshots
• SOP/procedure for audit review, analysis, and reporting
• Access review records (who reviewed, what changed, approvals)
• Test evidence showing permitted/prohibited actions were validated
• Evidence for third-party access controls if applicable (contracts/SLAs aren’t enough; keep actual access records)

Practical note: Daydream is often used as the system of record to map AU-6(7) to a control owner, an implementation procedure, and recurring evidence artifacts so you can produce a consistent audit packet without rebuilding it each cycle.

Common exam/audit questions and hangups

Expect questions like:

• “Show me where you specified permitted actions by role for audit log review and reporting.” (NIST SP 800-53 Rev. 5)
• “How do you enforce those actions in the SIEM and in the case management tool?”
• “Who can export logs, and how is that monitored?”
• “How do you ensure analysts cannot modify/delete audit records or change retention?”
• “How do you control third-party (MSSP) actions on your audit data?”
• “Show evidence of periodic review or testing of these permissions.”

Common hangup: teams provide a generic access list (“SOC has access to SIEM”) without action-level specificity. Another hangup is mismatch between documented roles and actual tool permissions.

Frequent implementation mistakes and how to avoid them

Mistake 1: Documenting roles but not actions

Fix: force every role entry to include verbs (view, export, tune, close, publish). If you can’t test it, it’s not specified.

Mistake 2: SIEM RBAC is configured, but workflow permissions are ignored

Fix: map actions across the full chain: SIEM → case management → reporting distribution. “Close incident” often happens outside the SIEM.

Mistake 3: Over-privileging “admins” for convenience

Fix: split “platform admin” from “content author” and “incident authority.” Require approvals for high-risk actions like exporting raw logs or suppressing critical detections.

Mistake 4: Third-party access treated as a contract clause

Fix: treat third parties as roles in the matrix, enforce least privilege in tooling, and retain access logs and time-bound approvals.

Mistake 5: No evidence of ongoing operation

Fix: keep recurring access review records and periodic validation tests. Assessors frequently fail controls on “designed but not operating.”

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should not expect a case-based checklist here. The operational risk is still straightforward: unclear or unenforced permitted actions can lead to unauthorized disclosure of audit data, undetected tampering, uncontrolled export, and breakdowns in incident reporting accountability. AU-6(7) reduces these failure modes by making permissions explicit, testable, and repeatable. (NIST SP 800-53 Rev. 5)

A practical 30/60/90-day execution plan

First 30 days (stabilize)

• Name a control owner and deputies (SOC + GRC).
• Inventory audit log sources/destinations and identify all roles with access.
• Draft the permitted actions matrix for the SIEM, case management, and reporting distribution.
• Implement quick RBAC fixes for obvious over-permissions (for example, remove export rights from broad groups).

By 60 days (enforce + document)

• Finalize and approve the matrix and SOP.
• Align IdP groups to roles; remove direct user grants where feasible.
• Implement workflow gates: who can close alerts, escalate to incident, and publish reports.
• Run the first access validation test and record results.

By 90 days (prove operation)

• Complete a full access review cycle with documented approvals and remediation.
• Add change-management triggers: new tool, new log source, new third party, org restructure.
• Package your evidence so an auditor can trace spec → config → test results quickly (Daydream can hold the mapping and recurring evidence set).

Frequently Asked Questions

Do I have to define permitted actions for every individual user?

Define permitted actions by role, then map users to roles through groups. You still need evidence that actual user assignments match the role design. (NIST SP 800-53 Rev. 5)

What counts as “reporting” under AU-6(7)?

Reporting includes generating and distributing outputs derived from audit records, such as scheduled SIEM reports, incident summaries, and executive dashboards. Define who can publish, who can approve, and who can distribute externally. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Our SOC is outsourced. How do we satisfy AU-6(7)?

Treat the MSSP as a role (or set of roles) in the permitted actions matrix and enforce those permissions in your SIEM and case tooling. Keep evidence of time-bound access, monitored exports, and your approvals for high-risk actions.

Is “read-only access to logs” enough to pass?

Often no. AU-6(7) asks for permitted actions associated with review, analysis, and reporting. Many roles need more than read-only, and you must specify what they can do and what they cannot do. (NIST SP 800-53 Rev. 5)

What artifact do auditors ask for most often?

A role-to-action matrix that ties directly to system permissions, plus evidence that you reviewed and tested those permissions. If the matrix doesn’t match the tool configuration, expect findings.

How do we handle emergencies where someone needs extra access quickly?

Define a break-glass process as a permitted action pathway: who can approve, how access is time-bound, and how actions are logged and reviewed after the fact. Record each invocation as evidence.