ISO 27001 Annex A 8.8 — What Evidence Does It Actually Require?
Reviewed: 24 August 2026 — reviewed quarterly
Quick Answer
Annex A 8.8 of ISO/IEC 27001:2022 requires an organisation to obtain information about technical vulnerabilities in its systems, evaluate its exposure, and take appropriate measures. Auditors typically look for a documented process, evidence of testing performed at a defined frequency by a competent party, and records showing what was remediated. A 8.29 is a separate control and requires more.
What Does Annex A.8.8 Actually Say?
Annex A.8.8, "Management of technical vulnerabilities", asks an organisation to do three things on an ongoing basis: obtain timely information about technical vulnerabilities affecting its information systems, evaluate the organisation's exposure to those vulnerabilities, and take appropriate measures to address the risk they present. It is written as a continuous process control, not a one-time test requirement — the standard is asking whether vulnerability management is something your organisation does routinely, not whether you can produce a single report on request.
In practice, an auditor assessing this control is trying to answer three questions: is there a defined process for finding out about vulnerabilities (through scanning, testing, vendor advisories, or a combination); is that process actually followed on a schedule you can describe and justify; and is there a record of what happened after a vulnerability was identified — was it triaged, was it remediated, and how quickly.
What Evidence Do Auditors Accept?
No single document satisfies this control on its own. Auditors are typically looking for a combination of the four items below.
| Type of evidence | What this looks like in practice | Who produces it |
|---|---|---|
| Documented vulnerability management process | A written procedure describing how vulnerabilities are identified, triaged and remediated, with an owner and a review cadence | Internal — written by the organisation |
| Independent testing report | A Vulnerability Assessment or penetration test report covering the in-scope systems, with dated findings | External tester or internal security team |
| Findings register with closure dates | A tracked list showing when each finding was identified and when it was closed, not just a point-in-time report | Internal — maintained between test cycles |
| Evidence of testing cadence | Proof that testing happens on a defined, repeated schedule — not a one-off exercise run just before the audit | Internal, cross-referenced against test reports |
How Is A.8.8 Different From A.8.29?
This is the single most common point of confusion in ISO 27001 audits involving security testing — the two controls sound similar but ask for different depth of evidence.
| Annex A.8.8 | Annex A.8.29 | |
|---|---|---|
| Control name | Management of technical vulnerabilities | Security testing in development and acceptance |
| What it's about | An ongoing process to identify and remediate vulnerabilities in systems already in operation | Testing performed as part of the development and acceptance lifecycle, before and during release |
| What typically satisfies it | Regular vulnerability scanning with manual validation of results | Testing that most auditors interpret as requiring manual penetration testing |
| Typical evidence | Vulnerability assessment report + findings closure register | Penetration test report + remediation retest |
| Our matching service | Vulnerability Assessment, €539 | Focused Pentest, from €1,800 |
How Often Does "Regular" Mean?
The standard deliberately doesn't set a fixed interval — it leaves the frequency to be justified by the organisation's own risk assessment. In practice, annual testing of externally-facing systems is the most common baseline seen in audits, with more frequent testing (quarterly or after major changes) expected for systems handling higher-risk data or exposed to greater change. The strongest position with an auditor isn't a specific number by itself — it's being able to explain why the interval you chose fits your risk profile, and showing that you actually keep to it.
Where a Vulnerability Assessment Fits — and Where It Doesn't
A vulnerability assessment — automated discovery combined with manual validation of high-severity findings — is a well-matched, cost-effective form of evidence for Annex A.8.8. It directly answers the control's three obligations: it surfaces vulnerability information, the manual validation step evaluates real exposure rather than raw scanner noise, and the report plus findings register documents what measures were taken.
It is not, on its own, sufficient evidence for Annex A.8.29. That control is generally interpreted by auditors as requiring manual exploitation attempts, not automated-plus-validation testing — for that, a penetration test for Annex A.8.29 is the correct evidence to gather.
What Auditors Most Often Flag
Evidence Checklist
Need evidence that satisfies A.8.8 specifically? Our €539 Vulnerability Assessment includes the report structure this checklist describes — see what a vulnerability assessment report contains and how the accompanying attestation letter is structured for auditors. If your requirement is Annex A.8.29 instead, see our full ISO 27001 readiness assessment.
Start with Vulnerability Assessment