Prioritising Vulnerability Remediation Under a 14-Day SLA
Meridian Health has 1,800 servers and 6,200 endpoints. Its vulnerability scanner reports 41,000 open findings, including 12 rated CVSS 9.8. One internet-facing Apache Tomcat server runs a version listed in CISA KEV, has EPSS 0.92, and supports a patient portal. An internal billing database also has a CVSS 9.8 flaw, but it is reachable only from a hardened application subnet and has no public exploit. A six-year-old VPN appliance is end-of-life with a CVSS 8.1 flaw and no vendor patch; 240 remote staff use it daily. The patch SLA says critical findings must be remediated in 14 days, but 75% of exceptions are past due. The next change window is 5 days away and the portal has a 2-hour maintenance limit.
1. Rank the three findings and justify the order using exposure, exploitability, and business impact rather than CVSS alone.
Read the worked answer
The internet-facing Tomcat finding comes first. It is reachable by attackers, listed in KEV, has EPSS 0.92, and supports a patient portal, so exploitation could lead to data exposure or outage. CVSS 9.8 confirms severity, but KEV and EPSS show active exploitation likelihood. The internal billing database comes second despite the same CVSS score because it is reachable only from a hardened subnet and has no public exploit. It still needs remediation, but the practical attack path is narrower; I would verify that the application subnet is truly not internet-reachable and that no compromised application host can reach it. The end-of-life VPN appliance comes third only in terms of patchability, not overall risk: it has no patch, 240 daily users, and internet exposure. It needs immediate compensating controls such as restricting source IPs, enforcing MFA, and accelerating replacement, because an unpatched edge device can become the initial access path.
2. How should the end-of-life VPN appliance be handled when no vendor patch exists and the SLA clock is already past due?
Read the worked answer
I would not mark it as remediated. I would open a risk acceptance with a dated replacement plan and impose compensating controls: restrict management access to a dedicated admin network, enforce phishing-resistant MFA for all VPN users, apply geo-IP and behavioural restrictions where feasible, enable detailed logging to the SIEM, and run vulnerability checks against the appliance. If the vendor will not support it, the business must fund replacement; otherwise the risk owner should accept the residual risk in writing with a short expiry. I would also review whether 240 users all need the same access or whether a smaller group can use an alternative remote-access path. The SLA exception metric should distinguish “no patch available” from “patch available but ignored,” because the first requires architecture change and the second requires process correction.
3. What metrics should be reported to executives so the programme shows risk reduction rather than raw finding counts?
Read the worked answer
I would report exposure-weighted metrics: number of internet-facing critical findings, number of KEV-listed findings, median time to remediate by risk tier, percentage of exceptions past their approved expiry, and percentage of critical assets with an owner and patch path. Raw counts of 41,000 findings encourage the wrong behaviour because many are low risk or duplicated. I would add a trend line for attack surface, such as externally reachable services and missing compensating controls on unpatchable assets. For the board, one page should show the top three risk decisions, the business owner, the date, and the residual risk. That demonstrates judgement and accountability, not just scanner output.