AU-4: Audit Log Storage Capacity

AU-4 requires you to size and manage audit log storage so your systems can retain logs for your defined retention period and expected peak volume without losing, overwriting, or dropping events. Operationalize it by forecasting log volume, allocating storage with headroom, setting alerting thresholds, and proving in evidence that capacity is monitored and expanded before logs are lost. ¹

Key takeaways:

• Define the organization-determined log retention and volume assumptions, then design storage to meet them. ¹
• Put capacity monitoring and alerting in place so “disk full” never becomes a logging outage. ¹
• Keep evidence that shows sizing, thresholds, and actions taken when growth or spikes occur. ¹

The au-4: audit log storage capacity requirement exists to prevent a predictable failure mode: you collect the right audit events, but you cannot keep them long enough to support investigations, incident response, eDiscovery, or compliance reporting because storage runs out. AU-4 is simple in wording and easy to fail in practice because logging volume grows quietly over time and spikes during incidents, new deployments, or misconfigurations.

From a CCO or GRC lead perspective, AU-4 is less about buying storage and more about defining an enforceable “logging capacity objective” that engineering can operate against. You need a clear retention target, a forecast method tied to real log rates, an alerting and expansion process, and recurring evidence that shows the control is operating. You also need a decision on what happens when capacity pressure hits: drop logs (usually unacceptable), throttle sources (risky), reduce verbosity (can break other AU controls), or expand storage (preferred).

This page gives requirement-level implementation guidance you can hand to security engineering, platform teams, and system owners, then assess quickly and consistently across systems.

Regulatory text

Requirement (AU-4): “Allocate audit log storage capacity to accommodate {{ insert: param, au-04_odp }}.” ¹

Operator interpretation of the text:

• “Allocate” means you must proactively provision storage (and the supporting pipelines) for audit logs, not react after logs are dropped. ¹
• “Audit log storage capacity” includes the full chain required to retain logs: collectors/forwarders, message queues/brokers (if used), SIEM/log platform hot storage, warm/cold tiers, and immutable archives if your environment requires them. ²
• “Accommodate” means your capacity must support your organization-defined needs (the organization-defined parameter in AU-4). You must explicitly define those needs and show your sizing meets them. ¹

Plain-English requirement

You must have enough audit log storage to keep the logs you’re supposed to keep, for as long as you’re supposed to keep them, even when log volume increases. You must detect capacity risk early and expand storage before logging fails. ¹

Who it applies to (entity and operational context)

Applies to:

• Federal information systems and contractor systems handling federal data where NIST SP 800-53 is in scope (including inherited requirements through authorizations, contracts, or system security plans). ²

Operational scope (where AU-4 shows up during assessment):

• Central logging/SIEM platforms (cloud-native logging, SIEM, data lake logging).
• Mission/business applications that write security-relevant logs locally before forwarding.
• Infrastructure layers: identity services, endpoints, containers/Kubernetes, network/security devices.
• Third-party hosted platforms where you depend on a provider’s log retention and export features; AU-4 still requires you to ensure capacity for what you must retain (often via export/archival). ²

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

1) Define the AU-4 organization-determined parameter (ODP)

AU-4’s text depends on your organization-defined needs. Write them down in a control statement that engineering can implement.

Minimum ODP decisions to document:

• Retention period(s) by log type or system tier (example: authentication and admin activity vs. application debug logs).
• Storage tiering expectations (example: searchable vs. archived).
• Peak-volume assumption (what “spike” you must tolerate).
• Loss tolerance (usually “no loss for in-scope audit events”; if you allow exceptions, document them with compensating controls).

Deliverable: “AU-4 Control Implementation Standard” for your environment, including the ODP values and definitions. ¹

2) Build an inventory of log sources and pipelines

Create a list of systems and services that generate or handle audit logs, and map where logs flow and where they are stored.

Include:

• Source system (owner, environment, criticality)
• Log type (auth, admin, database, network, application)
• Collection method (agent, API pull, syslog, cloud native integration)
• Destination(s) and storage tiers
• Current retention settings ¹
• Current average daily volume and peak indicators (where available)

This inventory becomes your AU-4 scoping backbone and prevents “unknown sources” from silently exhausting storage.

3) Forecast capacity using real log volume

Capacity planning fails when it is guessed once and never revisited. Use measured ingestion and growth rates from your logging platform.

Practical method:

• Take current daily ingestion volume per source/destination.
• Apply retention settings to compute total required storage by tier.
• Add explicit headroom for growth and spikes, and document why you chose it (don’t hide this in tribal knowledge).

If you have multiple tiers (hot/warm/cold), compute each tier separately so you don’t pass AU-4 on total capacity while failing the searchable tier.

4) Allocate storage and set platform limits to prevent silent drops

Allocate storage on the systems that can become bottlenecks:

• SIEM/log platform storage pools (indexes, buckets, partitions)
• Message broker retention and disk limits (if used)
• Collector/forwarder local buffers (disk-backed queues)
• Local application/system disks where logs accumulate before forwarding

Set explicit safeguards:

• Configure backpressure/queue behavior so that a downstream outage does not cause a local disk fill event that takes a server down.
• Ensure rotation settings do not overwrite logs before your required retention is met (rotation can be correct for OS logs if forwarding plus central retention meets the ODP, but you must prove the end-to-end outcome).

5) Implement monitoring, alerting, and an expansion runbook

AU-4 is operational. Auditors will ask how you know you won’t run out of storage.

Minimum expectations to operationalize:

• Monitoring for percent-used, remaining days at current rate (if available), queue depth, ingestion failures, and dropped-event counters.
• Alerts routed to an on-call group with ticket creation.
• A documented runbook: “what we do when log storage hits threshold X,” including who approves spend/config changes and how quickly expansion happens.

Tie runbook steps to change management so expansions are traceable.

6) Prove it in recurring evidence

Treat AU-4 like any other measurable SLO: you either maintain capacity or you don’t. Set a review cadence (engineering-owned) that produces artifacts you can show without scrambling.

A practical approach is to assign a control owner and define recurring evidence outputs (this is also where Daydream helps teams stay assessment-ready by mapping the control to owners, procedures, and evidence requests). ¹

Required evidence and artifacts to retain

Keep evidence that covers design + operation:

Design / configuration evidence

• AU-4 ODP statement (retention, tiers, spike assumptions) ¹
• Logging architecture diagram showing storage locations and tiers
• SIEM/log platform retention configuration screenshots/exports
• Broker/collector buffer settings (where applicable)
• Storage allocation records (cloud storage configuration, index sizing)

Operational evidence

• Capacity dashboards (screenshots or exported reports) showing trends and current utilization
• Alert configurations and sample alert notifications/tickets
• Change records for storage expansions or retention adjustments
• Incident/postmortem notes if capacity pressure occurred, including corrective actions
• Periodic review minutes or attestations from platform owner confirming capacity is within thresholds

Common exam/audit questions and hangups

Auditors and assessors commonly probe AU-4 with questions like:

• “Show me how you determined your log storage capacity meets your retention requirement.”
• “What happens during a spike in log volume? Do you drop events?”
• “Where is the single point of failure in the logging pipeline?”
• “Do local systems overwrite logs before forwarding succeeds?”
• “Show alerting and tickets for capacity warnings, plus evidence you acted.”

Hangups that delay assessments:

• Retention is defined in policy, but SIEM settings differ by index/workspace.
• Only the SIEM is sized; collectors/brokers fill first and silently drop.
• Debug logging enabled in production created unexpected volume; teams “fixed” it by shortening retention without documenting a risk decision.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails AU-4	Avoidance tactic
Treating AU-4 as “buy more storage”	AU-4 expects capacity allocated to a defined requirement, plus operational monitoring	Write the ODP, tie it to measured ingestion, and show monitoring + runbook 1
No documented spike assumption	Capacity works on normal days, fails during incidents	Document peak scenario assumptions and validate periodically
Ignoring downstream bottlenecks	SIEM has space; forwarder disks fill and logs are lost	Monitor each pipeline layer (collector, broker, SIEM, archive)
Solving capacity by lowering retention ad hoc	Can break compliance/investigations if retention drops below ODP	Treat retention changes as a risk decision with approval and evidence
Relying on a third party’s default retention	Defaults may not match your ODP	Contractually confirm retention/export, or export to your storage to meet ODP

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-4, so you should treat this primarily as an assessment and authorization risk rather than a “fine-driven” requirement in this write-up. Practically, AU-4 failures still create real exposure: you can’t reconstruct events, prove control operation, or support incident investigations if logs were overwritten or dropped. ²

A practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Assign AU-4 control owner(s) for the logging platform and for system onboarding.
• Write and approve the AU-4 ODP statement (retention, tiering, spike assumption). ¹
• Build the log-source and pipeline inventory for in-scope systems.
• Turn on baseline dashboards for storage utilization and ingestion trends.

By 60 days (implement monitoring + close obvious gaps)

• Configure alerts for storage thresholds, ingestion failures, and dropped events.
• Publish an operational runbook for capacity events, with ticketing integration.
• Validate retention settings match the ODP across the SIEM/log platform.
• Identify and remediate bottlenecks (collector buffers, broker retention, local disk rotation).

By 90 days (prove operation + make it repeatable)

• Run a capacity review using measured ingestion and document the sizing calculation.
• Produce a complete evidence packet: ODP, configs, dashboards, tickets/changes. ¹
• Add AU-4 checks to onboarding for new systems and to change management for high-volume logging changes.
• Consider using Daydream to map AU-4 to owners, procedures, and recurring evidence so assessments don’t become a scramble. ¹

Frequently Asked Questions

What does “allocate audit log storage capacity” mean in practice?

It means you proactively provision enough storage across your logging pipeline to meet your defined retention and volume needs, then monitor and expand it before logs are lost. The requirement is explicit that capacity must accommodate your organization-defined parameter. ¹

If my SIEM retains logs, do I still need local log storage on servers?

You need whatever local buffering is required to reliably forward logs without overwriting before central storage receives them. If local rotation overwrites logs during outages, AU-4 is at risk even if the SIEM is well-sized.

Can I meet AU-4 by reducing log verbosity to control storage growth?

Sometimes, but treat it as a security-impacting change. You still must meet the retention and auditability expectations captured in your AU-4 ODP, and you should confirm you are not undermining other audit controls by removing needed events. ²

How do I handle third-party SaaS logs with short default retention?

Confirm retention and export capabilities with the third party, then export logs to your own storage/SIEM if the default does not meet your ODP. Your evidence should show how the end-to-end retention requirement is met.

What evidence is the fastest path to satisfy assessors?

A written AU-4 ODP, retention configuration exports from the logging platform, capacity dashboards showing utilization trends, and a ticket/change trail showing you respond to alerts by expanding capacity. ¹

Who should own AU-4: security or platform engineering?

Platform engineering typically owns the logging infrastructure and monitoring, while security/GRC owns the ODP definition and assessment readiness. Document the RACI so there is no gap during incidents or audits.

Footnotes

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

2. NIST SP 800-53 Rev. 5