A.8.8 ISO 27001

ISO 27001 A.8.8: Management of technical vulnerabilities

What This Control Requires

Information about technical vulnerabilities of information systems in use shall be obtained in a timely fashion, the organization's exposure to such vulnerabilities shall be evaluated and appropriate measures shall be taken.

In Plain Language

New vulnerabilities are discovered every single day, and the window between public disclosure and active exploitation keeps shrinking. If you are not systematically finding and fixing vulnerabilities in your environment, attackers will find them for you.

You need a continuous process: identify what is vulnerable, assess how badly it affects you, prioritise based on real risk, patch or mitigate within defined timeframes, and verify the fix worked. This is not a quarterly exercise - it is an ongoing operational discipline.

This covers everything in your environment: operating systems, applications, firmware, network devices, cloud configurations, and third-party components. It requires tight coordination between security, sysadmins, and developers to fix things without breaking things.

How to Implement

Build a vulnerability management programme with clear phases: discovery, assessment, prioritisation, remediation, and verification.

For discovery: deploy vulnerability scanning tools that cover your entire asset inventory. Scan internet-facing assets at least weekly and internal assets monthly. Run both authenticated and unauthenticated scans. Subscribe to security advisories from every vendor you use. Monitor CVE databases and threat intelligence feeds.

For assessment and prioritisation: do not just sort by CVSS score and call it a day. Factor in whether the vulnerability is being actively exploited in the wild, whether the affected system is internet-facing, what data sits on that system, whether you have compensating controls, and how easy it is to exploit. A medium-severity vulnerability on your public-facing API can be more urgent than a critical one on an air-gapped test server.

Set remediation SLAs by risk level. A reasonable starting point: critical vulnerabilities (actively exploited, internet-facing) within 24-48 hours, high within 7-14 days, medium within 30 days, low within 90 days. Adjust to fit your operational reality, but make sure the SLAs have teeth.

For remediation: patch first, always. When patching is not immediately possible, deploy compensating controls like network segmentation, application-level restrictions, or IPS signatures. Document any accepted risk for vulnerabilities that miss SLA deadlines and get explicit management sign-off.

For verification: re-scan after every remediation to confirm the fix actually worked. Track metrics - open vulnerabilities by severity, average time to remediate, patch compliance rates, trends over time. Report these to management regularly. If the numbers are not improving, something in the process is broken.

Tie vulnerability management into your other processes. Feed findings into risk assessments. Coordinate patching through change management. Bake vulnerability scanning into your CI/CD pipeline so developers catch issues before production.

Evidence Your Auditor Will Request

Documented vulnerability management policy with defined SLAs
Vulnerability scanning tool deployment and scan schedule records
Vulnerability assessment and prioritization records
Patch compliance reports showing remediation within SLA timeframes
Metrics and trend reports on vulnerability management effectiveness

Common Mistakes

Vulnerability scanning is not conducted regularly or does not cover all assets
Vulnerabilities are identified but remediation is not tracked or enforced within SLAs
Critical vulnerabilities on internet-facing systems are not addressed promptly
No process for applying compensating controls when patches cannot be deployed
Vulnerability management does not cover cloud configurations and third-party components

Related Controls Across Frameworks

Framework	Control ID	Relationship
SOC 2	CC7.1	Equivalent
GDPR	Art.32	Related
NIS2	Art.21(2)(d)	Related
NIS2	Art.21(2)(e)	Partial overlap

Frequently Asked Questions

How quickly should we patch critical vulnerabilities?

If it is actively exploited and internet-facing, 24-48 hours. That is not a typo. For critical vulnerabilities not yet being exploited in the wild, 7 days is a reasonable target. The decision factors are: is exploitation happening right now, is the system reachable from the internet, and what is the blast radius if it gets compromised. When you genuinely cannot patch that fast, get compensating controls in place immediately and document why the delay is necessary.

What tools do we need for vulnerability management?

At minimum you need an infrastructure vulnerability scanner (Nessus, Qualys, or Rapid7), a DAST tool for web applications, a software composition analysis tool for dependency scanning, and a patch management tool. If you are running cloud infrastructure, add a cloud security posture management (CSPM) tool. Ideally these all feed into a centralised platform for tracking and reporting, so you are not juggling spreadsheets across five different tools.

Track ISO 27001 compliance in one place

AuditFront helps you manage every ISO 27001 control, collect evidence, and stay audit-ready.

Start Free Assessment