AU-4 Audit log storage capacity: requirements and evidence

AU-4 audit log storage capacity: what it asks for and why it fails

AU-4 asks the organization to allocate audit log storage capacity that accommodates its defined audit log retention requirements. If you are the compliance lead or engineer who must show that logs survive for the full retention period, the control is less about disk size today and more about whether anyone can prove the storage will still be there at the end of that period. SP 800-53B Release 5.2.0 selects AU-4 for the low, moderate and high baselines but not for the privacy baseline, and the control enhancement AU-4(1), which covers transferring logs to alternate storage, is not selected in any SP 800-53B baseline. That means the base requirement is what you must meet by default, and the alternate storage transfer is something you add only when your own risk decision or contract calls for it.

The risk is simple to state: when audit log storage fills up or is misconfigured, new records are lost or older records are overwritten before their retention period ends, and the gap may not be noticed until an investigation or assessor asks for records that no longer exist. Three things usually make this hard. First, the retention period is often never written down in one place, so storage is sized against an assumption nobody can point to. Second, log growth is rarely forecast, especially after a new application, a verbose debug setting or a new data source is switched on. Third, the storage is frequently owned by a different team, such as a central logging platform or a cloud account administrator, so the team accountable for AU-4 cannot see the capacity it depends on. Confirm the defined retention periods with the owners of each system, then ask the storage owner for current usage, growth trend and the alert threshold they monitor.

A practical starting check is to compare each documented retention requirement with the storage that actually holds those records, and to confirm that a capacity alert reaches someone who can act before the buffer runs out. For self-hosted platforms, the evidence often sits in the platform's own logging and metrics. For example, Nextcloud's admin_audit app writes additional event information to a file named audit.log in the data directory, or to a path set with logfile_audit, so the disk holding that path belongs in your capacity plan. OpenBao audit devices keep a detailed JSON log of every API request and response, which can grow quickly on busy clusters. Prometheus can record disk usage metrics, and Grafana Alerting can turn those metrics into a rule that notifies the owner. Confirm the exact metric names and retention settings for your versions in each product's documentation, and keep the alert rule, its threshold and its test results as evidence.

Which systems, log sources and teams fall under AU-4 storage capacity

AU-4 applies wherever a system is in scope for a baseline that selects it, so the first decisions are which systems those are and which log sources feed them. Each decision below changes how much storage must be sized, who signs it off, and how much evidence an assessor will ask for.

Baseline selection for each system

AU-4 is selected in the low, moderate and high baselines of SP 800-53B Release 5.2.0 but not in the privacy baseline. A system that holds only privacy-scoped data under a privacy baseline therefore may not carry this control at all. Confirm the impact level and baseline of each system in writing, and record any tailoring that adds or removes controls, because that record decides the size of the storage workstream.

Log sources feeding each system

Every source that writes audit records to a system's audit trail adds volume to the storage the control requires. Typical sources include application logs, identity providers, operating system logs, network devices and container platforms. Inventory each source, its event rate and its format before sizing storage. A source omitted from the inventory is usually the one that fills the disk first.

Source of the retention requirement

AU-4 requires storage that accommodates the organization's defined audit log retention requirements, so the retention period sets the capacity. That period may come from a contract, a regulator or internal policy, and the longest applicable period usually governs. Ask legal, compliance and the customer contract owner to name the period and the event types it covers, and write them into the retention definition that AU-11 and AU-4 both depend on.

Ownership of log storage

Storage for audit records may sit with the platform team, the infrastructure team, a SIEM or log platform team, or a managed service provider. When ownership is split, capacity alerts can reach the wrong queue and nobody is accountable for a full volume. Name one owner for the storage allocation, one for the logging platform, and one for the retention decision, and record who approves capacity changes.

Logging platform and forwarding design

Where logs are forwarded to a central platform, the local buffer on each host and the central store both count toward capacity. An outage in the forwarding path can cause local volumes to fill, while the central store continues to accept less data than the hosts produce. Document the forwarding path, the local buffer size and the central store size as one design, then test what happens when the path fails.

Enhancement scope and alternate storage

AU-4(1) asks for audit records to be transferred to a different system or media than the one that produced them, but SP 800-53B Release 5.2.0 does not select it for any baseline. Decide whether the organization will adopt it voluntarily, which contract or policy would require it, and which alternate store will receive the transfer. Confirm this with the assessor before work starts, because an unselected enhancement may still be expected by a customer.

How an assessor tests AU-4 storage capacity

This table breaks down the single SP 800-53A determination statement for AU-4 into its examine, interview and test methods, with the objects each method uses and the evidence an assessor will ask for. Read each row as one step the assessor takes, and the common finding shows where teams usually fall short. The main takeaway is that an assessor needs proof of the retention requirement, the sizing decision and the live configuration, and the three must agree.

Assessment method	Objects assessed	Common finding and evidence requested
Examine: retention requirements	Audit record storage requirements that state how long audit records must be kept	Finding: retention period is missing, outdated or differs between policy and system. Evidence: approved retention requirement tied to AU-11 and the regulations or contracts that drive it.
Examine: storage capability	Audit record storage capability for system components, such as the capacity each log store can hold	Finding: no documented estimate of storage needed for the retention period. Evidence: sizing worksheet or design record showing projected log volume multiplied by retention.
Examine: system audit records	Existing audit records and their storage locations across the system	Finding: logs are stored in places not covered by the sizing decision. Evidence: inventory of log sources and destinations with current volumes and growth trend.
Interview: audit and accountability personnel	Organizational personnel with audit and accountability responsibilities	Finding: staff cannot explain how the retention requirement translates into capacity. Evidence: confirm the named owner, the process for revisiting sizing and any recorded decisions.
Interview: system and network administrators	System and network administrators who operate log stores and storage	Finding: administrators are unaware of capacity thresholds or what happens when storage fills. Evidence: description of monitoring, alerting and the steps taken when log storage approaches its limit.
Test: storage capacity	Audit record storage capacity of the deployed log stores	Finding: allocated capacity is below what the retention period requires. Evidence: current capacity and utilization readings from the log stores, compared with the sizing record.
Test: related configuration settings	Configuration that governs log retention, rotation, overwrite and storage limits	Finding: rotation or overwrite settings delete records before the retention period ends. Evidence: exported configuration files, with a test showing records are kept for the defined period.

How to implement AU-4 storage capacity in six steps

This sequence turns the AU-4 requirement into a documented storage design that holds the defined retention period, with capacity warnings, a decision on alternate storage and test evidence that retention survives real event volumes.

Document retention requirements for each log type
Start by listing every audit log source in scope, such as identity providers, application logs, database audit trails and network devices, and recording the retention period the organization has defined for each one. The owner is usually the audit and accountability policy owner, working with legal, compliance and the teams that investigate incidents. The output is a retention register that maps each log type to its period and its business or regulatory reason. The step is done when every in-scope source has a documented period and an approver has signed it off. Confirm any external retention obligations with counsel, since the required periods come from the organization's own requirements, not from NIST.
Forecast log volume from current event rates
Measure how many events each source produces today, the average and peak record size, and how the rate changes with business cycles or growth in users and transactions. Platform engineers usually gather this from existing logging pipelines, metrics stores and sample exports, and they state the assumptions behind each figure. The output is a volume model that converts event rates and record sizes into storage needed per log type across the full retention period. The step is done when the model has been reviewed against a recent period of real traffic and the team can explain where each input came from.
Size primary storage with headroom and record the calculation
Using the retention register and the volume model, calculate the primary audit storage capacity, add headroom for peaks and for overhead such as indexes, replication and filesystem reservations, and write the arithmetic down in a sizing worksheet. Infrastructure and storage administrators own this step, and the worksheet should name the storage platform, its usable capacity and the assumptions used. The output is an approved sizing record that an assessor can trace from requirement to number. The step is done when the record shows the capacity exceeds projected need for the full retention period and the approver has accepted the headroom margin.
Configure capacity alerts and defined responses
Set thresholds on audit storage usage and on log ingestion so that administrators learn about capacity pressure before logs are dropped or overwritten. Monitoring tooling such as Prometheus with alert rules, or Grafana Alerting, can evaluate storage metrics and notify the on-call team. Write down the response for each threshold, including who acts, what they check and when they escalate, and link this to the processing failure procedure covered under AU-5. The output is an alert configuration with a documented response runbook. The step is done when a test alert reaches the named responder and the runbook has been walked through by the people who would use it.
Decide whether and how to transfer logs to alternate storage
AU-4(1) is an enhancement that asks organizations to transfer audit records to a different storage system, and it is not selected in the SP 800-53B low, moderate, high or privacy baselines. Decide whether your design needs it based on your retention period, your risk and any stated requirement, and record that decision either way. If you transfer logs, document the destination, the schedule, the integrity checks, the access controls on the destination and how a retrieval request is served. The output is a transfer decision record and, where chosen, a transfer design. The step is done when the decision is approved and the design names the systems involved.
Test that retention holds under load
Run a controlled test that sends realistic peak volume to the audit pipeline, confirms that records persist for the full defined retention period, and checks that alerts fire before capacity is exhausted. Verify that no records are lost or overwritten early by comparing record counts at source and at storage, and that any transferred copies match. Your own engineers or your implementation partner can run the test, but the organization owns the acceptance decision. The output is a dated test report with the configuration tested, the results and any remediation. The step is done when the report shows retention held under the tested load and the findings are tracked to closure, ready for an independent assessor to examine.

Which evidence shows AU-4 storage capacity is met

An assessor testing AU-4 wants to see that the storage allocated for audit records matches the retention requirements the organization defined, and that the allocation holds up in operation. The cards below cover the artifacts that link those two things, and each one needs a dated copy and an owner so it stays current between assessments.

Written audit log retention requirements

AU-4 depends on the retention period set under AU-11, so the starting artifact is the approved retention schedule. It should state each log source, the retention period, the legal or contractual basis for it, and the owner who approved it. Check that the schedule matches what the logging platforms actually keep, and re-approve it whenever a regulation or contract changes the period.

Storage sizing calculation and assumptions

The sizing worksheet converts retention requirements into required capacity. It records the average and peak event volume per source, average record size, retention period, compression and replication factors, and headroom. Keep the assumptions visible, because an assessor will ask what happens when event volume grows. Re-run the calculation after new log sources are onboarded and file the dated version with the change record.

Storage configuration and capacity monitoring exports

Exports from the logging stack show the storage volumes, retention settings and current utilization for each audit component. For a self-hosted platform, capture the relevant configuration files and the query output that reports used and free space over time. Dated exports from each quarter let an assessor see that capacity was tracked continuously, not only at the moment of the review.

Capacity threshold alert records

Alert rules that fire at defined utilization levels show that someone was told before storage ran out. Keep the rule definitions, the notification routing, and a sample of fired alerts with acknowledgment and response notes. Grafana Alerting can build such rules from metrics and logs in one place, but the organization must confirm which thresholds it set and who receives them.

Transfer job logs for AU-4(1)

If the organization implements AU-4(1), transfer jobs move audit records from primary storage to alternate storage. The job logs show schedules, success or failure per run, record counts and checksums where used. Review failed transfers and confirm that records were not deleted from primary storage before a successful copy existed. Note that the SP 800-53B baselines do not select AU-4(1), so this evidence applies only where the organization chose to implement it.

Test results showing no record loss

A capacity test fills storage toward its limit in a non-production environment and checks what the platform does: whether it stops accepting records, overwrites old ones, or raises an alert first. Record the test plan, the outcome and the remediation. Repeat the test after changes to storage size or log volume, and keep the dated report with the configuration it tested.

What meeting AU-4 storage capacity costs in money and effort

This table breaks down the cost components of meeting AU-4 audit log storage capacity, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to shape a quote request, since no price or duration is supplied for this control and every figure depends on your own log volume and retention rules.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it and how to reduce it
Storage hardware or cloud storage	Your cloud provider, data center or hardware vendor	Recurring for cloud storage; one-time plus refresh for on-premises arrays	Event volume, retention length and replication copies. Reduce by filtering low-value events, tiering older logs to cheaper storage and confirming replication needs with your retention policy.
Logging platform licenses	Commercial logging vendor or SIEM provider	Recurring, often priced on ingest or retention	Number of log sources and daily ingest volume. Self-hosted open-source platforms such as Prometheus, Grafana and Nextcloud's audit logging can remove per-seat or per-volume license spend, though support and hosting still apply.
Engineering time for sizing and configuration	Your internal platform team or an implementation partner under a written scope	One-time, with revisits when sources change	Number of log sources, retention periods and whether storage thresholds and alerts are built from the start. Reduce by sizing from a documented event inventory rather than estimating after go-live.
Ongoing capacity review	Your operations or security team, or a retained support provider	Recurring	Growth in event volume and new systems added to scope. Reduce by alerting on storage usage trends so reviews are scheduled, not reactive.
External review of the sizing	Independent assessor or a consultant you engage	One-time per assessment cycle	Depth of the review and how much documentation you supply. Ask whether the quote covers the sizing calculation, the retention justification and a sample of storage configurations.
Auditor sampling time	The independent auditor or assessor you engage	Recurring per assessment	Number of systems in scope and how easily you can produce storage configurations, capacity reports and alert history on request. Keep these evidence sets current to shorten sampling.

Which open-source tools produce AU-4 capacity evidence

AU-4 is satisfied by a documented storage allocation that fits the retention requirement, and the evidence is the configuration and the monitoring history behind it. The four tools below each produce a different piece of that picture: where audit records land, how a platform's own API audit trail is written, how storage and log conditions are alerted on, and how capacity metrics are collected over time.

Nextcloud admin_audit logging

The admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. For AU-4, the file location is the storage decision: confirm which volume holds it, how much space that volume has, and whether it sits on the same disk as user data. Capture the logging configuration and the directory listing as evidence of where records are stored. Confirm log rotation and retention settings in your own deployment, since this page does not establish any default.

OpenBao audit devices

OpenBao audit devices keep a detailed JSON log of every API request and response, including errors, with most sensitive values hashed using HMAC-SHA256. Because every request produces an entry, audit device volume grows with secret activity, which makes it a capacity planning input in its own right. Evidence for AU-4 includes the audit device configuration, the storage location it writes to, and a record of how growth was measured against the retention period. Confirm the failure behavior of the audit device with your own configuration and tests.

Grafana Alerting on storage conditions

Grafana Alerting builds alert rules from queries and expressions across multiple data sources and can alert on metrics and logs together. Rules that watch free space on audit volumes, or the log-ingest volume that feeds them, turn a capacity risk into a notification before records are lost. Evidence includes exported alert rule definitions, notification routing, and a history of fired alerts and responses. Confirm the thresholds, notification channels and escalation path in your environment, since they are set by the operator.

Prometheus capacity metrics

Prometheus collects metrics from instrumented jobs through a pull model over HTTP and stores them as time series on autonomous local storage, queried with PromQL. Disk usage metrics exported from audit hosts and log stores can show the trend that AU-4 assessors ask about: whether allocated capacity still covers the retention period. Evidence includes the scrape configuration, the PromQL queries used for capacity trends, and retained time series. Confirm the Prometheus retention setting and the storage size of its own data directory, because metric history is also subject to local capacity limits.

Who owns AU-4 storage capacity and what gets outsourced

Your organization owns AU-4 in full. The control requires an allocation of audit log storage capacity that accommodates the audit log retention requirements you define, so the retention decision is a business and legal decision that belongs to you, not to a vendor or consultant. Your team also carries the operational duty of keeping the storage available and responding when capacity warnings fire.

Retention decisions: Set and approve the retention periods for each log source, based on your legal, contractual and internal obligations, and record who approved them.
Storage ownership: Fund, provision and operate the storage that holds audit records, including the capacity headroom you choose to keep.
Alert response: Staff the people who act on storage and ingestion alerts, and define what happens when capacity runs low.
System security plan entry: Write and maintain the AU-4 entry in the system security plan, naming the responsible role, the retention periods and the storage design.
Ongoing review: Re-check capacity when log volume, new systems or retention rules change.

Before engaging anyone, confirm which of these roles already have named owners in your environment, because assessors will look for those names first.

Where organizations fall short on AU-4 and how to close each gap

AU-4 looks simple on paper, but assessors find the same weaknesses repeatedly: retention rules that live in conversation, alerts nobody reads, and capacity plans that stopped at deployment. Each gap below breaks the link between a defined retention requirement and audit records that actually survive.

Retention period exists only in conversation

Teams often say logs are kept for a certain period, but no document states the number, the log sources it covers or who approved it. AU-4 depends on a defined audit log retention requirement, so capacity cannot be sized against it. Write the retention period per log source in the audit policy, have the owner approve it, and check that the storage plan references that same number. Ask the assessor to trace one log source from the policy to the sizing calculation.

Capacity alerts go unmonitored

Storage utilization warnings are frequently sent to a shared mailbox that no one watches, or to a channel with no defined responder. The warning exists, but nobody acts before the disk fills. Route capacity alerts to a monitored queue with a named on-call owner and a documented response step. Test the route by triggering a non-production threshold alert and recording who acknowledged it and when.

Storage sized once and never reviewed

Log volume grows as users, services and event types are added, yet the storage allocation often reflects the day the system went live. The result is a retention commitment that quietly stops being true. Review actual growth against the allocation on a set schedule, and record each review with the date, the measured volume and any change made. Dashboards that show daily ingestion trends make this review routine rather than ad hoc.

No test that retention survives a full disk

Many programs have never checked what happens when the audit store reaches its limit. Some platforms stop logging, overwrite the oldest records or drop new events silently, and each outcome breaks AU-4. Run a controlled test in a non-production environment that fills the audit volume and records the system's behavior, including whether AU-5 alerts fire. Keep the test output as evidence for the assessor.

Alternate storage claimed without proof

The AU-4(1) enhancement asks for audit records to be transferred to a different system or media, but it is frequently described in diagrams without any running job. Confirm that a transfer process exists, that it runs on schedule, and that records arrive intact at the alternate location. Keep transfer logs, checksum or count comparisons and a sample restore so the claim rests on evidence. The enhancement is not selected in SP 800-53B baselines, so confirm whether your system selects it through tailoring or a custom requirement.

What do buyers ask about AU-4 storage capacity before hiring help?

How much effort does AU-4 take compared with other audit controls?

AU-4 is a single requirement with one determination statement, so the control itself is narrow. The effort comes from the inputs it depends on: your defined audit log retention periods, the volume of logs each component produces, and whether storage has been sized against both. Teams that already document retention under AU-11 and know their event volume usually find AU-4 quicker to evidence. Teams without those inputs spend most of their time establishing them first. Ask a prospective partner to estimate effort from your retention schedule and component list, and to state which inputs they expect you to supply.

Is AU-4 required in every SP 800-53 baseline?

AU-4 is selected for the low, moderate and high baselines in SP 800-53B Release 5.2.0. It is not selected for the privacy baseline. Its one enhancement, AU-4(1), which covers transferring logs to alternate storage, is not selected in any baseline, including low, moderate, high and privacy. That means an assessment of a standard baseline tests the base control, while the enhancement applies only if your organization or a contract adds it through tailoring. Confirm the baseline your system's impact level selects with your authorizing official or contract owner before scoping the work.

Can our own team implement and evidence AU-4 without outside help?

Yes, in principle. AU-4 is an organizational requirement, so your staff can allocate storage, set retention-driven sizing and keep the records. The question is capacity and independence. Someone must own the storage sizing, monitor capacity against retention targets and produce the configuration and capacity evidence an assessor will examine and test. Many teams keep ownership in-house and bring in a partner only for the platform work, such as configuring log storage on self-hosted systems. Decide which of those tasks your staff can sustain after the initial work is complete.

How long does AU-4 work take, and what does the client need to provide?

No duration is fixed for AU-4 here, because it depends on how many systems are in scope and how mature their logging is. The work runs in three parts: confirming retention requirements, sizing storage for each in-scope component, and collecting capacity evidence. The client typically provides the retention schedule, component and log source inventory, current storage allocations, access to configuration for the logging and storage platforms, and named owners for audit and infrastructure decisions. Ask any partner to state the duration and dependencies in the written scope before work starts.

What can a partner do for the AU-4 assessment, and what can it not do?

A partner can prepare systems and evidence: configure storage allocations, document sizing logic, set capacity monitoring, and assemble the configuration records an assessor will test. It cannot assess the control or issue a finding. Under SP 800-53A, assessment is performed through examine, interview and test methods, and the results are determined by your independent assessor or authorizing body. The organization still owns the control and its retention decisions. Confirm with any provider in writing that its role ends at preparation and that the assessor is independent of the implementation work.

Which AU-4 costs recur after the first implementation?

The recurring costs are mostly operational. Storage capacity must grow as event volumes grow or retention periods change, so the storage bill, hardware refresh or cloud capacity spend continues. Capacity monitoring and periodic review of sizing against retention requirements also recur, as do updates when logging sources are added. Partner costs recur only if you buy a retainer for ongoing support or upgrades. When requesting a quote, ask the provider to separate one-time setup from recurring support, and ask your own team to model storage growth against your retention schedule.

Which open-source tools produce AU-4 capacity evidence?

Several self-hosted platforms emit logs that you can size and monitor. Prometheus collects metrics over HTTP and stores them as time series on local storage, so its disk allocation and retention settings are direct capacity evidence. Grafana Alerting can raise alerts from metrics and logs in one place, which helps show that storage thresholds are watched. Nextcloud's admin_audit app writes audit records to audit.log in the data directory or a configured path, and OpenBao's audit devices write detailed JSON logs, so their storage locations and rotation settings belong in your sizing record. Confirm each tool's retention and rotation behavior in your version before relying on it as evidence.

How DeployOpen scopes and prepares AU-4 storage evidence

DeployOpen works on AU-4 by preparing the self-hosted logging stack inside your own infrastructure so that storage capacity can be sized to your defined retention requirements and shown to an assessor. We plan, configure and document the capacity evidence, while your organization owns the control and the independent assessor reaches its own conclusion.

How we scope

Scope names the audit log sources, retention periods and storage locations that AU-4 covers in your environment.
We agree in writing which platforms, such as Nextcloud, OpenBao or Prometheus, are in scope for storage sizing.
Engagements are fixed-scope, so deliverables and timelines are settled in writing before work starts.
Your organization confirms its retention requirements, since the control depends on those defined values.

How we build

We configure audit output paths and storage volumes so each platform writes its logs to a defined location.
We set up capacity monitoring and alert rules so storage pressure is visible before audit data is lost.
We configure the transfer of logs to alternate storage where your AU-4(1) decision calls for it.
We test capacity thresholds and alerting in a non-production environment before changes reach production.

How we hand over

You receive configuration records showing storage allocation, retention settings and alert thresholds for each platform.
Documentation maps each storage setting to the retention requirement it supports, for your assessor to examine.
Test results show the alerting and capacity checks performed, with the date and configuration version recorded.
Handover includes runbooks so your own staff can respond to capacity alerts after the engagement ends.

How we support

Ongoing support and upgrades are available as a retainer, covering changes to log volume and retention.
Capacity reviews can be repeated when retention requirements, platforms or log volumes change.
Your organization decides whether to keep the retainer, and independent auditors issue any assessment report.
We help you prepare evidence for an assessor, but we do not issue audit reports, attestations or certifications.