6 August 2026

ISO 27001 A.8.8 in practice: the evidence an auditor will ask for

Control A.8.8 in ISO 27001:2022 is called "management of technical vulnerabilities" and sounds harmless, right up until an auditor sits down across the table from you. That is when you discover it is one of the controls where a nonconformity is easiest to pick up, because almost every company does something here, yet few can prove it.

I have been through these conversations as an administrator and DevOps engineer preparing the technical side of an audit. I want to describe how they look from IT's perspective. A housekeeping note: I am not a certification auditor and this is not an interpretation of the standard. The samples and expectations depend on the audit scope and the auditor's method.

The auditor does not ask whether you scan

That is the first misunderstanding. People prepare for A.8.8 as if it were about showing they have a scanner. They run Trivy, the excellent free scanner from Aqua Security, present a tidy result and consider the matter closed. The auditor looks at that and asks a question from an entirely different shelf: "fine, I can see you scan. Show me what you did with the critical vulnerability this scan found on 12 March".

The difference between those two situations is the difference between owning a tool and running a process. A scanner is a tool. A.8.8 is about a process, and a process is recognised by the trace it leaves behind.

The questions that actually come up

Below is the list of questions you will hear in one form or another, and the artefact that answers each one.

How do you learn about new vulnerabilities. The auditor wants to see that you have defined sources, not that someone checks something now and then. Artefact: a description of the process naming the sources and the frequency, plus evidence that scanning actually happens on a schedule, such as a run history.

What exactly do you scan, and does it cover the inventory. Many companies fall here. They scan ten servers while the asset register lists eighteen. Artefact: the scan scope set against the asset register, with an explanation of every difference.

How do you decide what to fix first. The auditor checks whether prioritisation is a method or an accident. Artefact: a documented prioritisation rule and evidence it is applied, meaning specific vulnerabilities with an assigned priority and reasoning.

Within what time do you fix things. This is about severity-dependent deadlines, the SLA. Artefact: defined deadlines plus data showing whether they were met, including for vulnerabilities closed in the past.

What about what you did not fix. This is the question about exceptions and risk acceptances. Artefact: a register of risk acceptance decisions, each with an owner, a justification and an expiry date.

Now show me all of that for the past year. The aggregate question, which cannot be answered with the current state. Artefact: evidence for a period, meaning history, not a screenshot from today.

The common failures

Three recur most often and each stems from the same gap: there is a tool but no trace of a process.

The scans exist but there is no history. The company shows the current result and cannot prove what came before. The question about March has no answer, because the March scan was never kept.

Exceptions without a signature. A critical vulnerability has been open for six months and the "notes" field says "to be migrated". Who accepted that risk, for how long, on whose authority, is unknown. To an auditor that is not a risk acceptance, it is negligence with a comment attached.

The scan scope does not cover the inventory. The asset register says one thing, scanning covers another, and nobody can explain the difference. The auditor assumes that what you do not scan is out of control, and they are right.

What a good auditor does not expect

Contrary to popular belief, a good auditor does not expect a perfect picture. They expect a true picture with visible command of the situation. An honest register that says "we have three end-of-life systems, each with a risk owner, a deadline and an exit plan" is, in an auditor's eyes, better than a suspiciously clean list with not a single exception. The latter usually means something is being swept under the rug, and auditors sense it.

That is good news, incidentally, because it takes the pressure off pretending to be perfect. You do not need zero open vulnerabilities. You need documented control over them.

What a full set of evidence looks like

All of these artefacts together form one coherent picture of the process over a period. I built a sample evidence pack to look exactly like a set assembled for A.8.8: a report, raw data, checksums and a clearly defined period. You can download it and show it to your auditor before you buy anything, to see whether such a set answers their questions: download the sample Evidence Pack.

A.8.8 is not reduced to owning a scanner. What matters is a documented process for obtaining information, assessing exposure and taking appropriate action. A vulnerability history with dates, decisions and accountability is strong evidence that the process operates, but the audit result always depends on the full scope and evidence set.

Sources

One email a week with newly published vulnerabilities worth knowing about. No account needed.

This digest covers new vulnerabilities in general, not your servers. If you want to know which of them actually run in your infrastructure, that is what Secvalis does: it scans your machines and reports only what concerns them.