SOC 2 Penetration Testing: Scope, Method and Evidence Your Auditor Can Use

A hypothetical scene: a B2B payroll service for mid-sized companies is going through its first SOC 2 Type 2. A month before the observation period ends, a large prospect sends a security questionnaire with one line that matters: "Attach a penetration test report covering the systems within the boundary of your SOC 2 report." The company has a report. It was bought six months earlier at the lowest price: the vendor scanned the marketing site and a test environment, attached forty pages of scanner output and issued a "clean" conclusion. The prospect's security team asks three questions: was the production API that carries payroll files tested; was isolation between customers checked; were the findings fixed and re-verified? The honest answer to all three is no.

The scenario is invented, but the procurement risk is real: a SOC 2 penetration test can be bought as a document rather than as a meaningful assessment. A company that chooses on price and page count alone risks paying once for evidence that does not answer the auditor's questions and again for the additional testing those questions reveal. Below we look at what SOC 2 actually says about penetration testing, how to scope a test by the system boundary, which methodology to test against, how to turn findings into traceable evidence, and what to look for when choosing a vendor.

What SOC 2 says about penetration testing, and what it does not

SOC 2 is not a certification. An organization can obtain a SOC 2 report after an examination by an independent CPA service auditor; the report addresses the service organization's controls relevant to security, availability, processing integrity, confidentiality or privacy. The basis is the AICPA Trust Services Criteria, the 2017 edition with points of focus revised in 2022. Type 1 and Type 2 are report types, not maturity levels: put simply, the first addresses control design as of a date, the second also covers how controls operated over a period.

One detail is frequently distorted: the AICPA criteria do not establish a universal requirement to "run a penetration test every year". The criteria are framed as control objectives, and the organization chooses how to meet them. A pentest becomes part of the picture when specific circumstances tie it in: the organization's own control in its system description ("external penetration testing is performed at least annually"), the outcome of its risk assessment, a contractual commitment to customers, or the auditor's evidence expectations for monitoring and vulnerability management. So the first conversation about a pentest should be with the auditor, not the vendor: which Trust Services Categories are in scope, where the system boundary lies, which subservice organizations are carved out, which period the evidence must cover, and how the auditor intends to use test results.

The pentest itself is not the SOC 2 attestation. A tester can conclude whether particular controls held under the scenarios, scope and conditions tested, but the SOC 2 opinion belongs to the service auditor and no tester can guarantee a clean report. NIST SP 800-115 presents vulnerability discovery and verification against policy or other requirements as possible assessment objectives. The parties should agree whether this engagement pursues one objective or both. For SOC 2 evidence, combining technical discovery with checks tied to selected controls is often useful: discovery without control context can be hard to place, while a narrow conformance check can miss the paths customer data actually travels.

Scoping the pentest by the SOC 2 system boundary

Scope should follow the system described in the report, not whatever is convenient or cheap to test. Depending on the system description, the boundary may contain components that store, process or transmit customer data: production applications, public and partner APIs, authentication and session mechanisms, administrative consoles and support tooling, and supporting cloud or network infrastructure. Testing only the marketing site may produce few findings, but it does not justify a clean conclusion about the in-scope product and is weak evidence for controls elsewhere in the boundary.

What to list in the scope document

A good scope document reads without its author in the room. It names the applications, domains, APIs, environments and cloud accounts; states which roles and tenants were created for the test; and describes the expected boundaries between them. Exclusions are listed separately and explicitly, with a reason: "billing provider is a subservice organization tested under its own programme", "mobile app is outside the boundary of the current report". The auditor should see what was not tested and understand that it was a deliberate decision rather than a forgotten item.

The environment is a separate question. Sometimes testing production is risky and work moves to staging. That is a legitimate choice, but results do not carry over to production automatically: different configuration, feature flags, secrets, network rules and data volumes change the picture. If testing happens in staging, record the known differences from production and decide with the auditor which checks still need confirmation in the live environment, such as external configuration and headers.

Authorization, rules of engagement and third-party platforms

NIST SP 800-115 makes planning the first phase of an assessment, and for SOC 2 that is especially sensible. Before work starts, the parties agree in writing on what is in and out of scope, testing windows, prohibited techniques, handling of test data and of sensitive data discovered by accident, stop conditions, and emergency contacts in case something goes wrong.

Authorization must come from the people actually empowered to decide about each target system. A commercial director's signature on the vendor contract does not grant the right to test a cloud provider's infrastructure, a partner's SaaS service or a platform operated by a third party: they have their own rules, which must be checked separately. If part of the system belongs to a subsidiary or a customer, their consent is needed too.

Attacker positions and tenant isolation

Scope is defined not only by the asset list but by the positions the test is run from. The usual set is an external unauthenticated user, an authenticated user at each meaningful privilege level and, for multi-tenant products, a user of one tenant trying to reach another tenant's data. For SOC 2 report readers that last position often matters most: an enterprise customer cares above all that the neighbouring customer cannot see its payroll files. How to design such checks for a cloud product is covered in more detail in our piece on penetration testing for SaaS companies.

If you are still assembling the boundary and roles, this is a good moment to discuss scope with Pentest.red: from the system description and the list of environments and roles you can see in advance where a test will give the auditor useful evidence and where it would go beyond what a pentest is able to confirm.

Methodology: NIST SP 800-115 and the OWASP WSTG

The three NIST assessment phases

NIST SP 800-115 was published in September 2008 and superseded SP 800-42. It describes technical testing as a process with three phases: planning, execution and post-execution. Planning covers objectives, scope, rules and logistics. Execution covers the techniques themselves, from discovery and scanning to penetration attempts. Post-execution covers analysis of findings, remediation recommendations and reporting. The guide discusses the strengths and limitations of individual techniques rather than promising a comprehensive testing programme.

The document's age means it should be combined with current application testing methods rather than used alone. As a frame, though, it is useful: an auditor finds it easier to accept results when the test was visibly planned, executed and analysed against a recognized structure. NIST's catalogue also relates the guide to several control families — audit and accountability, assessment and monitoring, risk assessment, system and services acquisition, system and communications protection, system and information integrity. That helps explain how a technical test relates to control areas. A catalogue relationship does not mean a specific control in your system description works. A test and retest can provide evidence for that control under recorded conditions; the auditor evaluates it together with design, operation and other relevant evidence.

A working method for web applications and APIs

For web applications and APIs, the OWASP Web Security Testing Guide gives more detail. It is an OWASP flagship project covering testing of configuration, identity, authentication, authorization, session management, input validation, business logic and the client side. The vendor should name the version it works to — for example, 4.2 — and show how its test plan maps to it.

The point is verifiability. Nobody outside a vendor can examine its private checklist. A named, versioned method lets the auditor, the customer and your own team understand which classes of checks were performed and which were deliberately skipped.

Coverage depth: OWASP Top 10, ASVS and CWE weakness classes

The OWASP Top 10 is an awareness document about the most critical web application security risks, reflecting broad practitioner consensus; OWASP publishes 2025, 2021 and 2017 editions, and a report should state which one it used. For a SOC 2 pentest it is a floor, not a ceiling. A report that claims only "OWASP Top 10 coverage" describes a minimum set of topics, not the depth of testing.

OWASP ASVS solves a different problem: it defines verifiable application security requirements and narrows the variation in testing rigour across the market. Each requirement has an identifier that OWASP recommends citing together with the standard version, in a format such as v5.0.0-1.2.5: version, then chapter, section and requirement number. Requirements are also published in machine-readable formats. For SOC 2 this is convenient: a finding tied to a versioned requirement can be compared with last year's, tracked in tickets and checked without interpretation. A caveat: an ASVS mapping belongs only where the requirement genuinely applies, and on its own it does not prove the application conforms to the standard.

CWE classification is useful for another reason. MITRE publishes the CWE Top 25 Most Dangerous Software Weaknesses, built from real CVE data — the 2025 list, for example — and positions it as feedback for development and architecture. When findings with a suitable technical weakness carry an applicable CWE, a series of reports becomes data: you can see whether identified defect classes disappear or come back in new code. Do not confuse the levels, though: a CWE describes a type of weakness, not the fact of exploitation. A CWE-79 label says which class a finding belongs to; the evidence that the vulnerability is actually exploitable in your system is the tester's reproduction.

CISA's Secure by Design programme points the same way. Its alerts urge manufacturers to eliminate entire vulnerability classes — cross-site scripting, OS command injection, directory traversal — rather than patch individual instances. For a pentest this means grouping applicable findings by weakness class and tracing the root cause across the affected paths. If a tester finds command injection in one handler, review the shared process-invocation paths and use a safe invocation design where the same cause exists; do not assume one finding proves the condition exists across the whole service.

The HTTP layer: sessions, cookies and browser policies

A large part of web testing happens at the HTTP layer. The protocol itself does not keep state between requests: from HTTP's point of view, each request is self-contained. That does not mean servers cannot have sessions. The common pattern is for the server to store session data itself and give the client an identifier via the Set-Cookie header, which the browser returns in later requests. The alternative is self-contained signed tokens in which the client carries the state. Both designs are legitimate, and each has its failure points: predictable or unrevocable identifiers, missing Secure, HttpOnly and SameSite attributes, a session that survives logout or a password change, a token the server does not validate properly. That is why session creation, storage, termination and revocation are a central testing area, alongside the authentication mechanisms that guard protected resources.

Several browser protections are configured through response headers. Content Security Policy defines which resources a page may load and helps mitigate cross-site scripting and data injection. CORS tells the browser whether script from another origin may read a response; reflecting an attacker-controlled Origin while allowing usable credentials can expose that response in the victim's browser, but CORS does not replace server-side authorization. For certain cross-origin no-cors requests, CORP can make the browser block the response body from the requesting context; it does not necessarily prevent the request from being sent. Permissions Policy restricts page code's access to browser features and APIs.

Teams can perform a preliminary header check before a paid test, for instance with HTTP Observatory; the effort and coverage depend on the estate and configuration. Fixing obvious header problems can leave more assessment time for areas automated tools handle less reliably, such as authorization logic, tenant isolation and business-process abuse. The method for those checks is covered in detail in our article on business logic security testing.

Scanner, black box, grey box or white box

NIST SP 800-115 treats vulnerability scanning and penetration testing as different techniques with their own strengths and limitations. Scanning is broad and repeatable, which suits regular monitoring. A manual pentest can find what scanners see poorly: authorization failures between roles, broken tenant isolation, abuse of the sequence of steps in a business process. A mature programme uses both. A common procurement mistake is to receive scanner output dressed up as a pentest: the document looks like evidence, but the risky paths remain untested.

A fixed budget can force a choice between depth and breadth. If the scope cannot be tested exhaustively, prioritize paths that touch customer data, authentication and sessions, administrative functions and the boundaries between tenants. A shallow pass over many low-value assets is a weaker use of the same days. Write the priorities into the scope document so the auditor sees a deliberate risk-based decision rather than an omission.

Timing should be agreed with the auditor and with the release calendar. A test right after a significant architectural change, with time left for fixes and a retest before the auditor reviews evidence, is more useful than a test at a random point in the period. If the system changes quickly, it makes sense to complement planned engagements with targeted tests of changes; that approach is described in our article on change-triggered penetration testing.

From finding to evidence: report, remediation and retest

In NIST SP 800-115, analysis of findings and remediation recommendations belong to the post-execution phase rather than being an optional appendix. For SOC 2, the report should let someone who was not involved understand what was tested, when, from which positions, against which method and with what result. Each finding carries a severity, the affected component, a CWE classification where applicable, a reference to a versioned ASVS requirement where appropriate, business impact and recommendations. Proof should be reproducible and proportionate to the finding. It may include a protected proof of concept when needed for verification, while avoiding secrets, unnecessary personal data and unsafe distribution. In logs and screenshots, tokens, passwords and keys should be masked, personal data minimized, and the report itself kept under restricted access with a defined retention period.

Then comes the practical cycle that NIST does not formally spell out but without which a report is worth little to an auditor: fix, re-verify and record residual risk.

1. Boundary and authorizationScope from the system description, written authorization from empowered owners, test roles and tenants
2. Testing from several positionsExternal user, each role, cross-tenant access; findings are reproduced and classified
3. Ticket and fixEach finding is linked to a ticket, an owner and a change that removes the root cause, not one instance
4. Retest in agreed environmentVerify the original scenario and reasonable variants; conclusions are bounded to the environment and variants tested
5. Residual riskOpen findings are accepted in writing: owner, rationale, review date

Build the retest into the engagement from the start. Both the auditor and the enterprise customer will ask whether serious problems are closed and whether the fix was confirmed. A retest's conclusion is valid only within the limits in which it was performed: if re-verification ran in staging against the original scenario, it does not prove production is protected against every variant of the attack. More on how to structure such verification and what counts as evidence of closure is in our piece on penetration test remediation validation.

Root-cause analysis is what makes a pentest useful beyond the audit. If findings reach the development team with CWE labels, after a few cycles it becomes visible which defect classes the system has learned to eliminate, which keep returning, and where changes in architecture, libraries or code review are needed.

How to choose a SOC 2 penetration testing vendor

CISA has published Secure by Demand guidance for software customers: it teaches buyers to ask suppliers concrete, verifiable questions rather than trust marketing. The same approach works when choosing a pentest provider. A sample report with a handsome cover says little; what matters is how the vendor answers questions about method, authorization and retesting.

Ask which methodology and which version of it they follow and how that is reflected in the test plan. Check whether findings will be mapped to CWE and, where appropriate, to versioned ASVS requirements. Ask them to describe how they obtain and document written authorization for each system and what they do when part of the infrastructure belongs to a third party. Find out which positions the test will cover: unauthenticated, per role, cross-tenant. Confirm whether a retest is included and how closure is documented. Request an anonymized sample report and ask how the vendor handles sensitive data found during the work, who has access to it and when it is deleted. A broader framework for comparing providers is in our article on penetration testing vendor comparison.

Potential red flags include no formal written-authorization process; a methodology that is not named or named without a version; no applicable CWE or requirement mapping and no explanation of non-applicability; no retest; or a sample report that is obviously raw scanner output. And the most obvious one: a promise to "guarantee you pass SOC 2". The opinion is the auditor's, and no tester can promise its outcome.

If you are a software manufacturer, a pentest is a convenient moment to check your product against the secure-by-default ideas CISA promotes: multi-factor authentication, logging and single sign-on should be available to customers without extra charge. Include in scope whether MFA is enforced for people and resists bypass, whether logs are complete and protected, and whether SSO is configured correctly. Service and workload credentials — API keys, integration tokens, service accounts — are tested separately: MFA does not apply to them, and the questions there are different — scope of permissions, rotation, storage and revocation.

Once the system boundary and the auditor's questions are clear, you can bring them to a conversation about penetration testing with Pentest.red: which assets and roles to include, which positions to choose, how to structure the retest. SOC 2 itself — the examination and the report — is performed only by an independent audit firm; a pentest gives that firm material but does not replace its work.

Pentesting as part of a risk management cycle

The NIST Cybersecurity Framework 2.0 helps organizations understand and improve how they manage cybersecurity risk; it offers profiles, quick-start guides and informative references showing how NIST resources relate. Placed in that frame, a pentest stops being an annual purchase and becomes one input to a continuous cycle: findings are related to target outcomes in the organization's profile, and the next test is planned around how the system has changed.

In practice the sequence of decisions looks like this. First, confirm with the auditor whether and how pentest results will be used, and by when. Then define scope from the system description: assets, environments, roles, tenants, exclusions. Before the paid test, handle basic hygiene — headers, CSP, CORS, obvious misconfigurations. Choose the testing positions and record the rationale. Select the vendor on a named, versioned method, CWE and ASVS mapping, retesting and authorization discipline. Run the work under written rules of engagement. Fix by root cause, re-verify, document residual risk and feed CWE trends back to development. Finally, relate the results to the CSF profile and plan the next cycle.

This sequence is the author's practical recommendation, not a SOC 2 or NIST requirement. Its purpose is that you come to vendor conversations knowing what you need, why, and how you will judge the result.

Conclusion: a repeatable evidence cycle

A SOC 2 pentest is useful when it meets the engagement's agreed objectives and produces evidence the auditor can trace from scope to method and from finding to disposition. Depending on the objective, that may combine discovery of real weaknesses with verification of selected controls or requirements. Everything needed is available: the phase structure of NIST SP 800-115, the working method of the OWASP WSTG, versioned ASVS requirements, CWE classification for trend analysis, an understanding of HTTP mechanisms, and procurement discipline in the spirit of CISA.

What none of these documents contains is SOC 2's rules for your organization. Those are set by your system description, your risk assessment, your customer commitments and your auditor. Start with that conversation, then choose a pentest on methodological transparency, standards mapping, retesting and authorization discipline — never on a promise of a clean report. Then the test stops being an annual compliance purchase and becomes a cycle of scoping, testing, fixing and learning that keeps the product safer between audits too.