How should organisations scope a penetration test for SOC 2 or ISO 27001 compliance?

Work with the auditor first and treat the framework requirement as a baseline, not the full answer. The safest scope is the one the auditor will accept, because annual testing language often leaves room for interpretation. A provider can advise from experience, but final scope should reflect audit expectations, system risk, and the boundaries of the environment being tested.

How to scope a SOC 2 or ISO 27001 penetration test

The scope should be driven by the control objective, the in-scope systems and the auditor’s expectations, not by a generic “test everything” rule. For SOC 2, anchor the test to the services and boundaries described in the report. For iso 27001, align it to the ISMS scope and the assets, interfaces, and trust paths that matter most to the organisation’s risk profile.

What belongs in scope for compliance testing

Start with the external and internal attack surface that could credibly affect the systems the audit is meant to cover. That usually includes internet-facing applications, VPN and remote access entry points, identity and access paths, critical administration interfaces, cloud control planes, and any third-party connection that can reach in-scope data or services. If a system is out of scope on paper but can materially influence an in-scope environment, it deserves at least consideration in the test design.

Scoping should also follow the audit narrative. In SOC 2, the test should support the trust services criteria that are actually being asserted, especially security and confidentiality where access paths and data exposure matter most. In ISO 27001, the test should reflect the controls and boundaries documented in the ISMS rather than a one-size-fits-all checklist. That is why many teams use the standard as a baseline, then narrow or widen the test based on business criticality and exposure. For implementation guidance on control selection, the ISO/IEC 27002:2022 Information Security Controls companion is often the more useful reference, while the SOC 2 Trust Services Criteria (AICPA) set the compliance context for the report itself.

For cloud-heavy environments, the scope should include the seams where trust assumptions usually fail: identity federation, exposed APIs, storage permissions, privileged roles, CI/CD paths, and any externally reachable management layer. A test can be technically broad and still be audit-relevant if it is tied to the systems that create the reportable risk. In cloud and service-account driven environments, internal attack paths can matter as much as public entry points, which is why the test boundary should be drawn from actual privilege and connectivity, not just network topology. Where cloud control mapping is needed, the CSA Cloud Controls Matrix can help translate those boundaries into control language.

How auditors, providers, and risk determine the final scope

The practical scope decision is a three-way balance: what the auditor will accept, what the organisation can justify from a risk perspective, and what the provider can credibly execute. Auditors usually care less about test volume than about whether the chosen scope is defensible, documented, and aligned to the system boundary and control claims. Providers can advise where the likely weak points are, but they should not be allowed to invent a narrower scope simply because it is easier to test.

That is why scoping should be explicit about exclusions. If a system is excluded, the record should explain whether the reason is outside the audit boundary, duplicate coverage, immaterial exposure, or operational infeasibility. The more the environment relies on shared services, federated identity, or third-party integrations, the less useful a purely application-centric scope becomes. In those cases, a focused test of authentication, privilege paths, and third-party trust relationships is often more valuable than adding extra low-risk assets that do not change the audit outcome. The ISO/IEC 27001:2022 Information Security Management standard is the anchor point for the ISMS boundary and risk treatment logic that should inform that decision.

Risk and Threat Considerations

A poorly scoped pen test can create false comfort. If the test omits the entry points or privilege paths that actually connect into the audited environment, the organisation may pass a compliance exercise while leaving the highest-risk attack routes untouched. The same problem appears when the scope is too broad in low-value areas, because the test effort gets diluted and the material exposures are not exercised deeply enough.

Failure mechanism: Teams often scope to visible applications or named systems, but attackers usually exploit the connection points between systems, especially authentication, admin access, cloud permissions, and third-party trust relationships.

Impact: The result can be a compliance-aligned report that misses the most realistic path to compromise, which weakens both audit assurance and actual security posture.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

SOC 2 (AICPA) and ISO/IEC 27001:2022 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
SOC 2 (AICPA)	CC6.1 — Logical and Physical Access Controls	Pen test scope must cover access paths that protect in-scope SOC 2 systems.
Recommendation — Test the access paths that could affect SOC 2 in-scope systems and evidence.
ISO/IEC 27001:2022	A.5.15 — Access Control	Scope should include the access paths and trust boundaries in the ISMS scope.
	A.8.8 — Management of Technical Vulnerabilities	Pen testing helps identify exploitable weaknesses in scoped systems and interfaces.
	A.5.35 — Independent Review of Information Security	Audit-facing testing scope should be independently reviewable and defensible.
Recommendation — Include the access paths that define the ISO 27001 scope boundary. Target exploitable weaknesses in the systems and interfaces you have scoped. Ensure the scope is reviewable and defensible before the test begins.

Practitioner Guidance

What to verify: Confirm that the scope statement matches the system boundary used in the compliance evidence, not just the network diagram. If the audit claim covers production services, the test should cover the paths that can reach production, including remote access, privileged admin functions, and externally exposed dependencies.

Decision rule: If a candidate in-scope system can change, access, or disrupt the audited service, keep it in scope even if it is not customer-facing. If it cannot materially affect the service or data under review, exclude it and document why.

Practitioner takeaway: The best compliance scope is the smallest scope that still forces the test to exercise the real attack and privilege paths behind the audit claim; anything narrower risks becoming a paperwork exercise rather than a meaningful security test.