A vulnerability scan reports a low-severity issue on 2,000 internet-facing web servers. The CVSS base score is 3.1, the scanner shows no known exploit, and there is no critical data loss impact. Management asks why the finding remains in the remediation queue. Which reporting rationale best justifies continued tracking?

A vulnerability report should communicate risk, not just severity. A low-severity finding can still matter when it is present across many internet-facing web servers, because the number of reachable assets increases the chance an attacker finds a usable path. The analyst tracks and communicates it so remediation, compensating controls, or formal risk acceptance can be applied to the whole population. A finding with a high impact subscore despite its base score is not the right reason here, because the scenario describes low severity and no critical data loss impact; impact is already reflected in the score. A scanner escalating all internet-facing web server findings to high severity is also wrong, because scanner severity is based on CVSS or configured environmental metrics, not a blanket web-server rule. A policy requiring immediate remediation of every low-severity finding regardless of exposure is wrong too, because remediation timing should depend on risk, exposure, exploitability, and business impact rather than a fixed rule. Exam caveat: do not equate CVSS base score with real-world priority; asset count, exposure, and context change the answer. Operational check: in the ticket, list affected asset count, internet exposure, compensating controls, and recommended SLA before closing or accepting the risk.