Search the entire text of ISO/IEC 27001:2022 and you won't find the phrase "penetration testing" anywhere in it. That surprises most people going through certification for the first time, usually right after their auditor asks for a pentest report they don't have.
Here's what the standard actually says, and why "it's not explicitly required" doesn't mean what people think it means.
What ISO 27001 actually says
ISO 27001 is a risk-based standard. It doesn't hand you a checklist of specific technical activities. It asks you to identify your information security risks, pick controls to address them from Annex A, document that selection in your Statement of Applicability, and then prove those controls actually work.
Two Annex A controls are where penetration testing comes in:
A.8.8, Management of technical vulnerabilities. This control requires you to get information about technical vulnerabilities in your systems in a timely way, evaluate your exposure, and take appropriate action. A penetration test is the practical way to generate that information independently, rather than relying on your own team telling the auditor everything's fine.
A.8.29, Security testing in development and acceptance. This one requires security testing throughout your development lifecycle, before you release anything and before you accept software from third parties. If you build your own product, whether that's a lending app, a payment API, or an internal admin tool, this control applies to you.
Neither control says "run a penetration test." Both are, in practice, almost impossible to evidence credibly without one.
So why do auditors ask for it anyway
Once you've marked A.8.8 and A.8.29 as applicable in your Statement of Applicability, which almost every company with internet-facing systems does, you've committed to showing those controls work. A policy document saying "we manage vulnerabilities" doesn't do that. An independent test that found real issues, and a remediation log showing you fixed them, does.
This is the gap that catches people out. They treat "not explicitly required" as "optional" and show up to their audit with nothing but a vulnerability scanner report from a free tool, or worse, nothing at all. That's a common way to walk out of a Stage 2 audit with a nonconformity.
What auditors actually want to see
A pentest report that survives an ISO 27001 audit usually has four things:
- A signed report, dated within the last 12 months, with clear scope, methodology, and the tester's qualifications. Auditors want to know a qualified person did the work, not that a scanner ran overnight.
- Findings with severity ratings, mapped to what they actually affect. A critical finding on your production payment API is a different conversation than a low-severity issue on a staging server nobody uses.
- A remediation log showing what got fixed, by whom, and when. This is the part people skip, and it's the part that matters most.
- Retest evidence confirming the fixes actually worked. A findings list from six months ago with no follow-up doesn't close the loop your auditor is looking for.
If your evidence is missing the retest, you haven't really evidenced A.8.8. You've evidenced that you found problems, not that you solved them.
The automated-scan trap
A lot of companies going through ISO 27001 for the first time get a cheap automated scan, format it nicely, and hand it over as their pentest evidence. Sometimes it gets through. Often it doesn't, because a vulnerability scanner finds outdated software versions and missing patches, and stops there.
What it won't find is a broken authorization check that lets one user see another user's data, or a business logic flaw in how your payment flow handles edge cases. Those are the findings that actually matter for A.8.29, and they only come from a person manually trying to break your application the way an attacker would. Vulnerability assessment and penetration testing, done properly, means both halves: the scan for known issues, and the manual work for everything a scanner can't see.
Timing it around your audit
Run your test with enough runway before your certification or surveillance audit to actually fix what it finds and get retested, not the week before. Six to eight weeks is a reasonable buffer for most companies. Testing the month of your audit and hoping the findings don't come up is a bet that doesn't usually pay off.
If you're also chasing SOC 2
If you're a fintech or SaaS platform selling into enterprise clients, there's a decent chance ISO 27001 isn't the only compliance conversation on your plate. SOC 2's Security criteria expects the same kind of independent testing evidence. A well-scoped pentest, with the right report structure, generally covers both asks without needing to run two separate engagements.