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.
This control maps to 226 controls across 43 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
ISO 27002:2022 8.8 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of ISO 27002:2022 your existing evidence covers. Hold NIST SP 800-53 Rev 5 and 79 of 93 ISO 27002:2022 controls already carry evidence.
Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 180 were rejected on the NIST SP 800-53 Rev 5 pair alone.
The graph holds this control, the 226 it maps to, and the evidence behind each claim, over MCP and REST.