If you run a UK software company and you’ve started selling to customers in the United States, there’s a good chance a prospect has already asked for your SOC 2 report. Shortly after that, the next question usually arrives, which is whether SOC 2 means you need a penetration test.
The honest answer is that SOC 2 doesn’t strictly require one. In practice, though, most SaaS firms going through a SOC 2 audit end up commissioning a penetration test anyway, because it’s one of the clearest ways to provide evidence of the controls their auditor is assessing, and because customers will ask for it regardless. This guide explains what SOC 2 actually says, what auditors tend to expect, and how to plan a test that does the job.
What is SOC 2?
SOC 2 is an attestation framework developed by the American Institute of Certified Public Accountants (AICPA). It assesses how a service organisation protects the data it handles for its customers, which is why it has become the default security question for software and cloud providers selling into the US market.
A SOC 2 report is issued by a licensed CPA firm after it audits your controls against the Trust Services Criteria. Security is the only mandatory category, and organisations can choose to add availability, processing integrity, confidentiality and privacy, depending on the services they provide and what their customers need.
There are two types of reports, and the difference matters for penetration testing:
- A Type I report assesses how well your controls are designed at a single point in time.
- A Type II report assesses how effectively those controls actually operated over a period, which is typically somewhere between three and twelve months.
Most enterprise customers want a Type II report because it shows that your security works consistently, not just on the day the auditor looked.
Does SOC 2 Require Penetration Testing?
Strictly speaking, no. SOC 2 doesn’t contain a list of mandatory controls, so there’s no line in the framework that says “you must commission a penetration test”. As the Cloud Security Alliance puts it, a SOC 2 report has no explicit requirements for penetration testing, or for any specific control. Instead, you design your own controls to meet the criteria, and the auditor decides if those controls do the job.
Interestingly, though, penetration testing is named in the criteria themselves. Criterion CC4.1 asks organisations to select, develop, and perform ongoing, separate evaluations to confirm their controls are present and functioning, and one of its points of focus describes management using different types of evaluation, including penetration testing.
Criterion CC7.1, which covers detecting new vulnerabilities and configuration changes, has a point of focus on carrying out vulnerability scans periodically and after significant changes.
Points of focus aren’t a checklist, so you’re not obliged to meet every one of them, but when the criteria you’re being audited against mention penetration testing by name, it’s easy to see why so many auditors treat it as the expected way of meeting them.
Why SaaS Firms End Up Commissioning a Pen Test Anyway
- Your auditor needs evidence: To meet CC4.1, you need to show that you’re independently evaluating your security controls, and to meet the wider monitoring and vulnerability management criteria, you need to show that weaknesses are being found and fixed. An independent penetration test of your production application and infrastructure is one of the most straightforward ways to provide that evidence. Without one, you’d need to show an alternative evaluation that gives your auditor the same level of comfort, which is usually harder to put together.
- Your customers want to see it: A SOC 2 report tells a prospect that your controls have been audited, but many security teams at larger US companies will still ask for a penetration test summary or attestation letter as part of their vendor review. Some will ask for it even when you already have a SOC 2 report, because a pen test tells them something different, namely how your actual product holds up against an attacker. Cyber insurers often make the same request, so the test tends to pay for itself several times over.
What Auditors Actually Expect from a SOC 2 Penetration Test
Because SOC 2 doesn’t define the test, it’s worth agreeing on the details with your auditor before you commission it. That said, auditors consistently look for a few things.
Independence
The test should be carried out by someone independent of the team that builds and runs the system, which in practice usually means an external provider. Choosing a CREST-accredited penetration testing provider gives both your auditor and your customers confidence that the work meets a recognised standard.
A scope that matches your SOC 2 system
Your SOC 2 report includes a description of the system being audited, covering the applications, infrastructure, data and people involved. Your penetration test should cover the same ground.
For most SaaS businesses, that means web application penetration testing of the customer-facing product and its APIs, testing of the cloud environment it runs in, and, where it’s relevant, the internal tooling staff use to administer it. Document any exclusions, because an auditor will notice if a key part of the system is left out.
If your product includes AI features, such as a chatbot or an assistant built on a large language model, include those in scope too. They introduce risks that traditional testing doesn’t cover, which is why we offer dedicated LLM testing.
Timing within the audit period
For a Type II report, the test needs to fall within the observation period; otherwise, it can’t show that your controls were operating during that period. If your audit window runs from January to June, a penetration test completed the previous November won’t help much. Planning the test date around the audit calendar is one of the simplest ways to avoid a frustrating gap.
Manual testing, not just a scan
Automated vulnerability scanning supports CC7.1, but a scan report isn’t the same as a penetration test, and auditors and customers can usually tell the difference. The issues that matter most in SaaS applications, such as broken access controls, tenant isolation failures and business logic flaws, are found by people, not scanners. Our guide to automated vs manual penetration testing explains why.
Evidence that findings were fixed
Perhaps most importantly, auditors care about what happened after the test as much as the test itself. A report full of unresolved high-risk findings can raise more questions than it answers. Keep a record of how you handled each finding, such as a fix, a compensating control, or documented risk acceptance, and confirm fixes through retesting after you fix vulnerabilities. If you can’t fix everything before the audit, our guide on what to do if you can’t fix everything explains how to prioritise and document the rest.
How Often Should You Test for SOC 2?
The Trust Services Criteria don’t set a frequency, but annual testing has become the common baseline, which lines up neatly with an annual SOC 2 Type II cycle, and most auditors are comfortable with it. You should also test after significant changes to your product or infrastructure, such as a major release, a new authentication system or a move to a different cloud provider, since those changes can introduce new weaknesses part-way through the year.
Be careful not to let the audit cycle become the only thing that decides your scope, though. Testing the same parts of the product every year to keep the auditor happy, while new features go untested, is a classic example of the Pentest Trap.
SOC 2 or ISO 27001?
UK SaaS firms often ask which of the two they should pursue. The short answer is that it depends on where your customers are. SOC 2 is the expectation in the US, while ISO 27001 is more widely recognised in the UK, Europe and much of the rest of the world. Firms with customers on both sides of the Atlantic frequently end up with both.
The good news is that a well-scoped penetration test can provide evidence for both at once. ISO 27001 doesn’t explicitly require a pen test either, but its controls on managing technical vulnerabilities and security testing are very well supported by one. For a wider comparison, see our guide to which compliance standards require penetration testing.
SOC 2 Penetration Testing with Fortifi
Fortifi is a CREST-accredited penetration testing company, and our UK penetration testing services help SaaS businesses get the evidence they need for SOC 2, ISO 27001 and customer security reviews. We test web applications, APIs, cloud environments and AI features, and every engagement includes clear reporting, practical remediation guidance and retesting, so you’re ready when your auditor or a prospect asks.
Because we don’t do sales calls, you’ll speak directly to a cybersecurity expert who can help you scope a test around your SOC 2 system description and time it to fit your audit window. Book a call with our team today.
SOC 2 Penetration Testing FAQs
Is a penetration test mandatory for SOC 2?
No. SOC 2 doesn’t prescribe specific controls, so a penetration test isn’t strictly mandatory. However, the Trust Services Criteria mention penetration testing as a way of evaluating controls, and in practice, most auditors and enterprise customers expect to see one.
Does a SOC 2 Type I report need a penetration test?
A Type I report only assesses how your controls are designed at a point in time, so a penetration test is less critical. Even so, many firms commission one before their first Type I audit because it identifies issues early and gives them evidence to share with prospects right away.
Can a UK penetration testing company provide a SOC 2 pen test?
Yes. SOC 2 doesn’t require the penetration tester to be based in the US. What matters is that the test is independent, properly scoped and well documented. The SOC 2 report itself must be issued by a licensed CPA firm, which is a separate engagement from the penetration test.
Will a vulnerability scan be enough for SOC 2?
Regular vulnerability scanning supports SOC 2’s vulnerability management criteria, but it doesn’t replace a penetration test. Scans identify known weaknesses, while a penetration test shows how an attacker could exploit your application, which auditors and customers usually want to understand.