Vulnerability management programme
A vulnerability management programme is the standing process that finds weaknesses across every system you own, decides which ones matter first, gets them fixed inside agreed deadlines, and records the ones you choose to live with. Most organizations have a scanner. Far fewer have a programme, which is why the same critical finding can sit in a report for most of a year.
What a vulnerability management programme covers
We build it in six parts, sized to your estate:
- Asset coverage. An inventory reconciled against what the scanner actually sees. The cloud account a project team opened last spring is where findings hide.
- Authenticated scanning. Scans that log in find missing patches and weak configuration an outside-only scan cannot see. Scan credentials get only the rights the scanner needs, and their use is logged. Agents on staff laptops also touch employee data, which matters in a unionised workplace.
- Prioritization. A written rule for what goes first, described below.
- Remediation deadlines. Service levels per priority tier, agreed with the people who own the systems.
- Exceptions. A way to accept a risk on purpose, with an owner, a reason, a compensating control and an expiry date.
- Reporting. A short monthly view leadership can read: coverage, overdue items, and the trend.
How to prioritize vulnerabilities beyond CVSS
The CVSS base score published with a flaw measures how bad it could be in general. It does not reflect whether anyone is exploiting it or whether the affected system is reachable in your environment, and those two facts decide most real priorities. CVSS has threat and environmental metrics for exactly that, but they are rarely filled in, and most scanners sort by the base score alone. A backlog sorted by CVSS alone usually has thousands of “critical” items and no honest way to finish.
We add two public signals. The first is CISA’s Known Exploited Vulnerabilities (KEV) catalogue: a flaw is listed there when there is reliable evidence of exploitation in the wild, so it jumps the queue. The second is FIRST’s Exploit Prediction Scoring System (EPSS), a daily-updated probability that a flaw will be exploited in the next 30 days.
Then comes your own context. A known-exploited flaw on an internet-facing VPN gateway is a this-week fix. The same flaw on an isolated lab machine can wait for the normal patch cycle. CVSS still has a place as one input; it just should not be the only one.
What realistic remediation SLAs look like
Deadlines only work if the people who patch agreed to them. We set tiers with your system owners, tie each tier to exploitation and exposure rather than to a score, and test them against real data before anyone is held to them.
A missed deadline becomes an exception or an overdue item, never a quiet slip.
How this differs from penetration testing
A programme answers “what known weaknesses do we have, and are we closing them?” A human-led test answers “what could someone actually do with them?” The comparison is laid out in pentest vs vulnerability scan, and our testing work is on penetration testing. Weaknesses in how software is written belong upstream, in secure development.
What you receive
| Deliverable | What it is for |
|---|---|
| Coverage map | Which assets are scanned, how, and which are not |
| Prioritization rule | One page your team can apply without us |
| SLA and exception standard | Deadlines per tier and how a risk is accepted on the record |
| Reporting template | The monthly view for leadership and the board |
Overdue KEV items and coverage gaps also make good indicators for a cyber risk register.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
What is a vulnerability management programme?
A vulnerability management programme is the standing process that finds weaknesses across every system you own, decides which ones matter first, gets them fixed inside agreed deadlines, and records the ones you choose to live with.
Is this the same as a penetration test?
No. A programme runs all the time and is mostly automated, while a penetration test is a bounded exercise where a person tries to chain weaknesses together. You need the programme first, or the test spends its days on findings a scanner would have caught.
Why not just fix everything rated critical by CVSS?
The CVSS base score published with a flaw measures how bad it could be in general. It does not reflect whether anyone is exploiting it or whether the affected system is reachable in your environment, and those two facts decide most real priorities. CVSS has threat and environmental metrics for exactly that, but they are rarely filled in, and most scanners sort by the base score alone.
Do we need to buy a new scanner?
Usually not. Most organizations already own a scanner, often bundled with endpoint or cloud tooling. The gap is coverage, credentials, triage rules and follow-through, and that is what we set up with your existing tools.
Start with what you scan today
Tell us roughly how many systems you run, what scans them now, and where the backlog stands. The reply says what a programme would change first. See also all security services.