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

SOC 2 Type 1 vs Type 2: the short answer

Both reports come from the same place. A licensed CPA firm examines your controls against the AICPA's Trust Services Criteria and issues a SOC 2 report. The difference between SOC 2 Type 1 vs Type 2 is what the auditor tests and over what stretch of time.

• Type 1 looks at a single point in time. The auditor gives an opinion on whether your system description is fair and whether your controls are suitably designed and in place as of a specific date.
• Type 2 looks at a period of time, usually called the observation period or review period. The auditor gives the same opinion on design, and also tests whether your controls operated effectively throughout that period.

Put simply, a Type 1 says "the controls you described exist and make sense." A Type 2 says "and they actually ran, every time they were supposed to, for months." That second claim is harder to earn, which is why customers tend to value it more.

Type 1 and Type 2 side by side

Both report types use the same criteria. Security (the Common Criteria, CC1 to CC9) is always in scope, and you can add Availability, Confidentiality, Processing Integrity or Privacy. That choice is separate from the Type 1 or Type 2 decision.

Which SOC 2 report should you get first?

There is no universal right answer. The decision usually comes down to four questions.

1. What are your customers actually asking for? Read the security questionnaires and contract language you already have. If a prospect has written "SOC 2 Type 2" into their requirements, a Type 1 may only buy you time. If they just want to see a SOC 2 report, a Type 1 may be enough for now. When in doubt, ask the customer's security team directly.
2. When do you need a report in hand? A Type 2 cannot be issued until the observation period has ended and the auditor has done their fieldwork. A Type 1 has no observation period, so it can usually be delivered sooner. Your auditor can tell you what timeline is realistic for your situation.
3. Have your controls been running? If your policies are freshly written and your access reviews have never happened, you have nothing for a Type 2 auditor to sample yet. A Type 1 lets you get the design checked while the operating history builds up.
4. Can you afford two audits? Doing a Type 1 and then a Type 2 means two engagements. Ask auditors to quote both paths so you can compare.

Two common paths to a Type 2 report

Type 1 first, then Type 2

You get your controls designed and documented, the auditor issues a Type 1 report as of a date, and your observation period for the Type 2 runs from around then. This path suits teams that need something to show customers soon, or that want an auditor's view of their design before months of evidence depend on it. If the Type 1 finds a design gap, you can fix it before the period that gets tested.

Straight to Type 2

You skip the Type 1, often after an informal readiness review (some auditors offer one), and start the observation period once your controls are in place. Some teams choose a shorter first observation period to get a report sooner, if their auditor and customers accept it. This path suits teams whose customers will only accept a Type 2, or whose controls are already running and documented.

Either way, the work that matters most is the same: getting every control to run on schedule and leave evidence. The SOC 2 audit readiness checklist covers what to have in place before any audit starts.

What the observation period means in practice

The observation period is where most teams struggle. A Type 1 can be earned with good documents and a working setup on the day. A Type 2 needs proof that each control operated every time it was due, across the whole period.

Your auditor picks samples from the period and asks for evidence that the control ran for each one. Sample sizes and acceptable evidence formats are the auditor's call, and they depend on how often the control runs. What that means for a few typical controls:

• A quarterly user access review has to happen in each quarter of the period, with a record of who reviewed which systems and what changed.
• A monthly vulnerability scan review has to happen every month, with the results and the triage decisions.
• Annual controls such as a risk assessment, a penetration test, security awareness training or an incident response tabletop exercise need to fall inside the period, or your auditor needs to be satisfied they are current.
• Policies need to be approved, reviewed on the schedule they state, and acknowledged by the people they apply to, including people who joined during the period.
• Event-driven controls such as onboarding, offboarding and change approvals are sampled from the events that happened during the period.

Where teams usually come unstuck

• A missed period. Nobody did the access review in the second quarter. You cannot go back and do it later, and the gap is likely to be reported as an exception.
• Evidence created after the fact. A screenshot with no date, or a review written up weeks later from memory, is hard for an auditor to rely on.
• No record of sign-off. The work happened, but there is nothing showing who reviewed it and when.
• Documents that changed after approval. A policy was edited after it was approved, and nobody can show which version people agreed to.
• Owners who left. The person who ran a control moved on, and their recurring work quietly stopped.

Habits that make the period manageable

1. Give every recurring control a named owner and an independent approver.
2. Put every control on a calendar with due dates that match your fiscal year. The SOC 2 compliance calendar lays out a typical year.
3. Create the evidence while doing the work, in a place that records dates and versions automatically.
4. Record approval of each piece of evidence, tied to what was actually reviewed.
5. If a period genuinely does not apply, write down why at the time instead of leaving a silent gap.
6. Check status monthly, not the week before fieldwork.

For how to organize the evidence itself, see SOC 2 evidence collection.

Producing continuous evidence in Confluence

If your policies already live in Confluence, Compliance in a Box turns one Confluence space into the record for your observation period. It is built around the scheduled, sign-off-heavy controls that a Type 2 samples most.

• Recurring activities. The SOC 2 program includes 15 recurring activities, such as a quarterly User Access Review, a monthly Vulnerability Scan Review and an annual Penetration Test. Each one opens its own dated evidence page before every period is due (14 days ahead by default), aligned to your fiscal year. Missed periods stay visible as overdue, and skipping a period needs a written reason that is kept for auditors. See Recurring activities.
• Version-bound approvals. When an owner submits a policy or evidence page, the approvers approve that exact page version. If the page is edited before every approver has decided, the submission is cancelled and has to be submitted again.
• Acknowledgements. Employees acknowledge the approved version of a policy with one click. A material change asks for acknowledgement again, and people who join the audience later are added by the app's daily check.
• Reminders and a dashboard. Reminders arrive as Confluence task notifications, admins see overdue items on the Dashboard, and everyone sees what is waiting for them in My Tasks.
• Evidence reports. The app generates a Policy Approval Log, a Policy Acknowledgement Report, an Activity Completion Report, monthly Audit Log pages and a Controls Matrix as Confluence pages, refreshed daily. Each "Version N" link opens the exact page version that was approved or acknowledged, and an optional Auditors group can view the reports without editing them.

When fieldwork starts, you point your auditor at the report pages for the months in scope, or export them with Confluence's own export. The Evidence, reports and audits chapter of the user guide walks through each report and how to prepare for an audit.

Two limits are worth knowing. Event-driven controls such as onboarding and offboarding checklists are not recurring activities, so they stay in the tools where those events happen. And the control mappings are a starting point, not audit advice: have them reviewed by your auditor.

FAQ

Is a Type 1 report worth getting?

It can be, if customers need to see a report soon and your controls do not have an operating history yet. It is less useful if your customers have already said they need a Type 2.

How long is a Type 2 observation period?

Periods of 3 to 12 months are common, and many companies settle into a 12-month cycle after the first report. Your auditor sets the period with you, so ask them what they would accept for a first report.

Do we need a new SOC 2 report every year?

Most companies renew on a regular cycle because customers want a recent report. For the time between the end of one period and the next report, companies often provide a bridge letter written by management.

Can a Type 2 cover more criteria than our Type 1 did?

Yes. Scope is set for each report, so you can add categories such as Availability or Confidentiality later. Any added controls need to operate through the new period too.

← All articles