SOC 2 Penetration Testing Evidence Checklist: What to Hand Your Auditor

A penetration test only helps your SOC 2 examination if it turns into evidence the auditor can use. That sounds obvious, and yet the most common way a test gets wasted is a good report filed in a folder nobody attaches to a control, dated outside the observation window, with findings that were fixed but never re-verified.

This checklist lists every item an auditor is likely to ask for, in the order you will need it, with the Trust Services Criteria each one evidences. Use it to brief your testing firm before the engagement and to build the evidence package afterward. Our SOC 2 penetration testing services are structured around it.

Before the test: scope and timing evidence

Settle these before the engagement starts:

• Scope statement that matches your system description. The systems tested should be the systems inside your SOC 2 boundary: the product, its APIs, the cloud infrastructure that hosts it, and any corporate systems in scope. An auditor compares the two documents, and a mismatch is the first question you will get.
• Timing that lands inside the audit window. For a Type I, the test and remediation complete before the as-of date. For a Type II, the test lands inside the observation period, early enough that remediation and retest also fall inside it. Our guide to SOC 2 penetration testing requirements covers the timing traps in detail.
• Independence statement. Confirmation that the testers did not build or operate the systems under test. An external firm satisfies this by default.
• Tester qualifications. Certifications (OSCP, OSCE3, OSWE, or equivalent) and experience, stated in the proposal or the report.
• Methodology reference. The standard the test follows (PTES, the OWASP Web Security Testing Guide, the OWASP API Security Top 10), so the auditor can see the test was structured rather than ad hoc.
• Rules of engagement and authorization. The signed agreement showing the test was authorized, which some auditors request as evidence of change-management discipline.

The report itself

The report should contain:

• Executive summary written for a non-engineer. Overall risk posture, count of findings by severity, and the remediation status. This is the page the auditor reads first and the page an enterprise customer reads second.
• Scope and coverage section. What was tested, what was excluded and why, the dates, and the roles and credentials used. Coverage evidence (for example, the endpoints tested against an API) belongs here.
• Findings with severity, evidence, and reproduction steps. Each finding rated (CVSS or an equivalent scale), with the affected asset, the evidence that it is real, and the steps to reproduce it. Auditors do not verify the exploit, but they do check that severity ratings are consistent and defensible.
• Control mapping. Each finding tied to the criterion it affects (see the table below). This is the item most reports lack and the one that saves the most audit time.
• Remediation guidance. Specific enough that engineering could act on it, which demonstrates the finding was actionable and not theoretical.
• A retest section or a separate retest report. Showing each remediated finding verified closed, with the date. Without this the auditor sees open findings, not a working vulnerability management process.

After the test: remediation evidence

After delivery, the auditor will ask for:

• Tickets or change records for each finding. The link between a finding and the work that fixed it, with dates, is the operating-effectiveness evidence a Type II examines.
• Retest confirmation. The tester’s verification that each fix works, with the report updated to show the finding closed.
• Risk acceptance for anything not fixed. A documented decision, signed by an appropriate owner, with a compensating control and a review date. Open findings without a decision are a control exception; open findings with a decision are a managed risk.
• Attestation letter. A one-page letter from the testing firm confirming that testing occurred, its scope, dates, methodology, and outcome, without technical detail. Auditors accept it as summary evidence and enterprise customers accept it in place of the full report.
• Cadence policy. A policy or procedure stating how often penetration testing is performed (annually and after significant change is the common standard) and who is responsible. The test is then evidence that the policy operates.

Uploading into Vanta, Drata, or Secureframe

Compliance platforms map evidence to controls automatically only if the evidence is attached to the right control. Attach the full report to the penetration testing control, attach the retest and tickets to the vulnerability remediation control, and attach the attestation letter to the customer-facing trust center if the platform offers one. Name files with the date and scope (“2026-09 Web app and API penetration test, retest included”) so the auditor can identify them without opening each one. Our reports are formatted so they upload without reformatting, which is a question worth asking any firm before you sign.

Control mapping: which criteria the evidence supports

Criterion	What it covers	Which evidence item supports it
CC4.1	Ongoing and separate evaluations to determine whether controls are present and functioning	The engagement itself: scope, methodology, report, and cadence policy
CC6.1	Logical access security over protected information assets	Authentication and authorization findings and their remediation
CC6.6	Security measures against threats from outside the system boundary	External and application-layer testing results
CC6.7	Restriction of data transmission and movement to authorized users	Transport security and data exposure findings
CC6.8	Prevention and detection of unauthorized or malicious software	Findings related to code execution and upload handling, and their fixes
CC7.1	Detection and monitoring of new vulnerabilities	The findings list, the remediation tickets, and the retest
CC7.2	Monitoring of system components for anomalies	Whether the test’s activity was detected, if the report includes a detection note
A1.2	Environmental protections, backup, and recovery infrastructure	Resilience findings, where Availability is in your report’s scope

The questions auditors actually ask

“When was the last penetration test, and was it within the period?” Answer with the report date and the retest date; both should fall inside the window for a Type II.

“Who performed it, and were they independent?” Answer with the firm, the tester qualifications, and the independence statement.

“What was found, and what did you do about it?” Answer with the findings summary, the tickets, the retest, and the risk acceptances.

“Does the scope match your system description?” Answer with the scope statement, side by side with the boundary in your description.

“Is there a policy that requires this?” Answer with the cadence policy and the prior year’s report, which together show a repeating process rather than a one-time event.

If all five answers are documents you can produce in a minute, the penetration testing portion of the examination is done.

Common gaps, and the fix for each

Gap	Fix
Report dated before the observation window	Schedule the test inside the window, one to three months before it closes
Findings fixed but never retested	Every Invadel engagement includes a free retest; use it and file the result
No mapping to criteria	Ask for control mapping up front; we include it in every SOC 2 report
Scope covers the corporate network but not the product	Scope to the system description: product, APIs, and hosting environment first
Open criticals with no decision	Fix them, or document a risk acceptance with a compensating control and owner
Scanner export presented as a penetration test	Commission a manual test; auditors and enterprise customers can tell the difference

Frequently asked questions

Can we use last year’s test? For a Type I with an unchanged system, some auditors accept a test up to twelve months old. For a Type II, evidence inside the observation period is expected. Annual testing keeps the question from arising.

Do we need a separate test for each product? Scope to the system description. Multiple products inside one boundary can be tested in one engagement; separate SOC 2 reports usually mean separate scopes.

Is a vulnerability scan enough? Auditors increasingly distinguish the two. A scan evidences CC7.1’s monitoring; a penetration test evidences CC4.1’s evaluation of whether controls work. Our guide to penetration testing vs vulnerability scanning covers the difference.

What does a SOC 2 penetration test cost? Scoped to the systems in the audit boundary, usually a web application test from $5,200 and an external test from $4,200, fixed before work begins, with the retest and the attestation letter included. Starting prices for every service are on our pricing page.

Audit window open and the evidence not yet in the folder? Scope a SOC 2 penetration test and tell us your audit dates; we will time the test, the retest, and the attestation letter to land inside the period.