AU-11 Audit record retention: requirements and evidence

What AU-11 audit record retention requires and why it fails in practice

An assessor who asks for your defined audit record retention period and proof that logs from several months ago still exist is testing AU-11 directly. The control asks the organization to retain audit records for an organization-defined period that supports after-the-fact incident investigations and meets regulatory and organizational information retention requirements. Passing it means three things are true at once: the period is written down, the platform is configured to keep records for that period, and you can produce older records on request. Many programs fail on the first point before anyone looks at a log store. If no one defined the number, the configuration has nothing to enforce, and the assessor has nothing to compare the evidence against.

The failure modes are predictable. The first is an undefined period, where the retention figure lives in a conversation rather than in a policy or system security plan. The second is rotation by default settings: a log rotation policy, a Bareos pruning job or a container log driver quietly discards records long before the defined period ends, and nobody notices until an investigation needs them. The third is archives that cannot be read, such as backups written in a format or with keys that no longer work, or log stores that were migrated and left unindexed. The fourth is no owner. Retention spans the logging platform, the backup system and the storage team, so without a named accountable role each one assumes another is covering it. Confirm which retention settings each component actually applies, and test a restore of a months-old record before the assessment starts.

SP 800-53B selects AU-11 for the low, moderate and high baselines and for the privacy baseline, so it applies at every impact level. The long-term retrieval enhancement, AU-11(1), is not selected in any SP 800-53B baseline. Organizations should still decide whether they need it, because a retention period is only useful if records remain retrievable in a usable form for the whole period. Ask your assessor or the authorizing official how they will treat the enhancement, and confirm with your legal and records teams which retention rules apply to your data. The definition and test steps for AU-11 are in the NIST CPRT entry for AU-11.

Which logs, systems and third parties fall under AU-11 retention

Retention under AU-11 applies only to audit records the organization has chosen to generate and keep, so scope comes first. The cards below cover the decisions that change how much evidence must be retained, for how long, and where copies live.

Audit sources inside the system boundary

Decide which applications, identity providers, cloud control planes, backup tools and secrets managers write audit records that belong to the system under assessment. Each source in the boundary needs a defined retention period, and each one outside it should be documented as out of scope with the reason. Ask the assessor to confirm the boundary before retention periods are set, because a missing source is a gap found late. Self-hosted platforms such as Nextcloud keep audit output in files that must be included in the retention plan.

Records with regulatory retention duties

Some records must be kept for a period set by a regulator or contract, which can exceed the period needed for incident investigations. Identify which record types, such as access to payment or health data, fall under those duties and set the longer period for them. Confirm the governing rule with legal counsel, since AU-11 requires the organization to define the period rather than the control text setting one.

Privacy baseline and PII in retained records

The privacy baseline applies AU-11 regardless of impact level, so it changes how long personal data sits in logs. Retention for PII should be the shortest period that still supports investigations and legal duties, with the rationale recorded. Coordinate with the AU-3 decision on limiting PII in records, because data removed at creation cannot be recovered at retention review. Confirm the approach with the privacy office.

Secrets managers and identity logs

Secrets managers and identity providers record authentication and secret access events that investigators often need months later. OpenBao audit devices write a detailed JSON log of every API request and response, with most sensitive values hashed, so the retained volume and sensitivity both need review. Decide whether these logs are retained in the same store as application logs, and confirm that hashed values remain protected for the full retention period.

Backup tools and retained backup catalogs

Backup systems create their own audit trail and hold catalogs that show what was backed up and restored. Bareos keeps a SQL catalog of backed-up files, and its job records are needed to show when restores occurred. Set retention for these catalogs and job logs separately from the backup data itself, and check that restore events can be traced for the defined period. Verify that the retained data is still readable, since restic can read pack files back with its read-data check.

Cloud and hosting providers holding copies

Cloud control plane logs and provider-side copies of audit data may sit outside the organization's own storage, with their own default retention. Identify each provider that stores a copy, read its retention settings, and decide whether the organization's period or the provider's governs. Ask each provider to confirm in writing how long copies persist and how the organization can export them before the provider deletes them. Where the provider's period is shorter, export to organization-controlled storage.

How an assessor tests AU-11 retention

This table walks through the single AU-11 determination statement in SP 800-53A and shows, for each examine and interview object, how an assessor tests retention, what evidence to prepare and where retention programs commonly fail. Read it as a checklist of what the assessor will ask to see, and confirm the exact wording of the procedure against the SP 800-53A text before relying on it.

Assessment element	Test approach	Evidence to prepare	Common finding
Determination statement (one statement)	Confirm the organization defined a retention period for audit records and that the system is set up to keep records for that period to support after-the-fact investigations and retention requirements.	Written, approved retention period tied to incident investigation and regulatory needs; configuration showing the system keeps records for that period.	Retention period stated in policy but never set in the logging or storage configuration.
Examine: organization-defined retention period	Compare the stated period with the obligations the organization must meet, such as contract, sector or regulatory retention terms.	Retention schedule with the source of each requirement; sign-off by the owner of the obligation.	Period chosen without reference to any named obligation, or the schedule is undated and unversioned.
Examine: audit record archives	Sample archives from different periods and check they exist, are complete for the stated window and are not overwritten early.	Archive inventory with date ranges, storage locations and immutability or lock settings where used.	Archive gaps for part of the window, often caused by rotation settings or a storage quota.
Examine: audit logs	Check the active logs and rotation or purge settings against the defined period.	Logging and rotation configuration files, with change history showing who altered retention settings.	Log rotation deletes records sooner than the policy period, with no alert or exception record.
Examine: audit records	Pick specific events from earlier in the retention window and confirm the records are present and readable.	Records returned for a sample event selected by the assessor, with the query or export used to retrieve them.	Records exist on disk but cannot be parsed or matched to a user or time without manual rebuilding.
Interview: personnel with retention responsibilities	Ask who owns the retention period, who approves changes and how requests to extend or shorten it are handled.	Named owners in a RACI or equivalent; records of approved exceptions.	Owners cannot state the period, or the role has changed hands with no handover record.
Interview: system and network administrators	Ask how retention is implemented, how backups of logs are handled and how they would retrieve records from an older period.	Runbook for retention settings, archive restores and checks; description of the last retrieval test.	Administrators describe the setting from memory and have never restored an archive from the oldest part of the window.
Related follow-up (outside the single statement)	Assessors often probe whether archives can be retrieved on demand, which supports the AU-11(1) enhancement that is not selected in any baseline.	Documented restore test with timing and result; a note on whether the organization has elected to adopt AU-11(1).	Archives exist but a restore test has never been run, so their usability is unproven.

Implementing AU-11 retention in six steps

This sequence turns the AU-11 requirement into a retention decision that is agreed, mapped to each log source, configured, protected, tested and kept under review. Each step produces a record that an assessor can examine.

Define the retention period with owners
Work with legal counsel, the compliance lead and the data owners to set the organization-defined retention period for audit records. Identify the regulatory and contractual retention requirements that apply to each system, and record why each period was chosen. The step closes with a signed retention schedule that names the approver and the date it takes effect. Ask legal and compliance to confirm which laws, contracts or framework obligations set the minimum period, because this is the input that the assessor will test first.
Map each log source to its period
List every audit log source in scope, including application logs, identity provider logs, operating system logs, database audit trails and the audit.log or equivalent files produced by self-hosted platforms. Assign each source to a retention period from the signed schedule and name the system owner responsible for it. The output is a source-to-period register. Sources that carry the most sensitive data, such as privileged access logs, usually need the longest or most tightly controlled periods, so check them against the schedule explicitly.
Configure storage and archive tiers
Set up the live log store and the archive tier so that records remain available for the full period in the register. Configure rotation, export and archive jobs for each source, and confirm that log storage capacity covers the retention window without silently dropping records. Backup tools such as Bareos or restic can hold archive copies, but the team must confirm which repository holds the authoritative copy. The output is configuration evidence: exported settings, job definitions and storage capacity reports that show the retention behavior is in place.
Protect archives from unauthorized change
Restrict who can read, modify or delete archived audit records, and separate the archive administrators from the people whose activity the logs record. Apply integrity protection such as checksums, repository verification or write-once storage where the platform supports it, and confirm the capability with the vendor before relying on it. Record the access list and the integrity verification settings. This step links to the AU-9 protections, so the evidence produced here should be reused rather than duplicated.
Test retrieval from the archive
Select sample records from each retention tier, including records near the end of the retention period, and retrieve them the way an investigator would. Time the retrieval, confirm the records are complete and readable, and confirm that time stamps and record content are unchanged. Run integrity checks on the archive, such as a restic check with data reads on a sample of pack files where that tool is used. The output is a retrieval test record that lists the samples, the method, the result and the person who performed the test.
Document owners, runbook and review cycle
Write a runbook that explains how archives are searched, restored, extended or disposed of at the end of the retention period, and name the owner for each log source. Set a review cycle for the retention schedule and the register, and record the date and outcome of each review. The closing artifact is a runbook together with a review record that shows the schedule was checked against current legal and contractual requirements. Ask the implementation partner and your auditor to confirm which review cadence and evidence format they expect before the runbook is finalized.

Evidence that passes an AU-11 assessment

An assessor testing AU-11 looks for one chain of evidence: a defined retention period, a documented reason for it, a configuration that enforces it, and proof that retained records can still be found and read. The cards below cover each link, plus the disposal records that show the period also ends. Keep each artifact dated and reviewed so the chain is current at assessment time, not reconstructed for it.

Approved retention schedule

This document states the organization-defined retention period for audit records, who approved it, and when it was last reviewed. It should name the regulatory and organizational requirements that drive the period, since AU-11 ties retention to after-the-fact investigations and to those obligations. Check that the approver has authority over the system and that the schedule covers every audit record type in scope, not only the security log. Review it on a fixed cycle and whenever a new regulation applies to the system.

Source-to-period register

A register maps each audit log source, such as the operating system, identity provider, application audit log and secrets manager, to its retention period and storage location. Assessors use it to confirm that no source was left out of the schedule. Export it from a configuration inventory or a maintained spreadsheet, and record the owner of each source. Update it when a component is added, replaced or decommissioned, because an unlisted source is a common finding.

Storage and archive configuration exports

Configuration exports show that the retention period is enforced, not just written down. Examples include log rotation and archive settings for the audit log path, backup job retention for the backup server, and retention policies on the log store. Capture them as versioned files with a timestamp so the state at any review date can be shown. Compare them against the schedule and investigate any gap. Confirm the exact configuration keys with each platform's documentation, because retention settings differ between products.

Archive access and integrity controls

Retained records must be protected for the full retention period. Evidence here includes access lists limiting who can read or delete archives, separation of duties between administrators and log reviewers, and integrity checks such as periodic verification of backup repositories. For example, restic's check command with read-data options reads pack files back to confirm stored data is unmodified. Keep the check output and the schedule that produced it, since a single run does not show ongoing integrity.

Retrieval test records

Retrieval tests show that old records can be found and read when an investigation needs them. Pick records from different points inside the retention window, restore or search them, and record the request, the result and the time taken. For example, a Bareos restore of files selected from a backup taken before a given date shows that retrieval works from the catalog. Run these tests on a schedule and after any storage migration, and file the results with the named tester. This is the evidence that supports the long-term retrieval enhancement, AU-11(1), if the organization selects it.

Disposal records

Disposal records prove that audit records were removed when the retention period ended, which matters because keeping records past the period can also breach the schedule and privacy obligations. Each record should list the data set, the date of disposal, the authority for the deletion, the method, and the person who confirmed it. Check that deletion reaches backups and archive copies, not only the primary store. Record legal holds that suspended disposal, with the holding authority and the release date.

What AU-11 retention costs to meet

This table lists the cost components of meeting AU-11 retention, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to build a quote request and to separate open-source license savings from the costs that remain. NIST does not estimate compliance costs, so the figures must come from your own environment and written quotes.

Cost component	One-time or recurring	Who is paid or who bears it	What drives it up or down
Defining the retention period	One-time, revisited on change	Internal legal, compliance and records staff, possibly outside counsel	Number of applicable laws, contracts and sector rules; fewer conflicting periods keep this down
Storage and archive capacity	Recurring	Cloud or data center providers, or internal infrastructure teams	Log volume, retention length and replication copies; reducing event scope under AU-2 lowers volume
Tooling and licenses for supplied open-source tools	No license fee for the supplied tools; support contracts optional	Storage vendors and any paid support provider you choose	Support tier and hosting model; confirm license terms with each project before deployment
Engineering time to configure tiers and integrity checks	One-time build, with recurring tuning	Implementation partner or internal platform engineers	Number of log sources, tiering design and integrity verification approach
Retrieval testing	Recurring, at the frequency you set	Internal operations staff or implementation partner	Archive size, number of restore paths and how many test scenarios you define
Evidence upkeep	Recurring	Internal compliance staff and system owners	Frequency of assessments, number of systems in scope and how much is automated
External review and auditor sampling	Recurring, per assessment cycle	Independent assessor or auditor, billed by their engagement terms	Sample sizes, number of systems and evidence quality; request the assessor's fee basis in writing

What stays in-house and what a partner or auditor handles

Your organization owns AU-11 because the control turns on decisions only you can make. SP 800-53 requires an organization-defined retention period, so the number of days, months or years and the record types it covers must come from your own obligations and risk appetite. Legal, compliance and data owners should confirm that period against the laws, contracts and internal policies that apply to your systems, and they should sign off on it in writing.

Retention period: Set the defined period for each class of audit record and document why it was chosen.
Data owners and legal sign-off: Confirm which records fall under regulatory retention and which may be deleted earlier.
Storage budget: Decide how much long-term storage you will fund, including archive tiers and recurring costs.
Access decisions: Name the roles allowed to retrieve archived records and approve exceptions.
Ownership of the policy: Keep the retention rule in your audit and accountability policy so an assessor can trace it.

Confirm that each decision is recorded in a form an assessor can examine, with a named owner and a review date.

Where AU-11 retention programs usually fall short

AU-11 is short in wording but easy to fail in practice. Most gaps sit between the policy and the systems that actually hold the logs: the period is written down but not configured, some sources are missed, and nobody checks that archives restore or that deletion followed the schedule. Each card below names one gap and the step that closes it.

Retention period exists only in policy

The organization-defined period is written in a policy document, but no system setting enforces it. An assessor examining AU-11 will look for the period in configuration and records, not just the policy text. Check each audit source for its actual retention setting and record who approved the value. Where a platform keeps logs in a data directory, confirm the path and the retention or rotation settings in the deployed configuration, not in the design document.

Default log rotation shorter than policy

Operating system, web server and application logrotate defaults often delete logs well before the approved retention period ends. The gap is silent: nothing fails until an investigation or regulator request asks for older records. Compare each rotation rule with the defined period, raise the rotation count or move logs to an archive location before deletion, and test by listing the oldest surviving record on each host. Name the owner of each rotation rule.

Archives never restored

Backups and archives are created on schedule, but no one has tried to read an audit record from them. Retention only supports investigations if the records can be retrieved and read in a usable form. Schedule periodic restore tests of a sample of audit archives, covering both recent and older dates, and record the time taken and any missing fields. Backup tools with catalogs, such as Bareos, can restore files from a point in time, so confirm that audit log paths are included in the job selection and that restores are tested.

No owner or review cycle

Retention periods set years ago continue unchanged after new regulations, contracts or business lines appear. Without a named owner, no one notices when a period no longer matches the obligations. Assign an accountable role for AU-11, define a review cycle in the organization's own procedures, and record each review with the regulatory and contractual inputs it considered. The owner also approves exceptions, such as a legal hold that extends retention beyond the standard period.

Retention applied to some sources only

Central logging platforms may retain events for the full period while application-level audit logs, identity provider logs or container logs follow shorter defaults. An investigation then finds a gap exactly where the activity occurred. Build an inventory of every audit source feeding the retention scope, mark each as covered or not, and check each one's setting. Application audit trails, such as the admin_audit app in Nextcloud, write to their own file, so they need their own retention entry.

PII kept beyond need

Where the privacy baseline applies, audit records can hold personal data, and keeping them for the full security period may conflict with a shorter need for that data. Retention for audit records should be set with privacy input, not copied from the security default. Identify which record fields contain personal data, decide whether they can be minimized or masked before archive, and document the reason for any longer retention. Ask the privacy officer to confirm the decision in writing.

No check that deletion followed schedule

Deletion is often automatic and unrecorded, so no one can show that records were removed on the approved schedule and not earlier or later. Assessors look for evidence of both retention and disposal. Keep a deletion log or an automated report that lists the date range removed from each source, and compare it with the approved schedule each quarter. Investigate any deletion that falls before the defined period ends, since it may point to a misconfigured job or an unauthorized action.

Questions buyers ask about AU-11 retention

How much does it cost to meet AU-11 audit record retention?

No supplied source gives a cost for AU-11, so no figure appears here. The bill has three parts: internal staff time to define the retention period and document it, storage and backup infrastructure to hold the records for that period, and outside help to design the retention setup and prepare evidence. Storage is the main recurring cost and grows with log volume and the length of the period. Ask any provider for a quote built from a written scope that lists each log source, the retention period per source, the storage target, and who runs the retention jobs after handover. Ask the independent assessor separately for its fees, since it issues the assessment result.

How long does AU-11 retention work take?

No supplied source gives a duration, so confirm the timeline against your own environment. Two factors drive it most. The first is the number of sources: each application, operating system, identity service and backup tool that generates audit records needs its own retention setting and test. The second is whether the retention period is already defined. If the organization has already set the period from a regulatory or contractual requirement, the work is mainly configuration and verification. If the period still has to be decided with legal, compliance and records owners, expect that decision to set the schedule. Ask for milestones tied to the source list.

What does the client team need to provide for AU-11?

The client team owns the control, so it must supply decisions and access. Retention periods must be set by people who know the regulatory, contractual and organizational requirements, typically records, legal and compliance owners. Engineering must supply access to the log sources, storage targets and backup systems, plus change windows for configuration. Administrators must confirm which logs are actually produced and where they are kept. An assessor will interview personnel with audit record retention responsibilities, so those people need to be named and able to explain the process. Agree these responsibilities in writing before work starts.

Can an in-house team meet AU-11 without outside help?

Yes, an in-house team can meet AU-11 if it has the skills and time. The control is not a tool purchase. It requires a defined retention period, configured storage that keeps records for that period, protection against early deletion, and evidence that the setup works. Teams with experience in log management, backup administration and records policy often handle this internally. Outside help is useful when the source list is large, the period is contested, or the team lacks capacity to produce evidence for an assessment. Whichever route you take, the organization remains responsible for the control, and an independent assessor is still needed for any formal assessment result.

Is AU-11(1) long-term retrieval required for my system?

AU-11(1) is not selected in any SP 800-53B baseline, so it is not required for the low, moderate, high or privacy baseline by default. The control enhancement covers long-term retrieval capability for audit records. Whether it applies depends on your authorizing body, contract or tailored baseline, so confirm this in writing before planning. Ask the authorizing official or contract owner whether AU-11(1) is required, and if so, which records and how long retrieval must work. If it is not required, document that decision in your tailoring record so an assessor can see it.

Does the privacy baseline change AU-11 work?

AU-11 is selected in the privacy baseline, so the control applies there as well as in the low, moderate and high baselines. The retention requirement still follows an organization-defined period, but that period should reflect privacy obligations, such as limiting how long records containing personal information are kept. Audit records can contain personal data, so the retention decision and the privacy review should be aligned. Ask your privacy office to confirm the period and any deletion expectations before engineers configure storage.

Who issues the assessment result for AU-11?

An independent assessor issues the assessment result, not the implementation partner and not NIST. NIST publishes SP 800-53A, which gives the assessment procedure for AU-11: one determination statement, assessed through examine and interview methods. The assessor examines objects such as the defined retention period, audit record archives and audit logs, and interviews personnel responsible for retention and system administrators. An implementation partner can prepare configurations, documentation and evidence, but it does not produce the assessment report. Your authorizing body or contract sets which assessor is acceptable.

How DeployOpen scopes and prepares AU-11 retention evidence

DeployOpen works on AU-11 Audit record retention as an implementation partner: we set up self-hosted open-source platforms so retention periods are defined, enforced and provable inside your own infrastructure. Your organization sets the retention period and owns the control, and an independent assessor reviews the evidence we help prepare.

How we scope

We agree in writing which audit record sources fall under your defined retention period.
The written scope names each platform, storage location and the retention requirement it must meet.
Engagements are fixed-scope, with deliverables and timelines agreed before work starts; ongoing support is available as a retainer.

How we build

We configure audit logging on in-scope platforms so records are written to a known, protected location.
We set up backup and archive jobs so audit records remain retrievable for the full defined period.
We test restores of archived audit records to confirm they can be read after the retention window is reached.

How we hand over

We document the retention period, storage paths, backup schedules and restore procedures for your assessor.
We provide retention test results, configuration exports and sample restore records as evidence.
We walk your administrators through the procedures so they can keep the evidence current after handover.

How we support

We can maintain retention settings and backup jobs under a retainer as platforms are upgraded.
We can rerun restore tests on a schedule you define and update the evidence set after each run.
Your organization remains responsible for the retention decision, so changes to the period stay under your governance.