SOC Engagement Planning and Scoping - CPA Tcp

SECTION 1

Historical Context & Motivation

Modern enterprises routinely outsource critical business functions—payroll processing, cloud hosting, investment custody, and data analytics—to third-party service organizations. As outsourcing accelerated through the 1990s and 2000s, user entities (the companies that hire these service organizations) and their auditors faced a persistent question: how can we obtain assurance over controls that operate outside our own walls? Without a standardized framework, every auditor would need to perform independent, redundant testing at every service organization—a costly and inefficient proposition. The professional response to this challenge evolved over several decades, culminating in the System and Organizational Controls (SOC) engagement framework maintained by the American Institute of Certified Public Accountants (AICPA).

1992 • SAS 70 Introduced

The AICPA issued Statement on Auditing Standards No. 70, establishing the first widely adopted standard for reporting on controls at service organizations. SAS 70 became the de facto credential for outsourced processing environments.

2010 • SSAE 16 Replaces SAS 70

The AICPA released Statement on Standards for Attestation Engagements No. 16 (SSAE 16), shifting SOC engagements from an audit standard to an attestation standard and introducing the SOC 1, SOC 2, and SOC 3 report taxonomy.

2017 • SSAE 18 Modernizes the Framework

SSAE 18 (codified as AT-C sections 105, 205, and 320) superseded SSAE 16, strengthening requirements around risk assessment, subservice organizations, and complementary user entity controls (CUECs). It remains the governing standard today.

2018 • SOC 2 Trust Services Criteria Revised

The AICPA updated the Trust Services Criteria (TSC) used in SOC 2 and SOC 3 examinations, aligning them more closely with the 2013 COSO Internal Control—Integrated Framework and adding granularity to the five trust service categories.

2020–Present • SOC for Cybersecurity & Supply Chain

The AICPA expanded the SOC suite to address enterprise-wide cybersecurity risk management and supply-chain risk, reflecting market demand for broader assurance over complex, interconnected technology ecosystems.

Against this backdrop, planning and scoping represents the foundational phase of every SOC engagement. Without rigorous scoping, a practitioner risks examining controls that are irrelevant, omitting controls that are material, or failing to align the report with the needs of intended users. This section of the CPA TCP curriculum explores how practitioners define the system boundaries, select the appropriate report type, assess risk, and establish the criteria against which controls will be evaluated.

SECTION 2

Core Principles of SOC Engagement Planning

Effective SOC engagement planning requires the practitioner to address several interrelated dimensions simultaneously. The engagement must be scoped so that it provides meaningful assurance to user entities and their auditors, while remaining feasible for the service organization to support with documentation and evidence. Five foundational principles underpin every well-structured SOC engagement.

Report Type Selection

The practitioner must determine whether a SOC 1 (ICFR-relevant controls), SOC 2 (Trust Services Criteria), or SOC 3 (general-use TSC report) best serves the intended users' needs. Each report type carries different scoping implications and criteria.

System Description Boundaries

The system under examination must be clearly delineated—infrastructure, software, people, procedures, and data included in the scope must be identified, along with any components explicitly excluded. This prevents scope creep and clarifies accountability.

Criteria Selection

SOC 1 engagements use control objectives relevant to users' ICFR. SOC 2 engagements evaluate controls against one or more of the five Trust Services Categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy.

Risk Assessment & Materiality

The practitioner assesses inherent and control risk factors specific to the service organization's environment, including IT complexity, personnel turnover, regulatory exposure, and prior findings, to determine the nature, timing, and extent of testing procedures.

Subservice Organization Scoping

When the service organization itself outsources functions (e.g., using a cloud infrastructure provider), the practitioner must decide whether to use the inclusive method (including the subservice organization's controls) or the carve-out method (excluding them).

✦

KEY TAKEAWAY

Think of SOC engagement planning like drafting the blueprint for a building inspection. Before the inspector arrives, everyone must agree on which building is being inspected (system boundaries), what standards apply (criteria), which floors are in scope (inclusive vs. carve-out for subcontractors), and who will read the report (intended users). Skipping this blueprint phase leads to wasted effort, gaps in assurance, and reports that fail to satisfy stakeholders.

SECTION 3

Visualizing the SOC Engagement Planning Workflow

The diagram above traces the seven-step planning workflow from initial engagement acceptance through formalization in the engagement letter. Notice how Steps 5 and 6 feed back into the testing strategy, reflecting the iterative nature of risk-informed scoping.

The planning workflow is not strictly linear. As the practitioner deepens understanding of the service organization's environment during Steps 3 through 6, insights may necessitate revisiting earlier decisions—for example, discovering a significant subservice organization may alter the system boundary defined in Step 3 or change the risk assessment conclusions reached in Step 5. The engagement letter at the bottom of the diagram formalizes every scoping decision and serves as the contractual foundation of the engagement. Under SSAE 18, this letter must explicitly describe the system, the applicable criteria, management's responsibilities, the practitioner's responsibilities, and the type of report to be issued.

SECTION 4

How SOC Scoping Decisions Work in Practice

Report Type Decision Logic

The first substantive scoping decision is selecting the appropriate SOC report type. This choice cascades through every subsequent planning decision because it determines the criteria, the intended audience, and the depth of testing required. A SOC 1 engagement (performed under AT-C Section 320) is appropriate when the service organization's controls are relevant to user entities' internal control over financial reporting (ICFR). For example, a payroll processing company or an investment fund administrator would typically undergo a SOC 1 examination because errors in their processing directly affect user entities' financial statements. In contrast, a SOC 2 engagement (performed under AT-C Section 205 using the AICPA Trust Services Criteria) focuses on operational controls across five categories: Security (the common criteria, always included), Availability, Processing Integrity, Confidentiality, and Privacy. SOC 2 is most relevant when user entities need assurance over the service organization's IT controls irrespective of ICFR implications—for instance, a cloud hosting provider or a SaaS platform.

Type I vs. Type II Reports

Within both SOC 1 and SOC 2 frameworks, the practitioner and the service organization must agree on whether the engagement will produce a Type I or Type II report. A Type I report evaluates the suitability of design of controls as of a specified date—essentially a snapshot. A Type II report goes further by evaluating both the design and the operating effectiveness of controls throughout a specified period, typically six to twelve months. Type II reports carry significantly higher evidentiary value because they demonstrate that controls not only exist on paper but function consistently over time. Most mature service organizations pursue Type II reports, while first-time SOC examinees often start with Type I to establish a baseline.

The Five Components of a System Description

Under SSAE 18, the service organization's management is responsible for preparing a system description that delineates the system under examination. The AICPA specifies five essential components of this description, sometimes referred to by the mnemonic ISPDD: Infrastructure (physical and logical), Software (applications and IT), People (roles and competencies), Procedures (manual and automated), and Data (transaction flows and data lifecycle). Scoping the system requires the practitioner to validate that all five components are adequately described and that the boundaries drawn around them are neither too narrow (missing relevant controls) nor too broad (introducing unnecessary testing cost). The practitioner must also identify any complementary user entity controls (CUECs)—controls that the service organization assumes user entities have in place. If user entities fail to implement these CUECs, the controls at the service organization may not operate effectively in the broader control environment.

This decision tree illustrates the branching logic used to select the appropriate SOC report type. The first fork distinguishes ICFR-relevant engagements (SOC 1) from operational/IT controls engagements (SOC 2/3). Subsequent branches address the choice between Type I and Type II, and between restricted-use (SOC 2) and general-use (SOC 3) distribution.

SECTION 5

Trust Services Categories & Scoping Depth

For SOC 2 and SOC 3 engagements, the Trust Services Criteria (TSC) serve as the evaluation framework. The five categories are hierarchical in one important sense: Security (the Common Criteria) is mandatory in every SOC 2 examination, while the remaining four categories—Availability, Processing Integrity, Confidentiality, and Privacy—are included based on the nature of the services provided and the needs of intended users. During scoping, the practitioner and the service organization negotiate which additional categories to include, a decision that significantly affects the volume of controls to be documented and tested.

Trust Services Category	Focus Area	Typical Applicability	Example Controls
Security (CC)	Protection against unauthorized access (logical & physical)	Always required—applies to every SOC 2/3 engagement	Firewalls, MFA, access reviews, intrusion detection, background checks
Availability	System uptime and accessibility per SLAs	Cloud hosting, SaaS platforms, data centers with uptime commitments	Disaster recovery plans, redundant infrastructure, capacity monitoring, incident response
Processing Integrity	Completeness, validity, accuracy, and timeliness of system processing	Transaction processors, fintech platforms, payment gateways	Input validation, reconciliation controls, exception reporting, batch processing checks
Confidentiality	Protection of information designated as confidential	Legal services, M&A advisory, IP-handling organizations	Encryption at rest/in transit, data classification, DLP tools, NDA management
Privacy	Collection, use, retention, disclosure, and disposal of personal information	Healthcare data processors, consumer platforms, HR services	Privacy notices, consent management, data retention schedules, access/correction mechanisms

Trust Services Categories applicable to SOC 2 and SOC 3 engagements

Typical Scoping Breadth by Report Type

Narrower Scope Broader Scope

💡

CPA Exam Tip

On the CPA TCP exam, questions frequently test whether a candidate can distinguish SOC 1 from SOC 2 based on a fact pattern. The critical differentiator is whether the service organization's controls are relevant to user entities' ICFR. If the fact pattern mentions financial statement audit reliance, payroll processing, or transaction recording, SOC 1 is likely correct. If the emphasis is on data security, uptime, or privacy, SOC 2 is the answer.

SECTION 6

Worked Example: Scoping a SOC 2 Engagement

Consider the following scenario. CloudSecure Inc. is a SaaS provider that hosts accounting data for 300 mid-market companies. Its infrastructure runs on Amazon Web Services (AWS), and it uses a third-party payment processor (PayBridge) for customer billing. CloudSecure has never undergone a SOC examination but is receiving increasing requests from user entities' auditors for assurance over security and availability. You are the CPA practitioner engaged to plan this engagement.

Scoping CloudSecure Inc.'s First SOC Engagement

1
Step 1 — Determine Report Type

CloudSecure hosts accounting data, but its controls do not directly process or post transactions to user entities' general ledgers. The user entities' auditors are requesting assurance over data security and system uptime, not over controls relevant to financial statement assertions. Therefore, a SOC 2 report is appropriate.

Report Type: SOC 2
2
Step 2 — Select Type I or Type II

Because this is CloudSecure's first SOC examination, management and the practitioner agree to begin with a Type I report. This allows the company to receive feedback on control design before investing in the more resource-intensive Type II examination. The plan is to transition to Type II within 12 months.

Report Sub-Type: Type I (as of June 30, 2025)
3
Step 3 — Select Trust Services Categories

User entity auditors have specifically requested assurance over security and availability. CloudSecure does not process payments (PayBridge handles that), so Processing Integrity is not directly relevant to CloudSecure's core services. The company handles confidential accounting data, warranting the Confidentiality category. Privacy is excluded because CloudSecure does not collect personal consumer information directly.

Categories: Security (mandatory), Availability, Confidentiality
4
Step 4 — Define System Boundaries (ISPDD)

Infrastructure: AWS us-east-1 region (VPC, EC2 instances, S3 storage, RDS databases). Software: CloudSecure application v4.2, monitoring tools (Datadog), identity management (Okta). People: 45-person engineering team, 8-person DevOps/SRE team, 3-person security team. Procedures: Change management, incident response, access provisioning/deprovisioning, backup and recovery. Data: Customer accounting files, application logs, configuration data. Excluded: CloudSecure's internal HR systems, marketing website, and corporate email.

System: CloudSecure SaaS platform hosted on AWS us-east-1
5
Step 5 — Address Subservice Organizations

CloudSecure relies on AWS for infrastructure and PayBridge for billing. For AWS, the practitioner recommends the carve-out method because AWS publishes its own SOC 2 Type II report, and CloudSecure can reference it. For PayBridge, the carve-out method is also selected because PayBridge maintains its own SOC 1 report. CUECs are identified: user entities must implement their own access controls for user accounts within the CloudSecure platform and must configure role-based permissions.

Subservice Method: Carve-out for both AWS and PayBridge
6
Step 6 — Document in Engagement Letter

All scoping decisions are formalized in the engagement letter, which specifies: (1) the system description boundaries, (2) the applicable Trust Services Categories, (3) the carve-out treatment for AWS and PayBridge, (4) the Type I nature and as-of date, (5) management's responsibility for the system description and assertion, (6) the practitioner's responsibility to express an opinion, and (7) the restricted-use nature of the SOC 2 report.

Engagement letter executed — planning phase complete

SECTION 7

Comparing SOC Report Types: Strengths and Limitations

Understanding the comparative advantages and constraints of each SOC report type is essential for practitioners and for user entities evaluating which type of assurance to request. The table below distills the key differences across several dimensions that directly affect scoping decisions.

Dimension	SOC 1	SOC 2	SOC 3
Governing Standard	AT-C 320	AT-C 205 + TSC	AT-C 205 + TSC
Criteria	Control objectives relevant to ICFR	Trust Services Criteria (5 categories)	Trust Services Criteria (5 categories)
Distribution	Restricted use	Restricted use	General use (publicly distributable)
Detail Level	Full system description, control testing details, exceptions	Full system description, control testing details, exceptions	Summary opinion only—no detailed testing or exceptions disclosed
Primary Users	User entities' management and auditors	User entities, regulators, business partners with NDA	Anyone—often used for marketing and stakeholder communication
Scoping Complexity	Moderate—driven by financial reporting relevance	High—multiple TSC categories, subservice orgs, CUECs	Lower—uses same criteria as SOC 2 but produces a condensed deliverable

Comparative analysis of SOC 1, SOC 2, and SOC 3 report types

✦

KEY TAKEAWAY

Think of SOC report types as different tiers of due diligence in M&A transactions. A SOC 3 is like a public fact sheet—broad and accessible, but lacking the granularity needed for decision-making. A SOC 2 is analogous to a full due diligence data room—restricted access, detailed disclosures, and exception tracking. A SOC 1 is the equivalent of a targeted financial due diligence workstream—narrowly focused on controls that directly affect financial reporting. Choosing the wrong tier wastes resources or leaves critical risks unexamined.

SECTION 8

Connecting to Advanced SOC Concepts

SOC engagement planning does not exist in isolation. Practitioners with experience in SOC engagements must increasingly navigate connections to broader assurance and governance frameworks. The table below situates SOC planning concepts alongside their advanced counterparts, illustrating how foundational scoping skills extend into more specialized domains.

Planning Concept	Foundational Application	Advanced Extension
System Boundary Definition	Identifying the five ISPDD components for a single service	SOC for Cybersecurity: scoping entity-wide risk management programs across all business lines and geographies
Subservice Organization Scoping	Carve-out vs. inclusive method for one or two subservice organizations	SOC for Supply Chain: mapping multi-tier vendor dependencies and assessing controls across the full supply chain
Risk Assessment	Evaluating inherent and control risk at the service organization level	Integrated risk assessments combining SOC findings with ISO 27001, NIST CSF, and HITRUST certifications
Criteria Selection	Choosing among ICFR control objectives or TSC categories	Mapping TSC to regulatory requirements (GDPR, HIPAA, CCPA) and developing integrated compliance reporting
CUECs	Identifying controls assumed to exist at user entities	Continuous monitoring platforms that automate CUEC verification and provide real-time assurance dashboards

From foundational SOC planning to advanced assurance frameworks

As the assurance landscape evolves, practitioners who master the fundamentals of SOC engagement planning are well positioned to lead engagements in emerging areas such as SOC for Cybersecurity and SOC for Supply Chain. These newer frameworks extend the same scoping logic—defining boundaries, selecting criteria, assessing risk, and addressing third-party dependencies—to broader organizational contexts. The AICPA's ongoing guidance documents signal that future SOC standards may further integrate environmental, social, and governance (ESG) reporting controls, making scoping skills even more versatile and valuable for the modern CPA.

SECTION 9

Practice Problems

Question 1: CONCEPTUAL

A CPA firm is hired to examine controls at a company that processes payroll on behalf of 150 employer clients. The employer clients' auditors need to rely on these controls when auditing the clients' financial statements. Should this be a SOC 1 or SOC 2 engagement, and why?

Show answer

This should be a SOC 1 engagement. The payroll processing company's controls are directly relevant to the employer clients' internal control over financial reporting (ICFR), because payroll transactions affect salaries expense, payroll tax liabilities, and benefit accruals on the clients' financial statements. The employer clients' auditors need to understand and rely on these controls as part of their ICFR assessment under AU-C 402. SOC 2 would be inappropriate here because the primary assurance need is financial reporting relevance, not operational IT criteria like availability or confidentiality.

Question 2: BASIC CALCULATION

A SOC 2 Type II engagement covers a 12-month reporting period. The service organization has 85 controls mapped to the Security (Common Criteria) category, 30 controls mapped to Availability, and 20 controls mapped to Confidentiality. If the practitioner plans to test each control once per quarter for the Type II period, how many total individual control test procedures are planned? How would this number change if the service organization removed the Confidentiality category from scope?

Show answer

Total controls in scope = 85 + 30 + 20 = 135 controls. With quarterly testing (4 tests per control per year), the total number of individual test procedures = 135 × 4 = 540 procedures. If Confidentiality is removed, the in-scope controls drop to 85 + 30 = 115, and the total test procedures become 115 × 4 = 460 procedures. This represents a reduction of 80 test procedures (540 − 460), illustrating how scoping decisions directly affect engagement effort and cost. Note that in practice, some controls may serve multiple categories and the testing frequency may vary based on risk assessment.

Question 3: INTERMEDIATE

DataVault Corp. provides cloud storage and data analytics services. It uses AWS for infrastructure and a third-party encryption provider (CryptoShield) to manage encryption keys. DataVault is planning its first SOC 2 Type I engagement. The practitioner must decide whether to use the inclusive or carve-out method for each subservice organization. AWS publishes a publicly available SOC 2 Type II report; CryptoShield does not have any SOC report. What scoping method would you recommend for each, and what additional procedures might be required?

Show answer

For AWS, the carve-out method is appropriate because AWS independently publishes a SOC 2 Type II report that DataVault can reference, and including AWS's controls within DataVault's scope would be impractical—DataVault has no ability to provide evidence for AWS's internal controls. User entities can review AWS's own SOC report for assurance over infrastructure controls. For CryptoShield, the decision is more nuanced. Because CryptoShield lacks its own SOC report, the carve-out method would leave a gap in assurance over a critical function (encryption key management). The practitioner could recommend the inclusive method if CryptoShield grants access for testing, or use the carve-out method and disclose CryptoShield as a carved-out subservice organization while identifying specific CUECs. Additional procedures might include obtaining a bridge letter from CryptoShield, performing alternative procedures such as reviewing CryptoShield's SOC readiness documentation, or recommending that DataVault contractually require CryptoShield to obtain its own SOC report.

Question 4: APPLIED

You are planning a SOC 2 Type II engagement for FinServe Solutions, a financial technology company that provides automated reconciliation services for banks. FinServe processes 2 million transactions daily, uses three subservice organizations, has experienced significant employee turnover in its IT department (40% in the past year), and recently migrated its core application to a new platform. Draft a risk assessment memorandum identifying at least four specific risk factors, the Trust Services Categories you would recommend including in scope, and how each risk factor would influence the nature, timing, or extent of your testing procedures.

Show answer

Risk Factor 1: High transaction volume (2M daily) increases inherent risk of processing errors, supporting inclusion of the Processing Integrity category and requiring the practitioner to perform more extensive testing of automated reconciliation controls, including larger sample sizes for transaction-level testing. Risk Factor 2: Significant IT turnover (40%) elevates control risk because institutional knowledge may be lost, segregation of duties may be compromised during transitions, and access provisioning/deprovisioning controls may not operate consistently. This justifies increased testing of logical access controls and more frequent sampling intervals throughout the period. Risk Factor 3: Recent platform migration creates elevated risk of control design deficiencies in the new environment, configuration errors, and data integrity issues during migration. The practitioner should perform targeted testing of change management controls around the migration, validate data integrity post-migration, and potentially test controls both before and after the cutover date. Risk Factor 4: Three subservice organizations introduce dependency risk—each must be evaluated for the carve-out versus inclusive method, and monitoring controls over these third parties must be tested. Recommended TSC categories: Security (mandatory), Processing Integrity (due to transaction volume and reconciliation nature), Availability (banks depend on continuous service), and Confidentiality (financial data sensitivity). These risk factors collectively support a more conservative testing approach with larger sample sizes, more frequent testing intervals, and focused attention on controls that mitigated the risks created by turnover and migration.

Question 5: CRITICAL THINKING

A service organization's management insists on narrowing the scope of a SOC 2 engagement by excluding several controls related to data backup and disaster recovery, arguing that these controls are 'operational' and not relevant to the Trust Services Criteria. However, the practitioner has identified these controls as directly supporting the Availability category, which is in scope. Analyze the professional and ethical considerations the practitioner faces. What should the practitioner do, and what are the potential consequences of acquiescing to management's request?

Show answer

This scenario raises fundamental issues of professional independence, objectivity, and adherence to attestation standards. Under SSAE 18 and AT-C 205, the practitioner is responsible for determining whether the controls identified by management are sufficient to meet the applicable criteria. If backup and disaster recovery controls are necessary to satisfy the Availability criteria—as they almost certainly are, since availability inherently requires recovery capability—then excluding them would render the system description incomplete or inaccurate, potentially leading to a qualified or adverse opinion. The practitioner should clearly communicate to management that the Trust Services Criteria for Availability explicitly address system recovery, business continuity, and disaster recovery. The AICPA's TSC point of focus A1.2, for example, addresses environmental protections and recovery procedures. Excluding these controls while the Availability category remains in scope would mean the system description does not fairly present the system. If management refuses to include these controls, the practitioner has several options: (1) remove the Availability category from scope entirely, if management agrees and if doing so would still serve intended users' needs; (2) include the controls over management's objection and test them; or (3) decline or withdraw from the engagement if management's position fundamentally compromises the engagement's integrity. Acquiescing would risk issuing a misleading report, violating professional standards (AT-C 105 on ethical requirements), exposing the firm to liability, and undermining the value of the SOC report to user entities who rely on it for assurance over availability.

SUMMARY

SOC Engagement Planning and Scoping — Summary

Summary

SOC engagement planning begins with engagement acceptance and proceeds through a structured workflow encompassing report type selection (SOC 1 for ICFR-relevant controls under AT-C 320, SOC 2 for Trust Services Criteria under AT-C 205, or SOC 3 for general-use distribution), system boundary definition using the five ISPDD components (Infrastructure, Software, People, Procedures, Data), criteria selection including the mandatory Security (Common Criteria) category and optional Availability, Processing Integrity, Confidentiality, and Privacy categories, and risk assessment that drives the nature, timing, and extent of testing.

Critical scoping decisions include the choice between Type I (design as of a date) and Type II (design and operating effectiveness over a period) reports, the treatment of subservice organizations via the inclusive or carve-out method, and the identification of complementary user entity controls (CUECs). All decisions are documented in the engagement letter, which serves as the contractual and professional foundation for the examination. Mastery of these planning concepts is essential for CPA candidates preparing for the TCP section and for practitioners entering the assurance services profession.