SOC 2 Penetration Testing: The Report Your Auditor Checks
SOC 2 penetration testing is not a requirement written into the AICPA's Trust Services Criteria, but it is the standard evidence auditors expect for monitoring activities under criterion CC4.1. The test should cover the systems in your audit scope, be run by a firm independent of your vendors, and produce a report with remediation and retest results inside the reporting period, because that is what turns a control claim into evidence.
A SaaS company walks into its first SOC 2 Type II audit with every policy written, every questionnaire answered, and one question nobody in the room has answered: what technical evidence proves the controls actually work? The auditor's answer is usually the same: show me your penetration test. If the test does not exist, or it tested a different environment than the one being audited, the audit schedule gets longer and the opinion gets harder.
This is not a new expectation, but the context around it changed this spring. In May 2026, the AICPA's Peer Review Board issued guidance telling peer reviewers to treat SOC 2 engagements as nonconforming when engagements at one firm show identical risk assessments, sample sizes, and testing procedures across different clients, and beginning June 1, 2026, the AICPA's peer review staff started a structured monitoring process for firms with SOC 2 practices [3]. The AICPA has said SOC 2 is now used to examine the controls of more than 1,600 organizations across 16,500 tests and 24,000 test procedures [3]. In that environment, the audit report is a document that can look templated. The pen test report is the one piece of evidence that cannot be templated, and in our engagements it is the first file an auditor asks to see before the walkthrough begins.
Clone Systems' position: a SOC 2 penetration test is not a required checkbox. It is the most client-specific evidence in the file, and scoping it correctly is the client's job, not the auditor's. Clients arrive at the scoping conversation assuming the auditor will tell them what to test. The auditor inherits your scope.
Is Penetration Testing Required for SOC 2?
No. The AICPA's 2017 Trust Services Criteria (with revised points of focus in 2022) do not contain a criterion that says a service organization must commission a penetration test [1]. But the criteria do put the obligation on the organization being audited to select, develop, and perform ongoing and separate evaluations of its controls, and the CC4.1 point of focus names penetration testing as one of the acceptable forms of separate evaluation [1][5]. Auditors test whether that evaluation happened. A clean opinion with no independent test evidence behind CC4.1 is an opinion the auditor has to work harder to support, which is why the absence of a test shows up in practice as extra procedures, not as a formal requirement.
SOC 2 is also not a certification. It is an examination-level attestation engagement performed by a CPA under AICPA attestation standards, and the AICPA has been explicit that a flat-fee, quick-turn "SOC 2 certification" is a misdescription of what the engagement is [2]. If a vendor is selling you a badge, ask what the report actually evidences.
The practical answer splits by report type:
- SOC 2 Type I covers control design at a point in time. A recent penetration test is not strictly required, but it is the fastest way to evidence that the design works.
- SOC 2 Type II covers operating effectiveness over a period, typically three to twelve months. Test evidence dated inside that period is what the auditor will look for, and a test that predates the period has to be explained.
What Does the Auditor Actually Look at in the Test Report?
The auditor is not grading your test. The auditor is asking whether the evidence matches the scope of the audit, which is why the five items below matter more than the number of findings in the report. This is the Clone Systems 5-Point SOC 2 Test Evidence Check, and we run it on every SOC 2 engagement before the report goes to an auditor:
- Scope match. The tested environments are the same systems named in the audit scope document. A test of the production web app does not evidence a control that covers the internal network, and the reverse is also true.
- Tester independence. The testing firm is independent of the vendors and managed service providers who built and operate the in-scope systems. A test run by your cloud host or your SOC provider is evidence about their work, not about your control environment, and the AICPA's own ethics guidance flags business arrangements that compromise the objectivity of assurance work [2].
- Timing. The test report and any remediation or retest results fall inside the reporting period. For a Type II with a 12-month window, a test done the month before fieldwork is late. The audit clock is not the project clock.
- Remediation and retest trail. The report shows what was found, what was fixed, and that the fix was verified. Auditors read the retest the way they read any control sample: as proof the control operated, not just that it existed.
- An executive summary an auditor can cite. The report's summary maps findings to the criteria they evidence and states what was and was not in scope, so the auditor does not have to reconstruct the connection from the findings table.
Clients are often surprised to learn that a report with zero findings is less useful to the auditor than a report with a few findings and a clean retest. Zero findings raises the question of what was actually tested, while a fixed-and-retested finding demonstrates the monitoring cycle working end to end.
What Scope Should a SOC 2 Penetration Test Cover?
Scope is driven by what the auditor needs evidence for, not by a fixed list. In practice, a SOC 2 test that satisfies CC4.1 evidence covers the systems inside the audit scope plus the paths an external actor can use to reach them: the public-facing web application or API, the external network, and the internal network segments that hold the in-scope data. Where Availability, Confidentiality, or Processing Integrity criteria are in scope, the test typically extends to the controls behind those criteria, such as failover paths and data segregation.
The most common scoping mistake we see is the same one every year: the tested environment is a subset of the audited system. The test covers the production web app, while the audit scope also names the internal network, the data backup system, and a third-party-hosted database. The auditor then has a gap between the evidence and the criteria, and the client has to explain it in writing. The fix is cheap: reconcile the test scope line by line against the system description in the audit scope document before the test is written, and again before the report is delivered.
A scan is not a substitute for this scope decision, because a scan reports what the scanner can see from its vantage points, and it does not validate exploitability. We broke down what each method actually proves in penetration testing vs vulnerability scanning. If you are already running a continuous or automated testing program, the question becomes how that program produces dated, in-scope evidence the auditor can rely on, which is covered in can automated penetration testing replace your manual penetration test.
How Often Should You Test for SOC 2?
Once per audit period, minimum, with the test dated inside the period. For a Type II report on a 12-month window, that means at least one penetration test with its remediation and retest results completed within the window, and many clients schedule the test two to three months before fieldwork so retest time does not collide with it. A second driver is change: any significant new system, acquisition, or architecture change inside the reporting period is a new scope decision, and the test evidence should follow it.
The cadence question is really a remediation question. Cobalt's State of Pentesting 2026, based on data from 16,500 penetration tests, found that the median time to remediate 50% of high-risk findings is 10 days for top-performing teams and 249 days for the bottom tier, roughly a 25x difference, and that programmatic testing teams resolve 4.5x more critical findings in three days or less than compliance-driven teams (45% versus 10%) [4]. The implication for SOC 2 is direct: if your organization's remediation half-life is measured in months, a test scheduled late in the reporting period will produce findings that are still open at fieldwork, and open findings are what auditors spend time on.
If your test finds the same weaknesses year after year, the problem is not the test. We covered the structural causes in why passing a penetration test retest isn't the same as fixing the root cause, and the same root-cause logic is what the 2026 AICPA guidance is aimed at at the audit-firm level [3].
How Clone Systems Can Help
We run SOC 2 penetration tests from the tester side of the audit, so the report is built to be evidence, not a deliverable. The engagement runs as one continuous piece of work: scope reconciliation against your audit scope document, external and internal testing of the in-scope systems, a findings report mapped to the criteria your auditor is testing, and remediation support with a retest that closes the loop before fieldwork. Where the gap is broader than a single test, we bridge it with independent testing and SOC 2 gap work, which pairs the gap analysis with the independent evidence an auditor expects, or we help you compare what different service levels actually include in our vulnerability management comparison.
If you have a SOC 2 timeline, the ten-minute version of the 5-Point Check above takes less time than explaining a scope gap after the auditor finds it. Talk to our team about where your test evidence stands, or schedule a demo to see how the evidence pack works on a real scope.
Frequently Asked Questions
Is penetration testing required for SOC 2? No, the AICPA's Trust Services Criteria do not mandate a penetration test by name. Auditors expect independent test evidence for criterion CC4.1, monitoring activities, and engagements without it face more, not less, audit work [1][5].
What type of penetration test is needed for SOC 2? Scope is driven by what the auditor needs evidence for: typically external testing of the public-facing surface plus internal testing of the systems in the audit scope. A scan alone is not the evidence, because it does not validate exploitability.
How often should you penetration test for SOC 2? At least once per audit period, with the report and retest results dated inside the reporting window. Any significant new system or architecture change inside the period is a new scope decision that should be tested.
Who can perform the penetration test for a SOC 2 audit? A security firm independent of the vendors and managed service providers who built or operate your in-scope systems. Independence is the point: the test has to evidence your control environment, not your vendor's work [2].
Does SOC 2 Type I require a penetration test? Strictly, no, because Type I covers control design at a point in time. A recent test is still the fastest way to evidence that the design works, and most clients include one.
Conclusion
The framework never says the words "penetration test required," and that is exactly the trap. The evidence it does require is separate, independent evaluation of your controls, and in practice that evidence is a test report that matches the audit scope, from an independent tester, dated inside the reporting period, with the fixes verified. While the AICPA tells peer reviewers to flag the SOC 2 reports that all look the same [3], your test report is the one file in the engagement that should not be able to. Run the 5-Point Check against your last test, reconcile the scope before the next one, and the audit conversation gets a lot shorter. Start at www.clone-systems.com.
References
[1] AICPA & CIMA: 2017 Trust Services Criteria with Revised Points of Focus (2022) (CC4.1, Monitoring Activities, names penetration testing as an acceptable separate evaluation; the criteria set does not contain a standalone penetration testing requirement). https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022 [2] Journal of Accountancy (AICPA): The Risks of Quick-Turn SOC Engagements and What CPAs Should Know, podcast with Amy Pawlicki, AICPA VP, Assurance & Advisory Innovation, April 30, 2026 (SOC 2 is an examination-level attestation engagement, not a certification; the AICPA flags quick-turn, boilerplate SOC 2 reports and ethics risks in arrangements with SOC tool providers). https://www.journalofaccountancy.com/podcast/2026/apr/the-risks-of-quick%E2%80%91turn-soc-engagements-and-what-cpas-should-know/ [3] Journal of Accountancy (AICPA): AICPA Guides Peer Reviewers to Address SOC 2 Risks, May 14, 2026 (May 2026 reviewer alert treats SOC 2 engagements as nonconforming when risk assessments, sample sizes, and testing procedures are identical across clients; structured monitoring and outreach for firms with SOC 2 practices begins June 1, 2026; SOC 2 is used to examine the controls of more than 1,600 organizations across 16,500 tests and 24,000 test procedures). https://www.journalofaccountancy.com/issues/2026/may/aicpa-guides-peer-reviewers-to-address-soc-2-risks/ [4] Cobalt: State of Pentesting Report 2026 (landing page; the report itself is a PDF. High-risk finding remediation half-life of 10 days for leaders versus 249 days for laggards, about 25x apart; programmatic organizations resolve 4.5x more critical findings in under three days than compliance-driven organizations, 45% versus 10%; data from 16,500+ penetration tests and a survey of 450 security professionals). https://resource.cobalt.io/state-of-pentesting-2026 [5] Essendis: SOC 2 and Penetration Testing: Meeting Trust Services Criteria (corroborates the CC4.1 point-of-focus language naming penetration testing). https://www.essendis.com/post/soc-2-and-penetration-testing-meeting-trust-services-criteria [6] Clone Systems: In our engagements, the penetration test report is the first file an auditor asks to see before the walkthrough begins. The most common scoping mistake we see is that the tested environment is a subset of the audited system, and a report with zero findings is less useful to an auditor than a report with a few findings and a clean retest. [7] Clone Systems: Penetration Testing vs Vulnerability Scanning: Why the Difference Matters. www.clone-systems.com/blog/penetration-testing-vs-vulnerability-scanning [8] Clone Systems: Can Automated Penetration Testing Replace Your Manual Penetration Test? www.clone-systems.com/blog/can-automated-penetration-testing-replace-your-manual-penetration-test [9] Clone Systems: Your Penetration Test Report Is Evidence, Not a Findings List. www.clone-systems.com/blog/penetration-test-report-is-evidence-not-a-findings-list [10] Clone Systems: Why Passing a Penetration Test Retest Isn't the Same as Fixing the Root Cause. www.clone-systems.com/blog/why-passing-a-penetration-test-retest-isnt-the-same-as-fixing-the-root-cause [11] Clone Systems: Bridging the SOC 2 Gap with Independent Testing. www.clone-systems.com/bridging-soc2-gap-independent-testing [12] Clone Systems: Vulnerability Management Comparison. www.clone-systems.com/vulnerability-management-comparison [13] Clone Systems: Contact and consultation. www.clone-systems.com/contact [14] Clone Systems: Schedule a demo. www.clone-systems.com/schedule-a-demo