A.8.8
Management of technical vulnerabilities
Technological controlsCheckpoints 6Evidence 5Cases 6
Control objective
This control ensures that technical vulnerabilities in the information systems the organization uses are identified in a timely manner, assessed according to risk, and acted upon so that known weaknesses cannot be exploited. It requires a repeatable cycle that runs from maintaining an asset inventory, through collecting vulnerability information and evaluating exposure, to applying patches or mitigations, so that disclosed flaws are not left unaddressed. For vulnerabilities the organization cannot fix directly, interim mitigations and a documented risk acceptance decision should be applied together.
Key checkpoints
- Is the inventory of assets subject to vulnerability management (including hardware/software and version information) kept current?
- Are channels and owners assigned to regularly collect vulnerability information (vendor advisories, security bulletins such as CVEs, threat intelligence)?
- Are identified vulnerabilities assessed by severity/exposure/asset criticality, with remediation deadlines set per risk level?
- Are periodic vulnerability assessments (scanning, penetration testing, and so on) performed, and is remediation of findings tracked and verified?
- For vulnerabilities that cannot be patched immediately, are interim mitigations (access restriction, configuration changes, and so on) applied and residual risk accepted/recorded?
- Are patches tested and passed through change management before deployment to review impact on operational stability?
Implementation guidance
- Maintain an inventory of in-scope assets together with configuration details (OS/middleware/application/version/owner), and reflect newly introduced assets in the process so nothing is missed.
- Define vulnerability information sources (vendor notices, CVE/security advisories, CERT/threat intelligence) and make collection frequency and verification responsibility explicit.
- Prioritize remediation and deadlines using severity such as CVSS alongside evidence of active exploitation, exposure paths, asset criticality, and existing safeguards. Do not equate a score alone with actual risk.
- Validate patches to the extent feasible, deploy through change management (A.8.32), and prepare recovery. Handle urgent vulnerabilities through emergency change authority, minimum validation, monitoring, and retrospective review.
- When immediate remediation is not possible, apply mitigations such as tightened access control, service deactivation, or virtual patching, and register the residual risk in the risk management framework.
- Link periodic assessments with patch management and verify remediation. Run scans/penetration tests within authorized scope, timing, stop criteria, and operational safeguards, and track open findings and deadline compliance.
Evidence
- List of assets subject to vulnerability management and their configuration details
- Vulnerability information sources/frequency and collection records
- Vulnerability assessment (scanning/penetration test) reports and remediation plans
- Records of vulnerability remediation (patch/mitigation) and re-test results
- Mitigation and residual-risk acceptance approval records for vulnerabilities that cannot be fixed immediately
Nonconformity examples
- The asset inventory is not kept current, so some systems are excluded from vulnerability management.
- No owner or channel collects vulnerability information, so vulnerabilities disclosed long ago go unnoticed.
- Priorities and deadlines are not set because severity is not assessed, leaving high-risk vulnerabilities unaddressed for a long time.
- Remediation of findings from assessments is not tracked or verified, so unremediated conditions recur.
- Vulnerabilities that cannot be patched immediately are left without any mitigation or residual-risk acceptance decision.
- A patch is deployed without the validation and authorization required by the normal or emergency change procedure, causing an outage.