SOC 2 Scoping, Gap Analysis, and Risk Assessment
Domain 2 - SOC 2 scoping, gap analysis, and risk assessment. The exam tests whether you can define a defensible system boundary, choose trust services categories from commitments, and connect risk assessment to controls.
Scope from commitments, not convenience
- The system description defines the boundary: infrastructure, software, people, procedures, and data, plus supporting services that materially affect the criteria.
- Categories are selected from contracts, SLAs, marketing claims, and customer obligations. If you promise 99.9% uptime, Availability is in scope.
- Subservice organizations are handled carve-out (their controls excluded, CSOCs listed) or inclusive (their controls described and tested). Document and justify the choice.
Gap analysis is not an audit
A gap analysis compares the current control set to each applicable criterion, records design gaps and missing evidence, and produces a remediation plan with owners, dates, and risk ranking. It yields no opinion and cannot be presented to customers as assurance.
Risk assessment
CC3 expects identification of threats and vulnerabilities, fraud risk, and the effects of significant change. Maintain a risk register with likelihood, impact, treatment (mitigate, accept, transfer, avoid), and a mapped control for each risk above appetite. Scoping decisions should trace back to that register.
Worked example
A SaaS company runs on a hyperscaler, promises 99.9% uptime, processes card data, and outsources payroll. Reasoning: Availability is in scope because of the SLA; the hyperscaler is typically carve-out with CSOCs; Confidentiality enters scope because card data is handled; payroll sits outside the boundary unless it touches in-scope data; CUECs are written for customer-side administration.
Traps
Scoping to what is easy to test rather than what was promised; assuming a vendor's SOC 2 covers your own controls; omitting the risk assessment from evidence; forgetting to refresh scope after a major architecture change.