A vendor just sent you their SOC 2 report. It's 80 pages long, it arrived under an NDA, and the sales rep says it "proves we're secure." Your job is to decide whether that's true for the service you're actually buying.
This guide explains what a SOC 2 report is, then shows you how to read one in the right order and which red flags should stop a signature.
Here's the short answer. A SOC 2 report is an independent CPA firm's opinion on whether a service provider's controls protect the systems that hold your data. It's built on the AICPA's Trust Services Criteria: security is always in scope, and availability, processing integrity, confidentiality and privacy are optional. A Type 1 report checks the design of those controls on one date. A Type 2 report tests whether they actually worked over a period, usually several months to a year. It isn't a certificate, it doesn't expire on a set date, and it only covers what's written in its scope section. That last part is where most buyers get caught.
For Canadian buyers there's one more twist. No Canadian law requires your vendor to have a SOC 2 report, but PIPEDA, Quebec's Law 25 and, for banks and insurers, OSFI Guideline B-10 all hold you responsible for what the vendor does with your data. The report is evidence. It isn't a transfer of responsibility.
Want a second set of eyes first? Our free SOC 2 readiness assessment takes a few minutes and shows where your own controls stand, whether you're buying or being asked for a report.
What is a SOC 2 report?
A SOC 2 report is an attestation report. A licensed CPA firm examines a service organisation's description of its system and its controls against criteria published by the American Institute of Certified Public Accountants (AICPA), then signs an opinion on what it found.
Microsoft's own documentation puts the purpose plainly: SOC reports exist "so that users can assess and address the risk associated with an outsourced service" (Microsoft Learn). You're the user. The report is written for you, even though the vendor paid for it.
What does SOC 2 stand for?
SOC stands for System and Organization Controls. The "2" just identifies which report in the AICPA family you're holding. You'll still see the older name, Service Organization Control, on pre-2017 material.
What are SOC reports, and how do SOC 1, SOC 2 and SOC 3 differ?
There are three you'll meet in vendor reviews. They answer different questions.
Report | What it covers | Who it's for | How you get it |
|---|---|---|---|
SOC 1 | Controls that affect your financial reporting (payroll, billing, claims processing) | Your finance team and external auditor | On request, restricted use |
SOC 2 | Security, and optionally availability, processing integrity, confidentiality, privacy | IT, security, privacy and procurement | On request, usually under an NDA |
SOC 3 | A short, public summary of a SOC 2 examination | Anyone | Often posted on the vendor's website |
AWS is a clean example: its SOC 1 and SOC 2 reports need an NDA, while its SOC 3 is "a publicly available summary of the AWS SOC 2 report" (AWS SOC FAQs).
So if a vendor hands you a SOC 3 when you asked for a SOC 2, you've been given the brochure. A SOC 3 doesn't list the controls tested or the results. That's red flag number one, and we'll come back to it.
In Canada, the SOC 1 equivalent sits under a Canadian standard, CSAE 3416. Canadian standards don't include a SOC 2-specific standard, so Canadian CPA firms perform SOC 2-style work under the general attestation standard, CSAE 3000 (CPABC). CPA Canada publishes a non-authoritative SOC 2 guide, revised in 2024, built on that standard. Either way, the report you get looks the same.
What is a SOC audit, and who performs it?
A SOC audit (the formal term is "examination") is the work a CPA firm does to produce the report. Auditors interview staff, read policies, inspect configurations, and for a Type 2 they sample evidence across the whole period: tickets, access reviews, backup logs, terminated-user lists.
Only a licensed CPA firm can sign one. Not a security consultancy, not a compliance software platform, and not the firm that designed the vendor's controls. Independence rules stop the builder from grading its own work.
Is SOC 2 a certification?
No. There's no "SOC 2 certified" status, no certificate number and no registry. The searches for "SOC 2 certification" and "SOC 2 Type 2 certification" are real, but what they're looking for is a SOC 2 report carrying a CPA firm's opinion.
That matters when you read a vendor's website. "SOC 2 certified" with a badge and no report on request is a marketing line, not evidence. Ask for the report.
What is SOC 2 compliance, and what is its goal?
SOC 2 compliance means a service organisation runs controls that meet the AICPA's Trust Services Criteria for the categories it chose, and has a CPA firm's report saying so. The goal is simple: give customers enough evidence to trust a provider with their systems and data without auditing it themselves.
The criteria come in five categories.
Category | Required? | What it asks |
|---|---|---|
Security | Always | Are systems protected against unauthorised access and misuse? |
Availability | Optional | Is the system up and usable as committed? |
Processing integrity | Optional | Is processing complete, valid, accurate and timely? |
Confidentiality | Optional | Is information marked confidential protected as committed? |
Privacy | Optional | Is personal information collected, used, kept and disposed of as the privacy notice says? |
The criteria themselves date from 2017. The AICPA added and clarified the "points of focus" behind them in 2022 but didn't change the criteria (EY, 2022-11-02). So when people talk about "SOC 2 compliance requirements" or "AICPA SOC 2 requirements," they mean these criteria, mapped to the vendor's own controls.
Here's the bit vendors don't advertise. Each optional category is a choice, and each one adds cost. A provider can hold a clean SOC 2 report that covers security only. If you're relying on its uptime or it's handling your customers' personal information, that report says nothing about either.
What's the difference between SOC 2 Type 1 and Type 2?
Timing. That's the whole difference, and it's a big one.
- Type 1: the auditor checks whether controls are suitably designed as of a single date. Think of it as a photo.
- Type 2: the auditor checks design and tests whether the controls operated effectively across a period. Think of it as a video.
CPABC describes the same split for Canadian service organisation reports: Type 1 covers design "as of a specified date," Type 2 covers design and operating effectiveness "throughout a specified period" (CPABC). The same split applies to SOC 1, which is why "SOC 1 Type 2 vs SOC 2 Type 2" is really a SOC 1 vs SOC 2 question: same timing, different subject.
What is a SOC 2 Type 2 report?
A SOC 2 Type 2 report is the version with test results. Section 4 lists each control, what the auditor did to test it, how many samples it pulled, and whether anything failed. Mature providers run 12-month windows back to back. AWS issues its SOC 2 twice a year, each covering the previous 12 months (AWS), and Microsoft runs an October-to-September window with no gaps between periods (Microsoft Learn). A first-time report may cover a shorter window.
Is a Type 1 report ever enough?
Sometimes, for a low-risk vendor, or for a young provider that's honest about being mid-way to its first Type 2. A Type 1 proves the controls exist on paper on one day. It proves nothing about whether anyone followed them the next week. For a vendor holding sensitive or personal information, ask for the Type 2, or a dated plan for one.
Who needs SOC 2 compliance in Canada?
Nobody in Canada is legally required to hold a SOC 2 report. Customers require it, usually in procurement or contracts. If you sell software, hosting, managed IT or data processing to mid-market or enterprise buyers, expect the request.
The more useful question for a buyer is what Canadian law expects you to do with the vendor's report. Three rules do the work.
PIPEDA. Schedule 1, clause 4.1.3, says an organisation "is responsible for personal information in its possession or custody, including information that has been transferred to a third party for processing," and must use "contractual or other means to provide a comparable level of protection" (PIPEDA, Schedule 1). A vendor's report is one way to show you checked. The responsibility stays with you.
Quebec's Law 25. If you're in Quebec, section 18.3 of the private sector privacy act lets you share personal information with a service provider without consent only under a written mandate or contract that spells out confidentiality measures, limits use to the contract, and stops the provider keeping the information after it ends. The provider must also tell you about any violation, even an attempted one, and allow verification. Section 17 adds a privacy impact assessment before information leaves Quebec, including when a provider outside Quebec holds it for you (Act respecting the protection of personal information in the private sector, ss. 17 and 18.3). A SOC 2 report won't write that contract for you. It will tell you where the vendor hosts the data, which you need for the assessment. Montreal teams can see how we handle this on our Montreal page.
OSFI Guideline B-10. Banks, insurers and other federally regulated financial institutions have worked under B-10 since 2024-05-01. It lists "independent reports provided by third parties" among the ways an institution can gather assurance, and says the institution "is responsible for identifying, monitoring and managing risk arising from subcontracting arrangements" (OSFI B-10). That subcontracting line is why the carve-out section of a SOC 2 report matters so much (red flag 7 below). If you supply those institutions, B-10 reaches you through their contracts.
There's also fresh federal guidance. On 2026-09-10 the Office of the Privacy Commissioner published Guidance on assessing third-party service providers, open for comment until 2026-12-04 (OPC). It asks you to map where data flows and is stored, confirm every purpose the vendor uses it for, check subcontractors and cross-border handling, and keep monitoring after signing. It names independent audits as a monitoring tool. It doesn't mention SOC 2 by name, and a report on its own won't answer most of those questions.
That's the gap a vendor review has to close. If you'd rather not build the process yourself, our third-party risk management work does exactly this: rank your vendors, read the reports that matter, and fix the contracts at renewal.
What's inside a SOC 2 report?
Every SOC 2 report follows roughly the same five-section layout. If you've searched for a "SOC 2 report example" or "SOC 2 report template," this is the skeleton you'll find.
Section | What it is | How much attention it deserves |
|---|---|---|
1. Independent service auditor's report | The CPA firm's opinion, the report type, the period or date, and the scope | High. Two minutes, but read every line |
2. Management's assertion | The vendor's leadership stating the description is fair and controls work | Low. It's a formal statement |
3. System description | The services covered, infrastructure, locations, people, subservice organisations, user entity controls, incidents, changes | Highest. Most red flags live here |
4. Criteria, controls and tests | Each control mapped to the criteria. In a Type 2: the test performed and the result, including exceptions | High. Read every exception |
5. Other information (optional) | Management's responses to exceptions, and anything else the vendor adds | Medium. This is where you see whether they fixed it |
Section 5 is written by the vendor's management, so treat it as the vendor's side of the story.
How do you read a vendor's SOC 2 report in 30 minutes?
Don't start at page one and read forward. Read in this order. It's based on the review method SANS recommends (SANS), with the Canadian checks added.
- Opinion page (2 minutes). Note the CPA firm, the report type, the period (or date for Type 1), the categories in scope and the opinion wording. An unmodified opinion (often called unqualified) is the clean result. Qualified, adverse or a disclaimer means something went wrong and the paragraph above the opinion explains what.
- Report date vs today (1 minute). How many months since the period ended? If it's more than a few, ask for a bridge letter.
- System description scope (8 minutes). Find the exact product, service and region you're buying. If it isn't named, the report doesn't cover it. Check where data is hosted, too. You'll need that for a Law 25 assessment and for your own PIPEDA accountability record.
- Categories vs your contract (2 minutes). If your contract has an uptime commitment, availability should be in scope. If the vendor handles personal information, look for privacy or at least confidentiality.
- Subservice organisations (4 minutes). Who hosts, backs up or supports the service? Is each one "carved out" (excluded from testing) or "included"? List the carved-out ones. You'll want their reports too.
- Complementary user entity controls (4 minutes). These are controls you must run for the vendor's controls to work, such as telling the vendor when an employee leaves or turning on MFA for your own accounts. Microsoft calls them "User Entity Responsibilities" and puts them at the end of its report (Microsoft Learn). Copy them into your onboarding checklist.
- Exceptions in Section 4 (7 minutes). Search for "exception," "deviation" and "no exceptions noted." Read each exception against what it means for you.
- Management responses (2 minutes). Is there a dated fix, or just "management will consider"?
That's 30 minutes. It'll be faster the second time.
What are the red flags in a SOC 2 report?
Some exceptions are normal. Microsoft says outright that "most examinations have some observations on one or more of the specific controls examined. This outcome is expected" (Microsoft Learn). A report with zero exceptions isn't automatically better. The question is which controls failed and what was done about it.
These 12 are the ones that should slow a signature down.
# | Red flag | Why it matters | Severity |
|---|---|---|---|
1 | You were sent a SOC 3, a summary letter, or a "certificate" instead of the SOC 2 report | No controls, no tests, no exceptions to read | HIGH |
2 | Type 1 only, for a vendor that will hold sensitive or personal information | Proves design on one day, not operation over time | HIGH |
3 | Period ended a long time ago with no bridge letter | You're reading about last year's company | HIGH |
4 | Your product, module or region isn't named in the system description | The report doesn't cover what you're buying | CRITICAL |
5 | Opinion is qualified, adverse or a disclaimer | The auditor couldn't say the controls worked | CRITICAL |
6 | Exceptions on access removal, MFA, change management, backups or monitoring | These are the controls attackers and outages exploit | HIGH |
7 | The provider that actually holds your data is carved out, and you have no report for it | Your data sits with a fourth party nobody tested | HIGH |
8 | Only security in scope, but your contract relies on uptime or personal information handling | The report is silent on what you care about | MEDIUM |
9 | Long list of user entity controls you didn't know you owned | A gap on your side breaks the vendor's control | MEDIUM |
10 | Management responses are vague or undated, or Section 5 is missing when exceptions exist | No evidence the problem was fixed | MEDIUM |
11 | Significant changes or incidents disclosed in the system description (migration, acquisition, breach) | Controls tested may no longer reflect today | MEDIUM |
12 | Hosting locations outside Canada not mentioned in the contract | You can't judge comparable protection under PIPEDA 4.1.3 without it, and in Quebec it triggers a section 17 assessment | MEDIUM |
A word on bridge letters (flag 3). A bridge letter, also called a gap letter, covers the time between the end of the audited period and today. It's written by the vendor, not the auditor. Microsoft describes its own as "self-attestations by Microsoft, not reports based on examinations by the auditor" (Microsoft Learn). Accept it for a few months. Don't accept it as a substitute for next year's report.
Picture a 120-person Ottawa health-software reseller onboarding a US scheduling platform. The SOC 2 Type 2 is clean, unmodified, 12 months, no exceptions. Section 3 shows the platform carves out its hosting provider and lists one Canadian region, but only for the product tier the reseller isn't buying. The cheaper tier runs in a US region. Nothing in the report is wrong. It just doesn't describe the service on the order form. (Composite example.)
What should you do when you find a red flag?
Don't walk away by default. Write it down and ask. A good vendor answers quickly, because they've heard the questions before.
- Ask in writing, tied to the section. "Section 4, control CC6.2, two exceptions on terminated users. What changed, and when?"
- Ask for the missing reports. The bridge letter, the subservice provider's SOC 2, or the date of the next report.
- Move the answer into the contract. Breach notification timelines, audit or verification rights, subcontractor disclosure, data location and return or destruction at exit. In Quebec, section 18.3 already expects most of those terms in writing.
- Add the user entity controls to your own checklist. These are yours now.
- Record your decision. One page: report reviewed, period, exceptions, follow-ups, residual risk, who accepted it. That's the record PIPEDA's accountability principle and OSFI B-10 expect you to be able to show.
- Set a reminder for when the next report is due.
Picture a Toronto credit union's IT lead reviewing a managed backup provider. Two exceptions on restore testing, with a management response that says "process improved" and no date. The lead asks for evidence of the last two successful restores and adds quarterly restore reports to the renewal. The vendor sends them within a week. (Composite example.)
Not sure whether a finding is a deal-breaker? Bring us the report and the contract, and a senior engineer will tell you which flags matter for your risk. We cover Toronto and Ottawa as well as Montreal.
Is a SOC 2 report enough for a vendor review?
For a low-risk tool, a clean, current Type 2 that names the right service is usually enough. For a critical vendor, it's the starting point. A SOC 2 report won't tell you whether the vendor uses your data to train its own models, how fast it will tell you about a breach, or whether you can get your data back in a usable format when you leave. The OPC's 2026 guidance asks about all three. Your contract and your follow-up questions have to cover them.
It also doesn't cover PIPEDA or Law 25 compliance as such. Even the privacy category measures the vendor against its own privacy notice and the AICPA criteria, not against Canadian law. If privacy is the main risk, pair the report with a privacy impact assessment.
How do you get a SOC 2 Type 2 report for your own company?
If you're on the other side of the table, here's the short version of a SOC 2 compliance checklist.
- Read the request. Find out which categories and which report type the customer asked for, in writing. Many ask for security only.
- Scope it down. Define the system: which product, which environments, which providers.
- Run a gap assessment against the Trust Services Criteria in scope.
- Close the gaps and start producing evidence. Access reviews on a schedule, tickets for changes, offboarding that closes every account, logs kept as long as your policy says.
- Consider a Type 1 to unblock a deal while the Type 2 window runs.
- Pick a CPA firm and agree the period. Then run the window without gaps.
- Plan for next year. A SOC 2 is a yearly habit, not a one-off project.
We do the readiness part (scoping, gap list, evidence) and hand you to an independent CPA firm for the examination, because the firm that builds your controls can't be the one that grades them. See how our SOC 2 compliance work runs.
Common questions about SOC 2 reports
How long is a SOC 2 report valid?
There's no expiry date in the standard. In practice buyers expect a report whose period ended within roughly the last 12 months, plus a bridge letter for the time since. Large providers run back-to-back 12-month periods so there's never a gap.
Can I share a vendor's SOC 2 report with someone else?
Usually not. SOC 2 reports are restricted-use and normally shared under an NDA, as AWS does (AWS). If your own auditor or a customer needs to see it, ask the vendor first. The SOC 3 is the version made for sharing.
Is SOC 2 better than ISO 27001?
Neither is better. They're different instruments. ISO 27001 certifies a management system and comes with a certificate. A SOC 2 report gives an opinion on specific controls, and a Type 2 shows test results you can read. Many providers hold both, because different customers ask for different ones. If you're weighing which to pursue, our ISO 27001 page covers the other half.
How much does a SOC 2 audit cost in Canada?
We couldn't find a published Canadian fee schedule. CPA Canada and the provincial CPA bodies don't publish one, and the ranges you'll see online are US-dollar figures from compliance software vendors. What drives the price: the number of categories in scope, the size of the system, Type 1 vs Type 2, and how ready your evidence is. Remediation usually costs more than the examination.
Does a SOC 2 report prove PIPEDA compliance?
No. It's useful evidence for PIPEDA's accountability principle, but it doesn't test against Canadian privacy law. Our PIPEDA page covers what the law itself asks for.
Bottom line
A SOC 2 report is the best single document a vendor can hand you, and it's only as good as the 30 minutes you spend reading it. Start at the opinion, check the date, then live in the system description and the exceptions. Write down what you find, ask the follow-up questions, and move the answers into the contract.
Canadian law makes the vendor review your job, not the vendor's. Done properly, the report makes that job much smaller.
Have a vendor's report on your desk right now? Talk to a senior engineer and we'll read it with you.
