A.8.8
Management of technical vulnerabilities
ISO 27001 · ISO/IEC 27001:2022 · Last verified July 2026
Objective
Obtain information about technical vulnerabilities, evaluate exposure, and take appropriate measures.
Points of focus
- Run authenticated vulnerability scanning across infrastructure, plus dependency and container scanning in CI/CD
- Define remediation SLAs by severity and track actual closure time against them
- Prioritize by exploitability and asset criticality, not CVSS score alone
- Document exceptions with a named owner, a compensating control, and an expiration date
Implementation notes
Build the vulnerability management loop in three parts: intake, evaluation, and closure. Intake means continuous or scheduled scanning across infrastructure (authenticated where possible, since unauthenticated scans miss most real findings), dependency scanning (SCA) in the CI pipeline, and container image scanning before and after deployment. Evaluation means triaging findings by actual exploitability and the criticality of the affected asset — a critical CVE on an internal test system with no internet exposure is not the same priority as a medium-severity finding on a customer-facing API. Closure means enforcing defined SLAs by severity (commonly measured in days for critical/high and weeks for medium/low) and tracking real closure dates, not just ticket creation dates. Where a finding can't be remediated within its SLA — a vendor hasn't shipped a patch, or remediation requires a larger architectural change — document an exception with a named owner, the compensating control in place, and a review date, rather than letting it age silently. Coordinate remediation that requires production changes through your change management process (A.8.9/A.8.32) so patching doesn't bypass the same controls that govern any other deployment.
Audit tip: Pull the last two quarters of scan results next to the remediation tracker and let the auditor see the gap between finding date and closure date directly. A clean exception register with real owners and expiration dates is more convincing than a claim of zero open findings.
Evidence auditors typically request:
- Vulnerability scan reports (infrastructure, dependency/SCA, container image) covering the observation window
- Remediation SLA policy defining timeframes by severity, with a tracker showing actual closure dates against those SLAs
- Exception register listing accepted-risk findings with owner, compensating control, and review/expiration date
- Evidence of coordination with change management (A.8.9/A.8.32) for patches requiring production changes
Common gaps
- Critical findings sit open past the defined SLA with no ticket, exception, or explanation in the tracker
- Vulnerability scanning covers infrastructure but application dependencies are never scanned, so a known-vulnerable library ships to production undetected
- An exception was granted for a finding six months ago and never revisited, even though the compensating control it relied on has since changed
Cross-Framework Mapping
| Framework | Requirement | Implementation note |
|---|---|---|
| ISO 27001 | A.8.8 | This control |
| SOC 2 | CC7.1 | CC7.1 requires the entity to use detection and monitoring procedures to identify vulnerabilities — SOC 2 examiners typically sample the same scan reports and remediation tickets an ISO 27001 assessor would request for A.8.8. |
| GDPR | Article 32 | Article 32(1)(d) requires a process for regularly testing and evaluating the effectiveness of technical security measures — vulnerability management is one of the clearest ways to demonstrate this obligation is operating, not just documented. |
Primary sources
- ISO/IEC 27001:2022 Annex A: ISO/IEC 27001:2022 Annex A (A.8.8)