Skip to main content
Category: SOC Reporting

System and Organization Controls (SOC)

Also known as: SOC, SOC Suite of Services, System and Organization Controls reports
Simply put

System and Organization Controls (SOC) is a suite of examination and reporting services that CPAs provide to evaluate the controls a service organization uses to manage and safeguard its systems and data. The result of a SOC engagement is an independent report intended primarily for the service organization's customers and other users who rely on those controls. A SOC engagement gives assurance over how well an organization's controls function, but it is a point-in-time or period-specific assessment rather than a guarantee that no security incidents will occur.

Formal definition

System and Organization Controls (SOC) is an AICPA suite of service offerings under which a licensed CPA firm performs an attestation examination of system-level controls at a service organization and issues a report on those controls. SOC engagements assess controls relevant to the defined scope and, depending on the offering, produce reports intended for specified users; a SOC report reflects the findings of the underlying examination and attests only to the controls and the period or point in time covered. SOC is a family of distinct offerings (for example, SOC 1, SOC 2, and SOC 3) that differ in subject matter, applicable criteria, and intended audience, and a SOC report is an attestation deliverable rather than a certification.

Why it matters

Service organizations routinely handle systems and data on behalf of their customers, and those customers need a way to gain confidence in the controls protecting that information without auditing every vendor themselves. System and Organization Controls (SOC) reports address this need by having an independent, licensed CPA firm examine a service organization's controls and issue a report that customers and other reliant users can review. This shifts the burden away from every customer performing individual assessments and toward a single, standardized examination that multiple stakeholders can rely upon.

SOC reports carry weight because they are the product of an independent attestation examination rather than a self-assessment. The resulting report reflects the findings of the underlying examination and gives assurance over how well the organization's controls function. It is important to understand the boundaries of that assurance: a SOC report attests only to the controls and the point in time or period covered by the engagement. It is not a certification, and it does not guarantee that no security incident will occur or that the organization is free from risk outside the defined scope.

Because SOC is a family of distinct offerings, SOC 1, SOC 2, and SOC 3, among others, that differ in subject matter, applicable criteria, and intended audience, selecting and interpreting the correct report matters for procurement, vendor risk management, and audit reliance decisions. A user relying on the wrong SOC offering, or misreading a point-in-time report as an ongoing guarantee, can draw conclusions the report was never designed to support.

Who it's relevant to

Service Organizations
Organizations that operate systems or handle data on behalf of customers are the subjects of SOC engagements. They engage a CPA firm to examine their system-level controls and rely on the resulting report to demonstrate to customers how they manage and safeguard those systems, typically without needing to accommodate individual customer audits.
Customers and Reliant Users
Customers of a service organization, and other users who depend on its controls, are the intended audience for SOC reports. They use the independent report to gain assurance over the functioning of the organization's controls, while recognizing that the assurance is limited to the controls and the period or point in time covered.
CPA Firms and Practitioners
Licensed CPA firms perform SOC engagements, conducting the attestation examination of system-level controls and issuing the report. They determine, within the applicable AICPA framework, the appropriate offering, scope, and criteria for the engagement and are responsible for the findings the report reflects.
Vendor Risk and Procurement Teams
Teams responsible for evaluating third-party providers use SOC reports as evidence in vendor risk management and procurement decisions. They must select the appropriate SOC offering for their needs and interpret the report's scope and coverage period correctly, rather than treating it as a certification or an ongoing guarantee of security.

Inside SOC

SOC 1
An attestation examination performed by a licensed CPA firm under the AICPA's SSAE 18 standard, focused on controls at a service organization that are relevant to a user entity's internal control over financial reporting (ICFR). It results in a report, not a certification.
SOC 2
An attestation examination performed by a licensed CPA firm under SSAE 18, evaluating controls against the Trust Services Criteria. It produces a report and is available in Type I (suitability of design at a point in time) and Type II (design and operating effectiveness over a defined review period) forms.
SOC 3
A general-use report based on the same Trust Services Criteria examination underlying a SOC 2, but presented at a summary level suitable for broad distribution, without the detailed description of tests and results found in a SOC 2 report.
Trust Services Criteria
The criteria against which SOC 2 and SOC 3 controls are evaluated. Security (the Common Criteria) is the only required category; Availability, Processing Integrity, Confidentiality, and Privacy are optional and selected based on the scope of the engagement.
Type I versus Type II
Type I assesses the suitability of the design of controls at a specific point in time, while Type II assesses both design and operating effectiveness across a defined review period whose length is set by scoping decisions rather than a fixed duration.
Report output and boundaries
A SOC report attests only to the controls and, for Type II, the period covered by the examination. It does not guarantee freedom from breaches and does not constitute a certification.

Common questions

Answers to the questions practitioners most commonly ask about SOC.

Is a SOC 2 outcome a certification?
No. SOC 2 is an attestation examination performed by a licensed CPA firm under the AICPA's SSAE 18 standard, and its outcome is a report rather than a certificate. This distinguishes it from ISO/IEC 27001, which results in a certification issued by an accredited certification body. Referring to a SOC 2 report as a certification is a common but material error, particularly in procurement and vendor-assessment contexts.
What is the difference between a SOC 2 Type I and a Type II report?
A Type I report assesses the suitability of the design of controls at a single point in time, while a Type II report assesses both the design and the operating effectiveness of controls over a defined review period. The length of that period varies and is set through scoping decisions rather than being a fixed duration. Because a Type II covers operating effectiveness over time, many customers request it, but the appropriate type depends on the organization's stage and the assurance the report's users require.
Which Trust Services Criteria should we include in our SOC 2 scope?
Security, also known as the Common Criteria, is the only required category. Availability, Processing Integrity, Confidentiality, and Privacy are optional and selected based on the nature of the services and the commitments made to customers. In most engagements the choice is informed by what the system does and what assurances users are seeking, so scoping these categories is typically an early decision made with the service auditor.
Does a SOC 2 report guarantee that our organization will not experience a breach?
No. A SOC 2 report attests only to the controls and the period covered by the examination, and for a Type II, to their operating effectiveness over that period. It does not guarantee freedom from breaches, cover controls outside the defined scope, or speak to periods before or after the examination window. Users should read the report's scope and description carefully to understand exactly what was and was not evaluated.
How do we choose between SOC 1, SOC 2, and SOC 3?
The choice depends on the intended users and the subject matter. SOC 1 addresses controls relevant to a user entity's internal control over financial reporting, while SOC 2 addresses controls mapped to the Trust Services Criteria such as security. SOC 3 provides a general-use summary related to a SOC 2 engagement but without the detailed control and testing information. Selecting the right report typically starts with identifying who will rely on it and for what purpose.
If we already have a SOC 2 report, does that satisfy an ISO 27001 certification?
Not automatically. Mapping between SOC 2 and ISO 27001 is possible but partial, and satisfying one does not by itself satisfy the other. SOC 2 is an attestation against the Trust Services Criteria, whereas ISO 27001 certification is issued against management-system requirements with reference controls selected through a Statement of Applicability. Organizations pursuing both can often reuse evidence and controls, but each framework has distinct requirements that must be met separately.

Common misconceptions

A SOC 2 report is a certification that proves an organization is secure.
SOC 2 is an attestation examination performed by a licensed CPA firm under SSAE 18, resulting in a report rather than a certificate. It attests only to the controls and period covered and does not guarantee freedom from breaches. Certification against a management system standard is a characteristic of ISO/IEC 27001, not SOC 2.
All five Trust Services Criteria categories must be included in every SOC 2 engagement.
Only Security, the Common Criteria, is required. Availability, Processing Integrity, Confidentiality, and Privacy are optional and are selected based on the scope of the engagement.
A SOC 2 report and an ISO 27001 certificate are interchangeable, so achieving one satisfies the other.
Mapping between the two frameworks is possible but partial. They differ in nature, SOC 2 is a CPA attestation report against the Trust Services Criteria, while ISO 27001 is a certification against a management system standard, and satisfying one does not automatically satisfy the other.

Best practices

Clarify at the outset whether stakeholders need a Type I or Type II report, since Type I addresses design suitability at a point in time and Type II addresses design and operating effectiveness over a defined review period.
Scope the Trust Services Criteria deliberately, including Security (the Common Criteria) as required and selecting Availability, Processing Integrity, Confidentiality, or Privacy only where relevant to commitments made to customers.
Set the Type II review period through explicit scoping decisions and confirm it aligns with customer expectations rather than assuming a fixed duration.
Communicate the boundaries of the report to internal and external stakeholders, noting that it attests only to the controls and period covered and does not guarantee freedom from breaches.
Select the appropriate report type, SOC 1 for financial reporting relevance, SOC 2 for detailed Trust Services Criteria assurance, or SOC 3 for general-use summary distribution, based on the intended audience.
When pursuing both SOC 2 and ISO 27001, treat any control mapping as partial and validate each framework's requirements independently rather than assuming one outcome satisfies the other.