All 93 controls · Technological controls
Control 8.8
Management of technical vulnerabilities
What ISO/IEC 27002:2022 control 8.8 asks for, in our own words, with the five published attribute values, the evidence an auditor asks for and the gaps commonly found. ISO/IEC 27028 is the guidance that explains how to use these values.
What the control 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.
Purpose in the standard’s terms, in our words: Prevents exploitation of technical vulnerabilities.
Attribute values in one line: Preventive; Confidentiality, Integrity, Availability; Identify, Protect; Threat and vulnerability management; Governance and ecosystem, Protection, Defence.
The five attribute values
These are the published values for this control, from ISO/IEC 27002:2022 clause 4.2 and Annex A Table A.1. Where your own value differs, record the difference and the reason in the same row rather than replacing the published value.
| Control type | Preventive |
|---|---|
| Information security properties | ConfidentialityIntegrityAvailability |
| Cybersecurity concepts | IdentifyProtect |
| Operational capabilities | Threat and vulnerability management |
| Security domains | Governance and ecosystemProtectionDefence |
Evidence an auditor asks for
The attribute is a claim about how the control behaves. The evidence is what proves it operates. Keep both, and keep them together.
- A software asset inventory with vendor, product, version, deployment location and responsible owner
- Defined vulnerability management roles and a list of monitored vulnerability information sources
- Authenticated scan results and penetration test reports by authorized testers, with verification scans after patching
- Remediation timelines by severity with measured performance, and risk records weighing the vulnerability against update risk
- Records of compensating measures such as workarounds, service disablement, virtual patching or added monitoring where no patch exists
- A public vulnerability disclosure contact and procedure, and cloud provider agreements defining their vulnerability responsibilities and reporting
Where audits commonly find 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
What ISO/IEC 27028 changes for this control
It carries a single control type, preventive, which sets what the evidence has to prove. It contributes no detect function, so a control set built from this row alone would not show detection. Its earlier numbering (12.6.1, 18.2.3) is kept in the register so an older audit file can still be traced. It serves more than one security domain, which is why a domain count taken by row understates the view.
The guidance expands how the five values are used; it does not change the control or add a requirement. A register that carries the values and the evidence can answer the attribute question for this control without a new document. A register that does not can add the columns at the next SoA version, with an owner and a review date.
Controls that share its values
Source for this page
- ISO/IEC 27002:2022, the control catalogue and Table A.1. The reference record of the 93 controls, their five attribute values, purpose, evidence and gaps. The published standard is at https://www.iso.org/standard/75652.html.
- ISO/IEC 27028, official record. Stage 60.00 under publication, edition 1, committee, abstract and the dated lifecycle. Retrieved 20 October 2026.
Retrieved 2026-10-20. The requirement above is our statement of the clause in our own words; the official text is linked so you can check it.
The attribute kit, USD 799 one off. The 109-row register with all five values, the evidence list, a dated plan and the extension worksheet, as PDF, CSV and XLSX.