What Is
SOC 2?

SOC 2 is an attestation framework from the AICPA (American Institute of Certified Public Accountants) under which an independent licensed CPA firm examines a service organization’s controls over customer data — against the Trust Services Criteria for security, availability, processing integrity, confidentiality, and privacy — and issues a detailed report containing its opinion. It is a report, not a certificate. The framework exists to solve a trust problem at scale: modern companies hand critical data and operations to vendors, and every one of those customers needs assurance that the vendor protects what it holds. Instead of each customer auditing each vendor, the vendor undergoes one examination by a licensed CPA firm and shares the resulting report — usually under NDA — with any customer who asks. This page is the plain-English reference: what SOC 2 stands for, what the criteria cover, the difference between Type 1 and Type 2, who actually needs a report, and what “SOC 2 compliant” really means.

SOC stands for System and Organization Controls — the AICPA’s name for its family of examinations of service organizations. (The acronym originally meant “Service Organization Control”; the AICPA renamed it, and the letters survived.) The “2” distinguishes this framework from its siblings: SOC 1 deals with controls relevant to financial reporting, SOC 3 is a public summary, and SOC 2 — the one this page covers — deals with controls over the security and handling of customer data.

Under the hood, a SOC 2 is an attestation engagement performed under the AICPA’s attestation standards (the SSAEs — specifically AT-C sections 105 and 205). Three sets of rules shape the result: the attestation standards govern how the auditor examines and reports; the description criteria (DC section 200) define what the company’s system description must contain; and the Trust Services Criteria (the 2017 criteria, with points of focus revised in 2022) are the yardstick the controls are measured against. You don’t need to memorise the citations — but they explain why every genuine SOC 2 report looks structurally similar no matter who wrote it.

“Attestation” is worth a plain-English beat, because it is the word that makes SOC 2 different from a certification. In an attestation engagement, management makes a written claim — our description of the system is accurate, and our controls meet the criteria — and the CPA firm independently examines that claim and reports on whether it holds up. The CPA profession is the vehicle deliberately: licensed firms are bound by independence rules, professional standards, and external oversight, which is what gives a customer in another country a reason to rely on a document they didn’t commission.

One consequence of being an attestation engagement matters more than the rest: only an independent, licensed CPA firm can perform a SOC 2 examination and sign the opinion. Consultants and compliance platforms can prepare you — often very well — but they cannot issue the report. Our guide on who can perform a SOC 2 audit covers exactly where that line sits.

Enterprise buyers overwhelmingly ask for Type 2 — a snapshot says little about whether access reviews actually happened every quarter. A Type 1 still has a role as a first milestone: it proves the control set is in place while the Type 2 review period runs. The full trade-offs, including when a Type 1 is worth doing at all, are in SOC 2 Type 1 vs Type 2.

No law or regulator mandates SOC 2. It is demand-driven: buyers write it into procurement requirements, security questionnaires, and contracts, which makes it “commercially mandatory” for the vendors who want those deals. The honest test is not your industry — it is whether the organizations you sell to ask for it. In practice, the ones asked most often are:

• SaaS companies and cloud-hosted platforms holding customer data.
• Managed service providers (MSPs) and managed security providers with standing access to client environments.
• Data processors — analytics, BPO, support platforms — handling other companies’ customer records.
• Fintech infrastructure and payments-adjacent services, where both data sensitivity and buyer scrutiny run high.
• Any service organization whose enterprise prospects send security questionnaires that end with “please attach your SOC 2 report.”

The trigger moment is usually commercial, not regulatory: a first serious enterprise deal stalls in security review, or a renewal suddenly arrives with a vendor-risk questionnaire attached. Companies that wait for that moment end up running readiness under deal pressure; companies that see enterprise buyers on their roadmap tend to start earlier, so a report — or at least a Type 2 review period already underway — exists before procurement asks for it.

One note for Indian companies: Indian SaaS and IT-services firms selling into US and global enterprise face SOC 2 requests constantly — it has become table stakes in enterprise procurement. The framework itself does not change with geography: wherever the company operates, the examination still comes from a US-licensed CPA firm applying the same AICPA standards.

• Section 1 — the independent service auditor’s report: the CPA firm’s opinion, the scope, the criteria, and the period covered. The page most readers should open first.
• Section 2 — management’s assertion: the service organization’s own written claim that the description is accurate and the controls were suitably designed (and, for Type 2, operating effectively).
• Section 3 — the system description: the services, infrastructure, software, people, procedures, and data in scope, written by management against DC section 200.
• Section 4 — the description of tests and results: the controls matrix showing each control, how the auditor tested it, and what the tests found — including any exceptions. The heart of a Type 2.
• Section 5 — other information (optional): management’s responses to exceptions, future plans, or additional context. The auditor expresses no opinion on this section.

Two parts of the system description reward close reading: the treatment of subservice organizations (the vendors your vendor relies on, and whether their controls are carved out), and the complementary user entity controls — the things the report assumes you, the customer, are doing. For a section-by-section walkthrough of where to look first and what the red flags are, the deep dive is how to read a SOC 2 report.

• “SOC 2 is a certification.” No — it is an attestation examination that produces a report containing a CPA firm’s opinion. There is no certificate, no badge-issuing body, and no official register of “SOC 2 certified” companies.
• “SOC 2 is a security checklist.” The Trust Services Criteria are outcome-based criteria, not a prescribed control list. You design controls that meet the criteria for your system — two companies can satisfy the same criterion in different ways.
• “A compliance tool makes you SOC 2 compliant.” Automation platforms help you organise controls and evidence, and they genuinely reduce effort — but no tool can grant SOC 2 status. Only an independent licensed CPA firm’s examination produces the report.
• “SOC 2 covers GDPR and privacy law.” Different instruments. The Privacy category examines controls over personal information against the AICPA’s criteria; it is not a legal-compliance opinion on GDPR, India’s DPDP Act, or any other statute.
• “One report lasts forever.” Reports describe a specific period. In practice buyers treat a report as stale once it is roughly 12 months past the period end — which is why organizations run annual re-examinations.