SOC 2 (System and Organization Controls 2) is an attestation framework of the American Institute of Certified Public Accountants (AICPA) under which an independent CPA firm examines a service organization’s controls and reports on them against the Trust Services Criteria. It is the most common way for cloud, SaaS and outsourcing providers to show customers that their systems protect customer data.
Among security standards in cybersecurity, SOC 2 is distinctive because it is an audit report, not a certification. There is no pass or fail badge; the result is a detailed report with an auditor’s opinion, a description of the system and, in a Type II report, the results of testing each control over a period of time.
How a SOC 2 examination works
The service organization defines the scope of the system: the services, infrastructure, software, people, procedures and data involved. Management then writes a system description and an assertion that its controls meet the selected criteria, and the auditor examines that assertion under the AICPA attestation standards.
The organization designs its own controls. SOC 2 sets criteria to be met, not a fixed list of controls, so two companies can satisfy the same criterion in different ways, for example one with hardware security keys and another with a different strong authentication method.
| Section | Content | What readers look for |
|---|---|---|
| Auditor’s opinion | Conclusion on the description and controls | Unqualified opinion versus qualified or adverse |
| Management assertion | Statement signed by the organization | Scope and period claimed |
| System description | Services, components, boundaries, subservice providers | Whether the purchased service is in scope |
| Controls and test results | Each control, test performed and result | Exceptions and their explanations |
| Complementary user entity controls | Controls the customer must operate | Responsibilities left to the customer |
The Trust Services Criteria
The Trust Services Criteria are organized into five categories. Security is mandatory in every SOC 2 examination and is expressed through the common criteria; the other four are added when they matter to customers.
| Category | Question it addresses | Typical controls |
|---|---|---|
| Security | Is the system protected against unauthorized access | Access reviews, MFA, logging, vulnerability management |
| Availability | Is the system available as committed | Capacity monitoring, backups, disaster recovery tests |
| Processing integrity | Is processing complete, accurate and timely | Input validation, reconciliations, error handling |
| Confidentiality | Is confidential information protected | Encryption, data classification, secure disposal |
| Privacy | Is personal information handled as committed | Notice, consent, retention, data subject requests |
The common criteria, numbered CC1 to CC9, follow the COSO internal control framework and cover the control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management and risk mitigation including vendor management.
Type I and Type II reports
The report type determines whether controls were only designed or also proven to operate. Most customers and procurement teams expect a Type II report from mature vendors.
| Attribute | Type I | Type II |
|---|---|---|
| What is evaluated | Design of controls | Design and operating effectiveness |
| Time frame | A single date | A review period, usually 3 to 12 months |
| Testing | Inspection of design and implementation | Sampling of evidence across the period |
| Typical use | First report, early-stage vendors | Ongoing assurance for customers |
| Assurance level | Lower | Higher |
Because a Type II report covers a past period, customers often request a bridge letter: a management statement that no significant changes occurred between the end of the period and the current date. Reports are generally treated as current for about 12 months.
SOC 2 compared with related standards
SOC 2 is frequently weighed against ISO 27001, and the two overlap substantially in control content while differing in form, geography and output.
| Framework | Nature | Output | Typical audience |
|---|---|---|---|
| SOC 1 | Attestation on controls over financial reporting | Restricted report | Customers’ financial auditors |
| SOC 2 | Attestation on security and related criteria | Detailed restricted-use report | Customers under NDA |
| SOC 3 | Summary attestation on the same criteria | General-use report | Public and marketing use |
| ISO 27001 | Certification of a management system | Certificate with defined scope | International customers |
| NIST CSF | Voluntary framework for managing risk | Self-assessed profiles | Internal governance |
Many providers hold both SOC 2 and ISO 27001, reusing evidence across audits. SOC 2 dominates in North American procurement, while ISO 27001 is more widely requested in Europe and Asia.
Preparing for SOC 2 and common pitfalls
Preparation usually starts with a readiness assessment that maps existing controls to the criteria and identifies gaps. The first Type II period can begin only after the controls actually operate, so a realistic timeline from start to first Type II report is often 6 to 12 months.
- Scoping too broadly increases cost and the chance of exceptions; scope should match what customers buy.
- Undocumented controls fail testing even when people perform them, because auditors need evidence.
- Ignoring subservice organizations: carve-out treatment relies on the cloud provider’s own SOC 2 report.
- Treating it as a one-time project: Type II requires continuous evidence every period.
- Customers skipping the report details: exceptions and complementary user entity controls are where real risk shows.
Explained without jargon
When a company hands its data to a software provider, it wants proof that the provider takes good care of it. A SOC 2 report is that proof: an independent auditor checks how the provider protects data and writes down what was found.
The best version does not just look at the rules on paper. It checks that the rules were actually followed for months, much like a restaurant inspector who returns repeatedly instead of visiting once.
A typical use case
A fifty-person software company sells payroll analytics to mid-sized employers. Its sales team keeps losing deals at the security review stage because enterprise buyers ask for a SOC 2 Type II report before signing. The company runs a readiness assessment, introduces quarterly access reviews, formal change approvals and centralized logging, and starts a six-month observation period.
The resulting report covers the security and confidentiality categories and contains an unqualified opinion with two minor exceptions on late access removals, each with a documented response. Buyers now receive the report under a nondisclosure agreement instead of a long questionnaire, and the security review shortens from several weeks to a few days for most new customers.