340,000 Open Findings and Nine People
Adventure Works patches monthly. Vulnerability Response holds 340,000 open vulnerable items across 12,000 configuration items, with about 4,000 new items per scan cycle. Nine remediation specialists work the backlog of 21,000 items rated Critical, currently ranked purely by CVSS base score. Analysis shows 62% of the Critical items sit on 40 internet-facing hosts, and 70% of all open items sit on 900 end-of-life servers that will not be patched before decommissioning. A separate 300-device OT estate generates 1,800 findings per month and cannot be patched at all. The monthly change window is six hours, and the change board has refused emergency windows for three consecutive quarters.
1. The backlog is ranked by CVSS base score. What does that ranking get wrong in this estate, and what inputs would you add - and how would you roll the change out?
Read the worked answer
CVSS base score describes the vulnerability in the abstract. It knows nothing about your estate, and every fact in the setup is one it cannot see.
What it gets wrong here:
- It ranks a critical CVE on an isolated lab host above a medium CVE on an internet-facing payment server.
- It is blind to whether exploitation is happening now. A vulnerability with a published, weaponized exploit and a vulnerability with a theoretical proof of concept can share a base score.
- It ignores compensating controls. If a WAF rule or network segmentation blocks the attack path, the effective risk is lower - and that fact belongs in the record, not in someone's memory.
- It has no way to say 'this host is being decommissioned in 60 days', so it keeps surfacing work that should be closed as accepted.
Add: exploit availability and maturity from a known-exploited feed, asset criticality and internet exposure, service reachability, and data sensitivity. Then weight them.
Rollout matters more than the weights. Re-scoring re-ranks the entire backlog, invalidates every trend line the team reports, and destroys the analysts' mental model overnight. Snapshot the current scores, re-score in a sandbox, and compare the top 100 before and after. If the top 100 changes drastically, you have found either a data quality problem or a genuine blind spot - either way you want to know before production.
2. 62% of Critical items are on 40 hosts. What is the right unit of work, and how does that change assignment and the patch window?
Read the worked answer
The right unit of work is the host, not the finding. Forty hosts is a project; thirteen thousand findings is a despair.
Grouping. Create one remediation task per host (or per host group sharing an owner and a window), with the constituent vulnerable items linked so that closure rolls up. Nine specialists can sequence 40 hosts against a six-hour window. They cannot sequence 13,000 records.
Assignment. Assign the task to the CI's support group or owner, not to the remediation team. The remediation team cannot patch a host it does not own, and the current model produces tasks that bounce. The remediation specialists should own the programme - prioritization, sequencing, exception review - not the wrench-turning.
The window. Six hours forces selection. Pick the critical-and-exploitable subset per host rather than everything, group hosts that share a maintenance impact, and stage the reboot. Publish the sequence in advance so the change board is approving a plan, not a surprise.
Measurement. Report closure at host level and at host-critical-clearance level. If you report finding-level closure, you will be rewarded for clearing the easy low-risk items on already-clean hosts while the 40 internet-facing servers stay dirty - and the number will look excellent.
3. OT devices cannot be patched; end-of-life servers will not be patched. How should the exception process treat those two populations differently?
Read the worked answer
Both are risk acceptance, but they are different risks with different owners and different evidence.
OT estate (1,800 findings per month, unpatchable). Individual exceptions per finding will drown the process - at that rate the review queue becomes the bottleneck and the exceptions get rubber-stamped. Site the exception at the device or device-group level, require a named compensating control (segmentation, monitoring signature, restricted access path), set a review date, and route approval to the operational risk owner who can actually accept downtime risk. Report the control's effectiveness, not just its existence.
End-of-life servers (900 hosts, 70% of volume). This is not a patch backlog, it is a decommission decision wearing a patch backlog's clothes. Accept at the server-group level with a replacement or retirement date, and stop generating per-CVE exceptions for hosts whose remaining life is shorter than the patch cycle. If the retirement date keeps slipping, that fact should surface as a risk item rather than being absorbed silently.
Keep false positives strictly separate. A finding that the scanner got wrong is a data quality issue with a fix; a finding you have chosen not to fix is an accepted risk with an owner. Conflating them lets real findings hide inside a large exception pile - and with 1,800 findings a month from OT alone, that pile will be large. Report exception volume and exception age upward; that is the number that gets decommissioning funded.