AU-5(5): Alternate Audit Logging Capability

AU-5(5) requires you to maintain an alternate way to capture audit logs when your primary logging path fails, so security and compliance monitoring does not go dark during outages. Operationalize it by defining what “logging failure” means for your environment, engineering a secondary log collection route, and proving via testing and evidence that failover actually works. ¹

Key takeaways:

• You need a designed-and-tested backup logging path, not a promise to “restore logging quickly.” ¹
• Scope the alternate capability per system boundaries and critical log sources, then automate detection and failover where feasible.
• Evidence matters: architecture, alerting, failover tests, and log integrity/retention proof are what auditors ask for.

A primary audit logging pipeline can fail in predictable ways: log forwarders crash, agents stop, disks fill, network paths break, certificates expire, or a SIEM ingest endpoint is unavailable. AU-5(5): alternate audit logging capability requirement exists to keep you collecting audit records even during those failures, so incident response, forensics, and accountability are still possible. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing AU-5(5) is to treat it like a resilience requirement for evidence. You are not only building a technical failover; you are defining control intent, ownership, system scope, failure modes, and testable acceptance criteria that an assessor can verify. Your deliverable is a working alternate logging capability aligned to your organization-defined parameters (the control’s “ODP”), with repeatable tests and retained artifacts. ¹

This page gives requirement-level implementation guidance: who owns it, what to implement, how to test it, what evidence to retain, and what audit teams commonly challenge.

Regulatory text

Control requirement (excerpt): “Provide an alternate audit logging capability in the event of a failure in primary audit logging capability that implements {{ insert: param, au-05.05_odp }}.” ¹

What the operator must do:

1. Decide what “alternate audit logging capability” means for your system (the organization-defined parameters in the control). ¹
2. Implement a secondary method to capture and preserve audit logs when the primary method fails. ¹
3. Prove the alternate method activates and preserves required audit records under real failure conditions, then keep evidence.

Use the NIST SP 800-53 Rev. 5 catalog as the authoritative control source for your assessment mapping and SSP language. ²

Plain-English interpretation (what AU-5(5) is really asking)

AU-5(5) expects continuity of audit logging. If your SIEM is down, your log forwarder is broken, or an endpoint agent stops, you still need an alternate path that records events and preserves them until normal operations resume. This is about avoiding blind spots that coincide with outages or attacks.

A practical interpretation that works in assessments:

• Detect primary logging failure quickly (alerts).
• Fail over to an alternate capture mechanism (secondary collector, local spooling with protected storage, alternate transport, or alternate destination).
• Preserve audit records with integrity and retention controls (so “alternate” does not mean “temporary and lossy”).
• Reconcile after recovery (backfill to central platform, document gaps, and close incidents).

Who it applies to

Entity types and environments

• Federal information systems implementing NIST SP 800-53 controls. ¹
• Contractor systems handling federal data (common in FedRAMP and federal contract security baselines) where 800-53 controls are inherited or directly implemented. ¹

Operational context (where the control is assessed)

• Systems with centralized logging (SIEM, log analytics, SOC platform).
• Systems where audit logs are relied on for investigations, privileged access monitoring, and compliance reporting.
• Hybrid estates with fragile log paths (endpoint agents + forwarders + message queues + SIEM ingest).

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

1) Assign control ownership and define scope

• Control owner: usually Security Engineering or Platform Engineering for implementation; GRC owns the requirement mapping and evidence cadence.
• System scope: define system boundary (what is “in-system” vs shared services), then list in-scope log sources: OS, IAM/SSO, cloud control plane, application logs, databases, network/security tools.
• Critical events: document which event categories must not be lost (authentication, authorization changes, admin actions, key security alerts).

Deliverable: control statement in your SSP/control library that describes the alternate logging design at a system-specific level. ¹

2) Define “primary logging failure” and trigger conditions (your ODP)

Because AU-5(5) references organization-defined parameters, you must write down the triggers that represent failure in your environment. ¹

Examples of testable triggers (choose what fits):

• SIEM ingest unavailable (health check fails).
• Log forwarder queue backlog exceeds threshold (define your threshold).
• Agent stopped / service not running.
• Local disk spooling limit reached.
• TLS/cert failures to logging endpoint.

Deliverable: a short “Logging Failure Definition” standard (1–2 pages) that includes triggers, detection method, and owner/on-call routing.

3) Design an alternate audit logging capability (architectural patterns)

Pick a pattern that is realistic to operate. Auditors care that it works, is documented, and is within the system boundary or explicitly addressed via shared services.

Common patterns:

• Dual-destination forwarding: send logs to two independent endpoints (primary SIEM + secondary storage/collector).
• Local protected spooling + later forwarding: endpoint/app writes to local append-only files or protected queue when upstream is down; a forwarder drains backlog when restored.
• Secondary collector tier: if primary aggregator is down, clients fail over to a standby collector in another zone/account.
• Out-of-band audit trail for privileged operations: for high-risk admin actions, write to a separate audit system (for example, cloud-native audit logs to a dedicated account).

Minimum design requirements to document:

• How alternate logging is activated (automatic failover vs manual runbook).
• What log sources are covered by alternate capability (and what is excluded with justification).
• How you prevent tampering (permissions, immutability controls where available, access monitoring).
• How logs are time-synchronized and correlated after recovery.

4) Implement monitoring and alerting for logging pipeline health

AU-5(5) is hard to defend if you cannot prove you detect failure and switch to alternate capture. Implement:

• Heartbeat/health checks for forwarders and collectors.
• Alerts for ingest drops, zero-events anomalies, queue growth, and agent downtime.
• Incident tickets created and tracked to closure.

Evidence focus: alerts firing + incident records + remediation steps.

5) Write and operationalize runbooks (even if failover is automated)

Runbooks should answer:

• Who declares “primary logging failure”?
• What switches to alternate mode?
• How do you verify logs are being captured in the alternate destination?
• How do you backfill into the central platform after recovery?
• What is the escalation path if alternate logging also fails?

6) Test the alternate logging capability and keep the proof

Testing is where many programs fail audits. You need a planned, repeatable test that simulates primary logging failure and demonstrates:

• Detection occurred (alerts).
• Alternate logging captured audit events during the failure window.
• Logs remained intact and retrievable.
• Backfill/reconciliation completed (or you documented gaps and root cause).

A practical approach:

• Tabletop test (walkthrough) for process validation.
• Technical test in non-production mirroring key pipelines.
• Controlled production test during a maintenance window if feasible.

7) Map the requirement to recurring evidence artifacts (keep it assessable)

A recurring evidence plan prevents “we built it once” drift. Daydream can help here by mapping AU-5(5) to a named control owner, implementation procedure, and a recurring evidence checklist so you do not rebuild proof during an audit cycle. ¹

Required evidence and artifacts to retain

Keep artifacts tied to the system boundary and dated for auditability:

1. Control narrative / SSP excerpt describing alternate logging design and triggers. ¹
2. Logging architecture diagram showing primary path and alternate path, including destinations and trust boundaries.
3. Configuration evidence (sanitized):
   • Forwarder configs showing dual outputs or spool settings.
   • Collector/SIEM configs showing secondary ingest endpoint.
   • Access control settings for alternate log store.
4. Monitoring and alert evidence:
   • Alert definitions and routing.
   • Screenshots/exports showing alerts triggered during tests or incidents.
5. Test package:
   • Test plan, date, participants, steps executed.
   • Output samples: example events generated during outage, stored in alternate location.
   • Results summary + defects/remediation tickets.
6. Operational runbook and on-call procedure for logging outages.
7. Exception register for any log sources not covered, with compensating controls.

Common exam/audit questions and hangups

Assessors typically ask:

• “Show me what happens when your SIEM is down. Where do logs go?”
• “How do you know logging failed? What alert fires?”
• “Which systems are covered by alternate logging? Prove it with inventory.”
• “During the outage window, can you retrieve logs and demonstrate integrity?”
• “How often do you test failover, and where is the evidence?”

Hangups that slow audits:

• Alternate logging exists only for infrastructure logs, not critical SaaS/IAM audit trails.
• The design relies on a second destination that is not actually independent (same account, same network dependency, same credentials).
• Teams cannot demonstrate retrieval of logs from the alternate path during a real outage window.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: “Alternate” equals “we’ll fix the SIEM quickly.”
   Avoidance: build a secondary capture route that records events during the outage, not after it.

2. Mistake: No written failure definition.
   Avoidance: define triggers and responsibilities so detection and response is consistent.

3. Mistake: Local spooling without protection.
   Avoidance: lock down file permissions, restrict admin access, and monitor for tampering. Document the controls that protect the spool.

4. Mistake: Testing only in theory (tabletop only).
   Avoidance: run a technical failover test and retain raw outputs and screenshots/exports.

5. Mistake: Scope gaps hidden in “shared services.”
   Avoidance: document inherited controls and shared logging services explicitly in the SSP, including alternate logging coverage.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite case law or settlements. What matters operationally is assessment risk: if logging fails during an incident, you may be unable to reconstruct events, support disciplinary/accountability actions, or meet reporting obligations tied to security monitoring. That becomes a control effectiveness issue and can drive POA&M items, delayed authorizations, or contractual findings in federal contexts. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and design)

• Name the AU-5(5) control owner(s) and approver.
• Inventory log sources and identify “must-not-lose” event categories.
• Define primary logging failure triggers and alerting requirements (ODP).
• Choose an alternate logging pattern per log source class (endpoint, cloud, app, IAM).
• Draft runbook and test plan.

Days 31–60 (implement and instrument)

• Implement alternate destination/spooling for the highest-risk sources first (IAM/admin actions, critical workloads).
• Configure health monitoring and alert routing to on-call.
• Restrict access to alternate log storage and document permissions.
• Run a technical failover test in a non-production environment that mirrors the pipeline.

Days 61–90 (prove operation and make it repeatable)

• Execute a controlled failover test for production-critical sources where feasible.
• Produce an evidence package: diagrams, configs, alerts, test outputs, tickets.
• Close gaps with tracked remediation items and exceptions where justified.
• Set a recurring evidence cadence in your GRC tooling so tests, configs, and screenshots are captured consistently; Daydream can structure this mapping and evidence checklist so audit prep is procedural, not ad hoc. ¹

Frequently Asked Questions

What qualifies as an “alternate audit logging capability” for AU-5(5)?

Any secondary method that captures required audit logs when the primary logging path fails, and keeps them retrievable and protected until normal logging resumes. Document what “alternate” means for your system boundary and prove it with testing. ¹

Can local log files count as the alternate capability?

Yes, if you treat them as an engineered fallback: protected storage, monitored capacity, controlled access, and a documented backfill process to central logging. Auditors will ask how you prevent deletion or tampering and how you reconcile after recovery.

Does AU-5(5) require automatic failover?

The text does not mandate automation, but manual failover must still be reliable and testable. In practice, automation reduces the risk of gaps during off-hours and short outages. ¹

How do we handle SaaS audit logs (SSO, ticketing, CI/CD) that we don’t control?

Treat the SaaS export/collection mechanism as the “primary” path and implement an alternate collection or retention approach where possible (for example, secondary export destination or dedicated archive). If you cannot implement alternate capture, document an exception and compensating monitoring within your system’s SSP.

What evidence do auditors expect to see for AU-5(5)?

A documented design, alerting that detects failure, proof that alternate logging captured events during a simulated failure, and retrieval/backfill evidence. Keep dated artifacts so you can show the control operates, not just that it was designed. ¹

How should we document the organization-defined parameter (ODP) part of AU-5(5)?

Write down your failure triggers, what log sources must be covered, and what actions occur during failover (automatic or manual). Then align monitoring thresholds, runbooks, and test cases to those definitions. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5