SOC 2 Type 1 vs Type 2: How to Choose the Right Report

Marcal Santos
Marcal Santos
August 22, 2026
https://secureleap.tech/blog/soc-2-type-1-vs-type-2
SOC 2 Type 1 vs Type 2: How to Choose the Right Report

By Marçal Santos, vCISO and founder of SecureLeap. CISM and CDPSE (ISACA). Previously security roles at Aircall, Citibank and Talkdesk. +20 years in cybersecurity.

‍

SOC 2 Type 1 confirms your controls are designed correctly on one specific date. SOC 2 Type 2 proves they actually operated over a window that runs 3 to 12 months, with 3 months typical for a first report and 12 for a recurring annual cycle (Schellman). Enterprise buyers almost always mean Type 2 when they ask if you have a SOC 2. Most startups still start with Type 1, because it is the only one you can hold in your hand this quarter.

‍

Key Takeaways

  • Type 1 tests control design on a single date. Type 2 tests operating effectiveness across a period. Same criteria, same auditor, same report structure. The difference is time.
  • The Type 2 observation window is 3 to 12 months, not a fixed 6. Three months is the shortest most auditors will issue, six is the point at which the report is widely relied upon, twelve is the standard recurring cadence.
  • Type 1 is a stepping stone, not a destination. It buys you a report in weeks instead of quarters, and every control you build for it counts toward Type 2.
  • If a signed RFP already requires Type 2, a Type 1 will not substitute for it. What can move that deal is a Type 1 plus a dated remediation plan and, later, a bridge letter.
  • Going straight to Type 2 with immature processes is the expensive mistake. Control failures during the observation window become documented exceptions in the report your prospects read.

‍

‍

The comparison, in one table

‍

Both reports use the same Trust Services Criteria, require an independent CPA firm, and contain the same sections: system description, management assertion, and auditor's opinion. Everything that differs, differs because of time.

‍

Table 1: SOC 2 Type 1 vs SOC 2 Type 2 at a glance

‍

Dimension SOC 2 Type 1 SOC 2 Type 2
What the auditor tests Whether controls are suitably designed and implemented Design and operating effectiveness over a period
Point of reference A single date, for example "as of 30 June 2026" A period, for example "1 January to 30 June 2026"
Observation window None 3 to 12 months
Typical time to report 4 to 8 weeks after readiness Observation window plus 4 to 8 weeks
Evidence required Policies, system diagrams, configuration screenshots, procedures Months of logs, tickets, access reviews, scan results, sign-offs
How evidence is tested Usually one item per control A sample the auditor selects from your full population
Relative audit fee Lower Higher, because the auditor samples evidence across months
Enterprise acceptance Sometimes, usually with conditions Standard requirement
What it tells a buyer "The right controls exist" "The right controls have been working"
Best fit First report, recent security overhaul, near-term deal pressure Enterprise pipeline, regulated buyers, mature recurring processes

Note: How much SOC 2 costs in total, line by line.

‍

For what each report actually costs, see how much SOC 2 costs, which breaks fees down by company size, scope and auditor tier.

‍

Type 1 answers: are your controls designed properly today? Type 2 answers: have you actually followed them, consistently, for months?

‍

Both are SOC 2 reports. If you are trying to work out whether you need SOC 2 at all rather than which type, see SOC 1 vs SOC 2.

‍

What the auditor actually asks you for

‍

The clearest way to understand the difference is to look at what lands in your evidence request list, because that is where design testing and operating-effectiveness testing stop resembling each other.

‍

In a Type 1, the auditor is confirming the control exists and is designed properly. For most controls that means one piece of evidence. One record, one screenshot, one completed form, enough to show the control is real and built correctly.

‍

In a Type 2, the auditor tests whether the control actually operated, auditing operating effectiveness throughout the period rather than as of a date (Linford & Company). For many controls that means a sample. Several items, and critically, the auditor selects them, not you. They ask for the full population, then pick from it.

‍

Security awareness training makes the difference concrete:

‍

Type 1 Type 2
What the auditor wants Evidence the training programme exists and is assigned Evidence employees actually completed it during the period
What you hand over One employee's completion record Your full employee list
What the auditor does Confirms the control is designed Selects several employees from that list and checks each one's completion record
How it fails The programme does not exist or is not assigned to anyone The programme exists, but one of the selected employees never completed it

‍

The same pattern applies across the recurring controls: access reviews, onboarding and offboarding, change approvals, vulnerability scans, backup checks. In a Type 1 you show the process. In a Type 2 the auditor picks instances from the period and checks each one.

‍

Two consequences worth planning around:

‍

  • You cannot present your best examples. Because the auditor selects from the full population, a control that works for most people and quietly fails for a few will surface. That is the entire point of Type 2, and it is why a Type 2 carries more weight with buyers.
  • A control can pass Type 1 and fail Type 2 without anything changing. If the process runs but is not documented per instance, the design is fine and the evidence is not there. This is the most common reason a first Type 2 comes back with exceptions.

‍

This is also the honest explanation for why Type 2 costs more and takes longer. The auditor is not reviewing more documents about the same control, they are testing many instances of it.

‍

‍

How long the Type 2 observation window is

‍

The observation window runs 3 to 12 months. Three months is the shortest period most auditors will issue, and it is the usual choice for a first report. Twelve months is the standard cadence once you are on an annual cycle. Your auditor agrees the period with you: the AICPA sets the professional standards for SOC engagements but does not fix the length of the examination period (Schellman).

‍

Six months is the threshold that matters most in practice. Below it, a report is harder for your buyer's own auditors to lean on. Becky McCarty, a Partner at Linford & Company LLP , sets the bar plainly: "For the SOC report to be relied upon by user auditors, the SOC report should cover a minimum reporting period of six months."

‍

So choose the window against who will read the report:

‍

  • 3 months when you need a Type 2 in hand as fast as possible and the reader is a customer's security team. Plan to extend to 12 on the next cycle.
  • 6 months or more when a buyer's external auditor will rely on the report, or when procurement has asked for a "current" Type 2 without qualifying it.
  • 12 months once you are renewing annually, covering the full year.

‍

Picking 3 months to save a quarter and then being told the period is too short to rely on is the outcome to avoid. Ask the buyer what the report needs to support before you set the date.

‍

‍

Which report will your buyer actually accept?

‍

Most people arrive at this question from a live deal, not from curiosity. The honest answer depends on who is asking.

‍

Table 2: Who accepts what

‍

Buyer Type 1 accepted? What usually unblocks the deal
Early adopters, SMB Usually yes Type 1 alone is often enough
Mid-market Often, with conditions Type 1 plus a dated commitment to Type 2
Enterprise procurement Often, with conditions Type 1 plus a dated commitment to Type 2
Financial services, healthcare Almost never Current Type 2, often with specific criteria in scope
A buyer's external auditor No Type 2 covering at least 6 months

‍

‍

If the RFP requires Type 2 and you only have Type 1

‍

‍

This is a common position and it is not automatically fatal. What works, in order:

‍

  1. Ask what the requirement is protecting. Procurement often inherits "SOC 2 Type 2" from a template. The security team's actual concern may be narrower and answerable with your Type 1 plus specific evidence.
  2. Offer the Type 1 with your observation-period start date already set. A signed engagement letter showing your Type 2 window is running converts "we don't have it" into "it's dated".
  3. Request a time-bound exception. Many enterprises will grant one with a contractual commitment to deliver the Type 2 by a named date.
  4. Fill the gap in writing later. Once you have a Type 2, a bridge letter covers the period between your report's end date and the buyer's review date.

‍

If the requirement survives all four, the deal genuinely needs a Type 2 and the only variable left is how fast you can start the clock.

‍

‍

How to decide

‍

There is no universally better report. The choice comes down to four things: how soon a customer needs evidence, how mature your recurring processes are, who your buyers are, and whether anyone downstream will rely on the report formally.

‍

Table 3: Typical path by company stage

‍

Stage Usual starting point Why
Pre-Series A Type 1 No 3-month control history yet, and one anchor customer is usually driving the deadline
Series A to B Type 1, then Type 2 within 6 to 12 months Enterprise logos entering the pipeline while processes are still bedding in
Series B+, or regulated buyers Straight to Type 2 Type 1 will not clear procurement, and controls are mature enough to survive testing
Already ISO 27001 certified Straight to Type 2 Recurring evidence discipline already exists

‍

‍

Start with Type 1 when you have just stood up your security program, a named customer needs evidence this quarter, or your recurring controls have not run reliably long enough to survive sampling.

‍

Go straight to Type 2 when a buyer has stated the requirement explicitly, you already operate a mature framework, you handle regulated data, or your competitors all hold Type 2 reports and it is table stakes in your market.

‍

The mistake to avoid is going straight to Type 2 with processes that are not yet reliable. Every missed access review and skipped scan during the observation window becomes a documented exception in the report your prospects will read. A clean Type 1 is a better sales asset than a Type 2 full of findings.

‍

‍

"Treat Type 1 as a bridge, not a destination. It is the first step, and Type 2 is the gold standard your buyers actually trust. Every control you stand up for Type 1 is a control you have already built for Type 2."
Marçal Santos, vCISO and founder of SecureLeap

‍

‍

Moving from Type 1 to Type 2

‍

For teams deliberately staging it, the sequence is:

‍

  1. Run a readiness assessment. Evaluate current controls against the criteria you plan to include, and identify gaps before an auditor does. A formal readiness assessment simulates the examination and returns the auditor's recommendations before anything is on the record (A-LIGN). See readiness assessment.
  2. Complete the Type 1. Document the control environment and close design gaps. Details in the SOC 2 Type 1 guide.
  3. Close what the Type 1 surfaced. Strengthen anything that looks fragile under sustained execution, not just on paper.
  4. Assign owners and run the controls. HR takes onboarding, offboarding and training. IT takes access reviews and patching. DevOps takes backups and monitoring. Security takes scanning and incident response.
  5. Start the observation window. Agree the period with your CPA firm, 3 months at the low end, 6 or 12 if the report needs to be relied upon.
  6. Complete the Type 2 examination. The auditor samples evidence across the period. See what the finished report contains in the SOC 2 Type 2 report guide.

‍

Align the period with your business calendar where you can. A window that ends before your peak selling season means the report is in hand when procurement asks for it.

‍

Where the Type 1 to Type 2 transition goes wrong

‍

Most first Type 2 reports come back with exceptions for the same handful of reasons, and they share a single root cause: Type 1 is a project, Type 2 is an operating rhythm. Teams finish the Type 1, feel done, and then treat the Type 2 as a repeat of that project rather than as a period they have to live through. Because the auditor samples across the whole period and picks the instances, whatever drifted gets found.

‍

Four that come up again and again:

‍

1. Standing everything up for Type 1, then not looking again until the week before the Type 2 audit. This is the big one, and it is where the other three come from. Controls that ran in month one quietly stop running in month four. There is no way to retrofit an access review you never did in March, and no way to hide it, because the auditor selects which months to test. Book a recurring monthly or quarterly check from the day the observation window opens.

2. Onboarding training that never gets completed. New joiners get added to the training platform and nobody confirms they finished. In a Type 1 this passes, because one completion record proves the programme exists. In a Type 2 the auditor pulls your employee list and picks people, and every new hire during the period is in that population. One person who never completed is one exception. Check completion as part of onboarding sign-off, not as an annual sweep.

3. Policies written for Type 1 and never reviewed again. Your own policy set almost certainly states that policies are reviewed at least annually. Draft them for the Type 1, leave them untouched, and by the time the Type 2 period closes they are 12 months old with no review recorded. That is not a documentation problem, it is failing a control you wrote yourself. Schedule the review and record it with a date and an approver.

4. New vendors added during the period that never went through vendor review. The team signs up for tools mid-period, and the vendor risk assessment does not happen because nobody owns the trigger. Your vendor list at the end of the period no longer matches the one you assessed at the start, and the gap is visible. Tie vendor review to procurement or to whoever holds the company card. See vendor management for startups.

‍

The pattern in all four: nothing was designed badly. Everything was designed correctly and then not sustained, which is precisely the difference Type 2 exists to measure.

‍

What the difference costs

‍

Type 2 costs more than Type 1, because the auditor samples evidence across months instead of assessing a single date. But the report type is not what drives your budget. Company size, how many Trust Services Criteria are in scope, and which tier of auditor you engage all move the number more than the choice between Type 1 and Type 2 does.

‍

The framing that matters when you are deciding: the audit fee is only 30% to 40% of what SOC 2 costs you. Readiness work, the compliance platform and internal engineering time make up the rest, and those are broadly the same whichever report you commission first. Picking Type 1 to save money saves you a slice of one line item, not a category of spend.

‍

For fee ranges by company size, scope and auditor tier, see how much SOC 2 costs. That page is where the numbers are maintained.

‍

Two things worth knowing before you budget:

  • Roughly 90% of SecureLeap engagements are Security-only scope. Availability, confidentiality, processing integrity and privacy get added far less often than founders expect when they first read about the five Trust Services Criteria.
  • Buying Type 1 and Type 2 as a single engagement typically saves 10% to 15% versus commissioning them separately, because readiness work and the system description are not repeated.

‍

Full breakdown, including the year-one costs nobody quotes you: how much SOC 2 costs.

‍

Frequently Asked Questions

‍

What is the main difference between SOC 2 Type 1 and Type 2?

Type 1 is a point-in-time assessment of whether controls are designed correctly on a specific date. Type 2 tests whether those same controls actually operated effectively across a period of 3 to 12 months. Same criteria, same auditor, different depth.

‍

How long does the SOC 2 Type 2 observation period have to be?

There is no fixed minimum in the standard. In practice it runs 3 to 12 months. Three months is common for a first report, and six months is the point at which the report can be relied upon by a buyer's own auditors.

‍

How long does a SOC 2 audit take?

A Type 1 typically takes 4 to 8 weeks once you are ready. A Type 2 takes the length of the observation window plus 4 to 8 weeks for fieldwork and reporting.

‍

Does SOC 2 Type 2 cost more than Type 1?

Yes, because the auditor samples evidence across the observation period rather than assessing a single date. Company size, scope and auditor tier drive the total more than the report type does, and the audit fee is only 30% to 40% of what SOC 2 costs overall. Fee ranges are in our SOC 2 cost guide.

‍

Should a startup choose SOC 2 Type 1 or Type 2?

Most pre-Series A startups start with Type 1 because they lack the control history a Type 2 requires. Companies with enterprise or regulated buyers in the pipeline usually go straight to Type 2.

‍

Can I close an enterprise deal with only a SOC 2 Type 1?

Sometimes, usually with conditions. Mid-market buyers often accept a Type 1 plus a dated commitment to Type 2. Enterprise procurement and any buyer whose external auditor will rely on the report generally require Type 2.

‍

What are the most common reasons a first SOC 2 Type 2 fails?

Almost always sustained execution, not control design. The four that recur most: controls set up for the Type 1 and not checked again until the audit, onboarding training that new hires never completed, policies never reviewed within their own annual review cycle, and vendors added mid-period that never went through vendor review. In each case the control was designed correctly and then not maintained.

‍

How does evidence collection differ between Type 1 and Type 2?

In a Type 1 the auditor usually needs one piece of evidence per control to confirm it exists and is designed properly. In a Type 2 they test whether the control operated, so for many controls they request your full population and select a sample themselves. For security awareness training, a Type 1 may accept one employee's completion record, while a Type 2 auditor picks several employees from your full employee list and checks each one.

‍

Can we skip Type 1 and go straight to Type 2?

Yes, and it is the right call when your controls are already mature. The risk is that inconsistent execution during the observation window becomes documented exceptions in the final report.

‍

How long is a SOC 2 report valid?

Reports are generally treated as current for 12 months from the period end date. A bridge letter covers the gap between your report's end date and a buyer's review date.

‍

Is SOC 2 mandatory?

No. SOC 2 is not required by law in most jurisdictions, but it has become a de facto requirement for SaaS and cloud vendors selling to mid-market and enterprise buyers.

‍

Get the right report the first time

Choosing the wrong report type costs a quarter. Choosing the right one, with the right criteria in scope and the right observation window, is the difference between a report that closes deals and one that raises questions.

Talk to SecureLeap about which report your buyers will actually accept, or see our SOC 2 consulting services.

‍

‍

Relevant Articles

View all

SOX vs. SOC: Why They're Not the Same Thing For Startups

SOX is a federal law for public companies, while SOC is an AICPA audit report. Here's when a startup needs each one and the differences between them.
Read more

SOC 2 Background Checks for Startups: What's Required

SOC 2 background check requirements for startups: what SOC 2 actually expects, and how to document it before your audit.
Read more

SOC 2 for EU Startups: Costs, Timing, and When to Pursue

When should European startups get SOC 2 certification? Real costs in EUR and GBP, timeline guidance, and how SOC 2 fits with ISO 27001.
Read more