| Field | Detail |
|---|---|
| Control ID | AU-11 |
| Control name | Audit Record Retention |
| Framework | NIST SP 800-53, Revision 5 |
| Control family | Audit and Accountability |
| Baselines | LOW MODERATE HIGH PRIVACY |
| Relevance | Organization (First Party and Third Party) |
| Risk severity | Medium |
What this control requires
Audit record retention (AU-11) requires organizations to define and enforce how long they keep audit records to support investigations and compliance. It’s one of the foundational controls in the AU control family, and it applies across all baselines, including privacy.
In practice, this requirement means you need a documented policy that specifies how long you keep each category of audit records, where you store them, and how you protect them during the retention window. The control explicitly calls out Freedom of Information Act (FOIA) requests, subpoenas, and law enforcement actions as use cases that drive retention requirements.
Specifically, when you define retention periods, NIST expects you to align with the National Archives and Records Administration (NARA) General Records Schedules for federal systems. For private-sector organizations, the retention period should reflect your regulatory landscape, contractual obligations, and internal risk appetite. In practice, retention isn’t just about keeping records; it’s about keeping them retrievable, intact, and admissible when they’re needed.
Why it matters
Most organizations treat audit record retention as a storage problem. It’s actually a defensibility problem. When an incident response team, auditor, or legal counsel asks for records that no longer exist, the gap doesn’t just slow down the investigation. It undermines your ability to demonstrate due diligence.
The result is a compounding risk across multiple compliance domains. Inadequate retention policies can trigger findings during SOC 2 audits, create obstacles to demonstrating ISO 27001 5.28 Collection of Evidence requirements, and expose organizations to sanctions when regulators request historical log data that’s already been purged.
Where this breaks down most often is in the gap between policy and execution. An organization might have a written retention policy that says “retain for three years,” but if log rotation or storage cost optimization quietly purges records at 90 days, the policy is meaningless. Audit record retention is only as strong as the technical controls enforcing it.
Take vendor ecosystems as an example. If your third-party providers can’t demonstrate their own audit retention practices, your compliance posture inherits that weakness. Regulatory frameworks increasingly expect organizations to verify that vendors maintain adequate record-keeping, not just assume it.
What attackers exploit
- Insufficient retention windows that allow forensic evidence to age out before an intrusion is even detected, given that intrusions often go undetected for months before discovery
- Gaps between policy and implementation where retention policies exist on paper but log infrastructure silently discards records through automated rotation
- Lack of integrity protections on archived audit records, enabling post-compromise tampering with historical logs to cover tracks
- Decentralized log storage across cloud environments, SaaS platforms, and on-premises systems where retention enforcement is inconsistent
- Vendor blind spots where third-party service providers don’t retain audit data long enough to support joint incident investigations
How to implement
For your organization
The core implementation challenge with AU-11 isn’t technical complexity. It’s organizational alignment. Retention periods must satisfy legal, compliance, security operations, and privacy teams simultaneously, and those groups rarely agree on timelines without deliberate coordination.
Step 1: Define retention categories and periods. Don’t apply a single blanket retention period to all audit records. Instead, classify records by sensitivity and regulatory requirement. Authentication logs, privileged access records, and configuration change logs typically warrant longer retention than routine system health data. Map each category to a specific retention period supported by your regulatory obligations.
Step 2: Implement tiered storage. Use hot storage for recent records that support active monitoring and incident response, and cold or archival storage for records that satisfy long-term retention requirements. This approach manages cost without sacrificing availability. Common tooling categories include security information and event management (SIEM) platforms, centralized log management systems, and cloud-native archival storage.
Step 3: Enforce retention through automation. Manual retention management is a compliance liability. Configure automated lifecycle policies that move records through storage tiers and prevent premature deletion. Build in safeguards that require explicit approval before any retention policy change takes effect.
Step 4: Validate integrity and retrievability. Retained records are useless if they’ve been corrupted or can’t be located when needed. Implement integrity verification (checksums or write-once storage) and periodically test your ability to retrieve archived records within a reasonable timeframe.
Common mistakes:
- Setting a single retention period for all log types regardless of sensitivity or regulatory requirements
- Relying on default log rotation settings that conflict with the documented retention policy
- Failing to account for cloud provider log retention defaults, which may be shorter than your requirements
- Not testing whether archived records can actually be retrieved and read after extended storage periods
For your vendors
When AU-11 applies to your vendor ecosystem, the challenge shifts from implementation to verification. You can’t enforce retention policies inside a vendor’s environment, but you can establish contractual expectations and validate evidence of compliance.
Step 1: Include retention requirements in contracts. Define minimum audit record retention periods in your vendor agreements and service-level expectations. Specify which categories of records must be retained and for how long. Make clear that the vendor must produce records upon request for incident investigation or audit purposes.
Step 2: Request retention evidence during assessments. During vendor security assessments, ask for documentation of the vendor’s audit record retention policy and procedures. Look for specifics, not just a statement that records are “retained as required.” You want to see defined retention periods, storage mechanisms, and evidence of integrity protections.
Step 3: Validate alignment with your own requirements. Compare the vendor’s stated retention periods against your regulatory obligations. If your compliance framework requires three years of audit records and a critical vendor retains logs for only 90 days, that gap becomes your risk. Escalate misalignments and negotiate remediation timelines.
Step 4: Monitor for changes. Vendor retention practices can shift without notice, especially after infrastructure migrations or cost-cutting initiatives. Include retention policy validation as a recurring item in your vendor review cycle, not a one-time assessment checkbox.
Common mistakes:
- Assuming vendors retain audit records for the same duration as your organization without verifying
- Accepting a vendor’s general security certification as evidence of adequate retention practices
- Failing to define what “audit records” means in vendor contracts, leaving room for interpretation
- Not establishing a process for requesting vendor log data during incident investigations
Evidence examples
The following artifacts demonstrate AU-11 compliance and align with ISO 27001 logging requirements for evidence preservation.
| Evidence type | Example artifact |
|---|---|
| Retention policy documentation | Audit record retention policy specifying retention periods by record category, approved by CISO or compliance officer |
| System security and privacy plans | Sections of the system security plan and privacy plan addressing audit log retention requirements and procedures |
| Retention period definitions | Organization-defined retention periods for each audit record category, cross-referenced to regulatory requirements |
| Archived audit records | Samples of archived audit logs demonstrating records retained beyond the minimum required period |
| Storage and integrity controls | Configuration documentation for archival storage, including write-once settings, checksums, or integrity verification mechanisms |
| Audit log lifecycle evidence | Screenshots or exports from SIEM or log management platforms showing automated retention and tiering policies |
| Retrieval test results | Documentation from periodic retrieval tests confirming archived records remain accessible and intact |
Cross-framework mapping
| Framework | Control(s) | Coverage |
|---|---|---|
| ISO 27001:2022 | 5.28 Collection of evidence | Partial |
| ISO 27001:2022 | 8.15 Logging | Partial |
| NIST SP 800-171 Rev 3 | 03.03.03 Audit Record Generation | Partial |
Related controls
- AU-02 Event Logging defines which events generate audit records, directly determining the scope of what AU-11 must retain.
- AU-04 Audit Log Storage Capacity ensures sufficient storage exists to support the retention periods defined by AU-11.
- AU-05 Response to Audit Logging Process Failures addresses what happens when logging breaks down, which can create gaps in the records AU-11 is meant to preserve.
- AU-06 Audit Record Review, Analysis, and Reporting depends on retained records being available for ongoing analysis and reporting.
- AU-09 Protection of Audit Information provides the integrity and access controls that keep retained audit records trustworthy throughout the retention period.
- AU-14 Session Audit generates session-level records that fall within AU-11’s retention scope.
- MP-06 Media Sanitization governs how audit records are securely destroyed when they reach the end of their retention period.
- RA-05 Vulnerability Monitoring and Scanning produces scan results and findings that may need to be retained as part of the audit record.
- SI-12 Information Management and Retention provides the broader organizational framework for information lifecycle management, of which audit record retention is a specific subset.
Frequently asked questions
What is NIST SP 800-53 AU-11?
AU-11 is the audit record retention control within the NIST SP 800-53 framework, requiring organizations to define and enforce specific time periods for keeping audit logs. It applies across all baselines (LOW, MODERATE, HIGH, and PRIVACY) and addresses the need to preserve log data for incident investigations, legal proceedings such as FOIA requests and subpoenas, and regulatory compliance obligations. The control works alongside related controls like AU-02 (Event Logging) and AU-09 (Protection of Audit Information) to ensure audit records are generated, protected, and retained for as long as they’re needed.
What happens if AU-11 is not implemented?
Without AU-11 implementation, organizations lose the ability to support after-the-fact investigations because the audit records needed to reconstruct events may no longer exist. This gap creates direct exposure during compliance audits, where assessors expect documented retention policies and evidence that records are preserved according to defined organizational requirements. It also weakens legal defensibility, since courts and regulators may view missing audit records as evidence of inadequate controls or, worse, intentional destruction.
How do you audit AU-11?
Auditing AU-11 starts with verifying that the organization has defined specific retention periods for each category of audit records, aligned with regulatory and operational requirements. Assessors then examine whether retained audit logs, archived records, and system configurations match those documented periods. The assessment also includes testing whether archived records can actually be retrieved and used, confirming that retention isn’t just a policy statement but a functional capability backed by the audit and accountability policy, system security plan, and supporting procedures.
How long should audit records be kept?
There’s no single answer because retention periods depend on your regulatory requirements, industry, and operational needs. Federal agencies typically follow NARA General Records Schedules, which prescribe specific timelines for different record types. For private-sector organizations, common benchmarks range from one year for routine operational logs to seven or more years for records subject to financial regulations or legal hold requirements. The critical principle is that your defined retention period must be long enough to support incident investigations, given that many breaches aren’t discovered for months after initial compromise.