Category: SOC Reporting

Service Organization

Also known as: User Organization's Service Provider

Simply put

A service organization is a company that performs services or handles operations on behalf of another organization, such as payroll processing, data hosting, or utility metering. Because these outsourced functions affect the customers who rely on them, the service organization's controls are often examined and reported on so those customers can understand the risks involved.

Formal definition

In the context of SOC examinations, a service organization is an entity that provides services to user entities and, in doing so, operates controls that are relevant to the user entities' operations, security, or financial reporting. The service organization is the subject entity whose controls are described and evaluated in a SOC report; in a SOC 2 engagement the controls are assessed against the applicable Trust Services Criteria, while in a SOC 1 engagement the focus is on controls relevant to user entities' internal control over financial reporting. A given examination attests only to the specific service organization, controls, and period or point in time within the defined scope, and does not extend to services or functions outside that scope.

Why it matters

When an organization outsources a function such as payroll processing, data hosting, or utility sub-metering, it hands operational control of that function to another entity. Yet the risks associated with that function do not disappear; they extend to the customers (the user entities) that depend on the service. The concept of a service organization matters because it identifies the entity whose controls need to be examined so that those user entities, and their auditors, can understand and account for the risks they have effectively taken on through the outsourcing arrangement.

SOC examinations exist precisely to give user entities visibility into a service organization's controls without each customer having to audit the provider individually. In a SOC 2 engagement, the service organization's controls are evaluated against the applicable Trust Services Criteria; in a SOC 1 engagement, the focus is on controls relevant to user entities' internal control over financial reporting. This distinction matters because selecting the wrong report type, or relying on one where the other is needed, can leave a gap in a user entity's own assurance.

It is important to recognize the boundaries of what such an examination conveys. A SOC report attests only to the specific service organization, the defined controls, and the period or point in time within the defined scope. It does not extend to services or functions outside that scope, and it does not guarantee that the service organization will be free from incidents. User entities therefore need to read the scope carefully rather than treat any report as a blanket endorsement.

Who it's relevant to

Service organizations undergoing examination

Companies that provide outsourced services such as payroll processing, data hosting, or utility sub-metering are the subject entities in SOC engagements. They are responsible for describing their controls and for defining the scope, controls, and period or point in time that the examination will cover, and they should understand that the resulting report speaks only to what falls within that defined boundary.

User entities and their management

Organizations that outsource operations to a service provider rely on that provider's controls, and the associated risks extend to them even though the function is performed elsewhere. Reviewing a service organization's SOC report helps user entities understand those risks, but they should read the defined scope closely rather than assume the report covers every service the provider performs.

Auditors of user entities

Auditors evaluating a user entity's operations or financial reporting need to account for functions the entity has outsourced to a service organization. A SOC 1 report addresses controls relevant to internal control over financial reporting, while a SOC 2 report addresses controls against the applicable Trust Services Criteria; selecting and relying on the appropriate report type is essential to avoid a gap in assurance.

Compliance and GRC professionals

Those managing vendor risk and third-party assurance programs use the service organization concept to determine which providers warrant examination and which SOC report type applies. They should confirm that the controls and scope described in a provider's report align with the outsourced functions their own organization actually depends on.

Inside Service Organization

Service Organization

An entity that provides services to user entities (its customers) where those services are relevant to the user entities' own systems of internal control. In the SOC context, the service organization is the party whose controls are examined and described in a SOC report.

User Entity

A customer of the service organization that relies on the outsourced service and may reference the service organization's SOC report when evaluating its own control environment.

System Description

A description of the service organization's system prepared by management, covering the services provided and the controls in place, against which an auditor performs a SOC 2 examination under the AICPA SSAE 18 standard.

Controls in Scope

The specific controls the service organization defines and includes within the boundaries of the engagement, typically aligned to the applicable Trust Services Criteria selected for the report.

Subservice Organization

A third party engaged by the service organization to perform some of the services (and related controls) covered by the report, which may be handled through the inclusive or carve-out method depending on scoping decisions.

Common questions

Answers to the questions practitioners most commonly ask about Service Organization.

Does becoming a service organization mean my company receives a SOC 2 certificate?

No. A SOC 2 engagement is an attestation examination performed by a licensed CPA firm under the AICPA's SSAE 18 standard, and it results in a report rather than a certificate. The term 'certification' applies to frameworks such as ISO/IEC 27001, where an accredited certification body issues a certificate against a management system standard. A service organization undergoing SOC 2 receives an auditor's report describing the controls and the outcome of the examination, not a certificate.

If my service organization has a SOC 2 report, does that guarantee it is free from breaches?

No. A SOC 2 report attests only to the controls and, for a Type II, the period covered by the examination. It reflects the auditor's opinion on the suitability of design (Type I) or on both design and operating effectiveness over the defined review period (Type II). It does not guarantee that no security incident will occur, and it does not extend to controls, systems, or timeframes outside the defined scope.

How does a service organization determine which Trust Services Criteria to include in its SOC 2 scope?

In most engagements, scope is set through scoping decisions between the service organization and its auditor. Security, expressed as the Common Criteria, is the only required category. Availability, Processing Integrity, Confidentiality, and Privacy are optional and are typically selected based on the nature of the services provided and the commitments made to customers. The chosen categories define what the resulting report covers.

What should a service organization consider when defining the boundaries of its SOC 2 report?

A service organization typically defines the system boundary to reflect the services relevant to its customers, including the infrastructure, software, people, procedures, and data involved. Because a SOC 2 report attests only to the controls and period covered, scoping directly affects what the report can and cannot demonstrate. Elements outside the defined boundary are not addressed, so boundaries should be set with the intended users of the report in mind.

How does a service organization choose between a SOC 2 Type I and a Type II?

The choice generally depends on what the service organization needs to demonstrate. A Type I assesses the suitability of design of controls at a point in time, while a Type II assesses both design and operating effectiveness over a defined review period. The length of that period varies and is set through scoping decisions rather than being fixed. Some organizations begin with a Type I and later pursue a Type II to show sustained operating effectiveness.

Can a service organization use a single effort to satisfy both SOC 2 and ISO 27001?

Mapping between SOC 2 and ISO 27001 is possible but partial, so a single effort does not automatically satisfy both. SOC 2 is an attestation examination against the Trust Services Criteria, whereas ISO 27001 is a certification against management system requirements in clauses 4 through 10, with reference controls in Annex A selected through a Statement of Applicability. A service organization pursuing both should expect overlapping evidence in some areas but distinct requirements and separate outcomes.

Common misconceptions

A service organization that undergoes a SOC 2 examination receives a certification proving it is secure.

SOC 2 is an attestation examination performed by a licensed CPA firm under the AICPA SSAE 18 standard, resulting in a report rather than a certificate. The report attests only to the controls and period covered and does not guarantee the service organization is free from breaches. Certification against a management system standard is a feature of ISO/IEC 27001, which is a separate framework.

A SOC 2 report covers everything a service organization does across its entire business.

A report addresses only the system, controls, and Trust Services Criteria within the defined scope, and for a Type II report only the review period covered. Services, systems, or business units outside that boundary are not addressed.

If a service organization satisfies SOC 2, it automatically satisfies ISO/IEC 27001 as well.

The two frameworks are distinct, and mapping between them is possible but partial. Satisfying one does not automatically satisfy the other, since ISO 27001 certification is assessed against ISMS requirements in clauses 4 through 10 with Annex A reference controls selected via a Statement of Applicability, whereas SOC 2 is an attestation against selected Trust Services Criteria.

Best practices

Define the system boundary and in-scope services precisely before engagement so the resulting SOC 2 report accurately reflects what the service organization delivers to user entities.

Select the applicable Trust Services Criteria based on the services provided and customer needs, recognizing that Security (the Common Criteria) is required while Availability, Processing Integrity, Confidentiality, and Privacy are optional and chosen by scope.

Decide early whether to use the inclusive or carve-out method for any subservice organizations, and document how their controls are addressed relative to the service organization's own controls.

Choose the appropriate report type for the intended assurance: a Type I addressing suitability of design at a point in time, or a Type II addressing design and operating effectiveness over a defined review period whose length is set by scoping decisions.

Communicate clearly to user entities that a SOC 2 report attests only to the controls and period covered and does not guarantee freedom from breaches or cover activities outside the defined scope.

If pursuing both SOC 2 and ISO/IEC 27001, treat any control mapping between them as partial and validate each framework's requirements separately rather than assuming one outcome satisfies the other.