Capacity and Scalability Planning for SOC 2

What this control should accomplish

The team understands current headroom and foreseeable bottlenecks for critical services, then acts before compute, storage, connection, queue, throughput, or provider limits cause customer impact.

How to implement Capacity and Scalability Planning

1. 1

   Map capacity constraints

   For each critical service, identify compute, memory, database, connection, storage, queue, throughput, rate-limit, and third-party constraints with an owner.

   You should end up with: Service capacity and constraint map

2. 2

   Set headroom and warning levels

   Use observed peaks, recovery time, scaling delay, customer commitments, and provider quotas to define when investigation and action should begin.

   You should end up with: Capacity thresholds with rationale

3. 3

   Monitor trends and limits

   Track peaks and sustained use, backlog growth, storage trajectory, throttling, autoscaling behavior, and hard provider limits.

   You should end up with: Capacity dashboard covering leading and hard-limit signals

4. 4

   Review upcoming demand

   Consider customer growth, launches, migrations, retention changes, seasonal load, and dependency plans before material events.

   You should end up with: Dated capacity forecast and assumptions

5. 5

   Validate scaling behavior

   Run safe load or failover exercises to confirm the system scales as expected and identify the component that becomes limiting first.

   You should end up with: Scaling test with measured limits and findings

6. 6

   Track capacity actions

   Assign owners and dates for quota increases, architecture changes, cleanup, tuning, or accepted constraints and verify completion.

   You should end up with: Capacity remediation tracker

Evidence to keep, and what it should prove

Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.

Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.

Which records should you prepare for the audit?

How an auditor may test this control

Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.

• Confirm the intended control outcome

  Determine whether the control is designed to achieve this result: The team understands current headroom and foreseeable bottlenecks for critical services, then acts before compute, storage, connection, queue, throughput, or provider limits cause customer impact.

• Confirm ownership and operating cadence

  Compare the documented owner with the intended role (Operations Lead / Infrastructure Owner), then compare dated records with the stated cadence: Continuous for backups/monitoring; quarterly/annual testing as defined.

• Establish the complete audit record set

  Reconcile full-period threshold and provider-limit alert exports with on-call or engineering records, then reconcile the approved review calendar and designated launch or migration triggers to capacity assessments; account for every missed review, suppressed alert, deferred decision, and action without validation.

• Prepare the as-of-date evidence for a Type 1 engagement

  The current service constraint map, active capacity thresholds and dashboards, latest forecast or scaling review, and open capacity actions showing the process is designed and in use at the review date.

• Prepare period evidence for a Type 2 engagement

  Every scheduled capacity or scaling review due during the review period, every capacity threshold or hard-limit alert generated for covered services, and every material launch, migration, retention, or demand event designated to trigger a capacity assessment, including missed, deferred, and closed occurrences.

• Inspect the approval / review evidence

  Records showing that an accountable person reviewed, approved, challenged, or accepted the work.

  • Inspect scaling reviews

    For each selected record, confirm it demonstrates Known launches, customer growth, migrations, retention changes, and failure scenarios are translated into capacity decisions and owned work.

    • Review date
    • Services and scenarios
    • Demand assumptions
    • Constraints identified
    • Decision
    • Actions and owners

• Inspect the operating / technical evidence

  Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.

  • Inspect Capacity dashboards

    For each selected record, confirm it demonstrates Critical services expose current and historical headroom across the resources and hard limits most likely to constrain customer operations.

    • Service and environment
    • Resource or limit
    • Covered period
    • Current and peak values
    • Warning threshold
    • Data source

  • Inspect utilization reports

    For each selected record, confirm it demonstrates The team reviews sustained and peak demand, growth rate, headroom, and likely exhaustion dates instead of relying only on a live dashboard.

    • Covered services
    • Reporting period
    • Peak and sustained use
    • Growth assumption
    • Remaining headroom
    • Reviewer

  • Inspect backlog/queue monitoring

    For each selected record, confirm it demonstrates The team can detect processing pressure and delay that resource averages may hide, with thresholds tied to timely response.

    • Queue or pipeline
    • Depth and age measures
    • Covered period
    • Threshold
    • Owner or route
    • Observed exceptions

  • Inspect remediation tickets

    For each selected record, confirm it demonstrates Identified capacity risks become accountable changes with due dates, decision history, completion proof, and validation of added headroom.

    • Risk and service
    • Triggering measure
    • Owner
    • Opened and due dates
    • Treatment
    • Completion validation

• Trace the control from design to operation

  Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.

Common implementation and evidence gaps

• Average utilization hides short peaks, queue buildup, or tenant-specific pressure.
• Autoscaling is assumed to remove capacity risk without checking quotas, warm-up time, or downstream limits.
• Storage growth and retention changes are absent from planning until a hard limit is near.
• Forecasts are discussed but do not create owned engineering actions.
• Load tests measure one component while a dependency becomes the real bottleneck.

Before you call this control ready

• Can each critical service name its first likely bottleneck and remaining headroom?
• Do alerts fire early enough to act before a hard limit or customer impact?
• Are cloud and third-party quotas visible alongside ordinary utilization metrics?
• Does the latest forecast include known launches, growth, migrations, and retention changes?
• Can recent capacity risks be traced to an owner, decision, and completed action?

Trust Services Criteria references

These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.

• A1.1

Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.

Related controls to review next