Short answer: ISO 27001:2022 Annex A, control A.8.8, "Management of technical vulnerabilities" (A.12.6.1 in the 2013 edition) requires that you obtain information about technical vulnerabilities in your information systems in a timely fashion, evaluate your exposure, and take appropriate measures. For most organisations the practical core is recurring vulnerability scanning, a documented remediation process, and evidence an auditor can review — not a one-off pentest and a folder of results scanned in the week before the audit.
TL;DR
- The control is A.8.8 (2022 edition; A.12.6.1 in the 2013 edition). Auditors still accept evidence framed against either.
- What it needs: a documented procedure, recurring scans, remediation targets, and records.
- Once-a-year scanning is rarely enough. The control language points at timeliness, and most assessors treat annual scans as not timely for internet-facing systems.
- Who it's for: SMBs going for ISO 27001 for the first time, and ISMS owners who need A.8.8 to stay defensible between audits.
What the control text requires
Annex A.8.8 asks that:
- Information about technical vulnerabilities of information systems used within the organization be obtained in a timely fashion,
- The organization's exposure to such vulnerabilities be evaluated,
- Appropriate measures be taken to address the risk.
Three points in that wording matter more than people expect:
- Timeliness. A scan performed once per year — usually right before an audit — is technically "obtained" but is not timely for anything exposed to the internet. Recurring scanning is the reading auditors actually enforce.
- Evaluation. Finding a vulnerability is not the control being done. You need to show you judged whether it applies to your systems and what the exposure is — that's what a findings register with owners and severities demonstrates.
- Appropriate measures. Patching is the obvious one, but configuration changes and compensating controls count too. For "can't patch yet" situations you need a documented exception, risk assessment, and ideally a compensating measure.
What an auditor actually asks for
In practice, ISO 27001 audit evidence for A.8.8 looks like:
| Evidence | What it proves | |----------|----------------| | Documented A.8.8 process — scope, cadence, escalation path | The control is part of the documented ISMS | | Recurring scan history (weekly/monthly scans with dates) | Timeliness | | Findings register — severity, owner, due date | Evaluation | | Remediation evidence — patch version, change ticket, after-scan | Appropriate measures taken | | Approved exceptions for unpatched exposed systems | Risk evaluation where compromise couldn't be done |
Vulnerability scanning is the raw material for most of this table. It produces the open ports, exposures, and known CVEs that your team feeds into the findings register — the artifact that becomes "vulnerability found, severity assessed, fixed by patch X, verified."
A practical A.8.8 setup
1. Document the process (a paragraph of policy)
A paragraph is enough to start: scope (e.g., all externally reachable hosts you own), the scanning cadence (below), who reviews findings, remediation timeframes by severity, and how exceptions get approved. This is the control document your auditor expects before they look at a single scan.
2. Scan on a schedule, not just before the audit
Internet-exposed estates change weekly: a dev environment opened to the internet for a weekend, an admin panel someone put up last month, a VPN upgraded to a build with a known flaw. A once-a-year external scan cannot see that, and the "timely" wording is exactly what it's for.
For recurring external scanning, hosted scanning is a practical fit: VulnScanners runs Nmap, Nuclei, and OWASP ZAP on a schedule against targets you own and produces a PDF per scan — dated, severity-broken-down evidence for the audit folder. Credits are pay-per-scan and never expire, so there's no subscription to remember and no annual renewal to budget for.
Honest limitation: external scanning demonstrates timely identification and evaluation for assets reachable from the internet. It is not authenticated or internal scanning — plan that separately if your ISMS scope includes internal estates.
3. Fix remediation SLAs
The scan is only the start. The audit record is findings → triage → remediation → proof. A simple table:
| Severity | Time to triage | Time to remediate or formally except | |----------|----------------|--------------------------------------| | Critical | 24 h | 14 days | | High | 48 h | 30 days | | Medium | 7 days | 90 days | | Low / info | 30 days | At discretion |
This gives the "evaluation and action" half of the control something concrete: the register plus these SLAs is the story your auditor reads.
4. Record exceptions honestly
If a patch can't be installed yet (unsupported old appliance, vendor-dependent window), that's fine — record it, assess the risk, get it approved, and add a compensating measure if one exists (block the port, WAF rule, restrict access). An explicit, risk-assessed exception is an acceptable artifact for A.8.8. The main failure mode is an unexplained open finding recurring every cycle without a record.
Where consultants and auditors fit
The scanning evidence is one pillar of the ISMS. The management system around it — policy set, scope, risk register, internal audits, management reviews, and the Stage 1 / Stage 2 certification calendar — is where certified help pays for itself. Most organisations preparing for ISO 27001 use a consultant for the gap analysis and certification preparation, and a certification body for the audits themselves.
For that part, ISMS Directory is a curated directory of ISO 27001 consultants and auditors — a faster, more trustworthy way to find certified help than a generic web search, in the same way a scanner directory is less useful than a vetted list. Use it when you're assembling the ISMS team; use recurring scans for the A.8.8 evidence pillar.
Final TL;DR
A.8.8 boils down to: documented process + recurring scan evidence + a findings register + fixes (or approved exceptions). The scanner produces the evidence; the ISMS framework and audit capacity come from your process and — when you need it — certified help. Run the scanning part on a schedule so the timeliness requirement writes itself, and use a vetted directory like ISMS Directory when it's time to bring in the consultants.