Insights · Compliance guide

ISO 27001 vulnerability management: what control 8.8 expects

ISO/IEC 27001:2022 handles vulnerabilities mainly in Annex A control 8.8, management of technical vulnerabilities. You do not need a specific scanner or a fixed patch deadline, but you do need a defined, repeatable process that finds weaknesses, rates them by risk, fixes or consciously accepts them, and leaves records. This guide shows what that means in practice and what auditors usually ask for.

Updated: 6 November 2026

Which edition applies today

ISO/IEC 27001:2022 was published in October 2022. According to SGS, certification bodies stopped initial and recertification audits against the 2013 edition on 30 April 2024, and the transition period ended on 31 October 2025, after which 2013 certificates are no longer valid. In November 2026, the 2022 edition is therefore the only one you can be certified against, and an organization whose 2013 certificate lapsed is treated as a new client needing a full initial audit.

The 2022 edition reorganized Annex A from 114 to 93 controls, according to NQA, and added new controls such as threat intelligence (5.7). The guidance behind the controls sits in ISO/IEC 27002:2022, the third edition of that standard, published in February 2022.

What control 8.8 covers

Control 8.8 aims to prevent the exploitation of technical vulnerabilities. It is classed as a preventive control and sits in the technological theme of Annex A. The ISO/IEC 27002 guidance behind it is advice, not a checklist: your own risk assessment decides how deep and how fast you go.

Based on common readings of the control, a working process covers the following points.

• A current inventory of assets with versions, owners and supplier details, linked to the asset register under control 5.9.
• Named roles for monitoring vulnerability information, assessing risk, patching and tracking assets.
• Ways to find weaknesses: authenticated scans, authorized penetration tests, vendor advisories and tracking of third-party libraries.
• A risk-based decision for each finding: patch, apply a workaround or compensating control, or accept the risk formally.
• Testing of fixes before rollout and verification afterwards, handled through your change process.
• Logs of each step, so you can show what happened and when.

Related controls auditors will connect

Vulnerability management rarely stands alone in an audit. Expect questions that move across neighbouring controls, because a finding in one area often points to a gap in another.

Threat intelligence (5.7) feeds the process with information on actively exploited weaknesses. Configuration management (8.9) keeps systems in a hardened, documented state, which removes many findings before a scanner sees them. Change management (8.32) governs how patches reach production. Incident response, including control 5.26, takes over when a weakness is exploited before you could fix it. NIST SP 800-40 Rev. 4 offers a useful non-ISO view of enterprise patching as routine preventive maintenance and is a sound reference for process design.

Evidence auditors typically ask for

ISO 27001 sets no mandatory evidence list, and auditors differ in style. In practice, most ask you to show that the process exists, runs, and produces decisions. The following items are commonly requested.

• A vulnerability or patch management policy and procedure with owners and a recent review date.
• The asset inventory that defines scan scope, including cloud and externally exposed systems.
• Scan reports over several months, not a single export, with proof that scans also ran after major changes.
• Remediation timelines by severity, written down and tied to your risk method, plus data showing how often you met them.
• A formal exception record for findings you cannot fix, with a justification, compensating controls, an owner and an expiry date.
• Rescan results or change tickets showing that fixes worked.
• Penetration test reports with a tracked list of resulting actions.
• Management reporting with a few KPIs, such as time to remediate by severity, share of assets scanned and number of overdue exceptions.

Setting remediation timelines

The standard does not prescribe hours or days. Many organizations publish tiers by severity, for example faster deadlines for critical issues and longer ones for low risk, and some commentators call a CVSS-based scheme of roughly two days for critical up to ninety days for low a common benchmark. Treat such numbers as an example, not a requirement.

Raw CVSS scores alone are a weak basis. Combine severity with how critical the asset is, whether it faces the internet and whether the weakness is known to be exploited. Whatever you choose, auditors mainly care that the timelines are defined, approved, applied and measured, and that misses lead to a recorded exception rather than silence.

The 2024 climate amendment

ISO/IEC 27001:2022/Amd 1:2024 was published in February 2024 and adopted in Germany as a DIN standard in November 2024. It adds climate change considerations to clauses 4.1 and 4.2: you decide whether climate change is a relevant issue for your context and consider related expectations of interested parties.

This does not change control 8.8. It only affects how you document your context, so a short note in that document is typically enough.

Where external providers help

Many teams run the process internally but buy parts of it. Managed vulnerability assessment services operate scanners on a schedule, remove false positives and deliver prioritized reports. Penetration testing providers add manual testing of applications and networks that scanners miss. Both produce dated, signed-off reports that serve directly as audit evidence.

When you request offers, state your scope, systems and cloud accounts, the testing frequency your risk assessment requires, how findings must be reported, whether retesting is included, and which certification body audits you. Also check how the provider handles access to your data and the written authorization needed for testing.