SOC 2 Type 1 vs Type 2: What Canadian Buyers Accept

Your security questionnaire came back with one line on it. Send us your SOC 2 report. Then the quote from a CPA firm lands with two options on it, and the SOC 2 Type 1 vs Type 2 decision is suddenly yours to make, before you have scoped a system or run a single access review.

Most Canadian founders meet these two reports the same way. Somebody in procurement asks for "the SOC 2", a signature is waiting on it, and the choice looks like a ladder where Type 1 is the beginner version and Type 2 is the grown up one. It is not a ladder. It is a decision about what your auditor is allowed to say about you, and about which of your buyers will accept that answer.

The difference is time, not seniority

Here is the part people get wrong. Both reports come out of the same examination, against the same criteria, from the same kind of firm. What separates them is the window.

The Canadian Centre for Cyber Security states it plainly in ITSP.50.105, its guidance on cloud security assessment and authorization (May 2020): a Type 1 report is an attestation of controls at a specific point in time, while a Type 2 report provides an attestation of controls over a minimum period of six months. The same guidance notes that both reports carry an opinion on whether management's description of the system is fairly presented, and on whether the controls are suitably designed to meet the applicable trust services criteria. A Type 2 adds one more opinion on top: whether those controls were operating effectively.

That one extra opinion is the entire argument. A Type 1 says your controls were designed properly on a date. A Type 2 says they actually ran, and the auditor went and checked.

Neither report certifies you

Before anything else, a correction that saves a lot of embarrassment in a sales call. There is no such thing as being "SOC 2 certified". The Cyber Centre's guidance says it directly: SOC 1 and SOC 2 reports are not a certification, they are an auditor's opinion on a service organization's internal controls and security practices.

Being straight about our own role here. We are not an auditor, we do not issue reports, and no software product can hand you a SOC 2. A CPA firm performs the examination and signs the opinion, and it should stay that way. What we build is the system that has your evidence in order long before that firm opens a sample.

The Canadian layer almost nobody explains

Here is where most of the writing on this topic, all of it American, quietly misleads Canadian readers.

A SOC 2 issued by a Canadian firm is not performed under American standards. FRAS Canada's non-authoritative guidance on SOC engagements sets out the map: SOC engagements are attestation engagements, so Canadian Standard on Assurance Engagements (CSAE) 3000 applies, and that standard was issued by the Auditing and Assurance Standards Board in July 2015 and took effect for reports dated on or after June 30, 2017. For a SOC 2 specifically, the same guidance lists the applicable criteria as the AICPA's TSP Section 100 trust services criteria and DC Section 200 description criteria. Canadian standard, American criteria, one report.

Two details in that document matter to you as a seller. SOC engagements do not permit the issuance of limited assurance reports, so the reasonable assurance requirements are the only ones in play. And SOC engagements cannot be performed as direct engagements, which is the formal way of saying your management has to make its own statement about the system rather than leaving the description to the auditor. You write the description. You sign it. That is true of a Type 1 and a Type 2 alike.

CPA Canada publishes its own SOC 2 guide, adapted from the AICPA's 2022 version to meet Canadian standards and revised in 2024. Its contents page is quietly useful for this exact question: it lists understanding the difference between a type 1 and type 2 SOC 2 report as a topic in its own right, and it ships two separate illustrative management representation letters, one for a type 2 engagement and one for a type 1. Different letters mean different promises. The paperwork you sign is not the same in the two cases.

If your buyers are split across Canada and the United States, tell your auditor early. The FRAS Canada guidance is written for exactly that case, where a report has to satisfy both CSAE 3000 and the AICPA's AT-C sections 105 and 205, and it is a scoping conversation, not an afterthought.

Which one your buyer will actually take

This is where the choice gets settled, and it is not settled by you.

If you sell cloud software into the federal government, the answer is already written down. The Cyber Centre's cloud service provider assessment process, ITSM.50.100 (October 2018), lists the attestation standards that have been compared against the ITSG-33 security controls, and the SOC entry on that list is AICPA SOC 2 Type II reports. Not SOC 2 generally. Type II. ITSP.50.105 goes further and recommends a SOC 2 type 2 report for cloud services because of the higher level of assurance it gives, and tells departments to request reports covering security, availability, processing integrity and confidentiality, adding privacy where they have privacy requirements.

So for that buyer, a Type 1 is not a finish line. It is a progress report.

Commercial enterprise buyers are more flexible, and this is where a Type 1 earns its keep. A large customer that wants to sign this quarter will often accept a Type 1 now with a committed Type 2 window, because it gives their vendor risk team something signed by a CPA firm to put in the file. That is a legitimate use of a Type 1, and it is very different from treating it as the destination.

The practical read: ask the buyer which one clears their review before you buy anything. One email saves you a report.

What actually changes inside your company

The gap between these two reports is not a form. It is several months of your team behaving consistently while somebody counts.

In a Type 1, you show that the control exists and is designed sensibly on the date the auditor looks. In a Type 2, the auditor samples across the window and finds out whether the quarterly access review really happened in the quarter you said it did, whether the offboarding ticket was closed the week the person left, whether the change was approved before it shipped. The report reflects that. ITSP.50.105's breakdown of a SOC 2 report describes five sections, and the one that carries the testing and results from the service auditor sits alongside your own description of the system.

That guidance also tells buyers to look for complementary user entity controls in your report, which are the controls the report says your customer has to operate at their end. Those show up in negotiation. Read yours before your customer does.

The failure mode we see most is not a missing control. It is a control that exists and cannot be evidenced. Nobody can produce the ticket, the export, the approval or the dated record without three people and a week. That is the gap, and it is the same gap whether you picked Type 1 or Type 2. The only difference is that a Type 2 finds it for you, in front of an auditor, across months rather than on one convenient morning.

How to decide this week

Ask the deal that triggered all of this which report clears their review, and by when. Ask the CPA firm what observation window they would sign and what they need in place before it opens. Then look honestly at whether your team could produce a full quarter of access reviews, change approvals and onboarding records today, from one place, without a heroic effort. If the answer is no, that is your real starting point, and it does not change based on which report you order.

If you want the version of this you can work through with your team, our SOC 2 and ISO 27001 Readiness Checklist covers what enterprise buyers check before they sign, in plain language, and the same evidence carries both frameworks. Our SOC 2 compliance page covers the scoping and timeline side, and if you would rather have someone read your situation back to you, book a gap review.

One more thing worth knowing before you scope. If your product has anything AI facing in it, the SOC 2 will not answer the AI questions your buyers are now attaching to the same review, because the trust services criteria were not written for models. That is a separate evidence problem, and we cover it on SecuritAI's Canadian AI governance page.

Frequently asked questions

Is SOC 2 Type 2 better than Type 1?

It carries more assurance, because it includes an opinion on whether your controls operated effectively over a period rather than only on whether they were designed properly at a point in time. Whether it is better for you depends on the buyer in front of you. The Cyber Centre recommends type 2 reports for cloud services in ITSP.50.105, and federal cloud assessments compare AICPA SOC 2 Type II reports against ITSG-33.

Do I have to do a Type 1 before a Type 2?

No. Nothing in the standards requires it. Many companies go straight to a Type 2 when no deal is waiting, because it avoids paying for two examinations. A Type 1 makes sense when a specific customer will accept it now and you need the signature this quarter.

How long does the Type 2 observation window have to be?

You and the CPA firm agree it. For context on what Canadian federal buyers expect, ITSP.50.105 describes a Type 2 as an attestation of controls over a minimum period of six months. Start the window counting backwards from the date a buyer needs the report, not forwards from today.

Is a SOC 2 report a certificate I can put on my website?

No. It is a restricted report containing an auditor's opinion, normally shared under a non-disclosure agreement. The Cyber Centre notes that SOC 1 and SOC 2 reports are not certifications, and that SOC 3 is the general use report that can be distributed freely.

Can a Canadian CPA firm issue a SOC 2?

Yes. The engagement is performed under CSAE 3000 using the AICPA trust services criteria, and CPA Canada publishes its own SOC 2 guide for practitioners, revised in 2024. If you also need the report to satisfy American buyers, say so during scoping so the firm can report under both sets of standards.

References

• Canadian Centre for Cyber Security, Guidance on cloud security assessment and authorization (ITSP.50.105), May 2020
• Canadian Centre for Cyber Security, Cloud service provider information technology security assessment process (ITSM.50.100), October 2018
• FRAS Canada, Non-authoritative guidance: System and Organization Controls (SOC) engagements
• CPA Canada, System and organization controls (SOC) 2 guide: Reporting on controls at a service organization