---
title: "SOC 2 Type 1 vs Type 2: which report should you get first?"
canonical: https://www.grcmana.io/vault/soc-2/type-1-vs-type-2
published: 2024-05-31
updated: 2026-10-23
author: "Harry West"
framework: "SOC 2"
control: "Guide SOC 2 Type 1 vs Type 2: which report should you get first?"
journeyStage: fundamentals
---

# SOC 2 Type 1 vs Type 2: which report should you get first?

## Key takeaways

A SOC 2 Type 1 report gives an auditor's opinion on whether controls are suitably designed as of a specified date, while a Type 2 adds an opinion on whether they operated effectively throughout a specified period. GRCMANA recommends going straight to Type 2 unless a named deal needs evidence before a Type 2 period can close. AICPA guidance sets no minimum period for SOC 2, so plan the first observation window backwards from the deal date.

- **Type 1 report** — An auditor's opinion on whether the system description is fairly presented and the controls are suitably designed, as of a specified date, without testing how they operated over time.
- **Type 2 report** — The same opinions as a Type 1, plus an opinion on whether the controls operated effectively throughout a specified period, with a description of the auditor's tests and their results.
- **Observation period** — The span a Type 2 report covers. AICPA guidance sets no generally accepted minimum for SOC 2; the period must support an opinion on operating effectiveness and meet report users' needs.
- **Attestation, not certificate** — A SOC 2 report is a CPA examination under the AICPA's attestation standards, restricted to specified parties. It is not a certificate, and SOC 2 examinations never use the term compliance.

A US prospect wants a SOC 2 report before procurement will sign, and the auditor needs to know which type to examine. This guide is for UK founders, COOs and engineering leads making the SOC 2 Type 1 vs Type 2 call for the first time.

A Type 1 report tests whether your controls are suitably designed on a single date. A Type 2 report also tests whether they operated effectively across a period. Start with Type 1 only if a named deal needs evidence before a Type 2 period can close; otherwise, go straight to Type 2.

This guide sets out what each report tests, the triggers for each, how to time your first observation window so the report lands before the deal does, and what carries over. For what SOC 2 is and what the Trust Services Criteria cover, start with our [SOC 2 hub](https://www.grcmana.io/vault/soc-2).

## SOC 2 Type 1 vs Type 2: what is the difference?

A SOC 2 Type 1 report gives the auditor's opinion on whether your system description is fair and your controls are suitably designed, as of a specified date. A Type 2 report contains the same opinions plus an opinion on whether those controls operated effectively throughout a specified period, and it describes the auditor's tests and results.

Those definitions come from the AICPA, which owns SOC 2. Its [Journal of Accountancy overview of SOC 1, SOC 2 and SOC 3](https://www.journalofaccountancy.com/newsletters/2016/jun/3-face-of-soc/) sets out the two report types. Both are attestation reports: a CPA's opinion on your controls, not a certificate. The AICPA's own journal notes that "compliance" is [a term never used in SOC 2 examinations](https://www.journalofaccountancy.com/issues/2026/feb/promises-of-fast-and-easy-threaten-soc-credibility/).

| Compared on | SOC 2 Type 1 | SOC 2 Type 2 |
| --- | --- | --- |
| What it tests | Whether the system description is fair and the controls are suitably designed | The same, plus whether the controls operated effectively |
| Period covered | A single specified date | A specified period you agree with the auditor |
| Evidence the auditor examines | How each control is designed and set up on that date | Records of each control operating across the whole period, with the tests and results described in the report |
| Earliest you can have the report | As soon as the controls are designed and in place | Only after the period ends and the auditor has tested it |
| What a buyer can rely on | That the controls were designed to work on one day | That the controls operated effectively throughout the period |
| How long it stays useful | Until the first Type 2 replaces it | Until the next period's report follows on from it |

A Type 1 shows the controls were designed to work; only a Type 2 shows they did.

That does not make a Type 1 worthless. It is faster to reach, it puts an independent eye on your control design, and it gives a buyer something concrete while a Type 2 period runs.

## When should you choose a SOC 2 Type 1 report?

Choose a SOC 2 Type 1 report when a named deal needs independent evidence before a Type 2 period could close, and the buyer has agreed to accept it. A Type 1 also gives you an independent check on control design before an observation period starts, so gaps surface early.

The triggers are concrete. A Type 1 makes sense when most of these are true:

- **Who is asking.** A specific buyer's security or procurement team has said, in writing, that a Type 1 now and a Type 2 to follow is acceptable.
- **The deal deadline.** The signing date falls before a Type 2 period, plus the auditor's reporting time, could finish.
- **The questionnaire wording.** The security questionnaire asks for "a SOC 2 report" or evidence of control design, and does not name Type 2.
- **Your readiness.** Your controls are newly designed, and you want an independent view of that design before you commit to a period.

A Type 1 that becomes the destination is a delay, not a strategy.

If you commission a Type 1, set the start date of the Type 2 period at the same time. The buyer then sees both halves of the plan, and your team knows when every control has to start leaving evidence.

## When should you go straight to SOC 2 Type 2?

Go straight to SOC 2 Type 2 when no signed deal needs a report sooner than a Type 2 period can deliver one, when the buyer's contract or questionnaire names Type 2, or when your controls already run and leave records. Skipping the Type 1 puts all the effort into the report a buyer can rely on over time.

AICPA guidance treats the choice as a question of what your report users need. The [Journal of Accountancy's guide to SOC 2 engagements](https://www.journalofaccountancy.com/issues/2011/jul/20103500/) lists deciding between a Type 1 and a Type 2 "depending on the needs of users" as a management decision. A Type 1 is not a required first step.

Go straight to Type 2 when any of these apply:

- **Who is asking.** An enterprise security team running a vendor risk review, which will read your test results to judge how they affect its own risk.
- **The deal deadline.** The contract date is months away, or you are building a pipeline of buyers rather than closing one deal.
- **The questionnaire wording.** It names Type 2, asks for the report period, or asks for test results and exceptions.
- **Your starting point.** You already run an ISO 27001 management system, or mature engineering practice that produces evidence as a by-product.

## How do you plan your first SOC 2 Type 2 observation window?

Plan the first SOC 2 Type 2 observation window backwards from the deal date. Subtract the auditor's reporting time, then the window length, and you have your start date. AICPA guidance sets no minimum period for SOC 2; the period must be long enough to support an opinion on operating effectiveness and to meet report users' needs.

The same Journal of Accountancy guide says there is "no generally accepted minimum useful period" for a SOC 2 report, and suggests service organisations discuss the period with their auditor. That leaves the length to you, your auditor and your buyers.

We recommend a first window of about three months, then 12-month windows from then on. Three months is long enough for quarterly controls, such as access reviews, to run at least once. A 12-month window gives buyers a report that covers a full year.

The observation window starts on a date you choose, and from that day every control is on the record.

That is why the start date is a commitment. A control you are still building on day one cannot show it operated throughout the period. Fix design gaps first, then open the window.

Here is a worked timeline for a buyer whose contract is due to sign in July:

| When | Milestone | What it needs |
| --- | --- | --- |
| January | Deal date confirmed for July | Agree the scope, the period and the reporting turnaround with your auditor |
| 1 February | Observation window opens | Every in-scope control running and leaving evidence |
| 30 April | Window closes after three months | Evidence complete for every control across the whole period |
| May to June | Auditor tests and issues the report | The turnaround you agreed in January |
| July | Contract signs | Report shared with the buyer under its use restrictions |

If the auditor cannot commit to issuing the report before July, that is the trigger for a Type 1 as of a date in February. What happens during the examination itself is covered in our [SOC 2 audit guide](https://www.grcmana.io/vault/soc-2/audit).

## What carries over from a Type 1 or from ISO 27001?

Most of the work behind a SOC 2 Type 1 carries into the Type 2: the system description and the designed controls, because a Type 2 repeats the same opinions and adds operating effectiveness. An existing ISO 27001 management system carries over too. Its risk assessment, policies and running controls are the raw material a Type 2 tests.

What never carries over is time. A Type 1 has no period, so it gives you no operating evidence. The Type 2 period starts from zero on the day the window opens.

An [ISO 27001](https://www.grcmana.io/vault/iso-27001) management system is a strong head start, because its controls already run on a cycle and leave records. The frameworks still differ in scope, criteria and who issues the report. Our [ISO 27001 vs SOC 2 comparison](https://www.grcmana.io/blog/iso-27001-vs-soc-2) covers where they overlap and the order to do them in.

## What happens after your first SOC 2 Type 2 report?

After your first SOC 2 Type 2 report, the next period should start the day after the last one ended. We recommend back-to-back 12-month periods, so buyers never see a gap in coverage. For the months between a period's end and the next report, buyers may ask for a bridge letter.

Bridge letters are a recognised part of reading a SOC 2 report, and the [AICPA's SOC 2 report walkthrough course](https://www.aicpa-cima.com/cpe-learning/webcast/soc-2-report-walkthrough) covers them alongside exceptions. Plan for one each year, timed to your buyers' renewal and review dates.

A Type 2 is a running system, not a project with an end date.

## Frequently asked questions

### Can you share a SOC 2 Type 1 or Type 2 report publicly?

No. SOC 2 reports are restricted to specified parties who understand the service organisation's system, as the Journal of Accountancy explains. If you need something you can publish, a SOC 3 report covers the same subject matter in a less detailed form whose use is not restricted.

### Do SOC 1 reports have Type 1 and Type 2 versions too?

Yes. SOC 1 and SOC 2 both offer Type 1 and Type 2 reports, with the same split between design on a date and operating effectiveness over a period. A [SOC 1 report](https://www.grcmana.io/vault/soc-1) covers controls relevant to your customers' financial reporting rather than security, so a buyer's finance team asks for it for a different reason.

### How long does a SOC 2 Type 2 report stay valid?

A SOC 2 Type 2 report has no expiry date. It covers the period stated in it, and buyers judge how recent that period is. In our view, plan on each report covering 12 months and arriving soon after its period ends, so the next one is ready before buyers ask.

### What should you ask a buyer before choosing a report type?

Ask four questions: which type they need, which Trust Services Criteria must be in scope, the latest period end date they will accept, and whether an interim Type 1 or a bridge letter will do. The answers usually settle the choice and give you the date to plan backwards from.