Pros
- • Shifts focus from passive scanning to active, risk-based remediation
- • Integrates EPSS and threat intelligence to prioritize truly exploitable flaws
- • Establishes clear asset ownership and remediation accountability
- • Implements strict retest discipline to validate patch deployment
- • Provides executive visibility into Mean Time to Remediate (MTTR)
- • Aligns closely with CIS Benchmarks (Control 7) and ISO/IEC 27001
- • Transforms raw scan data into actionable engineering workflows
Cons
- • Heavily dependent on an accurate, constantly updated asset inventory
- • Requires explicit executive support to enforce remediation SLAs
- • Necessitates time-intensive organizational mapping to assign ownership
- • Vulnerability triage requires ongoing manual effort and operational discipline
A 500-page vulnerability report doesn’t mean anything if nothing actually gets fixed. Most companies aren’t struggling with visibility—they’re struggling with actually closing vulnerabilities. Your security team reports it, IT ignores it, it stays broken, and your attack surface never shrinks.
This Vulnerability Management Operating Model actually gets things fixed. We prioritize what matters, assign it to the right people, enforce deadlines, and most importantly: we verify the fix actually works.
The Process (It’s A Cycle, Not A One-Time Thing)
- Know What You Have: Every IP, every container, every cloud instance has an owner. No owner = can’t patch = stays vulnerable.
- Scan It: Credentialed scans where you can. Also scan from outside to see what attackers see.
- Filter The Noise: Scanners report a lot of false positives. We manually confirm real critical issues before bugging the dev team.
- Prioritize Smartly: A 9.8 score on an internal test server? Not urgent. A 7.2 on your public API? Fix it now.
- Make It Their Problem: Create tickets in Jira/ServiceNow. Put it in their queue, not in a spreadsheet they’ll ignore.
- Actually Patch It: Patches, workarounds, or formal documented risk acceptance for the stuff you can’t patch.
- Verify It’s Fixed: Don’t close the ticket because the team says it’s fixed. Retest. Confirm. Then close it.
Smart Prioritization (Not Just “Fix All Criticals”)
The “fix everything critical within 30 days” rule kills teams and doesn’t actually make sense.
Here’s what matters:
- CVSS Score: How bad is the flaw technically?
- EPSS: Will anyone actually exploit this in the next 30 days? (Not everything that could be exploited will be.)
- Is There An Exploit?: Is it in Metasploit, or just theoretical?
- What’s Actually at Risk? Is it internet-facing? Does it have customer data?
- Are There Workarounds? Is there a WAF protecting it? Network segmentation blocking access?
All this together determines priority, not just a score.
Tools We Use
We integrate with what you already have:
- Scanning: Nessus, OpenVAS, Nmap, Shodan
- Endpoint visibility: Wazuh, your existing EDR
- Ticketing: Jira, ServiceNow—wherever your engineers already work
- Automation: GitHub Actions, Python scripts to bulk-create tickets
- Intel: CISA’s list of vulnerabilities actually being exploited in the wild
The SLAs (And Yes, You Enforce Them)
Speed depends on how bad it actually is:
| 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 explaining the workaround and when you’ll revisit it. Don’t just ignore it.
Metrics That Actually Matter
Stop reporting “we found 500 vulnerabilities.” That’s meaningless.
Instead, track:
- MTTR: How long before we fix critical stuff? Are we getting faster?
- Compliance: What percentage of vulnerabilities are being fixed within their SLA?
- Oldest Critical: How old is the worst vulnerability on the internet? (Should go down.)
- Coverage: What percentage of your network are we actually scanning?
What You Get
- Vulnerability Register: One place where all findings live. Jira board, spreadsheet, whatever. Prioritized and updated.
- SLA Policy: Written rules. Timelines. Roles. What happens if you can’t meet a deadline. Aligns with ISO.
- Fix Instructions: Not just “Apache needs updating.” More like “Update this version of Apache and it kills 14 CVEs.”
- Proof It’s Fixed: Evidence that high-risk vulnerabilities are gone. Not just your team’s word—actual retests.
- Executive Dashboard: MTTR, how we’re doing, compliance rate. Monthly update for leadership.
Get It Done in 90 Days
- Month 1: Find everything. Map your network. Who owns what? Scan 80% internally, 100% externally. Credentialed where possible.
- Month 2: Triage the first big batch. Kill false positives. Automate ticket creation for P0 and P1 stuff. Get Jira/ServiceNow connected.
- Month 3: Start enforcing deadlines. Build the exception process. Show leadership your MTTR and compliance numbers.
Vulnerability management isn’t a technology problem—it’s a discipline problem. Do this right and you stop reacting to reports. You actually harden your infrastructure.
