How to Achieve SOC 2 Compliance: From Scope to Audit Report

Quick Answer: SOC 2 compliance is earned through an independent audit conducted by a licensed CPA firm that evaluates your organisation's controls against the AICPA's Trust Services Criteria. The path to getting there involves selecting which criteria apply to your operations, writing a formal system description, implementing controls and running them consistently through an observation period, and submitting to a formal audit. For most enterprise IT buyers, a Type 2 report is what procurement teams require, and the full process realistically takes nine to eighteen months from initial readiness assessment to issued report.

Key Takeaways

• OC 2 compliance requires an independent audit by a licensed Certified Public Accountant firm against the American Institute of Certified Public Accountants’ Trust Services Criteria.
• Security is mandatory for every SOC 2 engagement, while Availability, Processing Integrity, Confidentiality, and Privacy are selected based on customer and service requirements.
• Type 1 reports assess control design at a point in time, while Type 2 reports test control effectiveness over a six-to-twelve-month observation period.
• Organisations should define scope, write the system description, run controls consistently, and build evidence collection into daily operations before the Type 2 audit.
• Hosting infrastructure affects SOC 2 scope because physical access, environmental controls, power redundancy, connectivity, and facility security may be reviewed.
• Qu Data Centres operates nine Canadian facilities certified to SOC 1, SOC 2, ISO 27001, PCI DSS, and HIPAA standards, including four Tier III sites.
• Book a facility tour and see how Qu Data Centres provides independently validated infrastructure that supports your SOC 2 audit posture from day one.

When a prospective enterprise customer asks for your SOC 2 report for the first time, the clock starts ticking on a process that most organisations underestimate. The report they're asking for is not a certification you apply for and receive. It is the output of an independent audit that evaluates how well your controls protect customer data over a defined period of time, and it can take over a year to produce if you are starting from scratch.

Most guidance available on this topic is written for SaaS startups working through their first audit. Enterprise IT leaders face a different set of questions. Which Trust Services Criteria apply to your operations? When should you start the observation window? How does your hosting environment factor into what your auditor will test? How do scope decisions made early in the process affect your audit timeline and cost months down the line?

Here are all the answers most firms need when looking into a SOC 2 compliance.

What SOC 2 Compliance Requires From Your Organisation

SOC 2 is a voluntary compliance framework developed by the American Institute of Certified Public Accountants (AICPA) to assess how a service company protects customer data. Unlike many compliance standards, it does not prescribe a fixed list of controls. Instead, it defines five Trust Services Criteria that organisations use as the basis for designing their own control environment.

What constitutes compliance for one organisation may look very different from another's program, even within the same industry, because the framework is built around principles rather than prescriptions.

SOC 2 has become a procurement baseline across regulated industries in Canada and internationally. According to IBM's 2024 Cost of a Data Breach Report, the global average breach cost reached USD 4.88 million in 2024, a ten percent jump over the prior year. That figure has made security attestation a non-negotiable for enterprise buyers, and SOC 2 is the most widely requested report in North American vendor assessments.

The Five Trust Services Criteria Explained

The five Trust Services Criteria are the categories from which organisations build their SOC 2 control environment. Security is the only mandatory criterion. The others are selected based on what is relevant to your services and what your customers are asking for in their procurement requirements.

• Security: Protection of systems against unauthorised access, both internal and external. This criterion is required in every SOC 2 engagement and covers access controls, threat monitoring, and incident response procedures.
• Availability: System uptime and performance in line with what the business has committed to in service agreements. Relevant for any organisation with defined uptime SLAs.
• Processing Integrity: Whether data is processed completely, accurately, and on time. Applies to organisations where the accuracy of data processing is central to the service delivered.
• Confidentiality: Controls over how confidential information is collected, used, retained, and disposed of. Broadly applicable to companies handling proprietary or sensitive client data.
• Privacy: How personal information is collected, used, retained, and disclosed in line with applicable privacy commitments. Particularly relevant for Canadian organisations in regulated sectors subject to PIPEDA and provincial equivalents.

SOC 2 Type 1 Vs. Type 2: Knowing Which Report You Need

Type 1 and Type 2 reports evaluate the same controls but at fundamentally different levels of rigour. A Type 1 report is a point-in-time assessment. It documents that your controls are designed appropriately as of the audit date but does not assess whether those controls have been operating consistently over a period of time.

A Type 2 report is what enterprise procurement teams, CISOs, and compliance officers are asking for. It covers a defined observation period, typically six to twelve months, and assesses both the design and operating effectiveness of your controls throughout that window. Any exceptions found during a Type 2 audit appear in the final customer-visible report. That is precisely why the sequence and timing of how you enter the observation window matters more than most guides acknowledge.

How the SOC 2 Process Works, and Where Most Orgs Misread It

The SOC 2 process is not as linear as most people think. There are decision points early on that have disproportionate consequences later, and most first-time programs misread the sequence because they are focused on the audit at the end rather than the control environment they need to build and sustain to get there cleanly.

1. Pick Your Trust Services Criteria Based on What Customers Require (Not What Sounds Thorough)

The first real decision in a SOC 2 program is not what controls to implement. It is which criteria to include in scope, and this decision is made before any controls are built. It also has a direct financial and operational impact on every step that follows.

Security is mandatory. Beyond that, the right question is not what sounds thorough, but what your customers are specifying in their procurement questionnaires and vendor assessment forms.

Enterprise buyers typically state which criteria they need attested and whether they require a Type 1 or Type 2 report. Adding Availability, Processing Integrity, Confidentiality, or Privacy to your audit without a specific, customer-driven reason for each adds controls to implement, evidence to collect, and time to the audit engagement.

Every additional criterion carries an extra cost as well.

2. Write the System Description Before You Build Any Controls

The system description is one of the most underestimated requirements in a SOC 2 engagement.

Before an auditor can issue a report, management must provide a formal written assertion confirming that the system description is accurate. That document needs to cover what the system does, the infrastructure it runs on, the data it processes, the boundaries of the audit scope, and how each control addresses the applicable criteria.

Most organisations notice the lack of formal documentation of their systems during the description phase. Controls may exist, but the written description of those controls, the boundaries they apply to, and the infrastructure they depend on has never been formally captured.

Building controls before this document exists means you may design the wrong controls for the wrong scope. Writing the system description first forces the kind of clarity that prevents expensive rework later in the process.

3. Use a Type 1 Report as a Control Checkpoint Before the Observation Window Opens

A common misconception about Type 1 reports is that they are a stepping stone for organisations that cannot yet achieve Type 2. In practice, they are most valuable as a private checkpoint before the Type 2 clock starts.

Exceptions identified during a Type 1 audit are not included in a customer-visible report. Your auditor can tell you where controls are inadequately designed, where the system description does not match operational reality, and where you will encounter problems if the Type 2 observation window opens now.

That feedback, received privately, gives you the opportunity to fix design gaps before they become reportable. Exceptions found during a Type 2 audit go into the report your enterprise customers and their legal teams read. The Type 1 engagement is the checkpoint that keeps those exceptions off the page.

4. Start the Observation Window Only When Controls Are Running Consistently

The Type 2 observation period evaluates your controls for the entirety of its duration, typically six to twelve months. This is where most first-time programs face avoidable trouble.

Organisations start the observation window before controls are fully operational, before access reviews are running on schedule, before system logging is being consistently retained, or before change management procedures are being followed end-to-end.

Any gap in control operation during the observation window creates an exception. Those exceptions appear in the Type 2 report and must be explained to readers. Starting the window before operational readiness does not save time. It lengthens the remediation cycle and weakens the final report. Waiting until controls are genuinely running consistently, even if that delays the start by an additional few weeks, produces a meaningfully cleaner result.

5. Build Evidence Into Daily Operations, Not a Pre-Audit Sprint

Evidence collection for a Type 2 audit cannot be assembled in the weeks before the auditor arrives. The audit covers the entire observation period. Access review logs from eight months ago that were not retained cannot be produced now. Patch management documentation that was not created at the time patches were applied does not exist retroactively.

Every control that will be tested in the audit needs to generate evidence continuously throughout the observation window. That means treating evidence generation as an operational function built into standard workflow, through documentation practices, logging configurations, and scheduled review cycles. Teams that build this discipline in from the start of the observation window tend to produce cleaner audit results and spend considerably less time on reactive evidence gathering in the final weeks.

How Your Hosting Infrastructure Affects SOC 2 Scope

One of the least-discussed dimensions of SOC 2 compliance is how the infrastructure environment where your systems run affects your audit scope.

When an organisation hosts workloads in a third-party data centre, the audit does not stop at the software layer. It extends into the physical and environmental controls of the facility where that infrastructure operates. Getting this right is a scope decision, and it is one most organisations make far too late in the process.

This matters because it determines what your organisation needs to independently evidence and what can be addressed through your infrastructure provider's own SOC 2 reports. Colocation customers can reference their data centre provider's independently audited control environment for facility-layer controls, which meaningfully reduces both the depth of your own control documentation and the testing your auditor needs to perform.

Qu Data Centres operates nine carrier-neutral facilities across Calgary, Edmonton, Ottawa, Toronto, and London, Ontario, each independently certified to SOC 1, SOC 2, and ISO 27001 standards. For organisations hosting within Qu's facilities, the physical access controls, power redundancy, environmental monitoring, fire suppression systems, and facility security posture are already covered by Qu's own independently audited control environment.

What a SOC 2-Certified Colocation Provider Covers on Your Behalf

A SOC 2-certified colocation provider brings independently validated controls to several areas that would otherwise fall entirely to your organisation to design, implement, and evidence throughout the observation period:

• Physical Access Controls: Mantraps, biometric two-factor authentication, individually locked cabinets, and 24/7 manned security monitoring are controls your auditor would otherwise require you to document and test independently.
• Environmental and Power Controls: Redundant power feeds, UPS systems, generator backup with on-site fuel, and N+1 cooling configurations all address facility availability controls that appear under the Availability Trust Services Criterion.
• Network and Connectivity: Carrier-neutral facilities with physically isolated carrier interconnect rooms and diverse fibre routing support evidence of network security and availability controls across multiple providers.
• Certifications as Audit Evidence: A data centre's SOC 2 report, ISO 27001 certification, and Uptime Institute Tier III certification can serve as evidence of the facility's control environment, reducing the testing depth your auditor needs to perform on those controls independently.

Inherited Controls and the Shared Responsibility Model in Colocation

The shared responsibility model in colocation defines which controls belong to the data centre and which belong to the organisation hosting there. The data centre owns the physical, environmental, and facility-layer controls. The organisation owns the logical security layer: access provisioning, encryption, application-level controls, and data governance practices.

This is meaningfully different from hosting in a hyperscale public cloud environment, where the shared responsibility boundary is defined by the cloud provider's contract and can be harder to map directly to your SOC 2 control objectives. In colocation, the boundaries are clearer.

Your auditor reviews the data centre's SOC 2 report for facility-layer controls and concentrates independent testing on your logical and operational layer. That clarity tends to produce a more efficient audit engagement and a cleaner evidence package. For organisations evaluating virtual private cloud or interconnection options alongside colocation, how each hosting model maps to your SOC 2 control boundary is an early-stage planning decision, not an afterthought.

Why Qu Data Centres Keeps Enterprise IT Teams Audit-Ready

Enterprise organisations need infrastructure that holds up under auditor scrutiny year after year, not just when the report is due. Qu Data Centres operates nine purpose-built facilities across five Canadian markets, each independently certified to SOC 1, SOC 2, ISO 27001, PCI DSS, and HIPAA standards. Four of those facilities carry Uptime Institute Tier III certification, one of the highest concentrations of independently certified Tier III data centres in Canada.

The operational depth behind those certifications matters as much as the certifications themselves. Qu's facilities are staffed and monitored 24/7 by more than 130 Canadian employees, many with fifteen to twenty years of tenure at these specific sites.

For organisations that host within Qu's infrastructure and access managed services, the physical and operational control layer of their SOC 2 environment is already independently validated. That is not a compliance add-on. It is infrastructure built and operated to enterprise standards for decades, with an audit history to prove it.

Whether you are hosting in Toronto, Calgary, Edmonton, Ottawa, or London, Ontario, you are entering your SOC 2 engagement with a physical and environmental control layer that has already been tested. Book a facility tour and see the infrastructure your audit posture rests on.

Frequently Asked Questions About SOC 2 Compliance

How Long Does It Take to Get SOC 2 Certified?

Achieving a SOC 2 Type 2 report typically takes nine to eighteen months from initial readiness assessment to issued report. The observation period alone runs six to twelve months, and the time required to implement controls before the window opens depends on your current security posture. Organisations with a mature security program can compress the preparation timeline, but the observation period itself cannot be shortened without affecting the scope of the report.

What Is the Difference Between SOC 1 and SOC 2?

SOC 1 evaluates controls relevant to financial reporting, making it applicable to organisations that process data affecting client financial statements. SOC 2 evaluates controls relevant to security, availability, processing integrity, confidentiality, and privacy. Most enterprise software providers and data centre operators pursue SOC 2, while payroll processors and financial transaction handlers are more likely to require SOC 1 in addition to or instead of SOC 2.

Is SOC 2 a Legal Requirement in Canada?

SOC 2 is not a legal requirement in Canada. It is a voluntary framework that enterprise buyers frequently require of their vendors through contract terms and procurement processes. It complements Canadian legal obligations under PIPEDA but does not replace them. Canadian organisations in regulated industries may need both a clean SOC 2 report and demonstrable PIPEDA compliance to satisfy their enterprise customers and the regulatory expectations of their sector.

What Happens When a SOC 2 Audit Finds Exceptions?

SOC 2 audits do not result in a binary pass or fail. An auditor issues a qualified or unqualified opinion. An unqualified opinion is the goal, meaning no material exceptions were identified. When exceptions are found, they are documented in the report with a description of what was tested, what was expected, and what the auditor observed. Significant exceptions can affect how enterprise customers interpret the report and may delay contract decisions while remediation is completed and retested.

Can a Colocation Provider Help With SOC 2 Compliance?

A SOC 2-certified colocation provider contributes to your compliance posture by independently validating the physical, environmental, and facility-layer controls that would otherwise fall within your audit scope. Their SOC 2 report can be referenced in your audit to address facility controls without requiring your auditor to independently test them, reducing the testing depth required at the infrastructure layer. Your organisation remains fully responsible for the logical and operational controls governing your systems.

How Much Does a SOC 2 Audit Cost?

SOC 2 audit costs vary based on the size of the organisation, the number of Trust Services Criteria in scope, and the audit firm selected. For a mid-sized enterprise, a Type 2 audit typically ranges from CAD $30,000 to $100,000 in direct audit fees, with additional internal preparation costs. Organisations that invest in readiness work before the observation window opens tend to spend less on audit fees overall, since fewer exceptions mean less remediation and less follow-up testing required during the engagement.

Sources Used for This Article

• AICPA: "SOC 2® Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy" - us.aicpa.org/interestareas/frc/assuranceadvisoryservices/aicpasoc2report.html
• IBM Newsroom: "IBM Report: Escalating Data Breach Disruption Pushes Costs to New Highs" - newsroom.ibm.com/2024-07-30-ibm-report-escalating-data-breach-disruption-pushes-costs-to-new-highs
• CIRA: "2025 CIRA Cybersecurity Survey" - cira.ca/en/resources/documents/cybersecurity/2025-cybersecurity-survey/
• Government of Canada / Office of the Privacy Commissioner: "The Personal Information Protection and Electronic Documents Act (PIPEDA)" - priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/