TSC-A1.1 Guidance

TSC-A1.1 sits in the Availability category of the AICPA Trust Services Criteria and is commonly tested in SOC 2 reports where customers expect predictable performance and uptime. The requirement is short, but audits fail on the operational details: unclear scope (“which systems count?”), weak ownership (“who reviews capacity?”), and missing evidence (“we monitor it” without proof of review or actions).

For a CCO or GRC lead, the fastest path is to treat capacity management as a control loop: define capacity targets aligned to service commitments, monitor a small set of leading indicators, review trends on a fixed cadence, and document what decisions were made (and why). Auditors typically look for two things: (1) monitoring exists and is appropriate for the service, and (2) the organization evaluates capacity and takes action before customers feel pain.

This page gives requirement-level implementation guidance you can hand to engineering and operations, plus the evidence package you need to pass a SOC 2 examination against TSC-A1.1 ¹.

Regulatory text

Requirement (excerpt): “The entity maintains, monitors, and evaluates current processing capacity” ¹.

What the operator must do:
You must be able to show that the organization (a) knows the current capacity of in-scope systems, (b) monitors capacity-related signals over time, and (c) evaluates whether capacity remains sufficient given demand, changes, and risk. “Evaluates” is the keyword auditors push on: you need a repeatable review process that produces documented conclusions and, when needed, capacity changes or risk acceptance ¹.

Plain-English interpretation (what it really means)

TSC-A1.1 requires active capacity management for the systems that deliver your SOC 2 in-scope services. That includes:

• Maintain: You have defined baselines and you keep the environment in a known-good state (e.g., autoscaling policies, quotas, limits, runbooks).
• Monitor: You collect and alert on capacity indicators that predict customer-impacting degradation (not only “is it down?”).
• Evaluate: You review trends and forecasts and decide whether to add capacity, tune systems, or accept risk. Then you document the decision and follow through.

A simple litmus test: if an auditor asks, “How do you know you’ll handle next month’s load increase or a marketing launch?” you should be able to answer with artifacts, not verbal assurances ¹.

Who it applies to (entity and operational context)

Applies to: organizations seeking or maintaining a SOC 2 report that includes Availability criteria ¹.

Operational scope typically includes:

• Production infrastructure that processes customer transactions or workloads (compute, databases, storage, queues, network).
• Shared services that can become bottlenecks (identity, logging pipeline, CI/CD runners if they affect release throughput, API gateways).
• Third-party dependencies where you have capacity constraints or quotas (e.g., managed databases, messaging services, SaaS rate limits). You can’t control their internals, but you can monitor your consumption and manage limits through vendor management and architecture.

Teams involved: SRE/Operations, Infrastructure, Application owners, Product (demand signals), Security/Compliance (control design and evidence), and incident management.

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

1) Define “processing capacity” for the in-scope service

Create a one-page capacity definition per in-scope product/service:

• Critical user journeys (what must stay responsive).
• Primary throughput units (requests/sec, jobs/min, messages/sec).
• Primary constraints (CPU, memory, IOPS, connections, queue depth, rate limits).
• Key dependencies and their capacity constraints (internal and third party). This becomes your capacity “system boundary” for audit testing.

2) Set capacity objectives and thresholds

Document service-specific objectives that translate into capacity signals, such as:

• Saturation thresholds (e.g., sustained CPU or DB connections above a defined limit).
• Queue/lag thresholds (backlog indicates processing is falling behind).
• Rate-limit consumption thresholds for third-party APIs. Tie each threshold to an action: page, ticket, or review.

Practical tip: keep the list short. Auditors prefer a small, owned set of indicators that are reviewed and acted on versus dozens of noisy charts with no decisions.

3) Implement monitoring and alerting that supports proactive action

Minimum monitoring set (adapt to your stack):

• Compute saturation (CPU, memory, container throttling)
• Storage performance (IOPS, latency)
• Database constraints (connections, slow queries, replication lag)
• Queue/stream metrics (depth, age, consumer lag)
• Application throughput and latency (p95/p99 if you track it)
• Error rates that correlate with overload (timeouts, 429s, 5xx spikes)

Route alerts to an on-call function with runbooks that include “capacity triage” steps.

4) Establish a recurring capacity review with documented outputs

Create a capacity review cadence and stick to it. A workable structure:

• Inputs: last period trends, notable releases, incidents, forecasted demand events, third-party quota status.
• Outputs: “capacity is sufficient” statement, identified risks, and a short action list.
• Actions: scaling changes, performance work, cost-risk tradeoffs, third-party contract/quota changes, or formal risk acceptance with an expiry date.

Auditors routinely ask for evidence that reviews happened and produced decisions ¹.

5) Add forecasting and change-triggered evaluations

Beyond the recurring meeting, define triggers that require an out-of-cycle evaluation:

• Major launches or customer onboardings
• Architecture changes (database migration, caching changes)
• New third-party dependency or quota change
• Significant incident tied to overload/latency Your goal: demonstrate you evaluate capacity during change, not only after outages.

6) Keep an audit trail end-to-end

For each review period, be able to connect:

• Metrics and alerts → review notes → decisions → implemented changes → post-change validation. This is where many teams fail TSC-A1.1: monitoring exists, but the organization can’t show evaluation and follow-through ¹.

Required evidence and artifacts to retain

Use this as your SOC 2 evidence checklist for the tsc-a1.1 guidance requirement:

Core documentation

• Capacity Management Policy/Standard (scope, roles, cadence, thresholds, escalation path).
• Capacity review procedure (agenda template, required inputs/outputs).
• System/service inventory with “in-scope” designation for Availability.

Operational records (auditors love these)

• Monitoring dashboards and alert definitions (screenshots or exports with timestamps).
• On-call alerts and incident tickets tied to capacity signals (including resolution notes).
• Capacity review meeting minutes/slides/notes with attendees and decisions.
• Forecast artifacts (demand forecast doc, launch readiness checklist, load test results where applicable).
• Change records for capacity adjustments (autoscaling config changes, DB scaling, quota increases) with approvals.
• Post-change validation results (before/after graphs, performance test summary).

Testing/assurance artifacts

• Internal control testing results or management self-assessments showing the review cadence occurred and actions closed ¹.

Common exam/audit questions and hangups

Expect these questions in walkthroughs and evidence requests:

1. What systems are in scope for Availability, and who owns capacity for each?
2. What are your capacity thresholds and how were they chosen?
3. Show the last two capacity reviews. What decisions were made?
4. Where do capacity-related alerts go, and what happens after an alert fires?
5. How do you evaluate capacity impact for major releases or demand spikes?
6. How do you manage third-party constraints (quotas, rate limits, shared tenancy risk)?

Hangups that cause control exceptions:

• Reviews happen verbally but aren’t documented.
• Dashboards exist but don’t map to capacity risks (or no one can explain them).
• Tickets show firefighting after incidents, with no proactive evaluation process ¹.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails in SOC 2 testing	How to fix it
“We have monitoring” as the whole control	Monitoring alone doesn’t prove evaluation	Add a recurring capacity review and retain notes/outputs 1.
No defined scope	Auditors can’t tell what capacity you manage	Publish an in-scope service/system list with owners.
No thresholds or unclear triggers	Alerts are noisy or subjective	Define a small set of thresholds and action paths per service.
Actions not tracked to completion	Decisions don’t turn into changes	Require tickets for actions with due dates; review closure in the next meeting.
Third-party limits ignored	Quotas and rate limits can cause outages	Monitor quota consumption; document vendor escalation paths and contract/quota changes.

Enforcement context and risk implications

SOC 2 is an audit framework, not a regulatory enforcement regime. Your risk is primarily commercial and contractual: capacity failures drive SLA breaches, customer churn, and SOC 2 report findings that slow sales cycles. A TSC-A1.1 exception often shows up as a maturity gap (“monitoring exists but no documented evaluation”), which customers interpret as operational risk ¹.

Practical 30/60/90-day execution plan

First 30 days: establish scope, ownership, and minimum viable control

• Confirm which products/services are in SOC 2 scope for Availability ¹.
• Assign a named owner for capacity per service (engineering manager or SRE lead).
• Publish a short Capacity Management policy/standard and a capacity review template.
• Identify the top capacity indicators per service and confirm they are collected in your monitoring tool.
• Start capturing evidence immediately: screenshots/exports, meeting invites, and notes.

Days 31–60: make evaluation real and repeatable

• Run at least one formal capacity review per in-scope service; produce decisions and action tickets.
• Create out-of-cycle triggers (launches, major changes, incidents) and embed them in change management checklists.
• Build an evidence binder structure (by service, by month) so audit requests are one folder, not a scramble.
• Add a lightweight internal test: verify the review occurred, attendees were appropriate, and actions closed ¹.

Days 61–90: harden, test, and operationalize across teams

• Tune thresholds to reduce noise and focus on leading indicators.
• Validate response: run a capacity tabletop or controlled load event and document outcomes.
• Extend to third-party constraints: quotas, API limits, and key vendors’ status/health signals.
• Prepare for auditor walkthrough: pick one service, trace metrics → review → ticket → implemented change → post-change graph ¹.

Where Daydream fits (practical, non-disruptive)

If your main pain is evidence assembly and control traceability across tools (monitoring, tickets, change logs), Daydream can act as the system of record for TSC-A1.1 by mapping the control to required artifacts, tracking review cadence, and packaging time-bound evidence for your SOC 2 auditor without rebuilding your engineering workflow.

Frequently Asked Questions

What counts as “processing capacity” under TSC-A1.1?

It’s the ability of your in-scope systems to handle workload demand without unacceptable degradation. Define it per service in terms of the constraints that actually bottleneck delivery (compute, database, queues, rate limits) ¹.

Do we need formal capacity planning, or is monitoring enough?

Monitoring is necessary but usually not sufficient for SOC 2 testing. You need documented evaluation, typically a recurring capacity review with recorded conclusions and actions ¹.

How do we handle capacity risk when we rely on third parties (cloud/SaaS)?

You can’t control a third party’s internals, but you can monitor your consumption, manage quotas/limits, and document escalation and contractual steps. Auditors look for how you manage the dependency within your boundary of control ¹.

What evidence is strongest for auditors?

Time-stamped capacity review notes plus linked tickets/changes and before-and-after metrics. Dashboards alone rarely show evaluation or governance ¹.

Who should own this control—SRE, engineering, or compliance?

Engineering/SRE should own operation (metrics, scaling, reviews). Compliance should own control definition, evidence standards, and periodic testing so the process stays auditable ¹.

We autoscale. Does that satisfy TSC-A1.1 automatically?

Autoscaling is a strong “maintain” mechanism, but auditors still expect monitoring and documented evaluation to confirm it works for real demand patterns and dependencies like databases and third-party rate limits ¹.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. AICPA Trust Services Criteria 2017