Despite being widely requested and routinely referenced, the differences between SOC 1, SOC 2, and SOC 3, and between Type I and Type II examinations, cause genuine confusion for people who encounter them without working with them regularly. More practically, a SOC report received and filed without proper analysis provides no meaningful assurance at all.
This article explains what each report type covers, what the distinctions mean in practice, and how to actually use a SOC report to reach an informed view of a supplier's control environment.
The Three Report Types: What Each Is For
SOC 1: Internal Controls Over Financial Reporting
A SOC 1 report, formally titled a Service Organisation Control 1 report, focuses specifically on controls at a service organisation that are relevant to its customers' internal control over financial reporting. It exists to answer a specific question: can organisations relying on this service trust that the controls in place are adequate to support the accuracy of their own financial statements?
This makes SOC 1 most relevant in a specific set of contexts: payroll processing, fund administration, custody and settlement services, insurance claims processing, and other situations where a service provider's activities feed directly into the financial reporting of the organisations using them.
A SOC 1 report is not an assessment of general information security, operational reliability, or data protection. It is specifically and deliberately scoped to financial reporting risk. An organisation seeking assurance about a SaaS provider's data security practices should not be requesting a SOC 1. That is what SOC 2 is for.
SOC 2: The Trust Services Criteria
A SOC 2 report assesses a service organisation's controls against the Trust Services Criteria, developed by the American Institute of Certified Public Accountants. The criteria cover five categories.
Security is the only required category for all SOC 2 examinations. It covers the protection of information and systems against unauthorised access, both physical and logical. All SOC 2 reports address security regardless of what else is in scope.
Availability covers whether systems and services are available for operation and use as agreed or committed to. This is relevant for services where uptime and performance guarantees are material to the customer relationship.
Processing integrity covers whether system processing is complete, valid, accurate, timely, and authorised. This is relevant for services involving complex data transformation, transaction processing, or financial calculation.
Confidentiality covers whether information designated as confidential is protected as agreed or committed to. Relevant for services handling proprietary or commercially sensitive information.
Privacy covers the collection, use, retention, disclosure, and disposal of personal information in conformity with the organisation's privacy notice and the AICPA's privacy criteria. This is distinct from but related to GDPR compliance.
Service organisations choose which additional criteria to include based on the nature of their services and what their customers are likely to need assurance about. A cloud infrastructure provider will typically include availability. A service handling medical data will typically include privacy. It is not unusual for the security criterion only to be included, particularly for organisations at an early stage of their SOC 2 journey.
SOC 3: The Public-Friendly Summary
A SOC 3 report covers the same Trust Services Criteria as a SOC 2 but is designed for general public distribution. Where a SOC 2 report contains detailed, sensitive information about systems, controls, and findings that most service organisations share only under confidentiality agreements, a SOC 3 strips out that detail while retaining the auditor's overall opinion on whether controls were suitably designed and operating effectively.
A SOC 3 report allows an organisation to demonstrate that an independent assessment has been conducted and that the overall conclusion was positive, without disclosing the underlying system and control details that competitors or bad actors could exploit. Many organisations publish their SOC 3 report on their website.
Type I vs Type II: The Distinction That Matters Most
Both SOC 1 and SOC 2 reports can be either Type I or Type II, and this distinction is more important to understand than the choice between SOC 1 and SOC 2 for most assurance purposes.
Type I: Suitability of Design at a Point in Time
A Type I report assesses whether controls are suitably designed as of a specific date. The auditor examines the control environment and provides an opinion on whether the controls that exist would, if operating as described, address the risks they are intended to manage.
Type I answers one question: are these controls well designed? It does not address whether those controls have actually been applied in practice, consistently, over any period of time.
Type II: Design and Operating Effectiveness Over a Period
A Type II report assesses both whether controls are suitably designed and whether they have been operating effectively over a specified period, typically six months to a year. The auditor performs testing across the examination period to gather evidence that controls were not merely documented but actually performed as described.
Type II provides substantially stronger assurance than Type I because it demonstrates sustained, consistent operation rather than point-in-time design assessment. A service organisation with well-designed controls that are rarely followed in practice would pass a Type I examination and fail a Type II.
For most organisations evaluating third-party relationships, a Type II report is the appropriate standard for higher-risk or critical suppliers. A Type I is generally acceptable for initial or preliminary assessment, or for lower-risk relationships where Type II adds disproportionate cost relative to the assurance value.
The Examination Period and Why It Matters
Every SOC report covers a specific period of time or, for Type I, a specific date. The currency of the report is directly relevant to the assurance it provides.
A SOC 2 Type II covering the twelve months ending six months ago provides reasonable current assurance, given that the examination period recently concluded. A SOC 2 Type II covering a period that ended eighteen months ago is providing assurance about a control environment that may have changed significantly since the examination. Significant system changes, staff changes, acquisitions, and the introduction of new services all affect the relevance of a report based on an earlier period.
Most organisations set a threshold beyond which a SOC report is considered too old to provide adequate current assurance, typically twelve to eighteen months since the end of the examination period. When evaluating supplier SOC reports, always check when the examination period ended, not just whether the report exists.
Understanding the Auditor's Opinion
A SOC report contains an independent auditor's opinion that is the core conclusion of the examination. Understanding what the opinion says and, critically, what it does not say is essential to using the report meaningfully.
The opinion will typically be one of three types.
Unqualified opinion: the auditor found that controls were suitably designed and, for Type II, operating effectively throughout the period. This is the expected outcome for organisations with mature control environments.
Qualified opinion: the auditor identified one or more specific exceptions but concluded that the overall control environment was otherwise sound. A qualified opinion requires careful reading. The qualification might relate to a control that is genuinely material to your organisation's use of the service, or it might relate to a control outside your scope of concern. The nature and severity of the qualification matters significantly.
Adverse opinion or disclaimer: the auditor found controls to be materially deficient or was unable to gather sufficient evidence to form an opinion. Either outcome is a serious finding that warrants significant scrutiny of whether to rely on this service organisation without remediation.
Most SOC reports from mature, well-governed service organisations will carry unqualified opinions. Do not assume this is the case without checking. Read the opinion section of every report rather than filing it on receipt.
Reading the Control Exceptions
Even with an unqualified overall opinion, a SOC 2 Type II report typically includes a table of individual control tests and their results. Controls where the test identified an exception are listed, along with management's response explaining the exception and what was done about it.
Reading these exceptions is where the practical value of a SOC report is often found. An exception in a control that is directly relevant to your organisation's use of the service warrants direct follow-up with the supplier: what happened, why did it happen, what was the impact, and what has been done to prevent recurrence?
Pay particular attention to patterns rather than individual exceptions. A single exception in an otherwise clean report may reflect a one-off event with a clear explanation. Multiple exceptions in the same control area, or the same type of exception appearing in several related controls, suggests a more systemic issue with the control environment.
The Complementary User Entity Controls
Most SOC 2 reports include a section describing Complementary User Entity Controls, often abbreviated as CUECs. These are controls that the service organisation's design assumes its customers have in place, without which the service organisation's own controls may not be effective.
Common examples include: customers implementing appropriate access controls over credentials used to access the service, customers reviewing audit logs provided by the service organisation on a timely basis, and customers testing their own disaster recovery plans for the applications they run on the service organisation's infrastructure.
CUECs are an important and frequently overlooked part of the SOC report. If the service organisation's controls assume you have specific controls in place, and you do not, the assurance provided by the SOC report is incomplete. Review the CUEC section of every SOC 2 report and confirm that your organisation actually has the controls it assumes.
Connecting the SOC Report to Your Third-Party Risk Assessment
A SOC report is one input into a third-party risk assessment, not the entirety of it. The report tells you about the control environment as examined by an independent auditor over a specific period. It does not tell you about changes since the examination period, about the financial stability of the supplier, about contractual arrangements, or about how the supplier would behave in an exit scenario.
Connect SOC report findings to the broader supplier risk file. Any exceptions or qualifications should be assessed in the context of how critical the relevant service is to your operations. Where a qualified opinion or significant exceptions are found, consider whether additional assurance mechanisms, such as contractual rights to conduct your own audit, or a specific supplier questionnaire addressing the issue, are appropriate.
And close the loop in your governance documentation. A SOC report filed and never referenced again has provided no governance value. The fact that you reviewed it, what you found, and what decisions you made as a result should be documented as part of your third-party risk management record.
Related Reading
References
