Control 8.8 requires you to obtain information about vulnerabilities in your IT systems, evaluate your exposure and take suitable action. The guidance puts it plainly: the sooner a vulnerability is removed, the lower the risk of an incident. You decide the timelines, then follow them and keep records.
What the control asks
Three things: gather vulnerability information, assess it, and define responses. The guidance gives no fixed timeframes, so the deadlines are yours to set from your risk assessment. That freedom comes with a catch. Whatever you write, an auditor will test whether you meet it.
Build the process
- Know what you run. You cannot assess exposure to a flaw in a component you have not listed.
- Subscribe to sources: manufacturers, security groups and notification services for your technologies.
- Assess each relevant item for exposure and severity in your context.
- Choose a response: fix, mitigate, accept or defer, with an owner and date.
- Verify the fix and record it.
Set your own timelines
Write a short table of target times by severity and exposure, for example faster for internet facing systems. The numbers should reflect what your team can actually deliver. A target you routinely miss becomes a finding, so start realistic and tighten later.
Technology, process, people
For technology, specialised software to assess applications and devices helps. Larger companies may need a continuous service. For process, collect information from vendors and security groups, watch notifications and define responses. For people, make staff aware of the risk reduction from early removal, and train IT staff to use the assessment tools and gather vulnerability information.
Documents
Recommended, not mandatory: security procedures for the IT department in smaller and mid sized companies, or a technical vulnerabilities management procedure in larger ones.
What the auditor checks
Evidence that relevant vulnerability information is obtained, that your exposure is evaluated, and that proper actions are taken. Prepare:
- The source list and who reads it.
- A scan or assessment report with dates.
- A ticket trail from finding to fix.
- The exceptions list, with reasons and approvals.
Where reachability helps
Most findings in dependencies are not reachable from your code. Safeguard reachability analysis shows which vulnerable functions your code can actually call, which supports a risk based order of work. Its policies and gates can enforce your timelines, and autonomous remediation with fix PRs is available but off by default, with every category on Manual.
Click through it at your own pace, or open it full screen.
Quick check
How fast must we patch to satisfy the control?
The control sets no timeframe. You define it from risk and then meet it, so the number matters less than your record of keeping to it.
Is a scanner mandatory?
The control calls for gathering and assessing vulnerability information. Software helps, and larger companies may need a continuous service, but the control does not name a tool.
Sources
Last reviewed: 19 October 2026.
