Control statement
- a.Alert [Organization-defined: personnel or roles] within [Organization-defined: time period] in the event of an audit logging process failure; and
- b.Take the following additional actions: [Organization-defined: additional actions].
Discussion
Audit logging process failures include software and hardware errors, failures in audit log capturing mechanisms, and reaching or exceeding audit log storage capacity. Organization-defined actions include overwriting oldest audit records, shutting down the system, and stopping the generation of audit records. Organizations may choose to define additional actions for audit logging process failures based on the type of failure, the location of the failure, the severity of the failure, or a combination of such factors. When the audit logging process failure is related to storage, the response is carried out for the audit log storage repository (i.e., the distinct system component where the audit logs are stored), the system on which the audit logs reside, the total audit log storage capacity of the organization (i.e., all audit log storage repositories combined), or all three. Organizations may decide to take no additional actions after alerting designated roles or personnel.
Organization-defined parameters
These values must be resolved through the organization’s tailoring and governance process. Bracketed parameter references in the control text identify where a decision is required.
From control text to operational evidence
Use Response to Audit Logging Process Failures as a testable risk decision. Translate the official statement into accountable people, repeatable processes, configured technology, and evidence that demonstrates the outcome over time. In this family, pay particular attention to audit event design, trustworthy collection, retention, review, and investigation support.
Implementation workflow
- Define the control boundary, responsible owner, inherited portions, and systems or processes in scope.
- Resolve each organization-defined parameter before declaring the control implemented.
- Document how the implementation satisfies every clause of the official control statement.
- Collect evidence as a normal byproduct of operation rather than only before an assessment.
- Review exceptions, changes, and monitoring results on a risk-based cadence.
Evidence examples
- logging standards and event-selection decisions
- sample audit records and retention settings
- time-synchronization evidence
- alert and review records
Common failure patterns
- collecting logs without defined use cases
- critical events missing from the audit trail
- retention shorter than investigative needs
- logs accessible to the same administrators being monitored
Questions practitioners should ask
- What risk decision is this control intended to support in this system?
- Which parts are implemented locally, inherited, shared, or not applicable—and what evidence supports that decision?
- Do the documented narrative, deployed configuration, operating process, and collected evidence agree?
- What event or threshold requires the implementation to be reviewed or changed?
Assessment objectives and methods
Show the assessment objective
- AU-05a.[Organization-defined: personnel or roles] are alerted in the event of an audit logging process failure within [Organization-defined: time period];
- AU-05b.[Organization-defined: additional actions] are taken in the event of an audit logging process failure.
Examine
- Audit and accountability policy
- procedures addressing response to audit processing failures
- system design documentation
- system security plan
- privacy plan
- system configuration settings and associated documentation
- list of personnel to be notified in case of an audit processing failure
- system audit records
- other relevant documents or records
Interview
- Organizational personnel with audit and accountability responsibilities
- organizational personnel with information security and privacy responsibilities
- system/network administrators
- system developers
Test
- Mechanisms implementing system response to audit processing failures
Related controls
These relationships come from the official OSCAL catalog. They indicate useful dependencies or context, not automatic inheritance or equivalence.
Control enhancements
Enhancements add specificity, strength, or scope to the base control. Baseline badges show explicit selections in the official SP 800-53B OSCAL profiles.
AU-5(1) — Storage Capacity Warning
Provide a warning to [Organization-defined: personnel, roles, and/or locations] within [Organization-defined: time period] when allocated audit log storage volume reaches [Organization-defined: percentage] of repository maximum audit log storage capacity.
Official discussion
Organizations may have multiple audit log storage repositories distributed across multiple system components with each repository having different storage volume capacities.
Organization-defined parameters (3)
Assessment objectives and methods
a warning is provided to [Organization-defined: personnel, roles, and/or locations] within [Organization-defined: time period] when allocated audit log storage volume reaches [Organization-defined: percentage] of repository maximum audit log storage capacity.
Examine
- Audit and accountability policy
- procedures addressing response to audit processing failures
- system design documentation
- system security plan
- privacy system configuration settings and associated documentation
- system audit records
- other relevant documents or records
Interview
- Organizational personnel with audit and accountability responsibilities
- organizational personnel with information security and privacy responsibilities
- system/network administrators
- system developers
Test
- Mechanisms implementing audit storage limit warnings
AU-5(2) — Real-time Alerts
Provide an alert within [Organization-defined: real-time period] to [Organization-defined: personnel, roles, and/or locations] when the following audit failure events occur: [Organization-defined: audit logging failure events requiring real-time alerts].
Official discussion
Alerts provide organizations with urgent messages. Real-time alerts provide these messages at information technology speed (i.e., the time from event detection to alert occurs in seconds or less).
Organization-defined parameters (3)
Assessment objectives and methods
an alert is provided within [Organization-defined: real-time period] to [Organization-defined: personnel, roles, and/or locations] when [Organization-defined: audit logging failure events requiring real-time alerts] occur.
Examine
- Audit and accountability policy
- procedures addressing response to audit processing failures
- system design documentation
- system security plan
- privacy plan
- system configuration settings and associated documentation
- system audit records
- other relevant documents or records
Interview
- Organizational personnel with audit and accountability responsibilities
- organizational personnel with information security and privacy responsibilities
- system/network administrators
- system developers
AU-5(3) — Configurable Traffic Volume Thresholds
Enforce configurable network communications traffic volume thresholds reflecting limits on audit log storage capacity and [Organization-defined: au-05.03_odp] network traffic above those thresholds.
Official discussion
Organizations have the capability to reject or delay the processing of network communications traffic if audit logging information about such traffic is determined to exceed the storage capacity of the system audit logging function. The rejection or delay response is triggered by the established organizational traffic volume thresholds that can be adjusted based on changes to audit log storage capacity.
Organization-defined parameters (1)
Assessment objectives and methods
- AU-05(03)[01]configurable network communications traffic volume thresholds reflecting limits on audit log storage capacity are enforced;
- AU-05(03)[02]network traffic is [Organization-defined: au-05.03_odp] if network traffic volume is above configured thresholds.
Examine
- Audit and accountability policy
- procedures addressing response to audit processing failures
- system design documentation
- system security plan
- privacy plan
- system configuration settings and associated documentation
- system audit records
- other relevant documents or records
Interview
- Organizational personnel with audit and accountability responsibilities
- organizational personnel with information security and privacy responsibilities
- system/network administrators
- system developers
AU-5(4) — Shutdown on Failure
Invoke a [Organization-defined: au-05.04_odp.01] in the event of [Organization-defined: audit logging failures] , unless an alternate audit logging capability exists.
Official discussion
Organizations determine the types of audit logging failures that can trigger automatic system shutdowns or degraded operations. Because of the importance of ensuring mission and business continuity, organizations may determine that the nature of the audit logging failure is not so severe that it warrants a complete shutdown of the system supporting the core organizational mission and business functions. In those instances, partial system shutdowns or operating in a degraded mode with reduced capability may be viable alternatives.
Organization-defined parameters (2)
Assessment objectives and methods
[Organization-defined: au-05.04_odp.01] is/are invoked in the event of [Organization-defined: audit logging failures] , unless an alternate audit logging capability exists.
Examine
- Audit and accountability policy
- procedures addressing response to audit processing failures
- system design documentation
- system security plan
- privacy plan
- system configuration settings and associated documentation
- system audit records
- other relevant documents or records
Interview
- Organizational personnel with audit and accountability responsibilities
- organizational personnel with information security and privacy responsibilities
- system/network administrators
- system developers
Test
- System capability invoking system shutdown or degraded operational mode in the event of an audit processing failure
Related controls
AU-5(5) — Alternate Audit Logging Capability
Provide an alternate audit logging capability in the event of a failure in primary audit logging capability that implements [Organization-defined: alternate audit logging functionality].
Official discussion
Since an alternate audit logging capability may be a short-term protection solution employed until the failure in the primary audit logging capability is corrected, organizations may determine that the alternate audit logging capability need only provide a subset of the primary audit logging functionality that is impacted by the failure.
Organization-defined parameters (1)
Assessment objectives and methods
an alternate audit logging capability is provided in the event of a failure in primary audit logging capability that implements [Organization-defined: alternate audit logging functionality].
Examine
- Audit and accountability policy
- procedures addressing response to audit processing failures
- system design documentation
- system security plan
- privacy plan
- system configuration settings and associated documentation
- system audit records
- other relevant documents or records
Interview
- Organizational personnel with audit and accountability responsibilities
- organizational personnel with information security and privacy responsibilities
- system/network administrators
- system developers
Test
- Alternate audit logging capability
Related controls
Authoritative sources
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST. Official control requirements and interpretations remain with NIST and the responsible authorizing organization.