SOC 2 Type I vs. Type II: What Mid-Market SaaS and Fintech Need
Enterprise buyers don’t ask for “a SOC 2” — they ask for a specific type, and the difference determines whether your report proves your controls are designed correctly or proves they actually worked for months.
Schedule a Consultation →A SOC 2 report is an attestation, issued by an independent licensed CPA firm under AICPA attestation standards (SSAE 18 / AT-C 205), on how a service organization’s controls measure up against the AICPA’s Trust Services Criteria. It is not a certification and not a pass/fail exam — it is an auditor’s opinion, and that opinion comes in two distinct types that answer two different questions.
A Snapshot vs. a Track Record
Point-in-time design opinion
Confirms that controls were suitably designed as of a single specified date. There is no testing of whether those controls actually operated correctly over any stretch of time. A Type I engagement can be issued in a matter of weeks once policies and controls are documented and in place.
Operating-effectiveness opinion
Confirms both design and that controls operated effectively across an observation window — typically a minimum of three months, commonly six months for a first report, and twelve months for ongoing annual renewals. The auditor samples real evidence — access logs, deployment records, ticket history — generated during that window. It cannot be assembled retroactively; the controls have to be running and producing evidence before the window even opens.
Which One Do Enterprise Buyers Actually Require?
Type II is increasingly the real bar. A Type I report is sometimes accepted as an interim milestone — a signal that a young company has a documented control environment and is on a credible path — but most enterprise security review teams and vendor risk management questionnaires now ask for Type II explicitly, because a design opinion says nothing about whether the access reviews, log monitoring, or change-management gate actually happened on any given week. Deals commonly stall at security review specifically because the vendor can only produce a Type I, or no report at all, when the buyer’s procurement policy requires Type II.
For a worked example of what closing that gap looks like end-to-end — the control build, the observation period, and what changed operationally — see our case study on how a fintech startup reached SOC 2 Type II in six months.
When Starting With Type I Still Makes Sense
Type I is not obsolete. A company six months past its first enterprise deal, with no prior compliance program, cannot manufacture a six-month operating history retroactively — the observation window only starts counting once the controls are actually running. A Type I report, produced quickly, gives sales a credible artifact to show mid-cycle while the Type II observation window is already open in the background. What does not work is treating Type I as a permanent substitute: once a buyer’s security questionnaire explicitly requires Type II, a Type I report answers a different question than the one being asked, and the deal stalls until the real report exists.
The Trust Services Criteria
Both types are scoped against the same five Trust Services Criteria. Only one is mandatory — the other four are add-ons chosen based on what your service actually does and what you’re attesting to.
Security Required
The Common Criteria, CC1–CC9: access control, change management, monitoring, and system operations. Every SOC 2 report includes it.
Availability
Systems are available for operation and use as committed — relevant to SaaS platforms with uptime SLAs.
Confidentiality
Information designated confidential is protected — common for fintech and B2B platforms handling client data.
Processing Integrity
Processing is complete, valid, accurate, and timely — relevant to payment and transaction-processing platforms.
Privacy
Personal information is collected, used, retained, and disposed of per commitments — relevant when consumer PII is in scope.
What the Path to Type II Actually Involves
The sequence is consistent regardless of company size: a gap assessment against the selected Trust Services Criteria, a written policy set with a named owner and evidence artifact for every control, implementation work to close identified gaps (access review cadence, change-management gates, encryption, logging), the observation window itself where those controls run and generate evidence as a byproduct of normal operations, and finally auditor fieldwork and report issuance. Note that a SOC 2 report is restricted-use — shared with customers and prospects under NDA, not published publicly. Organizations that want a public-facing summary typically also commission a SOC 3 report, which covers the same criteria at a higher level of abstraction.
Security awareness and training — covered under Common Criteria CC1.4 — is one of the control areas auditors sample directly. If that program is a once-a-year video, it is a common source of exceptions; see our guide to building a security awareness and phishing simulation program that actually holds up under Type II testing. And because most of the infrastructure controls behind CC6 and CC7 map directly onto the NIST Cybersecurity Framework’s Protect and Detect functions, organizations that build a CSF profile first tend to move through SOC 2 gap assessment faster.
Stuck Between a Type I and a Deal That Needs Type II?
Armorstack builds SOC 2 programs around continuous evidence generation from day one of the observation window, not a scramble before the auditor arrives. Let’s talk about your Trust Services Criteria and your timeline.
Schedule a Consultation →