Vulnerability Prioritization Under a 30-Day Regulatory Clock
Corvus Financial has 18,500 managed assets. A quarterly scan finds 3,200 vulnerabilities rated critical and 41,000 high. The patch window is four hours on the third Sunday; six change approvers sign off; 7,800 endpoints are remote. One finding is a remote-access gateway with CVSS 9.8, unauthenticated remote code execution, public exploit code, 26 internet-facing instances, 9 confirmed vulnerable, and 2 showing exploitation attempts. Another finding covers 1,200 internal servers with a critical library vulnerability but no known exploit and compensating WAF rules. A regulator requires critical vulnerabilities remediated within 30 days unless a documented exception exists. The CISO has two vulnerability analysts and no automated patch orchestration for third-party applications. The board asks why the team cannot simply patch everything and wants a risk-based plan.
1. Prioritize the first 72 hours and the next 30 days. Which findings get attention and why?
Read the worked answer
First 72 hours: the internet-facing gateway. It has public exploit code, confirmed vulnerable instances, and exploitation attempts - exposure and exploitability outweigh raw CVSS. Isolate or disable the 26 instances, apply the vendor patch or a WAF virtual patch, reset credentials, and hunt for compromise on the 9 confirmed hosts. Next 30 days: the 1,200 internal servers with the critical library flaw. No known exploit and WAF coverage lowers urgency, but the regulator's 30-day rule still applies; schedule risk-based patching, verify WAF efficacy, and document compensating controls.
Do not treat all 3,200 criticals equally. Rank by internet exposure, known exploited vulnerability status, asset criticality, and blast radius. The board should hear that 'patch everything' is impossible with four hours and six approvers; the plan reduces the highest-risk exposure first.
2. How would you handle exceptions and regulatory reporting for the 1,200 servers?
Read the worked answer
For the 1,200 servers, do not issue a blanket exception. If patching cannot finish within 30 days, create a documented exception per asset group: vulnerability, compensating control (WAF rule ID, network isolation, no internet), residual risk, owner, expiration date, and remediation date. Require risk-committee approval and legal or regulatory review. Report to the regulator only if required and only with counsel; do not misrepresent unpatched assets as remediated.
Use EPSS or KEV to distinguish exploited risk from theoretical severity, but the regulatory clock is separate. If the library is embedded in an application, get a vendor fix or isolate the service. Track exception aging weekly. An exception is a time-bound risk acceptance, not a permanent waiver.
3. What metrics and process changes would you propose to the board?
Read the worked answer
Propose metrics: percentage of internet-facing criticals remediated within 7 days, all criticals within 30 days, exception count and age, patch coverage, mean time to remediate by asset class, and number of known exploited vulnerabilities open. Add process changes: pre-approved emergency change for exploited internet-facing flaws, automated inventory and patch orchestration for third-party apps, and a risk-based SLA instead of one-size-fits-all. Reduce six approvers to an emergency panel for criticals.
Report residual risk, not just scan counts. A board dashboard should show the gateway closure, the 1,200-server plan, and exceptions with expiry - not 3,200 open criticals without context. The narrative should explain why prioritization reduces real risk faster than a raw patch-everything target.