No. There's no clause in ISO/IEC 27001 that says you must buy a penetration test.
What the standard asks is that you manage technical vulnerabilities and that you test security, then show your working. Your risk assessment and your Statement of Applicability decide what that looks like, and your certification body decides whether the evidence you produced is good enough. Same shape as the SOC 2 answer, for different reasons.
This is general information, not legal or certification advice.
Clauses are the requirements. Annex A is a menu
Get this straight before anyone quotes a control number at you, because the rest of the post hangs off it.
The auditable requirements of ISO/IEC 27001:2022 live in clauses 4 through 10: context, leadership, planning, support, operation, performance evaluation, improvement. Those are the parts you can't opt out of. None of them names a testing technique.
Annex A is a reference list of information security controls. The standard directs you to compare the controls your risk treatment produced against that list, so nothing necessary gets missed, and then to write a Statement of Applicability: which controls are necessary, why they are in, whether they are implemented, and a justification for excluding any Annex A control. That requirement sits in clause 6.1.3. The Annex A list is explicitly not exhaustive, and you can add controls of your own.
Annex A in the 2022 revision uses the same controls, numbering and titles as the guidance in ISO/IEC 27002:2022. That matters in practice: 27001 gives you a one-line control, and 27002 is where the implementation guidance lives. When a consultant tells you what a control “requires,” they're usually reading 27002.
The two controls that actually bear on testing
Under the 2022 numbering, the controls people argue about are 8.8, Management of technical vulnerabilities, and 8.29, Security testing in development and acceptance. Nearby and often relevant: 8.25 secure development life cycle, 8.26 application security requirements, 8.28 secure coding.
Check the numbering against the revision you are being audited to, because it moved. In the 2013 edition, management of technical vulnerabilities was 12.6.1, and testing was split across two controls in the 14.2 family. The 2022 edition consolidated and renumbered. A template, blog post or GRC tool built for 2013 will cite numbers your auditor no longer uses, so if you ever see a mismatch, go by the control title rather than the digits.
Here's what those two controls are for. Control 8.8 is about obtaining information on vulnerabilities in the systems you use, working out your exposure, and taking action. It does not name a technique, an interval, or a tester. A vulnerability scanner, a dependency alert feed, a bug bounty and an external pen test are all ways to feed it, and most organisations use more than one.
Control 8.29 is about testing security during development and before something goes into production. It points at your release process rather than at an annual event. A test run once a year against prod does not satisfy 8.29 on its own, and 8.29 is not satisfied by a checkbox in your pipeline that nobody reads.
Both controls describe a running process. A pen test is strong evidence inside that process. It isn't the process.
Clause 9 is where the evidence gets used
Clause 9, performance evaluation, is the part founders skip and auditors don't. It has three pieces. Clause 9.1 covers monitoring, measurement, analysis and evaluation: you decide what to measure about your ISMS, then measure it. Clause 9.2 is internal audit, run at planned intervals, by someone who is not auditing their own work. Clause 9.3 is management review, which has defined inputs and defined outputs.
A test report is an input to all three. Your internal audit asks whether control 8.8 is operating as you described it in the Statement of Applicability, and a dated report with a remediation log is the cleanest answer to that. Your management review is where someone with authority looks at the findings and decides what gets funded. If the findings never appear in a management review record, you have bought a PDF, not an ISMS artefact.
The failure mode is predictable. Buy a test, fix two of five findings, never write down why the other three were accepted. That is a clause 9 problem, and more testing does not fix it.
You are working to the 2022 revision
If you're starting now, this is settled. ISO/IEC 27001:2022 was published in October 2022, and the International Accreditation Forum set a three-year transition for existing certificates in its mandatory document IAF MD 26, ending 31 October 2025. That date has passed. 2013 certificates that weren't transitioned in time expired, and the way back is a fresh certification audit against the 2022 edition.
Accreditation bodies publish the mechanics of this for certification bodies rather than for you. UKAS's technical bulletin on the transition arrangements shows the chain: ISO writes the standard, IAF writes the transition rules, a national accreditation body assesses your certification body, and your certification body audits you. Nobody in that chain requires a penetration test. Your auditor can still find your evidence for 8.8 inadequate, which is the part that costs you time.
What auditors expect in practice
For an internet-facing SaaS product, expect your certification auditor to want some technical testing done by someone other than the developer who wrote the code. Not because a clause says so. Because the alternative is you claiming your exposure was evaluated with nothing to show for it. What they look for:
- Scope that matches the ISMS. If your certificate scope is the product and its hosting, the product should be tested. A test of your marketing site is not evidence about your application.
- Independence. Someone outside the team that built it. There is no accreditation requirement for the tester under ISO 27001, unlike CREST or CHECK in some UK contracts.
- A defined method. OWASP-based testing is easy to describe in a procedure and easy for an auditor to recognise.
- Findings tracked to a decision. Fixed, or formally accepted with a risk owner attached. Clause 6.1.3 asks for risk owners' approval of the treatment plan, so an accepted finding with a name against it is a legitimate outcome.
- A stated cadence that you actually follow. Whatever interval you wrote into your own procedure is the interval you will be audited against. Write down something you will keep doing.
That last one catches people. ISO sets no frequency, so you set it, and then it is a requirement with your signature on it. Annual is the usual choice. Quarterly sounds impressive in a policy document and produces a nonconformity in month seven.
ISO 27001 or SOC 2, and why your buyer asked for this one
They're different kinds of thing. ISO 27001 is a certification: an accredited certification body audits your management system and issues a certificate with a defined scope, valid for a period with surveillance audits in between. SOC 2 is an attestation: a CPA firm reports an opinion on your controls, and the deliverable is a report you hand to a customer, not a certificate you put on a website.
That's most of why the ask splits by geography. SOC 2 is an AICPA framework and US enterprise procurement grew up around it. ISO 27001 is an international standard with a national accreditation infrastructure behind it, so European and Asian buyers, and most public-sector-adjacent procurement outside the US, tend to ask for the certificate. If a German or Japanese enterprise sent you a form asking for ISO 27001, offering a SOC 2 report instead is a conversation, not an answer.
The testing expectations end up in the same place, though. SOC 2 names penetration testing in its criteria as one way to monitor controls. ISO 27001 doesn't name it anywhere and still ends up wanting the same artefact. If you're doing both, one external test of the same scope feeds both files. It's the cheapest part of either project.