AU-6: Audit Record Review, Analysis, and Reporting

The au-6: audit record review, analysis, and reporting requirement is the point where “we have logs” becomes “we detect and respond.” AU-6 expects you to review and analyze audit records for indicators of inappropriate or unusual activity and evaluate potential impact, then report outcomes to appropriate personnel. ¹

For a Compliance Officer, CCO, or GRC lead, the practical challenge is not selecting a SIEM. It’s making sure your organization can show consistent, risk-based coverage across systems, with clear ownership, defined review frequency, actionable criteria, and durable evidence. If your team cannot show who reviewed what, when, what they looked for, what they concluded, and what they escalated, AU-6 will fail in assessment even if you have centralized logging.

This page gives requirement-level implementation guidance: applicability, a step-by-step procedure you can hand to Security Operations and system owners, the minimum evidence set to retain, common audit questions, and a practical execution plan. It is written to help you operationalize AU-6 quickly and stand up to scrutiny under NIST SP 800-53 Rev. 5 expectations. ²

Regulatory text

Requirement excerpt (AU-6): “Review and analyze system audit records [organization-defined audit record review/analysis] for indications of [organization-defined inappropriate or unusual activity] and the potential impact of the inappropriate or unusual activity;” ¹

What the operator must do (plain reading)

You must:

1. Decide what audit records get reviewed and analyzed (your defined scope and triggers).
2. Define what “inappropriate or unusual activity” means for your environment (examples and detection logic).
3. Perform the reviews and analysis on an ongoing basis (humans, automation, or both).
4. Assess potential impact for identified events (business + security impact, not just “true/false positive”).
5. Report results to the right roles so action occurs (incident response, IT operations, system owner, compliance). ¹

AU-6 has “organization-defined parameters” in the text. Your job is to make those definitions explicit, documented, and consistently followed.

Plain-English interpretation of the requirement

AU-6 means you run a disciplined log-review program that can catch misuse, compromise, policy violations, and anomalous behavior; you then evaluate what it means and communicate it so the organization responds. Collection alone is insufficient. AU-6 expects analysis and reporting tied to action. ¹

Who it applies to

Entity scope

AU-6 is expected in:

• Federal information systems
• Contractor systems handling federal data (for example, systems in a regulated federal supply chain) ¹

Operational context (where it lands in real orgs)

AU-6 usually spans:

• Security Operations (SOC): alerting, triage, escalations, case management.
• IT Operations / Platform teams: system-level logs, admin activity, change events.
• Application owners: application audit trails and business-logic events.
• GRC / Compliance: control definition, evidence, exceptions, governance.
• Incident Response: impact analysis, containment, eradication steps, reporting outputs. ²

If you do not have a SOC, AU-6 still applies. You assign the function to IT/Security staff or a third party, then document the operating model and evidence.

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

Use this as an implementation procedure you can drop into a control narrative.

Step 1: Define AU-6 scope (systems, log sources, and boundaries)

Create an “AU-6 Log Review Scope” register with:

• In-scope systems (production first; include identity, endpoints, network, critical apps, and cloud control planes).
• Authoritative log sources per system (e.g., IAM audit logs, EDR, OS logs, database audit, application audit).
• Centralization path (where logs land, who can access them, and retention location).

Output artifact: AU-6 Scope & Log Source Matrix (table).

Step 2: Define “inappropriate or unusual activity” in operational terms

Write detection and review criteria that a reviewer can execute. Examples of categories to define:

• Privileged access misuse (unexpected admin actions, privilege escalations)
• Authentication anomalies (impossible travel patterns, repeated failures, unusual device/location)
• Data access anomalies (mass export, access outside role, unusual queries)
• Configuration changes (logging disabled, MFA policy changed, security group opened)
• Integrity signals (tamper indicators, audit log clearing attempts)

Output artifact: AU-6 Review & Detection Criteria (playbook-style list).
This satisfies the “organization-defined” element in AU-6. ¹

Step 3: Assign ownership and segregation of duties

Document:

• Control owner (often Head of Security Ops or CISO delegate)
• Operators (SOC analysts, system admins, app owners)
• Approvers (who signs off on recurring review completion)
• Escalation targets (IR lead, system owner, Compliance)

Add a RACI that prevents “self-review” for sensitive systems where feasible (e.g., the admin who made a change should not be the only reviewer of that change’s audit trail).

Output artifact: AU-6 RACI and Escalation Path.

Step 4: Set review cadences and triggers (risk-based, explicit)

Define two mechanisms:

• Scheduled reviews (recurring checks of key log sets)
• Event-driven reviews (alerts, major changes, incidents, high-risk third party activity, new integrations)

Write down:

• Which log sources are reviewed on a schedule vs. only via alerts
• Who performs the review
• What constitutes completion (e.g., checklist + ticket closure)

Output artifact: Log Review Schedule and Trigger Register.
Note: AU-6 does not supply default frequencies; you must define them and show consistent execution. ¹

Step 5: Implement analysis workflow (triage → impact → disposition)

Standardize the reviewer workflow in your ticketing/case system:

1. Ingest: alert or scheduled review task created
2. Triage: validate signal quality; collect context (user, host, IP, change record)
3. Impact analysis: document plausible impact (data exposure, integrity risk, availability, privilege)
4. Disposition: false positive, benign true positive, suspicious, confirmed incident
5. Escalation: route to IR or system owner with required SLA and next steps
6. Closure: evidence attached; lessons learned tagged; tuning requests captured

Output artifacts:

• AU-6 Triage/Impact Template (required ticket fields)
• AU-6 Case Taxonomy (disposition codes)

This is the “analysis” and “potential impact” core of AU-6. ¹

Step 6: Reporting: make the output consumable and provable

Define reporting audiences and outputs:

• Operational reporting: daily/weekly queue status, top alerts, tuning backlog
• Control reporting: monthly control attestation that reviews occurred, exceptions, coverage gaps
• Incident reporting inputs: escalations with impact narrative and evidence links

Keep reporting lightweight but consistent. Auditors value repeatability over fancy dashboards.

Output artifacts:

• Recurring AU-6 Review Report (export, PDF, or dashboard snapshot + narrative)
• Exception log (missed reviews, log source outages, access issues)

Step 7: Evidence retention and assessor readiness

Decide where evidence lives (GRC tool, ticketing system, SIEM exports, document repository) and ensure it is:

• Access-controlled
• Tamper-evident where feasible
• Searchable by system and date

Daydream (or a similar GRC workflow) becomes useful when you need AU-6 mapped cleanly to an owner, a procedure, and a recurring evidence set that is easy to produce during assessment. ¹

Required evidence and artifacts to retain

Minimum set most assessors expect for AU-6:

• AU-6 control narrative (scope, roles, cadence, reporting)
• AU-6 Scope & Log Source Matrix
• AU-6 Review & Detection Criteria / playbooks
• RACI + escalation procedure
• Completed review records (tickets, cases, or checklists) showing:
  • reviewer name/role
  • date/time
  • logs/queries checked (or alert IDs)
  • findings and disposition
  • impact analysis notes
  • escalation links (IR ticket, system owner ticket)
• Samples of reports delivered to stakeholders
• Tuning/lessons learned backlog (proof that analysis improves detection)
• Exceptions and compensating controls when logs were unavailable

If you cannot produce completed review records, AU-6 usually fails on “operating effectiveness,” even if the design is strong.

Common exam/audit questions and hangups

Expect these questions (and prepare the corresponding evidence):

1. “Show me the last X reviews for this high-impact system.” Provide tickets/cases, the query used, and the outcome.
2. “How did you define ‘unusual activity’?” Provide documented criteria and examples mapped to systems. ¹
3. “Who reviews privileged activity, and how do you prevent conflicts?” Show RACI and reviewer assignments.
4. “What happens when you find something?” Show escalation workflow, IR linkage, and impact narrative. ¹
5. “How do you know this happens consistently?” Show recurring tasks, report cadence, and exception handling.
6. “How do you cover cloud control plane logs?” Show log source matrix entries for cloud audit logs and a sample review.

Hangup to anticipate: teams often have SIEM alerts but lack evidence of scheduled reviews for log sources that do not reliably alert.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails AU-6	Avoid it by
“We collect logs” as the whole control	AU-6 requires review, analysis, and impact assessment 1	Add a documented review procedure plus recurring execution evidence
No organization-defined criteria	The control text explicitly expects defined parameters 1	Publish a detection/review criteria catalog and keep it versioned
Reviews happen in chat with no record	No audit trail of the audit review	Force reviews through tickets/cases with required fields
Only alert-based monitoring	Gaps when alerts are misconfigured or missing coverage	Add scheduled reviews for critical log sources
No impact analysis notes	AU-6 requires analyzing potential impact 1	Add a mandatory “impact assessment” field to cases
Unclear reporting and escalation	Findings do not drive action	Define recipients, thresholds, and escalation SLAs in the procedure

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific enforcement actions.

Operationally, AU-6 failures create predictable risk: suspicious activity goes unreviewed, incidents are detected late, and you cannot demonstrate due care during customer, regulator, or agency assessments. The most common real-world consequence is assessment findings tied to missing evidence of recurring review and follow-through, not missing tooling.

Practical 30/60/90-day execution plan

First 30 days (stand up the control and prove it runs once)

• Assign AU-6 control owner and operators; publish RACI and escalation path.
• Build the AU-6 Scope & Log Source Matrix for critical systems.
• Draft “inappropriate or unusual activity” criteria for those systems and get Security + system owners to sign off.
• Implement the ticket template for reviews (triage, impact, disposition, escalation link).
• Run the first scheduled reviews and retain the evidence package.

By 60 days (make it consistent and auditable)

• Expand scope to remaining in-scope systems; close log source gaps.
• Add recurring review tasks to your workflow tool and ensure completion tracking.
• Produce the first recurring AU-6 report and deliver it to stakeholders.
• Establish exception handling for missed reviews and log outages.

By 90 days (make it resilient and assessment-ready)

• Tune detection criteria based on findings and false positives; version the playbooks.
• Run a tabletop of the AU-6 workflow: from log signal to impact analysis to escalation to closure.
• Perform an internal mini-assessment: sample multiple systems, pull evidence, and confirm it is complete and consistent.
• If you manage controls in Daydream, map AU-6 to the owner, procedure, and recurring evidence artifacts so audits become a packaging exercise rather than a scramble. ¹

Frequently Asked Questions

Do we need a SIEM to meet AU-6?

AU-6 requires review, analysis, and reporting of audit records, not a specific tool. If you can prove consistent review and impact-focused triage with your existing logging and ticketing stack, you can satisfy the requirement. ¹

What counts as “organization-defined inappropriate or unusual activity”?

It’s your documented set of conditions that indicate misuse, compromise, or policy violations in your environment. Define categories (privilege misuse, anomalous logins, suspicious data access) and map them to log sources and review steps. ¹

How do we show auditors that reviews actually happened?

Keep review tickets or cases with timestamps, the log sources or queries checked, reviewer identity, findings, impact analysis, and any escalations. Pair that with a recurring report or task completion record. ¹

Can we rely only on automated alerts?

You can automate parts of AU-6, but you still need defined criteria, analysis of results, impact assessment, and reporting. Many teams add scheduled reviews for critical log sources to cover gaps when alerting fails. ¹

Who should own AU-6: SOC, IT, or GRC?

Security Operations typically owns execution, system owners supply system context, and GRC owns governance and evidence standards. Put this in a RACI so there is no ambiguity during an assessment. ²

What’s the minimum reporting expected under AU-6?

Report enough to show that findings are communicated and acted on: recurring review status, notable events, escalations, and exceptions. The format can be simple if it is consistent and retained as evidence. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5