RMFInsider

For a DoD application the number is one year, and five years if the application handles sources and methods intelligence. That is rule text, not policy from memory: DISA’s Application Security and Development STIG version 6, dated 12 February 2025, carries rule V-222621, mapped to CCI-000167 and AU-11, stating that the ISSO must ensure application audit trails are retained at least one year without SAMI data and five years with it. On the federal side, OMB M-21-31 of 27 August 2021 sets 12 months active plus 18 months cold storage for the event log categories it covers, which NARA’s General Records Schedule 3.2 mirrors as destroy when 30 months old. Your AU-11 value is whichever of these your AO accepted, written in the SSP.

What AU-11 actually says, and who fills in the blank

AU-11 in NIST SP 800-53 Rev 5 is a one-line control with a hole in the middle. It directs the organization to retain audit records for an organization-defined time period to support after-the-fact investigation of incidents and to meet regulatory and organizational retention requirements. The discussion names Freedom of Information Act requests, subpoenas and law enforcement action as the drivers.

The phrase doing the work is organization-defined. Inside DoD that definition arrives from three directions at once, and the repeated mistake is an ISSO who finds one of the three and assumes the question is settled:

1. The baseline you inherited. The overlay or baseline your system was categorized into may already carry a value, and if it does, that value is a requirement.
2. The applicable STIG or SRG. The rule text is the testable statement an assessor will open, which is why the STIG number beats oral tradition in your shop.
3. The mission owner, the data type and the records schedule. Litigation hold or a records schedule can extend the period past the cybersecurity floor, and nothing in AU-11 stops it.

Whichever is longest wins, and the number in your SSP has to be that one. I have never seen an assessor ding a system for keeping logs too long. I have watched three get written up for keeping them a shorter period than the SSP claimed, which is the problem at the end of this post.

The DoD and CJCS citations, and what I could and could not confirm

• One year, five years for SAMI. DISA Application Security and Development STIG V6, 12 February 2025, rule V-222621. The check text reads: verify a process is in place to retain application audit log files for one year and five years for SAMI data. It maps to CCI-000167 and AU-11, and to NIST SP 800-171 requirements 3.3.1 and 3.3.2.
• CJCSI 6510.01F, Information Assurance and Support to Computer Network Defense, 9 February 2011. Enclosure A paragraph 8.c requires a provision to log security-relevant events and to store log data securely, protected against unauthorized tampering or disclosure. I went looking for a CJCS paragraph that puts a number of days or months on retention and did not find one I can cite by reference. The CJCS expectation I can point to is that you log the right events and protect what you logged. The duration arrives through the STIG and CCI chain above, descending from the legacy DoD 8500.2 audit retention language.
• OMB M-21-31, 27 August 2021. Appendix C, Table 5 sets 12 months of active storage plus 18 months of cold storage as a minimum for the covered event log categories, with agencies free to keep data longer. Full packet capture gets 72 hours. The memo also defines maturity tiers EL0 through EL3: Not Effective, Basic, Intermediate and Advanced.
• NARA General Records Schedule 3.2, Transmittal 33. Item 036 (DAA-GRS2022-0005-0002), covering the cybersecurity event logs M-21-31 requires, says destroy when 30 months old. Item 035 handles full packet capture at 72 hours. Item 031, system access records for highly sensitive systems requiring special accountability, runs six years past account termination.

Read together: AU-11 wants a number, DISA supplies one for the system type, OMB supplies a federal floor expressed as hot plus cold, and NARA says when deletion is allowed. If your SSP says one year and your logs are an M-21-31 covered category, a 30-month obligation sits underneath a one-year statement, and the statement is what is wrong.

Online, offline and archival are three different answers

This is where one number in the SSP starts to leak. Retention is three tiers, and an assessor who knows the control asks about all three:

• Online. Records queryable in the SIEM right now, full index behind them. The expensive tier, and the one quietly shortened when a license renewal comes in high.
• Offline or warm. Records moved off the hot index to cheaper storage. Still retrievable, but a restore job rather than a search bar. M-21-31 calls this cold data storage and gives it 18 months.
• Archival. Records written to media or an object store under a lifecycle policy, held purely to satisfy the obligation. Nobody looks here until a lawyer asks.

Write all three into the SSP with the boundaries stated in days, because the question an assessor asks is not how long you keep logs, it is how fast you can produce a record from eleven months ago. An uncomfortable pause there is a finding waiting. The companion control is AU-7, record reduction and report generation, which is what makes AU-6 review and analysis survivable instead of theatrical.

AU-4, the control nobody thinks about until the partition fills

AU-11 says how long to keep records. AU-4 says to allocate audit log storage capacity sized to that requirement. They are a matched pair assessed by two different people in two different weeks, which is how a system ends up with a one-year retention statement and a 90-day partition. Three failure modes I have cleaned up myself:

1. The ring buffer. The log destination overwrites the oldest records when it fills. Your retention period silently becomes however long the disk lasts, which on a chatty server is days. The system is technically still logging, which is how it passes a shallow check.
2. The stop. The opposite setting, where the system halts logging rather than overwrite. Now the record set is clean with a hole in it, plus an AU-5 problem, because AU-5 covers responding to audit logging process failures and somebody has to receive the alert.
3. The uncounted forwarder. Storage was sized for the SIEM and nobody sized the local spool on each endpoint, so records queue on a host with 2 GB free and start dropping during the exact network outage whose logs you need.

Sizing it, with arithmetic you can defend

The calculation an assessor accepts is dull and takes ten minutes. Measured average events per second, times average event size, times the retention period in seconds, plus headroom. Worked: 400 events per second at 500 bytes each is 200 KB per second, about 17.3 GB a day, about 6.3 TB over a year before compression. If the SSP says one year online and the appliance holds 4 TB, that is a procurement problem rather than a configuration debate, and better found now than in the out-brief.

Measure the events per second rather than estimating it. The figure sits in the log platform’s own licensing dashboard, and it runs higher than the architecture document claims, because somebody enabled verbose logging for a troubleshooting session in 2024 and never turned it off. Which events you generate at all is an AU-2 conversation, and AU-2 belongs in the same review as AU-11, because every event added there changes the AU-4 math.

The evidence set that actually closes AU-11

A compliant status in eMASS needs artifacts behind it, not a narrative restating the control. Three pieces, and I would not submit AU-11 without all three:

• The retention policy statement. A signed document or SSP section naming the period, split by tier, citing the STIG rule or the OMB memo. A narrative reading “audit records are retained in accordance with organizational policy” is a circular reference and an assessor will treat it as one.
• The storage sizing calculation. The arithmetic above, dated, with measured events per second and provisioned capacity. It doubles as your AU-4 evidence, a rare two-for-one in this line of work.
• A restore test near the end of the window. Pull one record from within thirty days of your retention limit, screenshot it with the timestamp visible, and write a short memo naming who ran it and when. The artifact people skip, and the only one proving retention is real rather than aspirational.

All three belong in the same folder as the rest of the package. My artifact checklist lays out what each control family owes, and the AU family owes more documents than its control count suggests.

The finding that keeps coming back: the SSP number versus the SIEM

This one recurs because the two halves live with two different teams. The SSP says audit records are retained for one year. The platform runs a 90-day hot index and a lifecycle rule expiring objects at 180 days, because that was the storage budget at stand-up and nobody rewrote the SSP. Both halves are internally consistent. Together they are a false statement in an authorization document, which is a materially worse finding than a short retention period honestly declared.

Fix it in whichever direction is true. If the mission needs one year, the sizing calculation and procurement follow. If 180 days is the real answer and the data type permits it, change the SSP and record the decision. If the shortfall is against a requirement you cannot meet yet, open a POA&M item with a milestone and an owner. An honest POA&M item is a managed risk. A confident SSP paragraph the configuration contradicts undermines every other control you asserted.

One downstream consumer makes the argument concrete. Your incident response plan promises an investigative capability, and IR-8 planning is where that promise is written down. An intrusion discovered on day 200 with 90 days of logs is not an investigation, it is a guess with a timestamp. That framing funds retention faster than any control number.

A half-hour check you can run today

1. Read the AU-11 statement in your SSP. Write down the number it claims, by tier if it bothers.
2. Read the log platform’s actual index retention and lifecycle policy. Write those down too.
3. Compare them. A disagreement means you found the finding before the assessor did.
4. Run the AU-4 arithmetic against measured events per second and provisioned capacity.
5. Retrieve one record from near the end of the retention window and time it.
6. Confirm AU-5 alerting notifies a person when the destination fills or stops.

A mismatch at step three is a good day: you caught a documentation defect while it was cheap. For why organization-defined parameters cause so much of this, my walkthrough of the 800-53 control structure covers the mechanics.

For the AU family evidence requirements alongside everything else a package needs, grab the RMF Checklist and work AU-2, AU-4, AU-6 and AU-11 as one block rather than four controls, because that is how they fail.