Skip to content
AuditFront
A1.1 SOC 2

SOC 2 A1.1: Availability - System Availability and Capacity Management

What This Control Requires

The entity maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives.

In Plain Language

If your systems run out of headroom - CPU, memory, storage, bandwidth - your customers experience slowdowns or outages. Auditors want to see that you saw it coming and acted before it became a problem.

In practice, this means monitoring resource utilisation across your entire stack, understanding usage trends and growth patterns, and planning capacity increases before they're needed. It covers servers, databases, network infrastructure, cloud services, and any third-party systems in your delivery chain.

During a SOC 2 availability audit, assessors look for evidence that you track capacity metrics with defined thresholds and alerts, that your capacity planning process is documented, and that you proactively manage resources rather than scrambling after an outage caused by resource exhaustion.

How to Implement

Start by deploying monitoring across all critical system components. Track CPU utilisation, memory usage, disk space and I/O performance, network bandwidth and latency, database connection pools, query performance, and application-level metrics like response times and error rates. Cover all environments - production, disaster recovery, and critical third-party services.

Set capacity baselines and thresholds for each monitored resource. Define normal utilisation ranges, warning thresholds (typically 70-80%), and critical thresholds (typically 85-90%). Wire up automated alerting when thresholds are breached, including both sustained utilisation alerts and spike detection.

Build a capacity planning process. Analyse historical utilisation trends to forecast future needs. Factor in planned business growth, seasonal patterns, new feature rollouts, and marketing campaigns that could drive demand spikes. Review forecasts at least quarterly and align capacity planning with your budget cycles.

Set up auto-scaling where possible, especially in cloud environments. Configure auto-scaling groups for compute, database read replicas for database scaling, CDNs for traffic distribution, and queue-based scaling for async processing. Define scaling policies that respond automatically to demand changes.

Run regular capacity reviews with stakeholders. Bring engineering, operations, product, and business teams together to review current capacity, discuss upcoming demand changes, and agree on investments. Document these reviews and the decisions that come out of them.

Validate your capacity through load and stress testing. Run regular performance tests confirming the system handles expected peak loads. Test auto-scaling mechanisms to make sure they actually work. Use results to spot bottlenecks and validate your planning assumptions.

Evidence Your Auditor Will Request

  • System monitoring dashboards showing real-time resource utilization and historical trends
  • Capacity threshold definitions and alerting configurations for critical system components
  • Capacity planning documents including growth forecasts and planned capacity increases
  • Auto-scaling configurations and evidence of scaling events responding to demand changes
  • Load testing and performance test results validating capacity adequacy

Common Mistakes

  • Monitoring covers only a subset of critical resources, leaving blind spots in capacity visibility
  • No proactive capacity planning, with capacity increases only triggered after outages or performance degradation
  • Capacity thresholds are not defined or alerts are not configured, preventing early detection of resource constraints
  • Auto-scaling is not implemented or not tested, leading to manual intervention during demand spikes
  • Load testing is not performed, leaving capacity assumptions unvalidated

Related Controls Across Frameworks

Framework Control ID Relationship
ISO 27001 A.8.6 Equivalent
nist-csf PR.DS-04 Related

Frequently Asked Questions

How far in advance should we plan for capacity?
For physical infrastructure with long procurement lead times, plan 6-12 months ahead. Cloud environments let you work with shorter cycles thanks to on-demand scaling, but you should still forecast 3-6 months out for budgeting and to spot architectural changes needed to support growth. Review your capacity plans quarterly.
Is auto-scaling sufficient for capacity management?
It's a crucial piece, but not the whole picture. You still need monitoring to understand utilisation patterns, capacity planning for budget and architecture decisions, load testing to validate scaling limits, and human oversight to catch trends that need infrastructure changes beyond what auto-scaling can handle. Think of auto-scaling as your tactical response to demand changes, and capacity planning as your strategic approach to growth.
What metrics should we track for capacity management?
The essentials: CPU utilisation, memory usage, disk space and I/O, network throughput and latency, database connections and query performance, application response times, error rates, and queue depths. Layer in business-level metrics too - concurrent users, transaction volumes, data growth rates. The exact mix depends on your architecture, but those cover most bases.

Track SOC 2 compliance in one place

AuditFront helps you manage every SOC 2 control, collect evidence, and stay audit-ready.

Start Free Assessment