SOC 2 A1.1: capacity planning, explained for startups

What usually proves it

An auditor wants records from the period being examined, pulled from the systems that hold them rather than written up afterwards. Dates matter. A record with a date and a named owner carries more weight than a screenshot with neither. For A1.1, the usual records are these.

• Capacity dashboards and alert thresholds
• Autoscaling configuration
• Capacity review notes

What Polara asks about it

The free readiness assessment asks 3 questions that bear on A1.1. A yes becomes a task to show the proof. A no becomes a task to fix the gap, with the steps written out.

• Capacity and uptime monitored? If yes, show it: Datadog infrastructure dashboard, CloudWatch alarms, capacity trend report, or uptime monitoring dashboard. If no, the fix: configure capacity and uptime monitoring with alert thresholds and export the dashboard or alert rules.
• How do you keep production from running out of capacity? If yes, show it: monitoring alert rules with capacity thresholds, a capacity dashboard, a quota increase request, or notes from the most recent capacity review. If no, the fix: set alert thresholds for CPU, memory, storage and connection limits, and review capacity against expected growth every quarter.

It also asks, for context:

• Uptime SLA target (percentage or N/A).

Policies, templates and connected evidence

A policy states the rule, a template gives you the record to keep, and a connected system pulls the proof from the source. An auditor checks that the three agree: the cadence in the policy, the dates in the record and what the system shows.

In the policy pack, the Business Continuity and Disaster Recovery Policy covers A1.1. Availability adds no policy of its own; its criteria are written into that policy.

If you also run ISO 27001, the Annex A control A.8.6, capacity ask for overlapping evidence. One record can serve both when it names what it proves.

Is it in your scope?

Only if you add Availability. Whether the service stays up as promised. Capacity, backups, redundancy and tested recovery. It belongs in scope when customers rely on an uptime commitment in your contracts.

The scoping tool decides it with one question: Add it when your contracts promise uptime, such as a 99.9 percent service level, or customers cannot run their own business while you are down. Recovery objectives, redundancy across zones or data centers, capacity monitoring, backups and recovery testing.

Security is the default and always in scope. Adding Availability in the assessment puts its 3 criteria into the report and the examination, and adds 3 questions to the assessment.

Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.

Availability: the criteria around it

A1.1 is one of 3 criteria in availability, A1.1 to A1.3. Reading a group together shows how its outcomes fit, and one record often serves more than one of them.

• A1.1, this page
• A1.2, recovery infrastructure
• A1.3, recovery testing

Before it: CC9.2, vendor risk. After it: A1.2, recovery infrastructure. All the criteria, Security first, are on the Trust Services Criteria page, grouped by category.