Vulnerability Management Operating Model

Almost nobody has a scanning problem. The 500-page Nessus export proves you can find vulnerabilities; it says nothing about whether any of them get fixed. The real failure is the handoff — security reports it, IT never gets the ticket or deprioritises it, the finding reappears in next quarter’s scan unchanged, and the attack surface stays exactly where it was. Visibility was never the bottleneck. Closure is.

This Vulnerability Management Operating Model is built around the closure, not the scan. It prioritises what’s actually exploitable, routes it to the person who can fix it, enforces a deadline, and — the step that’s forever skipped — retests to confirm the fix worked instead of trusting that it did.

The Process (It’s A Cycle, Not A One-Time Thing)

1. Know What You Have: Every IP, container and cloud instance needs a named owner. This is the foundation and the part everyone underestimates — an asset with no owner can’t be assigned a fix, so it stays vulnerable indefinitely, and the inventory is never as complete as anyone believes.
2. Scan It: Credentialed scans where you can get credentials (they see far more than an unauthenticated probe), plus an external scan to see the subset an attacker sees. The two views disagree, and the disagreement is informative.
3. Filter The Noise: Scanners over-report. We confirm the genuine criticals by hand before they reach an engineer, because the fastest way to lose developer trust is to send them three false positives before the one that’s real.
4. Prioritise Smartly: A 9.8 on an isolated internal test box can wait; a 7.2 on the public API cannot. Context beats the raw score every time — see the next section.
5. Route It To The Owner: A ticket in the system engineers already work in — Jira, ServiceNow — not a security spreadsheet nobody outside the team opens. If it’s not in their queue, it doesn’t exist.
6. Remediate: Patch, apply a workaround, or formally accept the risk in writing for what genuinely can’t be patched. Documented acceptance is a valid outcome; a silent unpatched finding is not.
7. Verify It’s Fixed: Never close on the word “done”. Retest, confirm the finding is actually gone, then close. A patch that didn’t deploy and a patch that did look identical in the ticket — only the retest tells them apart.

Smart Prioritization (Not Just “Fix All Criticals”)

“Fix every critical within 30 days” sounds disciplined and quietly wrecks teams. CVSS base scores deliberately encode no context about your environment, so the rule sends engineers chasing a 9.8 on an air-gapped lab box with the same urgency as one on the payments API. That miscalibration burns the credibility you need for the finding that genuinely is on fire.

What actually sets priority:

• CVSS Score: The technical severity — the starting point, not the answer.
• EPSS: The probability it’s exploited in the near term. Most of what could be exploited never is, and EPSS is how you tell the difference at scale.
• Known Exploited: Is it on CISA’s KEV list or weaponised in Metasploit, or still theoretical? A public exploit changes the maths entirely.
• Exposure & Data: Internet-facing? Touching customer data? A flaw an attacker can’t reach isn’t the same flaw.
• Compensating Controls: Is a WAF or network segmentation already blunting it? A mitigated critical can wait behind an unmitigated high.

Priority falls out of all of these together. Anyone ranking purely by CVSS is optimising the wrong number.

Tools We Use

We integrate with what you run rather than adding another console to check:

• Scanning: Nessus, OpenVAS, Nmap, Shodan
• Endpoint visibility: Wazuh or your existing EDR
• Ticketing: Jira or ServiceNow — the system engineers already live in, because routing is the whole battle
• Automation: GitHub Actions and Python to bulk-create and update tickets, so triage scales past what one person can paste by hand
• Intel: CISA’s KEV catalogue — the vulnerabilities confirmed exploited in the wild, which is the strongest single prioritisation signal available and it’s free

The SLAs (And Yes, You Enforce Them)

The deadline scales with real risk, not raw score — and the SLA only means anything if someone with authority actually enforces it, which is why each tier names who can waive it:

Level	Deadline	When	Who Can Waive
P0	48 Hours	Actively being exploited, internet-facing, critical asset.	CISO
P1	14 Days	Probably getting exploited, internal critical asset.	InfoSec Director
P2	30 Days	Serious but not critical. Standard internal systems.	System Owner
P3	90 Days	Theoretical risk, local access only, good workarounds.	System Owner

Can’t meet the deadline? File a formal exception naming the compensating control and a review date — a governed, dated decision. What you don’t get is silence: an ignored SLA with no exception on record is the gap an auditor and an attacker both find.

Metrics That Actually Matter

“We found 500 vulnerabilities” measures the scanner, not the programme, and reporting it upward actively rewards finding more while fixing nothing. Track outcomes instead:

• MTTR: Time to remediate criticals, trended — the headline number for whether the programme is getting faster or just busier.
• SLA Compliance: Share of findings closed within their deadline. This is where the model either works or is theatre.
• Oldest Open Critical: The age of the worst unfixed internet-facing finding. It should fall over time; if it’s climbing, the SLAs aren’t real.
• Scan Coverage: The proportion of the estate actually being scanned — because an unscanned asset reports zero vulnerabilities, and zero looks exactly like “clean” on a dashboard.

What You Get

• Vulnerability Register: A single source of truth for every finding — prioritised, owned, and current, wherever your team already works.
• SLA Policy: Written timelines, roles, and the exception path, aligned to ISO/IEC 27001 and CIS Control 7 so it holds up to audit.
• Remediation Guidance: Not “Apache needs updating” but “upgrade to this version, which closes these 14 CVEs” — grouped so one action retires many findings, because that’s what makes the backlog tractable.
• Proof of Closure: Retest evidence that the high-risk findings are actually gone, not a status field someone flipped.
• Executive Dashboard: MTTR, SLA compliance and trend, monthly — the outcome view, not the finding count.

Get It Done in 90 Days

• Month 1: Build the inventory and assign ownership — the unglamorous month everything else depends on. Scan the internal estate (aim for 80% coverage) and the full external surface, credentialed wherever you can.
• Month 2: Triage the first wave, cut the false positives before they reach engineers, and automate ticket creation for P0/P1 into Jira or ServiceNow so the pipeline scales.
• Month 3: Start enforcing SLAs, stand up the exception process, and put MTTR and compliance in front of leadership — because the SLAs only bite with executive backing, and you need that support secured, not assumed.

Vulnerability management is a discipline problem wearing a technology costume. The scanners are the easy part; the ownership, the routing, the enforcement and the retest are the work. Do that and you stop re-reading the same findings each quarter and the attack surface finally starts to shrink.