A UK enterprise prospect asks for ISO 27001. Your US pipeline has been asking about SOC 2 for months. You are a seed or Series A SaaS founder trying to figure out which framework to pursue first, and somewhere in that decision sits a question nobody answers clearly: does either framework actually require a penetration test, and does it matter which one you choose?
The honest answer is more interesting than most compliance guides let on. ISO 27001 vs SOC 2 pentest requirements are not the same, and the difference is not what most founders assume.
What ISO 27001 Actually Says
Here is the detail that surprises most people: the words “penetration testing” do not appear anywhere in ISO 27001’s Annex A controls. Not once.
What exists instead are two controls that get mapped to penetration testing in practice. A.8.29, Security Testing in Development and Acceptance, requires organizations to define and implement security testing processes during development and before systems go live. A.8.8, Management of Technical Vulnerabilities, the 2022 successor to the old A.12.6.1, requires organizations to obtain information about technical vulnerabilities, evaluate their exposure, and take appropriate measures to address the risk.
Neither control specifies a method. The standard explicitly does not mandate specific tools or tests, it expects risk-based, structured security testing appropriate to the system and its exposure. That could be satisfied with automated scanning, code review, manual penetration testing, or some combination, depending on what your own risk assessment determines is appropriate.
In practice, certification bodies and ISO 27001 auditors treat penetration testing as the most credible way to demonstrate A.8.29 and A.8.8 compliance, especially for any organization handling customer data through a web application or API. Most certification bodies expect at least one penetration test per year, plus additional testing after significant changes to your systems. But that expectation comes from auditor practice and your own risk assessment, not from explicit language in the standard itself.
What SOC 2 Actually Says
SOC 2 takes a different approach. Under CC4.1, the Trust Services Criteria implementation guidance explicitly names penetration testing as an acceptable monitoring activity to verify that controls are functioning. The word appears directly in the AICPA’s guidance for evaluating ongoing control effectiveness.
That makes SOC 2 more explicit than ISO 27001 on this specific point, even though neither framework technically mandates a pentest as a line-item requirement. SOC 2 auditors reviewing your CC4.1 evidence are looking for exactly this kind of independent testing, and a penetration test report is the most direct way to satisfy it.
The Side-by-Side Comparison
Putting the two frameworks next to each other on this specific question:
ISO 27001 never uses the words “penetration testing” in its controls. SOC 2’s CC4.1 implementation guidance does. ISO 27001 leaves the testing method to your own risk-based decision. SOC 2 points specifically toward independent evaluation methods including penetration testing. ISO 27001’s expected frequency comes from auditor practice and certification body norms, typically annual, plus after major changes. SOC 2’s expectation comes from the same logic applied to a 6 to 12 month observation period for Type II reports.
The practical result is nearly identical for a SaaS startup regardless of which framework you choose: auditors and certification bodies for both frameworks expect to see a current, credible penetration test report as part of your evidence package. The legal language differs. The operational expectation does not.
Why This Matters for Choosing a Framework
If you are a seed or Series A SaaS founder deciding which compliance framework to pursue first, the pentest requirement should not be the deciding factor, because the practical burden is roughly equivalent either way. What should actually drive the decision is your customer base.
If your enterprise pipeline is predominantly US-based, SOC 2 is almost always the better starting point. It is the framework US enterprise buyers ask for by default, and the audit process is generally faster and less expensive than ISO 27001 certification for an early-stage company.
If you have meaningful UK or EU enterprise prospects, or you are selling into industries, financial services, government-adjacent sectors, certain healthcare contexts, where ISO 27001 is the established standard, it becomes the more relevant framework regardless of testing requirements.
Many growth-stage SaaS companies eventually pursue both. The good news is that a well-scoped penetration test satisfies the practical expectation under either framework. A single annual pentest, timed appropriately and documented with the right level of detail, can serve as supporting evidence for a SOC 2 Type II observation period and an ISO 27001 surveillance audit in the same year, as long as the scope covers the systems relevant to both certifications.
What a Pentest Needs to Cover for Either Framework
Regardless of which framework you choose first, a pentest that genuinely satisfies auditor expectations under ISO 27001 or SOC 2 needs a few specific things.
The report needs to map findings to the relevant controls, A.8.29 and A.8.8 for ISO 27001, CC4.1 for SOC 2, rather than presenting a generic list of vulnerabilities ranked only by CVSS score. Auditors reviewing your evidence want to see the connection between what was tested and which control it satisfies.
The testing needs to be manual, not purely automated. Both frameworks expect evidence of genuine evaluation, and an automated scan output does not carry the same weight as a report demonstrating human-led exploitation attempts, business logic testing, and exploitation evidence.
The scope needs to reflect your current environment. A report that predates a significant infrastructure change or new product launch will draw questions from auditors under either framework, since both expect testing to be revisited after major changes.
And the findings need documented remediation. Auditors for both frameworks are evaluating whether you found problems and fixed them, not just whether you ran a test.
The Bottom Line
Neither ISO 27001 nor SOC 2 contains a line that says “you must conduct a penetration test.” But ISO 27001’s risk-based language and SOC 2’s CC4.1 implementation guidance both lead to the same practical place, auditors and certification bodies expect to see one, and enterprise buyers reviewing your compliance reports will ask for one regardless of which framework you are pursuing.
The framework you choose should be driven by your customer base and where your enterprise pipeline actually sits, not by which one has a more explicit pentest requirement on paper. Once you have made that decision, a single well-scoped penetration test, timed to your audit cycle, satisfies the practical expectation under either standard.
Packet33 conducts web application, API, and external network penetration tests for SaaS and HealthTech startups, with reports formatted to support evidence requirements under SOC 2, ISO 27001, and HIPAA. We work with clients in both the US and UK to time testing around their specific certification and audit cycles.
Talk to us about scoping a pentest that supports your compliance roadmap.
Packet33 is a penetration testing and compliance advisory firm serving SaaS and HealthTech startups in the US, Canada, and UK.