ISO 27001 A.8.8: what auditors ask to see

ISO 27001 A.8.8 — management of technical vulnerabilities — is one of the shortest controls in Annex A and one of the most commonly failed. It asks for three things and takes about four lines to do it. The distance between reading it and passing an audit against it is almost entirely a question of evidence.

What the control actually says

The 2022 revision restructured Annex A into four themes — organizational, people, physical, technological — and consolidated 114 controls into 93. A.8.8 lives in the technological theme and merges what used to be A.12.6.1 and A.18.2.3. It requires that you obtain information about technical vulnerabilities in the systems you use, evaluate your exposure to them, and take appropriate measures.

Three verbs: obtain, evaluate, act. ISO/IEC 27002:2022 carries the implementation guidance — defined roles, identified information sources, a timeline for reacting, and a documented handoff into change management. The certification standard tells you what, the guidance standard tells you roughly how, and neither tells you what your auditor will actually open.

The dependency nobody writes down

You cannot evaluate exposure to a vulnerability on an asset you did not know you had. A.8.8 quietly rests on A.5.9, the inventory of information and other associated assets, and that dependency is where a surprising share of findings originate. An inventory maintained by hand drifts inside a quarter: a subdomain stood up for a campaign, a staging box rebuilt without its security group, an acquired team's estate that never got merged in.

An auditor testing A.8.8 seriously does not start with your patch policy. They pick an asset that appears in your cloud bill and does not appear in your inventory, and ask what the vulnerability process is doing about it.

What an auditor asks to see

1. Remediation timelines defined by severity, in a document with an owner and a review date. "Promptly" is not a timeline.
2. Evidence you met them — first-seen and closed dates, per finding, across the whole audit period. A screenshot of today's dashboard shows today.
3. Exceptions as explicit risk acceptances, with a named approver and an expiry date, rather than findings that quietly aged out of the queue.
4. Coverage — that the scanning reached everything in scope, and that you can say what it did not reach and why.

None of that is satisfied by an annual penetration test. A test is real assurance evidence and maps neatly onto the evaluate step, but it produces a point-in-time report where the control describes an ongoing process — and the gap between tests is where the estate changes.

Conclusion

A.8.8 is not a difficult control to satisfy. It is an easy one to fail, because the policy takes an afternoon to write and the record is the one artefact you cannot produce retroactively the week before the audit. Whatever you scan with should be recording first-seen and last-seen per finding starting now; that record is the control.

CyberSpec maps findings to the Annex A controls they break, alongside SOC 2 and PCI DSS — see compliance mapping or how findings are tracked over time. The neighbouring question, what "logical access" means to a different auditor, is in the CC6.1 writeup.