SOC 1 Type 1 vs Type 2: which one your buyer is asking for
SOC 1 Type 1 vs Type 2 explained: point-in-time design versus operating effectiveness over 3 to 12 months, and which report a user auditor actually wants.
Dev Agarwal, CPALicensed CPA · FounderA customer's external auditor emails your CFO asking for "the SOC 1." You have two quotes on your desk. One is for a Type 1, priced and scoped for next month. The other is for a Type 2, priced for a twelve-month observation window. Which one satisfies the request?
The short version below, then the mechanics.
The short answer
A SOC 1 Type 1 reports on whether your controls were suitably designed as of a single date. A SOC 1 Type 2 reports on whether those same controls operated effectively over a period of three to twelve months. Both reports are attestation engagements performed under AT-C section 320 of SSAE No. 18, the AICPA attestation standard that governs service auditor examinations.
What a SOC 1 report covers
SOC 1 is scoped to Internal Control over Financial Reporting (ICFR). It exists because your customers' financial statements depend, in part, on your systems. When a public company's PCAOB-registered auditor signs off on that filer's financials, the auditor needs comfort that the controls at every service organization in the reporting chain are working. Your SOC 1 is how they get that comfort without sending their own team to audit you.
The service organizations that most often need SOC 1 are the ones touching numbers that roll up to somebody else's financial statements:
- Payroll processors and PEOs.
- Claims adjudicators and TPAs.
- Managed accounting, outsourced bookkeeping, and fund administrators.
- Custodians and transfer agents.
- Loan servicers and billing platforms that cut customer invoices.
- Revenue-relevant SaaS where the system of record is yours, not theirs.
If your product is sold to security teams and the buyer is worried about data breaches rather than audit opinions, you probably want SOC 2 instead. If your product calculates, holds, or moves numbers that end up on a 10-K, you want SOC 1.
SOC 1 Type 1: point-in-time design
A Type 1 answers one question: on a specific date, were the controls described in management's assertion suitably designed to achieve the stated control objectives?
The auditor walks through each control, confirms it exists, confirms it was built to do what it claims, and confirms the evidence for that design is in place on the as-of date. No sample of transactions. No three-month window. A single photograph of the control environment.
Type 1 makes sense in three situations:
- You just launched the service. There is no six-month history to sample, so a Type 2 has nothing to test. Type 1 lets you give a customer a real deliverable while you accrue the operating history.
- It is your first audit. Running a Type 1 first surfaces design gaps cheaply, before you commit to a twelve-month Type 2 observation window where the same gaps would generate exceptions every time they recur.
- You have a short runway to a customer deadline. A prospect's user auditor wants something attached to the vendor file by quarter end. Type 1 is the honest way to ship something meaningful in six to ten weeks.
What a Type 1 will not do: satisfy a PCAOB firm auditing a filer's annual financials. They will ask for the Type 2 next year regardless.
SOC 1 Type 2: operating effectiveness over a period
Type 2 is what most requests actually mean. The observation window is typically 3, 6, 9, or 12 months. Twelve months is the default for mature service organizations because it aligns with customers' fiscal years and removes the need for a bridge letter (more on those below). Shorter windows show up for first-year reports, newly in-scope subservice organizations, or short-form reports ahead of a major deadline.
Inside the window, the auditor does two things the Type 1 auditor does not:
- Samples transactions. Sample sizes follow AICPA guidance in the SOC 1 audit guide and depend on control frequency. A daily control might get 25 samples across the window; a weekly control might get 8 to 12; a monthly control 2 to 5; quarterly controls get one or two. The tester is confirming the control operated every time it was supposed to, not only on the day you showed up.
- Lists exceptions. Every sampled failure appears in Section 4 with a management response. A clean report does not have to be zero exceptions (see what a SOC 2 report actually tells your buyer, the same dynamic applies). It has to be unqualified and honest.
What user auditors actually want from a Type 2: coverage of their audit period, an unqualified opinion, a scope that includes the processes their client relies on, and complementary user entity controls (CUECs) written clearly enough that they can test them on their side.
Which one your customers actually ask for
Here is the pattern we see most often.
A private-company buyer with no PCAOB overhang will take a Type 1 the first year and a Type 2 thereafter. They want to know a real auditor looked at your system.
A PCAOB firm auditing a public-company filer almost always requires a Type 2 whose observation window covers the filer's fiscal year. The same expectation applies to ERISA plan auditors; the AICPA's employee-benefit-plan SOC 1 resource center explains how plan auditors rely on Type 2 reports to reduce substantive testing. If the filer's year ends December 31, the user auditor wants a Type 2 covering, at minimum, January through September, plus a bridge letter for October through December. A Type 1 does not satisfy the integrated-audit standard on its side. That is the single most common reason a customer escalates.
If you sell into both groups, plan for Type 2 as the steady state and use Type 1 only as a bridge to your first Type 2.
When to do Type 1 first
Do a Type 1 first when all three of these are true:
- The service has been live for less than six months, or the scope has materially expanded.
- Your customers need proof of an audit now, not in a year.
- You have not run the controls long enough to defend a sample-based test without embarrassment.
Otherwise, skip directly to Type 2. The mirror-image decision on the SOC 2 side lives in SOC 2 Type I vs Type II; the logic is the same, the audience is different.
Type 1 buys you a deliverable. Type 2 buys you a renewal.
Bridge letters, gap periods, and stitching two Type 2s together
A Type 2 covers a defined period. The day it ends, the clock starts on a gap that your customer's auditor will ask about. You close that gap with a bridge letter (sometimes called a gap letter): a signed statement from management that, to the best of its knowledge, the controls described in the most recent SOC 1 Type 2 have continued to operate and no material changes have occurred since the report date.
Bridge letters are not audited. They are management assertions, typically covering one to three months. Four months is the outer edge of what user auditors accept; beyond that, most will ask for a short-form Type 2 instead.
The durable pattern for a service organization with a calendar-year fiscal client base is two overlapping or adjacent Type 2s per year, plus a bridge letter covering any gap:
- Type 2 #1: January 1 to September 30.
- Bridge letter: October 1 to December 31.
- Type 2 #2: October 1 to September 30 of the following year, or a full calendar-year Type 2 starting January 1.
Get the mechanics and the signer right, and your user auditors stop calling. We wrote a separate walkthrough on bridge letters for the SOC 2 case; the format is identical for SOC 1.
How SOC 1 relates to SOC 2
SOC 1 is about ICFR. SOC 2 is about vendor trust, security, availability, processing integrity, confidentiality, privacy. A buyer's security team asks for SOC 2. A buyer's finance team and their auditor ask for SOC 1. (If your buyer asks for a public-facing assurance marker rather than a restricted-use report, see SOC 3 reports.)
Many of our clients need both because they sell into procurement committees that include both groups. The control libraries overlap on the infrastructure side (access management, change management, backups) but diverge on the business-process side. A SOC 1 tests that payroll taxes were calculated and remitted accurately; a SOC 2 tests that the payroll system was available and its data was not disclosed without authorization. Same company, different questions. SOC 1 vs SOC 2 walks through the decision for companies deciding whether to run one or both, and what is a SOC 1 report is the pillar piece if you are still orienting to SOC 1 itself.
If your prospect's auditor has asked for "the SOC 1" and you have not scoped the engagement yet, the first question to answer is whether that auditor needs the report to cover their client's fiscal year. The answer tells you Type 1 or Type 2, and everything else falls out of it.
If you are sizing a first SOC 1 and trying to decide between Type 1 now and Type 2 next year, get in touch or see the services we offer, we will help you pick the scope that answers the customer's question without paying twice.