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

What this control requires

AU-06 requires organizations to regularly review and analyze system audit records for signs of inappropriate or unusual activity, report findings to designated personnel, and adjust review depth when the risk environment changes. Without a defined process for turning raw log data into actionable findings, audit records become an expensive storage problem rather than a security tool.

In practice, this means you need three things working together. First, a documented cadence for reviewing logs across your environment, covering everything from account usage and remote access to configuration changes, physical access events, and communications at system boundaries. Second, a clear reporting path so that findings reach the people who can act on them, whether that’s an incident response team, a security operations center, or a privacy office.

The third requirement is the ability to scale review intensity up or down based on new intelligence, such as law enforcement advisories, threat intelligence feeds, or credible reports of increased targeting in your sector.

The control exists because logging without review is security theater. Organizations that collect audit records but never systematically analyze them discover breaches months after the fact, if they discover them at all. AU-06 closes that gap by making log review a repeatable, accountable process tied to the NIST SP 800-53 framework.

Why it matters

Most organizations treat log review as a checkbox exercise rather than an operational discipline. The result is predictable: alerts pile up unexamined, anomalies go unnoticed, and the gap between compromise and detection stretches from hours to months.

Failure to maintain AU-06 introduces direct audit risk and may result in certification withdrawal or regulatory findings. Federal agencies that cannot demonstrate regular, documented log review face noncompliance findings during Federal Information Security Management Act (FISMA) assessments, and organizations pursuing Federal Risk and Authorization Management Program (FedRAMP) authorization risk having an Authority to Operate (ATO) stalled or revoked. In regulated industries, weak log review practices undermine the defensibility of your entire compliance posture.

Where this breaks down is the volume problem. Modern environments generate millions of log entries per day across endpoints, cloud workloads, identity providers, and network appliances. Without a structured approach to filtering, correlating, and prioritizing those records, security teams default to reactive investigation only after something visibly fails, which is precisely what AU-06 is designed to prevent.

The operational consequence extends beyond compliance. Organizations that don’t review audit records systematically lose the ability to detect lateral movement, privilege escalation, and data exfiltration while those activities are still in progress. By the time a breach surfaces through external notification, attackers have completed their objectives and the forensic trail has gone cold.

What attackers exploit

• Unmonitored service accounts that generate high volumes of legitimate-looking activity, masking unauthorized access
• Log gaps during maintenance windows, system reboots, or cloud scaling events where records aren’t captured
• Alert fatigue in security teams that receive thousands of low-fidelity notifications and stop investigating
• Inconsistent review cadences that leave weekends, holidays, and off-hours uncovered
• Siloed log sources where no single team correlates activity across identity, network, and endpoint data

How to implement

The most common failure mode with AU-06 isn’t a missing policy; it’s a policy that defines a review cadence but provides no operational process for actually conducting the review, escalating findings, or adjusting depth when conditions change.

For your organization

Step 1: Define your review scope and frequency. Map every log source in your environment: operating systems, applications, network devices, identity providers, cloud platforms, physical access systems, and Voice over Internet Protocol (VoIP) infrastructure. Assign each source a review frequency based on its risk profile.

High-value targets like privileged account activity, remote access logs, and security event records warrant daily or near-real-time review. Lower-risk sources such as equipment inventory changes may justify weekly or monthly review.

Step 2: Establish a correlation and analysis process. Raw log review doesn’t scale. Deploy a centralized log management platform (security information and event management, or SIEM) that aggregates records from all sources and applies correlation rules.

Build detection logic around the specific types of inappropriate or unusual activity defined in your system security plan. Tune alert thresholds to reduce false positives without suppressing genuine anomalies.

Step 3: Define reporting paths. Document who receives findings and how. Routine anomalies may route to the help desk or security operations center. Confirmed incidents should escalate to the incident response team following your incident response procedures.

Privacy-related findings need a separate path to privacy officers. Every report should include the log source, the anomaly detected, the potential impact, and the recommended action.

Step 4: Build a risk-adjustment mechanism. Your review process can’t be static. When you receive a credible threat advisory, a law enforcement notification, or intelligence indicating elevated targeting of your sector, you need a documented procedure to increase review frequency, broaden scope, or deepen analysis. This might mean shifting from daily to near-real-time review, expanding the types of logged events under scrutiny, or bringing in additional analysts.

Common mistakes:

• Setting a review frequency in policy but never assigning staff or allocating time to perform it
• Relying entirely on automated alerting without any human review of aggregate trends
• Failing to document review activities, which leaves you unable to prove compliance during an audit
• Treating all log sources with the same review cadence regardless of risk

For your vendors

What to ask in a security questionnaire:

• What is your documented frequency for reviewing system audit records?
• Who receives reports of unusual or suspicious activity found during log review?
• What tools do you use to aggregate and correlate audit records across systems?
• How do you adjust your log review process when a new threat or vulnerability is disclosed?
• Can you provide evidence of completed log reviews from the past 90 days?

Evidence to request:

• Audit and accountability policy with defined review frequencies
• Sample reports of audit findings from the most recent review cycle
• SIEM or log management platform configuration showing correlation rules
• Records of actions taken in response to identified anomalies
• Documentation of any risk-based adjustments to review depth or frequency

Red flags:

• The vendor cannot name a specific review cadence or says reviews happen “as needed”
• Log review responsibilities aren’t assigned to a named role or team
• The vendor has no centralized log management and reviews logs on individual systems manually
• There’s no documented escalation path from log findings to incident response
• The vendor has never adjusted review intensity in response to a threat advisory

Verification beyond self-attestation: Request a walkthrough of the vendor’s SIEM dashboard or log review workflow. Ask for a sample of findings reports with redacted details. If the vendor claims automated monitoring capabilities, ask to see the alert rules and tuning history.

Compare their stated review frequency against the volume of findings reports they can produce.

Evidence examples

Cross-framework mapping

Related controls

• AC-02, Account Management: Account lifecycle events (creation, modification, disabling) are among the most critical audit records AU-06 requires you to review.
• AC-03, Access Enforcement: Access enforcement logs reveal unauthorized access attempts that AU-06 review processes should detect and escalate.
• AC-05, Separation of Duties: Log review should flag when a single user performs actions that violate separation of duties policies, such as both creating and approving accounts.
• AC-06, Least Privilege: AU-06 review processes should identify privilege escalation patterns or users operating outside their authorized access level.
• AC-07, Unsuccessful Logon Attempts: Failed authentication attempts are a primary indicator of brute-force or credential-stuffing attacks that AU-06 reviews should surface.
• AC-17, Remote Access: Remote access sessions generate audit records that require heightened review attention due to their elevated risk profile.
• AU-07, Audit Record Reduction and Report Generation: AU-07 provides the tooling to filter and summarize audit records, directly supporting the analysis and reporting requirements of AU-06.
• AU-16, Cross-organizational Audit Logging: When audit records span organizational boundaries, AU-06 review processes must account for logs received from or shared with external entities.
• CA-02, Control Assessments: Assessors evaluate AU-06 effectiveness by examining whether log reviews actually occur at the stated frequency and produce documented findings.
• CA-07, Continuous Monitoring: Continuous monitoring programs depend on the regular audit record review that AU-06 mandates to detect security-relevant changes in near-real time.

Frequently asked questions

What is NIST SP 800-53 AU-06

AU-06 requires organizations to review and analyze system audit records at a defined frequency, report findings of inappropriate or unusual activity to designated personnel, and adjust review intensity when the risk environment changes. The control applies to all federal information systems at LOW, MODERATE, and HIGH baselines, making it one of the most broadly required audit controls in the framework. It covers logging across a wide range of sources, from account usage and remote access to physical access events and VoIP communications.

What happens if AU-06 is not implemented

Without AU-06, your organization loses the ability to detect unauthorized activity through audit records before it causes damage. Audit findings from FISMA assessments and FedRAMP reviews will flag the gap, potentially resulting in a Plan of Action and Milestones (POA&M) or loss of authorization to operate. Beyond compliance consequences, the practical impact is that indicators of compromise buried in log data, such as unusual account usage patterns or unauthorized configuration changes, go undetected until the damage escalates to the point of external discovery.

How do you audit AU-06

Auditors verify AU-06 by examining the audit and accountability policy for defined review frequencies, interviewing personnel responsible for log review, and reviewing completed reports of audit findings to confirm reviews actually occur. They’ll look for evidence that findings are reported to the correct roles and that the organization has adjusted review depth in response to risk changes, such as threat intelligence advisories. Key artifacts include the system security plan’s logging configuration, sample audit finding reports with reviewer sign-off, and records of actions taken in response to identified anomalies.

How often should audit records be reviewed under AU-06

AU-06 doesn’t prescribe a universal frequency; instead, it requires you to define a review cadence appropriate to your system’s risk level and document it in your security plan. In practice, most organizations review high-risk log sources (privileged access, remote sessions, authentication failures) daily or in near-real time, while lower-risk sources like equipment inventory logs follow a weekly or monthly cycle. What matters most is that your chosen frequency is documented, consistently followed, and adjusted when threat conditions change.