AU-5(1): Storage Capacity Warning

AU-5(1) requires you to automatically warn designated responders within a defined time window when your audit log repository reaches a defined capacity threshold, so you can act before logging stops or overwrites. To operationalize it, set measurable thresholds and notification targets, implement monitoring and alerting on every log store, and retain evidence that alerts fired and were handled. ¹

Key takeaways:

• Define three variables up front: who gets alerted, how fast, and at what capacity threshold. ¹
• Implement alerts on the actual audit log repositories (SIEM, cloud log services, endpoint log collectors), not just on general disk utilization.
• Keep proof of operation: configuration, alert test results, and incident/ticket records showing response when thresholds are hit.

Audit logs are only useful if they exist when you need them. Capacity failures are a common “silent” control break: the system keeps running, teams assume logging is fine, and then an incident or audit reveals log gaps or overwritten records. AU-5(1) is the requirement-level fix for that scenario. It forces you to set a clear warning trigger tied to audit log storage saturation and notify the right people fast enough to prevent data loss.

This requirement is intentionally specific: it does not ask for general monitoring, and it does not ask you to expand storage forever. It asks for a warning to defined personnel, roles, or locations within a defined time period when allocated audit log storage reaches a defined percentage of the repository’s maximum capacity. ¹ Your job as a CCO or GRC lead is to turn those brackets into decisions, then ensure engineering can prove the warning mechanism works continuously across the systems in scope.

Below is a requirement page you can hand to operations with clear implementation steps, evidence expectations, and audit-ready talking points.

Regulatory text

Requirement (AU-5(1)): “Provide a warning to [personnel, roles, and/or locations] within [time period] when allocated audit log storage volume reaches [percentage] of repository maximum audit log storage capacity.” ¹

What the operator must do

• Decide who receives the warning (named team, role-based on-call, SOC mailbox, etc.). ¹
• Decide how quickly they must be notified after the threshold is reached. ¹
• Decide the capacity threshold that triggers the warning, measured against the audit log repository’s maximum capacity. ¹
• Implement monitoring so the warning occurs reliably and is not dependent on a person checking dashboards.

Plain-English interpretation

You must detect “we are running out of space for audit logs” early enough that staff can fix it before logs stop being stored, roll off, or overwrite. The warning must go to the right place (role/person/location), within a defined time window, at a defined saturation point of the log repository.

This is an availability requirement for evidence. If your audit logs drop, investigations, incident response, fraud detection, and regulatory reporting all degrade. AU-5(1) focuses on the leading indicator: storage consumption in the audit log repository.

Who it applies to (entity and operational context)

Entities

• Federal information systems and contractors handling federal data commonly inherit AU controls through system security plans and contract requirements. ²
• Any organization aligning to NIST SP 800-53 Rev. 5 will treat this as a baseline logging resilience requirement. ³

Operational contexts in scope

• Centralized SIEM platforms (self-hosted or managed) where audit logs are indexed and retained.
• Cloud-native logging services (for example, log groups/buckets/workspaces where audit logs land).
• Endpoint, database, and application audit log repositories when they store locally or in a dedicated datastore before forwarding.
• Managed security providers or third parties operating logging infrastructure for you. You still need assurance that warnings occur and reach your defined recipients.

Common scoping call you must make

• What counts as an “audit log repository” in your environment: your SIEM index, object storage bucket, log analytics workspace, or all of the above. Treat each distinct storage boundary as a repository with its own maximum capacity and alerting.

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

1) Turn the bracketed variables into decisions (control design)

Create a short control card (one page) with:

• Alert recipients: primary and secondary (role-based where possible, tied to on-call). ¹
• Time to warn: define the maximum time allowed from threshold breach to notification delivery. ¹
• Capacity threshold: define the percentage of maximum capacity that triggers the warning. ¹
• Repositories covered: list each log repository and its owner.
• Response expectation: what responders must do when alerted (extend capacity, fix pipeline backlog, adjust retention, route to cold storage, etc.).

Practical choices:

• Use role-based targets (SOC on-call, SRE on-call) rather than a single person.
• Set distinct thresholds for high-ingest systems if needed, but document exceptions.

2) Build an authoritative inventory of audit log repositories (control scope)

You cannot pass an audit with “we alert on the SIEM” if multiple systems store audit logs elsewhere first.

Minimum inventory fields:

• Repository name and platform (SIEM index, cloud log workspace, bucket).
• Maximum capacity definition (license cap, disk allocation, service quota).
• Current retention and expected ingest drivers.
• Monitoring method and alert routing destination(s).
• Owner and backup owner.

3) Implement capacity monitoring on each repository (control implementation)

Engineering tasks typically include:

• Collect metrics for allocated audit log storage volume and maximum capacity for each repository. ¹
• Compute the saturation ratio and compare to your defined threshold.
• Trigger alert generation at or above threshold and route it to the defined recipients.

Implementation notes that reduce audit pain:

• Alert must be tied to the audit log repository’s capacity, not generic host disk usage, unless the repository capacity is truly the same thing (document that equivalence).
• Ensure alerts still fire when log pipelines are degraded (out-of-band monitoring is ideal).
• Route alerts into your ticketing/incident system so you can show acknowledgement and closure.

4) Define the response runbook (control operation)

For each alert, responders need an approved set of actions. Common actions:

• Increase storage allocation or service quota.
• Reduce ingest volume from noisy sources (only if policy allows; document approvals).
• Adjust retention tiers (hot to warm/cold) while still meeting retention requirements elsewhere.
• Fix forwarding failures that cause local buildup.
• Validate that logging continued during the event and that no rollover/overwrite occurred.

Write the runbook so it answers two audit questions: “Who responds?” and “How do you prevent log loss?”

5) Test the warning path and record results (control validation)

AU-5(1) is easy to claim and easy to fail quietly. You need periodic testing that demonstrates:

• The alert triggers at the defined threshold condition.
• It reaches the defined recipients within the defined time period. ¹

Testing approaches:

• Non-production or canary repository filled to simulate threshold breach.
• Synthetic metric injection if supported.
• Temporarily lowering the threshold in a controlled window (get approvals; avoid risky changes in production).

6) Operate and prove continuous effectiveness (control monitoring)

Add a lightweight “control health check”:

• Confirm alerts are enabled and not muted.
• Confirm routing is current (on-call rotations change).
• Review recent capacity trend and near-miss events.
• Track remediation items to closure when capacity warnings occur.

If you use Daydream to manage control operations, treat AU-5(1) as a recurring control with a defined evidence bundle and automated reminders for health checks, alert tests, and exception approvals.

Required evidence and artifacts to retain

Keep evidence that proves design, implementation, and operation:

Design evidence

• AU-5(1) control card (recipients/roles, time period, threshold percentage, repositories in scope). ¹
• Logging architecture diagram or dataflow showing where audit logs are stored.

Implementation evidence

• Monitoring/alert configuration exports or screenshots for each repository (threshold logic, routing targets).
• Infrastructure-as-code snippets (preferred) that define alerts and recipients.

Operational evidence

• Alert test record: date, method, expected result, actual delivery timestamps, recipients. ¹
• Tickets/incidents generated from real alerts, including triage notes and closure.
• Change records for capacity increases or retention changes tied to alerts.

Retention location

• Store artifacts in a controlled GRC repository with access control and version history. Point auditors to a single folder per control and per test cycle.

Common exam/audit questions and hangups

Auditors and assessors tend to probe four areas:

1. “What is the repository maximum capacity?”
   Be ready to explain the max: license cap, quota, allocated volume size, or service limit. Show where it is defined.

2. “Who gets warned, exactly?”
   Role-based definitions beat named individuals. Provide your on-call group mapping and escalation path.

3. “Prove the alert reaches them within your time period.”
   Screenshots alone often fail. Provide test evidence or ticket timestamps.

4. “How do you know you covered all audit log repositories?”
   Your inventory is the answer. If it is incomplete, the control is incomplete.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Alerting on server disk usage instead of the log repository	Disk can be fine while the log service quota is maxed (or vice versa)	Alert on the repository’s own capacity metric; document equivalence only when true
Single-person notification	People go on vacation; auditors see single points of failure	Use role/on-call groups; add secondary targets
Threshold exists but alerts are muted/noisy	Teams silence noisy alerts; control stops operating	Tune alerting, add deduplication, and treat muting as a change requiring approval
No evidence of testing	“Configured” is not “operating”	Run controlled tests and retain delivery proof
No runbook	Alert fires, nobody acts, logs roll off	Define response steps and ownership; tie to ticketing

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AU-5(1), so treat enforcement discussion as risk-based rather than case-based.

Risk to your organization is straightforward:

• Incident response failure: missing audit logs slow containment, root cause analysis, and recovery.
• Regulatory and contractual noncompliance: many federal-aligned programs expect auditable logging controls mapped to NIST SP 800-53.
• Legal and HR exposure: investigations can be compromised without reliable logs, especially for privileged activity.

Practically, capacity warnings are one of the highest ROI logging controls because they prevent preventable log loss events.

Practical execution plan (30/60/90-day)

You asked for a 30/60/90-day plan. Use the phases below as a working cadence; adjust to your engineering change windows.

First 30 days (design + scope)

• Name an AU-5(1) control owner (typically Security Operations or Platform Engineering).
• Draft and approve the AU-5(1) control card: recipients/roles, time period, threshold, repositories. ¹
• Build the repository inventory and identify coverage gaps.
• Confirm alert routing destinations and escalation path.

Day 31–60 (implement + integrate)

• Implement capacity alerts on all in-scope repositories.
• Route alerts into ticketing/incident tooling with required fields (repository, saturation level, timestamp, owner).
• Write the response runbook and align it with change management.
• Define the evidence bundle and the storage location for artifacts.

Day 61–90 (validate + stabilize operations)

• Execute at least one end-to-end alert test per repository type and retain proof of delivery and timeliness. ¹
• Run a control health check and remediate any muted alerts, broken routes, or missing repositories.
• Add AU-5(1) to your recurring control calendar in Daydream (or your GRC system) with owners, due dates, and evidence reminders.

Frequently Asked Questions

What counts as “repository maximum audit log storage capacity” in cloud logging?

It can be a service quota, workspace limit, allocated storage tier, or defined retention+capacity boundary, depending on the platform. Document the platform-specific “maximum” you measure against and show where it is configured or reported.

Do we have to alert on every application’s local logs if we forward everything to a SIEM?

If local logs can fill and stop logging before forwarding, they are a repository risk and should be in scope. If logs do not persist locally (or local capacity cannot affect audit logging), document that architecture decision and focus on the actual storage boundary.

How do we prove the “within [time period]” part to an auditor?

Keep an alert test record that includes the trigger time and the delivery/receipt time for the target recipients. Ticket creation timestamps and notification logs are stronger than screenshots.

Can the warning go to a “location” like a SOC dashboard instead of a person?

The text allows personnel, roles, and/or locations. ¹ In practice, treat dashboards as supplemental; auditors usually expect a routed notification to an accountable on-call role.

What if our SIEM is run by a third party?

You still need assurance that warnings fire and reach your recipients. Require alert configuration, test evidence, and operational records in the third party’s deliverables, and map them into your evidence bundle.

How should we handle exceptions, like systems with fixed storage we cannot expand?

Document an exception with compensating controls (for example, shorter retention with downstream archival) and an owner-approved risk acceptance. Keep the exception scoped, time-bound, and reviewed on a recurring basis.

Footnotes

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

2. NIST SP 800-53 Rev. 5

3. NIST SP 800-53 Rev. 5 DOI