A quarterly vulnerability scan returns thousands of findings across servers, workstations and network devices. The remediation team can address only a fraction of them each month. How should the information security manager prioritize remediation?
Select an answer to reveal the explanation.
Short Explanation
When the to-do list is a mile long, you start with the jobs where a failure would actually hurt and an attacker could actually get in. That's asset criticality plus exploitability. The trap is trusting the scanner's severity score alone, because it has no idea which server runs payroll.
Full Explanation
Vulnerability remediation is risk treatment, and risk depends on both likelihood and impact. Exploitability, including whether a vulnerability is exposed, whether exploit code exists and whether it is being used in the wild, drives likelihood. Asset criticality, derived from the business processes and data the asset supports, drives impact. Combining the two directs limited remediation capacity to the findings that carry the most business risk. A scanner severity score alone is a generic technical rating that ignores the asset's importance and its exposure; a critical finding on an isolated test machine may matter less than a high finding on an internet-facing payment server. Counting findings per system rewards fixing noisy systems and says nothing about which weaknesses matter. Fixing the oldest findings first is an administrative order, not a risk-based one, and can leave new, actively exploited vulnerabilities open on critical assets. Exam caveat: severity scores remain a useful input; the error is using them as the only criterion. Operational check: confirm the remediation queue is ranked using both criticality from the asset inventory and current exploitability data, and that service-level targets are tighter for critical assets.