What is SOC 2?

Why service providers are asked for SOC 2

When a company moves payroll, customer records or source code to a cloud service, it hands part of its own risk to someone else. The customer cannot audit every supplier itself, so it asks a simple question: can you show independent evidence that you protect our data? A breach at a supplier is still a breach for the customer, and a failed security questionnaire can stop a deal in procurement.

This is the problem SOC 2 was designed to solve. The American Institute of Certified Public Accountants (AICPA) created the SOC suite of reports so that service organizations could give their customers an independent, standardized assurance report instead of answering a different questionnaire from every client. Who has access to our data? Who approves changes? How would you know if something went wrong? SOC 2 answers these questions with tested evidence.

What is SOC 2?

SOC stands for System and Organization Controls. AICPA describes SOC as a suite of service offerings that CPAs provide in connection with system-level controls of a service organization. SOC 2 is the report that addresses controls relevant to security, availability, processing integrity, confidentiality and privacy.

It is important to understand what a SOC 2 report is not. It is an attestation report issued by an independent licensed CPA firm under AICPA professional standards, not a certificate issued by a certification body. This is the clearest difference from ISO 27001, which specifies requirements for a management system and is certified by an accredited certification body against a fixed standard. In SOC 2 the criteria are fixed, but the controls that meet them are chosen by the organization.

SOC 2 is used mainly by technology and service companies such as software-as-a-service providers, data centres, managed service providers and other organizations that store, process or transmit customer data.

SOC 1, SOC 2 and SOC 3

The SOC suite contains several reports, and the choice depends on who the readers are and what they need assurance about.

• SOC 1: addresses controls relevant to the user entities' internal control over financial reporting, for example a payroll processor whose output affects the customer's financial statements
• SOC 2: addresses controls relevant to security, availability, processing integrity, confidentiality or privacy; it is a detailed report intended for customers, prospects and other parties with an understanding of the service, normally shared under a non-disclosure agreement
• SOC 3: addresses the same criteria as SOC 2 but is a general-use report without the detailed testing, so it can be published openly
• Type I and Type II: SOC 1 and SOC 2 reports can be issued as Type I (design at a point in time) or Type II (design and operating effectiveness over a period)

The five Trust Services Criteria

SOC 2 is built on the AICPA Trust Services Criteria (TSC), which are organized into five categories. The service organization and its auditor agree which categories are in scope for the engagement.

• Security: protection of information and systems against unauthorized access, disclosure and damage. Security is required in every SOC 2 report, and its criteria are known as the common criteria
• Availability: the system is available for operation and use as committed or agreed, which includes capacity, recovery and monitoring
• Processing integrity: system processing is complete, valid, accurate, timely and authorized
• Confidentiality: information designated as confidential is protected as committed or agreed
• Privacy: personal information is collected, used, retained, disclosed and disposed of in line with the organization's commitments and applicable criteria
• Only Security is mandatory. For example, a file-sharing provider would normally add Availability and Confidentiality, while a payment-processing service might add Processing Integrity

The common criteria

The security category is described by the common criteria, numbered CC1 to CC9, which are shared by all five categories. Auditors from a management-systems background will recognize the logic: governance first, then risk, then controls, then monitoring.

• CC1 Control environment: integrity, ethics, oversight by the board, structure, competence and accountability
• CC2 Communication and information: quality information and internal and external communication
• CC3 Risk assessment: objectives, identification and analysis of risks, fraud risk and significant change
• CC4 Monitoring activities: ongoing and separate evaluations and communication of deficiencies
• CC5 Control activities: selection and development of controls, technology controls and policies deployed through procedures
• CC6 Logical and physical access controls: access to systems, data and facilities, authentication, authorization, removal and protection from external threats
• CC7 System operations: detection of vulnerabilities and anomalies, incident response and recovery
• CC8 Change management: authorization, testing and approval of changes to infrastructure, data and software
• CC9 Risk mitigation: business disruption and vendor and business partner risk
• Additional criteria apply for Availability, Confidentiality, Processing Integrity and Privacy when they are in scope

What happens in a SOC 2 audit?

A SOC 2 engagement is performed by an independent CPA firm. The service organization writes a description of its system and management provides a written assertion about it, and the auditor then tests whether the controls meet the criteria in scope. The organization designs its own controls, so two companies with the same criteria can have very different control sets.

The auditor examines evidence, such as policies, access reviews, change tickets, monitoring records and incident records, observes processes and interviews staff. The result is a report with the auditor's opinion, the system description, the controls and the test results. Findings, called exceptions, are reported in the test results.

The opinion can be one of four types. Unqualified: the controls meet the criteria. Qualified: the controls meet the criteria except for a specific matter. Adverse: the controls do not meet the criteria. Disclaimer of opinion: the auditor could not obtain enough evidence to form an opinion. Every engagement results in a report, whatever the opinion, so a clean report matters more than the existence of one.

SOC 2 Type I vs. Type II

The two report types answer different questions and give different levels of assurance.

• Type I: the auditor reports on the description of the system and the suitability of the design of controls at a specific date. It answers whether the controls are designed properly
• Type II: the auditor reports on the suitability of design and the operating effectiveness of controls over a period of time, often between three and twelve months. It answers whether the controls actually worked
• Assurance: Type II gives customers stronger assurance because it includes testing of operation over time
• Timing: Type I can be completed faster and may be used as a first step, while many customers now ask for Type II
• Cost and effort: a Type II needs evidence collection for the whole period, so an organization should plan its control operation before the period starts

Who needs SOC 2 and is it mandatory?

SOC 2 is not a law and it is not mandatory in the way that data protection regulations are. It is usually driven by customers. Any service organization that stores, processes or transmits customer data may be asked for a SOC 2 report during procurement, due diligence or a security review.

In practice, the organizations that pursue it are cloud and SaaS providers, managed service providers, data processors, fintech and health technology companies, and other suppliers selling to enterprise customers. A SOC 2 report can also support internal discipline, because it requires documented responsibilities, access control, change control and monitoring. Is the request coming from one customer or from the whole market? That answer helps decide the criteria and the report type to choose.

How to prepare for a SOC 2 audit

A SOC 2 programme is easier when it follows the audit logic from the beginning.

• Define scope: decide the system, services, infrastructure, people and locations that are in scope
• Select criteria: security is required, then choose Availability, Confidentiality, Processing Integrity and Privacy based on commitments to customers
• Gap assessment: compare current practices with the criteria and identify missing or weak controls
• Design controls and policies: define controls, owners and evidence for each criterion
• Operate and collect evidence: run the controls consistently and keep records such as access reviews, change approvals and incident logs
• Readiness review: test your own controls before the auditor does and correct exceptions
• Select a CPA firm and the report type: agree scope, period and timeline
• Audit and maintain: complete the audit, share the report under agreement and repeat the cycle each year

SOC 2 and ISO 27001, and how ComplyEncrypt helps

SOC 2 and ISO 27001 overlap significantly. Both expect risk assessment, access control, change management, incident response, supplier management, monitoring and management oversight. The difference is the form of assurance: ISO 27001 results in a certificate against a management system standard, while SOC 2 results in an attestation report with the auditor's opinion on your own controls. Many companies that sell internationally hold both, because customers in different regions ask for different evidence.

SOC 2 is on the ComplyEncrypt roadmap. ComplyEncrypt is built to bring policy and procedure drafts, risk and control records, evidence collection, mappings between SOC 2 criteria and ISO 27001 controls, and internal-audit preparation into an AI-assisted workflow so the same evidence supports several frameworks. AI assistance applies to documentation work; people still run the controls, and the opinion in a SOC 2 report always comes from an independent CPA firm. A vigorous control environment is one where evidence is produced by daily work, not assembled before the audit. See the SOC 2 framework page for current availability.