Quick Answer: SOC 2 is an auditing framework developed by the American Institute of Certified Public Accountants (AICPA) that evaluates how a service organisation handles customer data across up to five security and operational criteria. It is not a certification with a pass or fail grade. It is an auditor's opinion, and that distinction matters more than most buyers realise when they are handed a report and asked to accept it as proof of security.
Every vendor in the infrastructure space claims to be "SOC 2 compliant." It appears on websites, in RFP responses, and in sales decks as though it settles the question of whether a provider is secure. The problem is that most buyers do not know what they are actually looking at when the report lands in their inbox.
What criteria were in scope? Was it a Type I or a Type II? When was the observation period? Are there exceptions buried in the testing results? These are the questions that separate a meaningful compliance review from a checkbox exercise. And vendors do not go out of their way to explain the difference.
This article talks about SOC 2, how it works, and what to look for when you are evaluating a data centre or infrastructure provider that holds one.
SOC 2 stands for System and Organisation Controls 2. It is an auditing standard developed and maintained by the AICPA, the same body that governs accounting and assurance standards in the United States and, by adoption, Canada through the CSAE framework.
The standard was designed specifically for service organisations, cloud providers, data centres, managed service providers, and SaaS platforms that store, process, or transmit customer data on behalf of other businesses.
Where most people go wrong is treating it like a certification. There is no SOC 2 badge that gets awarded when a company meets a minimum threshold. The output is an audit report, and at the centre of that report is an opinion issued by a licensed CPA firm.
That opinion can be clean, it can contain exceptions, or it can be adverse. The nature of that opinion, and what sits behind it, is what a buyer actually needs to evaluate.
The AICPA defines four possible opinion types in a SOC 2 report.
Most vendors will tell you they "passed their SOC 2." That is not a standard term, and it obscures what the report actually says. A qualified report is not the same as a failed report. Exceptions can be minor, well-documented, and already remediated.
The only way to know is to read the testing results section of the report, not just the opinion letter on the cover page. Accepting a vendor's summary of their own compliance status without reviewing the report is where procurement teams leave real risk on the table.
The SOC 2 framework is built on five Trust Services Criteria defined by the AICPA. Security is the only required criterion. The other four are optional and included based on the nature of the service being provided and what customers require.
This matters when evaluating vendors.
A data centre or cloud provider may hold a SOC 2 report that only covers the Security criterion. That tells you their controls around preventing unauthorised access to systems were audited. It says nothing about whether their Availability controls were tested, which for a data centre, is arguably just as relevant.
When requesting a SOC 2 report from any infrastructure partner, ask which specific criteria were included in scope before drawing conclusions about what the report actually covers.
The Type I and Type II distinction is where a lot of business execs have ambiguity, and it is a distinction that significantly changes how much weight you should give a vendor's report.
A Type I report is a point-in-time assessment. The auditor evaluates whether the controls described by the service organisation were suitably designed as of a specific date.
Think of it as: on the day of the audit, the right policies and procedures were in place and appeared to be appropriately structured. Type I is a legitimate starting point for organisations that are new to the SOC 2 process, but it provides limited assurance for a buyer.
It does not tell you whether those controls were actually followed in practice, day in and day out.
A Type II audit evaluates whether controls operated effectively over a defined period, typically six to twelve months. It requires consistent evidence across that entire window, including log retention, access reviews, and incident records.
This is meaningfully harder to achieve than a Type I because it requires a service organisation to demonstrate operational consistency, not just good design.
If you’re looking for a colocation provider or managed services partner, Type II is the standard to ask for. A Type I report from a vendor who has held that status for two years is worth far less than a Type II covering a twelve-month observation period.
When reviewing any report, check the audit period dates. SOC 2 reports are valid for twelve months, meaning a renewal audit must be completed within that window to maintain the current compliance status. A report that is fifteen months old is, for all practical purposes, stale.
These two frameworks are frequently conflated, and vendors who hold both do not always explain the difference. A data centre handing you a SOC 1 report when you asked about data security is not answering the question you asked.
SOC 1 was designed to evaluate internal controls over financial reporting (ICFR). It is relevant for organisations that process transactions or data that could affect a customer's financial statements: payroll processors, financial SaaS platforms, transfer agents, and similar services.
In Canada, the applicable standard is CSAE 3416; in the U.S., it is SSAE 18. The audit covers things like transaction processing accuracy, financial data integrity, and access controls over systems that feed into financial reporting.
If a data centre holds SOC 1, it reflects something specific about the financial control environment of that facility. It says nothing, on its own, about how they manage your operational or security controls.
SOC 2 is what governs how a service organisation protects and manages customer data operationally. This is the report that evaluates physical security, logical access controls, incident response, encryption, change management, and system availability.
It is the relevant framework for cloud providers, data centres, managed IT service providers, and any organisation that holds or processes customer data in an ongoing operational capacity.
Holding SOC 1 and SOC 2 is not redundant. They cover different audit surfaces and both can be relevant depending on the services being provided and the regulatory environment of the customer.
Receiving a SOC 2 report and accepting it at face value is not a compliance review. The opinion letter on the front page is the conclusion, not the evidence. A data centre's SOC 2 report contains several sections that carry far more information than the summary, and buyers who know where to look are in a much stronger position when making infrastructure decisions.
The scope section of a SOC 2 report defines exactly which systems, services, and physical locations were included in the audit. This is the easiest place to identify gaps.
A provider operating multiple facilities may have only submitted one or two of them for audit. The independent auditor's report describes the scope of the examination, and the auditor may also explicitly describe things that were not tested.
For example, the scope of the audit may not include an examination of a specific component of the environment, in which case the auditor will state their assumption about that component. Match the scope directly against the specific facility or service you are deploying in. If your workload is going into a facility that was not included in the audit scope, the report does not cover you.
The system description section outlines what the data centre asserts their controls to be. Auditors test against this description, which means if a control is not listed here, it is not being tested.
For a data centre, look specifically for how they describe physical access controls, power redundancy procedures, cooling systems, incident response protocols, and logical access management for operations staff. Vague descriptions in this section are a signal worth probing further in conversation with the provider.
A description that says "access is restricted to authorised personnel" without describing how that access is provisioned, reviewed, and revoked is not giving you much to work with.
The testing results section is where exceptions are documented, and this is the section most buyers skip entirely. Read every exception. Note what the control was, when it failed, and whether the provider included a management response.
A single exception in an access review process is very different from repeated exceptions in physical security procedures. The nature of what failed matters as much as the fact that something did.
Complementary User Entity Controls, or CUECs, are controls that reside at the customer's level and must be implemented by the customer for the service organisation's control environment to function as described.
In a data centre context, CUECs might specify that the customer is responsible for managing their own logical access credentials, maintaining their own encryption for data in transit, or notifying the provider when personnel access needs to be modified or revoked.
If these controls do not operate effectively at the customer level, control failures can still occur even when the data center's own controls are performing as described. CUECs are not optional reading. They define where the data centre's responsibility ends and yours begins.
Most organisations pursuing SOC 2 underestimate the preparation required to get there. Buyers evaluating vendors benefit from knowing what a rigorous audit requires because it helps them ask better questions and spot shortcuts.
The audit is not a documentation review. Auditors are testing whether controls were actually followed, consistently, with evidence across the entire observation period. The most common audit failures are not missing tools or wrong technology choices.
Documentation gaps show up in the form of access reviews that were scheduled monthly but only happened twice, incident logs with gaps, and change management approvals that were not recorded at the time they occurred.
For a data centre specifically, the control areas that carry the most weight are:
For a first SOC 2 audit, most organisations can expect a total timeline of six to twelve months. A Type I audit typically takes three to six months from initial preparation through to the issued report. A Type II audit requires an observation window of six to twelve months before the audit phase even begins, meaning the total timeline from kickoff to issued report is considerably longer.
Organisations with mature controls and clean documentation move faster. Those with gaps spend the first several months in remediation before the observation window can begin.
There is no simple answer to the costs associated with a SOC 2 audit. There are several distinct cost categories, and conflating the audit fee with the total compliance cost is where most first-time estimates go wrong.
P.S. All the prices mentioned here are in USD.
The total all-in cost for a first-year Type II audit, across all of the above categories, typically lands between $30,000 and $80,000 for a small to mid-sized organisation.
Larger or more complex organisations, those adding multiple Trust Services Criteria beyond Security, or those engaging Big Four firms can see total costs well above $200,000. Annual renewal costs, covering ongoing tooling, monitoring, and the renewal audit itself, typically run $10,000 to $40,000 for organisations with mature, well-documented controls.
When evaluating a data centre partner, compliance documentation is either readily available or it is not.
At Qu Data Centres, SOC 1 and SOC 2 reports are part of a broader certification framework that includes ISO 27001, PCI DSS, HIPAA, CSAE/ISAE standards, and Uptime Institute Tier III certification across multiple facilities. These are not marketing claims. They are independently audited, annually renewed, and available for review as part of any procurement process.
For organisations in regulated industries, that breadth of documentation matters. A financial institution, healthcare provider, or government agency cannot afford to deploy into a facility that holds only a narrow SOC 2 scoped to one criterion and one building.
The certification portfolio needs to match the compliance requirements of the workload. Qu's facilities across Calgary, Edmonton, Ottawa, Toronto, and London, Ontario have been running mission-critical workloads for Canadian enterprises for decades, with the audit history to back it up.
If your team is conducting a compliance review and you want to see the documentation before the conversation goes further, reach out to Qu Data Centres. The reports are there. The answers are straightforward.
SOC 2 stands for System and Organisation Controls 2. It is an auditing standard developed by the American Institute of Certified Public Accountants (AICPA) that evaluates how service organisations manage customer data across up to five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.
SOC 2 Type II is an audit that evaluates whether a service organisation's controls operated effectively over a defined period, typically six to twelve months. Unlike a Type I audit, which only confirms controls were designed correctly at a single point in time, Type II requires consistent evidence across the entire observation window. It is the standard most enterprise buyers should require from infrastructure partners.
A qualified opinion in a SOC 2 report means the auditor identified one or more exceptions. These areas where controls did not operate as described during the audit period. It does not mean the vendor failed their audit outright. The significance of a qualified report depends entirely on what the exceptions were, how material they are to your specific workload, and whether the provider has documented a remediation response.
A SOC 2 Type I audit typically takes three to six months from initial preparation through to the issued report. A Type II audit takes six to twelve months because it requires an observation period during which auditors collect evidence of controls operating over time. Organisations with mature documentation and established controls generally move through the process faster than those starting from scratch.
Base audit fees for a Type I typically range from $5,000 to $20,000. A Type II audit generally costs between $20,000 and $50,000 in audit fees alone. Readiness preparation, compliance tooling, and internal staff time add to the total. Larger or more complex organisations, and those including additional Trust Services Criteria beyond Security, can expect costs at the higher end or above those ranges.
SOC 2 reports are valid for twelve months from the date of issuance. Most organisations schedule an annual renewal audit to maintain continuous compliance coverage. Enterprise customers and regulated buyers typically require a current report, meaning one issued within the past twelve months, as a condition of vendor approval.