What Is SOC 2? A Plain-English Guide
What is SOC 2? An AICPA attestation report on your security controls that buyers demand before they sign. Type I vs II, the 5 criteria, and how to get one.
What is SOC 2? The one-sentence version
So, what is SOC 2? In plain terms, it’s an independent report, produced by a licensed CPA firm, that describes the security controls your company uses to protect customer data and gives an outside opinion on whether those controls are designed well and — for a Type II — actually operating.
That is the whole idea. A prospect wants to hand you their data. Before they do, they want evidence that you run a tight ship. Rather than take your word for it or audit you themselves, they ask for your SOC 2 report: a document a trusted third party has already vetted. You prove your security posture once and reuse that proof with every customer who asks.
SOC 2 stands for “System and Organization Controls 2.” It is governed by the AICPA (the American Institute of Certified Public Accountants), the same body that sets the standards CPAs use for financial audits.
Who needs SOC 2, and why
SOC 2 is almost always customer-driven. Nobody wakes up wanting one; a deal forces it. The usual triggers:
- A prospect’s security questionnaire or vendor review stalls the deal until you can produce a report.
- You sell to mid-market or enterprise buyers whose procurement and security teams require SOC 2 from any vendor that touches their data.
- You are a SaaS, infrastructure, fintech, or data-processing company — if customer data flows through your systems, expect the ask.
- Your competitors already have it, and you are losing deals where security is a checkbox.
The pattern is a chain of trust. Your customers have their own customers and their own auditors, and every vendor they buy becomes part of their attack surface, so they push their security requirements down to you. In North America, SOC 2 is the standard artifact that satisfies that push. If you sell to companies that care about security, you will be asked for it — usually right when a real contract is on the table.
The AICPA and SSAE 18 basis (what makes it credible)
A SOC 2 engagement is an attestation performed under the AICPA’s attestation standards, SSAE 18 (Statement on Standards for Attestation Engagements No. 18). Two things follow, and both matter:
- Only a licensed CPA firm can issue a SOC 2 report. A consultancy or a software tool can help you prepare, but the report itself must come from an independent auditor. That is why it carries weight: a regulated professional is putting their license behind an opinion.
- The auditor gives an opinion, not a grade. As in a financial audit, the deliverable is a professional judgment — unqualified (clean), qualified (largely sound, with noted exceptions), adverse, or a disclaimer. There is no score.
This is also why “SOC 2 certified” is technically wrong. There is no certificate and no certifying body. You do not pass or fail SOC 2 the way you pass ISO 27001 certification; you receive an attestation report. If you are weighing the two frameworks, that reporting model is one of the biggest practical differences — see SOC 2 vs ISO 27001.
What a SOC 2 report actually is
A finished SOC 2 report is a detailed PDF, often dozens of pages long and sometimes past 100, with a consistent structure:
- The auditor’s opinion letter — the CPA firm’s formal conclusion.
- Management’s assertion — your own written claim about your system and controls.
- A system description — how your service works, where its boundaries are, and the infrastructure and people involved.
- The controls, the criteria they map to, and the auditor’s tests and results — the core of the report, where each control is listed against the relevant criteria, with any exceptions noted.
You do not publish this document. It contains sensitive detail, so it is shared under NDA with prospects and customers who ask. For lighter-weight assurance, many buyers will accept a SOC 3 report — a short, public-facing summary derived from the same audit.
Type I vs Type II at a glance
SOC 2 comes in two flavors, and the difference is time.
| Type I | Type II | |
|---|---|---|
| What it attests | Control design at a single point in time | Control operating effectiveness over a period |
| Question it answers | ”Are the right controls in place today?" | "Did the controls actually work, consistently, over months?” |
| Time covered | A specific date | A window, commonly 3-12 months |
| Evidence | Controls exist and are designed properly | Controls ran as intended across the whole period |
| Buyer preference | Weaker; a snapshot | Stronger; what most enterprises want |
| Typical use | A fast first milestone | The report that closes serious deals |
Type I proves you set up the right controls. Type II proves you lived by them day after day. Because Type II requires a period of evidence, it takes longer — and it is the report most buyers actually want. Many startups run a Type I first as a quick win, then roll straight into a Type II observation window; others skip Type I and go directly to Type II. We break the tradeoff down in Type I vs Type II.
The 5 Trust Services Criteria at a glance
SOC 2 is built on the Trust Services Criteria (TSC). There are five — and here is the part people miss: you do not do all five. You pick the ones that fit your service.
| Criterion | Covers | Required? |
|---|---|---|
| Security (Common Criteria) | Protecting systems and data against unauthorized access — access control, change management, risk assessment, monitoring | Always. The baseline every report includes. |
| Availability | The system is up and reachable per your commitments — uptime, monitoring, DR, incident response | Optional |
| Processing Integrity | Processing is complete, valid, accurate, timely, and authorized | Optional |
| Confidentiality | Information designated confidential is protected (e.g., encryption, access limits) | Optional |
| Privacy | Personal information is collected, used, retained, and disposed of per your notice and criteria | Optional |
Security — the Common Criteria — is mandatory in every SOC 2. The other four are added only when they are relevant to what you promise customers. A pure infrastructure provider often adds Availability; a payments engine might add Processing Integrity; a company handling a lot of PII might add Confidentiality or Privacy. Each added criterion means more controls and more evidence, so most first-timers scope tightly — Security only, or Security plus Availability. The full breakdown lives in The 5 Trust Services Criteria, Explained.
The high-level path to getting one
Every SOC 2 project follows roughly the same arc:
- Scope it. Decide Type I or Type II, which Trust Services Criteria apply, and which systems and products are in bounds. Tight scope early saves real money later.
- Gap assessment. Measure your current controls against the criteria and find what is missing — MFA everywhere, formal access reviews, a change-management process, logging, an incident-response plan, vendor management, written policies.
- Remediate. Close the gaps. For a startup this is usually the longest phase, because it is real engineering and process work, not paperwork.
- Collect evidence. For a Type II, you must show the controls operated across the whole observation window — access reviews actually happened, alerts were triaged, backups ran. This is where automation earns its keep: continuously pulling evidence from your cloud, identity, and code systems beats screenshotting on the last day.
- The audit. A CPA firm tests your controls and evidence, then issues the report.
- Maintain and renew. SOC 2 is not one-and-done. Type II reports cover a period, so you renew on a rolling basis, typically once a year.
Timelines vary widely by starting posture and scope. A prepared startup can reach a Type I in weeks and a Type II a few months after that; teams starting from scratch take longer. See How Long Does SOC 2 Actually Take? and How Much Does SOC 2 Cost in 2026? for the drivers behind both.
The manual version of this — chasing evidence in spreadsheets, writing policies from blank pages, mapping controls by hand — is where most of the pain and cost live. Compliance automation platforms like avow connect to your stack, map controls to the criteria, and collect evidence continuously, so the audit becomes a review rather than a fire drill.
Where to go next
If you are scoping SOC 2 for the first time, start with the SOC 2 Readiness Checklist to see concretely which controls you will need, then read up on what your first Type II audit looks like and the mistakes most startups make so you can head them off before the auditor shows up.