SOC 2 Vendor Management When Your Data Center Is a Subservice Organization

TL;DR

• When your data center is operated by another organization (a colocation or hosting provider), that organization is a subservice organization under SOC 2
• The carve-out method is more common for colocation: the user entity describes the boundary, implements Complementary User Entity Controls (CUECs) on top, and references the provider's own SOC 2 report for the carved-out controls
• For Canadian SaaS, Leaseweb Canada and OVH Cloud are two archetypal subservice providers that publish SOC 2 (or Canadian CSAE 3000) trust materials user entities can request
• Vendor management maps to CC9.2 (vendor and business partner risk management) and CC3.2 (risk identification)
• What to ask the colocation provider for: the SOC 2 or CSAE 3000 report, scope and trust criteria covered, audit period, exceptions section, complementary controls, contractual commitments around breach notification and data residency

Somewhere in the rack, the floor you're standing on belongs to somebody else.

That is the part most SOC 2 content leaves out. A Canadian SaaS running bare metal in a Quebec colocation, a hybrid shop with compute split between a hypervisor cluster and a Canadian hosting region, an MSP running client workloads out of a Beauharnois facility. In all of those cases, the physical environment, the power, the cooling, the building access, the network uplinks, and a meaningful part of the availability story are operated by a different organization entirely. SOC 2 has a specific name for that organization. It is a subservice organization, and it changes how the user entity has to think about vendor management.

Two Canadian examples make this concrete. Leaseweb Canada operates a Quebec facility that Canadian SaaS companies use for bare metal and dedicated hosting. OVH Cloud operates Canadian regions that Canadian SaaS companies use for cloud, hosted private cloud, and bare metal. Both publish audited trust material. Both are the worked example for everything in this post. Neither can be ignored in the user entity's own audit, and that is precisely the point.

What a Subservice Organization Actually Is

The AICPA framing is specific. A subservice organization is a separate entity whose services are part of the user entity's system under audit. A colocation provider hosting production infrastructure is a textbook subservice organization. Physical security, environmental controls, power continuity, and facility network access are operated by the provider, not by the user entity, but they materially affect whether the user entity meets its security and availability commitments. The controls live at the provider. The outcomes belong to the user entity.

That creates a scoping decision the user entity's auditor has to make up front. There are two options, and the difference between them shapes how the vendor relationship is treated in the report.

For Canadian SaaS running on Leaseweb Canada, OVH Cloud, or any comparable Canadian operator, the carve-out method is the default. That is not a gap. It is the standard treatment, and it is what auditors expect to see.

Complementary User Entity Controls: The Part That Belongs to You

The carve-out method comes with a specific obligation. When the provider's controls are carved out, there are things the user entity must do on its own side to complete the picture. Those are the Complementary User Entity Controls, or CUECs. Every mature subservice SOC 2 report includes a section describing them in generic categories: logical access over any provider-managed interface, personnel change notifications for facility access, configuring and maintaining systems the user entity has physical access to, monitoring the user entity's own workloads, managing encryption keys the user entity controls, reviewing the reports the provider publishes, and notifying the provider of incidents that affect shared infrastructure.

The user entity has to implement those controls. More importantly, the user entity has to be able to prove it implemented them. That is where most on-prem SOC 2 programs stumble the first time they see a colocation contract framed this way. The team assumed the provider handled the data center stuff. The auditor reads the CUEC list out of the provider's report and asks which ticket, which access review, and which policy lines up with each one.

A practical move in on-prem SOC 2 readiness is to treat the CUEC list as a checklist fed into the Security Program Manual. Every CUEC category maps to a domain: physical access management, logical access, change management, incident response, monitoring, data handling. Each domain already has a scope, technology, evidence plan, process cadence, and named owner. The CUEC just adds a row. The program stays the source of truth, and the framework maps onto it without restart.

How CC9.2 and CC3.2 Get Involved

Two Trust Services Criteria carry most of the vendor management load when a data center is a subservice organization.

CC9.2 is the vendor and business partner risk management criterion. It expects the user entity to assess and manage risks associated with vendors across the full relationship, from the requirements for the engagement through termination. The Points of Focus cover establishing requirements for the engagement (scope, roles, compliance expectations, service levels), identifying vulnerabilities arising from the relationship, inventorying and tiering vendors and assessing them periodically, assigning responsibility and accountability for each relationship, establishing communication and exception handling protocols, assessing performance on a cadence proportional to risk, addressing issues identified during assessments, and having a termination procedure that covers the safe return or removal of data. A colocation provider that hosts production systems sits squarely in scope for every one of those.

CC3.2 is the risk identification criterion. It expects the user entity to identify risks to the achievement of its objectives and analyze them as a basis for determining how to manage them. One Point of Focus names threats and vulnerabilities arising from vendors, business partners, and other parties with access to the entity's information systems as a specific category the risk assessment process needs to cover. Another calls out identifying vulnerabilities of system components including infrastructure. When a data center is a subservice organization, the risk assessment has to treat the colocation relationship as a specific identified risk with its own analysis, not a footnote at the bottom of the vendor inventory.

The Over-Scoping Trap

Vendor risk management is one of the most over-scoped sections in SOC 2 preparation. From real engagements: a SaaS company preparing for SOC 2 had entered every vendor they used into their GRC platform, including their bank, open-source tools used locally, and low-risk marketing utilities. The vendor section looked like dozens of incomplete assessments and the company looked behind schedule. In reality, most of those vendors did not need formal assessment at all.

The move that makes CC9.2 tractable is classifying vendors by data access, not by invoice count. Four categories cover it: production data access, development or staging access, employee personal information, and generic business information. A bank processing payroll runs through an HR system and does not directly touch production. An open-source tool compiled locally is not a vendor at all. A marketing task management tool handles generic business information at most. None of those need a formal assessment.

A colocation or hosting provider sits in the opposite category and is never low risk. A provider hosting production workloads has access to the physical systems that store production data, operates the network that carries it, and controls facility access to the hardware. That puts the relationship at the top of the vendor tier every time, with a full assessment, a reviewed trust report, and documented CUECs. The practical result is a short, high-value vendor list rather than an over-scoped inventory that drowns the real work.

What to Request From Your Colocation Provider

When a user entity engages a provider as the subservice organization behind its production environment, a specific set of trust material should be requested and reviewed annually.

The current SOC 2 Type 2 report, or its Canadian equivalent. In the United States, service auditors issue SOC 2 reports under the AICPA's AT-C 205 attestation standard. In Canada, the equivalent assurance engagement is performed under CPA Canada's CSAE 3000 standard and the resulting report is functionally equivalent for user entity purposes. A Canadian SaaS running on a Canadian colocation provider typically receives a CSAE 3000-audited trust report prepared by a CPA Canada-licensed firm. This matters for audit defensibility and sets up the link to the Round 3 post on CSAE 3000 vs SOC 2 and the Canadian standard behind your report.

A security walkthrough or facility overview. Most Canadian providers offer a documented walkthrough covering access zoning, biometric enrollment, cage and cabinet lock management, CCTV coverage, escort policies, and incident reporting. It sits alongside the audited report and gives operations teams something concrete to reference during onboarding.

Contractual service level commitments. Uptime, response time for trouble tickets, power continuity guarantees, and network availability. These become evidence for availability commitments the user entity makes to its own customers. When the provider commits to a specific SLA, that commitment flows through the user entity's own commitments and into the SOC 2 availability criterion.

Change notification commitments. A provider that changes its facility, relocates cabinets, upgrades network routing, or changes subcontractors without notifying user entities creates invisible risk. The contract should name the categories of change the user entity must be notified about and the notification lead time.

A defined exit clause. Data removal, media sanitization, and return of equipment on termination are not optional. CC9.2's termination Point of Focus expects a procedure that covers the safe return of data and its removal from the vendor's systems.

How to Read a Subservice SOC 2 Report

Receiving the report is the easy part. Reading it in a way that produces evidence for the user entity's own audit is the part that takes practice.

Scope. What the report covers and what it does not. A provider operating in multiple countries may scope a report to specific facilities, services, or trust categories. A user entity running production out of a Canadian facility needs a report that explicitly includes that facility and includes the services the user entity consumes.

Observation period. SOC 2 Type 2 and CSAE 3000 reports cover a defined window, typically twelve months. A report whose observation period ended eight months ago is fine for most user entity purposes, but one older than eighteen months should be refreshed or explicitly bridged with a bridge letter from the provider.

Trust Services Categories. Security is the common denominator. Availability matters most for colocation and hosting providers, since uptime is part of the commitment. Confidentiality and Privacy may or may not be in scope. A user entity whose own SOC 2 includes Availability needs a subservice report that includes Availability too, since the provider's availability controls are the upstream dependency.

Exceptions and tests with results. Exceptions are not automatic failures. Read them in context: the nature of the exception, whether management provided a response, whether the exception affects the Trust Services Category the user entity cares about, and whether compensating controls cover the gap. Produce a short memo summarizing scope, period, categories, and any exceptions that affect the user entity's position. Attach the memo to the vendor record in the GRC platform. That memo is the CC9.2 evidence artifact.

The Complementary User Entity Controls section. This list is a contract between what the provider's audit covers and what the user entity's audit has to cover. Read it line by line during onboarding, map each CUEC to a control in the Security Program Manual, and confirm the control is actually implemented before the user entity's own audit begins.

Annual Review Cadence and the Contractual Side

CC9.2 expects vendor assessments on a cadence proportional to risk. For a colocation provider sitting at the top of the vendor tier, annual is the baseline, and the review covers four things: the current trust report has been obtained and the memo described above is attached, new or changed CUECs have been mapped to the Security Program Manual, any exceptions that materially affect the user entity have been either accepted or flagged as action items, and any changes to the provider's subcontractors, facility, or services during the year have been evaluated for impact on the user entity's scope. This is the work a fractional security team keeps on cadence alongside access reviews and firewall reviews. Programs run on cadence, not intention.

The contractual side belongs upstream of all of that, in the MSA signed at the start of the relationship. The categories that matter: a contractual commitment that the provider will make its own SOC 2 or CSAE 3000 report available annually, breach notification commitments with a defined timeline measured in hours rather than days for material incidents, data residency commitments naming the country and region where equipment and data physically reside, and termination and data handling commitments including secure erasure or media destruction. These belong in the initial contract. Renegotiating them after an incident is expensive and sometimes impossible.

The Canadian CSAE 3000 Angle

For Canadian SaaS running on Canadian infrastructure, one practical advantage of the ecosystem is that the subservice trust report is often issued under CSAE 3000, the Canadian assurance standard published by CPA Canada. CSAE 3000 engagements are performed by CPA Canada-licensed firms. The substance of the engagement is functionally equivalent to AT-C 205 for user entity purposes. The label on the cover is different and the practitioner firm is Canadian-licensed rather than US-licensed.

When a user entity's vendor management memo records that a trust report is CSAE 3000 and prepared by a CPA Canada-licensed firm, that record supports the CC9.2 vendor assessment and doubles as procurement-ready documentation for customers asking about Canadian data handling. The upcoming CSAE 3000 vs SOC 2 post covers the standards comparison and how to handle the mixed ecosystem where some providers publish under AT-C 205 and others under CSAE 3000. For provider-specific depth on running SOC 2 with Leaseweb Canada as the subservice organization, the upcoming SOC 2 on Leaseweb Canada post walks through what the user entity inherits and what it still owns.

How CC9.2 and CC3.2 Points of Focus Show Up in Subservice Vendor Management

Pulling the paraphrased Points of Focus together into a single reference makes the mapping concrete.

CC9.2, Vendor and Business Partner Risk Management

• Establishes Requirements for Vendor and Business Partner Engagements. The contract step: scope of services, roles and responsibilities, compliance expectations, and service levels captured in the MSA with the provider.
• Identifies Vulnerabilities. Evaluation of risks the provider relationship introduces, including any physical or network connectivity into the user entity's systems.
• Assesses Vendor and Business Partner Risks. The annual tiering exercise that keeps the colocation provider at the top of the vendor list, covering financial failure, security vulnerabilities, operational disruption, and regulatory failure as explicit risk categories.
• Assigns Responsibility and Accountability for Managing Vendors. The named owner in the Security Program Manual who runs the cadence.
• Establishes Communication Protocols and Establishes Exception Handling Procedures. The agreed channels for routine and incident-driven communication.
• Assesses Vendor and Business Partner Performance. The annual review of the trust report and the SLA posture.
• Implements Procedures for Addressing Issues. The action-tracking step when the trust report surfaces exceptions.
• Implements Procedures for Terminating Vendor and Business Partner Relationships. The exit clause with data return, sanitization, and equipment handling defined in advance.
• Obtains Confidentiality Commitments and Assesses Compliance With Confidentiality Commitments. For engagements including Confidentiality, explicit confidentiality obligations are added to the vendor relationship.

CC3.2, Risk Identification

• Analyzes Internal and External Factors. Where the colocation relationship shows up as a specific identified external dependency.
• Estimates Significance of Risks Identified. Where the risk of a material provider incident is rated against the user entity's objectives.
• Determines How to Respond to Risks. Where the user entity decides to accept, avoid, reduce, or share, typically reducing through CUECs and sharing through the provider's trust report.
• Identifies Vulnerability of System Components. Extends beyond the user entity's own infrastructure to include components at the subservice organization, since those components are part of the user entity's system.
• Analyzes Threats and Vulnerabilities From Vendors, Business Partners, and Other Parties. The explicit CC3.2 instruction to include vendor-origin threats in the risk assessment process.

Explore further in Framework Explorer: CC9.2 · CC3.2, see the full requirement, implementation guidance, evidence types, and cross-framework mappings.

Source: AICPA TSP Section 100, 2017 Trust Services Criteria with Revised Points of Focus (2022). Point of Focus characteristics described in Truvo's words and mapped to a subservice data center vendor management pattern. Consult the source document for the official AICPA text.

Where This Lands in an Effective Security Program

Teams that pass the vendor management walkthrough cleanly on CC9.2 and CC3.2 are not the ones with the longest vendor inventories. They're the ones whose program is honest about which relationships carry real risk, tiered by data access and operational dependency, with the colocation or hosting provider treated as the load-bearing relationship it actually is. The bank, the marketing tool, and the open-source dependency get the five-minute treatment they deserve. The data center gets the top tier, the annual trust report review, the CUEC-to-control mapping, and the named owner.

Build the program once around the real dependencies. Map CC9.2 and CC3.2 onto it without restart. The same vendor management program satisfies SOC 2, ISO 27001 third-party risk management, and the supplier relationship controls in CPCSC and ITSP.10.171. Extend, don't restart. The program is the source of truth; the frameworks are lenses.

Further Reading

• SOC 2 Readiness for Bare Metal SaaS: cluster overview and what an on-prem engagement looks like end to end
• SOC 2 Network Security Controls for On-Premise Environments: the network and perimeter controls that sit on top of the colocation fabric
• SOC 2 Consultants for Canadian SaaS: the Canadian-presence consulting landing page
• SOC 2 Compliance: the Truvo service page for SOC 2 engagements

Frequently Asked Questions

What is a subservice organization in SOC 2 terms?

A subservice organization is a separate entity whose services form part of the user entity's system under audit. For a SaaS company running production infrastructure in a colocation facility or on dedicated hosting, the colocation or hosting provider is the subservice organization. The provider's physical security, environmental controls, power continuity, and facility network access materially affect whether the user entity meets its security and availability commitments, so the relationship has to be treated as in scope for vendor management under CC9.2 and risk identification under CC3.2.

Should I use the carve-out method or the inclusive method for my data center provider?

The carve-out method is the default for commercial colocation and hosting providers. The provider's controls are described in the user entity's SOC 2 report by reference and excluded from direct testing, with the user entity implementing Complementary User Entity Controls on its own side and reviewing the provider's own trust report annually. The inclusive method requires active participation from the provider in the user entity's audit and is uncommon, since commercial providers prove their controls at scale through their own published SOC 2 or CSAE 3000 report.

What are Complementary User Entity Controls and who implements them?

Complementary User Entity Controls, or CUECs, are the controls the user entity must implement on its own side to complete the picture when a subservice organization's controls are carved out. Every mature subservice SOC 2 report includes a CUEC section describing categories such as logical access, personnel change notifications for facility access, monitoring of the user entity's own workloads, incident notification to the provider, and data handling on systems the user entity controls. The user entity is responsible for implementing each CUEC and for producing evidence that it did, typically by mapping each CUEC to a control in its Security Program Manual.

What trust material should I request from a colocation or hosting provider?

At minimum: the current SOC 2 Type 2 report or its CSAE 3000-audited Canadian equivalent, a facility security walkthrough, the contractual service level commitments, change notification commitments, and a defined data handling and equipment return clause for termination. Canadian providers typically publish trust material specifically for user entity consumption. Review the report annually, produce a short memo summarizing scope, period, trust categories, and any exceptions that affect the user entity, and attach the memo to the vendor record.

How is CSAE 3000 different from SOC 2 for a Canadian colocation report?

CSAE 3000 is the Canadian assurance standard published by CPA Canada for attestation engagements, performed by CPA Canada-licensed firms. A report issued under CSAE 3000 for a Canadian colocation or hosting provider is functionally equivalent to a SOC 2 report issued under the AICPA's AT-C 205 standard for user entity purposes. The substance of the controls, the testing, and the resulting opinion serve the same role. The label on the cover is different and the practitioner firm is Canadian-licensed. Canadian user entities often prefer a CSAE 3000-audited report for Canadian infrastructure because it aligns the audit chain with Canadian professional standards.

Does my bank count as an in-scope SOC 2 vendor?

Usually not. SOC 2 vendor management under CC9.2 expects vendors to be tiered by data access and operational risk, not by invoice count. A bank processing payroll typically does not touch production systems or customer data directly, so it sits at the low end of the vendor tier and requires only a basic risk-level record rather than a full assessment. A colocation or hosting provider running production workloads sits at the opposite end and always gets the full treatment: trust report review, CUEC mapping, annual assessment, and named owner. Over-scoping the vendor list is one of the most common ways to make CC9.2 look more daunting than it is.