SOC 2 Availability Criteria: System Uptime and Performance Management

Dana Whitfield had forty-seven minutes to explain why Correlate Health's patient-scheduling platform had gone dark in the middle of a $2.4 million enterprise renewal call.

Dana was VP of Engineering at Correlate Health, a mid-sized health-tech company whose scheduling and intake platform sat behind the workflows of eleven regional hospital systems. The outage itself wasn't dramatic — a database failover that should have taken ninety seconds took forty-seven minutes because the standby replica hadn't been tested in eight months and came up with a stale connection pool configuration. Nobody got hurt. No data was lost. But the prospective customer's procurement team was on that renewal call, watching Correlate's own status page turn red in real time, and their first question in the follow-up email wasn't about the root cause — it was "Does your SOC 2 report cover Availability?"

It didn't. Correlate had scoped its SOC 2 examination to Security only, the mandatory Common Criteria, two years earlier, because that was what the first few enterprise deals had asked for. Nobody had revisited the decision as the customer base shifted toward hospital systems that treated scheduling downtime as a patient-safety issue, not just an IT inconvenience. Dana's compliance lead, Craig Doheny, had flagged the gap in a risk review eighteen months prior. The flag sat in a spreadsheet. Now it was costing them a renewal.

This article is about closing that gap properly — not by bolting an uptime dashboard onto a wall and calling it a control, but by building the capacity management, environmental protection, backup and recovery, and recovery-testing discipline that the Availability criteria actually require, and the evidence trail that proves you're doing it consistently rather than performing it for auditors twice a year.

Who This Is For, and What You'll Walk Away With

This is written for engineering directors, SRE and platform teams, and compliance or GRC managers at service organizations that are either scoping Availability into a SOC 2 examination for the first time or trying to make an existing Availability-in-scope report defensible under sustained Type II testing. You should already understand the basic SOC 2 structure — Trust Services Criteria, Type I versus Type II, the mandatory Common Criteria — because this article goes one level deeper into a single optional criteria category. You'll walk away with the real A1.1–A1.3 control structure, a framework for setting and documenting availability commitments, the evidence auditors expect for capacity, redundancy, backup/recovery, and monitoring, and a clear line between "this is an Availability control" and "this is just Security criteria doing double duty."

Availability Is Optional — and That's the First Decision You Have to Get Right

Every SOC 2 examination includes the Security criteria, formally the Common Criteria (the CC-series), because the AICPA requires it as the baseline in every report regardless of scope. Availability is one of four additional Trust Services Criteria categories a service organization can choose to add on top of that baseline — alongside Processing Integrity, Confidentiality, and Privacy — and it is included only when it reflects a genuine commitment the organization has made to its customers about uptime, performance, or operational continuity.

That "only when" matters more than most first-time SOC 2 candidates realize. Adding Availability isn't a marketing decision to make the report look more thorough; it's a scope decision that obligates you to design, operate, and evidence an entire additional set of controls — capacity management, environmental and infrastructure protections, backup and recovery processes, and recovery plan testing — across the full audit period. Scope it in without the operational maturity to back it up, and you've handed your auditor a roadmap to your worst outages.

"I've watched two companies add Availability to their SOC 2 scope in the same quarter for opposite reasons. One had genuine 99.95% uptime SLAs baked into every enterprise contract and needed the report to reflect reality. The other added it because a competitor's report had it and their sales team thought it looked incomplete without it. The second one failed its first Type II test on capacity monitoring evidence because nobody had actually been tracking capacity trends — they'd been reacting to pages. Scope should follow your commitments, not your envy of a competitor's table of contents."
— Priya Chandrasekaran, CISO, Bluewater Fintech

The table below is the scoping filter I walk clients through before they commit to adding Availability.

Table: When Availability Belongs in Your SOC 2 Scope

Distinguishing Availability Engineering from Security

This is the conceptual mistake I see most often, and it's worth addressing before we get into the A1 criteria themselves: Availability is not "Security, but for uptime." The two categories overlap at the edges — a denial-of-service attack is both a security event and an availability event — but they test fundamentally different disciplines.

The Common Criteria (CC1–CC9) are built around the CIA triad's confidentiality and integrity concerns as much as availability: access control, change management, logical and physical security, risk assessment, monitoring for unauthorized activity. Security asks "can an unauthorized party get in, alter data, or exfiltrate something." Availability asks a completely different question: "when legitimate demand hits the system, or when infrastructure fails, does the system keep functioning at the level we promised, and can we prove that with capacity data, redundancy design, and tested recovery procedures — not just uptime percentages pulled from a monitoring dashboard the week before the audit."

An auditor testing Security controls wants to see your access reviews, your vulnerability scan results, your incident response runbooks for breaches. An auditor testing Availability wants to see capacity forecasting models, load test results, redundancy architecture diagrams, backup restoration test logs, and a recovery plan that's been exercised — not just written — within the audit period. These are different artifacts, produced by different teams, on different cadences, and conflating them is exactly how organizations end up scoping Availability into a SOC 2 report without the underlying operational muscle to support it.

Table: Availability Engineering vs. Security Engineering in SOC 2 Terms

Both categories sit inside the same Trust Services Criteria framework and the same attestation, but they earn their evidence separately. An organization that aces Security testing and stumbles on Availability testing usually has the same root cause: strong access governance, weak operational capacity discipline. If you want the fuller map of how all five TSC categories fit together, our guide to SOC 2's Trust Services Criteria walks through Security, Availability, Processing Integrity, Confidentiality, and Privacy side by side, and our deep dive on the SOC 2 Security criteria covers the mandatory baseline this article assumes you already have in place.

Availability in Regulated and High-Stakes Industries

The stakes attached to Availability criteria shift dramatically by industry, and it's worth naming that explicitly before diving into the control mechanics. For a marketing website or an internal analytics tool, a few hours of downtime is an inconvenience. For Correlate Health's patient-scheduling platform, downtime touches whether a clinic can see the patients on its calendar that day — not a life-safety event in the way a medical device outage would be, but close enough to patient operations that hospital procurement teams treat it as a contractual red line, not a technical footnote.

Financial services, payments infrastructure, logistics and supply chain platforms, and critical infrastructure providers all carry similar weight: downtime doesn't just cost the vendor a support ticket, it cascades into the customer's own operational or regulatory exposure. This is precisely why Availability scoping decisions should be industry-aware, not just architecture-aware. A fintech company processing real-time payments and a marketing SaaS tool with the exact same technical redundancy posture face very different expectations from their respective customer bases and, often, from their own regulators layered on top of SOC 2.

If you're mapping out which Trust Services Criteria apply to your specific industry context and customer commitments, our SOC 2 Trust Services Criteria Mapping Template is built for exactly this exercise — walking through each TSC category against your actual contractual and regulatory obligations before you lock in scope.

"Hospital procurement teams don't read SOC 2 reports the way SaaS buyers do. They're not looking for a clean opinion as a checkbox — they're mapping your downtime history against their own patient-safety risk register. When Availability is in scope with real tested numbers behind it, that conversation gets dramatically shorter."
— Craig Doheny, Head of Compliance, Correlate Health

The A1 Series: What the Availability Criteria Actually Require

The AICPA's Availability category contains three criteria, numbered A1.1 through A1.3. They build on each other in a specific order that mirrors how availability actually breaks in production: first you run out of capacity, then your recovery infrastructure fails you when you need it, then you discover your recovery plan was never actually tested. Each criterion targets one of those failure points.

Table: The A1 Series at a Glance

A1.1: Capacity Management — Monitoring and Managing Capacity to Meet Commitments

A1.1 is where most Availability scoping efforts either succeed or quietly fail. The criterion requires the entity to monitor system capacity — compute, storage, network, and (increasingly) the capacity of dependent third-party services — and to manage that capacity in a way that supports meeting its availability commitments. The key word auditors focus on is "manage," not just "monitor." A dashboard that shows CPU utilization climbing toward 90% for six months without a corresponding capacity decision — an upgrade, a scaling policy, an architecture change — is evidence of monitoring without management, and that gap is precisely what A1.1 testing is designed to surface.

"The single most common finding I write on Availability engagements is 'capacity monitoring exists, capacity management does not.' Teams have Grafana dashboards, they have alerts, they can show me a graph. What they usually can't show me is a decision log — a place where someone looked at a capacity trend, decided to act, and the action got tracked to completion. That decision trail is the actual control. The dashboard is just the input to it."
— Tom Radzik, Audit Partner, Ashgrove & Kline CPAs

Table: A1.1 Capacity Management — Controls and Evidence

Capacity Monitoring and Forecasting in Practice

The mechanics of A1.1 come down to picking the right metrics, setting thresholds with real margin, and building a forecasting cadence that outruns your growth curve rather than reacting to it after the fact. Most organizations I work with under-invest in the forecasting half. They have excellent real-time monitoring — anyone can see current CPU load — but no forward-looking model that says "at current growth rate, we exhaust database connection capacity in eleven weeks."

The metrics worth tracking depend on your architecture, but a few categories show up in almost every Availability engagement I've worked: compute utilization (CPU, memory, container/pod density), storage (disk utilization, IOPS, database connection pool saturation), network (bandwidth, request queue depth, egress limits), and increasingly, dependency capacity — API rate limits from payment processors, third-party auth providers, or CDN quotas that your own infrastructure can't scale past no matter how much headroom you add internally.

Table: Core Capacity Metrics by Layer

Thresholds without margin are a common gap. If your SLA commits to 99.9% uptime and your capacity threshold is set at "start scaling when we hit 95% utilization," you've left almost no room to react before a spike turns into an outage — provisioning new capacity, even with automation, rarely happens instantly. I generally recommend thresholds set to trigger action at 70–75% utilization for anything that takes more than a few minutes to remediate, reserving the 85–90% range for automated, near-instant scaling responses only.

Managing Third-Party and Vendor Capacity Dependencies

The capacity conversation most organizations skip entirely is the one that isn't under their own control. Your own compute and storage can scale essentially on demand with modern cloud infrastructure, but the third-party services you depend on — payment processors, authentication providers, SMS/email delivery services, CDN edge capacity, even upstream API partners — have their own rate limits, quotas, and failure modes that your redundancy architecture can't engineer around.

I've seen more than one A1.1 near-miss where internal capacity was fine and the actual constraint was a payment processor's API rate limit that nobody had mapped against projected transaction volume for an upcoming promotional period. The fix isn't complicated, but it does require discipline most teams don't build until after a first near-miss: maintain an inventory of every critical third-party dependency, its documented rate limits or quotas, your current consumption trend against those limits, and an escalation contact for requesting increases before you need them urgently. Treat vendor quota headroom with the same seriousness as your own infrastructure headroom — an auditor testing A1.1 thoroughly will ask about it, and "we didn't think about that" is not a comfortable answer to give mid-fieldwork. Organizations early in this process often lean on our SOC 2 Gap Analysis Tool to surface exactly this kind of blind spot before it becomes an audit finding.

A1.2: Environmental Protections, Backup, and Recovery Infrastructure

A1.2 covers two related but distinct obligations: environmental protections for the physical and infrastructure environment the system runs on, and the existence of backup and recovery infrastructure capable of restoring the system if something fails. For cloud-native organizations, "environmental protections" often gets misread as irrelevant — "we don't own a data center" — but the criterion still applies to how you've architected resilience against the environmental and infrastructure failures your cloud provider can and does experience: availability zone outages, regional service disruptions, and the loss of individual compute or storage resources.

"Clients tell me 'we're all in AWS, so environmental controls don't apply to us.' I ask them what happens if us-east-1 has a bad day — and AWS's own status history says it will, eventually. If the answer is 'we go down with it,' that's an A1.2 gap regardless of who owns the physical building. The criterion isn't about generators and HVAC anymore for most companies; it's about whether your architecture survives the failure domain you're actually exposed to."
— Marcus Oyelaran, Site Reliability Engineering Lead, Ferrotype Logistics

Table: A1.2 Environmental, Backup, and Recovery Infrastructure — Controls and Evidence

Redundancy and High Availability Architecture

Redundancy is the architectural half of A1.2, and it's where the gap between "we have backups" and "we can actually stay available" gets exposed. A backup that takes six hours to restore is a disaster recovery asset, not a high-availability one — and most availability commitments (anything above roughly 99.9%) simply can't tolerate a six-hour recovery window even once a year.

The redundancy pattern you need depends on the availability tier you've committed to. Active-passive failover with automated health checks is a reasonable baseline for a 99.9% commitment. Multi-region active-active architecture is what 99.99%-and-above commitments actually require, because it's the only pattern that survives an entire region failing without a manual cutover step in the critical path.

Table: Redundancy Patterns Mapped to Availability Commitments

Testing Redundancy Without Causing an Outage

A reasonable objection engineering teams raise when I recommend more aggressive recovery testing is: "won't testing failover risk causing the exact outage we're trying to prevent?" It's a fair concern, and the answer is a graduated approach rather than an all-or-nothing one. Tabletop exercises — walking through the failover scenario on paper or in a staging environment with the team that would actually execute it — carry essentially zero production risk and still surface the kind of architectural blind spots Ferrotype Logistics found in their zone-affinity gap. These should happen most frequently.

Controlled, announced failover tests against production during low-traffic windows, with rollback procedures ready and stakeholders informed, are the next rung up, and they're what actually validates your tested RTO/RPO numbers rather than just your team's understanding of the plan. The most mature organizations eventually graduate to chaos-engineering practices — deliberately injecting failures into production during business hours to validate that redundancy holds under real conditions, not just planned ones — but that's a capability to grow into over several audit cycles, not a starting point. Auditors testing A1.3 don't require chaos engineering; they require evidence that recovery has been exercised at a level of rigor proportional to your system's criticality, consistently, across the audit period.

Backup and Disaster Recovery: RTO, RPO, and What Auditors Actually Check

Every backup and disaster recovery conversation eventually collapses into two numbers: Recovery Time Objective (RTO), how long you can be down before the business impact becomes unacceptable, and Recovery Point Objective (RPO), how much data loss — measured in time — is tolerable if you have to restore from a backup rather than fail over live. SOC 2 auditors don't grade you against an absolute standard here; they check whether your actual, tested recovery capability matches the RTO/RPO figures you've documented and, implicitly, whatever you've told customers.

This is the single most common gap I find in Availability engagements: an RTO of "4 hours" written in a disaster recovery plan that has never been tested against a clock. When we run the first real test, actual recovery time is eleven hours, because nobody accounted for DNS propagation delay, application warm-up time, or the fact that the person who knows the manual failover steps is on parental leave. The documented number and the demonstrated number have to match, or the documented number is fiction.

Table: Backup and DR Design by System Tier

Backup design also has to account for where the copies live and how they're protected. A backup stored in the same region, same account, and same access-control boundary as production isn't much of a control — it's a copy that fails alongside the thing it was meant to protect. Encryption at rest for backup data, separate credentials for backup storage, and immutability or write-once protections against ransomware-driven deletion are all now standard expectations, not extras.

A1.3: Recovery Plan Testing

A1.3 is the criterion that catches the gap between a documented plan and a demonstrated capability. It requires the entity to test recovery plans and procedures supporting system recovery, and this is where "we have a disaster recovery document in Confluence" stops being sufficient evidence. Auditors want to see that the plan has been executed — fully or via tabletop exercise, depending on system criticality — within the audit period, with results documented, gaps identified, and remediation tracked.

"A recovery plan you haven't tested is a hypothesis, not a control. I've sat across the table from engineering leaders who were genuinely shocked that their well-written, detailed, sixty-page DR plan wasn't enough for a Type II pass. The plan tells me what you intend to do. The test tells me you can actually do it, under time pressure, with the people who'd really be on the call at 2 a.m."
— Tom Radzik, Audit Partner, Ashgrove & Kline CPAs

Table: A1.3 Recovery Plan Testing — Controls and Evidence

Testing cadence should scale with criticality: Tier 1 systems deserve at least a full live failover test annually with quarterly tabletop exercises in between, while Tier 3 and 4 systems can reasonably run on an annual tabletop-only cadence. What auditors consistently flag is inconsistency — a plan tested once, three years ago, right before the first SOC 2 audit, and never touched again.

Case Study: The Forty-Seven-Minute Failover That Changed Correlate Health's Roadmap

Back to Dana Whitfield. Correlate Health lost the renewal call's momentum but not the deal — the hospital system's procurement team gave them ninety days to demonstrate a credible remediation path before the contract lapsed. Dana and Craig Doheny used those ninety days to scope Availability into their next SOC 2 Type II examination rather than treating the outage as a one-off incident to patch and move past.

The root-cause work was unglamorous: the standby database replica had drifted out of sync with a connection-pool configuration change made seven months earlier, and nobody had a process that would have caught it because failover testing wasn't a scheduled control — it was something that happened "when someone remembered." Correlate's fix wasn't a single heroic engineering sprint; it was three structural changes. First, they instituted a quarterly failover test for their Tier 1 scheduling system, with results logged and gaps tracked to closure — turning A1.3 from theory into a calendar entry with an owner. Second, they set capacity thresholds with real margin (moving their database connection-pool alert from 92% to 70%) and added a monthly capacity review that Dana personally attended, closing the A1.1 gap Craig had flagged eighteen months earlier. Third, they moved their standby database from a cold, manually-activated replica to a warm standby with automated health-check-triggered promotion, cutting their tested failover time from that catastrophic forty-seven minutes to under ninety seconds.

Six months later, Correlate's next quarterly failover test completed in eighty-three seconds, logged, reviewed, and filed as evidence. The hospital system renewed for three years. Dana's summary of the experience, delivered at an internal engineering all-hands: "We didn't need to be perfect. We needed to be able to prove, on a schedule, that we could recover — and we couldn't, until we made recovery testing a control instead of a hope."

Availability Commitments and SLAs: Setting Numbers You Can Actually Defend

Every Availability engagement starts with a document that doesn't get enough attention: the availability commitment itself. This is the number — 99.5%, 99.9%, 99.95%, 99.99% — that shows up in customer contracts, your system description, and ultimately the auditor's testing criteria. Get this number wrong in either direction and you create problems: set it too aggressively and you're testing against a target your architecture can't consistently hit; set it too conservatively and you undersell what you've actually built, while still paying for the redundancy that would support a stronger number.

"I ask every client the same question before we talk about architecture: what number is in your contracts right now? Not what you'd like to promise — what's actually written down. Half the time, sales has quietly agreed to 99.99% in an enterprise MSA that engineering has never seen, and the SOC 2 report is about to make that gap very visible to everyone who reads it."
— Elena Vasquez, Director of Platform Engineering, NimbusCart

Table: SLA / Uptime Tiers and Their Real-World Implications

The lesson from Correlate's near-miss generalizes: the commitment you write down has to match a tested, not theoretical, recovery capability. If your contracts say 99.9% but your last real failover test took four hours, the gap between commitment and capability is exactly what an Availability-scoped SOC 2 audit exists to surface — better you find it than a customer does.

Monitoring Uptime: What "Continuous" Actually Means to an Auditor

Continuous monitoring is a term that gets used loosely, and Availability testing is where the looseness gets called out. Auditors want evidence of monitoring coverage across the full audit period — typically three to twelve months for a Type II report — not a monitoring stack that was configured properly the week before fieldwork started. That means monitoring configuration history, alert-firing history, and a documented on-call/escalation process that shows alerts actually reach a human who can act.

The monitoring stack itself matters less to an auditor than its completeness and its connection to action. A synthetic-transaction monitor that pings a health-check endpoint every sixty seconds is good baseline coverage, but it won't catch a slow-degrading database query pattern the way real-user monitoring or distributed tracing will. Most mature Availability programs run a layered approach: infrastructure-level metrics, application performance monitoring, synthetic uptime checks from multiple geographic locations, and a public or customer-facing status page that keeps the organization honest about incident timelines.

Table: Monitoring and Alerting Layers for Availability Evidence

An auditor sampling monitoring evidence during a Type II examination will typically pull alert history for a handful of dates across the audit period and trace each one forward: did the alert fire, did it reach an on-call responder, was there a documented response, and did the resolution match what the incident record says. Gaps anywhere in that chain — an alert that fired into a channel nobody was watching, an on-call rotation with an unstaffed slot — are exactly the kind of finding that turns a clean Type II into a qualified opinion.

Incident Handling for Outages: From Detection to Post-Mortem

Availability criteria don't just test whether outages happen — every system has outages eventually — they test whether your organization has a repeatable, evidenced process for detecting, responding to, communicating about, and learning from availability incidents. This is where Availability and Security incident response converge somewhat, but the outage-specific version of incident handling has its own shape: severity classification tied to availability impact, customer communication obligations tied to SLA commitments, and a post-incident review that feeds back into capacity and redundancy decisions rather than just closing a ticket.

Table: Outage Severity Classification and Response Expectations

Every SEV-1 and SEV-2 event should generate a post-incident review that explicitly asks: was this a capacity failure, a redundancy failure, or a recovery-process failure, and which A1 control should have caught it earlier. Correlate Health's forty-seven-minute outage, in this framing, was simultaneously an A1.1 failure (capacity/configuration drift went unmonitored) and an A1.3 failure (the recovery plan existed but hadn't been tested recently enough to catch the drift). Treating post-incident reviews as inputs to the control environment, not just engineering retrospectives, is what turns outages into evidence of a functioning system rather than repeated embarrassments.

How Capacity, Redundancy, Backup, and Monitoring Work Together

None of the four pillars covered so far — capacity management, redundancy architecture, backup and recovery, and monitoring — functions as a standalone control. They form a loop: monitoring feeds capacity decisions, capacity decisions inform redundancy investment, redundancy and backup infrastructure get validated through recovery testing, and recovery testing results flow back into what you monitor and alert on next. The diagram below is the mental model I use with engineering teams building an Availability program from scratch.

Read the loop clockwise: commitments set the targets, monitoring watches against those targets, capacity management acts on what monitoring shows, redundancy and backup infrastructure absorb the failures capacity management can't prevent, and recovery testing proves the whole chain actually works — with results looping back to refine both monitoring thresholds and the commitments themselves. A gap anywhere in this loop is a gap an auditor will eventually find, because A1.1 through A1.3 are written to test the loop's integrity, not just its individual links.

Case Study: Ferrotype Logistics and the Single-Region Blind Spot

Ferrotype Logistics ran freight-matching software that regional trucking brokers depended on to book loads in near-real time. Their SOC 2 report had included Availability for two audit cycles, with a documented 99.9% commitment and a redundancy architecture that looked solid on paper — until a cloud provider's regional network disruption took out a single availability zone that, it turned out, hosted every one of Ferrotype's "redundant" application servers.

Marcus Oyelaran, Ferrotype's SRE lead, discovered the flaw during what was supposed to be a routine A1.3 tabletop exercise, not during an actual outage — which is precisely the outcome recovery testing is supposed to produce. Running through the failover scenario on paper, the team realized their multi-server deployment, while genuinely redundant at the instance level, had never been explicitly pinned across availability zones; auto-scaling had simply been placing new instances wherever the cloud provider's scheduler found capacity, which had drifted to concentrate almost entirely in one zone over eighteen months of organic growth.

Ferrotype fixed the gap before it became an incident: they added explicit zone-anti-affinity rules to their infrastructure-as-code, split their database read replicas across three zones instead of a de facto one, and added a quarterly architecture review specifically checking zone and region distribution against the redundancy diagrams filed as SOC 2 evidence — closing the gap between what the diagram claimed and what was actually running. Their next real regional disruption, four months later, caused a 40-second latency blip with zero customer-visible downtime. Marcus's takeaway, shared at a regional SRE meetup: "Redundancy diagrams lie by omission all the time. The tabletop test is what catches the lie before a real outage does."

Case Study: NimbusCart's Capacity Forecasting Failure

NimbusCart, an e-commerce platform serving mid-market retailers, had strong monitoring and a genuinely redundant multi-AZ architecture — their A1.2 posture was solid. Their gap was in A1.1: capacity forecasting. Elena Vasquez's platform team tracked utilization in real time and had alerting configured correctly, but nobody owned forward-looking capacity planning tied to known demand spikes, like the promotional shopping events their retail customers ran every November.

The result was a database connection-pool exhaustion event during a coordinated flash-sale weekend across several large customers simultaneously — a scenario that was entirely predictable from historical traffic patterns and customer marketing calendars NimbusCart's own sales team had visibility into, but that never made it into a capacity model. The outage lasted twenty-two minutes and generated a wave of support escalations and one formal SLA credit claim.

NimbusCart's remediation became a case study in what A1.1 "management," not just monitoring, looks like: they instituted a formal quarterly capacity forecasting process that explicitly incorporated customer-provided demand signals (upcoming promotions, seasonal patterns) rather than relying purely on historical infrastructure trend lines, and they pre-provisioned connection pool headroom ahead of known high-traffic windows instead of reacting to threshold alerts in real time. The following November, traffic exceeded the prior year's peak by 60%, and the platform held without a single capacity-related incident. Elena's framing to her own board afterward: "Monitoring told us we were fine until the exact moment we weren't. Forecasting is what would have told us three weeks earlier that we needed to act."

Evidence Collection: Building an Availability Evidence Trail Auditors Trust

Across all three A1 criteria, the evidence that holds up under Type II testing shares a few characteristics: it's generated as a byproduct of normal operations rather than manufactured for the audit, it's timestamped and attributable to a specific person or system, and it exists consistently across the full audit period rather than clustering suspiciously around known audit windows.

Table: Evidence Types Mapped to A1 Criteria

Auditors sampling this evidence during fieldwork will typically request a handful of dates spread across the audit period and ask you to produce the corresponding capacity review, the corresponding backup log, the corresponding test record — not a single polished packet assembled after the fact. Organizations that pass Availability testing cleanly are, almost without exception, the ones whose evidence trail was a byproduct of how they already worked, not a project undertaken in the month before fieldwork. Our SOC 2 report structure guide walks through how this evidence ultimately surfaces in the description of tests of controls and results section of the finished report.

Before fieldwork starts, it's worth running an internal dry run against the same sampling logic an auditor will use — pick random dates across the audit period and confirm you can actually produce the corresponding capacity review, backup log, or test record within minutes, not days of searching. Our SOC 2 Readiness Checklist includes an Availability-specific evidence walkthrough for exactly this purpose, and if terminology across A1.1–A1.3 gets confusing for newer team members pulled into evidence-gathering, our SOC 2 Glossary is a fast reference to keep everyone using the same vocabulary with the auditor.

Common Pitfalls in Availability Scoping and Evidence

Most Availability findings I write, or see written by other auditors, cluster around a small set of repeatable mistakes. Knowing them in advance is the cheapest remediation available.

Table: Common Availability Pitfalls and How to Avoid Them

Tooling and Investment: What Availability Actually Costs to Support

Adding Availability to SOC 2 scope isn't primarily a paperwork exercise — it's an operational commitment that typically requires real tooling and, in some cases, architecture investment. Organizations sizing this up for the first time consistently underestimate the ongoing cost relative to the one-time audit prep cost.

Table: Tooling Categories Supporting Availability Controls

The multi-region active-active architecture that supports a 99.99% commitment costs meaningfully more, in both infrastructure spend and engineering complexity, than the active-passive setup that supports 99.9%. This is exactly why the scoping conversation earlier in this article matters: committing to a tier your budget can't sustain year-round is a slower-motion version of the same mistake as never testing your recovery plan — a promise your infrastructure can't consistently keep.

Roles and Responsibilities: Who Owns Availability Controls

Availability controls fail most often not because the technical capability is missing, but because ownership is diffuse. Capacity monitoring might sit with platform engineering, redundancy architecture with a principal engineer, backup configuration with a DBA team, and recovery testing with whoever volunteers — with no single person accountable for the A1 series as a whole the way a compliance lead is accountable for Security criteria evidence.

Table: RACI for Availability Criteria Implementation

Getting this table filled in with names, not just roles, before the audit period starts is one of the highest-leverage steps in an Availability scoping project — it's the difference between Craig Doheny's flagged risk sitting in a spreadsheet for eighteen months and it landing on someone's calendar with a due date. Our SOC 2 Control Matrix / RACI Template gives you a starting structure across all in-scope Trust Services Criteria, not just Availability, so ownership doesn't fragment the moment you add a second or third optional category to your report.

It's also worth stating plainly what happens when this table doesn't get filled in with names: the organization defaults to whoever notices a problem first reacting to it, which is exactly the "reacting to pages instead of managing capacity" pattern that produces A1.1 findings. Explicit ownership, reviewed and reconfirmed at least annually as teams reorganize, is cheap insurance against the single most common root cause behind Availability control failures — not a lack of technical capability, but a lack of anyone whose job it clearly was to act on the data everyone could already see.

Implementation Timeline: Adding Availability to an Existing SOC 2 Program

Organizations that already have Security-only SOC 2 reports and want to add Availability in the next cycle should plan on a runway measured in quarters, not weeks — mostly because A1.3 recovery testing evidence has to accumulate across the actual audit period, not get manufactured retroactively.

Table: Realistic Timeline for Adding Availability to SOC 2 Scope

Trying to compress the evidence-generating period is the single most common way organizations set themselves up for a qualified opinion on newly added Availability criteria. A capacity review process started six weeks before fieldwork can't produce six months of monthly meeting minutes — it can only produce six weeks of them, and an auditor will notice the gap immediately.

Availability as a Business Opportunity, Not Just an Audit Line Item

It's tempting to treat the Availability criteria as one more compliance checkbox competing for engineering time against feature work. That framing undersells what's actually happening when you do this well: capacity forecasting, tested redundancy, verified backups, and exercised recovery plans are the exact operational disciplines that separate vendors customers trust with mission-critical workloads from vendors they keep on a short leash pending "one more good quarter." Correlate Health didn't just save a renewal — Dana's team used the resulting SOC 2 Type II report, with Availability in scope and a demonstrated eighty-three-second failover on record, as a sales asset in every subsequent enterprise deal, turning a defensive compliance project into competitive differentiation against competitors still scoped to Security only.

"Once we had tested recovery numbers we could put in front of a customer's technical due-diligence team, our sales cycles with hospital systems got shorter, not longer. Compliance had been the thing slowing deals down. It became the thing closing them."
— Craig Doheny, Head of Compliance, Correlate Health

That's the real case for treating Availability as more than a scope box to tick: the underlying work — knowing your capacity headroom before you exhaust it, architecture that survives the failure domains you're actually exposed to, backups you've proven you can restore, and a recovery plan you've actually run — is work you want regardless of whether an auditor ever asks for it. The SOC 2 report is just the mechanism that makes the discipline visible, verifiable, and sellable to customers who can't audit your infrastructure themselves.

If you're scoping Availability into an upcoming SOC 2 examination, or trying to strengthen evidence for a report that already includes it, PentesterWorld's compliance team can help you assess A1.1–A1.3 readiness, build the capacity and recovery-testing cadence that generates defensible evidence year-round, and prepare for Type II fieldwork without the scramble. Get in touch to talk through where your Availability posture stands today.