AU-5(5): Alternate Audit Logging Capability

AU-5(5) requires you to keep audit logging running even if your primary logging pipeline fails by implementing a pre-defined alternate logging capability. Operationalize it by designing a fallback path (agent/buffer/secondary collector), defining failover triggers and responsibilities, testing the switchover, and retaining evidence that logs stayed available and tamper-resistant during logging outages. ¹

Key takeaways:

• Build a fallback logging path that works during SIEM/collector outages, not just a backup of stored logs. ¹
• Define clear failover triggers, roles, and escalation so the alternate logging capability activates consistently under stress.
• Test and document failover; auditors will ask for proof that the alternate path works, not just architecture diagrams.

AU-5(5): Alternate Audit Logging Capability is a resilience requirement for your audit trail. It expects that if your primary audit logging capability fails (for example, a centralized log collector is down, a forwarder misconfigures, a network path breaks, or your SIEM is unavailable), the system still produces and retains audit records through an alternate method. The control text is short, but the implementation work is real: you have to decide what “alternate” means for your environment and prove it works in practice. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat AU-5(5) like a runbook-backed engineering control with measurable outcomes: (1) audit events continue to be captured during a primary logging failure, (2) the organization can recover and reconcile any buffered/offline logs, and (3) you can show evidence of testing and operation. This page gives requirement-level guidance you can hand to Security Engineering and Infrastructure, plus the evidence bundle you’ll need for an assessor.

Regulatory text

Requirement (excerpt): “Provide an alternate audit logging capability in the event of a failure in primary audit logging capability that implements [alternate audit logging functionality].” ¹

Operator interpretation: You must implement a secondary way to capture audit logs when the primary path fails. “Alternate audit logging functionality” is organization-defined in NIST language, so you must explicitly specify what the alternate capability is (technical design) and when it is invoked (operational trigger), then validate it through testing and evidence. ¹

Plain-English interpretation (what AU-5(5) really demands)

AU-5(5) is about continuity of audit evidence. If your main logging pipeline breaks, you still need an audit trail that supports detection, investigation, and accountability.

In practice, auditors look for three things:

1. A credible failure mode is identified (what “primary audit logging capability” means in your stack).
2. An alternate logging path exists (not theoretical) and is protected from easy tampering.
3. Proof of operation exists (testing records and/or incident evidence showing continued logging during outages).

Examples of “primary logging capability”:

• Centralized syslog/SIEM forwarder and collector
• Cloud-native log sinks (e.g., a single log subscription, stream, or workspace)
• A single endpoint log agent fleet without local buffering

Examples of “alternate logging capability”:

• Local journaling/buffering on hosts with later forward/replay
• Secondary collector endpoint in another environment/account/region
• Dual-write to two independent logging backends
• Out-of-band storage of critical audit events (for example, immutable object storage as a parallel target)

Who it applies to

Entity scope

• Federal information systems and systems operated by contractors handling federal data commonly inherit NIST SP 800-53 controls as contractual or authorization requirements. ²

Operational scope (what systems you include) Apply AU-5(5) to systems where loss of audit logs would materially impact investigations, compliance reporting, or incident response. Common targets:

• Identity systems (SSO, directory, PAM)
• Security tooling (EDR, vulnerability management)
• Network/security infrastructure (firewalls, gateways)
• Production workloads handling sensitive data
• Admin control planes (cloud management logs)

A workable scoping approach: start with “systems required to produce audit records” under your broader AU program, then prioritize those with single points of failure in logging.

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

Use this as an operator checklist you can turn into a control card and an engineering ticket set.

1) Define the primary logging capability and failure modes

• Document your current log pipeline for each major platform (on-prem, cloud, SaaS):
  • Event source → agent/forwarder → transport → collector → storage/SIEM
• Identify realistic failures:
  • Collector down, ingestion quota exceeded, certificate expired, routing misconfig, network segmentation change, agent crash, API outage
• Pick the failure(s) AU-5(5) must cover first: focus on the most likely and highest impact.

Output: “Logging Architecture & Failure Mode Register” (short, system-by-system).

2) Define “alternate audit logging functionality” in concrete terms

NIST expects you to fill in the bracketed part with your chosen alternate functionality. ¹

Define, at minimum:

• What data is captured during failover (minimum audit event set)
• Where it is stored (and why it remains available)
• How long it can buffer before risk becomes unacceptable
• How integrity is protected (permissions, immutability where feasible)
• How logs reconcile back into the primary system after recovery

Decision matrix (choose a pattern):

Pattern	Works best when	Pros	Common pitfalls
Local buffer + later forward	Endpoint/host logs, intermittent connectivity	Simple, resilient to collector outages	Buffer overruns; no alerting on backlog
Dual-write to two collectors	Central syslog-style environments	Immediate redundancy	Coupled failures if same network/IAM
Secondary logging account/tenant	Cloud logs	Reduces blast radius	Cross-account permissions drift
Immutable storage as alternate sink	High-integrity needs	Strong evidence preservation	Ingestion format/searchability gaps

3) Implement activation triggers and responsibilities (the runbook)

AU-5(5) becomes fragile when nobody knows when to declare “primary logging failure.”

Define:

• Triggers: e.g., ingestion health checks failing, queue depth threshold, error rate spike, missing heartbeat logs from critical sources
• Owners: Security Operations (detection), Platform/SRE (restore), GRC (evidence)
• Escalation: who gets paged and who can declare failover
• Communication: incident channel, ticket template, and required timestamps

Control design tip: Put the trigger logic in monitoring, not in a human inbox.

4) Validate with a failover test (tabletop plus technical test)

Auditors will ask: “How do you know it works?”

Minimum validation package:

• Tabletop: walk through a collector outage and the decision to fail over
• Technical: intentionally block primary ingestion in a lower environment (or controlled window) and show:
  • Events still generated
  • Alternate sink receives them or buffer holds them
  • Recovery procedure reconciles and no silent loss occurs

5) Operationalize with recurring health checks and drift control

Alternate logging breaks quietly over time due to:

• Agent upgrades
• IAM/policy drift
• New services not onboarded
• Route/DNS changes

Put in place:

• A recurring “logging continuity health check” owned by Security Engineering/SRE
• Automated checks where possible (synthetic audit events, heartbeat logs)
• A remediation workflow with due dates and closure evidence

6) Build the evidence bundle (so you can pass audits quickly)

Treat this control like an always-on capability with point-in-time proof.

Required evidence and artifacts to retain

Keep evidence in a single, assessor-friendly location (GRC repository) with stable naming.

Minimum evidence bundle

• Control card / control narrative: objective, scope, owner, triggers, steps, exceptions
• Architecture diagram showing primary and alternate logging paths
• Configuration evidence (screenshots/exports):
  • Agent buffering settings or dual destination configs
  • Secondary collector endpoints and access controls
  • Storage controls for alternate sink (permissions, immutability settings if used)
• Monitoring and alerting evidence:
  • Health checks for ingestion/collector availability
  • Alerts for backlog growth or missing heartbeats
• Test evidence:
  • Test plan, date, participants
  • Results (before/during/after screenshots or logs)
  • Issues found and tracked to closure
• Exception log:
  • Systems not covered yet, compensating controls, and target remediation date

Retention note: AU-5(5) does not set retention duration by itself; align retention to your broader audit logging and incident response requirements.

Common exam/audit questions and hangups

Expect these questions from assessors, customers, and internal audit:

1. “What is your primary audit logging capability?”
   They want a specific system-of-record description, not “we use a SIEM.”

2. “What constitutes failure, and how do you detect it?”
   If you cannot show objective triggers, the alternate capability looks ad hoc.

3. “Show me evidence from a real outage or a test.”
   A diagram is not evidence of operation.

4. “Does the alternate log path preserve integrity?”
   They’ll probe permissions, admin access, and whether an attacker could erase buffered logs.

5. “How do you ensure new systems are covered?”
   Onboarding and change management tie-in is a frequent gap.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: “Backup” replaces “alternate.”
   Backing up the SIEM database does not help if logs never reach the SIEM during an outage. Build a path that captures events during the failure window.

2. Mistake: Alternate path exists but nobody monitors it.
   Add health checks for the alternate sink and for backlog/buffer conditions.

3. Mistake: Same blast radius for primary and alternate.
   If both depend on the same IAM role, same network segment, or same collector cluster, a single issue can take both out. Separate trust boundaries where feasible.

4. Mistake: No reconciliation story.
   Buffered/offline logs that never get replayed leave investigative gaps. Document recovery steps and validate them in testing.

5. Mistake: Evidence scattered across teams.
   Centralize your AU-5(5) evidence bundle. Tools like Daydream help by turning the requirement into a control card with an explicit minimum evidence checklist, plus recurring control health checks and remediation tracking.

Enforcement context and risk implications

No public enforcement cases were provided in the source material for AU-5(5), so treat this as a control assurance and incident survivability issue rather than a “known fine” issue.

Risk outcomes when AU-5(5) is weak:

• Inability to reconstruct incidents that coincide with logging outages
• Loss of accountability for privileged/admin activity during tool downtime
• Audit findings for control design (no defined alternate functionality) or control operation (no tests/evidence)

This control also matters in third-party due diligence: customers frequently ask how you ensure logs are captured during SIEM outages and how you prevent gaps during high-severity incidents.

Practical 30/60/90-day execution plan

Use phases rather than calendar promises. Move as fast as your engineering bandwidth allows.

First 30 days (Establish design + ownership)

• Assign an AU-5(5) control owner (Security Engineering or Platform/SRE) and a GRC evidence owner.
• Document primary logging architecture and top failure modes for in-scope systems.
• Choose your alternate pattern(s) per platform (local buffer, dual-write, secondary account/collector).
• Draft the AU-5(5) control card: triggers, runbook, and evidence bundle.

Days 31–60 (Implement the alternate capability for critical systems)

• Implement alternate logging for your highest-risk systems first (identity, admin planes, production).
• Add monitoring:
  • Ingestion heartbeat checks
  • Backlog/buffer alerts
  • Collector availability checks
• Define the reconciliation workflow (replay/backfill) and document the steps.

Days 61–90 (Test, harden, and make it repeatable)

• Run a controlled failover test and retain the evidence package.
• Fix gaps found in testing (permissions, missing sources, buffer sizing, alert noise).
• Add change-management hooks:
  • New system onboarding includes logging + alternate logging requirements
  • Periodic health check with tracked remediation items to closure
• Prepare an assessor-ready folder: control narrative, configs, monitoring, test results, exception log.

Frequently Asked Questions

Does AU-5(5) require a second SIEM?

No. It requires an alternate audit logging capability when the primary logging capability fails. For many environments, local buffering with later forward/replay or a secondary collector endpoint meets the intent if it is defined, monitored, and tested. ¹

What counts as “primary audit logging capability” in a modern cloud stack?

Treat the end-to-end pipeline as the capability: event generation, forwarding/transport, collection, and storage/search. If any single component failure creates a logging blackout for in-scope systems, that component is part of the primary capability you must backstop.

Can local disk logs satisfy the alternate capability?

They can, if you configure durable storage, access controls, and a documented process to forward/reconcile logs after recovery. You also need evidence that the buffer does not silently drop events and that you detect backlog conditions.

How do we prove this control in an audit if we haven’t had a real outage?

Run a planned failover test in a controlled environment or maintenance window and retain the test plan, screenshots/exports, and results. Auditors generally accept testing evidence when it clearly demonstrates continued logging during simulated primary failure.

What’s the minimum evidence assessors ask for most often?

A defined alternate logging design (diagram + configuration), a runbook with triggers and owners, monitoring/alert proof, and a failover test record. If any one of those is missing, the control often fails on “operating effectiveness.”

How does Daydream help with AU-5(5) specifically?

Daydream is useful for turning AU-5(5) into an operator-grade control card (objective, owner, triggers, steps, exceptions), standardizing the evidence bundle, and running recurring control health checks with tracked remediation to closure.

Footnotes

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

2. NIST SP 800-53 Rev. 5