SOC 2 Type 1 vs Type 2: What Each Report Proves and Which to Ask For

A SOC 2 Type 1 report and a SOC 2 Type 2 report carry the same name, the same criteria and often the same auditor, yet they prove very different things, and buyers regularly accept the weaker one without noticing. A Type 1 tells you controls were designed sensibly on one day. A Type 2 tells you an auditor tested whether those controls actually ran, over months. This guide compares the two directly: what each report contains, a side-by-side table, when a Type 1 is acceptable, how to move a supplier from one to the other, and the mistakes that lead to false assurance. It is written for third-party risk, procurement and security teams who request and review reports, and for service organisations deciding which report to commission first. For a full walkthrough of report sections see the How to Read a SOC 2 Report Guide, and for the framework itself the SOC 2 Guide.

Key takeaways

• Short answer: ask for a Type 2. Only a Type 2 contains evidence that controls operated effectively over a period. A Type 1 is a design opinion as of a single date.
• A Type 1 is a starting point, not an end state. It fits a new service, a supplier in its first audit cycle, or a significant change in system scope, and it should come with a dated commitment to a Type 2.
• The period matters as much as the type. A Type 2 covering three months that ended a year ago tells you less about today than its label suggests. Check the period length and how recently it ended.
• Neither type covers your side of the shared model. Complementary user entity controls (CUECs) and carved-out subservice organisations sit outside the opinion in both types, so you still have work to do.
• Reliance should follow risk tier. Critical suppliers handling sensitive data or privileged access warrant a current Type 2 with the right trust services categories; low-risk suppliers may not need a SOC 2 at all.

What each report is

SOC 2 is an attestation engagement performed by a licensed CPA firm under AICPA standards. The auditor reports on a service organisation's description of its system and its controls against the AICPA Trust Services Criteria, currently the 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality and Privacy (with revised points of focus, 2022). The AICPA has also published an exposure draft of proposed 2027 Trust Services Criteria and Description Criteria; check its status before relying on any change it proposes. The common criteria, CC1 to CC9, apply to every SOC 2, and the other categories are added by scope. See the SOC 2 CC1 to CC5 Guide.

• Type 1: the auditor's opinion covers whether the system description is fairly presented and whether controls were suitably designed to meet the criteria as of a specified date. The auditor confirms that each control exists and is designed sensibly, usually through inquiry, observation and inspection of a single instance. There is no testing of operation over time.
• Type 2: the opinion covers the same two points plus whether controls operated effectively throughout a specified period. The report adds a section listing each control, the tests the auditor performed, and the results, including any deviations (exceptions) found in samples.

Both types are restricted-use reports intended for parties with sufficient knowledge of the system, usually customers and their auditors under a non-disclosure agreement. A SOC 3 reports against the same criteria with far less detail and is a general-use report that can be freely distributed, so it is a marketing summary, not a substitute for either SOC 2 type.

Side-by-side comparison

What a Type 2 shows that a Type 1 cannot

Most control failures in real environments are not design failures. The access review policy exists, the procedure is sound, and then the quarterly review is skipped in a busy quarter. A Type 1 cannot see that. A Type 2 can, because the auditor samples occurrences. Examples of what only operating-effectiveness testing exposes:

• Access reviews (CC6): whether each scheduled user access review was completed, with evidence of removals, not only that a review procedure was written. See the SOC 2 CC6 Logical Access Guide.
• Leaver processing: whether accounts for a sample of leavers were disabled within the stated time.
• Change management (CC8): whether a sample of production changes had approval and testing evidence, including emergency changes. See the SOC 2 CC8 Change Management Guide.
• Monitoring and incident handling (CC7): whether alerts were triaged and incidents followed the documented process during the period. See the SOC 2 CC7 System Operations Guide.
• Backups and recovery (Availability): whether restore tests happened at the stated frequency, where Availability is in scope.

When you read a Type 2, the tests and results section is where the value is. An unmodified opinion can still list exceptions, so read them, weigh each by the control it affects and the sample size, and look for management's response.

When a Type 1 is acceptable, and when it is not

Period length: no minimum period is mandated for a Type 2, but AICPA guidance suggests at least six months because shorter periods are less useful to user entities and their auditors. A shorter first period, such as three months for a new service, can be reasonable if the reason is disclosed in the system description and later reports extend to six or twelve months.

Small and large organisations: a small buyer with a handful of suppliers can simply require a Type 2 for anything critical and read it fully. A large buyer with hundreds of suppliers should set the requirement by tier in its supplier security policy, automate collection of report dates and categories, and reserve full review for the top tiers. See the Supplier Security Policy Template.

For service organisations: moving from Type 1 to Type 2

1. Readiness assessment: map controls to the Trust Services Criteria, decide the categories that match what customers actually rely on, and fix design gaps first. See the SOC 2 Readiness Checklist.
2. Decide whether to start with a Type 1: it is useful when customers need something now and controls are new. If controls have already run reliably for months, going straight to a Type 2 saves a cycle.
3. Set the observation period: agree the start date with your auditor before evidence collection begins; anything that happens inside the period is in scope.
4. Collect evidence for every occurrence: tickets, approvals, review sign-offs and logs, retained so samples can be pulled. Automated evidence collection reduces gaps.
5. Run an internal mid-period check: sample your own controls halfway through and fix process drift before the auditor finds it.
6. Handle exceptions honestly: where a control failed, document root cause and remediation; the management response appears in the report.
7. Plan continuity: align annual periods so reports roll forward with short gaps, and issue bridge letters only for those gaps.

If a period goes badly, there is no rollback: the report records what happened. The realistic fallback is a qualified or exception-heavy report with clear remediation, followed by a cleaner next period. Choosing the auditor is covered in the SOC 2 Auditor Selection buyer's guide.

Each option in depth

For each option below: the threat it is built for, how it fails, the controls that make it work, when to choose it and a worked example.

Type 1

Threat model. A Type 1 report covers the suitability of control design as of a specified date. The risk for the reader is a supplier whose controls look right on paper but are not operated.

Failure modes. Accepting a Type 1 indefinitely; ignoring complementary user entity controls; and treating a design opinion as evidence that access reviews or change approvals actually happened.

Controls. Accept a Type 1 only as an interim position with a date for the first Type 2, track its age, and add compensating checks such as a security questionnaire or evidence of one control in operation.

Decision criteria. Accept a Type 1 for a new service or a supplier on its first audit cycle.

Worked scenario. A start-up supplier offers a Type 1 dated last month. Procurement signs with a contract clause requiring a Type 2 within 12 months and verifies MFA enforcement on the integration account directly.

Type 2

Threat model. A Type 2 report covers design and operating effectiveness over a period. Schellman notes there is no required minimum period but AICPA guidance suggests at least six months, and an initial report can be shorter for a new service with the reason disclosed. The reader's risk becomes exceptions, scope exclusions and gaps between period end and today.

Failure modes. Reading only the opinion; missing exceptions in the test results; and not checking that the services you use are in scope.

Controls. Read the system description, exceptions and user entity controls, and ask for a bridge letter covering the gap since period end.

Decision criteria. Require a Type 2 for any supplier holding your data or privileged access.

Worked scenario. A Type 2 shows an exception in quarterly access reviews. The customer asks for the remediation evidence and confirms its own user entity controls, such as MFA on its tenant, are in place.

Where identity fits

Much of what a Type 2 tests is identity: joiner, mover and leaver processing, access reviews, privileged access, MFA and the handling of credentials. Check whether the testing covers non-human identities too: service accounts, API keys, OAuth integrations and the keys the supplier holds for your tenant. A Type 2 that samples only human leavers says little about a long-lived integration token. Ask the supplier how machine credentials are inventoried, rotated and reviewed, and look for those controls in the tests. See the Third-Party Risk Management Guide.

Detection and measurement

For a buyer, "detection" means knowing when assurance has lapsed or weakened. Track these for every in-scope supplier:

• Type 2 coverage: percentage of critical suppliers with a Type 2 whose period ended within the last 12 months.
• Interim Type 1 ageing: number of suppliers on a Type 1 for more than 12 months without a Type 2.
• Gap length: days between the last period end and today, with bridge letters on file where the gap exceeds your threshold.
• Exception follow-up: percentage of reported exceptions affecting your use reviewed and closed with the supplier.
• CUEC ownership: percentage of CUECs from critical supplier reports with a named internal owner and evidence of operation.
• Scope fit: percentage of critical suppliers whose report scope (system, regions, categories) matches the service you consume.

Common failure patterns

• Treating "SOC 2 compliant" as a fact. There is no SOC 2 certificate. Ask for the report and check the type, period and opinion.
• Accepting a Type 1 indefinitely. The interim report becomes permanent and operating effectiveness is never tested.
• Reading only the opinion page. A clean opinion with exceptions in the tests section can still matter to your use of the service.
• Ignoring CUECs. Both types assume customers operate their own controls. In the Snowflake Breach 2024, the provider's platform was not breached; attackers used stolen credentials against customer accounts that did not have MFA enabled, which is exactly the kind of customer-side control a supplier's report leaves to you.
• Scope mismatch. The report covers a different product, region or set of categories from the one you use, often without Availability or Confidentiality.
• Chained bridge letters. Management-signed letters covering long gaps, with no new independent testing.

Framework mapping

To relate SOC 2 criteria to an ISMS, see the SOC 2 to ISO 27001 Mapping Guide.

Practitioner checklist

• Require a Type 2 for critical suppliers in your supplier security policy, and say when a Type 1 is acceptable.
• Record the report type, period start and end, categories and opinion for every supplier.
• Give every interim Type 1 an expiry date tied to the supplier's Type 2 commitment.
• Read the tests and results section, not just the opinion, and log exceptions that affect you.
• Confirm the system description covers the product and regions you use.
• Assign an internal owner to each relevant CUEC and keep evidence that it runs.
• Obtain assurance for carved-out subservice organisations that matter to you.
• Accept bridge letters only for short gaps and diarise the next report.
• Check that non-human identity and credential controls appear in the testing.

Standards and references

• AICPA: 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
• AICPA: System and Organization Controls, SOC suite of services
• AICPA: SOC 2, SOC for Service Organizations: Trust Services Criteria
• AICPA: SOC 3, SOC for Service Organizations: Trust Services Criteria for General Use Report
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations
• Schellman: The difference between Type 1 and Type 2 SOC reports

Related NHI Mgmt Group resources: How to Read a SOC 2 Report Guide · SOC 2 Guide · SOC 2 Readiness Checklist · Third-Party Risk Management Guide · Third-Party Risk vs Supply Chain Risk