8.8 Management of technical vulnerabilities

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.

Source: ISO/IEC 27002:2022, 8.8. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open ISO/IEC 27002:2022 in the compliance library.

ISO/IEC 27002 is guidance on the Annex A controls; certification is against ISO/IEC 27001. Use this set when your sheet follows the 27002 numbering.