What SOC 2 A1.1 capacity management asks for
A1.1 requires the organization to maintain, monitor and evaluate its current processing capacity and use of system components, so it can manage demand and add capacity when needed. It applies only when the availability category is in scope of your SOC 2, which usually happens because a customer contract promises uptime or a service level and the buyer asks for independent evidence that you can keep the service running under load. If availability is out of scope, A1.1 is not tested, although the same discipline still protects you commercially. The risk A1.1 addresses is slow, unnoticed saturation. Disk fills, connection pools exhaust, queues back up and database storage grows until a normal peak becomes an outage, and nobody acted because no one was looking at the right number. The difficulty is that usage data sits in many places: cloud account consoles, virtual machines, container clusters, databases, message brokers and application logs. CC7 covers how you detect and respond to anomalies and security events. A1.1 is different in purpose: it asks whether you can see the trend in capacity and act on it before the system runs out. The criterion's points of focus describe three activities: measuring current usage, forecasting future capacity and making changes based on those forecasts. They are design aids, not a checklist you must complete item by item. In practice, confirm with your auditor which components are in the availability boundary, which metrics and thresholds you will use, who reviews the forecast and how a decision to add capacity is recorded. The AICPA 2017 Trust Services Criteria sets out the full wording, and the evidence you build in the next sections should match it.
Which systems and teams A1.1 covers in a SOC 2
A1.1 applies only to the parts of the system the organization describes and includes in the examination. The cards below cover the components that carry availability commitments, the scoping choices that change how much capacity work is in scope, and the teams that own capacity decisions.
Production compute and network infrastructure
Virtual machines, container clusters, load balancers, and network links that serve customers form the core of what A1.1 measures. Record each pool with its current utilization and its headroom against demand. Confirm which clusters, regions or accounts appear in the system description, because capacity controls only need to cover components the description names. Ask whether shared platform capacity is counted separately for each customer-facing service.
Data stores and storage volumes
Databases, object storage, queues and caches often hit limits before compute does. Disk growth, connection pool exhaustion and replication lag all change how much capacity remains. List each store that holds customer data or supports the service, then define the usage metric and the threshold that triggers a review. Auditors usually ask how those thresholds were set and who reviewed them.
Third-party and subservice providers
Hosting providers, managed database services and content delivery networks may carry much of your capacity risk. Decide whether each provider is a subservice organization that the report carves out, or is included and tested directly. Collect the provider's own SOC report or capacity commitments, and confirm how your team monitors usage that the provider controls. Gaps here are a common source of exceptions in A1.1 testing.
Environments that count as production
A1.1 applies to the production environment described in the report, not automatically to staging, test or sandbox systems. Define which environments serve customers and which feed production, such as build pipelines or data replication targets. Confirm that the capacity monitoring applies to every environment inside the boundary. Document any environment you exclude and the reason, so the auditor can trace the scope decision.
Self-hosted deployments at customer sites
When the software runs in a customer's own cloud account, data center or air-gapped network, the question is whether those deployments are part of your described system. If you operate them, their capacity signals may fall within A1.1. If the customer operates them, their capacity may be a complementary user entity control instead. Agree on this boundary in writing before fieldwork, because it determines who collects the usage data and who answers for forecasts.
Owners of capacity decisions
Capacity decisions are split among operations, engineering leadership, finance and sometimes the customer success team that handles large commitments. Name the owner of the forecast, the person who approves purchases or scale-up changes, and the reviewer who checks that thresholds were followed. Auditors look for evidence that these roles exist and acted, such as review minutes or change tickets tied to forecasts.
How an assessor tests capacity management
This table compares how a service auditor approaches A1.1 at a point in time (Type 1 design review) and across an observation period (Type 2 operating effectiveness). Read each row as a test step, the evidence it produces, and where engagements usually stall. The main takeaway is that a capacity control only passes when thresholds, forecasts and responses are visibly reviewed and acted on over time, not just configured.
| Test area | Type 1 design view | Type 2 operating period |
|---|---|---|
| Monitoring configuration | Auditor inspects whether usage metrics for servers, databases, storage and key software are defined and collected, and whether alert thresholds exist. | Auditor confirms the same monitoring ran continuously through the period, including any changes to metrics, thresholds or data sources. |
| Capacity reports and forecasts | Auditor checks that a capacity report or forecast template exists and describes how demand is projected against current use. | Auditor samples reports issued across the period and checks that forecasts were refreshed on a stated cadence. |
| Alerts and actions taken | Auditor walks through how an alert would route to an owner and what triggers escalation or provisioning. | Auditor samples alerts that fired and traces each to a ticket, change or documented decision showing the response. |
| Capacity review meetings | Auditor confirms management has a defined forum, attendees and agenda for reviewing capacity. | Auditor reads minutes or records from sampled meetings and checks that action items carried into later periods were closed. |
| Threshold reviews | Auditor checks that thresholds are documented with a rationale tied to system demand and commitments. | Auditor confirms thresholds were reviewed at the stated interval and changed only through a recorded approval. |
| Evidence requested | Monitoring and alerting configuration, capacity policy, forecast method, and a sample of current reports. | Dated exports of usage data, alert history, forecast revisions, meeting minutes, and tickets for sampled alerts. |
| Common finding: thresholds never reviewed | Thresholds exist but carry no owner, date or rationale, so the auditor cannot judge whether they fit current demand. | Thresholds remain at launch values for the whole period with no review record, which is often reported as an exception. |
| Common finding: forecasts without follow-up | Forecast method is described but no link exists between projected growth and planned capacity changes. | Forecasts predict shortfalls that appear in later reports with no purchase, scaling change or accepted risk recorded. |
| Common finding: alerts with no recorded response | Alert routing is defined but no escalation path names who acts or how quickly. | Alerts fire during the period but sampled items have no acknowledgment, ticket or closure note. |
Choosing a capacity monitoring approach
Teams that already run a metrics stack can usually meet A1.1 by extending it rather than replacing it. Prometheus (Apache-2.0) collects metrics from instrumented jobs through a pull model over HTTP and stores them as time series identified by metric name and labels on its autonomous local storage. Grafana Alerting (AGPL-3.0-only) builds alert rules from queries across data sources and can alert on metrics and logs together, which lets the team act on capacity signals from one view. The work is mostly in deciding what the existing stack must cover and writing it down.
- Measure saturation, not just averages: track CPU, memory, disk, network, connection pools and queue depth for each system component in scope.
- Keep the data in one place: confirm that retention in local storage covers the forecasting window the team documents.
- Route alerts to a named owner: define who receives capacity alerts and who decides whether to add capacity.
- Retain the forecast review: store dashboards, alert history and the minutes of periodic capacity reviews as evidence.
- Confirm scope with the auditor early: check whether the stack's own components, such as the monitoring server, are inside the system description.
Check that every in-scope component is actually scraped, because an unmonitored service produces no evidence.
A team on one managed cloud account often starts with the provider's native monitoring and logging services. The provider's own metrics, alarms and usage reports can show current use of compute, storage and managed databases without a separate collection layer. The trade-off is that the evidence sits inside the provider's console, so the team must export, snapshot or otherwise preserve it in a form the auditor can sample across the examination period. Whether a given native service meets a given need should be confirmed against the provider's documentation.
- Measure the managed services in use: include autoscaling groups, database storage and quotas, and load balancer capacity.
- Set threshold alarms with notifications: record which thresholds were set, when they changed and who approved changes.
- Export periodic usage reports: schedule exports so usage history is preserved beyond the console's default retention.
- Review and forecast on a cadence: document a recurring capacity review that compares usage trends with planned growth.
- Use the provider's SOC reports carefully: the provider's report covers its own infrastructure, so confirm which capacity controls remain the team's responsibility.
Confirm the retention period of each native metric and log store against the examination period you need to evidence.
Teams deploying self-hosted platforms into a customer's cloud, data center or air-gapped network face a different question: the customer usually owns the infrastructure, so capacity data may need to stay inside that environment and be reviewed by both parties. The service organization must decide whether it has access to the customer's metrics, whether it monitors remotely, and how capacity responsibilities are split in the contract. Those decisions belong in the system description and in the complementary user entity controls.
- Define the responsibility split in writing: state which capacity measurements the service organization performs and which the customer must perform.
- Deploy the collection stack with the platform: include Prometheus and Grafana in the delivery so each environment produces its own usage history.
- Keep data in the customer's boundary: where remote access is limited, agree on exports or periodic reports instead.
- Forecast per deployment: record growth assumptions for each customer and the date each was last reviewed.
- Document customer-side actions: track capacity requests and the customer's responses as evidence of follow-through.
Illustrative example: a customer asks for more storage after an alert; the ticket, the alert and the approved change together show the criterion operating.
How to implement A1.1 step by step
This sequence turns A1.1 from a statement of intent into a working cycle: measured capacity, alerts that fire before limits are reached, forecasts that drive decisions, and a record that an auditor can sample across the operating period.
Define the capacity metrics inventory
List every in-scope component that can run out of capacity: compute, storage, database connections, network throughput, message queues, and the software licenses or API quotas the service depends on. For each one, name the metric that shows current use, the limit that matters, and the owner who acts on it. The output is a metrics inventory approved by the platform owner and attached to the system description. The step is done when every in-scope component has a named metric, a stated limit and an owner.
Instrument and collect the metrics
Configure the monitoring stack to collect the inventoried metrics from each system. Prometheus (Apache-2.0) can scrape metrics from instrumented jobs over HTTP and store them as time series on local storage, and Grafana (AGPL-3.0-only) can query those series for dashboards. Confirm with your own environment whether every component exposes the metric directly or needs an exporter. The output is a set of dashboards and a configuration export kept under change control. The step is done when each inventoried metric returns data for the full in-scope period.
Set thresholds and alert rules
Agree warning and critical thresholds for each metric, set below the hard limit so there is time to add capacity. Build alert rules in Grafana Alerting from queries across the relevant data sources, and route them to the on-call owner. Record the reasoning for each threshold. The output is an exported alert rule set and a threshold register with the owner's sign-off. The step is done when a test alert fires and reaches the named owner.
Build the forecasting routine
Using stored history, project demand for each component over a period the organization chooses, and compare the projection with the limits in the inventory. Document the method so a reviewer can repeat it. The forecast should show when each limit is expected to be reached if current trends continue. The output is a forecast workbook or dashboard snapshot, dated and assigned to an owner. The step is done when every in-scope component has a current forecast.
Hold the recurring capacity review
Schedule a review at a cadence the organization sets and states in its policy. Attendees look at the forecasts, alert history and any threshold breaches since the last review, then decide whether capacity changes are needed. The output is written minutes listing attendees, data reviewed, decisions and open actions. The step is done when minutes exist for each scheduled review, including reviews where no action was needed.
Record decisions and link them to change tickets
For each decision to add, remove or reconfigure capacity, open a change ticket that cites the forecast or alert that triggered it, and follow the change management process for approval and deployment. Where the decision is to accept the current capacity, record that too with the reason. The output is a set of change tickets traceable to a forecast, alert or review. The step is done when a sampled decision can be followed from the trigger through approval to the deployed change.
Test that the cycle runs in the operating period
Confirm that the cycle operated throughout the period the auditor will examine, not only at the start. Pull a sample of metric history, alert records, review minutes and change tickets, and check that each one is complete and dated. Look for gaps, such as months without a review or alerts that fired with no recorded response, and fix them before fieldwork. The output is an internal test log showing the samples checked and any exceptions with remediation. The step is done when the log shows no unexplained gaps.
How Prometheus and Grafana produce capacity evidence
Prometheus and Grafana can generate the usage history and alert records that an A1.1 review draws on, but they do not decide what capacity the organization needs. Prometheus collects metrics from instrumented jobs through a pull model over HTTP, meaning the server scrapes an endpoint that each job exposes. It stores each measurement as a time series identified by a metric name and labels, on its own local storage, and the team queries that history with PromQL. For capacity work, the useful series usually cover CPU, memory, disk, network throughput, queue depth, database connections and application request rates for the production components in scope. The engineer who configures the scrape targets and retention period should record which systems are covered, so an assessor can see that the population of components matches the system description.
Grafana Alerting sits on top of those data sources. Teams build alert rules from queries and expressions, can combine metrics and logs in one rule set, and manage and act on alerts from a single view. An alert rule that fires when disk use on a database host stays above an agreed threshold for a set period is a record of the organization's own trigger. The rule definition, its threshold, the notification routing and the history of firings are the artifacts to preserve. The organization must set the thresholds, forecast growth from the usage data, decide when to add capacity and document why a threshold was changed. Confirm with your own environment whether the retention of Prometheus data and Grafana alert history meets the observation period your auditor expects, since the tools do not set that period for you.
Before you modify or distribute either tool, confirm your license obligations. Prometheus is licensed under Apache-2.0, while Grafana is licensed under AGPL-3.0-only, and the AGPL carries network-use obligations that a legal or open-source review should assess for any changes you make to Grafana itself. Using the stock releases in your own environment and keeping configuration in version-controlled files is generally a simpler position, but the decision belongs to your counsel. Read the AICPA 2017 Trust Services Criteria with revised points of focus to map each usage and forecasting step to A1.1 before you present the tooling as evidence.
Evidence that passes A1.1 and how to keep it current
A1.1 is tested over a period, so an assessor needs proof that capacity was watched, forecast and acted on throughout the observation window, not only a dashboard shown on the day of fieldwork. The six artifacts below connect measurement, alerting, forecasting, governance and change, and each one needs a recurring routine so it stays complete between audits.
Capacity metrics with retained history
Dashboards show current utilization, but the auditor samples past periods, so the underlying time series must survive that long. Confirm which system components are measured (compute, storage, database connections, queue depth, network throughput, and the software limits that cap users or transactions), that each metric has a named owner, and that retention covers the full observation period. Export a dated snapshot of key panels at a fixed interval so the record does not depend on a single live tool. Ask the auditor which granularity they expect.
Alert rule definitions and alert history
Alert rules show what the organization decided counts as a capacity risk, and alert history shows that the rules fired and were handled. Keep rule definitions in version control so each threshold change has an author, a date and a reason. Retain the history of fired and resolved alerts, along with the tickets that record who responded. Check that notification routing still reaches a staffed channel, because an alert that goes to an unmonitored mailbox will not show as a control operating.
Capacity forecast documents with assumptions
A forecast ties observed usage to expected demand, such as customer growth, planned launches or seasonal peaks. The document should state each assumption, the data it came from and the date it was prepared, and it should show the capacity that will be added and when. Assessors test whether forecasts were made, whether they were based on evidence, and whether later actions followed them. Revise the forecast on a set cycle and when a major customer or product change occurs, and keep each version rather than overwriting it.
Capacity review meeting minutes
Minutes prove that someone with authority reviewed capacity on a schedule and decided what to do. Record the attendees, the metrics reviewed, the forecast considered, the decisions taken and the owners and due dates for follow-up. Keep a recurring calendar entry that is visibly completed, and note when a review was skipped and why. Minutes that repeat the same line every period without showing decisions are weak evidence, so write down any capacity risk the group chose to accept.
Change records for capacity added
This is the link between forecast and action. For each capacity increase, keep the change ticket showing the trigger (an alert, a forecast figure or a review decision), the approval, the implementation and the post-change check that the metric recovered. Infrastructure as code commits can serve as the implementation record if they reference the ticket. Sample a capacity change from each period and confirm that the trigger, approval and result can be traced in both directions.
Scheduled evidence collection calendar
Most A1.1 gaps happen between audits because exports are not taken and reviews lapse. Create a single calendar that lists each artifact, its owner, its frequency and where it is stored, and assign a reviewer to confirm completion. Store exports in an access-controlled location with dates in the file names. Before fieldwork, run a dry run that samples one month of each artifact to confirm the set is complete. Ask your auditor which evidence they will request so the calendar matches the sample they will draw.
What meeting A1.1 costs in money and effort
This table breaks down the cost components of meeting A1.1 by who is paid, whether the cost is one-time or recurring, and what drives it up or down. Use it to structure a quote request, since no price or duration is supplied for this criterion and each figure must come from the written scope.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Monitoring tooling or licenses | Commercial vendor or open-source platform operator; self-hosted open source removes license fees but not hosting | Licenses recur; self-hosted tools carry one-time setup | Number of hosts, services and data sources; ask whether the quote covers retention and user seats |
| Engineering time to instrument and tune | Internal engineers or an implementation partner building exporters, dashboards and alert rules | Mostly one-time, with recurring tuning | Number of components and environments; the range of workloads that need usage baselines |
| Alert design and noise reduction | Internal operations staff who respond to alerts | Recurring | Alert noise drives staff time; thresholds set too low create fatigue and missed capacity warnings |
| Evidence upkeep | Internal control owners who export reports, retain dashboards and record threshold reviews | Recurring | Frequency of capacity reviews and how much evidence is collected manually versus automatically |
| External review of the forecasting approach | Independent consultant or advisor, if the organization chooses to buy review | One-time per review, optional recurring | Complexity of the forecast model and whether reviews are scheduled or ad hoc; ask for the review method in writing |
| Auditor sampling effort | Independent CPA firm, billed under its engagement letter | Recurring with each examination period | Number of capacity events and samples the auditor selects; clean, well-indexed records reduce testing time |
Which open-source tools support A1.1 evidence
Which open-source tool collects capacity usage metrics for A1.1?
Prometheus is the open-source tool most often used to collect the usage metrics that A1.1 evidence rests on. It is licensed under Apache-2.0 and collects metrics from instrumented jobs through a pull model over HTTP. It stores each measurement as a time series identified by a metric name and labels, on autonomous local storage, and you query it with PromQL. For A1.1, the useful outputs are CPU, memory, disk, network and application queue metrics over time for the components in scope. Those series show current use and trends, which is the raw material for forecasting. Prometheus does not decide what capacity is adequate, set thresholds your organization has approved, or record the decisions made from the data. Your team still needs to define those.
Which open-source tool handles capacity alerting and dashboards?
Grafana Alerting is the component that turns capacity queries into alerts and dashboards. It is licensed under AGPL-3.0-only. Alert rules are built from queries and expressions across multiple data sources, so you can alert on metrics and logs together from a single view. Teams create, manage and act on alerts there, which produces a record of which thresholds fired and who responded. Confirm the licensing position with your legal team before you modify and redistribute Grafana, because AGPL-3.0 carries network-use obligations. Grafana does not forecast capacity on its own, and it does not provide a ticketing trail for the approved capacity decisions unless you connect it to your change or service management process.
How does Prometheus produce evidence that an auditor can test?
Prometheus produces evidence in the form of retained time-series data and the queries that read it. An auditor testing A1.1 usually asks for usage history across a period, so you should confirm the retention period you configure is long enough to cover the audit window. Keep the exact PromQL queries and dashboard definitions under version control so the same measurement can be reproduced. Also export or snapshot reports at set intervals, such as monthly capacity reviews, and keep them with the meeting notes. Local storage is autonomous, so confirm how you back up that data and what happens if a node fails, because a gap in history can become an exception in the examination.
How does Grafana alerting show that capacity was managed?
Grafana produces evidence in its alert history, rule definitions and dashboards. Export the alert rule configuration, keep records of notifications sent, and retain the dashboards used in capacity reviews. The strongest evidence links an alert to a documented response: a ticket, a change request or a capacity decision. Grafana can notify teams, but the link between alert and action must be recorded in your own process. Ask your auditor which artifacts they will accept, because the format and retention they expect should be agreed before the observation period begins.
Can Prometheus and Grafana alone satisfy A1.1?
No. Prometheus and Grafana cover the measurement and alerting parts of A1.1, which are the monitoring of current use and the ability to act on it. A1.1 also expects forecasting and changes made on the basis of forecasts. Those require a documented capacity plan, defined thresholds, named owners and a record of procurement or scaling decisions. Your organization owns those controls. An implementation partner can help configure the tools, define the metrics and assemble the evidence, but only the independent CPA firm issues the report and its opinion.
What does it cost to run Prometheus and Grafana for capacity evidence?
The software licenses are free under the listed open-source licenses, so cost comes from the infrastructure, the people and the support around them. Expect recurring costs for the servers or cloud resources that host the stack, storage for retained metrics, and staff time to maintain dashboards, alert rules and upgrades. One-time costs include designing metrics, defining thresholds and writing the capacity procedure. Costs rise with the number of systems monitored, the metric cardinality and the retention period. To compare quotes, ask for the scope of components covered, the retention design, backup arrangements and who handles upgrades and evidence exports. DeployOpen does not publish prices; a quote follows from a written scope.
Who sets up Prometheus and Grafana for an A1.1 program?
Your organization decides what capacity means for its services and owns the control. Your engineering team can install and operate Prometheus and Grafana in your own infrastructure. If you need outside help, an implementation partner such as DeployOpen can plan, deploy, integrate, document and support self-hosted deployments in your cloud accounts, data center or air-gapped network, and prepare the evidence the auditor will request. Engagements are typically fixed-scope, with scope and deliverables agreed in writing before work starts. The auditor tests the controls independently and issues the report.
Who owns capacity management and who helps
Your organization owns A1.1. Capacity management is a control you operate, so the people accountable for the platform decide what capacity is needed, what thresholds matter and when infrastructure changes. Those decisions have to be made by staff who understand the business demand the system serves, not delegated to an outside party that leaves afterward.
- Capacity decisions: Named owners set acceptable utilization levels, decide when to add or reduce capacity and approve those changes.
- Forecasts: Your team reviews usage trends and projected growth tied to customer, product and seasonal demand.
- Review cadence: Capacity reviews happen on a schedule you define, with minutes or tickets that show what was discussed and decided.
- Follow-through: Changes prompted by forecasts are tracked from request to completion.
- Policy and scope: Management defines which components fall within capacity monitoring, consistent with the system description.
Before the examination, confirm that each decision has a named owner and that the review records exist for the whole observation period, not only the months just before the audit.
An implementation partner can build the technical machinery that produces capacity evidence. DeployOpen, for example, configures and documents self-hosted monitoring inside your own cloud accounts or data centers. The partner prepares systems and evidence; it does not own the control, make capacity decisions for you or issue any report.
- Collection: Configuring exporters and scrape targets so usage data for compute, storage, network and key software components is gathered consistently.
- Dashboards and alert rules: Building views and thresholds that your owners have approved, with alerts routed to people who act on them.
- Evidence exports: Setting up scheduled reports or retained snapshots that show usage over time for the auditor to sample.
- Documentation: Writing runbooks that explain what each dashboard measures and how to respond to an alert.
- Handover: Training the staff who will run the platform after the engagement ends.
Confirm in the written scope which of these items are included, who approves threshold values, and where the retained data will be stored and for how long.
The independent CPA firm performs the SOC 2 examination and issues the report. Under the attestation framework, the service auditor tests whether the controls described in the system description were designed appropriately and, for a Type 2 report, operated effectively over the period. The auditor must remain independent of the organization, so it cannot design the controls it tests.
- Testing the record: The auditor samples capacity reviews, alert history and forecast records to confirm the control operated.
- Independence: Helping select thresholds or writing the control is generally treated as a conflict, so keep those steps with management and the partner.
- Inquiry and observation: The auditor asks owners how they forecast and may observe a review meeting.
- Exceptions: Missed reviews or unaddressed alerts appear as exceptions in the report, which is why the record must be complete.
- Engagement terms: Ask the audit firm early which evidence formats it accepts and how it handles tools that you host.
Before engaging a CPA firm, confirm with it in writing what it can and cannot help prepare, so that the division of work is clear from the start.
Most organizations outsource the build and the evidence plumbing, and keep the decisions and the review. This split reduces engagement time without moving accountability out of the business. Outsourcing also works best when the outside party is clearly limited to preparation.
- Usually outsourced: Initial monitoring deployment, dashboard and alert configuration, export automation and runbook drafting.
- Usually kept in-house: Capacity thresholds, forecast ownership, approval of infrastructure changes and attendance at reviews.
- Shared: Tuning alerts after the first months of data, which needs both operator knowledge and management sign-off.
- Cost drivers: The number of components in scope, the number of environments and how much custom integration is needed. Ask for a fixed-scope quote that lists each of these.
- Recurring work: Ongoing support or upgrades of the monitoring stack are typically separate from the one-time build.
When you request a quote, ask the partner to state which deliverables transfer ownership to your team and which remain its responsibility.
Where capacity management usually falls short
Most capacity programs exist on paper but fail at the handoffs between measurement, decision and change. The gaps below share one root cause: the organization can see its usage but cannot show that it acted on what it saw. Each card names one gap and the check that shows whether it is closed.
Thresholds set once and never reviewed
Alert thresholds for CPU, memory, storage and connection counts are often chosen at launch and left alone while workloads grow. An auditor testing A1.1 will ask how the limits were chosen and when they were last reviewed against actual demand. Check that each threshold has an owner, a documented basis and a review date tied to the capacity forecast. Illustrative example: a disk alert set at a level that was reasonable two years ago may now fire too late to allow a procurement cycle.
Alerts without recorded action
A capacity alert that fires and is silently acknowledged shows monitoring but not management. A1.1 expects the organization to act on current usage, so the evidence should link each alert to a ticket, a decision or a documented reason for no action. Check the alert history for a sample of firings and confirm each one traces to a record. Ask who receives alerts after hours and whether that routing is tested.
Forecasts that do not reach change decisions
Teams often produce a growth estimate that sits in a slide deck and never enters the change or budget process. The criterion points toward forecasting capacity and making changes based on the forecast, so the link between the two must be visible. Check that the forecast has a date, names the assumptions behind it, and appears in the minutes or tickets where capacity additions are approved.
Monitoring that covers production but not dependencies
Dashboards frequently cover production application servers while ignoring the databases, message queues, DNS, identity services and third-party APIs those servers depend on. A constraint in a dependency can look like an application problem and delay the right fix. Inventory the components that support each in-scope service, confirm each one emits usage data, and check that the monitoring scope matches the system description used in the SOC 2 report.
Usage data that cannot be trusted
Metrics collected by an exporter that stopped reporting, or a scrape target that silently dropped out, can make a system look idle when it is saturated. Auditors may ask how the organization knows its monitoring itself is working. Check that the metrics pipeline has its own health alerts, that scrape failures are visible, and that retention is long enough to show usage trends across the audit period.
How much effort does A1.1 take and what does it need from us?
What drives the effort and cost of meeting A1.1 capacity management?
The effort depends mostly on how many systems are in scope, how much capacity data already exists, and how many people must review it. A1.1 asks for current usage to be measured, capacity to be forecast and changes to be made from those forecasts, so the work splits into building measurement, building a forecasting routine and keeping records of the decisions taken. Costs come from three places: the internal hours spent defining thresholds and reviewing trends, the tooling (open-source or licensed) and the time an outside firm spends preparing the evidence. No fixed figure applies to every environment, so ask any provider to break a quote into these parts and to state which items are one-time and which recur each month or each audit period.
How long does it take to get ready for a SOC 2 Type 1 on A1.1?
Readiness time depends on how mature your monitoring already is. A team that already collects metrics for its production systems and reviews them regularly needs to document the process and show it running. A team with no capacity measurement needs to choose metrics, set up collection, define review thresholds and run the routine long enough to show it works before an auditor looks at the design. A Type 1 tests design as of a date, so the controls must exist and be documented by then, but they do not need a long operating history. Confirm the exact timeline with your CPA firm and your implementation partner, because the auditor sets the evidence expectations and the window for the examination.
What does the work need from engineering and management?
Engineering owns the technical side: instrumenting systems, selecting the metrics that describe current use, building dashboards and alert rules, and keeping the data retained long enough to support forecasts. Management owns the decisions: approving capacity thresholds, reviewing forecasts at a set cadence, and authorizing capacity changes or accepting the risk of not making them. Both groups should expect to produce records, such as review notes, meeting minutes, tickets for capacity changes and the forecast itself. Without management review, the control will not show the link between measurement and action that A1.1 describes, so plan for a standing review rather than an ad hoc one.
Can our own team prepare A1.1 in-house?
Many teams can, provided someone owns the control, the engineers have time to build and run the monitoring, and management commits to the review cadence. In-house preparation works best when the environment is small or already well instrumented. It becomes harder when several cloud accounts, data centers or customer-hosted components must be covered, or when no one has written a capacity process before. A fair test is whether your team can name the metrics you watch, the thresholds that trigger action, the last forecast and the last capacity decision, with records for each. If those answers are unclear, a partner can help build the process, but the organization still owns the control and the evidence.
What should we ask a partner to include in a scoped quote for A1.1?
Ask for the written scope first: which systems, environments and accounts are covered, which metrics and logs are in scope, and whether the work covers the monitoring build, the forecasting process, the documentation or all three. Then ask which deliverables you receive, such as configured monitoring, alert rules, a capacity review procedure, a forecast template and an evidence checklist for the auditor. Ask what the partner does not do: a partner prepares systems and evidence, while only the independent CPA firm issues the report. Also ask how support after the examination is handled, since capacity reviews recur throughout the audit period, and whether the work is fixed-scope with timelines agreed before work starts.
How does A1.1 change if availability is not in scope for our SOC 2?
A1.1 is an additional criterion in the availability category, so it applies only when you include availability in the report. If availability is out of scope, you do not need a separate capacity management control to satisfy A1.1. However, many capacity practices still help you meet common criteria, particularly those about monitoring and system operations, so the work you do may partly overlap. Confirm the boundary with your CPA firm when you define the system description, because a customer may still ask about capacity even when the report excludes availability. Adding the category later means A1.1 and its sibling criteria become part of the examination, with the additional effort that brings.
What tools and records make A1.1 easier to evidence?
Evidence for A1.1 usually comes from the monitoring system itself plus the records of human review. Prometheus collects metrics from instrumented jobs over HTTP and stores them as time series that PromQL can query, so historical usage can be shown for the audit period. Grafana Alerting builds alert rules from queries across data sources and lets teams manage alerts from one view, which helps show that thresholds exist and were acted on. Keep dashboard exports, alert rule definitions under version control, review minutes, forecast documents and tickets for capacity changes. Confirm with your auditor which format and sampling approach they expect before you build the evidence set.
How DeployOpen prepares A1.1 for a SOC 2
DeployOpen plans, implements and documents self-hosted open-source monitoring for A1.1 inside the client's own cloud accounts, data centers or private networks, and prepares the capacity evidence the examination will ask for. The work is delivered under a fixed-scope written agreement that fixes the systems in scope, the metrics collected, the alert thresholds, the forecasting method and the deliverables before work starts. Ongoing support, upgrades and tuning can be added as a retainer. The organization keeps ownership of its controls: management decides the capacity thresholds, approves the forecast and signs off on the capacity decisions that follow from it.
In practice, the preparation covers the components that carry the service: compute, storage, databases, queues and network paths. DeployOpen configures Prometheus to scrape instrumented jobs over HTTP and retain time series on local storage, and sets up Grafana Alerting so that rules built from queries across metrics and logs notify the right owners. The team documents which metrics are measured, how often usage is reviewed, who receives each alert and how a threshold breach becomes a capacity change ticket. Confirm with your own environment how long metric history must be kept to support a forecast, because retention settings in Prometheus and any long-term store you add will determine what the auditor can see for the Type 2 period.
DeployOpen does not issue SOC 2 reports, attestations or opinions. Only an independent CPA firm can examine the system and issue a report, and DeployOpen's role is to prepare systems, controls and evidence for that examination. Before engaging anyone, ask the CPA firm which capacity evidence it will sample, and ask the implementation partner to show how each artifact maps to the control activity it supports. Keep the written scope, the configuration history and the review records together, because the examination depends on the organization's own records rather than on any statement made by its implementation partner.
