Management of technical vulnerabilities

What the requirement asks

The organization is to gather information about technical vulnerabilities in the information systems it uses, assess how exposed it is, and take suitable action. Purpose: prevent technical vulnerabilities from being exploited. Identifying vulnerabilities: an accurate asset inventory (5.9 to 5.14) is a precondition, recording software vendor, name, versions, where it is deployed and who is responsible. Consider defining roles for vulnerability monitoring, risk assessment, updating, asset tracking and coordination; identifying and maintaining the information sources used to learn of vulnerabilities in the inventoried technologies; requiring system and component suppliers to report, handle and disclose vulnerabilities, including through contracts (5.20); scanning with tools suited to the technologies in use, also to confirm patches worked; penetration testing or vulnerability assessment that is planned, documented and repeatable and done by competent, authorized testers, with care since they can compromise systems; and tracking vulnerabilities in third-party libraries and source code as part of secure coding (8.28). Build capabilities to detect vulnerabilities in the organization's own products and services, including external components, and to receive reports from inside and outside; publish a public contact point under a vulnerability disclosure policy, with reporting procedures, online forms and use of threat intelligence or sharing forums; consider bug bounty programmes; and share information with competent industry bodies. Evaluating: analyse and verify reports to decide the response, then determine risks and actions such as updating systems or applying other controls. Acting: run a software update management process so approved current patches are installed on all authorized software; keep original software when changes are needed and apply them to a designated copy, fully tested and documented for future upgrades, with independent validation if required. Act promptly and within a defined reaction timeline; route actions through change management (8.32) or incident response (5.26) according to urgency; use updates only from legitimate sources; test and evaluate updates first, weighing the risk of the vulnerability against the risk of installing the update; deal with high-risk systems first; develop remediation, test that it works and provide ways to verify its authenticity; and where no update exists or it cannot be installed, apply vendor workarounds, disable affected services, add or adjust access controls at network borders (8.20 to 8.22), shield systems with traffic filtering (virtual patching), increase monitoring for attacks and raise awareness. Decide whether to use vendors' automatic updates. Keep an audit log of every step, monitor and evaluate the process regularly, and align it with incident management. For cloud services, the provider manages vulnerabilities in its own resources under the service agreement with reporting of its actions (5.23), while the customer handles its own assets. Other information: vulnerability management is a sub-function of change management; updates can fail or be hard to reverse, so where testing is not feasible a delay informed by others' experience may be considered; scanners can misreport where layered countermeasures mask each other; suppliers of products should publish advisories and remediation; ISO/IEC 19086, 27017, 29147 and 30111 give more. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

Vulnerability management is a loop. The guidance asks for the scan, the triage, the fix, the exception and the verification.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep A software asset inventory with vendor, product, version, deployment location and responsible owner and one live sample together.

Evidence an assessor asks for

• Vulnerability identificationA software asset inventory with vendor, product, version, deployment location and responsible owner
• Vulnerability identificationDefined vulnerability management roles and a list of monitored vulnerability information sources
• Vulnerability identificationAuthenticated scan results and penetration test reports by authorized testers, with verification scans after patching
• Vulnerability identificationRemediation timelines by severity with measured performance, and risk records weighing the vulnerability against update risk
• Vulnerability identificationRecords of compensating measures such as workarounds, service disablement, virtual patching or added monitoring where no patch exists
• Vulnerability identificationA public vulnerability disclosure contact and procedure, and cloud provider agreements defining their vulnerability responsibilities and reporting

The question an assessor will ask

An assessor will ask for A software asset inventory with vendor, product, version, deployment location and responsible owner, then trace it to the system it protects. For A.8.8 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common gaps

• The asset inventory is incomplete, so unknown software is never scanned or patched
• Remediation timelines are routinely missed with no risk acceptance
• Third-party libraries in in-house code are not tracked for vulnerabilities
• There is no way for external researchers to report vulnerabilities

Before the next audit

Before the next audit, check one live sample for this gap: the asset inventory is incomplete, so unknown software is never scanned or patched.