The short answer
SOC 2 does not explicitly require a penetration test, but the Trust Services Criteria point to one: the points of focus for CC4.1 name penetration testing as a separate evaluation, and those for CC7.1 cover vulnerability scanning. Most CPA firms and customers expect an independent test of the in-scope system at least once a year, with findings fixed and retested.
On this page
- Does SOC 2 require a penetration test?
- What should a SOC 2 penetration test cover?
- When should the pentest happen in the observation period?
- How often should SOC 2 pentests run?
- What should a SOC 2 penetration testing report include?
- Do you need a retest?
- How do you use a SOC 2 pen test in Vanta or another compliance platform?
- Why Sovereign Secure
- Book your SOC 2 penetration test
SOC 2 penetration testing is an independent test of the system your SOC 2 report covers, timed and reported so your CPA firm can rely on it as evidence. SOC 2 does not explicitly require a penetration test, but the Trust Services Criteria point to one: the points of focus for CC4.1 name penetration testing as a form of separate evaluation, and those for CC7.1 cover vulnerability scanning. In practice, CPA firms and customers expect a test of the in-scope system at least once a year, with findings fixed and retested.
Sovereign Secure tests the applications, APIs and cloud environments behind SaaS and service platforms, and scopes each SOC 2 test from your system description and observation period. We do not issue SOC 2 reports; only licensed CPA firms can. We provide the penetration test, the retest and the report they examine. For the framework itself, see our SOC 2 compliance guide.
Does SOC 2 require a penetration test?
Not in so many words. SOC 2 sets criteria rather than prescribed controls, and no criterion says you must commission a penetration test. But the points of focus in the AICPA’s 2017 Trust Services Criteria (revised in 2022) mention penetration testing directly, and most service organisations include a test in the controls they describe. Once a test is in your control description, the CPA firm will check that it happened.
| Criterion | What it asks for | What a penetration test shows |
|---|---|---|
| CC4.1 | Ongoing and separate evaluations of whether controls are present and functioning; the points of focus name penetration testing | An independent evaluation of your security controls |
| CC4.2 | Deficiencies are evaluated and communicated to those responsible for corrective action | Findings reported, assigned and tracked to closure |
| CC6.1 | Logical access security over protected information assets | Authentication, authorisation and tenant separation hold up under attack |
| CC6.6 | Protection against threats from outside the system boundary | Internet-facing services resist external attack |
| CC7.1 | Detection of new vulnerabilities and misconfigurations; the points of focus cover vulnerability scanning | Weaknesses that scanners miss, such as logic flaws and chained attacks |
| CC8.1 | Changes are authorised, designed, tested and approved before implementation | Major releases and architecture changes were security tested |
You can, in principle, address CC4.1 with other evaluations, such as internal audit or an ISO 27001 certification. But a SaaS company that cannot produce a recent independent test will struggle with customer security questionnaires even if its SOC 2 report is clean, and many CPA firms expect to see one. The NCSC’s guidance on penetration testing makes a similar point from the UK side: a test checks that your vulnerability management works, rather than replacing it.
What should a SOC 2 penetration test cover?
The scope should match the system in your SOC 2 system description: the services customers rely on, and the infrastructure, software and data behind them. A common mismatch is a test of the marketing website while the product itself goes untested, and CPA firms and customers notice it.
| Component | Include when | What we test |
|---|---|---|
| Customer-facing web application | Almost always | Authenticated testing across every user role, tenant isolation, session handling and business logic; see web application penetration testing |
| APIs | Your product or integrations expose them | Authorisation on every object and function, token handling and rate limiting; see API penetration testing |
| Cloud environment | The system runs on AWS, Azure or Google Cloud | Identity and access management, storage exposure, network rules and logging; see cloud penetration testing and AWS penetration testing |
| External perimeter | Internet-facing hosts are in scope | Exposed services, administrative interfaces and misconfigurations |
| Mobile apps | They are part of the service | Data storage, transport security and the APIs behind them |
| Corporate network and endpoints | Your description includes offices or internal systems | Internal network and Active Directory attack paths |
Your cloud provider’s own infrastructure is not yours to test. Many SaaS reports carve out the cloud provider as a subservice organisation, and the provider’s own assurance reports cover its controls. Your test covers what you build and configure on top of it, within the provider’s published testing rules. For multi-tenant platforms, our page on security testing for SaaS companies goes further into tenant isolation and release-cycle testing.
Every test follows the five stages of penetration testing: planning and reconnaissance, scanning, gaining access, maintaining access, and analysis and reporting.
When should the pentest happen in the observation period?
For a Type 2 report, the test should fall inside the observation period, early enough that you can fix findings and retest before the period ends. For a Type 1, complete it before the report date. The CPA firm can only test a control that operated within the period it reports on.
| Point in the cycle | What to do |
|---|---|
| Before the period starts | Agree the scope with your CPA firm and book the test; fix anything already known |
| Early in the period | Run the penetration test |
| Within your remediation deadlines | Fix findings according to the severity deadlines in your vulnerability management policy |
| Before the period ends | Retest, so the evidence shows findings closed |
| Each following year | Test in the same part of the period, so there is never more than a year between tests |
If no test takes place inside the period, the CPA firm has nothing to examine for that control, which can lead to an exception or a gap your customers will ask about. Our comparison of SOC 2 Type 1 vs Type 2 explains how the observation period works and how long it usually runs.
How often should SOC 2 pentests run?
At least once a year, and after significant changes to the system. The Trust Services Criteria do not set a frequency, so the commitment comes from your own control description and policy, and annual testing is what most CPA firms and customers expect. The CC7.1 points of focus also call for vulnerability scans periodically and after significant change, which is why most SOC 2 programmes pair an annual test with regular vulnerability scanning.
Significant change typically includes a new authentication model, a new API version, a move between cloud providers, a major new product module, or an acquisition that joins two platforms. Write down what counts as significant in your policy, so the CPA firm can test you against your own rule. Teams that release often sometimes spread testing across the year through penetration testing as a service (PTaaS), with smaller scoped tests after each major change.
What should a SOC 2 penetration testing report include?
It should show who tested what, when, what was found and what happened next, in a form both your CPA firm and your compliance platform can use. The CPA firm will compare the report with your control description and system boundary, so the scope section matters as much as the findings. Include:
- Executive summary in plain language, suitable for sharing with customers under NDA.
- Tester and dates: the testing firm, the test window and the report date, showing independence from the team that built the system.
- Scope: the applications, URLs, API versions, cloud accounts, environments and user roles tested, matching the system description.
- Methodology: the approach and standards followed, such as the OWASP Web Security Testing Guide for web applications.
- Findings with severity ratings, evidence, affected assets and remediation advice.
- Retest results showing which findings are closed, and when.
Compliance automation platforms such as Vanta collect this evidence and track it against your controls, but they do not replace the test. Our report and retest results can be uploaded to whichever platform you use, as the section on compliance platforms below explains.
Do you need a retest?
Yes, if you want your evidence to show findings closed. CC4.2 is about evaluating deficiencies and getting them to the people who fix them, and a CPA firm will look for evidence that significant findings were remediated within the deadlines your policy sets. A retest gives independent confirmation that each fix works; without one, your evidence rests on your own engineers’ word.
Set remediation deadlines by severity in your vulnerability management policy, and make them realistic, because the CPA firm will test you against what you wrote. Findings you decide not to fix should go through your risk acceptance process, with a named owner and a review date.
How do you use a SOC 2 pen test in Vanta or another compliance platform?
Treat the platform as the place the evidence lives, not the source of it. A “Vanta pentest” is simply an independent penetration test whose report you upload against the platform’s penetration testing control, and the same applies to other compliance automation tools. To make the evidence hold up:
- Check what the control asks for. Note the frequency and scope that the platform’s control and your own policy describe, so the test matches them.
- Scope the test to your system description, using the components table above, not just the marketing website.
- Commission an independent tester and book the test early in your observation period.
- Upload the report as evidence against the control, with the test dates and scope visible.
- Track findings to closure in your ticketing system or the platform, against the deadlines in your vulnerability management policy.
- Upload the retest results, so the evidence shows findings closed, and diarise next year’s test.
“External pen testing” can mean a test by an outside firm, which is what SOC 2 evidence usually needs, or a test of your internet-facing attack surface; a SOC 2 test is usually both.
Why Sovereign Secure
We are not a CPA firm and we do not issue SOC 2 reports. We provide the testing evidence:
- Full-stack testing of web applications, APIs, cloud environments, networks and mobile apps, plus source code review and AI and LLM testing, with vulnerability scanning between tests.
- ISO 27001 certified, so our own information security management is independently audited. We also provide ISO 27001 consultancy for companies whose UK and European customers ask for certification as well as SOC 2 (see ISO 27001 vs SOC 2); certification audits are carried out by our partner certification body, MQA International.
- A PCI SSC Qualified Security Assessor (QSA) company, for SaaS platforms that also handle card data and need penetration testing under PCI DSS requirement 11.4.
- UK and US presence: a UK company since 2012, headquartered in Accrington, Lancashire, with an office in Los Angeles as well as Singapore, Dubai and Dhaka.
Book your SOC 2 penetration test
Tell us your report type, your observation period dates, the applications, APIs and cloud accounts in scope, and anything your CPA firm has asked for. We will send a fixed quote for a test that lands inside your window, with time planned for the retest. Request a penetration testing quote or call +44 161 523 5276.
Last reviewed October 2026 by the Sovereign Secure assessment team.
