AU-5 audit logging failure response: requirements

AU-5 audit logging failure response: what the requirement asks

When an assessor asks what happens when logging stops, the answer AU-5 expects is specific: the system must alert defined personnel or roles within a defined time when an audit logging process fails, and it must take defined additional actions. The control does not leave the response to judgment. The organization writes down who is told, how quickly, and what the system does next, then shows that the mechanism works. The catalog guidance gives examples of the additional actions, including overwriting the oldest audit records so new events can still be captured, or shutting the system down. Either choice is a risk decision, and the organization owns it. A system that keeps running with no audit trail and no alert is the situation the control exists to prevent, because a silent logging gap can hide an intrusion, a privileged change or a data exfiltration for as long as nobody notices.

AU-5 is harder to satisfy than its one-sentence wording suggests because most of the work happens before the assessor arrives. The organization must define the recipients (named roles such as the security operations on-call queue, the system owner or the audit administrator), the time limit for the alert, and the actions the system takes on failure, all in writing. Assessors then examine the list of personnel to be notified and the system audit records, interview administrators and the people with audit responsibilities, and test the mechanisms that carry out the response. Confirm with your own environment whether the platform can send alerts from the logging failure itself, since a logging component that fails may not be able to report its own failure. Ask the implementation partner to demonstrate a deliberate failure in a test environment and record the alert and the resulting action as evidence.

Which systems carry AU-5 and which enhancements apply

AU-5 applies to the low, moderate and high baselines but not the privacy baseline, and its two enhancements that matter most for operations apply only at the high baseline. The cards below cover the scoping decisions that change how much work AU-5 creates, from the baseline selection itself to which logging pipelines and hosted services count as audit processes.

Baseline selection for AU-5

AU-5 is selected in the low, moderate and high baselines, but it is not part of the privacy baseline. A system categorized at any impact level that carries AU-5 must define who gets alerted when audit logging fails, within what time, and what additional action follows. Confirm the impact categorization with your authorizing official before assuming a privacy-only system is out of scope, since a system that holds PII under a security baseline still needs the control. Check the exact selection in the current SP 800-53B profiles.

High baseline enhancements AU-5(1) and AU-5(2)

Enhancement AU-5(1) requires a warning when audit storage capacity reaches a defined threshold, and AU-5(2) requires real-time alerts for defined audit failure events. Both apply only in the high baseline, so a moderate system needs the base control alone. For a high system, confirm the thresholds, the recipients and the delivery path, since an alert that fires into an unmonitored mailbox does not meet the intent of either enhancement.

Which pipelines count as audit processes

Scope AU-5 by listing every component whose failure would stop audit records from being generated, transmitted or stored. This includes the application's own audit module, log shippers, message queues, collectors and the storage backend. A pipeline that drops records silently is still an audit process failure, so the scope should follow where records are created and where they must arrive, not only the logging library. Document each path so an assessor can trace a failure from source to alert.

Whether AU-5(5) alternate logging is in scope

AU-5(5) covers an alternate audit logging capability used when the primary capability fails. It replaced the withdrawn AU-15 in Rev. 5, so organizations that mapped older programs to AU-15 need to confirm whether they still hold the alternate capability. Decide whether an alternate store is required by your system's risk and mission, then document its trigger, its storage and how records are later merged. If you do not adopt AU-5(5), record the rationale in the system security plan.

Hosted services that produce audit records

Identify every third-party or hosted service that generates audit records the organization relies on, such as identity providers, cloud control planes, SaaS applications and managed databases. Their logging failures may fall outside your own alerting. Ask each provider how it reports audit processing failures, what notice it gives you, and whether you can pull its logs into your own alerting. Record these dependencies in the system inventory and the agreements that define them, so the AU-5 response covers them.

Responsible personnel and roles

AU-5 requires a defined list of personnel or roles to receive failure alerts, so the scope must name who is on it and how the list is kept current. Include system and network administrators, the audit and accountability owner and an on-call route for after-hours events. Assessors examine the notification list and interview the people on it, so confirm that each named role still exists and that the list matches your staffing and on-call rota.

How an assessor tests AU-5

This table walks through the SP 800-53A assessment procedure for AU-5, row by row, showing the determination statements, the examine, interview and test methods, and the evidence an assessor requests. Read each row as one thread of the same test: the organization must define who is alerted and how fast, and the system must demonstrably do it.

Assessment element	What the assessor does	Evidence requested and passing result
Determination statement 1: defined personnel and time	Examine the defined list of personnel or roles to be alerted and the defined alert time, then check they match the organization's parameter values	Current notification list with named roles, the documented alert time, and approval records. Passing result: the list and timing are defined, current and consistent with the policy
Determination statement 2: defined additional actions	Examine the defined actions taken on a logging failure, such as overwriting the oldest records or shutting the system down, and confirm they are selected deliberately	Documented action list tied to system risk, with rationale. Common finding: actions are named in the plan but the selection is never justified
Examine: notification list and system audit records	Review the notification list and sample system audit records or failure logs for entries showing failure events	Notification list plus failure records. Passing result: the list is current and failure events appear in audit records with timestamps
Interview: personnel with audit and accountability responsibilities	Ask the responsible roles how they learn of a logging failure, what they do first, and who decides on additional actions	Consistent answers that match the documented procedure. Common finding: staff describe a process the documents do not contain
Interview: system and network administrators	Ask administrators how logging failures surface to them, including out-of-hours, and how they confirm recovery	Consistent answers across shifts, plus on-call or escalation records. Common finding: the alert goes only to a shared mailbox nobody monitors
Test: mechanisms implementing the response	Induce or simulate an audit logging failure in a controlled test, then observe whether alerts fire within the defined time and the defined actions execute	Test record with timestamps, alert delivery proof and the resulting system state. Passing result: the alert arrives within the defined time and the action completes as documented
High baseline: AU-5(1) and AU-5(2)	For high-baseline systems, confirm a storage capacity warning threshold exists and that real-time alerts reach defined personnel for audit processing failures	Threshold configuration, alert rule export and a test alert. Common finding: warnings exist only for disk full, not for the earlier capacity threshold the organization defined

How to implement AU-5 in six steps

This sequence turns AU-5 from a policy statement into a working response: named recipients, a documented alert time limit, defined actions, configured detection, and a tested record that an assessor can examine. Each step produces an artifact that the next step depends on.

Define the notification recipients and roles
Start by naming the personnel or roles who must hear about an audit logging failure. Assessors check the list against the AU-5 determination statements, and the SP 800-53A examine objects expect a list of personnel to be notified. Include the people who administer the logging components and the people with audit and accountability responsibilities, and confirm each name with its current owner. The output is a signed notification list with role names, contact paths and a named backup for each role.
Set the alert time limit in writing
AU-5 requires the system to alert the defined recipients within a defined time after a logging process fails, so the organization must choose that time and document it. The value is an organizational decision, not a figure supplied here, so confirm the time limit with the system owner, the authorizing official and any contract or regulator that applies. Record the value in the AU-5 procedure or system security plan so that the time limit can be compared against the alerting configuration in a later step.
Choose the defined additional actions
AU-5 also requires defined actions when logging fails. The catalog guidance lists examples such as overwriting the oldest audit records or shutting the system down, and the organization must select what its system does and why. Consider the trade-offs for availability, evidence preservation and the audit records needed for investigations. The output is a written decision that names the action for each failure type, with the reasoning and the owner who approved it.
Configure detection of logging failures and capacity warnings
Build the detection that triggers the response. Confirm that each in-scope component reports its own logging failures, and for the high baseline, configure a storage capacity warning (AU-5(1)) and real-time alerts (AU-5(2)). Open-source tooling can help: Grafana Alerting builds alert rules from queries across data sources, and Prometheus can collect metrics from instrumented jobs. Confirm with each vendor which failure events each component emits, because the detection must match the components you actually run. The output is a configured alert rule for each failure condition, linked to the recipient list from step one.
Test the response with a deliberate failure
Run a controlled test that stops or blocks a logging process in a non-production environment, or in a maintenance window agreed in writing with the system owner. Measure whether the alert reaches the defined recipients within the documented time limit and whether the chosen additional action runs as written. Record each failure, detection, notification and action with timestamps. Where the test exposes a gap, fix the configuration and repeat the test. An assessor will look for this kind of test evidence, since the AU-5 test objects cover the mechanisms that implement the response.
Record the results and keep them current
Close the sequence by filing the evidence an assessor will examine: the signed notification list, the time limit, the action decision, the alert rule configuration, and the dated test record with any corrective actions. Assign an owner and a review trigger, such as a logging component change or a new system release, so the evidence is updated when the configuration changes. Organizations that work with an implementation partner should confirm in the written scope who maintains these records after handover. An independent assessor, not the implementation partner, decides whether the control is met.

Which evidence shows AU-5 is working

AU-5 is only as good as the proof that failures are noticed and handled. The cards below name the artifacts an assessor expects to see, from the notification list and alert configuration to the records of induced failures and real events. Each one needs a refresh process so it reflects the system as it runs today.

Approved notification list

This is the list of personnel and roles that must be told when an audit logging process fails, which the control requires the organization to define. Assessors compare it against current staff, on-call rotations and service owners. Keep it current by tying it to the joiner, mover and leaver process and to rotation schedules, and confirm each named role still exists in your identity system before each assessment. Record the date of each review and who approved the change.

Alert configuration and change history

Export the rules that detect a logging failure, the routes that deliver the alert, and the time within which it must reach the defined personnel. Assessors check that the configuration matches the defined time and actions. Store configuration in version control so every change has an author, a reason and a date. Review the export at each assessment and compare it to the last approved version to catch silent edits.

Test records of induced failures

Assessors look for evidence that the alerting and response actually fire. Plan controlled tests, such as stopping a log sink or filling a test audit volume in a non-production environment, then record the time the failure started, when the alert was received and which defined action ran. Repeat tests after significant changes to logging or alerting components. Keep the test plan, raw output and sign-off together so the record is complete.

Capacity warning thresholds

For the high baseline, AU-5(1) requires a warning when audit storage nears capacity. Document the threshold percentage, the storage locations it covers and the people who receive the warning. Revisit thresholds when log volume grows, when retention periods change or when new components start logging. Check the warning fires at the documented level during a test, and keep the dated threshold history so the assessor can see the value in force on any given day.

Response procedure and runbook

The written procedure should state who acts, what they do and in what order when a logging failure occurs, including any defined actions such as preserving the oldest records or shutting down the system where that is chosen. Assessors use it as the reference for the interview and the test. Review it after every failure event and after changes to the logging architecture, and confirm that the steps still match the tools in use. Record the review date and version.

Alert and action logs from real events

Records from actual logging failures show whether the process worked outside a test. Keep the alert timestamps, acknowledgements, actions taken and closure notes for each event, and link them to the related incident ticket. Assessors read these to confirm people responded within the defined time. Where no real failures occurred, say so and point to the test records instead, so the gap is visible and explained rather than hidden.

What meeting AU-5 costs in money and effort

This table breaks the cost of meeting AU-5 into its components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. NIST does not estimate compliance costs, so no fees or durations are given; use the drivers to structure a written quote. The main takeaway is that open-source tooling mainly removes license spend, while engineering, evidence upkeep and assessment remain the larger effort.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it up or down
Tooling or licenses	Software vendors, or no license fee for self-hosted open-source components	Recurring for commercial licenses; near zero license spend for open-source components	Number of log sources and alert channels; self-hosted open source can remove most license spend, but hosting and storage remain
Engineering to configure failure alerts	Internal platform or security engineers, or an implementation partner under a written scope	One-time, with later changes	Number of audit sources, how many failure conditions are defined, and whether alerts already exist in a monitoring stack
Engineering to configure capacity warnings and real-time alerts (high baseline)	Internal engineers or an implementation partner	One-time for setup, recurring for tuning	Whether the high baseline enhancements AU-5(1) and AU-5(2) apply, and how many storage locations must be watched
Defining personnel, time limits and actions	Organization's security and compliance owners	One-time, reviewed periodically	Number of roles to notify, how many response actions are defined, and how often the list of personnel changes
Evidence upkeep	Internal compliance staff or the platform team	Recurring	Frequency of test alerts, retained alert and configuration records, and how much is captured automatically versus manually
External testing or review	Independent testers or consultants, under a written scope	Recurring if scheduled, otherwise one-time	Depth of testing, whether failure paths are tested in production-like environments, and the number of systems in scope
Auditor sampling and assessment	Independent auditor or assessor, not the implementation partner	Recurring with each assessment cycle	Number of samples the assessor selects, quality of evidence on hand, and how many determination statements are in scope

Which self-hosted tools can produce AU-5 evidence

AU-5 evidence comes from showing that a logging failure was detected, routed to the right people and acted on. The four tools below cover different parts of that chain: metric and log alerting, pull-based collection of health signals, an audit log written by an application, and a request log from a secrets service. Each one must be confirmed against your own failure detection design before you rely on it.

Grafana Alerting for failure rules

Grafana Alerting builds alert rules from queries and expressions across multiple data sources, and it can alert on metrics and logs together from a single view. For AU-5, this is where a rule that fires when audit logging stops, slows or reports errors can be defined, along with the personnel or roles it notifies. Check that the rule covers the audit pipeline itself, not only the application, and that notification routing matches the people named in your AU-5 procedure. Keep the rule definitions and notification history as evidence.

Prometheus for health signals

Prometheus collects metrics from instrumented jobs through a pull model over HTTP and stores them as time series identified by metric name and labels, using autonomous local storage. It queries them with PromQL. For AU-5, the useful signal is a metric that shows the logging process is running, such as a heartbeat, a write error counter or a queue depth, so that silence becomes detectable. Confirm that your audit components expose such metrics and that the scrape job itself is monitored, since a failed scrape can hide a logging failure.

Nextcloud admin_audit logging

The admin_audit app in Nextcloud logs additional event information to audit.log in the data directory, or to a path set with logfile_audit. For AU-5, this file is the record whose failure must be detected. Check that the log path is on storage that is monitored for free space and write errors, because a full or unwritable file is a logging process failure. Test the alert by making the path unwritable in a non-production instance and confirming that the defined personnel are notified within the time your procedure sets.

OpenBao audit devices

OpenBao audit devices keep a detailed JSON log of every API request and response, including errors, and hash most sensitive values with HMAC-SHA256. For AU-5, the relevant behavior is that requests are recorded, so a failing audit device can be observed in the request path. Decide what the system does when an audit device cannot write, since behavior under failure determines whether you need additional actions such as halting requests. Confirm that device failures are alerted and that the hashed fields still support investigation in your environment.

Who owns AU-5 and what a partner can take on

The organization owns AU-5 because it must decide the parameters the control depends on. AU-5 requires defined personnel or roles, a defined time limit for the alert, and defined additional actions when audit logging fails. Those choices reflect the organization's risk tolerance, staffing and operating hours, so they cannot be delegated to a vendor or left to default settings.

Policy ownership: The security or audit function records the AU-5 parameters in the audit and accountability policy and procedures, and approves changes when systems or risks change.
Defined recipients: Name the roles, such as the on-call security analyst and system administrator, and keep the list current as staff change.
Time limit: Set the alert window in writing and confirm it matches what the monitoring tooling can actually deliver.
Defined actions: Decide whether the system overwrites the oldest records, halts, or fails over to alternate logging, and document who authorizes each action.
Ongoing review: Assign an owner to test the alert path and review failures found in operations.

Before engaging any partner, confirm that the parameters are written, approved and traceable to the assessed system boundary.

Where AU-5 usually fails in an assessment

AU-5 is rarely missing outright. Teams usually have some alerting, but the assessor finds that the recipients were never named, the time limit was never set, or the alert watches the wrong layer. Each card below names one gap and a check your team can run before the assessor asks.

Recipients and time limit undefined

AU-5 asks the organization to define who must be alerted and within what time after an audit logging failure. Assessors examine the list of personnel to be notified, so a role-based distribution list with named owners is the starting point. Check that the list exists in a document you control, that each name or role maps to a current person, and that the time limit is written as a number the team can test. A vague phrase such as "promptly" will not pass.

Alerts watch the agent, not the pipeline

A common gap is an alert that fires when the logging agent stops reporting but stays silent when the path from source to storage breaks, such as a full queue, a rejected write or a stalled collector. Map every hop in the audit path and confirm that each one emits a health signal. Then stop a single hop in a test environment and confirm that the alert reaches the defined personnel. Grafana Alerting can combine metrics and logs in one rule set, which helps cover more than one hop.

Storage capacity warnings never tested

Where the high baseline selects the storage capacity warning enhancement, the warning must fire before logs are lost. Teams often set a threshold and never see it trigger. Fill a non-production audit volume to the threshold and record the time to alert, the recipient and the ticket or message produced. Keep that record as evidence. Prometheus can collect disk usage from the host and expose it as a time series, so the threshold rule can be tested the same way as any other alert.

Defined actions never exercised

AU-5 requires defined additional actions after a failure, and the catalog guidance cites examples such as overwriting the oldest records or shutting the system down. A written choice that nobody has run is hard to defend. Decide which action applies to each system, document the reason, and run it once in a controlled window. Confirm that the system does what the document says, that the change is logged, and that the people responsible know how to reverse it. Shutdown options in particular need prior sign off from the system owner.

No evidence from real failures

Assessors look for records of how the process behaved during actual events, not only design documents. Keep the alert history, the notification log and the change tickets for each logging failure, including minor ones such as a brief collector restart. Review these records at a set interval and note whether the time limit was met. If no real failure has occurred, the test records from the controlled exercises become the evidence, and they should be dated and signed by the person who ran them.

Failure events missing from the audit trail

The failure itself should appear in the system's own records. Check whether the logging component writes its own errors to a location that is protected and retained, and whether the platform's audit device records the request that changed logging settings. OpenBao audit devices keep a JSON log of each API request and response, including errors, which can show who changed a logging configuration around the time of a failure. Confirm the retention of those records matches the AU-11 period your organization has set.

AU-5 questions buyers ask before hiring help

How much does it cost to meet AU-5 in a NIST SP 800-53 program?

No supplied figure gives a price for AU-5, and DeployOpen does not publish a price list. The cost is driven by how many systems produce audit logs, how many alerting paths exist today, and whether a logging pipeline already sends failure signals to people who act on them. Costs fall into two groups. One-time work covers defining who is notified, how fast, and what automated actions run, plus building and testing the alerting. Recurring costs cover staff time to answer alerts, licences or hosting for monitoring tools, and periodic review. A fixed-scope written quote should list each system in scope, each alert path, the enhancements selected (AU-5(1) and AU-5(2) apply only at the high baseline), and who owns ongoing operation.

How long does it take to implement AU-5 controls?

No supplied fact gives a duration for AU-5 work, so confirm any timeline against a written scope. The schedule depends mainly on the number of systems, whether logging failures are already detected, the state of the notification list, and how many approvals the organization needs for alerting rules and response actions. Work moves faster when the logging platform already exposes health metrics and when named roles exist. It slows when the team must first agree on the defined time for notification and the defined response actions, which the control leaves to the organization. Ask the provider to split the schedule into scoping, build, testing and evidence collection, so each stage has a visible exit point.

What does our team need to provide during an AU-5 engagement?

Your team owns the control, so it must supply decisions and access. Expect to provide a current list of personnel or roles who must be alerted when audit logging fails, the time frame you define for alerting, and the additional actions you choose, such as overwriting the oldest records or shutting a system down. Staff with audit and accountability responsibilities and system or network administrators must be available for interviews, and you must provide read access to audit records and to the mechanisms that respond to processing failures. For the high baseline, the team also needs the storage capacity thresholds and the real-time alert destinations used for AU-5(1) and AU-5(2).

Can our own team implement AU-5 without an outside partner?

Yes, an internal team can implement AU-5 if it has engineers who run the logging stack and staff who own the policy decisions. The hard parts are not the alert rules themselves. They are agreeing on defined personnel, defined times and defined actions, then proving that failures actually reach those people. Internal teams often underestimate testing: a failure must be induced or simulated, the alert must arrive, and the defined action must run and leave a record. An assessor will look for that evidence, so the team should document each test with its date, the failure simulated, and the result. Independent assessors, not the implementing team, decide whether the control is met.

Which AU-5 tasks are worth outsourcing to an implementation partner?

The tasks most worth outsourcing are the ones that need specialist build time and repeatable testing. These typically include configuring alerting rules for logging failures and storage thresholds, integrating self-hosted tools such as Prometheus, Grafana and OpenBao audit devices with notification channels, and writing test scripts that prove each failure path. Policy decisions on defined personnel, defined times and response actions should stay with your leadership, because the organization owns its controls. DeployOpen implements, hardens and documents self-hosted platforms in the client's own infrastructure and prepares evidence for assessment, but it does not issue assessment reports or certifications.

Can a consulting partner certify that we meet AU-5?

No. Only an independent assessor or auditor issues an assessment report or a certification. A partner can prepare the system, configure alerting, document the response design and assemble evidence, which assessors then examine and test. When you hire help, make sure the written scope says exactly what is delivered, such as configuration, test records and evidence packages, and that no deliverable claims compliance on the organization's behalf. Ask your assessor early which evidence they expect for AU-5, including the list of notified personnel, alert records, and test results for the defined actions.

What should we ask a provider for in a written AU-5 quote?

Ask for a fixed-scope quote that names each system and log source in scope, the defined alerting paths and destinations, the enhancements selected for the high baseline, the test method for each failure type, and the evidence each deliverable produces. Also ask who is paid for what: the provider's implementation work, your staff time, any licences or hosting you must buy, and any retainer for ongoing support or upgrades. Confirm which items are one-time and which recur. Finally, ask for the acceptance criteria and whether the provider will walk an independent assessor through the evidence.

How DeployOpen scopes and prepares AU-5 evidence

DeployOpen plans and implements self-hosted open-source logging and alerting inside your own environment so that audit logging failures are detected, alerted to named personnel and handled as your AU-5 procedures define. The organization owns its control decisions and response procedures, and an independent assessor reaches the conclusion on whether AU-5 is met.

How we scope

Written scope lists the systems whose audit logging failures must be detected and alerted for AU-5.
Scope names the personnel or roles to notify and the response actions you define for each failure.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure alert rules that fire when audit pipelines stop writing, drop records or hit storage limits.
Alerting is set up across the audit trail of each in-scope platform, such as the audit log of a self-hosted app.
Where high baseline enhancements apply, we test capacity warnings and real-time alert paths before handover.

How we hand over

Handover documents the alert configuration, notification lists, response actions and test results for AU-5.
Test records show each logging failure scenario triggered an alert to the defined recipients in your environment.
Your assessor receives the evidence set to examine, and only the assessor issues any report or conclusion.

How we support

Ongoing support and upgrades are available as a retainer, so alert rules keep pace with platform updates.
Periodic re-testing of failure alerts can be scheduled under the same retainer when your environment changes.
Ask us to confirm which alert and audit capabilities each platform version supports before you commit to a design.