AU-5(3): Configurable Traffic Volume Thresholds

AU-5(3) sits in the NIST 800-53 Audit and Accountability family and addresses a failure mode that shows up during incidents: the environment keeps accepting traffic while audit logging falls behind, drops events, or runs out of storage. The control forces you to design for “logging is a dependency,” and to treat traffic volume as something you can throttle based on what your audit pipeline can safely ingest and store.

For a CCO or GRC lead, the fastest way to operationalize AU-5(3) is to (1) identify the systems where high traffic can saturate logging (internet gateways, API front doors, load balancers, message queues), (2) calculate safe operating limits based on logging capacity and retention commitments, and (3) implement a technical enforcement point that either rejects or delays traffic when the threshold is hit. The deliverable auditors want is simple: proof that thresholds are configurable, tied to audit log storage capacity, enforced automatically, and governed through change control. ¹

If you manage compliance for federal systems or contractor systems handling federal data, AU-5(3) is also a practical due diligence topic for third parties that provide edge services, managed SIEM, logging agents, WAF/CDN, or API gateways, because their design choices can determine whether your audit trail survives a traffic surge.

Regulatory text

NIST requirement (AU-5(3)): “Enforce configurable network communications traffic volume thresholds reflecting limits on audit log storage capacity and [one or more of: reject; delay] network traffic above those thresholds.” ¹

What the operator must do (requirement-level)

You must implement technical controls that:

1. Use configurable thresholds for network communications traffic volume (you can change them without re-architecting the system). ¹
2. Base those thresholds on audit log storage capacity limits, meaning the maximum sustainable logging volume given your ingestion, indexing, storage, and retention design. ¹
3. Automatically enforce one or more actions when thresholds are exceeded: reject traffic, delay traffic, or both, based on your design choice and risk acceptance. ¹

A practical interpretation: if a spike in requests could cause dropped logs or exhausted storage, your system must throttle the requests (delay) or shed them (reject) so the audit function remains reliable.

Plain-English interpretation

AU-5(3) means: your logging capacity is a hard constraint. When traffic increases to the point that it could overwhelm your ability to store audit logs, you must have a configurable mechanism to slow down or block that traffic, rather than silently losing audit records.

This is not a “nice-to-have performance tuning” control. It is an audit integrity control. The business outcome is that, during stress, you can still answer: who did what, from where, and when.

Who it applies to (entity and operational context)

AU-5(3) applies most directly to:

• Federal information systems using NIST SP 800-53 as their control baseline. ²
• Contractor systems handling federal data where 800-53 controls flow down via contract, agency requirements, or alignment to NIST-based programs. ²

Operationally, it applies where “network communications traffic volume” can spike and where logs are security-relevant:

• Internet ingress/egress (firewalls, proxies, secure web gateways)
• API gateways and load balancers
• WAF/CDN request handling tiers
• Identity endpoints (SSO, token services)
• Message brokers and integration layers
• Centralized log pipelines (agents, collectors, forwarders) where ingestion backpressure can cascade

Third-party risk angle: if a third party runs your edge (CDN/WAF), SIEM, or managed logging pipeline, AU-5(3) becomes a shared responsibility requirement. You still need evidence that thresholds exist and are enforceable, even if configured in the third party’s console.

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

Step 1 — Assign ownership and define the control boundary

• Name an engineering owner (typically Network/SRE/SecOps) and a governance owner (Security Compliance/GRC).
• Define which systems are in scope for thresholding (start with primary ingress paths and log pipeline choke points).
• Document the enforcement points you will use (API gateway throttles, WAF rate limits, load balancer connection limits, queue backpressure).

Operator output: a one-page control card/runbook with objective, scope, and owners.

Step 2 — Establish audit log capacity limits you can defend

You need a defensible statement of capacity. Build it from:

• Log sources in scope (gateway logs, auth logs, app audit events, network device logs)
• Log ingestion path (agents/collectors, transport, parsing)
• Storage and retention commitments (hot/warm/cold tiers if applicable)
• Failure behavior (what happens when storage is full or ingestion lags)

Translate this into an upper bound: “If traffic exceeds X, audit logging is at risk.” AU-5(3) does not dictate the math; it dictates that the threshold must reflect audit log storage capacity. ¹

Tip for practicality: define thresholds per tier (edge, API, internal) so you can throttle close to the source.

Step 3 — Choose enforcement behavior: reject, delay, or both

Decide what happens above threshold:

• Reject: Return errors (for example, HTTP 429/503) or drop new connections. Best where traffic is abusive or non-critical.
• Delay: Queue, slow down, or apply backpressure. Best where you can tolerate latency and need graceful degradation.
• Both: Delay first; reject at a higher “hard ceiling.”

Document your choice and the rationale. AU-5(3) explicitly expects one or more of reject/delay. ¹

Step 4 — Implement configurable thresholds at technical enforcement points

Implement configuration where it will reliably execute during stress:

• API gateway: rate limits per client, per route, per token, burst controls
• WAF/CDN: request rate limits, bot controls, challenge policies
• Load balancer: connection limits, request queue limits, circuit breakers
• Message queues: max in-flight, consumer throttles, dead-letter policies
• Log pipeline: ingestion backpressure, buffer limits, drop policies (avoid “drop” as your primary response if it causes audit gaps)

Control requirement: thresholds must be configurable. That means you can change them via code/config management or console settings with proper access control and auditability. ¹

Step 5 — Alerting, testing, and “prove it works”

You need to show that enforcement happens, not just that a setting exists.

• Create alerts on threshold events (rate-limit triggers, queue saturation, “requests rejected/delayed” metrics).
• Test in a lower environment, then test in production during a controlled window (traffic replay, load test, or synthetic burst).
• Validate two outcomes:
  1. traffic is rejected/delayed as designed
  2. audit logging continues to ingest and store records without loss during the event window

Step 6 — Govern configuration changes (and exceptions)

Auditors will ask: who can change thresholds, and how do you prevent someone from turning them off?

• Put thresholds under change control (ticket, approval, peer review).
• Restrict who can modify policies in WAF/CDN/API gateway.
• Define an exception process for systems that cannot throttle (legacy or safety-critical). Exceptions should be time-bound with compensating controls.

Daydream fit (earned mention): many teams fail AU-5(3) on evidence, not technology. Daydream can track the control card, required evidence bundle, recurring health checks, and remediation items so you can show sustained operation without assembling screenshots at audit time.

Required evidence and artifacts to retain

Keep evidence that maps directly to “configurable,” “capacity-based,” and “enforced reject/delay.”

Minimum evidence bundle (audit-ready):

• Control card / runbook: scope, owners, enforcement points, reject/delay decision, escalation path.
• Capacity basis: diagram of log pipeline, storage/retention assumptions, and the logic used to derive thresholds.
• Configuration exports (or screenshots where exports aren’t possible):
  • WAF/CDN rate limiting policies
  • API gateway throttling policies
  • Load balancer connection/request limits
• Change records: tickets/PRs showing threshold changes, approvals, and implementation dates.
• Test records: load test plan, results, and evidence of enforcement (metrics, logs).
• Monitoring evidence: alert definitions and sample alerts for threshold events.
• Access control evidence: IAM roles/groups permitted to change thresholds.

Retention location matters. Store evidence in a controlled repository with a clear naming convention aligned to AU-5(3).

Common exam/audit questions and hangups

Auditors and assessors often probe these points:

1. “Show me the threshold and how it ties to log storage capacity.”
   Hangup: teams present generic API rate limiting without connecting it to audit logging constraints.

2. “What happens when you exceed it?”
   Hangup: “we alert and scale” is not the same as reject/delay enforcement. AU-5(3) requires an enforceable action. ¹

3. “Is it configurable, and who can change it?”
   Hangup: thresholds hard-coded in application logic with no governance trail.

4. “Prove it works in production conditions.”
   Hangup: no test evidence, only design documents.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails AU-5(3)	Fix
Setting rate limits based on app performance only	Thresholds are not tied to audit log storage capacity	Document logging capacity constraints and derive limits from them 1
Alert-only approach	No reject/delay enforcement	Implement automatic throttle/reject at the edge 1
Thresholds exist but aren’t configurable safely	Anyone can change them, or changes aren’t tracked	Put thresholds behind IAM + change control; retain change artifacts
Logging pipeline drops events under load	You “protected” the app but lost audit records	Add backpressure, increase buffer/storage, and throttle earlier
Single global threshold	Doesn’t match different log volumes per endpoint/tenant	Use tiered or per-route/per-client thresholds tied to audit impact

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat AU-5(3) as an assessment and audit expectation rather than cite specific regulator actions.

From a risk standpoint, AU-5(3) reduces:

• Forensic failure risk (missing audit logs during the exact period you need them)
• Detection failure risk (SIEM blind spots during spikes or attacks)
• Operational risk (log storage exhaustion cascading into broader outages)

For federal and federal-adjacent environments, weak auditability can also become a contractual and program-level compliance issue during assessments aligned to NIST SP 800-53 Rev. 5. ²

Practical 30/60/90-day execution plan

First 30 days (get to “designed and scoped”)

• Assign control owner(s) and publish the AU-5(3) control card.
• Inventory ingress points and log pipeline dependencies.
• Define audit log capacity constraints and identify top “log loss” scenarios.
• Select enforcement points (WAF/CDN, API gateway, load balancer) for initial rollout.
• Define evidence bundle and where it will be stored.

Days 31–60 (implement and test)

• Configure thresholds in the selected enforcement points.
• Implement monitoring and alerting for threshold events.
• Run a controlled test to trigger delay/reject and confirm logging continuity.
• Put threshold configurations under change control and tighten IAM permissions.

Days 61–90 (expand coverage and operationalize)

• Extend thresholds to remaining high-risk paths (admin endpoints, auth endpoints, partner integrations).
• Run a control health check: verify thresholds still match current storage/retention capacity.
• Document exceptions with compensating controls and expiry dates.
• Set a recurring review cadence tied to log retention changes, SIEM changes, and major traffic profile changes.

Frequently Asked Questions

Do I have to reject traffic, or can I only delay it?

AU-5(3) allows “reject,” “delay,” or both, but you must implement at least one enforceable action above the threshold. Document your chosen behavior and show configuration evidence. ¹

What counts as “traffic volume” for AU-5(3)?

Treat it as the network communications load that drives audit events, such as requests per second, connections per second, or message throughput. Pick a metric you can enforce at the boundary where traffic enters the system.

How do I prove the threshold “reflects limits on audit log storage capacity”?

Keep a short capacity basis artifact that links expected audit event volume to ingestion and storage constraints, then show that your configured threshold is derived from that basis. Assessors look for a rational, documented tie to logging capacity. ¹

We use a managed SIEM. Does AU-5(3) still apply?

Yes. Your audit pipeline still has capacity limits, even if storage is outsourced. Get evidence from the third party on ingestion limits, throttling/backpressure features, and how threshold events are logged.

Can autoscaling replace AU-5(3) threshold enforcement?

Autoscaling can help, but AU-5(3) requires an enforcement mechanism to reject or delay traffic above thresholds tied to audit log storage capacity. If scaling fails or lags, you still need the throttle behavior. ¹

What’s the minimum evidence an auditor will accept?

Provide the configured threshold settings, a documented basis tied to audit log capacity, a change record showing governance, and test/monitoring evidence showing reject/delay events and continued log ingestion.

Footnotes

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

2. NIST SP 800-53 Rev. 5