Zum Hauptinhalt springen
Annex A · Technological Control

A.8.8 — Management of Technical Vulnerabilities

Updated on 4 min Reviewed by: Cenedril Editorial
A.8.8 ISO 27001ISO 27002BSI OPS.1.1.3

A critical vulnerability in a widely used library is disclosed on Monday. By Wednesday, exploit code is publicly available. Organizations that patch within 72 hours are safe; those that take three weeks become victims. A.8.8 requires a systematic process for discovering, evaluating and remediating technical vulnerabilities — before attackers exploit them.

Vulnerability management is a continuous cycle: discover, prioritize, remediate, verify. The control expects organizations to maintain an up-to-date asset inventory, actively monitor for vulnerabilities and apply patches or compensating controls within defined timeframes.

What does the standard require?

  • Maintain an asset inventory. You cannot patch what you do not know exists. Keep a current inventory of all hardware and software, including versions.
  • Monitor vulnerability sources. Subscribe to vendor advisories, CVE databases and threat intelligence feeds to learn about new vulnerabilities promptly.
  • Assess risk. Evaluate each vulnerability in the context of your environment: is the affected system internet-facing? Does it process sensitive data? Is exploit code available?
  • Remediate within defined timeframes. Apply patches, updates or compensating controls based on the severity and exposure of the vulnerability.
  • Verify remediation. Confirm that patches were applied successfully and that the vulnerability is no longer exploitable.
  • Document everything. Record discovered vulnerabilities, risk assessments, remediation actions and verification results.

In practice

Run regular vulnerability scans. Scan your entire environment at least monthly. Critical systems and internet-facing assets should be scanned weekly. Use authenticated scans for accurate results.

Define remediation SLAs. Critical: 72 hours. High: 14 days. Medium: 30 days. Low: 90 days. Adapt these to your risk appetite, but document them and enforce them consistently.

Integrate with change management. Patches are changes. Route them through your change management process (A.8.32), but use expedited procedures for critical patches. A three-week change advisory board cycle is too slow for actively exploited vulnerabilities.

Track metrics and trends. Monitor the number of open vulnerabilities by severity, the percentage remediated within SLA and the average age of open findings. These metrics tell you whether your process is effective.

Typical audit evidence

Auditors typically expect the following evidence for A.8.8:

KPI

Percentage of critical vulnerabilities remediated within defined SLA timeframe

Measured as a percentage: how many critical vulnerabilities were patched or mitigated within 72 hours of discovery? Target: 95% or higher.

Supplementary KPIs:

  • Total number of open vulnerabilities by severity (trend over time)
  • Mean time to remediate by severity level
  • Percentage of assets covered by regular vulnerability scanning (target: 100%)

BSI IT-Grundschutz

A.8.8 maps to BSI modules for patch and vulnerability management:

  • OPS.1.1.3 (Patch and Change Management) — the core module. Requires a documented process for identifying, evaluating and applying patches, including emergency patches.
  • DER.1 (Detection of Security Events) — vulnerability monitoring as an input to security event detection.

Sources

Frequently asked questions

How quickly must critical vulnerabilities be patched?

ISO 27001 does not specify a timeframe, but common practice is: critical within 72 hours, high within 14 days, medium within 30 days, low within 90 days. Define your own SLAs based on risk appetite and document them.

What if a patch is not available?

Apply compensating controls: network segmentation to isolate the vulnerable system, additional monitoring, disabling the affected feature, virtual patching through a WAF or IPS. Document the risk acceptance and the compensating measures.

Do we need penetration testing for A.8.8?

Penetration testing is not explicitly required by A.8.8, but it complements vulnerability scanning by finding issues that automated scanners miss. Annual penetration tests are standard practice and often expected by auditors.