AU-11: Audit Record Retention

AU-11 requires you to retain audit records for an organization-defined retention period so you can support after-the-fact investigations and satisfy regulatory and internal retention needs (NIST SP 800-53 Rev. 5 OSCAL JSON). Operationalize it by setting a defensible retention schedule, enforcing it across all log sources and storage tiers, and keeping evidence that retention is configured, protected, and consistently working.

Key takeaways:

• Define a single retention requirement that maps to each log source, storage location, and system boundary (NIST SP 800-53 Rev. 5 OSCAL JSON).
• Engineer retention into platforms (SIEM, cloud logging, endpoint, IAM, network) with immutable storage where appropriate, plus deletion controls.
• Keep assessor-ready artifacts: the retention standard, system-by-system mappings, and proof of enforcement (configs, screenshots, exports, and change records).

The au-11: audit record retention requirement sounds simple (“keep logs”), but auditors rarely fail teams on intent. They fail teams on scope, consistency, and proof. One business unit keeps security logs in the SIEM, another leaves them in a cloud service with default settings, and a third rotates logs locally with no central collection. During an incident, you cannot reconstruct actions. During an assessment, you cannot show retention is enforced.

AU-11 in NIST SP 800-53 Rev. 5 is explicitly about retaining audit records for a defined period to support investigations and meet regulatory and organizational retention requirements (NIST SP 800-53 Rev. 5 OSCAL JSON). That means you must (1) define the retention period(s), (2) ensure the technology actually retains those records, and (3) be able to prove it with durable evidence. The tricky part is operational: audit records exist across many layers (cloud control plane, OS, applications, databases, identity providers, endpoints, firewalls), and each layer has different retention knobs, costs, and failure modes.

This page focuses on requirement-level implementation guidance you can put into a control procedure, assign to owners, and test repeatedly.

Regulatory text

NIST excerpt: “Retain audit records for {{ insert: param, au-11_odp }} to provide support for after-the-fact investigations of incidents and to meet regulatory and organizational information retention requirements.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator translation: you must set an organization-defined audit-log retention period and make it real across the environment. “Retain” is an engineering outcome, not a policy statement. Your implementation has to preserve audit records long enough to investigate incidents that are discovered late, and long enough to satisfy any retention rules your organization has committed to (NIST SP 800-53 Rev. 5 OSCAL JSON).

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

AU-11 expects three things:

1. A defined retention requirement. Someone in your organization sets the retention duration and the rationale for it. NIST leaves the exact value as an organization-defined parameter (NIST SP 800-53 Rev. 5 OSCAL JSON).
2. Retention applied to audit records across the system boundary. Audit records are not only “security logs.” They include authentication, privilege changes, administrative actions, and application events that let you reconstruct “who did what, when, from where.”
3. Retention aligned to investigations and retention obligations. If a credible incident could be discovered after a long dwell time, retention must support that investigation. If your organization has separate retention requirements (contractual, regulatory, internal), AU-11 expects alignment (NIST SP 800-53 Rev. 5 OSCAL JSON).

Who it applies to (entity + operational context)

AU-11 commonly applies to:

• Federal information systems operating under NIST SP 800-53 control baselines (NIST SP 800-53 Rev. 5).
• Contractor systems handling federal data where NIST SP 800-53 is flowed down contractually or via authorization requirements (NIST SP 800-53 Rev. 5).

Operationally, the control applies wherever audit records are generated, transported, stored, and aged out, including:

• Central logging/SIEM and its underlying storage
• Cloud provider logging services (control plane and service logs)
• Identity providers (SSO, MFA, PAM)
• Endpoint security and EDR telemetry
• Network security devices (firewalls, proxies, DNS)
• Core business applications (including SaaS audit logs)
• Databases and data platforms where privileged actions occur

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

Use the sequence below to move from requirement to durable operations.

Step 1: Set the retention rule (and write it down)

• Define your audit record retention period as an explicit control parameter (the AU-11 “organization-defined” value) (NIST SP 800-53 Rev. 5 OSCAL JSON).
• Decide whether you need multiple tiers (for example, “hot” searchable retention vs. “cold” archived retention). If you do, document which audit record types go to which tier.
• Record decision inputs: investigation needs, contractual obligations, internal standards. Keep this short and concrete; auditors want traceability, not essays.

Deliverable: Audit Log Retention Standard (or section in your Logging Standard) with the AU-11 parameter defined (NIST SP 800-53 Rev. 5 OSCAL JSON).

Step 2: Inventory audit record sources and storage locations

Build a table that includes, at minimum:

• Log source (system/service)
• What events are captured (authentication, admin actions, data access, configuration changes)
• Where logs are stored (local, cloud logging service, SIEM, archive bucket)
• Current retention setting (configured value and where it is configured)
• Owner (system owner plus logging/SIEM owner)
• Coverage notes (gaps, exclusions, compensating controls)

This is where AU-11 efforts succeed or fail. Retention cannot be “global” if logs live in ten different places.

Deliverable: Audit Record Source & Retention Register.

Step 3: Engineer retention enforcement (don’t rely on defaults)

For each log source/storage location:

• Configure retention to meet the AU-11 parameter.
• Ensure retention settings are locked behind change control (role-based access, ticketed changes).
• If logs can be deleted early, add compensating controls:
  • Restrict deletion privileges to a small administrative group.
  • Enable immutable storage features where your platform supports it.
  • Monitor for retention policy changes and log deletions as security events.

Deliverables: Configuration evidence per platform (see “Evidence” section).

Step 4: Align retention with access control and integrity requirements

AU-11 is retention-focused, but assessors often test it alongside “can you trust the logs?”

• Make audit log storage access-controlled (read vs. administer vs. delete).
• Separate duties: the people who administer systems should not be the only people who can delete their logs.
• Ensure time synchronization is in place so retained logs can be correlated. (Time sync is typically covered elsewhere, but it affects AU outcomes in practice.)

Deliverable: Access control matrix for logging platforms and log storage.

Step 5: Prove it works with a repeatable test

Create an operational test you can rerun:

• Pick representative log sources from each category (cloud control plane, IAM, endpoints, application, network).
• Validate that logs older than the required minimum are still present and readable.
• Validate that attempted retention changes require approved access (or create an alert/ticket).

Deliverable: Quarterly (or assessment-cycle) AU-11 Retention Test Record with screenshots/exports.

Step 6: Make it auditable: map ownership, procedure, and recurring evidence

AU-11 assessments move faster when you can show clear control operations. Assign:

• Control owner (CCO/GRC accountable; logging engineering responsible)
• Operators (SIEM team, cloud platform team, app owners)
• Evidence cadence (what you collect, how often, and where it is stored)

Daydream fits cleanly here as a control operations hub: map AU-11 to an owner, link the procedure, schedule recurring evidence collection, and keep a single evidence packet for audits.

Required evidence and artifacts to retain

Keep evidence that shows policy, configuration, and operational reality.

Governance artifacts

• Audit Log Retention Standard with the defined AU-11 retention parameter (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Logging and Monitoring Policy (or equivalent) referencing audit record retention
• Data/records retention policy cross-reference (if separate from security)

Technical evidence ¹

• Screenshots or exports of retention settings in:
  • Cloud logging services
  • SIEM/index lifecycle policies
  • Archive storage lifecycle rules
  • SaaS audit log retention settings (admin console evidence)
• Access control evidence:
  • Roles/groups allowed to change retention or delete logs
  • Change control tickets or approvals for retention policy changes

Operational evidence

• Retention test records showing older logs are still present
• Incident or investigation examples (sanitized) showing use of retained logs for after-the-fact investigation (if available)
• Alerting rules for retention policy changes or log deletion events (where supported)

Common exam/audit questions and hangups

Expect assessors to ask:

• “What is your AU-11 retention period, and where is it documented?” (NIST SP 800-53 Rev. 5 OSCAL JSON)
• “Show me, in the tooling, that logs are retained for that period.”
• “Which systems are in scope, and which are excluded? Who approved exclusions?”
• “Can administrators delete or shorten retention? How do you prevent or detect that?”
• “If the SIEM is down, what happens to logs? Are they buffered, and for how long?”
• “Show evidence from multiple sources, not only the SIEM.”

Hangups that slow audits:

• Retention exists in the SIEM but not at the source (for example, SaaS audit logs set to default).
• Logs are retained, but not searchable, and no one can retrieve them in a reasonable time during an incident.
• Teams cannot prove historical settings because evidence is not captured after changes.

Frequent implementation mistakes (and how to avoid them)

1. Policy-only retention. A written standard with no verified configuration proof.
   Fix: require platform screenshots/exports and periodic tests.

2. Assuming the SIEM covers everything. Many critical audit trails never reach the SIEM (SaaS admin logs, PAM session logs, some cloud service logs).
   Fix: maintain the source register and reconcile it against your CMDB and cloud inventory.

3. Retention set, but deletion is easy. Broad admin roles can change lifecycle policies or delete buckets.
   Fix: narrow privileges, require tickets for changes, and alert on retention policy modifications.

4. Retention applied inconsistently across environments. Prod meets AU-11; non-prod and break-glass accounts do not.
   Fix: define scoping rules explicitly, then enforce via templates/IaC and platform guardrails.

5. No evidence trail for changes. You can’t show what retention was last quarter.
   Fix: store config exports with timestamps, and attach them to change tickets in Daydream or your GRC system of record.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-11, so you should treat AU-11 as an assessment-driven requirement: failures typically show up as audit findings, authorization risk, delayed incident response, and inability to meet contractual obligations for federal data environments (NIST SP 800-53 Rev. 5).

Risk shows up in real operations:

• Investigations stall because the needed time window is missing.
• Insider threat or privileged misuse cannot be reconstructed.
• Legal/regulatory requests become expensive because retrieval is manual or incomplete.

A practical execution plan (30/60/90)

Use these phases as a workable rollout pattern. Adjust sequencing to your environment.

First 30 days (Immediate)

• Name the AU-11 control owner and operators.
• Define the AU-11 retention parameter in the retention standard (NIST SP 800-53 Rev. 5 OSCAL JSON).
• Build the Audit Record Source & Retention Register for critical systems (identity, cloud control plane, SIEM, endpoints, network egress).

Next 60 days (Near-term)

• Configure retention and access controls for the top log sources that support incident investigations.
• Implement change control requirements for retention changes (tickets + approvals).
• Start collecting recurring evidence in a single AU-11 evidence packet (Daydream works well for this).

By 90 days (Operationalized)

• Expand the register to cover all in-scope systems and key third parties that provide audit logs.
• Run the retention test and document results plus remediation actions.
• Add monitoring for retention policy changes and log deletion events where platform support exists.

Frequently Asked Questions

What counts as an “audit record” for AU-11?

Treat any log that helps reconstruct user and administrative activity as an audit record, including authentication events, privilege changes, configuration changes, and key application actions (NIST SP 800-53 Rev. 5 OSCAL JSON). If it matters in an investigation, it belongs in scope.

Can we set different retention periods for different systems?

Yes, if you document the organization-defined values and the rationale, then apply them consistently per log source (NIST SP 800-53 Rev. 5 OSCAL JSON). Auditors usually accept tiered retention when it is explicit and evidenced.

Is “stored in the SIEM” enough to pass AU-11?

Only if the SIEM actually receives the relevant audit records and retains them for the required period. You still need evidence that upstream sources and downstream storage rules support the same retention outcome.

How do we prove retention without dumping huge log exports into evidence?

Use configuration exports (index lifecycle rules, bucket lifecycle policies, SaaS admin retention settings) plus a targeted test that retrieves older records across representative sources. Keep the minimal artifacts that prove settings and outcomes.

What about third-party and SaaS systems where we can’t control retention?

Document the retention limits, assess whether they meet your AU-11 parameter, and add compensating controls (more frequent export to your archive/SIEM, contract requirements, or risk acceptance). Keep evidence of the configuration and your decision.

Who should own AU-11: security operations or GRC?

GRC should be accountable for the requirement definition and evidence readiness; security operations and platform owners should be responsible for implementation and testing. Daydream can track this split cleanly by mapping AU-11 to owners, procedures, and recurring artifacts.

Footnotes

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