Vulnerability Management as a Service

Exploitability-weighted
Compensating controls
OT-safe
Evidence output

In plain terms

Security scanners produce tens of thousands of problems and no sense of order. We work out which ones an attacker could actually reach and exploit in your specific network, and hand you a short ranked list you can genuinely finish — plus an honest record of what you are choosing to live with.

Every organization with a scanner has a vulnerability list. Almost none has a defensible answer to which twenty things to fix this month. That gap is the entire service.

Why CVSS ranking fails

CVSS scores a vulnerability in the abstract. It knows nothing about whether the affected service is reachable in your network, whether a compensating control already blocks the path, or whether the asset is a domain controller or a meeting-room display. Sorting by CVSS reliably puts unreachable critical findings above reachable high ones.

How we prioritize instead

Reachability. Can the affected service be reached from anywhere an adversary plausibly stands, given your actual segmentation?
Exploitation reality. Is there a working public exploit, and is it being used?
Asset consequence. What does compromise of this specific host allow next?
Compensating control. Is the path already blocked by something you have?
Remediation cost. Including the outage window it needs.

The output is a short ordered list with a stated reason per item, and an explicit set of findings we recommend accepting — documented, so the acceptance is a decision rather than an omission.

OT and unpatchable assets

A large share of findings in industrial and clinical estates cannot be remediated at all — the vendor will not support the patch, or the outage is not available this year. For those we document the compensating control and the residual risk in the form an auditor and an insurer will both accept. See SCADA and ICS security.

Cadence

Continuous discovery, monthly prioritized worklist, quarterly trend against the previous quarter, and re-verification that closed items are genuinely closed — the step that is skipped most often and that quietly inflates every remediation metric in the industry.

The prioritization decision tree

Reachability first. It eliminates the majority of the list before anyone argues about severity.

The same finding, four contexts

One CVE, CVSS 9.8, on four hosts in the same estate. CVSS gives all four an identical score. The actual priorities are not remotely similar.

Host	Reachable from	Compensating control	Real priority
Internet-facing web server	The internet	None	Immediate — exploit is public
Internal application server	Corporate VLAN	Segmentation; service not exposed	Scheduled patch cycle
Isolated lab host	Lab VLAN only, no route out	Full isolation	Log; do not queue
Plant HMI	Process cell only	Cannot patch — vendor-locked	Document, accept, monitor

Ranking by CVSS puts the lab host level with the internet-facing server. That is why remediation backlogs grow without risk falling.

SLA model

Priority	Criteria	Remediate within	If missed
P1	Reachable + exploited in the wild + no control	72 hours	Executive escalation, documented
P2	Reachable + public exploit	14 days	Compensating control required
P3	Reachable, no known exploit	Next patch cycle	Rolls forward once, then re-scored
P4	Not reachable	Opportunistic	No escalation
Accepted	Cannot remediate	n/a	Annual review, named owner

Worked example — 12,000 assets, 41,000 open findings

Starting position: a scanner running for three years, a backlog nobody had ever cleared, and a metric ("open criticals") that had risen every quarter despite real patching effort.

Reachability modellingFindings correlated against actual segmentation policy. 41,000 findings reduced to 6,200 on hosts reachable from any position an adversary could plausibly occupy — an 85% reduction before a single patch.
Exploit enrichmentCross-referenced against known-exploited catalogues. 340 had public working exploits; 47 were actively exploited in the wild.
Compensating control checkOf the 47, nineteen were already blocked by an existing control — application allow-listing or a WAF rule. Verified rather than assumed, by attempting the path.
The actual P1 list28 findings. A team of three closed them in nine days.
Re-verificationEach closed item re-tested. Four had not actually been remediated — the patch was installed but the service was never restarted, so the vulnerable code was still resident. This is extremely common and it silently inflates every remediation metric in the industry.
Accepted risk register1,100 findings on unpatchable OT and clinical assets moved to a documented register with compensating controls and named owners, rather than sitting as permanently open "criticals" that trained everyone to ignore the dashboard.

Why the old metric was worse than useless

"Open criticals" rose every quarter because discovery outpaced remediation — which is true of every organization and says nothing about risk. The replacement metric is P1 count and P1 age. It is small, it is actionable, and when it moves it means something.