2 October 2026 · 9 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
SOC 2 Penetration Testing: What the Trust Services Criteria Ask and What Your Auditor Expects
SOC 2 does not list penetration testing as a required control. Nearly every SOC 2 auditor still asks for the report. This guide explains why, which criteria a test supports, and how to run one that holds up in a Type II observation period.
Is penetration testing required for SOC 2?
Strictly, no. SOC 2 is an attestation framework built on the AICPA Trust Services Criteria (TSC). The criteria describe outcomes, such as identifying vulnerabilities and evaluating whether controls operate effectively, and leave it to you to choose the controls that deliver those outcomes. The AICPA's points of focus for the criteria do name penetration testing as an example of how an organisation can meet them.
That is why in practice the question is settled. When an auditor tests whether you identify and address vulnerabilities, a dated penetration-test report from an independent firm is the cleanest piece of evidence you can hand over. Without it, you are asking the auditor to accept scanner output and internal assertions, and most will push back or note an exception.
The Trust Services Criteria a penetration test supports
The Common Criteria (CC series) apply to every SOC 2 report regardless of which trust categories you include. A penetration test is evidence for these.
CC4.1 Monitoring activities: ongoing and separate evaluations
The entity selects, develops and performs evaluations to confirm that controls are present and functioning. The AICPA points of focus for CC4.1 list penetration testing as a form of separate evaluation. This is the criterion most auditors map your test to.
CC7.1 Detection of new vulnerabilities and configuration changes
The entity uses detection and monitoring procedures to identify changes to configurations that introduce new vulnerabilities, and susceptibilities to newly discovered vulnerabilities. Penetration testing, alongside vulnerability scanning, is the standard evidence here.
CC7.2 and CC7.3 Monitoring and evaluation of security events
A test that includes detection-evasion checks shows whether your monitoring actually notices an attacker. Many auditors appreciate a short section in the report on what your SOC or MDR saw during the engagement.
CC3.2 Risk identification and CC9.1 Risk mitigation
Findings feed the risk register. A report with severity ratings and business impact gives the auditor a clear trail from identified risk to mitigation decision.
CC8.1 Change management
Testing after significant infrastructure or application changes demonstrates that security is evaluated as part of change, which is what CC8.1 asks for.
Type I versus Type II: what changes for the penetration test
The report type determines what the auditor needs from your testing programme, not only from a single test.
| Aspect | SOC 2 Type I | SOC 2 Type II |
|---|---|---|
| What is attested | Control design at a point in time | Control design and operating effectiveness over a period, typically 3 to 12 months |
| Penetration test evidence | A recent report shows the control is designed and in place | The test, the remediation tickets and the retest must all fall inside or just before the observation window |
| Cadence | One test before the report date | A documented annual cycle; auditors look for the previous year's test as well |
| Remediation | Plan is sufficient | Evidence that critical and high findings were fixed and verified within your stated SLA |
| Common exception | Test older than 12 months | Open critical findings at period end without a documented risk acceptance |
Scoping a SOC 2 penetration test
Scope follows the system description in your SOC 2 report. If a system is in the description, it should be in the test.
- The production environment that delivers the service described in the report, including the cloud accounts and the management plane
- Customer-facing web applications and APIs, tested for OWASP Top 10, authentication, authorisation and multi-tenant isolation
- Internal network or corporate environment where engineers access production, if it is in the system boundary
- Identity provider, single sign-on and MFA enforcement for staff and for customers
- Segmentation between production and non-production, and between tenants where applicable
- A retest of every critical and high finding, documented with before-and-after evidence
Cadence: once a year, plus after change
An annual penetration test is the de facto SOC 2 standard. Auditors expect it to be documented in your policies, performed within the last 12 months, and repeated after significant changes such as a new product, a cloud migration or a major architecture change. Fast-moving SaaS companies often add a lighter application test per quarter or per major release, which also strengthens the CC8.1 change-management narrative.
Plan the test early in the observation period. A test performed in the final month leaves no room for remediation and retest, and the auditor will record open findings rather than closed ones.
What a SOC 2 auditor looks for in the report
Auditors want to see independence (a third-party firm with named, certified testers), a methodology they recognise (OWASP, PTES, NIST SP 800-115), a scope that matches the system description, findings with severity and evidence, and proof of remediation. The report should be dated, the tester should be identifiable, and the retest should be a separate dated section. We map every finding to the relevant Trust Services Criteria so your auditor does not have to.
If your customers are in the United States, expect their vendor-risk teams to ask for the same report during procurement. A SOC 2-ready penetration-test report doubles as a sales document; a scanner export does not.
Frequently asked questions
Preparing for a SOC 2 audit?
Our OSCP-certified testers scope the engagement to your system description and map every finding to the Trust Services Criteria. Talk to an expert.