Introduction
Penetration test evidence for SOC 2 is the dated proof that your organization scoped an authorized simulated attack against in-scope systems, retained the report and executive summary, tracked findings to owners and due dates, verified significant fixes with a retest, and can show that work across the audit period.
Many teams treat the annual pen test as a PDF to file. The audit and diligence gap is rarely "we never tested." It is that nobody can show what was in scope, whether critical findings were owned and closed, whether a retest confirmed the fixes, or how the engagement relates to the recurring vulnerability management program that runs the rest of the year.
Here is a concrete example. An auditor asks for your most recent pen test and the status of high findings. Strong evidence includes the statement of work and rules of engagement, the full report with dates and methodology, a finding tracker with owners and closure notes, a retest letter confirming critical and high issues were fixed, and exception records for anything still open with an end date. Weak evidence is an executive summary alone, or a report dated outside the period with no remediation trail.
In plain language: this guide is an evidence playbook for scoping, reports, remediation, and retest. It is not a second definition of a penetration test. That glossary page explains what a pen test is. This page explains what to keep so you can prove the engagement and the follow-through. For the recurring scan and SLA playbook, see Vulnerability Management Evidence for SOC 2.
What Penetration Test Evidence Means
Penetration test evidence proves that an authorized, scoped assessment was planned and executed, that findings were communicated with enough detail to fix them, and that remediation and retest closed (or formally accepted) the issues that mattered.
A complete pen test evidence file usually answers:
- What systems, apps, APIs, and environments were in scope, and what was explicitly out of scope?
- Who authorized the test, under what rules of engagement, and in which window?
- Who performed the test, and when did fieldwork start and end?
- What methodology and severity scale appear in the report?
- Which findings were accepted into the remediation queue, with owners and due dates?
- Which significant findings were retested, and what was the result?
- Which residual findings remain open under an approved exception with an end date?
- What do you share with customers (letter or sanitized summary) versus what stays access-controlled?
How This Guide Differs From Related Pages
| Page | Primary job | Use it when |
|---|---|---|
| What Is a Penetration Test? | Defines pen testing and contrasts it with scans and red teams | You need the concept and vocabulary |
| What Is Vulnerability Management? | Defines the ongoing find-fix-verify program | You need the continuous program definition |
| Vulnerability Management Evidence for SOC 2 | Scan cadence, severity SLAs, and Type 2 sampling for the scan program | You are proving recurring scanning, not a scoped offensive engagement |
| What Is Remediation? | Defines the fix work and verification | You need the language of closing a known gap |
| Exception Management and Audit Findings Remediation | Operating model for exceptions and findings | You are governing deferred pen findings or auditor findings |
| What Is SOC 2? | Defines the attestation report family | You need the umbrella context for why evidence matters |
| This guide | Scope, report and retest artifacts, finding closure, and pen test vs scan evidence | You need the penetration test evidence playbook |
What SOC 2 Requires vs Common Practice
Keep the criteria and your chosen practices apart.
What the criteria address. The AICPA 2017 Trust Services Criteria with revised points of focus (2022) include themes that penetration testing commonly supports:
- CC7.1: detection and monitoring procedures to identify changes to configurations that introduce new vulnerabilities, and susceptibilities to newly discovered vulnerabilities. A related point of focus describes conducting vulnerability scans periodically and after significant changes, and remediating deficiencies on a timely basis. Penetration testing is a complementary assessment method many programs use alongside scanning, not a substitute for that recurring loop.
- CC4.1 and CC4.2: evaluating whether controls are present and functioning, and communicating deficiencies so they can be remediated. A scoped pen test is one way teams evaluate whether controls hold under simulated attack and then feed results into remediation.
- CC3.2 and risk themes: identifying risks that threaten objectives, which often drives which systems get deeper offensive testing.
Points of focus are illustrative, not a checklist. SOC 2 does not mandate an annual pen test, a specific firm, a black-box or white-box method, or a fixed severity scale. Your auditor tests the controls you describe. If your policy says you run an annual external pen test of production applications and remediate critical findings within a stated window, the evidence must show both for the sampled period.
What is common practice, not a fixed SOC 2 rule:
- An annual external penetration test of production web apps and APIs, plus infrastructure when risk warrants it
- A written statement of work, rules of engagement, and authorization before testing begins
- Finding severity aligned to your vulnerability SLAs so pen findings enter the same remediation queue as scan findings
- Retest of critical and high findings after remediation
- A customer-facing letter or sanitized summary, with the full report under NDA
For design input, NIST SP 800-115, Technical Guide to Information Security Testing and Assessment covers planning, execution, and post-test activities for security testing. NIST SP 800-53 Rev. 5 includes assessment themes such as CA-8 (Penetration Testing) as a control family reference, not as a SOC 2 mandate. Use them as reference points and map carefully to the controls you assert through control mapping.
The Penetration Test Evidence File at a Glance
| Area | What to keep | Stronger evidence | Weaker evidence |
|---|---|---|---|
| Scope | In-scope and out-of-scope assets | Dated SOW mapped to the system description | "We tested production" with no asset list |
| Authorization | Written approval and rules of engagement | Signed authorization, contacts, emergency stop, data handling | Verbal go-ahead in chat |
| Execution | Who tested, when, and how | Report with firm or tester identity, dates, methodology | Undated PDF with no methodology |
| Findings | Severity, impact, reproduction detail | Findings with IDs, severity, and engineer-usable detail | Executive summary only |
| Remediation | Owners, due dates, linked tickets | Tracker entries with change tickets and closure notes | Slack "we fixed it" |
| Retest | Confirmation of significant fixes | Retest letter or updated report section with dates | Claimed fix with no retest |
| Exceptions | Deferred residual risk | Approved exception with owner, rationale, end date | Open critical with no record |
| Customer share | What leaves the company | Letter or sanitized summary under controlled distribution | Full exploit detail in a shared drive |
Building the Evidence Step by Step
1. Align scope to the system description and risk
Start from your system description and risk assessment if you maintain one live. List the applications, APIs, cloud accounts, network segments, and environments that matter for SOC 2 readiness and customer diligence. Include staging only when it mirrors production auth or data paths that attackers could abuse. Explicitly list out-of-scope items (third-party SaaS you cannot authorize, denial-of-service tests, social engineering if disallowed) so the report does not get argued later.
Scope that never touches production-critical paths produces a clean report that fails diligence questions. Scope that is too wide without rules of engagement creates operational risk. Write the middle: the systems customers care about, under controls you can authorize.
2. Write rules of engagement and get authorization
Document testing windows, emergency contacts, stop conditions, data handling, whether credentialed testing is allowed, and whether social engineering or disruptive tests are in or out. Keep signed authorization from someone who can approve testing against those systems. Written authorization protects both sides and is part of the evidence packet, not only legal hygiene.
3. Choose the engagement type on purpose
Decide black-box, gray-box, or white-box (and network vs application focus) based on risk and what you already know from scanning. Gray-box or white-box tests with limited credentials often find authz and business-logic issues scanners miss. Do not relabel a vulnerability scan as a pen test in questionnaires. Keep the vocabulary aligned with What Is a Penetration Test?.
4. Retain the planning packet
Keep the statement of work, scope appendix, rules of engagement, authorization, tester or firm identity, and scheduled window. These artifacts answer "was this a real, authorized engagement?" before anyone opens the findings list.
5. Keep the full report and an executive summary
Retain the full report with dates, methodology notes, findings with severity, reproduction detail sufficient for engineers, and remediation recommendations. Keep an executive summary or briefing deck for leadership. Prefer a system of record (GRC vault, controlled share) over email-only copies. See audit evidence and evidence collection for retention habits.
6. Enter findings into one remediation queue
Move accepted findings into the same tracker you use for vulnerability work whenever possible: finding ID, severity, owner, due date, linked ticket, and status. Align severity timelines to your vulnerability SLAs so pen findings are not a parallel, unowned spreadsheet. Route production fixes through change management when impact warrants it.
7. Remediate with verification in mind
Remediation is the fix plus proof. Patch, config change, or code fix should leave a ticket, and significant issues should not close on "deployed" alone. For systemic or repeating issues, escalate into a corrective action plan or CAPA rather than closing one symptom at a time.
8. Retest significant findings
Schedule a retest (or retest section in an updated report) for critical and high findings after remediation. Keep the retest letter or updated finding status with dates. A retest that confirms the issue is gone is stronger than an engineer assertion. Informational findings may not need retest; write that rule down so sampling is consistent.
9. Govern what stays open
When a finding cannot meet the timeline, open a time-bounded exception with risk rationale, compensating control if any, owner, and end date. Run that through your exception management process. An approved, dated exception is evidence of control. An undocumented open critical is a finding waiting to happen. See Exception Management and Audit Findings Remediation.
10. Control how results are shared
Decide what customers and prospects receive: often a letter confirming dates, scope summary, and that critical and high issues were remediated or are tracked, not the full exploit narrative. Keep the full report access-controlled. Broad paste of exploit detail into Slack or a shared diligence folder creates unnecessary risk.
11. Connect results back to monitoring and incident readiness
Ask whether detections fired during the test, and whether monitoring gaps should become follow-up work. Significant exploitable paths may also inform incident management playbooks. Pen tests that never feed detection or response improvements leave half the value on the table. Related operating detail lives in Incident Response Evidence for SOC 2.
12. Keep the packet ready for Type 2 sampling
Export or vault the SOW, authorization, report, finding tracker export for the period, retest artifacts, and exceptions so you are not reconstructing history from email during fieldwork.
Penetration Test vs Vulnerability Scanning Evidence
Keep these evidence sets distinct so owners and auditors share meaning.
| Dimension | Penetration test evidence | Vulnerability scanning evidence |
|---|---|---|
| Rhythm | Planned engagement (often annual or after major releases) | Recurring cadence across the period |
| Depth | Human-led exploitation and chaining within scope | Broad automated discovery of known weaknesses |
| Primary artifacts | SOW, ROE, report, retest letter, finding tracker | Scan calendar, exports, SLA metrics, re-scan proof |
| Common failure | Clean PDF with no remediation or retest | One pre-audit scan PDF with gaps elsewhere in the period |
| Role in SOC 2 readiness | Point-in-time offensive assessment plus follow-through | Ongoing find-fix-verify loop |
You usually need both. Scans cover the months between engagements. Pen tests probe what scanners miss. Send pen findings into the same remediation queue described in Vulnerability Management Evidence for SOC 2, and do not claim a scan is a pen test on customer questionnaires.
Type 1 vs Type 2 Considerations
For a Type 1 report, auditors look at whether penetration testing and related remediation controls are suitably designed and in place at a point in time. A current policy or procedure, a recent SOW and report, the finding tracker design, and open exception examples usually support that.
For a Type 2 report, auditors test operation across the period. Expect requests such as:
- The pen test report (or reports) whose fieldwork dates fall in or reasonably support the period, per your stated cadence
- Remediation tickets and closure evidence for significant findings
- Retest artifacts for critical and high items claimed fixed during the period
- Exception approvals for deferred findings, with dates inside the period
- Proof that pen findings entered the vulnerability or findings queue rather than sitting only in a PDF
- Consistency between the written testing policy and actual engagement history
A report from three years ago with no remediation trail does not prove this period's operation. See SOC 2 Type 1 vs Type 2 and What Is SOC 2 Evidence?.
Evidence Examples by Scenario
| Scenario | Stronger evidence | Weaker evidence |
|---|---|---|
| Auditor asks for the latest pen test | SOW, ROE, full report with dates, executive summary | Undated summary slide |
| Critical finding claimed fixed | Ticket, change record, retest confirmation | Engineer chat message |
| High finding past SLA | Approved exception with end date and compensating control | Finding left open with no owner |
| Customer diligence request | Controlled letter or sanitized summary | Full report emailed broadly |
| New app launched mid-period | Risk-based decision to test, or documented deferral with compensating scans | No mention of the app anywhere |
| Scan vs pen test confusion | Distinct artifacts; pen findings in the shared remediation queue | Questionnaire claim that weekly scans are the pen test |
| Tester could not reach an in-scope host | Scope amendment note and follow-up plan | Silent omission from the report narrative |
Common Mistakes
- Calling a vulnerability scan a penetration test in questionnaires or the system description
- Scope so narrow that production-critical apps and APIs are never tested
- Filing the report with no owners, due dates, or tickets
- Closing critical findings without a retest
- Open findings past policy windows with no exception record
- Sharing full exploit detail outside a controlled channel
- Annual pen test theater with no link to change management, monitoring, or vulnerability SLAs
- A written testing policy that does not match engagement history (control drift)
- Treating a clean pen test as a substitute for continuous scanning and patching
When you find one of these, record it and track the fix through Exception Management and Audit Findings Remediation.
Operating Model: Make Pen Test Evidence Routine
- Name owners. Assign a control owner for the testing program and a technical owner for each in-scope application.
- Put cadence in the policy. State how often you pen test, what triggers an off-cycle test (major release, new internet-facing service), and how findings inherit vulnerability SLAs.
- Plan the engagement early. Leave time for scoping, authorization, testing, remediation, and retest before customer renewals or auditor fieldwork.
- Use one remediation queue. Pen findings, scan findings, and bug bounty items should not live in three disconnected trackers.
- Retest by default for critical and high. Make retest a gate in the procedure, not an optional courtesy from the firm.
- Dry-run the packet. Before fieldwork, pull SOW, report, tracker export, retest letter, and open exceptions. Fix gaps and record late items honestly.
Linking Penetration Testing to Neighboring Controls
- Vulnerability management. Pen findings feed the same find-fix-verify loop. See Vulnerability Management Evidence for SOC 2 and What Is Vulnerability Management?.
- Change management. Production fixes should leave change evidence.
- Exception management. Deferred findings need governed acceptance.
- Incident management. Exploitable paths may update playbooks and detection.
- Risk and system description. Scope should match what you say you operate and what risk assessment prioritizes.
- Continuous compliance. A pen test is episodic; dated remediation and scanning keep the months between tests from becoming a black box. See continuous compliance.
How AuditFlo.co Helps
AuditFlo.co helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as GitHub and Jira.
For penetration testing, that can mean dated history for finding tickets, remediation and retest tasks, exception approvals, and links to stored report artifacts your team retains, so you can show follow-through across the period without rebuilding the story from email. Your testing firm, ticketing system, and document vault remain the systems of record for the engagement and the report. AuditFlo.co does not perform penetration tests, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors or testing firms.
To see the workflow for your stack, request a demo.
Final Thoughts
Penetration test evidence is the proof behind an offensive assessment claim: clear scope and authorization, a dated report, owned remediation, retest of what mattered, and honest exceptions for what remains. SOC 2 does not dictate annual testing, a specific methodology, or a severity scale, so write the program you actually run, keep it distinct from vulnerability scanning, and retain history that survives Type 2 sampling. A pen test PDF without follow-through is a cost center. A pen test with scoped artifacts and closed findings is evidence.
If you are building the broader readiness path, start with What Is a Penetration Test?, Vulnerability Management Evidence for SOC 2, What Is Remediation?, Exception Management and Audit Findings Remediation, What Is SOC 2?, and how to prepare for a SOC 2 audit.
FAQ
Does SOC 2 require an annual penetration test?
SOC 2 does not contain a universal rule that every organization must pen test every year. The Trust Services Criteria address identifying and remediating vulnerabilities and evaluating whether controls function. Many organizations choose periodic penetration testing as a control activity and write that cadence into policy. If you write annual testing into your program, auditors will expect evidence that it happened and that findings were handled.
How is pen test evidence different from vulnerability management evidence?
Vulnerability management evidence proves the recurring scan-triage-fix-verify loop across the period. Penetration test evidence proves a scoped offensive engagement plus remediation and retest. You often need both. See Vulnerability Management Evidence for SOC 2.
What should we keep from the testing firm?
At minimum: statement of work or scope, rules of engagement and authorization, the full report with dates and methodology, an executive summary, and a retest letter or updated finding status for significant issues. Keep distribution of the full report controlled.
Do informational findings need remediation tickets?
Follow your written procedure. Many teams ticket medium and above, and track informational items only when they indicate a pattern or easy win. Whatever you write, apply it consistently so Type 2 sampling does not look arbitrary.
What if a critical finding cannot be fixed before the audit period ends?
Document an exception with owner, risk rationale, compensating controls, and an end date. Show interim progress. Hiding an unfinished critical is worse than a governed open item. See Exception Management and Audit Findings Remediation.
Can we share the full pen test report with every prospect?
Usually no. Prefer a letter or sanitized summary for broad diligence, and share the full report under NDA with a smaller audience when required. Full exploit detail is sensitive.
Does AuditFlo.co run penetration tests?
No. AuditFlo.co helps organize dated evidence such as tickets, reviews, and workflow history from systems you already use. Your testing firm performs the engagement, and AuditFlo.co does not replace your auditor or your pen test provider.