SOC 2
SOC 2 is the report enterprise buyers ask for when they want proof that a vendor handles their data responsibly. It isn't a certificate or a badge — it's an attestation report written by a licensed CPA firm after they examine your controls. If a prospect's security team just sent you a questionnaire and asked for "your SOC 2," here's the plain-language version: what SOC 2 actually is, the five Trust Services Criteria, the difference between Type I and Type II, who needs it, how the audit works, and how to get ready.
SOC 2 readiness checklist
A plain-language, area-by-area checklist.
Free readiness assessment
See your SOC 2 gaps in minutes.
Map to other frameworks
How SOC 2 lines up with ISO 27001, NIST 800-53 & HIPAA.
Illustrative statuses. Your real assessment is generated from your answers in the app. Standpoint is a self-assessment aid, not legal advice.
What is SOC 2?
SOC 2 is an attestation report, not a pass/fail certification. A service organization (usually a SaaS or B2B technology vendor) engages an independent CPA firm to examine the controls it uses to protect customer data. The CPA firm evaluates those controls against the AICPA's Trust Services Criteria and issues a report containing an independent opinion, a description of the system, and — for a Type II — the tests performed and their results. You then share that report, under a non-disclosure agreement, with customers and prospects who need assurance before they trust you with their data. Because it's an opinion by a licensed CPA, there's no certificate to frame; the deliverable is the report itself.
The five Trust Services Criteria
SOC 2 is built on five Trust Services Criteria (TSC). You don't have to cover all five — you choose which ones fit the promises you make to customers — but one is always required: Most vendors start with Security only and add criteria as customer promises grow. The Security / Common Criteria area itself is organized into groups covering the control environment, communication, risk assessment, monitoring, access, operations, and change — which is why our readiness checklist is grouped the same way.
Type I vs. Type II
Type I — Whether your controls are suitably designed at a single point in time. Faster to obtain; a reasonable first milestone. Type II — Whether those controls also operated effectively over a period — commonly 3 to 12 months. This is the report most enterprise customers ultimately ask for, because it shows the controls work over time, not just on paper. There are two flavors of SOC 2 report, and enterprise buyers usually want the second: A common path is to do a Type I first to prove design, then run an observation period and follow with a Type II covering that window.
Who needs SOC 2?
SOC 2 is aimed at service organizations that hold or process other companies' data — most often SaaS and B2B (business-to-business) technology vendors selling into the enterprise. Teams typically pursue it when: - a prospect's security or procurement team makes a SOC 2 report a condition of the deal; - they're moving upmarket and larger buyers demand independent assurance; - they want a recognized, third-party-validated way to answer security questionnaires faster; - a partner or platform they integrate with requires it of vendors.
How the SOC 2 process works
At a high level, getting to a SOC 2 report follows a predictable arc: - Define scope. Decide which Trust Services Criteria apply and which systems and services are covered. - Readiness. Run a gap assessment, implement missing controls, and write the policies and procedures that back them. - Observation period. For a Type II, let the controls operate for a set window (commonly 3–12 months) while you collect evidence. - CPA audit. A licensed CPA firm examines your controls and tests the evidence. - Report. The CPA firm issues the SOC 2 report with its opinion; you share it under NDA with customers.
How SOC 2 relates to ISO 27001 & NIST
They overlap heavily. ISO 27001 is a certifiable information-security management-system standard — an accredited body issues an actual certificate — whereas SOC 2 is a CPA attestation report; both cover much of the same control ground, so evidence gathered for one advances the other. NIST SP 800-53 and NIST CSF 2.0 are U.S. control catalogs and frameworks whose controls map closely to the SOC 2 Common Criteria. Because the controls line up, the access reviews, logging, change management, and risk-assessment work you do for SOC 2 also carries into these frameworks. See the SOC 2 crosswalk for t…
SOC 2 work counts elsewhere too
The crosswalk maps your SOC 2 evidence onto the frameworks it overlaps — so you move forward on several at once.