AU-15: Alternate Audit Logging Capability

AU-15 requires you to keep audit logging working even when your primary logging path fails by establishing an alternate audit logging capability you can switch to quickly. Operationalize it by designing a failover logging architecture, defining trigger conditions and manual/automatic switchover steps, testing the switchover, and retaining evidence that the alternate path reliably captures required audit events. ¹

Key takeaways:

• Build a documented, testable alternate path for audit event generation, transport, and storage, not just “SIEM redundancy.”
• Define clear failover triggers and roles so operations can switch logging modes under pressure.
• Prove it works with recurring tests and retain artifacts that show events remained complete and protected during failure modes.

AU-15: alternate audit logging capability requirement is a resilience control for your detection and investigation pipeline. You are being asked to plan for the reality that logging breaks: agents crash, collectors fill disks, TLS certs expire, network segments partition, or a cloud logging service throttles. When that happens, your incident response team loses timelines, your forensics get weaker, and you may fail to meet system and contractual obligations tied to monitoring and accountability.

For a CCO, GRC lead, or security compliance owner, the fastest path to operationalizing AU-15 is to treat logging like a safety-critical service with a defined “backup mode.” That backup mode must still collect audit events that matter, preserve integrity, and be reachable by authorized personnel. The point is not perfection; it is controlled degradation and a practiced switchover.

This page gives you requirement-level guidance you can hand to engineering: what to build, how to run it, what evidence to retain, and what auditors typically probe. It also covers how to assign ownership and keep the control alive quarter after quarter, including how tools like Daydream help you map AU-15 to owners and recurring evidence without turning it into a spreadsheet exercise. ¹

Regulatory text

Control requirement (excerpt): “NIST SP 800-53 control AU-15.” ²

Operator interpretation: You must implement an alternate capability to capture and retain audit logs when the primary logging capability is unavailable or degraded. Practically, this means you define (1) what “primary logging” is for your system boundary, (2) what failure conditions matter, (3) what “alternate logging” looks like end-to-end, and (4) how you will switch to it and validate it works. ¹

Plain-English interpretation

AU-15 expects that audit logging does not become a single point of failure. If your normal path is “host/app generates events → forwarder/agent → collector → SIEM/data lake,” AU-15 asks: what happens if any link breaks? Your alternate capability can be technical (secondary collectors, local buffering with protected storage, secondary cloud account, alternate transport) and/or procedural (manual steps to enable OS native audit, export logs, or re-route pipelines). The alternate capability must be documented, accessible during an outage, and tested.

A useful mental model: AU-15 is disaster recovery for audit evidence. The “RTO/RPO” framing is helpful internally, but you do not need to claim any numeric target to satisfy the requirement. You do need to show a designed method to continue capturing audit events and a history of exercising that method. ¹

Who it applies to (entity and operational context)

Entities:

• Federal information systems.
• Contractor systems handling federal data. ²

Operational contexts where AU-15 is commonly assessed:

• Systems authorized under federal risk programs (for example, systems aligned to NIST SP 800-53 control baselines).
• Multi-tenant SaaS environments supporting federal customers where logging is part of shared responsibility.
• High-availability environments where “logging outages” have occurred historically due to scaling, agent instability, or misconfiguration.

What’s in scope: Anything within your system boundary that generates or transports audit-relevant events: endpoints, servers, managed databases, IAM logs, cloud control plane logs, network devices, containers, and the log pipeline itself.

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

Use this as an implementation runbook for the au-15: alternate audit logging capability requirement.

1) Name the control owner and define the system boundary

• Assign a primary owner (often SecOps or Platform Engineering) and a compliance partner (GRC).
• Define “primary audit logging capability” in one paragraph: event sources, collection method, and storage location(s).
• Define who has authority to invoke alternate logging mode during incidents.

Daydream tip: Track AU-15 as a discrete control with a named owner, procedure link, and recurring evidence tasks so it stays operational after the assessment window. ²

2) Identify minimum audit event sources that must survive a logging outage

Create a short “must not lose” list aligned to your risk:

• Identity events (authn/authz, privilege changes).
• Administrative actions (configuration changes, policy edits).
• Data-access events for sensitive datasets (as applicable).
• Security detections and EDR alerts (where available).

Write this list into your AU-15 procedure so on-call engineers know what to validate during failover.

3) Design the alternate logging architecture (end-to-end)

Document an alternate capability that covers three layers:

A. Alternate event generation/collection

• If agents fail, can you fall back to OS-native logging with increased verbosity?
• If app logging is centralized, can the app write to local append-only storage temporarily?

B. Alternate transport

• Secondary log forwarder/collector endpoint in a different failure domain.
• Out-of-band path for emergency export (for example, secured object storage dropbox) with access controls.

C. Alternate storage and integrity

• Separate storage location (or separate account/project) with restricted write/delete permissions.
• Immutable or tamper-evident storage settings where feasible.
• Clear retention rules for alternate logs and how they merge back into primary analysis stores.

You are not required to pick a specific tool. You are required to make the alternate path real, reachable, and protected.

4) Define failover triggers and the switchover procedure

Write a short operational procedure that answers:

• Trigger conditions: collector unavailable, sustained ingestion failure, queue backlog, storage full, API throttling, certificate failure, region outage.
• Detection: who gets paged and how you know primary logging is degraded.
• Switchover steps: exact commands/config flags, where to change routing, who approves, and how you communicate.
• Backout/return to primary: how you return safely without dropping buffered logs or duplicating records.

Keep this procedure in the same repository as incident runbooks. Make it executable during an outage (no dependency on the failed system).

5) Test the alternate audit logging capability

Testing is where most teams fail AU-15 in practice. Do a planned exercise that simulates a real break:

• Disable or isolate the primary collector.
• Confirm events still generate, still transmit (or buffer), and land in alternate storage.
• Confirm access controls prevent unauthorized deletion or modification.
• Confirm the team can retrieve logs for an investigation workflow.

Retain the artifacts (see next section). If you cannot test in production, test in a staging environment that matches the logging pipeline architecture and document the limitations.

6) Operationalize monitoring and maintenance

Your alternate path will rot without maintenance. Add:

• Monitors for primary ingestion health and alternate readiness (connectivity, credentials, storage capacity).
• Change management hooks: any logging pipeline change requires validating the alternate path still works.
• Onboarding checklists: new services must be added to both primary and alternate logging designs.

Required evidence and artifacts to retain

Auditors usually want proof of design and operation. Keep evidence in a centralized GRC repository with clear dates and owners.

Design artifacts

• AU-15 procedure/runbook: triggers, roles, switchover steps, return-to-normal steps.
• Logging architecture diagram showing primary and alternate paths.
• Inventory of in-scope audit event sources and where they log in primary vs alternate mode.
• Access control design for alternate log storage (roles, permissions, immutability settings where used).

Operational artifacts

• Test plan and test results for alternate logging (screenshots, command outputs, tickets, postmortems).
• Incident tickets where alternate logging was invoked (if applicable) plus evidence logs were captured.
• Monitoring alerts showing detection of primary logging failure and/or alternate path readiness checks.
• Change records that show the alternate capability was reviewed/updated after pipeline changes.

Mapping artifacts (assessment readiness)

• Control-to-owner mapping and recurring evidence schedule for AU-15 (this is where Daydream typically saves time and prevents “we did it once” decay). ²

Common exam/audit questions and hangups

Expect these questions from assessors aligned to NIST SP 800-53:

1. “Define your primary audit logging capability.”
   They want system boundary clarity, not a vendor name.

2. “What failure modes did you design for?”
   If you only planned for “SIEM down,” they will probe agents, network, credentials, and storage capacity.

3. “Show me you can still capture critical events during an outage.”
   Bring a test record or an incident record, plus sample log entries from the alternate store.

4. “How do you protect alternate logs from tampering?”
   Be ready to show least privilege, separation of duties, and write/delete protections.

5. “How do you know alternate logging is still configured correctly?”
   They are looking for monitoring, periodic exercises, and change management ties.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails AU-15	How to fix it
“Our SIEM is redundant” with no alternate collection path	Redundant analytics does not equal alternate capture if collectors/agents fail	Build an alternate path for collection/transport/storage, not only SIEM HA
Alternate logging exists but no one can operate it	During incidents, tribal knowledge disappears	Put a runbook in the on-call system; practice switchover
Local buffering with no integrity protections	Attackers or admins can delete/alter local logs	Restrict permissions, centralize as soon as possible, document controls
Testing is skipped	You cannot prove the capability works	Run a planned failure simulation and retain artifacts
Alternate storage is in same failure domain	Regional/account-level outage can take both down	Separate failure domains where feasible; document assumptions and residual risk

Enforcement context and risk implications

No public enforcement cases were provided in the source material for AU-15, so this page does not cite specific actions or settlements.

Risk-wise, AU-15 failures tend to surface in three ways:

• Incident response gaps: you cannot reconstruct timelines or scope.
• Audit findings: assessors document an unavailable or untested alternate logging capability.
• Contractual exposure: federal customers and primes often require demonstrable continuity of security logging aligned to NIST SP 800-53. ¹

A practical 30/60/90-day execution plan

Avoid calendar promises tied to implementation complexity. Use this phased plan as a “start-to-operate” path and adjust scope to your system size.

First 30 days (Immediate build-ready work)

• Assign AU-15 owner and approvers; write the one-page AU-15 runbook skeleton.
• Document primary logging architecture and identify critical audit sources.
• Choose alternate design pattern(s) per environment (cloud, on-prem, containers).
• Create an evidence checklist and a place to store artifacts (tickets, runbooks, diagrams).

Days 31–60 (Implement and integrate)

• Implement alternate routing/storage for highest-risk log sources first (identity, admin actions).
• Add monitoring for ingestion failures and alternate readiness (credentials, connectivity, capacity).
• Lock down alternate storage access and document permissions.
• Update incident response runbooks to include AU-15 switchover decision points.

Days 61–90 (Prove operation and make it durable)

• Run a failover exercise; capture logs and produce a short test report.
• Remediate gaps found in the exercise and re-test targeted fixes.
• Add AU-15 checks to change management for logging pipeline changes.
• In Daydream, set recurring evidence tasks so you always have current test results, diagrams, and runbooks ready for assessors. ²

Frequently Asked Questions

Does AU-15 require a second SIEM?

No. AU-15 asks for an alternate audit logging capability, which can be alternate collection, transport, or storage. A second SIEM can be part of the design, but you still need a working alternate path that captures events when the primary path fails. ¹

Can “local log buffering” count as the alternate capability?

It can, if you document how buffering is enabled, protected from tampering, monitored for capacity, and drained to central storage after recovery. Auditors will ask how you prevent deletion or alteration while logs are buffered. ¹

What’s the minimum evidence to show an assessor?

Provide an architecture diagram, a short switchover runbook, and test artifacts that show primary logging was disrupted and alternate logging still captured defined audit events. Add access control evidence for the alternate store. ¹

How do we handle AU-15 in serverless and managed cloud services?

Treat the cloud control plane logs and service-native logs as primary sources, then design an alternate export or secondary destination (for example, a separate account/project sink) that remains available if the primary destination fails. Document shared responsibility boundaries explicitly. ¹

Who should own AU-15: Security or Platform Engineering?

Platform Engineering often owns implementation because they run the logging pipeline, while Security/GRC owns the requirement interpretation and evidence. Write both roles into the AU-15 procedure so failover authority is clear. ¹

If we’ve never had a logging outage, do we still need AU-15 testing?

Yes. AU-15 is about demonstrating an alternate capability exists and works under failure conditions, not about whether you have experienced an outage. A planned exercise provides the cleanest operational proof. ¹

Footnotes

1. NIST SP 800-53 Rev. 5

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