SOC 2 Type I vs Type II — what your enterprise clients are actually asking for

If you are a SaaS company or cloud service provider pursuing enterprise clients, you will encounter the SOC 2 request at some point in almost every sales cycle. It usually arrives in a security questionnaire, sometimes as a standalone ask, occasionally as a contractual condition of purchase.

The question that follows — do you have a SOC 2 report? — is rarely as simple as it sounds. What your prospect is actually asking depends on their risk profile, their procurement process, and sometimes on what their own auditors have told them to require. Getting this wrong costs deals.

What SOC 2 actually attests to

SOC 2 is a framework developed by the AICPA (American Institute of CPAs) for reporting on the controls relevant to security, availability, processing integrity, confidentiality, and privacy at service organisations. The framework is built around Trust Services Criteria — a structured set of control requirements across five categories.

A SOC 2 report does not certify that you are secure. It attests that a qualified CPA firm has examined your controls against the relevant Trust Services Criteria and found them to be suitably designed (Type I) or suitably designed and operating effectively over a period of time (Type II).

The distinction between "suitably designed" and "operating effectively over time" is the entire difference between Type I and Type II.

Type I — point in time

A SOC 2 Type I report covers a specific date. The auditor examines your control environment as it exists on that date and opines on whether your controls are suitably designed to meet the Trust Services Criteria you have scoped.

What it demonstrates: Your controls were in place and appropriately designed as of a specific date.

What it does not demonstrate: That those controls operated consistently over any period of time. A Type I report does not tell you whether the controls were actually followed, whether they were effective in practice, or whether they would hold up under sustained examination.

When it is useful: Type I reports are useful as a starting point — when you are building your compliance programme for the first time, or when you need to demonstrate a baseline of controls quickly. They signal commitment to the programme. They do not yet demonstrate operational maturity.

What sophisticated buyers think of it: Enterprise security teams and procurement functions know that Type I is a snapshot. Many will accept it as a starting point — especially if you can explain your roadmap to Type II — but they will ask when your Type II will be available. If the answer is indefinitely, that is a problem.

Type II — operating over time

A SOC 2 Type II report covers a period of time — typically 6 to 12 months. The auditor examines not just whether your controls are designed correctly, but whether they operated consistently and effectively throughout the review period.

What it demonstrates: Your controls were in place, designed correctly, and operating as intended throughout the report period. This is a fundamentally different and substantially stronger statement than Type I.

What it requires: Consistent evidence of control operation throughout the period. Log files showing your access reviews were conducted monthly, not just on the day the auditor visited. Change management records showing every production change was approved and documented. Incident response records showing your process was actually followed when something went wrong.

When it is required: Any enterprise client with a mature procurement process will require Type II. Financial services, healthcare, and regulated industries almost universally require it. Enterprise software procurement teams have it on their standard vendor questionnaire. If you are selling to companies with more than a few hundred employees, plan for Type II.

What the report period means: The period start and end dates in a Type II report matter. A 6-month report covering the most recent 6 months tells the reader something different from a 6-month report covering a period that ended 18 months ago. Enterprise buyers will check this. If your Type II report is significantly out of date, it raises questions about whether you have maintained continuous compliance or simply stopped renewing.

The scope question — which criteria matter

Both Type I and Type II reports are scoped to specific Trust Services Criteria. The Security criterion (also called the Common Criteria) is mandatory — every SOC 2 report must include it. The other four — Availability, Processing Integrity, Confidentiality, and Privacy — are optional and included based on relevance to your service commitments.

The question of which criteria to include is not purely a compliance question. It is a commercial question. What are your clients asking for? What does your service agreement promise?

Security: Always included. Covers logical and physical access controls, system monitoring, change management, risk assessment, and incident response. This is the baseline.

Availability: Relevant if you make uptime or performance commitments. SaaS companies with SLA obligations should include this.

Processing Integrity: Relevant if the completeness and accuracy of processing is a service commitment — payment processors, data analytics platforms, financial reporting tools.

Confidentiality: Relevant if you handle confidential information and commit to specific protections. More relevant than it might appear for most B2B SaaS.

Privacy: Relevant if you collect, use, retain, or disclose personal information. With GDPR and CCPA in effect, this is increasingly expected.

Scoping too narrowly to save audit cost is a false economy. If your enterprise clients have questions about availability and you have excluded that criterion, you will be re-entering the compliance conversation.

What enterprise clients are actually checking

When an enterprise security team reviews your SOC 2 report, they are looking at several things that are not always visible from the surface.

The auditor. Not all CPA firms are equal for SOC 2. Enterprise buyers know the major firms and have opinions about smaller ones. This is not always rational, but it is real. A report from a firm with a strong SOC 2 practice carries more weight.

The exceptions. A SOC 2 report almost always contains some qualified findings — controls that were tested and found to have exceptions during the period. Enterprise buyers are not shocked by exceptions. What they are looking at is whether the exceptions are material, whether you identified them yourself or the auditor found them, and what your management response says about how you are addressing them. A thoughtful management response to a control exception demonstrates maturity. No management response, or a defensive one, does not.

The complementary user entity controls. Most SOC 2 reports include CUECs — controls that the report relies on your clients implementing. Enterprise buyers will read these carefully. If your CUECs require clients to implement controls that are burdensome or unclear, that is a friction point.

The report date and period. As noted above, both the period end date and the period length matter. A 12-month Type II with a period ending last month is the strongest commercial position.

The commercial timeline question

Here is the practical question most growing SaaS companies face: when do you need SOC 2, and which type?

The answer depends on your customer profile. If your current clients are SMBs and startups, a Type I gets you through the near term. If you are pursuing enterprise, or if enterprise is on your 18-month roadmap, start the Type II process now. Type II requires a review period — you cannot compress that timeline. A 12-month report requires 12 months. If you start today, your first Type II will be available in a year.

The companies that end up scrambling on SOC 2 are the ones who started the process in response to a lost deal rather than ahead of one.

If you are planning a SOC 2 engagement — Type I or Type II — the most important decision is the methodology. Evidence gathered before the report is written. Controls assessed against your actual environment, not a generic template. Findings that an auditor can verify because the evidence trail is clean.

That is what we build. Start a conversation if you want to understand what your engagement would look like.