ISO 27001 does not contain the phrase "penetration testing". This surprises people who have been told the standard requires it, and it leads a certain number of organizations to conclude they can skip it.
That conclusion is usually wrong, for reasons that have to do with how the standard actually works.
A Risk-Based Standard
ISO 27001 specifies a management system rather than a control checklist. You assess risk, you select and apply controls proportionate to it, and you demonstrate that the whole arrangement operates and improves. What the standard mandates is the process; what controls you apply, and how thoroughly, follows from your own risk assessment.
That structure is why it does not name penetration testing. It also means the burden is on you: having decided your risk assessment, you must show the controls addressing those risks are effective. An auditor's question is not "did you test?" but "how do you know these controls work?"
For most organizations holding data of any consequence, the credible answer involves testing.
The Controls That Lead There
8.8 Management of technical vulnerabilities. This is the closest thing to a direct requirement. You must obtain timely information about technical vulnerabilities, evaluate exposure and take appropriate measures. Scanning covers part of this. Establishing whether a vulnerability is exploitable in your specific environment is what testing adds.
8.25 to 8.29 Secure development. Control 8.29 addresses security testing in development and acceptance, expecting that software is tested before it goes live. For an organization that builds anything, this points directly at application testing.
8.9 Configuration management. Requires configurations to be established, documented and monitored. Testing is how you verify the documented configuration is the actual one, which is frequently not the case.
5.35 Independent review of information security. Requires the approach to managing information security to be reviewed independently at planned intervals. An independent technical assessment is one of the more persuasive forms of evidence available here.
8.16 Monitoring activities. Requires networks and systems to be monitored for anomalous behavior. A test that generates activity your monitoring should catch, and does not, is direct evidence about this control.
What Auditors Actually Ask
In certification and surveillance audits, the useful preparation is anticipating four questions.
How did you determine your testing frequency and scope? The answer must come from your risk assessment. "Annually because that is what people do" is weaker than "annually plus after significant change, because our risk assessment identifies these systems as critical and our change rate is moderate."
Who performed it and were they independent? Independence from the team managing the systems matters more than any particular credential.
What did you do with the findings? This is where organizations most often struggle. A report with unaddressed high-severity findings and no documented decision is worse than no report, because it evidences awareness without action. Findings should be tracked in your risk treatment process with owners, dates and either remediation or an accepted risk with a rationale.
Can you show improvement over time? Across a three-year cycle, auditors look for a program rather than a series of unconnected tests. Findings that recur year after year suggest the management system is not working, which is the actual subject of the audit.
Scoping Sensibly
The most common scoping error is testing against the certification scope statement rather than against risk.
Your ISO 27001 scope defines what the management system covers. It is not a testing scope. A system outside the certification scope that connects to systems inside it is still a route in, and an auditor who notices that gap will ask about it under 8.8 regardless of the scope statement.
Scope your testing to the risk. If that produces a wider scope than certification, that is a good sign about your risk assessment.
For US Organizations Running Both
Many US organizations pursue ISO 27001 alongside SOC 2, typically because international customers ask for the former and domestic ones ask for the latter.
A single testing program supports both, and the efficiency is worth capturing deliberately. Ask your provider to map findings against both frameworks' control language in the same report. Neither framework prescribes testing explicitly, both effectively expect it, and both auditors want to see the same underlying thing: evidence that controls were verified rather than assumed.
The mapping matters more than it sounds. A report organized by technical finding requires the auditor to do the translation, and requires you to do it again next year. A report that already carries the mapping is a considerably easier conversation.
The Underlying Point
An organization can be certified with weak security, and some are, because certification assesses whether the management system operates rather than whether the security is good.
That is worth knowing on both sides. If you are pursuing certification, treat testing as something you do because you want to know, and let the evidence fall out of it. If you are relying on someone else's certificate, understand what it does and does not tell you, and ask what testing sits behind it.
To discuss a testing program that supports your certification, get in touch.
Frequently asked questions
Does ISO 27001 require penetration testing?
Not by name. The standard does not use the term, and no clause mandates it explicitly. What it does require is management of technical vulnerabilities under Annex A control 8.8, secure development and testing under 8.25 through 8.29, and independent review of information security under 5.35. Organizations that satisfy those without any form of security testing are rare, and auditors ask how the controls were verified.
Which Annex A controls does penetration testing support?
Principally 8.8 management of technical vulnerabilities, 8.29 security testing in development and acceptance, 8.9 configuration management, 5.35 independent review of information security and 8.16 monitoring activities. A well-written report maps its findings against these, which makes the auditor's job easier and yours considerably easier.
How often should we test for ISO 27001?
The standard is risk-based rather than prescriptive, so the answer is whatever your own risk assessment justifies and you can defend. In practice most certified organizations test annually, plus after significant change, because that is straightforward to evidence across a three-year certification cycle. If you test less often than that, be ready to explain the reasoning.
Will an auditor accept a vulnerability scan instead?
Sometimes, depending on your risk assessment and the auditor. Scanning demonstrates ongoing vulnerability management under 8.8 reasonably well. It demonstrates verification of control effectiveness less well, because it does not establish whether a control can actually be defeated. Organizations relying on scanning alone should expect the question and have an answer grounded in their risk assessment.
How does ISO 27001 relate to SOC 2 for US organizations?
They overlap substantially and serve different audiences. SOC 2 is more common in US commercial procurement, ISO 27001 in international and enterprise contexts. Many organizations pursue both, and a single penetration testing program supports both provided the report maps findings to each framework's control language. Neither prescribes testing explicitly, and both effectively expect it.