AU-4: Audit Log Storage Capacity

AU-4 requires you to provision and manage enough audit log storage to meet your organization’s audit log retention requirements, without losing, overwriting, or dropping logs during normal operations or spikes. Operationally, you need a documented sizing model, monitored capacity thresholds, and a tested response process that prevents retention violations. ¹

Key takeaways:

• Size log storage from retention requirements plus peak log volume, then build headroom and alerts into operations.
• Prove operation with monitoring evidence, retention configuration, and incident records showing you prevented or remediated capacity risk.
• Treat capacity failures as an auditability failure: they break investigations, IR timelines, and compliance attestations.

AU-4: Audit Log Storage Capacity is a deceptively small requirement that causes outsized audit pain. Auditors and customer assessors rarely accept “we have a SIEM” as evidence if you cannot show that storage is intentionally allocated to satisfy a defined retention requirement, and that the system keeps collecting logs even when volume spikes. AU-4 is about engineering and governance working together: compliance defines retention expectations (often driven by contracts, policies, or overlays), and operations proves the platform can sustain that retention without gaps.

In practice, AU-4 breaks in predictable ways: teams onboard new log sources without recalculating storage, high-volume events fill hot storage and trigger drop/overwrite behavior, or a SIEM license limit becomes the real bottleneck. The fastest way to operationalize AU-4 is to treat it as a control with an owner, a sizing method, monitoring thresholds, and a runbook tied to change management.

This page translates AU-4 into an execution checklist for a CCO, compliance officer, or GRC lead who needs implementable steps, clear evidence expectations, and common audit questions to preempt.

Regulatory text

NIST AU-4 requirement (excerpt): “Allocate audit log storage capacity to accommodate [audit log retention requirements].” ¹

What the operator must do:

1. Define the audit log retention requirements that apply to your system(s) in scope.
2. Allocate sufficient storage capacity (and supporting ingestion/archival design) so those retention requirements are actually met.
3. Operate the environment so you can demonstrate you did not lose required logs due to capacity constraints. ¹

AU-4 is intentionally short because it depends on your organization’s retention rules. Your job is to “close the bracket” by documenting what retention means for your environment, then proving your storage allocation and operations match it.

Plain-English interpretation

AU-4 means: If you’re required to keep audit logs for a given period, you must provision and operate enough storage so the logs are still there for that entire period. No silent drops, no rolling overwrites that violate retention, and no “we would have had it, but disk filled up.”

This is both a security control and an operational reliability control. If storage fills, you lose auditability, which breaks incident investigation, insider threat review, and many other AU-family controls.

Who it applies to

Entity types and contexts commonly in scope:

• Federal information systems implementing NIST SP 800-53 baselines. ²
• Contractor systems handling federal data where NIST SP 800-53 controls are contractually flowed down or used to support an authorization package. ²

Operationally, AU-4 applies wherever audit logs exist, including:

• Identity platforms (SSO, IAM, PAM)
• Cloud control planes and API activity logs
• Endpoint and server logs
• Network security tooling (firewalls, WAF, IDS/IPS)
• Application and database audit logs
• SIEM/log management pipelines and archives

If your system boundary is broad, scoping matters. AU-4 is easiest to pass when you can show “logs in scope” are defined, sourced, routed, stored, and retained under one policy-backed requirement set.

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

1) Establish the retention requirement you are sizing to

Create a short “AU-4 retention basis” statement per system boundary:

• Retention duration (as required by your internal policy, contract, or system security plan)
• Log types in scope (security-relevant events, admin activity, authentication events, etc.)
• Storage tiers (hot/warm/cold, if applicable) and retrieval expectations for investigations

AU-4 does not tell you what the retention period is; it tells you to allocate capacity that meets whatever you committed to. ¹

Operator tip: If retention requirements vary by data type, define the minimum required set for “audit logs” and ensure your storage plan covers that set end-to-end.

2) Inventory log sources and expected volume drivers

You need a living inventory that answers:

• What systems generate audit logs?
• How do logs flow (agent, API, syslog, collector)?
• Where are they stored (SIEM index, object storage, archive)?
• What causes growth (new apps, new endpoints, increased auth traffic, verbose logging modes)?

This inventory becomes the input to sizing and change control. Without it, AU-4 becomes a guessing exercise.

3) Build a sizing model that an auditor can follow

Your sizing model should be simple enough to explain and repeat:

• Baseline daily ingest estimate per source (or by category)
• Compression/normalization assumptions (document the assumption; don’t hand-wave)
• Retention period and required storage tiering
• Buffer/headroom decision and rationale
• Maximum credible burst assumptions (peak events, incident surge logging, DDoS, etc.)

Auditors look for two things: a method and evidence you re-run it when conditions change.

4) Allocate storage and enforce retention configuration

Implement the technical controls that make retention real:

• SIEM/index retention policies (time-based retention, immutable retention where required)
• Archive lifecycle policies (object storage lifecycle, WORM/immutability if applicable to your requirements)
• Backpressure controls: confirm what happens when collectors, queues, or the SIEM hit limits
• Guardrails to prevent “log drop” behavior (or to force a fail-closed/alerted state you can respond to)

If your architecture relies on multiple tiers, document the chain of custody: when logs move from hot to archive, how integrity is preserved, and how retrieval works.

5) Monitor capacity and alert before you violate retention

AU-4 is operational. Set monitoring on:

• Storage consumption by tier
• Ingestion rate anomalies
• Index/partition health
• Queue depth and collector saturation
• License-based limits that can cause ingestion throttling

Define alert thresholds and on-call routing so the right team is paged with enough lead time to act. Then connect it to a runbook.

6) Create and test a “log storage exhaustion” runbook

Your runbook should cover:

• Triage: confirm whether risk is storage, ingestion, or licensing
• Immediate containment: add capacity, extend partitions, scale collectors, adjust routing
• Retention protection: prevent overwrites that would violate the retention requirement
• Communications: security leadership, compliance, and system owners if auditability is at risk
• Post-incident: root cause, sizing model update, backlog remediation

Tabletop this scenario with Security Operations and the platform owner. Keep the record as evidence.

7) Bind AU-4 to change management

Most AU-4 failures come from change:

• Onboarding new log sources
• Turning on verbose audit logging
• Adding endpoints or users
• Migrating SIEM platforms
• Changing retention policy

Add a change-management checkpoint: “Does this change materially affect log volume or retention?” If yes, the sizing model must be updated and approved.

8) Assign ownership and run control health checks

AU-4 needs a named owner (often Security Engineering, SIEM team, or Cloud Platform). Compliance should require:

• A control card/runbook with owner, triggers, and steps
• A defined evidence bundle
• Recurring health checks and tracked remediation to closure

If you run Daydream for control operations, AU-4 maps cleanly to a control card workflow with recurring tasks, evidence collection, and remediation tracking so you can prove sustained operation during audits. ¹

Required evidence and artifacts to retain

Store evidence in a location that your audit team can access and that has its own retention rules.

Minimum evidence bundle (practical):

• AU-4 control card/runbook: objective, scope, owner, execution cadence, trigger events, exception handling
• Retention requirement statement: what retention you must meet for audit logs, per system boundary
• Log source inventory: systems, categories, routing, storage destinations
• Sizing model and approvals: spreadsheet or doc, assumptions, review/approval record
• Configuration exports/screenshots: SIEM retention settings, archive lifecycle policies, immutability settings if used
• Monitoring proof: dashboard screenshots, alert rules, recent alert history, tickets created from alerts
• Capacity change records: scaling events, storage expansions, relevant change tickets
• Incident/runbook execution records: any capacity-related events, triage notes, corrective actions, postmortems

Common exam/audit questions and hangups

Expect these questions and prepare tight answers:

1. “What is your audit log retention requirement?”
   Have a written requirement tied to policy/SSP/contract, not tribal knowledge.

2. “How did you determine storage is sufficient?”
   Show the sizing model and when it was last updated.

3. “What happens if the SIEM or collector runs out of space?”
   Auditors want specifics: drop, overwrite, throttle, fail ingestion, or alert. If the answer is “not sure,” AU-4 is at risk.

4. “Prove you didn’t lose logs last quarter.”
   Provide ingestion health metrics, alert history, and incident tickets. If you had a capacity event, show containment and recovery.

5. “How do you ensure new systems don’t break capacity?”
   Point to change management gating and the log source onboarding checklist.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails AU-4	Avoid it by
Retention is stated in policy but not implemented in tooling	AU-4 requires allocated capacity that meets retention	Export retention configs and reconcile them to the written requirement
Storage exists but ingestion throttles or drops during spikes	You meet “storage,” but still lose required logs	Monitor pipeline bottlenecks (collectors, queues, license caps) and test burst scenarios
Only “hot” SIEM storage is sized; archive is an afterthought	Long retention usually depends on archive tiers	Document tiering and prove lifecycle policies move data reliably
No owner, no cadence	Audits fail on “control not operating”	Assign an owner and require recurring health checks with evidence
Log sources are unknown or constantly changing	Sizing model becomes stale immediately	Maintain a log source inventory and bind onboarding to change control

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-4, so you should treat this as a control assurance and incident readiness risk rather than a case-driven requirement.

Operationally, the risk is straightforward:

• If log storage fills or retention is misconfigured, you may be unable to reconstruct user/admin actions, detect misuse, or support incident response and legal holds.
• In federal and contractor contexts, auditability gaps can create authorization, contract, and assessment problems because you cannot demonstrate control effectiveness against AU-family expectations. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Name an AU-4 owner and publish an AU-4 control card (scope, triggers, evidence).
• Write the retention requirement statement per system boundary.
• Build or refresh the log source inventory (start with “crown jewel” systems and the SIEM itself).
• Turn on baseline capacity monitoring for storage tiers and ingestion pipeline choke points.

Days 31–60 (size, configure, and prove)

• Produce a sizing model and get explicit approval from the control owner and system owner.
• Implement or correct SIEM retention policies and archive lifecycle policies to match the requirement.
• Create alerting and ticketing workflows for capacity thresholds.
• Draft the storage exhaustion runbook and run a tabletop exercise; capture notes as evidence.

Days 61–90 (operationalize and audit-harden)

• Add AU-4 checks to change management for log source onboarding and major platform changes.
• Run the first control health check: confirm capacity headroom, retention configs, and alert functionality.
• Close gaps with tracked remediation tickets and validated closure evidence.
• Package an “AU-4 audit-ready evidence folder” so you can respond quickly to assessors.

Frequently Asked Questions

Do we have to keep all logs in the SIEM hot tier to meet AU-4?

No. AU-4 requires enough storage capacity to meet retention requirements, which can include tiered storage if retrieval and integrity meet your requirements. Document the tiering design and prove lifecycle policies and retention settings match the written retention requirement. ¹

What if our SIEM license limit, not disk space, is the bottleneck?

Treat license-based ingestion caps as an AU-4 capacity risk because they can cause log drops or throttling that breaks retention. Monitor for ingestion throttling and document the control response (scale, reroute, or adjust sources) in the runbook.

How do we define “audit log retention requirements” if we have multiple stakeholders?

Start with the system’s governing documents (SSP, contracts, internal policies) and produce one scoped retention statement for “audit logs” that you can consistently implement. If requirements differ, define categories and apply the strictest retention to the in-scope audit log set.

What evidence is most persuasive to auditors for AU-4?

Auditors respond well to a simple chain: written retention requirement, sizing model, retention configuration exports, and monitoring/ticket evidence showing capacity is actively managed. Keep at least one example of a capacity alert and the associated response ticket.

We onboard new SaaS tools constantly. How do we stop AU-4 from becoming stale?

Make “log source onboarding” a formal change type that requires updating the log inventory and re-running the sizing model when volume changes materially. If you use Daydream, manage this as a recurring control health check plus a change-triggered task so evidence stays current. ¹

Does AU-4 require immutable (WORM) storage?

AU-4 itself is about allocating storage capacity to meet retention requirements; it does not, by itself, mandate immutability. If your retention requirement or system security objectives require tamper resistance, capture that in the retention requirement statement and implement the matching storage controls. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5