ISO 27001 Annex A control 8.8, management of technical vulnerabilities, requires you to identify, assess and address technical vulnerabilities in your systems. Penetration testing is one of the strongest ways to satisfy it, because it actively finds and proves exploitable vulnerabilities rather than just listing them, and it produces the evidence auditors want to see that the control is genuinely operating.
What Annex A 8.8 requires
Annex A 8.8 in ISO 27001:2022 is titled management of technical vulnerabilities. In plain terms, it requires an organisation to obtain information about the technical vulnerabilities in the systems it uses, assess its exposure to them, and take appropriate action to address the risk. It is one of the technological controls, and it sits at the heart of practical security, because unmanaged technical vulnerabilities are how a great many breaches happen.
The control does not prescribe exactly how you must find and address vulnerabilities. It sets the expectation that you do so systematically. That leaves room for different approaches, and it is where penetration testing earns its place.
Why vulnerability management is central
Technical vulnerabilities are the raw material of most attacks. An unpatched service, a misconfiguration, a flaw in a web application, these are the openings attackers look for. Annex A 8.8 exists because managing them is fundamental, not optional. An organisation that does not systematically find and address its vulnerabilities is leaving open exactly the doors attackers use.
For an auditor, this control is one where the difference between paper and practice is stark. A policy saying you manage vulnerabilities means little without evidence that you actually find and address them. That evidence is what penetration testing provides.
How penetration testing satisfies the control
Penetration testing directly supports Annex A 8.8 by doing what the control asks, and more. Where a vulnerability scan lists potential weaknesses, a penetration test goes further: it actively attempts to exploit them, proving which are genuinely dangerous and which are not. That means you are not just aware of vulnerabilities, you understand your real exposure to them, which is precisely what the control expects.
A penetration test also produces exactly the kind of evidence an auditor values. A dated report, showing what was tested, what was found, how serious each finding was, and, importantly, what was done to address it, demonstrates the full cycle the control describes: identify, assess, and act. When paired with retesting that confirms fixes worked, it shows the control operating end to end.
Where scanning fits alongside testing
This is not to dismiss vulnerability scanning, which also supports Annex A 8.8. Regular automated scanning provides broad, frequent coverage and catches known issues quickly, which is valuable for ongoing vulnerability management. The strongest approach uses both: scanning for continuous breadth, and penetration testing for depth and proof of real exposure.
Together they satisfy the control convincingly. Scanning shows you are continuously watching for vulnerabilities, and testing shows you understand and address the ones that actually matter.
Getting the evidence right
To make penetration testing count for Annex A 8.8, the evidence needs to close the loop. A report that identifies vulnerabilities is a start, but the control is about managing them, so the record should also show that findings were assessed, prioritised and remediated, and ideally retested. An auditor wants to see not just that you found problems, but that you acted on them. A good testing programme is structured to produce that complete picture.
The frequency also matters. Testing once and never again does not demonstrate ongoing management. Regular testing, appropriate to your risk and rate of change, shows the control operating continuously rather than as a one-off.
The cross-benefit
There is a practical bonus here. Penetration testing you undertake to satisfy Annex A 8.8 also genuinely improves your security, and it supports other requirements too, from risk assessment to secure development. It is one of those cases where doing the compliance thing properly and doing the security thing properly are the same activity, which is exactly how ISO 27001 is meant to work.
If you want penetration testing that satisfies Annex A 8.8 and produces audit-ready evidence, our penetration testing services deliver both the testing and the reporting, and our virtual CISO services can integrate it into your wider ISMS.
For the standard, see the official ISO/IEC 27001 page.
Frequently asked questions
What is ISO 27001 Annex A 8.8?
Annex A 8.8, management of technical vulnerabilities, requires you to obtain information about technical vulnerabilities in your systems, assess your exposure, and take appropriate action to address the risk. It is a technological control central to practical security.
Does ISO 27001 require penetration testing?
ISO 27001 does not explicitly mandate penetration testing, but Annex A 8.8 requires systematic management of technical vulnerabilities, and penetration testing is one of the strongest ways to satisfy it. It actively proves exploitable vulnerabilities and produces the evidence auditors expect.
How does penetration testing satisfy Annex A 8.8?
It identifies and actively exploits vulnerabilities to prove real exposure, then produces a dated report showing what was found, how serious it was, and what was done about it. Paired with retesting, it demonstrates the full identify, assess and act cycle the control describes.
Is scanning enough, or do you need testing too?
Scanning supports Annex A 8.8 by providing broad, frequent coverage of known issues, but it does not prove real exposure. The strongest approach uses both: scanning for continuous breadth and penetration testing for depth and proof, which together satisfy the control convincingly.
