SOC 2 Penetration Testing Requirements: A Practical Guide for UK Vendors

Here is the short version. SOC 2 penetration testing requirements are not written into the framework itself. But auditors treat a pentest as the default proof that your controls actually work. Skip it, and you will spend more time justifying the gap than you would have spent running the test.

This guide covers what the Trust Services Criteria actually say, why testing became the norm anyway, and what UK service and SaaS businesses need to get right before their next audit.

What SOC 2 is testing you against

SOC 2 is an audit framework built by the AICPA. It checks a service organisation’s controls against five Trust Services Criteria, as Cherry Bekaert’s overview of the framework sets out. Those five are security, availability, processing integrity, confidentiality and privacy. Security is mandatory. The other four get added depending on what your business does.

Cloud platforms, SaaS vendors, payment processors, and anyone handling customer data on another company’s behalf, typically need it. It is what enterprise buyers ask for before they will sign a contract.

What do SOC 2 penetration testing requirements actually say?

Not much, on paper. The 2017 Trust Services Criteria never use the phrase “penetration test”. Under Common Criteria 4.1, a business must run “ongoing and/or separate evaluations” to check that its controls are present and actually functioning. Not just written down in a policy document.

A penetration test is the clearest way most auditors have found to satisfy that. Common Criteria 7.1 covers how you detect and respond to new vulnerabilities. It points the same way. You could, in theory, argue your way to compliance using vulnerability scans and internal reviews alone. In practice, auditors expect a pentest, and going without one invites the exact scrutiny you are trying to avoid.

Type I and Type II want different things from you

A Type I report is a snapshot. Are your controls designed properly as of one date? There is no observation period behind it, so a recent test plus solid documentation is often enough.

A Type II report is a track record. It checks whether your controls worked continuously across an observation period. Per Drata’s comparison of the two report types, that period typically runs three to twelve months. The AICPA suggests six months as a minimum. Larger enterprise customers increasingly expect twelve. A pentest from a year ago proves little about the period the auditor is now examining. For Type II, the test needs to sit inside that window. That is not really optional.

Timing: get this wrong and the whole audit slips

The single most common mistake is leaving the penetration test until close to the audit date. Findings need time to be triaged, fixed, and ideally retested before the observation period closes. Build the test in early. Treat remediation as part of the timeline, not an afterthought. Keep a dated record of when each fix was verified. Auditors are far more comfortable with a report that shows “found, fixed, confirmed” than one that just lists open findings. Get this right, and SOC 2 penetration testing requirements become routine paperwork instead of a fire drill before the audit.

Common mistakes that trip businesses up

A few patterns come up again and again with SOC 2 penetration testing requirements. The first: submitting a vulnerability scan and labelling it a pentest, then being surprised when the auditor pushes back. These are not interchangeable, and most auditors spot the difference immediately. The second: scoping the test around whatever is convenient rather than what is actually in the SOC 2 boundary. A staging environment gets tested thoroughly while a production API handling customer data goes untouched.

The third mistake is treating remediation as optional once the report lands. A pentest that surfaces a critical finding and nothing more is not evidence that your controls work. It is evidence that they did not, at least on the day of testing. Auditors want the fix, and ideally a retest confirming it held. The fourth is timing: running the test so early it sits outside the observation period entirely. For a Type II report, that proves very little about the window under review.

What a SOC 2 pentest report needs to include

Meeting SOC 2 penetration testing requirements is not just about running the test. It is about the paperwork that proves it happened properly. Auditors are not grading prose style, but a well-written penetration testing report still separates a five-minute evidence review from a week of follow-up questions. At minimum, it should include:

• Scope that matches your actual SOC 2 boundary, not a generic sweep of whatever is easiest to test.
• Findings ranked by severity, written clearly enough for a non-technical auditor to follow the risk.
• Remediation evidence for anything critical or high, not just a list of what was found.
• A retest, dated, confirming the fixes hold up under a second look.

Miss the retest, and you are asking the auditor to take your word for it. That is rarely enough on its own.

Independence matters more than a specific certification

SOC 2 does not name a required accreditation for testers. What auditors, and increasingly your own enterprise customers, actually care about is independence. Someone with no stake in the system’s outcome should run the test, not the team that built it. Accreditation from a recognised body such as CREST demonstrates that independence quickly. You will not need to argue the point every time a customer asks.

This is precisely the gap a properly scoped, independent penetration test is built to close. It produces evidence that speaks directly to CC4.1 and CC7.1. That is worth more than a repurposed vulnerability scan with a different cover page.

Frequently asked questions

How often do we need to test for SOC 2?
In practice, SOC 2 penetration testing requirements settle into a simple pattern: annual testing, timed so the most recent test sits inside, or just before, your current observation period.

Will a vulnerability scan satisfy the auditor instead?
Rarely, on its own. A vulnerability scan finds known issues automatically. A penetration test has someone actively trying to exploit and chain them together, which is what CC4.1’s “ongoing evaluation” language is really asking for.

Do we need to test systems outside the SOC 2 boundary?
No. Only what falls inside the defined scope of your report. Testing more can be worthwhile for your own security posture, but it is not what the audit requires.

What if we find something serious right before the audit?
Fix it, document the fix, and retest if there is time. Auditors respond better to a disclosed, remediated finding than to a report that looks suspiciously clean.

Do we need to hand the full pentest report to every customer who asks?
Not usually. Many businesses share a summary or attestation letter instead of the full technical report, which can contain sensitive detail about live vulnerabilities. Check what your contracts and NDAs actually commit you to before deciding what to send.

SOC 2 penetration testing requirements really boil down to one question: can you show, with evidence, that your controls hold up under a genuine attempt to break them? If you want a second opinion on scoping before your next audit cycle, get in touch and we can walk through what your specific boundary needs.