SOC Reports and Third-Party Assurance

The AICPA designed the three SOC report types to serve different audiences and different assurance purposes. Confusing them is a common procurement error: a procurement team that asks a vendor for a SOC report may receive a SOC 3 public summary when they needed the full SOC 2 restricted report to satisfy their auditors.

SOC 1 matters to any service organisation whose processing could affect the financial statements of its customers. Payroll processors, loan servicers, transfer agents, and managed IT providers that support accounting systems are typical SOC 1 subjects. The governing standard, SSAE 18, replaced the older SAS 70 standard in 2017. Many organisations still refer informally to a SAS 70, but the standard has not been in force for nearly a decade.

SOC 2 is the standard most commonly requested in technology procurement. A cloud infrastructure provider, a SaaS platform, a managed security provider, or a data analytics vendor is typically expected to hold a SOC 2 Type II report. The report covers whatever subset of the five Trust Service Criteria the service organisation and its auditor agree is in scope. Security is always included. The other criteria are optional and should be included if they are relevant to the services provided.

SOC 3 is a marketing and trust tool. The AICPA allows a service organisation that holds a SOC 2 to publish the SOC 3 public summary and display the SOC seal. It provides no control detail, so it cannot substitute for SOC 2 in a procurement or audit context. Its value is in signalling to potential customers that an independent audit has occurred, without disclosing the specific controls or any exceptions noted.

The Type I and Type II distinction applies to both SOC 1 and SOC 2. The difference is about the nature and depth of the auditor's testing, and it directly affects how much weight a relying party can place on the report.

A Type I report answers one question: are the controls as described suitably designed to achieve the stated control objectives? The auditor examines the service organisation's control documentation and the system description, forms a view on whether the design is logical and complete, and issues an opinion as of a single date. The organisation might have installed a new access-control system yesterday; if the design is sound, the Type I report will say so. Whether the system actually enforced access restrictions on any real transaction is not part of the Type I scope.

A Type II report answers two questions: are the controls suitably designed, and did they operate effectively throughout the reporting period? The period is defined in the engagement letter, typically six to twelve months. The auditor selects samples of transactions, access logs, change records, and other evidence from across the period and tests whether the controls functioned as described. If a control was bypassed in month three, the auditor's testing should detect that exception and the report will note it.

The transition from a first-time Type I to an ongoing Type II audit cycle is a common milestone in a service organisation's compliance maturity. Organisations often obtain a Type I in year one to demonstrate a baseline, then move to annual Type II engagements. The period covered by the first Type II report sometimes starts from the date of the Type I examination.

The AICPA's 2017 Trust Services Criteria publication defines the five criteria categories and the specific criteria within each. The criteria are designed to be flexible: they describe outcomes rather than prescribing specific control implementations, which means a small SaaS startup and a large cloud provider can both be evaluated against the same criteria with controls proportionate to their risk.

The Security criterion is built on 17 control categories called Common Criteria. These cover the control environment, communication and information, risk assessment, monitoring, logical and physical access controls, system operations, and change management. Every SOC 2 report must address all 17 Common Criteria. The other four criteria have additional criteria that supplement the Common Criteria when they are in scope.

The Privacy criterion deserves particular attention for cross-border compliance. A SOC 2 Privacy criterion engagement is evaluated against the AICPA's privacy commitments, which align broadly with the Generally Accepted Privacy Principles (GAPP). For a service organisation operating under the EU General Data Protection Regulation, the UK GDPR, or India's Digital Personal Data Protection Act 2023, the SOC 2 Privacy criterion provides a useful framework for documenting controls, but it does not constitute regulatory certification under any of those regimes. A SOC 2 with Privacy in scope is evidence of controls, not a substitute for GDPR or DPDP Act compliance documentation.

A SOC 2 Type II report has a defined structure. Understanding the sections helps a relying party read the report efficiently rather than trying to absorb it in full.

Section one is the independent service auditor's report. This is the auditor's formal opinion: whether the system description is fairly presented, whether controls are suitably designed, and whether controls operated effectively throughout the period. The opinion can be unqualified (clean), qualified (effective except for specified exceptions), or adverse. Most published SOC 2 reports have unqualified opinions; a qualified opinion requires scrutiny of the exceptions.

Section two is the management assertion. The service organisation's management asserts that the system description is accurate and that the controls were suitably designed and operating effectively. This section gives the auditor's opinion its target: the auditor is opining on the accuracy of management's assertion.

Section three is the system description. This is often the most useful section for a technical reader. It describes the services provided, the infrastructure, software, people, data, and procedures that make up the system, the relevant control objectives, and the controls themselves. The description also lists the Complementary User Entity Controls that the relying party is expected to implement.

Section four, present only in Type II reports, is the description of tests and results. For each control, the auditor describes the test procedure and the result. Exceptions are listed here. A single exception does not automatically mean the control is ineffective; the auditor weighs the nature and frequency of exceptions. Multiple exceptions of the same type across a period, however, indicate a systemic weakness.

A relying party is any organisation that uses a SOC report as evidence in its own risk management, compliance, or audit programme. The term appears in the report itself: the auditor's report is addressed to the service organisation's management and to specified user entities, meaning the relying parties listed or described in the engagement.

The process a relying party follows has four steps. First, confirm the report is current: a SOC 2 Type II report covering a period that ended eighteen months ago gives little assurance about current controls. Most procurement policies require a report whose period ended within the last twelve months. Second, check the scope: does the report cover the services actually used? A vendor may have a SOC 2 that covers its data storage service but not its analytics module. If the relying party uses both, the analytics module is outside the audit scope.

Third, read the Complementary User Entity Controls section. This lists controls that the service organisation's design assumes the user entity will implement. Common CUECs include: implementing multi-factor authentication for user accounts on the service, classifying data before uploading, and reviewing access logs. If the relying party has not implemented the CUECs, the service organisation's controls do not provide the assurance the report describes. Fourth, read the exceptions section and decide whether any exception represents a risk relevant to the relying party's use case.

In a financial statement audit, the relying party's auditor uses the SOC 1 report to understand which of the client's transaction processing controls are actually implemented at the service organisation and which are at the client. This affects how the auditor designs substantive testing. If the service organisation has effective controls over completeness and accuracy of transaction data, the auditor can reduce direct testing at the client. If controls are missing or have exceptions, the auditor must compensate by testing more transactions directly.

For security and compliance teams, the SOC 2 report is one input to third-party risk management. The report should be reviewed alongside the vendor contract, the vendor's penetration test summary, and any incident history. A clean SOC 2 is not a guarantee that a vendor has never had a breach; it is evidence that defined controls were in place and operating during the audit period.

The AICPA SOC framework originated in the United States and is most deeply embedded in US regulatory and audit practice. Organisations operating internationally encounter equivalent standards that serve the same function and are generally accepted in cross-border procurement and audit engagements.

ISAE 3402 is the International Auditing and Assurance Standards Board standard for reports on controls at service organisations affecting financial reporting. It is the international equivalent of SOC 1 and is widely used by European, Asian, and Middle Eastern service organisations. US auditors applying PCAOB and AICPA standards can use an ISAE 3402 report as the basis for their risk assessment in the same way they use a SOC 1. The two standards have been harmonised to produce comparable reports, though specific wording differs.

ISAE 3000 is the IAASB standard for assurance engagements other than audits or reviews of historical financial information. European auditors conducting assurance engagements equivalent to SOC 2 may use ISAE 3000 as the governing standard, sometimes combined with criteria sets published by national regulators or industry bodies. The resulting report is often described as an ISAE 3000 assurance report on trust service criteria or on a specific set of security controls.

In the UK, the Cyber Essentials and Cyber Essentials Plus schemes, administered by the National Cyber Security Centre, provide a basic assurance framework for UK government procurement. They are not substitutes for SOC 2: they cover a narrower set of technical controls and do not include independent testing of operating effectiveness over time. Organisations serving UK government clients may need both.

In India, the Digital Personal Data Protection Act 2023 (DPDP Act) imposes obligations on data fiduciaries and data processors. The Act does not designate SOC 2 or any specific assurance standard as the compliance mechanism, but the Ministry of Electronics and Information Technology has indicated that technical and organisational measures will be specified in rules under the Act. Service organisations processing Indian personal data should expect that SOC 2 Privacy criterion reports may serve as useful evidence of technical and organisational measures, alongside ISO 27001 certification, when the rules are finalised.

Under the EU General Data Protection Regulation (GDPR), Article 28 requires that data processors process data only on documented instructions and implement appropriate technical and organisational measures. A SOC 2 report addressing the Privacy and Security criteria provides strong evidence of such measures, but it is not a formal certification under GDPR Article 42. Some data protection authorities accept SOC 2 reports as part of a due diligence record for data processor selection. See also the risk treatment and risk register topic for how assurance reports feed into organisational risk documentation.