Solution blueprint
Vulnerability management that teams can actually finish
Nobody needs more findings. The work is deciding which ten matter this week, getting them to the team that can fix them, and proving afterwards that they are gone.
The situation
A company scans its servers and produces a monthly report with thousands of findings. The policy says criticals are fixed in fourteen days. They are not, everyone knows it, and the report has become a ritual.
The problem is not the scanner. It is that severity is being used as priority, many assets have no owner, and large parts of the estate are not scanned at all. This blueprint rebuilds the program around decisions rather than volume.
Constraints that shape the plan
- Operational teams have limited change windows and competing work.
- Some systems cannot be patched quickly and need compensating controls instead.
- Asset ownership is incomplete, and fixing that is part of the work.
- The existing policy cannot be met, so it has to be renegotiated honestly.
- Audit and customer commitments reference the current policy.
The operating cycle
- Discover Assets and owners
- Scan Authenticated, broad coverage
- Enrich KEV, EPSS, exposure, criticality
- Prioritize Decision table
- Assign Team that can fix it
- Remediate Or mitigate with a record
- Verify Rescan and confirm
- Report Metrics that drive decisions
The approach, phase by phase
Phase 1: Baseline
Two to three weeks.
-
1
Measure coverage
What is scanned, what is not, and with what authentication. Coverage gaps are usually the biggest finding.
-
2
Assess asset inventory
How assets are known, and what share have a named owner.
-
3
Review the current process
Who looks at output, what happens next, how exceptions work, and what the metrics claim.
-
4
Agree what good looks like
With the teams who have to deliver it, not only with security.
Phase 2: Design the program
Three to four weeks.
-
5
Prioritization model
A decision table combining exploitation evidence, exposure, asset criticality and severity.
-
6
Service levels that can be met
Time limits by risk tier, agreed with operational teams and then published.
-
7
Remediation workflow
Findings grouped into work items per fix, routed to the team that owns the fix, in their tracker.
-
8
Exception process
Risk acceptance with an owner, a reason, a compensating control and an expiry date.
-
9
Metric set
Time to remediate by tier, coverage, exposure window for known exploited vulnerabilities, aging and recurrence.
Phase 3: Close the coverage gaps
Four to eight weeks.
-
10
Authenticated scanning
Where credentials can be managed safely, so installed software and missing patches are visible.
-
11
Cloud and container coverage
Configuration findings, container images and the registry, which network scanners miss.
-
12
Web application coverage
Scanning plus the manual testing that authorization flaws require.
-
13
External attack surface
What is reachable from outside, including resources nobody remembers creating.
-
14
Asset ownership
Every asset class gets an owner, recorded where the workflow can read it.
Phase 4: Operate and improve
Ongoing.
-
15
Run the cycle
Weekly queue, assigned work, verified fixes, exceptions reviewed on expiry.
-
16
Report honestly
Including where the program is behind, because a report that always looks good is not a report.
-
17
Find the patterns
Recurring classes of finding point at a build, image or process problem, which is cheaper to fix than the findings.
-
18
Review the model quarterly
Thresholds and tiers change as the estate and the threat picture change.
Phase names and order change with the engagement. This is a typical shape, not a fixed method you would be held to.
The prioritization model, as a table
| Condition | Tier | Expectation |
|---|---|---|
| In the CISA Known Exploited Vulnerabilities catalog, on an internet-facing or critical asset | Act now | Fix or mitigate within days, with daily reporting until closed |
| Public exploit and internet-facing, or high EPSS score on a critical asset | Act soon | Fix in the next scheduled window |
| High severity, internal only, no evidence of exploitation | Scheduled | Normal patch cycle |
| Low risk on every dimension | Track | Fix opportunistically, or accept with an expiry date |
The tiers and time limits are agreed with the teams who must meet them. CVSS measures severity, not risk; EPSS estimates the probability of exploitation in the wild; KEV records observed exploitation.
The kind of team this needs
Roles can be ours, yours or shared. Where you only need people rather than a project owner, the same roles are available through staffing.
Typical deliverables
- Coverage baseline and gap list
- Asset ownership model
- Prioritization decision table
- Agreed service levels by risk tier
- Remediation workflow in your existing tracker
- Exception and risk acceptance process
- Metric definitions and a reporting pack
- Quarterly review process
What usually goes wrong, and what we do about it
-
Sorting by severity
The decision table combines exploitation evidence, exposure and asset criticality. Severity alone is a sorting key, not a priority.
-
Findings with no owner
Asset ownership is part of the scope, because without it the queue goes nowhere.
-
Policies nobody can meet
Service levels are negotiated with operational teams and then published, rather than imposed and missed.
-
Exceptions that never expire
Every acceptance has an owner, a control and an expiry, and expiry triggers a review.
-
Metrics that reward easy work
We report time to remediate by tier and the exposure window for known exploited vulnerabilities, not total findings closed.
-
Coverage ignored
Coverage is the first measure in the baseline, because unscanned systems are the real unknown.
Questions people ask
Do we need a new tool?
Usually not. Most programs we see have adequate scanning and inadequate decisions and ownership. We will say if a coverage gap genuinely needs a different tool.
How does this relate to penetration testing?
A test shows which findings can be chained into real impact, which informs the model. They answer different questions: see penetration test or vulnerability assessment.
Can you run the program for us?
Only under a written agreement that states what we are responsible for and when. We do not advertise a managed service we have not contracted for.
What about continuous threat exposure management?
It is the same cycle with validation and continuous discovery added. See continuous threat exposure management.
Related
-
Enterprise vulnerability management
Design and run a vulnerability management program: ownership, prioritization rules, ticket routing, exceptions and measurement.
-
Vulnerability assessment
Broad, authenticated scanning of networks, servers, endpoints and applications, with validation so the report lists real findings.
-
Continuous threat exposure management
Move from periodic scans and tests to a repeating cycle of scoping, discovery, prioritization, validation and mobilization.
-
Vulnerability intelligence lookup
Look up a CVE and see its CVSS severity, whether CISA lists it as exploited and its EPSS exploitation estimate, side by side.
Need to understand your security exposure?
Speak with a security expert
Talk through your environment and goals. We reply to scope the work before anything is tested.
Speak with a security expertPlan an assessment
Answer a few questions and get a structured preliminary scope you can send us.
Use the plannerUnder attack right now?
Call the US office and tell us what you are seeing. Do not wait for a form reply.
Incident response