Does SOC 2 Require a Penetration Test? What the Trust Services Criteria Say
Short definition
A criterion-by-criterion guide to penetration testing and vulnerability scanning in SOC 2: what the 2017 Trust Services Criteria with the 2022 points of focus actually say, why a pentest is expected without being required, and the evidence a service auditor tests.
Why this matters now
The AICPA's 2022 revision of the points of focus lists penetration testing and vulnerability scans among the evaluations management may use to check that controls are present and functioning, and asks for scans on a periodic basis and after significant changes. None of that makes a pentest mandatory, but a type 2 report shows customers the tests the auditor performed on your controls, so a missing test is visible.
Key points
- ▸SOC 2 has no penetration testing requirement: the Trust Services Criteria describe outcomes, not a mandatory set of controls.
- ▸CC4.1 asks for ongoing and separate evaluations; its 2022 point of focus names penetration testing, vulnerability scans and security assessments among the possible evaluations.
- ▸CC7.1 covers detection of new vulnerabilities; its point of focus describes infrastructure and software scans on a periodic basis and after significant changes, with timely remediation.
- ▸Points of focus are important characteristics of the criteria, not requirements; some may not be relevant to your entity.
- ▸No frequency or tester type is set; evaluators need sufficient knowledge and separate evaluations should give objective feedback.
- ▸Whatever testing your system description says you do becomes a control the service auditor tests, and a type 2 report describes those tests and their results.
The short answer: does SOC 2 require a penetration test?
No. A SOC 2 examination reports on your controls against the AICPA's Trust Services Criteria, and the criteria do not prescribe controls. The introduction to the 2017 criteria (with revised points of focus, 2022) says so directly:
- The criteria set out the outcomes an entity's controls should ordinarily meet, and are intended to be used for evaluation and reporting regardless of the specific controls management implements.
- This contrasts with process and control frameworks that mandate a specific set of controls; the criteria recognize that there is no specific set of processes and controls that can mitigate all the unique threats, vulnerabilities and risks that entities face.
Under each criterion, the document lists points of focus. Following COSO, they represent important characteristics of the criteria and may help management and the auditor evaluate whether controls were suitably designed and operated effectively. The AICPA adds that some points of focus may not be suitable or relevant to an entity, and that management may customize them or consider others.
Penetration testing appears in exactly that layer: as one of the evaluations a point of focus under CC4.1 lists. So the honest answer has two halves. No criterion says “perform a penetration test”. And a security-scoped SOC 2 with no technical testing behind the monitoring and vulnerability criteria is hard to defend to an auditor or a customer.
CC4.1: the point of focus that names penetration testing
CC4.1 is COSO Principle 16: the entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.
The additional point of focus for engagements using the Trust Services Criteria, Considers Different Types of Ongoing and Separate Evaluations, reads in the 2022 revision: management uses a variety of ongoing and separate risk and control evaluations to determine whether internal controls are present and functioning; depending on the entity's objectives, such evaluations may include first- and second-line monitoring and control testing, internal audit assessments, compliance assessments, resilience assessments, vulnerability scans, security assessment, penetration testing, and third-party assessments.
The March 2020 edition already named penetration testing in the same point of focus, next to independent certification against established specifications (for example ISO certifications) and internal audit assessments. The 2022 revision widened the list; it did not turn it into a requirement.
The COSO points of focus under CC4.1 matter for how you run testing:
- Uses Knowledgeable Personnel: evaluators have sufficient knowledge to understand what is being evaluated.
- Adjusts Scope and Frequency: management varies the scope and frequency of separate evaluations depending on risk.
- Objectively Evaluates: separate evaluations are performed periodically to provide objective feedback.
CC4.2 then covers what happens to the results: management and the board assess them, deficiencies are communicated to those responsible for corrective action, and management tracks whether deficiencies are remedied on a timely basis.
CC7.1 and CC3.2: vulnerability scans and vulnerability identification
CC7.1 reads: to meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.
Its point of focus Conducts Vulnerability Scans describes infrastructure and software vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after significant changes are made to the environment, with action taken to remediate identified deficiencies in a timely manner. The other CC7.1 points of focus cover defined configuration standards for hardening, monitoring for noncompliance with them, change-detection mechanisms such as file integrity monitoring, and detection of unknown or unauthorized components.
In the risk assessment criteria, CC3.2 includes the point of focus Identifies Vulnerability of System Components: the entity identifies the vulnerabilities of system components, including system processes, infrastructure and software.
Scans answer CC7.1 on their own. A penetration test adds what scans cannot: which of those vulnerabilities, and which chains of them, can actually be exploited in your environment. That is the input the risk analysis under CC3.2 and the remediation priorities under CC4.2 need. See vulnerability assessment vs penetration testing.
What the service auditor actually tests
A SOC 2 report is about the controls in management's description of the system. The criteria describe two types of engagement:
- Type 2 reports on the suitability of design and the operating effectiveness of controls throughout a specified period, and includes a detailed description of the tests of controls the service auditor performed and their results.
- Type 1 addresses the same subject matter but has no opinion on operating effectiveness and no description of tests.
That is why the question “is a pentest required” has a practical answer. If your description says “an independent firm performs an external penetration test annually and findings are tracked to remediation”, the auditor tests that control, typically by asking for the report, checking its date against the period and tracing a sample of findings to closure. A missed test or unremediated findings become exceptions in the report your customers read.
Expect requests like these:
- The penetration test report dated within or relevant to the examination period, with scope and methodology.
- Evidence of who performed it and why they are qualified and objective.
- Vulnerability scan results over the period, including scans after significant changes.
- Tickets or records showing findings were prioritized, remediated and re-tested, and the approval of any accepted risk.
- Evidence that results reached management, and the board where relevant (CC4.2).
Frequency and independence
Frequency. The criteria set none. The CC4.1 point of focus asks management to vary scope and frequency depending on risk, and the CC7.1 point of focus asks for scans periodically and after significant changes. Whatever interval you write into your description is the one the auditor tests, so choose one you can meet every period. If you also answer to PCI DSS or NYDFS Part 500, their at-least-annual penetration testing floors are a natural anchor; see the worldwide guide to penetration testing requirements by regulation.
Independence. The criteria do not require an external tester. They ask for evaluators with sufficient knowledge and for separate evaluations that provide objective feedback. An internal red team can meet that if it is separate from the people who run the systems in scope; an outside firm for the annual test makes objectivity easier to show.
The service auditor is a CPA firm that is independent of you, but it examines your controls; it does not perform your penetration test, and its tests of controls are not a substitute for one.
What is explicit and what is expected
Written in the criteria:
- CC4.1: ongoing and/or separate evaluations of whether internal control components are present and functioning.
- CC7.1: detection and monitoring procedures for configuration changes that introduce vulnerabilities and for newly discovered vulnerabilities.
- CC3.2 and CC4.2: risk identification and analysis, and timely evaluation, communication and correction of deficiencies.
Points of focus, relevant unless you can show otherwise:
- Penetration testing, vulnerability scans and security assessments as types of evaluation (CC4.1, 2022 wording).
- Vulnerability scans on a periodic basis and after significant changes, with timely remediation (CC7.1).
- Knowledgeable evaluators, risk-based scope and frequency, objective separate evaluations.
Decided by your own control description:
- Whether a penetration test is part of your controls, and how often, is up to you; once your system description says it happens, the auditor tests it. Ask your auditor and your largest customers what they expect before the audit period starts.
Not written anywhere:
- A mandatory penetration test, a fixed interval, a required testing vendor or tester certification.
How an on-premise autonomous AI red team produces that evidence
Zero Hunt is an autonomous AI red team for networks and infrastructure: automated penetration testing on an on-premise appliance, on private AI, with a human in the loop. It is not a CPA firm, does not issue or sign SOC reports, and does not replace the service auditor or an independent tester you describe in your system description. What it adds is evidence for the months between annual tests.
- Trust Services Criteria mapping. SOC 2 is one of the 34 frameworks the engine maps to, using the 2017 criteria with the 2022 points of focus. Findings feed CC7.1 automatically and CC4.1 together with evidence you add, and the same record can be exported for your auditor.
- Periodic and after significant changes. Black-box and gray-box campaigns run once, daily, weekly, monthly or on a custom schedule, so the scans and tests your description promises actually happen, including after changes.
- Exploited, not just detected. Each finding records whether it was actually exploited, which is what separates a remediation priority from a scanner line, and each fix can be re-tested with the same proof for CC4.2.
- Human approval of risky steps. Five autonomy levels decide what waits for an operator. See human in the loop.
- Records that hold up for a type 2 period. Every attack attempt is an Ed25519-signed entry in a SHA-256 hash chain, and exported reports are ECDSA-signed.
- No customer data leaves the appliance. Models run on it with no external AI service, so no outside AI provider processes your test results.
Zero Hunt's own SOC 2 Type II is planned, not held; the status is on the Trust Center. To check how this fits your description and control matrix, book a 30-minute readiness call.
Sources
Goes deeper
- Worldwide guide: pentest requirements by regulation →
- Automated penetration testing: how it works and how to evaluate tools →
- Vulnerability assessment vs penetration testing (VA/PT) →
- Does ISO 27001 require penetration testing? →
- PCI DSS 11.3 and 11.4: scans and penetration tests →
- Industry: enterprise and corporate →
- On-premise AI red team on private AI →
- Book a 30-minute testing readiness call →
Want this against your environment?
Book a 30-minute scoping call — we will map this directly to your current compliance scope and threat profile.