.svg)
TL;DR: The core question for SOC 2 people scoping: does their role or access affect your system's ability to meet its Trust Services Criteria commitments? Developers, IT ops, and anyone with production access are always in scope. All employees are in scope for security awareness (CC1.1). Customer support, HR, and finance fall into a grey area that depends on data access. Contractors and vendors need policy acknowledgment (CC1.1, CC1.4, CC8.1) to extend your control environment.
SOC 2 Scoping Has Three Dimensions
SOC 2 scoping covers three areas: systems (infrastructure, software, data flows), people (employees, contractors, vendors), and processes (policies, procedures, controls that govern operations). This post focuses on people scoping, which is where companies underestimate the complexity. The AICPA defines a system as infrastructure, software, procedures, and data operated by people to achieve business objectives, so the people dimension touches everything else.
This is part of a three-part SOC 2 scoping series. Systems scoping and process scoping guides are coming soon.
The Impact Test: Who Needs to Be In Scope?
Your SOC 2 scope extends to every person whose activities directly or indirectly affect the controls designed to meet your Trust Services Criteria. That goes beyond W-2 employees to include contractors, vendors, and business partners. The test is simple: does their role or access affect your ability to meet your service commitments to customers?
Always In Scope: Direct System Access
Anyone with logical or physical access to protected information assets or systems that support your services is in scope. No ambiguity here:
- Production access: Developers, SREs, and DevOps engineers who deploy to production. If they can push code or change configuration, they're in scope.
- Development and staging: Engineers, QA, and architects working in environments where changes are prepared for production. The code they write today runs in production tomorrow.
- Infrastructure operations: DBAs, network engineers, and IT ops managing databases, servers, and network configurations. A DBA managing the customer database directly affects processing integrity and confidentiality.
Always In Scope: Security Awareness (Everyone)
CC1.1 (Commitment to Integrity and Ethical Values) and CC1.4 (Competent Individuals) bring everyone into scope for security awareness, regardless of technical access. That includes:
- All employees for security and privacy awareness training. Non-technical staff still need to recognize phishing, understand acceptable use policies, and report incidents.
- Senior management for oversight. Their role in establishing the control environment and setting expectations is a core audit focus.
The Grey Area: Support Functions That May Be In Scope
Some roles don't touch production systems but still affect your control environment. This is where scoping decisions get nuanced.
.svg)
Typically out of scope (for core system controls, still in scope for security awareness):
- Office maintenance staff with no system or data access
- External accountants handling only company financial records
- Marketing limited to analytics and public-facing tools with no customer data access
Contractors, Vendors, and Business Partners
Your scope doesn't end at your payroll. The AICPA explicitly includes contractors, vendors, and business partners. When you outsource functions, you can address third parties through the inclusive method (their controls become part of your system description) or the more common carve-out method (their services are identified, but their controls are excluded, with your monitoring controls included). Either way, their personnel who interact with your system need to be scoped.
Policy Acknowledgment: The Evidence That Makes It Work
Scoping third parties is one thing. Proving your control environment extends to them is another. The Trust Services Criteria require that outsourced personnel understand your standards of conduct (CC1.1) and that you've assessed their competency (CC1.4).
At minimum, contractors and vendor personnel need to acknowledge:
- Standards of conduct covering ethical behavior, security practices, and incident reporting
- Security policy covering access, acceptable use, and incident response
- Change management policies (CC8.1) if they perform development or maintenance work
Beyond acknowledgment, you need processes to evaluate adherence periodically (reviewing their SOC 2 reports, conducting vendor security assessments) and address deviations when they surface. The acknowledgment itself isn't the control. The ongoing oversight is.
Operationalizing People Scope with GRC Platforms
Tracking access, training status, and policy acknowledgments across employees, contractors, and vendors manually doesn't scale. GRC platforms like Secureframe, Vanta, and Drata integrate with your HRIS, identity provider, and other systems to automate the operational side of people scoping: identifying personnel, tracking onboarding and offboarding, monitoring access permissions, and collecting training and policy acknowledgment evidence.
The result is a single source of truth for your auditors and real-time visibility into gaps, so you're addressing issues as they surface rather than scrambling before an audit.
Action Plan
Six Steps to Get People Scoping Right
- Inventory all personnel. List everyone who interacts with your systems or impacts your control environment: employees, contractors, vendors, business partners.
- Apply the impact test. For each person: does their role or access affect your Trust Services Criteria commitments? Document the rationale.
- Map access and training. Verify MFA and least-privilege for system access. Confirm security awareness training for all in-scope personnel (CC1.1).
- Formalize vendor relationships. Contracts, standards of conduct, policy acknowledgments (CC1.1, CC1.4, CC8.1). Request and review their SOC 2 reports where applicable.
- Automate with a GRC platform. Personnel tracking, access reviews, training management, and acknowledgment collection in one place.
- Review regularly. At minimum annually, and whenever significant organizational changes occur: new hires in technical roles, new vendor relationships, or system architecture changes.
Not sure who's in scope?
We'll review your team structure, vendor relationships, and access patterns, then map them to an effective security program where scoping is clear and defensible.
Frequently Asked Questions
What determines whether a person is in scope for SOC 2?
The test is whether their role or access directly or indirectly affects your system's ability to meet its Trust Services Criteria commitments. Anyone with access to production systems, customer data, or critical infrastructure is in scope. All employees are in scope for foundational controls like security awareness training (CC1.1), regardless of their technical access level.
Are contractors and vendors included in SOC 2 people scope?
Yes. The AICPA explicitly includes contractors, vendors, and business partners. You can address them using the inclusive method (their controls become part of your system description) or the more common carve-out method (their services are identified but their controls are excluded, with your monitoring controls included). Either way, they must acknowledge your security policies.
What is the difference between the inclusive and carve-out method?
The inclusive method incorporates a vendor's controls directly into your SOC 2 system description and audit scope. The carve-out method identifies the vendor's services but excludes their specific controls, focusing instead on your controls for monitoring that vendor. Carve-out is far more common because it keeps your audit scope manageable while still demonstrating oversight.
Which roles are typically out of scope for SOC 2?
Roles with no access to customer-facing systems or sensitive data are generally out of scope for core system controls: office maintenance staff, external accountants handling only company financial records, and marketing personnel limited to non-production systems. However, all employees remain in scope for security awareness training under CC1.1.
How often should SOC 2 people scope be reviewed?
At minimum annually, and whenever significant organizational changes occur: new hires in technical roles, new vendor relationships, system architecture changes, or acquisitions. As your company grows, new roles and vendor relationships will emerge that need to be evaluated against the Trust Services Criteria.
About the Author
