SOC 2

Definition: An auditing standard that verifies a company’s systems are designed and operated securely, based on five “trust service criteria”: security, availability, processing integrity, confidentiality, and privacy.

How It Works

An independent CPA firm (a licensed auditor) reviews a company’s actual security controls and practices against the trust service criteria, security is mandatory, the other four are optional depending on scope
Controls typically cover access management, encryption, change management, monitoring/logging, vendor management, and incident response
Type I report: verifies controls are designed correctly at a single point in time, a snapshot
Type II report: verifies controls actually operated effectively over a period, commonly 3-12 months, a much stronger signal because it proves the controls work in practice, not just on paper
The result is an auditor’s report, not a certificate or badge, the report itself is usually shared under NDA with prospective customers, not published publicly
Report sections include management’s assertion, the auditor’s opinion, a system description, and a detailed list of controls tested with any exceptions noted
Scope is chosen by the company being audited, so two companies’ SOC 2 reports can cover meaningfully different sets of systems and criteria
Subservice organizations (cloud providers, payment processors, other vendors the company relies on) can be handled two ways: “carve-out” (excluded, referenced only) or “inclusive” (their controls tested as part of the same report)

Trust service criterion	What it covers	Required?
Security	Protection against unauthorized access, the baseline	Always
Availability	Systems are accessible and operable as agreed	Optional
Processing integrity	System processing is complete, accurate, timely	Optional
Confidentiality	Confidential data is protected as agreed	Optional
Privacy	Personal data is collected, used, retained per policy	Optional

Under the Hood

Worked example 1: Type I timeline

Given: a 20-person SaaS startup begins a SOC 2 readiness assessment on January 1
Step 1: gap analysis takes about 4-6 weeks, flags a missing access review process and no formal incident response plan
Step 2: remediation takes roughly 6 weeks (write policies, enforce MFA, centralize logging)
Step 3: auditor is engaged, Type I fieldwork takes 2-4 weeks
Answer: Type I report is typically ready around month 4 (early May)

Worked example 2: Type II timeline

Given: the same startup needs a Type II report to unblock an enterprise deal
Step 1: observation period begins right after the Type I report, auditor sets a 6-month window (a common middle-ground length)
Step 2: controls operate and generate evidence (access logs, ticket records, review sign-offs) from June through November
Step 3: auditor performs fieldwork and sampling in December
Answer: full Type II report is issued around January, roughly 12 months after the initial readiness assessment started

Worked example 3: the bridge letter gap

Given: a company’s Type II report covers June 1 through November 30, but a prospect wants to sign a contract in February, after the report has “aged out” of most buyers’ 12-month freshness window for the next audit
Step 1: the next observation period (December-May) is still in progress and won’t produce a report until summer
Step 2: the auditor issues a “bridge letter” (also called a gap letter), a short statement that no material changes occurred between the report’s end date and the letter date
Step 3: procurement accepts the bridge letter as interim assurance while the next Type II report is finalized
Answer: a bridge letter, not a new audit, covers the gap between report periods

Worked example 4: scope decision

Given: a startup offering an analytics API must decide which trust service criteria to include beyond mandatory Security
Step 1: customers keep asking whether uptime is guaranteed, so Availability is added to scope
Step 2: the product doesn’t do financial calculations, so Processing Integrity is left out as not relevant
Step 3: the product stores customer PII, so Confidentiality and Privacy are both added
Answer: final scope is Security, Availability, Confidentiality, and Privacy, Processing Integrity is skipped because it doesn’t match what the product actually does

Why It Matters

SOC 2 Type II has become the default trust signal enterprise buyers require before signing with a B2B SaaS vendor handling sensitive data
Procurement teams often gate contract signature on a current report, no report can mean a stalled or lost deal regardless of how good the product is
The audit forces a company to actually formalize practices (access reviews, change management, logging) that many startups only do informally, if at all, before the audit
Because scope is self-defined, buyers still need to read what’s actually covered, a narrow-scope SOC 2 report is a weaker signal than a broad one
Preparing for SOC 2 tends to improve actual security posture as a side effect, not just paperwork, since controls have to genuinely operate to pass Type II testing
A carve-out vs inclusive choice for subservice organizations affects how much a buyer still has to independently vet a company’s own vendors (like its cloud provider)
Sales cycles at larger companies routinely stall for weeks waiting on a security questionnaire that a current SOC 2 report would have answered in one attachment
Exceptions noted in a report aren’t automatically disqualifying, buyers generally care more about how a company responded to a finding than whether one existed at all

Common Pitfalls

This is general information, not legal advice, work with a compliance auditor or advisor for a real audit.

Treating a SOC 2 report as a one-time achievement rather than an ongoing operational commitment, Type II audits repeat annually with a fresh observation period
Confusing SOC 2 with ISO 27001-style certification, they’re similar in spirit but structured, scoped, and audited differently
Starting the observation period before controls are actually operating consistently, producing exceptions in the final report
Scoping the audit too narrowly to make it easier to pass, then having enterprise buyers reject it as insufficient coverage
Assuming a Type I report satisfies buyers who specifically require Type II, the two aren’t interchangeable in procurement conversations
Letting the report lapse between audit cycles, leaving a gap with no current report during an active sales cycle
Bolting on controls right before the audit instead of building them into normal engineering workflow, which shows up as inconsistent evidence during testing
Choosing a “carve-out” for a critical subservice organization (like the cloud provider running production) without realizing buyers may ask for that vendor’s own SOC 2 report separately
Letting a report go stale between cycles without a bridge letter in hand, leaving a visible gap during active procurement conversations
Picking an inexperienced or unaccredited auditor to save money, producing a report enterprise security teams don’t trust or recognize
Excluding Availability or Confidentiality from scope purely to reduce audit cost, then losing a deal when the buyer specifically asks for that criterion

Comparison

	SOC 2 Type I	SOC 2 Type II	ISO 27001
What it verifies	Control design at a point in time	Control operation over a period	A full information security management system (ISMS)
Typical duration	Snapshot, a few weeks of fieldwork	3-12 month observation window plus fieldwork	Ongoing, 3-year certification cycle with annual surveillance audits
Output	Auditor’s report	Auditor’s report	Certificate
Governing body	AICPA (US)	AICPA (US)	ISO (international)
Common use case	Faster interim proof for smaller or early deals	Standard requirement for US enterprise procurement	Standard requirement for international, especially EU, procurement
Renewal	N/A, usually superseded by Type II	Annual	Annual surveillance, full recertification every 3 years
Report distribution	Restricted, shared under NDA	Restricted, shared under NDA	Public certificate, report details usually private
Cost driver	Auditor fieldwork days	Fieldwork plus longer evidence collection	Certification body fees plus ongoing ISMS maintenance

Many companies pursuing both, especially those selling into the US and EU, end up running SOC 2 and ISO 27001 in parallel rather than choosing one, since the underlying controls overlap heavily even though the audit mechanics differ.

Example

It’s now standard practice for venture-backed SaaS startups to pursue SOC 2 Type II specifically to unblock enterprise sales, often using compliance automation platforms like Vanta or Drata to track control evidence continuously rather than scrambling before each audit. Procurement teams at large enterprises routinely include “current SOC 2 Type II report” as a checklist item in vendor security review, before a contract can even move to legal review.

Major SaaS platforms publish public trust pages that reference their SOC 2 status as part of vendor due diligence, Salesforce’s Trust site and Slack’s security page are two widely known examples, letting prospective customers self-serve basic compliance answers instead of requesting the full report for every deal.

SOC 2 and HIPAA are frequently paired in healthcare-adjacent products: HIPAA is a legal requirement for PHI specifically, while SOC 2 is a voluntary audit that can demonstrate broader security maturity to any buyer, healthcare or not.

Referenced by

Dig deeper

Spot an error in this note?