Audit Record Retention

Audit record retention (NIST SP 800-53 Rev. 5 AU-11) requires you to keep security-relevant logs for a defined retention period so you can расслед incidents after the fact and satisfy retention obligations. To operationalize it, set and document retention requirements, configure logging platforms to enforce them, and preserve proof that logs are retained, protected, searchable, and retrievable. ¹

Key takeaways:

• Define one retention standard per log category and map it to every in-scope system in your FedRAMP boundary. ¹
• Make retention enforceable in tooling (SIEM, cloud logging, endpoints), not just in policy, and capture configuration evidence.
• Prove operability: retrieval tests, access controls, and review/ticket evidence that logs support investigations and monitoring.

For a FedRAMP Moderate system, audit logs are not “nice to have” evidence. They are the primary record that supports incident investigation, continuous monitoring, and assessor testing. AU-11 is the control that forces the question every assessor and agency reviewer will ask during an authorization or annual assessment: “Can you reliably go back in time and reconstruct what happened, across all boundary components, for long enough to meet your obligations?” ¹

The core challenge is operational, not philosophical. Most teams have logs scattered across cloud-native services, SaaS consoles, endpoints, identity providers, and network/security tools. Retention breaks when one source has a short default time window, when storage lifecycle rules delete too early, or when a migration cuts over and drops historical data. AU-11 also fails quietly when logs exist but are not retrievable in practice, for example due to indexing gaps, permission issues, or an inability to prove integrity.

This page translates AU-11 into an execution checklist: scope, define retention, implement in tools, validate retrieval, and package evidence for assessors. It also calls out the exam questions that typically turn a “we retain logs” statement into a finding.

Regulatory text

Requirement (AU-11): “Retain audit records for an organization-defined time period to provide support for after-the-fact investigations of incidents and to meet regulatory and organizational information retention requirements.” ¹

What the operator must do

1. Pick and formally approve the “organization-defined time period.” AU-11 is explicit that the retention period is defined by you, but it must be defined, documented, and implemented consistently. ¹
2. Ensure the retention period supports investigations. Your retention choice must be defensible for incident response timelines and audit needs, not just storage cost. ¹
3. Meet “regulatory and organizational information retention requirements.” If other obligations apply (contractual, agency, internal), AU-11 expects your retention standard to align. ¹

Plain-English interpretation

You need a written retention rule for audit logs, and you must actually keep the logs long enough to investigate incidents after they are discovered. “We log events” is insufficient; “we can still retrieve the relevant logs later” is the standard you must meet. ¹

Assessors tend to evaluate AU-11 by sampling:

• A handful of systems (identity, compute, network, app, database),
• A few key event types (auth, privilege, admin actions, policy changes),
• Your ability to retrieve logs from a prior period, and
• Proof that automated lifecycle policies do not delete early.

Who it applies to

Entity scope

• Cloud Service Providers (CSPs) operating a system seeking or maintaining FedRAMP authorization. ¹
• Federal agencies responsible for implementing and maintaining the authorized baseline for systems they operate or sponsor. ¹

Operational scope (what’s “in”)

AU-11 applies to audit records generated by systems inside the FedRAMP authorization boundary, including infrastructure, platforms, applications, security tooling, and identity services used to administer or access the system. If a third party system produces audit data that is necessary to reconstruct security-relevant actions in-boundary, treat that log stream as in scope for your retention design and evidence package.

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

1) Build an audit log source inventory (boundary-first)

• Export a list of all in-boundary components from your SSP/asset inventory, then map each to its logging source(s).
• Include “control plane” sources that teams often miss: IdP admin logs, CI/CD audit trails, secrets manager audit logs, KMS key usage logs, and ticketing/privileged access audit trails (if used for boundary administration).

Output artifact: “Audit Log Source Register” with: system name, log source, owner, log location, retention setting, and retrieval method.

2) Define retention requirements by log category (and document rationale)

Create a retention standard that is simple enough to implement. A practical pattern is to define categories such as:

• Identity & access logs
• Privileged/admin activity logs
• Network/security device logs
• Application and database audit logs
• Cloud platform activity logs
• Endpoint/EDR logs (if in boundary)

For each category, specify:

• Retention duration (your organization-defined period),
• Storage tier/locations (hot vs archive, if applicable),
• Integrity expectations (immutability/WORM controls if you use them),
• Access restrictions (who can read/export),
• Retrieval SLA expectation (how quickly you can produce logs for IR/audits).

Key decision point: If you can’t implement one standard everywhere, write exceptions with compensating controls and approval. AU-11 tolerates “organization-defined,” but assessors won’t tolerate “we’re not sure” or “it depends on the tool.” ¹

Output artifacts: Logging & Retention Standard (policy/standard) and an exceptions register.

3) Configure retention in each logging system (make it enforceable)

Implement the retention period in the actual platforms:

• SIEM/data lake retention and index lifecycle settings
• Cloud logging retention settings and storage lifecycle rules
• Backup/archival policies if logs are exported to object storage
• SaaS audit log export jobs, if the SaaS native retention is shorter than your standard

Execution tip: Don’t rely on a SIEM alone if sources can disappear upstream. If a cloud service only retains logs natively for a limited time, export continuously into your retention store and document that pipeline.

Output artifacts: Screenshots/exports of retention configurations, lifecycle policies, and log export job configs.

4) Protect logs from deletion or tampering (prove integrity controls exist)

AU-11 is about retention, but “retained” has implied integrity expectations in audits. Make sure:

• Only authorized roles can delete indexes/buckets or alter lifecycle policies.
• Administrative actions on logging systems themselves are logged and reviewed.
• Changes to retention settings are change-controlled.

Output artifacts: IAM role mappings, change tickets for retention changes, and audit logs for the logging platform.

5) Validate retrieval with an operational test

Run a repeatable “log retrieval test”:

• Pick sample events (a known admin change, a login, a config update).
• Confirm you can retrieve the record from your retention store.
• Record: query used, date range, system, and results.

This is the fastest way to turn AU-11 from “paper compliance” into something an assessor can trust.

Output artifacts: Retrieval test record, saved queries, and exported sample logs (redacted as needed).

6) Operationalize ongoing monitoring evidence (tie AU-11 to operations)

AU-11 is commonly assessed alongside log review/monitoring controls. Keep evidence that logs are used:

• Review notes, alerts, and follow-up tickets
• Escalation and triage records
• Proof that gaps are remediated (e.g., “log source silent” incident tickets)

This aligns with common best-practice expectations for audit record programs and supports your continuous monitoring posture. ¹

Where Daydream fits: Daydream can track log-source-to-retention mappings as a living control record, attach config evidence and retrieval tests, and keep review/ticket evidence packaged for assessors without scrambling each assessment cycle.

Required evidence and artifacts to retain

Use this as your AU-11 evidence checklist:

Evidence item	What it proves	Typical owner
Logging & Retention Standard (approved)	Your organization-defined time period exists and is authoritative 1	GRC/CCO + Security
Audit Log Source Register (system-to-log mapping)	Boundary coverage and accountability	Security Eng / IT
Retention configuration exports/screenshots	Retention is implemented in tooling	Security Eng / Cloud Ops
Storage lifecycle policies (object storage/archive)	Logs aren’t deleted early	Cloud Ops
Access control/IAM evidence for log stores	Limited ability to alter/delete logs	IAM/SecOps
Change tickets for retention modifications	Controlled changes and traceability	ITSM/Change Mgmt
Log retrieval test results	After-the-fact investigation support 1	SecOps/IR
Review evidence, alerts, and follow-up tickets	Logs are monitored and acted on 1	SecOps

Common exam/audit questions and hangups

Expect these during FedRAMP assessments and agency reviews:

1. “What is your retention period, exactly, and where is it documented?” If the answer is scattered across tools, you’ll lose time and credibility. ¹
2. “Show me retention settings for these sampled systems.” Auditors often select identity, cloud control plane, and a production workload.
3. “Prove you can retrieve logs from earlier periods.” A live retrieval demo or documented test is high-value evidence. ¹
4. “How do you ensure logs are not deleted or altered?” Expect questions about who can change lifecycle policies and who can delete indexes/buckets.
5. “What happens during migrations or tool changes?” Assessors look for continuity plans that preserve history.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Defining retention in policy but leaving default tool retention unchanged. Fix: require configuration evidence for each log system and link it to the standard.
• Mistake: Assuming SIEM ingestion equals retention. Fix: verify upstream sources do not expire before ingestion; confirm storage lifecycle rules in the SIEM backend.
• Mistake: Ignoring SaaS/third party admin logs used for boundary operations. Fix: add them to the Audit Log Source Register and implement export pipelines where needed.
• Mistake: No proof of retrievability. Fix: schedule periodic retrieval tests and store results as assessor-ready evidence.
• Mistake: Weak change control over retention settings. Fix: restrict permissions and require change tickets for retention and lifecycle policy changes.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-11, so this page does not list specific actions.

Risk-wise, AU-11 failures show up as:

• Investigation blind spots: You can’t reconstruct actions after discovery of an incident. ¹
• Authorization and continuous monitoring friction: You may be unable to provide operating evidence during assessor testing and ongoing submissions. ¹

Practical 30/60/90-day execution plan

Use a staged approach that produces assessor-grade evidence quickly, then hardens coverage.

First 30 days (stabilize and define)

• Approve the Logging & Retention Standard with your organization-defined periods. ¹
• Build the Audit Log Source Register for all boundary systems.
• Identify gaps where native retention is shorter than your standard; open remediation tickets.

Days 31–60 (implement and evidence)

• Configure retention and lifecycle policies in each logging source/store; capture config evidence.
• Lock down permissions that allow deletion or retention changes; document roles and approvals.
• Implement or validate exports from SaaS/cloud-native logs into your retention store where needed.

Days 61–90 (prove operability)

• Run retrieval tests for representative sources; store test scripts/queries and results. ¹
• Package evidence in an assessor-ready folder structure (by system or by log category).
• Add an ongoing cadence: review the Audit Log Source Register during change management, and re-test retrieval after major platform changes.

Frequently Asked Questions

What does “organization-defined time period” mean for AU-11?

You choose the retention period, but you must document it, get it approved, and implement it consistently across in-scope systems. Auditors will test whether your tools actually enforce the period. ¹

Do I need one retention period for every system?

You can define retention by log category rather than per system, as long as every system maps to a category and exceptions are documented and approved. The risk is unmanaged variation that you can’t defend during assessment.

If our SIEM retains logs, do we still need retention settings at each source?

Often yes. Some sources expire or roll over before the SIEM ingests, and some SaaS platforms cap native retention. Treat “source-to-store continuity” as part of your AU-11 design, and document export pipelines where needed.

What evidence is most persuasive to an assessor for AU-11?

Configuration evidence of retention settings plus a retrieval test that demonstrates you can pull historical logs to support an investigation. Add change tickets for any retention modifications to show control over lifecycle changes. ¹

How do we handle retention during a logging platform migration?

Plan for continuity: export old logs to an archive that meets your retention standard, document chain of custody, and prove retrieval from both “old” and “new” stores during the transition. Keep the migration change record and post-migration retrieval test results.

Where should AU-11 be documented for FedRAMP?

Document the requirement in your SSP control narrative and keep detailed implementation evidence (registers, configs, tests) in your assessment evidence repository. FedRAMP templates and document expectations are published by the program. ²

Footnotes

1. NIST Special Publication 800-53 Revision 5

2. FedRAMP documents and templates