Most teams measure vulnerability management by counts. The scanner found 400 issues this week, 380 last week, and everyone feels productive watching the number drop. But a count tells an auditor nothing about whether the dangerous findings got fixed first, or whether anything got fixed on time.
Vulnerability management is really a prioritization and deadline problem. You take findings from every source, rank them by how much damage they could do, put a clock on each one, and give it an owner. Then you prove, month after month, that the clock is being respected. This guide covers how to run that program and how OptiTech keeps the register honest instead of letting it rot into another stale spreadsheet.
What auditors actually check
When an auditor reviews vulnerability management, they're not counting findings. They're checking for a repeatable process:
- Complete intake. Every source of findings feeds one place, so nothing hides in a tool nobody reads.
- Consistent triage. Severity is assigned by a rule, not a mood, so the same finding gets the same rating every time.
- Documented SLAs. Each severity has a remediation deadline written down before the finding arrives.
- Clear ownership. Every open item has a name attached, not a team alias.
- Evidence over time. You can show SLA compliance trending across months, not just a snapshot from the day before the audit.
Miss any one of these and the program looks ad hoc, which is exactly what a SOC 2 Type II or ISO 27001 assessor is trained to flag.
Where vulnerabilities come from
A finding is only as good as the intake that captures it. Most programs pull from three streams, and each one needs a home in the same register.
Scanners
Automated scanners for infrastructure, dependencies, and web apps run constantly and produce the highest volume. They're great at breadth and terrible at judgment. A scanner will rate a finding critical based on a raw score, even when the affected asset isn't exposed. Intake has to capture both the finding and the context so triage can correct for it.
Penetration tests
A pentest produces fewer findings but higher-quality ones, often chained exploits a scanner can't see. These usually arrive as a report, and the risk is that the report gets filed and forgotten. Every pentest finding should become a tracked item with the same severity, SLA, and owner as anything else.
Disclosures
Security researchers, customers, and your own staff report issues too, through a disclosure inbox or a bug bounty. These are unpredictable and sometimes urgent. A program that only ingests scanner output will miss the one report that actually matters.
Prioritize by severity, not by count
Here's the shift that makes a program credible: you stop celebrating the total and start asking which findings could hurt you most. A single critical flaw on an internet-facing system matters more than two hundred low-severity notices on an internal tool nobody can reach.
Prioritization means assigning a severity to every finding using a consistent rule, then working the list top down. Severity should reflect real exposure, not just a scanner's raw score. A flaw with a high score on an isolated asset may be a lower real-world priority than a medium finding on a customer-facing system. When you rank by impact, a smaller team fixes the things that matter and can defend why the rest can wait.
Set remediation SLAs per severity
An SLA turns "we'll get to it" into a deadline. You set one remediation window per severity, agree it with the business, and write it into your SLA policy so it's the same for everyone.
| Severity | Remediation SLA | Example |
|---|---|---|
| Critical | days | remote code execution on a public system |
| High | a few weeks | privilege escalation behind authentication |
| Medium | one to three months | missing hardening on an internal service |
| Low | up to six months or next cycle | informational or defense-in-depth item |
The exact numbers matter less than having them written down and applied consistently. Once the policy exists, every new finding inherits a due date the moment its severity is set. Nobody negotiates the deadline finding by finding, which is where programs usually fall apart.
Set SLAs you can actually hit
An SLA you can't measure is a suggestion. Set windows you can genuinely meet with the team you have, then tighten them as the program matures. A realistic 30-day medium SLA you meet beats a 7-day one you miss every time.
Assign owners and track due dates
A finding without an owner is a finding nobody fixes. Every item in the register needs one named person accountable for closing it, so the work can't hide behind a team alias.
Once each item has a severity, an SLA, a due date, and an owner, the state becomes obvious at a glance. OptiTech tracks each vulnerability with an SLA state:
- On track. Open, with the due date comfortably ahead.
- Caution. Approaching the deadline, time to escalate.
- Overdue. Past the SLA, needs attention now.
- Resolved. Fixed and verified, kept for the audit trail.
The value is that overdue items surface themselves. You don't hunt through a spreadsheet to find what slipped, because the register shows it. And when you change the SLA policy, for example tightening the medium window from 90 to 60 days, OptiTech recalculates due dates in bulk against the new policy, so every open finding reflects the current rule instead of the one in force when it was logged.
Connect findings to assets and controls
A severity and a deadline tell you how urgent a finding is. The link to an affected asset tells you what breaks if you ignore it. Every item in the OptiTech register connects to the assets it affects and the controls it relates to, so a single flaw shows both its blast radius and its place in your framework.
That linkage pays off twice. During remediation, the owner sees exactly which systems are in scope. During an audit, you can show that a control has real findings behind it and a real remediation history, which is far stronger evidence than a policy document that only claims the control exists.
Report on SLA compliance over time
The final piece is proof. A snapshot of open findings tells an auditor almost nothing. A trend tells the whole story. You want to show what share of findings you closed within SLA, month over month, broken down by severity.
OptiTech reports SLA compliance over time, so you can see whether the program is improving or slipping before an auditor does. If critical SLA compliance dipped last quarter, you can explain why and show the correction. That trend is the difference between "we have a scanner" and "we run a program".
From register to trust asset
The same register that satisfies an auditor also answers your customers. Every enterprise buyer's security review asks how you handle vulnerabilities, and "we scan and fix by severity within documented SLAs" is a far better answer than a screenshot of a dashboard.
A trust center backed by your OptiTech program lets buyers see that you run vulnerability management as a disciplined process, without your team writing a custom answer for every review. The work you already do to stay secure starts closing deals.
Getting started
You don't need a perfect program on day one. A realistic first pass looks like this:
- Route every source into one register: scanners, pentests, and disclosures.
- Write down your SLA policy with a remediation window per severity.
- Assign an owner to every open finding and let due dates fall out of the policy.
- Watch the overdue queue and the SLA trend, and tighten windows as you improve.
Vulnerability management rewards discipline over heroics. Capture everything once, prioritize by severity, hold the deadlines, and both your auditors and your buyers get the same clear answer.
Ready to run vulnerability management as a program you can prove? Book a demo and see how OptiTech keeps your register, SLAs, and evidence connected.
