AU-5: Response to Audit Logging Process Failures

Quick-reference card

What AU-05 requires

AU-05 requires organizations to alert designated personnel when an audit logging process fails and take predefined response actions.

In practice, this control addresses a systemic weakness most security programs overlook. Audit logs are the foundation of incident detection, forensic investigation, and compliance evidence. When the process that generates or stores those logs breaks down silently, every downstream control that depends on log data degrades without warning.

The result is that the entire Audit and Accountability family depends on logging integrity as a foundational assumption.

Specifically, NIST frames AU-05 around two discrete obligations. First, organizations must define who receives alerts and how quickly those alerts fire when a logging failure occurs. Second, organizations must specify what happens next, whether that means overwriting the oldest records, shutting down the affected system, or stopping audit record generation entirely.

But the scope extends beyond software crashes. Hardware errors, failures in the audit capture mechanism, and storage capacity exhaustion all qualify as audit logging process failures.

Specifically, organizations can tailor their response based on failure type, location, severity, or a combination of those factors. When storage is the root cause, the response can target the specific repository, the host system, the organization’s total log storage capacity, or all three.

Why AU-05 matters

Silent audit logging failures create a critical blind spot in any security program. When logs stop flowing and no one notices, the organization loses the ability to detect intrusions, prove compliance, and reconstruct events after an incident.

The result is a direct compliance and audit risk. Assessors evaluating AU-05 will verify that alert recipients are defined, that time thresholds are documented, and that additional response actions are both specified and tested. Failing this control during an audit signals a gap in the organization’s foundational monitoring posture, not just a missing configuration.

Specifically, this gap is more common than most teams realize. Log pipelines involve multiple components, including agents, forwarders, aggregators, and storage backends. A failure at any point in that chain can go undetected for days or weeks if no alerting mechanism exists. Monitoring activities that depend on continuous log ingestion will produce incomplete results during those silent outages.

What attackers exploit

Threat actors and compliance gaps converge around the same failure modes that AU-05 is designed to address:

• Log storage exhaustion. Attackers flood a system with benign events to fill audit log storage, causing legitimate records to be dropped or overwritten before analysts review them.
• Agent and forwarder failures. When log collection agents crash or lose connectivity, events generated during the outage are never captured. Attackers time lateral movement to coincide with known maintenance windows or service disruptions.
• Privilege escalation to disable logging. Compromised accounts with administrative access can stop or reconfigure audit services. Without failure alerting, the change goes unnoticed.
• Timestamp manipulation. Altering system clocks or log timestamps undermines forensic timelines. If the logging process itself is not monitored for integrity, manipulated records blend with legitimate ones.
• Network segmentation gaps in log transport. Log data traversing network segments without encryption or integrity checks can be intercepted or dropped, creating gaps that appear as normal collection pauses.

How to implement AU-05

The most common failure mode in AU-05 implementation is treating alerting as a one-time configuration rather than a tested, end-to-end response chain. Organizations that define alert rules during initial deployment but never validate them under real failure conditions discover the gap only when it matters most.

For your organization

Implementing AU-05 internally starts with mapping the complete audit logging pipeline, from event generation on endpoints and servers through collection, transport, aggregation, and storage. Every component in that chain is a potential failure point, and each one needs a corresponding alerting mechanism.

Specifically, define the alert recipients first. NIST requires organizations to specify the personnel or roles who receive failure notifications. In most environments, this means the security operations center (SOC) team, the system administrator responsible for the affected host, and the compliance officer who oversees audit record integrity.

In practice, document these assignments in the system security plan and review them during personnel changes.

Take time thresholds as the next configuration decision. A five-minute alert window may be appropriate for high-impact systems processing sensitive data. A 30-minute window might suffice for lower-priority systems. The key is that the threshold is defined, documented, and enforceable through automated monitoring.

In practice, configure your log management platform to detect common failure conditions. Storage utilization alerts should fire well before capacity is reached. Capacity management practices that monitor disk usage trends and set graduated thresholds at 70%, 85%, and 95% prevent storage exhaustion from becoming a crisis.

Specifically, specify the additional actions your organization will take beyond alerting. NIST provides three examples: overwriting the oldest audit records, shutting down the system, and stopping audit record generation.

But each option carries tradeoffs. Overwriting preserves system availability but sacrifices historical data, while shutting down preserves log integrity but impacts operations. Document the rationale for each decision and align it with the system’s categorization and mission criticality.

Where this breaks down is in testing. A documented alerting rule that has never fired in production may not work when it matters. Test the entire response chain at least annually.

Specifically, inject simulated failures, including disk full conditions, agent crashes, and network partitions, to verify that alerts reach the right people within the defined time period and that additional actions execute as configured.

For your vendors

When AU-05 applies to third-party systems, the organization retains accountability for verifying that vendor environments meet the same alerting and response requirements.

Specifically, start by reviewing the vendor’s system security plan and audit logging architecture documentation. Confirm that the vendor has defined alert recipients, time thresholds, and additional response actions for audit logging failures within the systems that process your data.

Where this breaks down is when vendors cannot produce this documentation. If they cannot, the control is not adequately implemented regardless of what their compliance certification states.

In practice, the most effective enforcement lever is contractual language. Service level agreements should specify maximum acceptable time-to-alert for logging failures, the actions the vendor will take when failures occur, and the notification obligations to your organization when a logging failure affects systems in scope.

But defining rules is not enough without verification. During vendor assessments, request evidence of tested alerting mechanisms. A vendor that has defined alert rules but never tested them carries the same risk as one that has no rules at all.

Specifically, ask for records of simulated failure exercises or post-incident reports that demonstrate the alerting chain functioned as designed.

In practice, the only way to catch drift between assessment cycles is monitoring vendor compliance continuously. Review audit logs and system monitoring reports from vendor environments on a recurring schedule. Access control reviews should verify that vendor personnel with the ability to modify logging configurations are limited to authorized roles. Platforms like UpGuard Vendor Risk can automate this continuous monitoring and streamline evidence collection for controls like AU-05 across the vendor portfolio.

Evidence examples

Assessors evaluating AU-05 will look for documented policies, tested procedures, and system-level evidence that the control operates as intended. The following artifacts address the control’s assessment objectives:

Cross-framework mapping

AU-05 maps to related controls in other compliance frameworks, enabling organizations to satisfy overlapping requirements through a unified implementation.

NIST SP 800-171 Rev 3 control 03.03.04 addresses the same core requirement for controlled unclassified information (CUI) environments. The coverage is partial because SP 800-171 scopes the requirement to CUI protection rather than the broader system categorization approach in SP 800-53.

Organizations subject to both frameworks can leverage the same implementation artifacts, but should verify that SP 800-171’s CUI-specific scoping requirements are met. For a broader overview of the relationship between these frameworks, see the UpGuard guide to NIST SP 800-171.

Related controls

Understanding how AU-05 connects to other controls in the full control catalog clarifies the dependencies that make audit logging failure response effective.

• AU-02 Event Logging. Defines which events the system must log, establishing the baseline that AU-05 protects by ensuring those logs are reliably generated and captured.
• AU-04 Audit Log Storage Capacity. Allocates sufficient storage for audit records, directly reducing the likelihood of the storage exhaustion failures that AU-05 must detect and address.
• AU-07 Audit Record Reduction and Report Generation. Enables analysis and reporting on audit data, which depends on the continuous log availability that AU-05 safeguards.
• AU-09 Protection of Audit Information. Prevents unauthorized modification or deletion of audit records, complementing AU-05’s focus on detecting process failures that could create gaps in the audit trail.
• AU-11 Audit Record Retention. Establishes how long audit records must be retained, a requirement that becomes unachievable if logging process failures go undetected and create gaps in the record.
• AU-12 Audit Record Generation. Governs the actual generation of audit records at the system level, making it the upstream process that AU-05 monitors for failures.
• AU-14 Session Audit. Extends audit capabilities to session-level recording, adding another logging process that falls within AU-05’s failure detection scope.
• SI-04 System Monitoring. Provides the broader monitoring infrastructure that often serves as the mechanism for detecting the audit logging failures AU-05 requires organizations to address.
• SI-12 Information Management and Retention. Governs the lifecycle management of information including audit records, reinforcing the retention objectives that depend on uninterrupted logging.

Frequently asked questions

What is NIST SP 800-53 AU-05

AU-05 is the NIST SP 800-53 control that requires organizations to alert designated personnel when an audit logging process fails and to take predefined additional actions in response. Failures covered include software and hardware errors, failures in the audit log capturing mechanism, and reaching or exceeding audit log storage capacity. The control applies across all three baselines (LOW, MODERATE, HIGH), reflecting the foundational role that logging integrity plays in every security program.

What happens if AU-05 is not implemented

Without AU-05, audit logging failures go undetected, creating gaps in the audit trail that undermine incident detection, forensic investigations, and compliance evidence. Assessors reviewing the system security plan will flag the absence of defined alert recipients, time thresholds, and additional response actions as a direct control failure. The downstream impact extends to every control that depends on continuous log availability, including event logging (AU-02), system monitoring (SI-04), and audit record retention (AU-11). An organization that cannot demonstrate a functioning failure response mechanism risks audit findings, certification delays, and reduced confidence from regulators and customers.

How do you audit AU-05

Auditors assess AU-05 by examining the audit and accountability policy, reviewing the personnel notification list for designated alert recipients, and testing whether system configuration settings enforce the defined alert thresholds and additional response actions. The two assessment objectives are verifiable: that the specified personnel or roles receive alerts within the documented time period, and that the defined additional actions execute when a logging failure occurs. Testing typically involves reviewing SIEM alert rules and storage threshold configurations, interviewing system administrators about escalation procedures, and requesting records of simulated failure exercises or historical audit records showing the system responded correctly to past incidents.

What should happen when audit logs are full

When audit log storage reaches capacity, the organization must execute the additional actions defined in its AU-05 implementation. NIST identifies three response options: overwriting the oldest audit records, shutting down the system, and stopping audit record generation. Each option carries distinct tradeoffs that should be evaluated against the system’s security categorization and mission criticality. Overwriting preserves system availability but sacrifices historical data that may be needed for forensic investigations. Organizations should configure graduated storage alerts at multiple utilization levels so that administrative action can free space before the system must execute its defined response.