ISO 27001 Annex A 8.8

Vulnerabilities are exploited far faster than most organisations patch them.

ISO 27001 Annex A 8.8 - Management of Technical Vulnerabilities

Vulnerability management has three parts: knowing what you have (asset inventory), knowing what's wrong with it (vulnerability identification), and fixing what matters (remediation). The control asks for all three to operate as a continuous process rather than as occasional projects. Time-to-patch on critical vulnerabilities is one of the strongest indicators of a working ISMS.

Vulnerability identification combines vulnerability scanning (regular automated checks against the estate), threat intelligence (alerts about new vulnerabilities affecting products in use), and penetration testing (deeper assessment of security posture). Each contributes a different view of where the organisation is exposed.

Remediation requires prioritisation. Not every vulnerability needs immediate attention - some are theoretical, some affect components not actually exposed, some have low exploitability. The patching schedule should reflect the actual risk: critical and exposed gets fast action, lower-risk gets routine handling, and the prioritisation logic should be documented.

The hardest part of vulnerability management is the boring part - keeping the inventory current, running the scans on schedule, reviewing the output, and tracking the remediation through to closure. Most failures are not failures of capability but failures of consistent execution. Calendar-driven cycles and clear ownership keep the process going.

The audit looks at vulnerabilities older than the policy SLA - vulnerabilities that should have been remediated by now but have not been. Each one is a potential nonconformity, and the explanation tends to involve the same patterns: lost ownership, exception that was never reviewed, system that nobody wants to touch. The fix is back to inventory and ownership.

Practical Compliance Guidance

Vulnerability management is described in the IMS1 manual at section 8.3 on IT equipment alongside the wider information security arrangements. Vulnerability scan reports and patch records provide the operational evidence.

alphaZ document How to use it
ISO 27001 Toolkit The full alphaZ ISO 27001 toolkit covering manual, policies, procedures, registers and audit checklists.
PP-8-100 Information Security Policy Procedure Contains the Information Security Policy including the vulnerability management requirements and patching SLAs. Use as the source for the governance framework.

Note - all the above files can be downloaded with an alphaZ subscription.

Frequently Asked Questions

The SLA depends on severity. Critical vulnerabilities exposed to the internet typically need action within days. High-severity vulnerabilities on internal systems may have a 30-day window. Medium and low severity follow standard patching cycles. The exact SLAs should be set in the policy and tracked through to closure.
For most organisations, yes - automated scanning of internal and external systems gives the visibility needed to manage vulnerabilities at scale. Smaller organisations may rely on patch management reports and threat intelligence. The choice should be deliberate and documented in the SoA.
Penetration testing complements scanning by finding the issues automated tools miss, particularly in custom applications. Most organisations test annually or after significant changes. The output feeds into the vulnerability management cycle alongside scanning results.

Further Resources

payment logos