On this page
Heading into an ISO 27001 audit? Run the free scan at scan.sumrite.com for a first look, then build the A.8.8 evidence your auditor will ask to see.
ISO 27001 does not read like a checklist of tests. It is a management-system standard: it asks you to run a process and prove it works. Control A.8.8 is where that philosophy meets penetration testing, and it is one of the controls auditors probe hardest, because the evidence is concrete and easy to check.
What A.8.8 actually says
In the 2022 revision, Annex A was restructured into 93 controls across four themes. A.8.8 sits in the Technological theme and is titled Management of technical vulnerabilities. Its intent is straightforward: information about technical vulnerabilities of the information systems in use should be obtained, the organisation’s exposure evaluated, and appropriate measures taken.
The supporting guidance in ISO/IEC 27002 fills in what “appropriate measures” looks like: maintain an asset inventory so you know what to assess, define roles and responsibilities for vulnerability management, obtain timely information about vulnerabilities, evaluate and prioritise them, and then patch, mitigate or formally accept the risk. Testing is how you obtain the information about your own systems rather than just about software in general.
Why this means VAPT in practice
The control asks three things of you, and testing answers each:
| A.8.8 expects you to… | How VAPT provides it |
|---|---|
| Know your technical vulnerabilities | Vulnerability scanning for breadth; penetration testing for the exploitable, chained and business-logic issues scanners miss |
| Evaluate your exposure | A penetration test shows what an attacker could actually reach, so findings are risk-rated by real impact, not just CVSS in isolation |
| Take suitable measures | The report gives specific, prioritised fixes; the retest proves they worked |
A clean vulnerability scan on its own rarely satisfies an experienced auditor for systems that matter, because it does not demonstrate that you understand your real exposure. Our explainer on VAPT vs a vulnerability scan covers why the two are not interchangeable.
What the auditor looks for
- A documented technical vulnerability management process, owned by a named role
- An asset inventory that defines what is in scope
- Vulnerability scan results on a regular cadence
- Penetration test reports for key internet-facing and critical systems
- A risk-rated register of findings, prioritised by exposure
- Remediation records: owner, action, date, and the decision where a risk is accepted
- Evidence of retesting, closing the loop on high and critical findings
- A cadence that your risk assessment justifies
The theme running through all of this is the management cycle. An auditor is not impressed by one penetration test from eighteen months ago. They want to see that you find vulnerabilities, act on them, and check the action worked, repeatedly.
A.8.8 rarely travels alone
Testing evidence usually supports several 2022 controls at once: A.8.9 (configuration management), A.8.25 to A.8.29 (secure development, security testing in development and acceptance) and A.5.7 (threat intelligence). Map one engagement to all the controls it touches so you are not buying separate tests for each.
How often should you test?
The standard deliberately avoids a fixed number, because the right cadence depends on your risk. A defensible baseline for most organisations:
- Vulnerability scanning: regularly and continuously for internet-facing assets.
- Penetration testing: at least annually for key systems, and before major releases or infrastructure changes.
- After change: a focused test whenever something significant goes live.
Write the cadence into your vulnerability management procedure and justify it from your risk assessment. That written rationale is itself evidence for the audit.
A practical path to A.8.8 evidence
- Document the process. Write the vulnerability management procedure: scope, roles, cadence, scoring method and remediation timelines by severity.
- Scan continuously. Stand up regular scanning across your estate for breadth and early warning.
- Penetration test the systems that matter. Internet-facing applications, APIs and infrastructure, scoped from your asset inventory.
- Risk-rate and assign. Put findings in a register, prioritise by real exposure, and assign owners and dates.
- Remediate and retest. Fix, then retest high and critical issues and record the closure.
- Review and repeat. Feed results into management review, and run the cycle on your defined cadence.
How Summit helps
Summit runs the testing that evidences A.8.8: web application, API and network penetration testing, with source code review where development controls are in scope. Every engagement comes with risk-rated findings, specific fixes, a retest and reporting you can drop straight into your ISMS evidence. Our ISO 27001 compliance page explains how we run the engagement alongside your certification. Start with the free check at scan.sumrite.com.
Turn testing into audit-ready A.8.8 evidence
Tell us your scope and audit date. We will run the testing and give you findings, fixes and retests mapped to A.8.8. Get a quote or run the free scan first.
Related reading: ISO 27001 VAPT audit · VAPT vs a vulnerability scan · Which compliance frameworks require penetration testing?
Frequently asked questions
What is ISO 27001 control A.8.8?
Annex A control 8.8 of ISO/IEC 27001:2022, 'Management of technical vulnerabilities'. It requires an organisation to obtain information about the technical vulnerabilities of its information systems, evaluate its exposure, and take suitable measures such as patching, mitigating or accepting the risk.
Does ISO 27001 require penetration testing?
Not by that exact word, but A.8.8 requires you to identify technical vulnerabilities and act on them, and the supporting guidance points to testing. Vulnerability scanning and penetration testing are the normal ways organisations generate the evidence, and most auditors expect to see them.
How often should we test for ISO 27001?
The standard does not fix an interval. Common practice is regular vulnerability scanning, at least annual penetration testing of key systems, and testing after significant changes, with the cadence justified by your risk assessment.
What evidence does an ISO 27001 auditor want for A.8.8?
A documented vulnerability management process, an asset inventory, scan and penetration test reports, a risk-rated register of findings, remediation records with owners and dates, and evidence of retesting. The auditor checks that the cycle runs, not just that one test happened.
Which 2022 controls relate to A.8.8?
A.8.8 (technical vulnerabilities) works with A.8.9 (configuration management), A.8.25 to A.8.29 (secure development and testing) and A.5.7 (threat intelligence). Testing evidence often supports several of these at once.
How do we start?
Run Summit's free scan at scan.sumrite.com for a first look, then set up scanning and penetration testing mapped to A.8.8 with findings tracked to closure.
Faisal Khan is a Director at Summit, where he oversees penetration testing, risk assessment and compliance engagements for SaaS and enterprise clients. Case studies are anonymised and published with client permission.
