Skip to main content
Compliance 101

SOC 2 Type 1 vs Type 2

A plain-English comparison of SOC 2 Type 1 and Type 2 reports: what each covers, why customers ask for them, and how an MSP can prepare clients.

Quick answer

Type 1 and Type 2 are the two common SOC 2 report types. Here is how they differ, what the AICPA publishes, and how MSPs guide clients through the first report.

A SOC 2 report is an independent CPA firm’s written opinion on a service organisation’s controls. The two report types most people talk about are Type 1 and Type 2. In the way practitioners commonly describe them, a Type 1 report looks at whether controls are suitably designed at a single date, while a Type 2 report also looks at whether those controls operated effectively over a stated period.

SOC 2 is not a certification and it is not a pass or fail score. It is an attestation report, and the report contains the auditor’s opinion, management’s description of the system, and the results of the auditor’s work. Reading it is part of the buyer’s job.

What the AICPA publishes

The American Institute of CPAs (AICPA) sets the professional standards for these engagements. Its public page on the System and Organization Controls suite describes SOC as “a suite of service offerings CPAs may provide”, and notes that the AICPA promulgates the professional standards for SOC engagements.

For SOC 2 specifically, the AICPA’s published materials establish three things that matter to a service provider:

  • The criteria. The trust services criteria were established by the AICPA’s Assurance Services Executive Committee for use in attestation or consulting engagements. The current set is titled the 2017 Trust Services Criteria with revised points of focus (2022), and it covers five categories: security, availability, processing integrity, confidentiality and privacy.
  • The system description. The AICPA publishes separate description criteria, which are used when preparing and evaluating the description of the service organisation’s system.
  • The guide for practitioners. The AICPA’s SOC 2 guide, updated in October 2022, describes SOC 2 as an assertion-based examination, and the same page lists SOC 3 separately as general-use reports.

The public AICPA pages we reviewed also list a management representation letter for a “SOC 2 Type 1” examination, which confirms that Type 1 is a recognised engagement type. They do not set out a minimum length for a Type 2 period, so we do not state one here.

Type 1 and Type 2 in practice

The distinction below is the one commonly used in practice. The exact wording of an opinion depends on the auditor and the engagement.

Type 1 Type 2
Time frame A single date A period of time
Question answered Are controls suitably designed? Are controls designed and operating effectively over the period?
Typical evidence Policies, configurations, a walkthrough Samples from across the period, such as tickets, logs and approvals
Common use A first report, or a stop-gap for a sales deadline The report many buyers ask for on renewal and in security reviews

The length of a Type 2 observation window is usually agreed with the auditor, and clients often choose a period of several months for a first report. Treat that as common practice, not a rule set by the AICPA.

Why it matters

Customers that outsource part of their processing often ask suppliers for a SOC 2 report during procurement or vendor risk review. For a client of an MSP, the report can shorten security questionnaires, because the buyer can read an independent opinion instead of relying only on answers the supplier wrote itself.

A Type 1 report can be useful when a client has just put controls in place and needs something to show. A Type 2 report carries more weight with many buyers because it speaks to how controls behaved over time. Whichever type is chosen, the buyer should check the scope, the categories covered and the period, because those decide whether the report answers their question.

How an MSP or vCISO delivers readiness

SOC 2 readiness is a repeatable service, and it usually follows this order.

  1. Choose the scope. Agree which system, which trust services categories and which locations are in scope. Security is the usual starting point, and other categories are added where a customer needs them.
  2. Run a gap assessment. Compare existing controls to the criteria before the auditor does. Our guide to gap assessments explains the method.
  3. Fix and document. Close gaps, finalise policies, and assign an owner to every control.
  4. Decide the report type and the dates. Many first-time clients start with a Type 1 report and move to Type 2, but that is a choice, not a requirement. Pick the observation period with the auditor early.
  5. Collect evidence continuously. In a Type 2 period, evidence is gathered as work happens, not reconstructed at the end. The compliance evidence operations guide covers this at scale.
  6. Support the audit and the follow-up. Answer auditor requests, review the draft report, and plan the next period.

For a fuller service model, see our SOC 2 Type 2 service line guide, and for a comparison with ISO certification see ISO 27001 vs SOC 2.

Common mistakes

  • Treating SOC 2 as a certificate. It is a report with an opinion, and the opinion may carry exceptions. Do not describe a client as “SOC 2 certified”.
  • Buying a Type 1 report and stopping. If buyers ask for a Type 2 report, a Type 1 report will only delay the question.
  • Starting the observation period before controls work. Controls that fail early in a period create exceptions that sit in the report for everyone to read.
  • Scoping too wide or too narrow. A scope that leaves out the system the customer actually uses makes the report less useful.
  • Leaving evidence to the end. Reconstructing six months of approvals from memory is slow and unreliable.
  • Forgetting subservice providers. If a cloud or hosting provider performs a control on the client’s behalf, the report has to deal with it.

Where GetCybr fits

If you run SOC 2 readiness for several clients, GetCybr is a platform for keeping the control library, policies and evidence for each client in one place, and for tracking readiness against the criteria. It does not replace the independent auditor, and it cannot issue or guarantee a SOC 2 report. You can see how the framework is handled on the SOC 2 compliance software page.

Sources

Need a deeper answer?

Book a demo to see how GetCybr handles frameworks, evidence, and client reporting in practice.