Capacity Management as a Security Control

When a log volume fills, a cloud quota runs out or an identity provider starts throttling, the result is either an outage that looks like an attack or a monitoring gap that hides one. Capacity management is usually owned by operations and judged on cost and performance, but exhaustion of storage, quotas, connections and licences directly affects whether you can detect, contain and recover from incidents. Attackers also cause exhaustion on purpose, through floods, resource hijacking and log flooding. This guide treats capacity as a security control: which resources matter, how exhaustion turns into a blind spot, how to set thresholds and headroom, and how to plan capacity for incident response itself. It is for SRE, platform, SOC and resilience teams. It complements the Observability, telemetry and SRE for security teams, which covers telemetry pipelines and SRE methods, and does not repeat API rate limiting, covered in the OWASP API Top 10 API4 Unrestricted Resource Consumption Guide.

Key takeaways

Exhaustion fails in two directions. Some resources fail closed and cause outages; others fail open or silently and remove visibility, which is worse for security.
Security tooling needs capacity planning too. Log storage, SIEM ingest, EDR licences and backup repositories are capacity-bound, and they run out precisely when an incident multiplies their load.
Quotas are an incident response dependency. Rebuilding, isolating and forensic imaging all consume cloud quota; plan headroom for them before you need it.
Alert on trend, not just on full. A 95% alert on a disk filling at 10% an hour gives you thirty minutes; forecast time-to-exhaustion instead.
Unexpected consumption is a security signal. Sudden compute, storage or log growth can mean cryptomining, data staging or log flooding, so route capacity anomalies to the SOC as well as to operations.

Why capacity is a security issue

NIST CSF 2.0 places capacity inside the Protect function: PR.IR-04 states that adequate resource capacity to ensure availability is maintained. NIST SP 800-53 Rev 5 has several capacity controls with a direct security purpose: AU-4 Audit Log Storage Capacity, AU-5 Response to Audit Logging Process Failures with enhancement AU-5(1) Storage Capacity Warning, CP-2(2) Capacity Planning for contingency operations, SC-5 Denial-of-service Protection and SC-6 Resource Availability. The common thread is that availability and accountability both depend on resources not running out.

Google's SRE book describes how exhaustion cascades: CPU saturation slows requests and lengthens queues, memory pressure causes crashes and garbage collection spirals, thread starvation fails health checks, and file descriptor exhaustion blocks new connections. Retries without backoff multiply the load. The same mechanics apply to security systems: an overloaded log collector drops events, and an identity provider under a password spray can throttle legitimate users.

Resources that fail into a security problem

Resource	What happens at exhaustion	Security consequence
Local event log size (for example the Windows Security log)	Old events overwritten, or logging stops, depending on retention setting	Evidence lost; attacker activity unrecorded
Log collector buffers and disk	Events queued, then dropped	Detection gap that looks like quiet
SIEM ingest licence or daily cap	Ingest throttled, sources disabled to save cost	Sources silently missing during the busiest period
EDR and MDM licences	New devices not protected or not enrolled	Unmanaged endpoints
Backup repository capacity	Jobs fail, retention shortened to make room	Recovery points missing when ransomware hits
Cloud service quotas	New instances, IPs or snapshots refused	Cannot scale under attack, rebuild, or image disks for forensics
Identity provider and API rate limits	Requests throttled	Users locked out; automation such as provisioning or revocation fails
Disk on domain controllers and critical servers	Services stop or databases go read-only	Authentication outage
Network: firewall sessions, NAT ports, DHCP scopes, IP ranges	New connections refused	Outage; some devices may fail open to bypass paths
Certificate and key stores, HSM capacity	Cannot issue or rotate	Rotation deferred; expired credentials. See the Certificate Expiry Outages and 47-Day TLS Certificates Guide

Decide for each resource whether it should fail open or closed. For logging, NIST AU-5 leaves the action on failure to the organisation: some regulated systems choose to stop processing rather than run unaudited, while most enterprises choose to alert and keep running. Write the choice down, because the default chosen by a product may be neither.

Deliberate exhaustion by attackers

Technique	ATT&CK	Capacity angle
Endpoint Denial of Service, including Application Exhaustion Flood	T1499, T1499.003	Exhausts application resources rather than bandwidth; headroom and load shedding limit impact. See the DDoS Protection Guide
Resource Hijacking	T1496	Cryptomining or abuse consumes compute and quota, often first seen as a cost or capacity anomaly
Log flooding to hide activity	Not a single technique; treat as defence impairment	Noise fills buffers, caps or retention so real events are dropped or overwritten
Data staging before exfiltration	Collection behaviour	Unexpected storage growth on file servers or buckets

For cost-driven exhaustion of AI and pay-per-use services, see the Denial-of-Wallet and AI Agent Cost Runaway Guide.

Setting thresholds and headroom

A single "90% full" alert is too late for fast growth and too noisy for slow growth. Use three layers:

Utilisation threshold: a warning at a fixed percentage. NIST AU-5(1) describes exactly this for log storage: a warning when allocated storage reaches a defined percentage of maximum capacity.
Time to exhaustion: forecast from the recent growth rate and alert when the projected full time is less than your response time plus a margin, for example under 72 hours for storage and under 24 hours for log buffers (NHI Mgmt Group suggested values).
Rate of change: alert on unusual growth even when far from full, and send it to the SOC, because that is where hijacking, staging and flooding show.

Cloud quota monitoring by platform

Platforms are listed alphabetically; confirm current options in each provider's documentation.

AWS: the Service Quotas console can create Amazon CloudWatch alarms for quotas that support them, at a chosen utilisation threshold. Notification actions are added separately in CloudWatch.
Google Cloud: in IAM and Admin, Quotas and System Limits, "Create usage alert" notifies when usage reaches a percentage of the maximum, for project-level quotas. Google notes quota values update once a day, so build in that delay.
Microsoft Azure: My quotas lets you create usage alert rules at a usage percentage (default 80%), evaluated every 5, 10 or 15 minutes, with a managed identity that needs read access to the subscription. Quota usage can also be queried through Azure Resource Graph.

Headroom for incident response

CP-2(2) asks for capacity planning so that capacity exists during contingency operations. In practice, reserve headroom for the incident case: quota to stand up a clean environment, snapshot and storage capacity for forensic images, SIEM ingest for turning on verbose logging, and spare licences for emergency endpoint deployment. Google's SRE book uses N+2 in its capacity planning example, a useful reference for service capacity; for security tooling, plan for a multiple of normal log volume during an incident, measured from your own past incidents or exercises.

Where identity fits

Identity systems are capacity-bound in ways that matter: provisioning and deprovisioning connectors hit API rate limits during bulk changes, so a mass revocation after a compromise may run slower than expected. Service accounts used by monitoring and backup tools need quota and permission to keep working when you most need them. Test bulk session revocation and credential rotation at scale before an incident, and record throttling limits from each provider's documentation. See the Backup Identity Isolation Guide for protecting the identities behind recovery tooling.

Implementation approach

Inventory security-relevant capacity: list the resources in the table above for your estate, with owner, current limit and current usage.
Classify failure mode: for each, record whether exhaustion causes an outage, a silent gap or both, and the intended behaviour.
Configure log retention safely: size local logs and collector buffers for the longest expected collector outage, and alert on logging process failures (AU-5).
Add layered alerts: utilisation, time to exhaustion and rate of change, with rate-of-change alerts going to the SOC.
Reserve incident headroom: agree quota increases in advance and document how to raise them quickly, including who holds the permission.
Exercise it: include a capacity element in tabletop or live exercises, such as SIEM ingest doubling or a quota being hit during rebuild, and record what broke.
Review quarterly: compare forecasts with actual growth and adjust limits and thresholds. Roll back noisy alerts by widening thresholds rather than deleting them.

Small organisations: focus on four items: log sizes on servers, backup capacity, licence counts and disk on critical systems, with simple alerts. Large organisations: feed capacity telemetry into the same platform as security monitoring and give the SOC read access to capacity dashboards.

Detection and measurement

Coverage: share of security-relevant resources with utilisation and time-to-exhaustion alerts.
Log loss: events dropped or overwritten per month across collectors and endpoints, target zero.
Headroom: minimum headroom across SIEM ingest, backup storage and key quotas, against your incident multiple.
Capacity incidents: number of outages or gaps caused by exhaustion, and how many were predicted by a forecast alert.
Anomaly hand-off: capacity anomalies triaged by the SOC, and how many turned out to be security events.

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	PR.IR-04	Adequate resource capacity to ensure availability is maintained
NIST CSF 2.0	DE.CM-01	Network monitoring, including capacity anomalies
NIST SP 800-53 Rev 5	AU-4, AU-5, AU-5(1)	Log storage capacity, logging failure response, storage warnings
NIST SP 800-53 Rev 5	CP-2(2)	Capacity planning for contingency operations
NIST SP 800-53 Rev 5	SC-5, SC-6	Denial-of-service protection; resource availability through allocation and priority
NIST SP 800-53 Rev 5	SI-4, CA-7	System monitoring and continuous monitoring
MITRE ATT&CK v20	T1499, T1499.003, T1496	Endpoint Denial of Service, Application Exhaustion Flood, Resource Hijacking

Common failure patterns

Security log set to overwrite with a tiny size: evidence of an intrusion is gone within hours on a busy server.
Turning off log sources to stay under the SIEM cap: the cheapest sources to drop are often the ones an investigation needs.
Quota hit during recovery: the rebuild stalls while a quota increase request waits in a queue.
Backups quietly shrinking: retention is cut to fit storage and nobody records that recovery points have gone.
Capacity alerts only to operations: a compute spike from cryptomining is treated as a scaling problem and resolved by adding capacity.
Retry storms: clients retrying without backoff turn a partial outage into a full one, as Google's SRE book describes.

Practitioner checklist

List security-relevant capacity resources with owners, limits and failure modes.
Size local logs and collector buffers for the longest expected outage, and alert on logging failures.
Alert on utilisation, time to exhaustion and unusual growth; route growth anomalies to the SOC.
Set cloud quota alerts on the quotas your recovery plan depends on.
Reserve headroom for incident response: quota, forensic storage, SIEM ingest and spare licences.
Test bulk revocation and rotation against identity provider rate limits.
Include capacity exhaustion in incident exercises and review forecasts quarterly.

Capacity Management as a Security Control: Stop Exhaustion From Becoming an Outage or Blind Spot