Historical Context & Motivation
As businesses increasingly outsourced critical functions—payroll processing, data hosting, transaction settlement—the auditing profession faced a growing challenge: how could auditors obtain reasonable assurance about a client's internal controls when significant processes resided outside the client's direct purview? The concept of relying on a service organization emerged gradually, but the complexity deepened when those service organizations themselves outsourced portions of their work to yet another entity—a subservice organization. Simultaneously, auditors recognized that no service organization's controls could function effectively in isolation; certain controls had to be implemented and maintained by the client, known as a user entity. These twin concepts—subservice organizations and user entity controls—became essential to defining the boundaries of assurance in SOC engagements.
The central question this lesson addresses is: When a service organization relies on third parties and when its controls depend on actions taken by user entities, how do auditors define the boundaries of the SOC engagement, allocate responsibility, and communicate residual obligations to report users? The answer shapes how SOC reports are scoped, how audit risk is managed, and how user entity auditors ultimately rely on these reports in their own financial statement or compliance engagements.
Core Principles & Definitions
Before diving into the mechanics of SOC engagements, it is essential to establish a shared vocabulary. A service organization is any entity that provides services to user entities when those services are relevant to the user entities' internal control over financial reporting (SOC 1) or to their operational and compliance objectives (SOC 2). A subservice organization is a separate entity that the service organization itself relies upon to perform certain functions within the scope of the SOC engagement. Finally, user entity controls (often called complementary user entity controls or CUECs) are controls that the service organization's system of internal controls assumes user entities have implemented. Without these CUECs in place, the service organization's own controls may not achieve their stated objectives.
Carve-Out Method
Inclusive Method
Complementary User Entity Controls (CUECs)
Complementary Subservice Organization Controls (CSOCs)
System Description Boundaries
Visual Explanation: The SOC Ecosystem
Notice that the dashed line between the service organization and the service auditor represents the examination relationship—the auditor tests the controls that fall within the system description boundary. In a carve-out scenario, the subservice organization's box would sit outside the audit boundary, and the service auditor's opinion would explicitly exclude those carved-out controls. In an inclusive scenario, the subservice organization's box would be drawn inside the audit boundary, and the service auditor would test both the service organization's and the subservice organization's relevant controls. Understanding this boundary distinction is critical for CPA candidates because it directly affects the scope of assurance and the user auditor's ability to rely on the SOC report.
How It Works: Scoping the SOC Engagement
Step-by-Step: From System Description to Auditor's Report
The SOC engagement process begins with the service organization's management preparing a system description that delineates the boundaries of the system under review. This description must identify three categories of controls: (1) controls operated by the service organization itself, (2) controls that the service organization assumes user entities have implemented (CUECs), and (3) controls performed by subservice organizations (CSOCs) that are necessary for achieving control objectives. Under SSAE 18 (AT-C Section 320), management must also disclose the method used for each subservice organization—carve-out or inclusive.
Decision Framework: Carve-Out vs. Inclusive
The choice between the carve-out and inclusive methods is not merely stylistic—it carries significant implications for the scope of the service auditor's examination, the cost and complexity of the engagement, and the degree of residual due diligence required by user entity auditors. The inclusive method requires the subservice organization to grant access to the service auditor, submit to testing, and often negotiate contractual provisions for audit rights. The carve-out method is far more common in practice because many subservice organizations—particularly large cloud providers like Amazon Web Services or Microsoft Azure—issue their own independent SOC reports and are unwilling to submit to each client's service auditor individually.
CUECs: The User Entity's Obligation
A SOC report is not a blanket assurance that the service organization's controls are sufficient in isolation. The system description typically lists CUECs that must be in place at the user entity for the control objectives to be fully achieved. Common CUECs include enforcing password complexity requirements, restricting user access provisioning to authorized personnel, performing periodic reconciliations of data processed by the service organization, reviewing output reports for accuracy, and maintaining adequate physical and logical security over interfaces and data transmissions. When a user entity auditor (the auditor of the user entity's financial statements) plans to rely on a SOC report, they must assess whether the user entity has actually implemented these CUECs. If CUECs are not operating effectively, the user auditor cannot simply rely on the SOC report's opinion as sufficient audit evidence; additional substantive procedures may be required.
Classification of Controls Across the Ecosystem
Mapping Controls to Responsible Parties
One of the most practical challenges in a SOC engagement is clearly mapping which controls belong to which party. Ambiguity in this mapping leads to gaps in assurance—situations where neither the service organization nor the user entity has taken responsibility for a critical control. The table below provides a detailed classification of common controls across the three responsible parties in a SOC ecosystem, using a payroll processing service organization as an illustrative context.
| Control Category | Service Organization | User Entity (CUEC) | Subservice Org (CSOC) |
|---|---|---|---|
| Access Control | Enforce role-based access within the payroll application | Promptly notify the service org of terminated employees; enforce password complexity | Restrict physical and logical access to the data center hosting the application |
| Data Integrity | Validate payroll calculations against tax tables and statutory rates | Verify accuracy of employee data submitted (hours, rates, deductions) | Maintain database replication integrity and backup verification |
| Change Management | Follow SDLC procedures for application changes; segregation of duties between dev and production | Test and approve configuration changes to interfaces before implementation | Manage infrastructure patches and operating system updates per SLA |
| Availability | Maintain application uptime SLAs; perform disaster recovery testing | Maintain redundant connectivity to the service org; implement local business continuity plans | Ensure power redundancy, environmental controls, and network uptime at the data center |
| Monitoring | Monitor processing exceptions and produce error reports for user entities | Review exception reports and reconcile output to source data | Provide infrastructure monitoring dashboards and alert notifications per SLA |
Worked Example: Evaluating a SOC 1 Report with Subservice Organizations
Consider the following scenario: You are the user entity auditor for GlobalRetail Inc., whose financial statements you are auditing. GlobalRetail outsources its payroll processing to PayRight Solutions, a service organization. PayRight issues a SOC 1 Type II report. Upon reading PayRight's system description, you discover that PayRight uses CloudVault (a cloud infrastructure provider) for hosting and data storage, and CloudVault's controls have been carved out. The SOC report lists seven CUECs and four CSOCs.
Carve-Out vs. Inclusive: Strengths & Limitations
Both the carve-out and inclusive methods are permissible under AICPA standards, and neither is inherently superior. The choice depends on practical considerations including the subservice organization's willingness to participate, contractual arrangements, and the needs of user entity auditors. The following comparison highlights the trade-offs that service organizations, user entity auditors, and CPA candidates must understand.
| Dimension | Carve-Out Method | Inclusive Method |
|---|---|---|
| Scope of Assurance | Narrower—opinion excludes subservice organization controls | Broader—opinion covers both service and subservice organization controls |
| User Auditor Burden | Higher—user auditor must separately assess subservice org controls (e.g., obtain their SOC report) | Lower—a single SOC report provides end-to-end coverage |
| Cost & Complexity | Lower for the service org; may be higher aggregate cost when user auditors separately assess subservice controls | Higher for the service org due to coordination with subservice org; lower aggregate cost for user auditors |
| Subservice Cooperation | Not required—subservice org operates independently | Required—subservice org must provide access and submit to testing |
| Prevalence | Most common in practice, especially with large cloud providers | Less common; typically seen with captive or closely affiliated subservice organizations |
| Disclosure Requirements | Must disclose subservice org identity, functions performed, and CSOCs | Subservice org controls are described and tested within the report itself |
Connection to Advanced Theory: Multi-Layer Subservice Chains & SOC 2
In today's technology-driven business environment, subservice relationships frequently extend beyond a single layer. A multi-layer subservice chain arises when a subservice organization itself relies on another subservice organization. For example, a SaaS payroll provider (service organization) may use a platform-as-a-service provider (first-tier subservice org), which in turn relies on an infrastructure-as-a-service provider (second-tier subservice org). Each layer introduces additional risk and complexity for user entity auditors attempting to trace the chain of assurance.
| Concept | SOC 1 (ICFR Focus) | SOC 2 (Trust Services Criteria) |
|---|---|---|
| Primary Audience | User entity auditors assessing ICFR | Management, regulators, business partners assessing security, availability, processing integrity, confidentiality, privacy |
| Subservice Org Treatment | Carve-out or inclusive; same framework applies | Carve-out or inclusive; same framework applies. Trust services criteria (CC2.1) requires disclosure. |
| CUECs | Focused on financial reporting controls (access, reconciliation, input validation) | Broader scope: security practices, incident reporting, privacy obligations, data classification responsibilities |
| SSAE 18 Monitoring Requirement | Service org must monitor subservice org controls (e.g., review subservice SOC reports, perform site visits) | Same monitoring obligation applies. CC3.3 and CC9.2 of the Trust Services Criteria reinforce vendor risk management. |
| Multi-Layer Chains | Less common in traditional ICFR contexts | Very common in cloud and SaaS environments; each layer may issue its own SOC 2 report |
Looking forward, the AICPA continues to refine guidance on vendor risk management and the service organization's responsibility to monitor subservice organizations even when using the carve-out method. SSAE 18 explicitly requires service organizations to implement monitoring controls over their subservice relationships—reviewing subservice SOC reports, performing periodic site visits or audits, tracking SLA compliance, and maintaining contractual rights to audit. For CPA candidates, this means understanding that the mere act of carving out a subservice organization does not eliminate the service organization's responsibility to oversee that relationship. The regulatory trajectory suggests increasing scrutiny of these chain-of-trust relationships, particularly as data privacy regulations like GDPR and CCPA impose obligations that flow through service chains.
Practice Problems
Lesson Summary
This lesson examined the two critical concepts that define the boundaries of assurance in SOC engagements. Subservice organizations are entities to which a service organization outsources functions that are relevant to the SOC engagement's control objectives. They can be addressed via the carve-out method (excluded from the service auditor's testing and opinion) or the inclusive method (included in the scope of the examination). Under the carve-out method, complementary subservice organization controls (CSOCs) are disclosed so that user entity auditors know which controls require separate evaluation.
User entity controls (CUECs) are the controls that the service organization's system assumes user entities have in place—such as access management, input validation, and reconciliation procedures. A user entity auditor who plans to rely on a SOC report must verify that CUECs are operating effectively, evaluate CSOCs independently when the carve-out method is used, and perform bridge procedures to address any coverage gaps between the SOC report period and the user entity's fiscal year-end. Together, these concepts ensure that no link in the assurance chain is overlooked and that audit risk is appropriately managed across the entire service delivery ecosystem.