Penetration Testing

May 25, 2026

SOC 2 Penetration Testing: Exactly What Auditors Want to See in Your Report

Sarah Chen

Senior Security Researcher

SOC 2 does not mandate penetration testing in its criteria, but auditors routinely request it as evidence of CC6.1 and CC7.1 controls, and a weak or scanner-only report can trigger findings that delay your certification. Here is what a SOC 2-ready pen test report actually contains, how auditors evaluate it, and what separates a report that passes review from one that raises questions.

What SOC 2 Auditors Are Actually Looking For in a Pen Test

Auditors reviewing penetration testing evidence are not assessing whether you ran a test. They are assessing whether your test is credible evidence of a functioning security control. That distinction matters.

A SOC 2 audit under the Trust Services Criteria evaluates whether your controls are designed and operating effectively. When an auditor asks for penetration testing documentation, they are checking three things:

Scope coverage matches the systems that handle in-scope data
Methodology demonstrates manual, skilled testing rather than automated scan output relabeled as a pen test
Remediation evidence shows that identified findings were addressed and verified

A report that lists CVEs with CVSS scores and no exploitation narrative tells an auditor that you ran Nessus or Qualys and printed the output. That is a vulnerability assessment, not a penetration test, and auditors who have reviewed a few dozen reports know the difference immediately.

The SOC 2 Trust Services Criteria That Pen Testing Supports

Penetration testing maps most directly to these criteria:

CC6.1 requires that the entity implements logical access security controls. A pen test that attempts to bypass those controls and documents the outcome is direct operational evidence.

CC6.6 covers logical access from outside the system boundary, making external network and application testing directly relevant.

CC7.1 requires detection and monitoring controls. A test that includes findings on logging gaps or alert bypasses speaks to this criterion explicitly.

CC7.2 covers incident response to security events. If your test simulates an attack and your SOC does not detect it, that is a CC7.2 observation an auditor may raise.

When scoping a SOC 2 penetration test, map every target to the criteria it validates. An auditor reviewing your report should be able to trace the test coverage to specific TSC line items without you having to explain it to them.

How to Scope a SOC 2 Penetration Test Correctly

Scope failures are the most common reason a pen test report does not satisfy an auditor. The test needs to cover the systems that are in scope for your SOC 2 audit. That sounds obvious, but the practical errors are frequent.

What must be in scope:

The application or platform that processes, stores, or transmits customer data
The APIs that feed or expose that data, including internal service-to-service APIs
The infrastructure layer: cloud environment (AWS, GCP, Azure), container orchestration, and network segmentation controls
Authentication and authorization mechanisms, including SSO integrations, MFA enforcement, and session management
Administrative interfaces and privileged access paths

What is commonly missed:

Staging and development environments that share credentials or access paths with production
Third-party integrations where data leaves your boundary
CI/CD pipelines that could allow code injection into production
Backup and recovery infrastructure that holds copies of production data

If your audit boundary includes subprocessors, your pen test does not need to cover their infrastructure, but your report should document what you tested and explicitly acknowledge what was excluded and why.

What a Credible SOC 2 Penetration Test Report Contains

This is the section most founders and CTOs need before their first audit. The structure below reflects what experienced SOC 2 auditors expect to see when they open your report.

Executive Summary With an Opinion, Not Just a Score

The executive summary should state, in plain language, whether your security posture presents material risk to the confidentiality, integrity, or availability of customer data. An auditor reading a summary that says "several findings were identified across the assessment" learns nothing. A summary that says "no critical vulnerabilities were exploitable from an unauthenticated external position; one high-severity IDOR vulnerability was confirmed in the authenticated API layer with a demonstrated impact of cross-account data access" is useful.

Scope and Rules of Engagement Documentation

This section must specify:

Test dates (start and end)
Testing methodology (black box, grey box, white box)
IP ranges, domains, and application URLs in scope
What was explicitly excluded
Whether the test was conducted from external network positions, an authenticated user session, or both
Any restrictions imposed (no denial-of-service, production environment constraints)

Auditors verify scope documentation against your system description. If your SOC 2 system description lists five application modules and your pen test scoped three, expect a question.

Methodology Section With Actual Technique Disclosure

This is where scanner-only firms get caught. A credible methodology section describes the manual techniques your testers used, not just the tool names. For an application test, it should reference testing categories drawn from standards like OWASP WSTG, with a narrative of what was actually exercised.

Example of what this looks like in a credible report:

Authentication Testing: - Tested for credential stuffing resistance via rate limiting on /api/v1/auth/login
- Confirmed MFA bypass was not achievable via response manipulation on the
/api/v1/auth/verify endpoint - Attempted session fixation via pre-authentication session token reuse
- Confirmed JWT signature validation was enforced; tested algorithm confusion
(RS256 to HS256 substitution) — not exploitable

Authorization Testing:
- Mapped all API endpoints from authenticated session using passive proxy capture
- Tested IDOR conditions on 34 object-referencing endpoints by substituting
user UUIDs across two provisioned test accounts - Confirmed one exploitable IDOR on GET /api/v1/reports/{report_id} allowing
cross-account report retrieval without authorization check

That level of specificity is what distinguishes a manual test from scan output. An auditor reading the methodology section should understand what your tester actually did, not just that "web application testing" occurred.

Finding Documentation With Exploitation Evidence

Each finding in the report should contain:

Title and classification (OWASP or CWE reference)
Severity rating with a defined scoring basis (CVSS v3.1 is standard; document your environmental modifiers)
Affected component with the specific endpoint, parameter, or system element
Description of the vulnerability and why it exists
Exploitation narrative explaining how an attacker would chain or exploit it
Evidence: request/response pairs, screenshots, or output demonstrating the finding is confirmed, not theoretical
Business impact specific to your application (not generic CVSS language)
Remediation guidance that is specific enough for a developer to act on

A finding that says "SQL injection was identified in the application" without a proof-of-concept request, a confirmed payload, and a specific affected parameter is not useful to your development team and is not credible evidence for an auditor.

Here is the difference:

Weak finding documentation:

Finding: SQL Injection
Severity: High
Description: The application may be vulnerable to SQL injection attacks,
which could allow an attacker to access the database.
Recommendation: Use parameterized queries.

Credible finding documentation:

Finding: SQL Injection — Authenticated Search Endpoint
Severity: High (CVSS 3.1: 8.8 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Affected Component: POST /api/v1/search — parameter: query
Confirmed Payload: ' OR 1=1-- -
Evidence: Response returned 2,847 rows from the customers table,
including records belonging to other tenant accounts. Business Impact: Authenticated users can extract cross-tenant customer
records, directly violating the confidentiality commitments in your
SOC 2 system description.
Remediation: Replace string concatenation in SearchController.php:84
with PDO prepared statements. Validate and sanitize the query parameter
server-side prior to database interaction.

Remediation Verification (Retest Results)

Auditors assess whether controls are operating effectively over the audit period. A penetration test that identifies ten findings and then closes the loop with a retest demonstrating that nine were resolved and one was accepted with compensating controls tells a coherent story.

A test report with no retest component tells the auditor that you found problems and then stopped. The auditor will ask your management what happened to those findings. If you cannot demonstrate resolution, that becomes an observation.

The retest section should document each original finding, the remediation the engineering team implemented, and the outcome of retesting: resolved, partially resolved (with remaining risk explained), or risk-accepted with a compensating control documented.

Timing a SOC 2 Penetration Test Within Your Audit Cycle

For a Type II audit covering a twelve-month period, your penetration test should occur during the audit window, not before it starts. A test completed six months before your audit period opened is generally not accepted as evidence of controls operating during the period under review.

A practical approach for most SaaS companies on an annual SOC 2 cycle:

Conduct the penetration test approximately two to three months before your audit period closes
Complete remediation and retest within four to six weeks of the original test
Provide the final report, including retest results, to your auditor as a deliverable

If you are pursuing SOC 2 Type I, the test needs to occur before or at the point-in-time date your auditor is evaluating. The same scope and quality standards apply.

What Separates a SOC 2-Ready Pen Test from a Generic Assessment

Attribute	Generic pen test	SOC 2-ready pen test
Scope documentation	Target list	Target list mapped to TSC criteria
Methodology	Tool names listed	Techniques described per test category
Finding evidence	Scanner output or screenshots	Confirmed exploitation with PoC artifacts
Business impact	Generic severity language	Impact tied to confidentiality/integrity commitments
Remediation	Recommendations only	Retest results confirming resolution
Report audience	Security team	Security team and external auditor

If a firm quotes you a penetration test and cannot show you a sample report that meets the right-hand column of that table, the report you receive will not satisfy a thorough auditor.

What Audit Firms and MSPs Should Expect From a White-Label Testing Partner

If you are an audit firm or MSP recommending penetration testing to your SOC 2 clients, the quality of the testing partner's report reflects directly on your advisory relationship. A report that triggers auditor questions creates work for you and erodes client confidence.

A credible white-label partner should provide:

Reports structured specifically for auditor consumption, not internal security teams only
Willingness to answer auditor questions about methodology directly, if needed
Retesting included as standard, not an add-on
Testing performed by certified testers (OSCP at minimum) who conducted the test, not a project manager narrating scanner output

IVASTA Security offers white-label penetration testing partnerships for audit firms and MSPs who need a trusted testing partner. Engagements are delivered under your firm's brand with report formatting matched to your documentation standards.

FAQ

SOC 2 does not list penetration testing as a mandatory control in the Trust Services Criteria. Auditors cannot require it. However, penetration testing is the most direct evidence available to demonstrate that CC6.1 and CC7.1 controls are operating effectively, and many auditors request it as part of their evidence review. Companies that do not have penetration testing documentation often face additional auditor inquiries about how they validate the effectiveness of their access controls.

Annual testing aligned to your audit cycle is the standard expectation for SOC 2 Type II. If your application undergoes significant architectural changes, such as a new API layer, a cloud migration, or a new authentication system, a targeted test scoped to those changes is warranted outside the annual cycle. Auditors may ask whether testing frequency reflects changes to your environment, so document your rationale when you decide not to test following a major change.

A vulnerability assessment identifies and ranks security weaknesses, typically using automated scanning tools, without attempting to exploit them. A penetration test includes manual exploitation to confirm whether a vulnerability is actually exploitable and what an attacker could achieve if they used it. For SOC 2 purposes, a vulnerability assessment demonstrates that you monitor for weaknesses. A penetration test demonstrates that you have validated your defenses against skilled adversarial activity. Auditors treat them as different categories of evidence, and a vulnerability assessment alone will not satisfy an auditor who is looking for penetration testing documentation.

There is no single mandated methodology. Auditors look for evidence that the methodology is systematic and credible. In practice, web application testing should reference OWASP WSTG or a comparable framework. Network and infrastructure testing should reference a recognized methodology such as PTES or NIST SP 800-115. The report should document which test categories were exercised and which were excluded, with a reason. A methodology section that says "industry-standard testing methodologies were used" without specifics will prompt auditor questions.

One test can generate evidence that is useful across multiple frameworks, but the report framing matters. A SOC 2-structured report maps findings to Trust Services Criteria. An ISO 27001 context requires mapping to Annex A controls. If you are using the same report for both, confirm with your auditors that the scope and methodology satisfy each framework's requirements independently. Most penetration testing firms can produce supplementary mapping documentation from a single engagement if requested during scoping.

IVASTA Security performs manual penetration testing for SaaS, fintech, and healthcare companies preparing for SOC 2 audits. If you want to see a sample report before scoping an

engagement, or if you are an audit firm looking for a white-label testing partner, request a scoping call and a senior tester will respond within one business day.