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

AU-6: Audit Record Review, Analysis, and Reporting is one of the fastest ways an assessor will gauge whether your security program works in practice. Many teams collect logs, keep them for a retention period, and still fail AU-6 because they cannot prove consistent review, analysis, and escalation. The control is simple in concept but operationally easy to break during tool changes, ownership gaps, or “we’ll look if something happens” informal monitoring.

This page translates AU-6 into an execution-ready requirement: who owns it, what must run on a defined cadence, what “analysis” means beyond staring at a dashboard, what reports must exist, and what evidence you should retain to survive an audit or customer diligence request.

If you’re a Compliance Officer, CCO, or GRC lead, your job is to make this review process measurable, repeatable, and testable. That means mapping systems to log sources, selecting a review frequency based on risk, documenting decision rules for escalation, and keeping a clean evidence bundle every cycle. The goal is straightforward: detect suspicious activity early and prove you did.

Regulatory text

Requirement (excerpt): “Review and analyze system audit records [frequency] for indications of [inappropriate or unusual activity] and the potential impact of the inappropriate or unusual activity;” ¹

Operator meaning:

• You must define a frequency ¹ and then actually perform the review on that schedule.
• You must look for inappropriate or unusual activity (not only system errors), and you must document what you looked for (review criteria/use cases).
• You must assess potential impact for significant items (data exposure, privilege misuse, service disruption, fraud paths, etc.).
• You must report results in a way that drives action (tickets, escalations, management reporting), not just keep raw logs. ²

Plain-English interpretation (what AU-6 expects)

AU-6 expects a closed-loop monitoring and review process:

1. Logs exist for key systems and are accessible for review.
2. Humans and/or automation review them on a documented cadence.
3. Findings are analyzed (triage, validation, scoping, impact thinking).
4. Material items are reported and acted on (incident process, risk acceptance, corrective actions).
5. You can prove all of the above with consistent evidence.

A good AU-6 implementation reads like an operations runbook, not a policy paragraph.

Who it applies to

AU-6 applies to:

• Federal information systems and contractor systems handling federal data that adopt NIST SP 800-53 as the control baseline. ³
• Operationally: any environment where security-relevant events occur and must be detectable, including cloud control planes, identity providers, endpoints, network security tooling, databases, and critical applications.

Practical scoping guidance:

• Start with systems that process or store sensitive data, provide authentication/authorization, or control production changes.
• Include third-party hosted components if they are part of the system boundary or provide security-relevant telemetry (for example, managed IdP, managed WAF, managed SIEM).

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

1) Create a control card (your “one-page runbook”)

Document, at minimum:

• Objective: detect inappropriate/unusual activity and assess potential impact.
• In-scope systems: list systems or system categories (e.g., “Production AWS accounts,” “Corporate IdP,” “Customer database”).
• Owner(s): primary and backup (Security Operations, IT, or delegated MSSP; GRC remains accountable for evidence quality).
• Frequency: per system/category (daily/weekly/monthly as risk-appropriate).
• Inputs: log sources and dashboards/queries.
• Outputs: review record, findings, tickets, reports.
• Escalation rules: what becomes an incident, what becomes a service ticket, what is informational only. This matches the “control card” best-practice pattern your auditors expect to see in mature programs. ¹

2) Build your audit record inventory (log source mapping)

Create a table that ties each in-scope system to the logs you review.

Minimum fields to include:

• System name / environment (prod/non-prod)
• Log sources (e.g., cloud audit logs, OS logs, application audit logs, database audit logs)
• Collection method (agent, native integration, API)
• Storage/aggregation location (SIEM, log archive)
• Review method (alerts, saved searches, manual sampling)
• Owner
• Review frequency
• Retention location for evidence

This artifact prevents the most common AU-6 failure: “We thought it was logging, but that system wasn’t onboarded.”

3) Define “inappropriate or unusual activity” as concrete review use cases

Write a short list of what reviewers must look for, tuned to your environment. Examples:

• Identity: impossible travel, repeated failed logins, MFA changes, new admin roles, dormant account use.
• Cloud: root/admin activity, access key creation, security group exposure, disabled logging, unusual API calls.
• Data: large exports, unusual query patterns, access from new principals, access outside normal hours for privileged users.
• Admin actions: production config changes outside change windows, bypassed approvals, disabled security tools.

If you can’t express it as a query/alert or a checklist item, it will not be reviewed consistently.

4) Establish the review workflow (triage → impact → disposition)

For each review cycle, require reviewers to record:

• What period was reviewed
• What dashboards/queries were run (or what alert queues were checked)
• Findings summary: none / informational / suspicious / confirmed issue
• For suspicious/confirmed items:
  • validation steps taken
  • potential impact statement (data, availability, integrity, privilege)
  • disposition (false positive with reason, accepted risk, ticket created, incident created)
  • linkage to ticket/incident ID This is the “analysis” AU-6 is looking for. ¹

5) Implement reporting that drives action (not a vanity report)

Create two reporting layers:

• Operational reporting: tickets and incident records with timestamps, owners, and outcomes.
• Management reporting: a recurring summary that shows review completion, notable findings, and open items.

Keep management reporting lightweight. Auditors want proof it exists and that it is used.

6) Add control health checks (prove sustained operation)

Run recurring checks that confirm:

• In-scope log sources are still connected (no ingestion gaps)
• Alert rules and dashboards still exist after tool changes
• Review assignments and backup coverage remain valid
• Evidence bundle completeness meets your standard Track gaps as remediation items to closure. ¹

7) Operationalize in tooling (SIEM/SOAR/ticketing) with a “minimum viable” standard

You do not need perfect automation to pass AU-6, but you do need repeatability:

• Scheduled reports or saved searches
• Alert routing to an owned queue
• Ticket templates for investigation and impact assessment
• A centralized evidence repository (GRC tool, shared drive with access controls, or system of record)

If you use Daydream, treat AU-6 as a requirement page with a mapped evidence bundle, recurring tasks, and closure tracking for findings. Daydream fits cleanly here because AU-6 failures usually stem from “we did it, but can’t prove it” evidence gaps rather than missing tools.

Required evidence and artifacts to retain

Keep evidence that proves design and operation:

Design evidence (static, updated as systems change)

• AU-6 control card (objective, scope, owner, frequency, escalation rules)
• Audit record inventory (system → log sources → review method)
• Documented review use cases / alert catalog (what constitutes unusual activity)
• Reporting template(s) (operational + management)

Operating evidence ¹

• Dated review record (ticket, checklist, or signed log review attestation) showing:
  • reviewer, date, systems covered, time range
  • queries/dashboards checked or alert queues reviewed
  • summary of findings
• Investigation notes for flagged items
• Linked tickets/incidents and closure evidence (root cause, corrective actions, approvals if risk accepted)
• Management summary for the period (if required by your process)

Control health evidence

• Log ingestion/coverage checks
• Exceptions register (systems temporarily excluded, with compensating controls and expiration)

Common exam/audit questions and hangups

Auditors and customer assessors tend to drill into:

• “Show me the last two review cycles.” They want timestamps, names, coverage, and outcomes.
• “How did you pick the frequency?” They want a risk-based rationale, even if qualitative.
• “What do you consider ‘unusual’?” They want specific detections, not “we monitor logs.”
• “Prove the logs are complete.” They will ask about onboarding, ingestion failures, and boundary systems.
• “What happens when you find something?” They want to see escalation criteria and ticket/incident linkages.

Hangup to anticipate: teams present SIEM screenshots but cannot show who reviewed them, when, and what decisions were made.

Frequent implementation mistakes (and how to avoid them)

1. Logging without review evidence
   Fix: require a review record each cycle (ticket/checklist) and store it centrally.

2. Unclear ownership between SecOps, IT, and an MSSP
   Fix: name an internal control owner accountable for completion and evidence quality; the MSSP can execute, but you must retain outputs.

3. “Frequency” is defined once, then ignored
   Fix: schedule recurring tasks and track completion; missed cycles should generate an exception and corrective action.

4. No impact assessment
   Fix: add a mandatory “potential impact” field for suspicious/confirmed findings. Even a short statement satisfies intent if it is thoughtful and consistent.

5. Scope drift after cloud migrations or new tooling
   Fix: run control health checks after major changes; update the audit record inventory as part of change management.

Risk implications (why AU-6 failures matter operationally)

AU-6 gaps create two concrete risks:

• Detection risk: you may not notice account compromise, privilege abuse, or data access anomalies until damage is done.
• Assurance risk: you cannot demonstrate monitoring to auditors, customers, or authorizing officials, which can delay ATO decisions or fail security reviews tied to federal data handling. ³

Practical 30/60/90-day execution plan

First 30 days (stand up minimum viable AU-6)

• Assign AU-6 owner and backup; publish the control card.
• Identify in-scope systems and draft the audit record inventory.
• Pick an initial review cadence by system tier (higher risk reviewed more often).
• Implement a basic review record (ticket template or checklist) and start running it.

Days 31–60 (make it consistent and testable)

• Convert “unusual activity” into a short alert/use-case catalog tied to log sources.
• Establish escalation rules and integrate with your incident and ticket workflows.
• Create a lightweight management report and send it on schedule.
• Run the first control health check (log ingestion gaps, missing sources, reviewer coverage).

Days 61–90 (reduce evidence pain and improve signal quality)

• Tune detections to reduce false positives and document disposition logic.
• Add automation where it materially reduces manual work (scheduled queries, alert routing, SOAR playbooks).
• Perform an internal “mini-audit” of AU-6: sample review cycles, trace findings to closure, and remediate documentation gaps.
• If you use Daydream, map AU-6 tasks to recurring reminders and attach evidence bundles per cycle for audit-ready retrieval.

Frequently Asked Questions

What counts as “review and analyze” if we have automated alerts?

Automated alerts can satisfy much of the review requirement, but you still need evidence that someone monitored the queue, investigated meaningful alerts, assessed potential impact, and recorded outcomes.

How do we choose the AU-6 review frequency?

Set frequency based on risk and system criticality, then document the rationale in the control card. Auditors mainly test that your chosen cadence is explicit and consistently followed.

Can an MSSP perform AU-6 reviews for us?

Yes, but you remain accountable for proving operation. Require the MSSP to deliver review records, findings, and ticket linkages in a format you can retain and retrieve.

What evidence is strongest for AU-6 in an audit?

Time-stamped review records tied to specific systems and time ranges, plus linked investigations and closure tickets. Dashboards alone are weak evidence without reviewer identity and decisions.

What do we do if a system can’t produce the audit logs we need?

Record an exception with a compensating control, an owner, and a remediation plan to add logging or replace the component. Keep the exception time-bound so it does not become permanent scope erosion.

How do we prove “potential impact” without overengineering the analysis?

Add a required field in your ticket template for a short impact statement (data, integrity, availability, privilege) and a disposition. Consistency matters more than length.

Footnotes

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

2. NIST SP 800-53 Rev. 5; Source: NIST SP 800-53 Rev. 5 DOI

3. NIST SP 800-53 Rev. 5