Trust Services Criteria Mapping for SOC 2 Security and Availability

SOC 2 reports build on a single foundation no matter which Trust Services Categories a company adds to its scope: the 33 Common Criteria that make up Security. A company can run a complete, valid SOC 2 examination on Security alone, but it cannot add Availability, Processing Integrity, Confidentiality, or Privacy without first building Security underneath it. That architecture is what makes mapping Security against Availability useful: it shows a company exactly which controls it has already built do double duty, and where it still owes the auditor something new. Used well, that map turns a SOC 2 examination from a once-a-year compliance exercise into a tool enterprise buyers actually read and trust.

When a company scopes both Security and Availability, all 33 Common Criteria (CC1 through CC9) carry over intact into the Availability examination, because Availability cannot be scoped without Security underneath it. Of those 33, the controls that do the most double duty are in CC7 (system operations), CC8 (change management), CC9.1 (business-disruption risk mitigation), and the physical-access portion of CC6: monitoring evidence built for CC7.1 and CC7.2 satisfies much of A1.1's capacity-monitoring requirement, CC7.5's incident-response and recovery evidence overlaps with A1.2 and A1.3, a documented business continuity and disaster recovery plan built for CC9.1 serves A1.2 and A1.3 simultaneously, and physical security evidence from CC6 carries forward into A1.2's environmental protection requirement. On top of those 33 shared criteria, Availability adds exactly three criteria of its own: A1.1, which requires active monitoring and management of processing capacity; A1.2, which requires environmental protections, redundancy, and backup systems sufficient to prevent data loss and sustain operations through a disruption; and A1.3, which requires regular, documented testing of recovery procedures before any incident occurs, not merely after one.

How the Trust Services Criteria are structured

The AICPA's Trust Services Criteria have 61 criteria in total. They sit in TSP Section 100, under the 2017 Trust Services Criteria, and the AICPA still lists that version, with points of focus revised in 2022, as current. Those 61 criteria sort into five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. It's tempting to think of these as five equal menu options a company picks from, but they don't work that way. Security contributes 33 criteria, known as the Common Criteria and organized as CC1 through CC9, and you find those same 33 criteria inside every other category's scope as well. Availability doesn't get its own independent set of 33; it inherits Security's 33 and adds a short list on top. Processing Integrity, Confidentiality, and Privacy work the same way: each adds its own series, but all of them stand on the same Security base.

A company cannot scope Availability, or any other category, without also scoping Security. The reverse isn't true. Security by itself is a complete, legitimate SOC 2 report, and plenty of organizations stop there. SOC 2 examinations have become a central way service organizations build and prove trust with clients, so auditors work out how this layered structure shapes scope and evidence strategy. Firms like Pease Bell treat that structure as more than a technicality in audit planning, since the dependency it creates determines, from the first planning conversation, how every subsequent category gets tested.

It helps to know that the content of the 33 Common Criteria hasn't changed since 2017. What has shifted, especially since the 2022 revision, is how auditors interpret and test them in practice: continuous risk assessment rather than an annual check-in, deeper scrutiny of vendors and subprocessors, zero-trust principles applied to access controls, and reporting that goes into more operational detail than it used to. None of that changes the underlying criteria count or structure, but it does raise the evidentiary bar for what "meeting" a given criterion looks like. Because Availability inherits every one of the 33 Common Criteria, understanding what those 33 actually require is a prerequisite to understanding what Availability adds on top of them.

What the 33 Common Criteria cover, series by series

The 33 Common Criteria reach well past firewall settings and password policies. They cover governance, risk management, access control, day-to-day operations, change management, and vendor relationships, making a Security-only SOC 2 report already a substantial assurance engagement. Readers researching this area sometimes see the framework described as having "17 Common Criteria" in one place and "33 Common Criteria" in another, and both figures are accurate: the 17 refers to CC1 through CC5 alone, while the 33 includes CC6 through CC9 as well. If you know which count a given source means, you avoid the confusion.

CC1 through CC5 make up that first set of 17 criteria, and each one maps one-to-one onto a principle from the COSO internal control framework, with the AICPA text citing the specific COSO principle number behind each. CC1, control environment, holds five criteria covering integrity and ethical values, board oversight, reporting lines, hiring and developing competent people, and holding individuals accountable for their control responsibilities. CC2, communication and information, holds three criteria: using quality information internally, communicating responsibilities to people inside the organization, and communicating appropriately with outside parties. CC3, risk assessment, holds four criteria: setting clear objectives, identifying and analyzing risk, considering the potential for fraud, and assessing the impact of significant changes. CC4, monitoring activities, holds two criteria covering both ongoing and separate evaluations of controls and reporting deficiencies to the people positioned to fix them. CC5, control activities, holds three criteria: selecting controls that reduce risk, selecting general technology controls, and deploying both through policies and procedures.

CC6 through CC9 add the remaining 16 criteria, and this is where the Common Criteria start to look more like the operational and technical controls people associate with SOC 2. CC6, logical and physical access, is the largest single series at eight criteria: access security, provisioning and deprovisioning users, role-based access, physical access controls, secure asset disposal, protection against outside threats, protection of data in transit, and controls against malicious software. CC7, system operations, holds five criteria covering detection of configuration changes and new vulnerabilities, monitoring for anomalies, evaluating security events, incident response, and recovery. CC8, change management, is a single criterion covering the full lifecycle of authorizing, designing, testing, approving, and implementing changes to infrastructure, data, software, and procedures. CC9, risk mitigation, holds two criteria: mitigating the risk of business disruption and managing risk tied to vendors and business partners.

Taken together, these 33 criteria span governance, risk management, access, operations, change, and vendor relationships, reaching well beyond technical settings alone. When auditors run a SOC 2 examination, they test whether a service organization's controls show genuine internal control discipline across that whole environment, and the locked perimeter is not the point. That full-environment lens is what firms like Pease Bell bring to assurance work in regulated industries such as multifamily housing and skilled nursing facilities, where vendor and operational risk can matter as much as access controls do. This series-by-series map is the reference point the next two sections build from, since the overlap and the gaps between Security and Availability only make sense once CC1 through CC9 are clear on their own terms.

Which criteria does Availability add on top of the 33 Common Criteria?

Availability adds exactly three criteria to the 33 Common Criteria, labeled A1.1 through A1.3, and each one targets an operational commitment that Security's 33 criteria don't fully cover on their own. The entity has to maintain, monitor, and evaluate its current processing capacity and use of system components, including infrastructure, data, and software, so it can manage capacity demand and bring on additional capacity when its objectives require it, which is what A1.1 covers as capacity monitoring. A1.2 covers environmental protections, backups, and recovery infrastructure: the physical safeguards, redundancy, and backup systems that protect operations against disruption. A1.3 requires regular, documented testing of recovery procedures, so you can confirm those plans actually work and don't just exist on paper.

Availability's scoping limit affects how companies set their commitments: the category itself doesn't set a minimum uptime percentage, and it doesn't define what "committed" availability means. The organization's own system description and the service commitments it makes to customers set that standard, and the auditor tests against whatever standard the organization has defined for itself. That has a direct practical effect. If a company promises a more aggressive uptime commitment in its contracts, it faces a harder Availability examination than a company promising more modest terms, even though both get tested against the same three criteria, A1.1 through A1.3. The rigor of the examination scales with the ambition of the commitment, not with the wording of the criteria.

With both layers now defined, Security's 33 and Availability's three, the mapping turns concrete: which of the controls a company has already built for Security also serve Availability, and which gaps remain untouched. That's the subject of the next two sections.

Security controls that do double duty when Availability is in scope

When Availability enters scope alongside Security, several of the 33 Common Criteria already produce the evidence the three Availability criteria need, so the marginal lift is smaller than a company might expect before it maps things out. The overlap runs deepest through CC7, system operations. CC7.1 and CC7.2 cover detecting configuration changes and monitoring for anomalies, and that same monitoring evidence covers most of what A1.1's capacity monitoring requirement calls for. A well-documented monitoring program built for Security purposes can satisfy both criteria without separate instrumentation. CC7.5, which covers incident response and recovery, overlaps with the recovery infrastructure A1.2 addresses and the recovery testing A1.3 requires.

CC9.1, mitigating business-disruption risk, explicitly covers business continuity planning, and a documented, tested business continuity and disaster recovery plan built to satisfy CC9.1 serves A1.2 and A1.3 at the same time. A tabletop exercise logged as evidence for the vendor and business-partner risk management criterion can also stand as supporting evidence for A1.2 and A1.3 if the exercise tests recovery procedures involving third-party dependencies. CC8.1, change management, supports Availability indirectly but meaningfully: its requirement to authorize, test, and implement changes before they go live is what keeps routine updates from becoming outages, and that stability requirement applies to all three Availability criteria even though none of them name change management directly.

CC6, logical and physical access, contributes to A1.2 through its physical access and asset-protection criteria. The same controls that keep unauthorized people out of a data center also protect the infrastructure that recovery depends on, so physical security evidence gathered for CC6 carries forward into Availability's environmental protection requirement. An organization that has already built strong evidence for CC7, CC8, CC9, and the physical-access portion of CC6 has covered a meaningful share of what Availability asks for before writing a single Availability-specific control. Treating Security and Availability as one connected evidence base rather than two separate projects is what delivers that practical payoff.

Where the overlap ends and Availability-specific coverage must begin

Organizations that assume shared controls cover everything will walk into the examination with gaps nobody flagged in time. A1.1 requires you to actively evaluate and manage processing capacity, and to enable additional capacity when needed, but nothing in CC1 through CC9 directly covers that. Security monitoring is built to catch threats and anomalies, not to track demand trends or confirm there's headroom before a usage spike hits. A company can have excellent CC7 monitoring and still have no evidence at all for capacity planning, because the two are measuring different things.

A1.2 goes further than CC6's physical access controls by requiring environmental protections, power, cooling, physical redundancy, and backup procedures specifically designed to prevent data loss and keep operations running through a disruption. CC6's access criteria answer who is allowed into a facility. A1.2 answers whether the facility keeps running if a transformer fails or a cooling system goes down, and that's a different question with its own evidence trail. In the same way, A1.3 asks for regular, documented testing of recovery procedures, and that differs from the incident-response evidence CC7.5 produces. Incident response documents what happens during and after an actual event. A1.3 asks you to proactively validate, before any incident occurs, that recovery procedures work when tested on their own terms.

There's also a documentation gap unique to Availability: because the category is tested against an organization's own stated service commitments rather than a fixed, universal benchmark, the organization has to explicitly document its availability commitments inside its system description. Security doesn't require that kind of self-defined benchmark, so if you skip it, the auditor has no standard to test against.

Some practitioners argue that a strong CC7 and CC9 program already covers what Availability asks for, making A1.1 through A1.3 redundant. That argument misreads what each layer is built to do. CC7 and CC9 focus on reacting to risk: they catch anomalies, respond to incidents, and manage disruption once it has started. A1.1 asks an organization to manage capacity proactively, and A1.3 asks it to validate recovery before anything breaks. That forward-looking orientation isn't something the Security criteria are designed to test, no matter how mature the CC7 and CC9 program is. Spotting these three gaps, capacity management, environmental and backup infrastructure, and proactive recovery testing, before the examination period starts is what turns a scope decision into a plan rather than a surprise, which is exactly where the final section picks up.

How the Security-Availability mapping shapes practical scope decisions

A company's uptime, recovery, or capacity commitments that customers are actually relying on should decide whether Availability belongs in scope, not the size of the incremental evidence burden. The CBIZ 2024 SOC Benchmark Report found that most SOC 2 reports it reviewed included Availability, so if you serve enterprise buyers, a Security-only report puts you in the minority. That pattern tracks with what enterprise procurement teams expect to see when they're deciding who to trust with their data and their uptime.

Certain industries tilt toward including Availability almost by default. SaaS and cloud infrastructure providers fall into this group because downtime on their end directly stops customers from operating their own products. Healthcare organizations belong here too: continuous system access ties directly to patient care obligations, so Availability works as much as a customer expectation as a compliance checkbox. Financial services organizations carry a similar weight, because system interruptions touch transaction integrity and regulatory obligations, including controls over financial reporting systems.

The double-duty mapping built across the earlier sections has a direct cost consequence. Because several Security controls already satisfy Availability requirements, adding Availability is a more modest lift than building a program from zero, but only if the organization's Security evidence was built with that overlap in mind from the start. Skipping that mapping work doesn't eliminate the gaps described in the previous section; it just delays the discovery of them. Over-scoping carries its own risk: every category a company adds becomes a permanent, recurring evidence obligation, and a qualified opinion on a category the company never actually needed does more damage in a vendor review than simply not reporting on that category.

For service organizations pursuing SOC 2 Availability attestation, this precision carries practical weight. Knowing exactly which controls an auditor will test twice, once under Security and again under Availability infrastructure, and which controls exist only for Availability, lets an organization and its audit partner scope the engagement with a clear sense of what will actually get examined. You should work through this mapping during planning, before the examination period opens; if remediation turns up partway through a Type II period, you can't test it retroactively once the clock has started. A CPA firm conducting the SOC examination, rather than a general compliance platform, is positioned to make the judgment calls this mapping requires: distinguishing which existing Security evidence genuinely satisfies an Availability criterion from which gaps represent controls that have never actually been tested. The auditor's opinion rests on that distinction, so getting it right before the period begins is what turns the mapping into a decision tool during planning.