Scope pentesting around the controls auditors will actually evaluate, especially authentication, authorisation, sensitive data exposure, and remediation evidence. For SaaS, that usually means testing the application layer, token handling, role boundaries, and any privileged workflows that could affect confidentiality or availability. A good scope mirrors real attack paths rather than infrastructure alone.
Why This Matters for Security Teams
SOC 2 pentesting is not about proving that a SaaS platform is impossible to breach. It is about showing that the company understands its attack surface, has tested the controls tied to confidentiality, availability, and change management, and can evidence remediation. A narrow or infrastructure-only scope often misses the behaviours auditors care about, especially around authentication flows, session handling, privilege boundaries, and data exposure paths.
For SaaS applications, that matters because the highest-risk failures usually sit in the product layer rather than the host layer. Attackers look for broken access control, insecure object references, weak tenant isolation, and token abuse, while auditors look for whether those risks were identified and handled in a disciplined way. Guidance from OWASP Non-Human Identity Top 10 also reinforces that service accounts, API keys, and automation credentials can become material attack paths in modern SaaS environments.
Teams commonly get this wrong by testing what is easiest to reach instead of what is most material to the control environment. In practice, many security teams encounter scope gaps only after an auditor asks for evidence of coverage on the very workflows that were left out of the original test plan.
How It Works in Practice
Effective scoping starts with the audit narrative: identify which SaaS controls are expected to support the SOC 2 trust services criteria and then translate those controls into testable attack paths. That usually means focusing on user authentication, session management, password reset, tenant isolation, role-based access control, privileged administration, API authorisation, and any workflow that can alter customer data or service availability. A broad vulnerability scan is useful, but it is not a substitute for scenario-based testing.
Strong scopes also distinguish between what the pentester can safely exercise in production, what should be tested in staging, and what must be excluded to avoid unnecessary impact. For SaaS, that often includes rate limits, destructive actions, and third-party dependencies that cannot be fully controlled. The goal is not maximum coverage of everything technical. The goal is evidence that the highest-risk paths were examined with enough depth to support the control story.
- Map test objectives to SOC 2-relevant controls, not just to application components.
- Include account lifecycle flows, especially invite, reset, recovery, and deprovisioning.
- Test privilege escalation and tenant breakout scenarios where the product design allows it.
- Cover secrets handling for API keys, tokens, certificates, and automated integrations.
- Require retest evidence and remediation tracking so findings are auditable.
For methodology, many teams align to established testing guidance such as the OWASP Web Security Testing Guide and threat-informed context from the ENISA Threat Landscape, then adapt the scope to the SaaS architecture and customer-facing risk. These controls tend to break down when multi-tenant authorisation is implemented inconsistently across microservices because the test scope no longer reflects how access decisions are actually enforced.
Common Variations and Edge Cases
Tighter pentest scoping often increases cost and coordination effort, requiring organisations to balance audit-ready evidence against product release timing and operational risk. That tradeoff is especially visible in SaaS environments with continuous deployment, where a single point-in-time test can age quickly if releases are frequent.
There is no universal standard for the exact perimeter of a SOC 2 pentest. Current guidance suggests the scope should be risk-based and architecture-aware, but the practical boundary depends on whether the SaaS product is single-tenant or multi-tenant, whether customers manage their own identities through SSO, and whether the provider controls privileged automation on behalf of customers. If the platform relies heavily on non-human identities, service-to-service authentication, or agentic workflows, those paths deserve explicit inclusion because they often carry more privilege than human users.
Edge cases also matter. External attack surface testing may be appropriate for public APIs and login pages, while deeper authorisation testing may need privileged test accounts and carefully controlled staging data. If the application processes regulated or sensitive data, scope should also reflect the blast radius of a compromise rather than the size of the codebase. A good rule is to ask which failed control would most weaken the SOC 2 assurance story, then make sure the test plan covers that failure mode directly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Access control is central to SaaS pentest scope and SOC 2 assurance. |
| MITRE ATT&CK | T1078 | Valid account abuse is a common SaaS attack path during testing. |
| OWASP Non-Human Identity Top 10 | SaaS often depends on tokens and service accounts that need explicit testing. | |
| NIST AI RMF | GOVERN | Risk governance should define what SaaS attack paths are in scope. |
Test authentication and authorisation paths that prove least-privilege access is enforced.
Related resources from NHI Mgmt Group
- How should security teams govern AI features embedded in SaaS applications?
- How should security teams govern Shadow AI in SaaS applications?
- How should security teams inventory webhook integrations across SaaS applications?
- How should security teams govern SaaS applications that rely on integrations and shared data?
