Vulnerability management is the continuous cycle of finding weaknesses across your systems, deciding which ones matter to your business, fixing them on a clock, and confirming the fix held. Most published guidance on the subject describes that cycle correctly and then stops. Our team has run this work inside 10 to 500 employee firms for years, and the cycle diagram is almost never what breaks. What breaks is the operating detail underneath it: scan frequency that quietly slipped to quarterly, findings nobody owns between discovery and the fix, no remediation clock, and no written record of the vulnerabilities you have decided to live with. This guide covers the seven places we see that detail fail, and what to put in its place.
The 5 Things This Guide Answers
We wrote this for the IT manager, operations director, or fractional CISO carrying security at a firm with one or two technical generalists and no dedicated security team. If that is your seat, these are the answers you came for.
- Cadence beats coverage. A monthly authenticated scan you actually read is worth more than a quarterly all-asset scan that lands in an inbox nobody opens.
- A finding needs a name, not a queue. Vulnerabilities stall in the gap between the scanner and the person who can patch. One named owner per asset class closes that gap.
- Severity is not priority. CVSS scores rank the flaw in the abstract. Your priority order comes from exposure, exploit activity, and what the asset touches.
- Remediation needs a clock. Without a written service level per severity tier, “we will get to it” becomes the policy by default.
- The unpatchable needs a register. Every SMB has a line of business application that blocks an update. That is an exception with a compensating control and a review date, not an open ticket.
Why Vulnerability Management Fails at SMB Scale
A vulnerability management program fails at small business scale when it is designed for a security team that does not exist. Enterprise guidance assumes a dedicated analyst reads scan output daily, a change board meets weekly, and a remediation engineer works a queue. At a 60-person firm, all three of those roles are one person who also resets passwords and orders laptops. The program has to survive that reality or it becomes shelfware.
We see the same failure shape repeatedly. A firm buys a scanner, runs a first scan, and gets back several thousand findings. Nobody can triage several thousand of anything alongside a help desk. The report gets filed, the scan schedule drifts, and eighteen months later the same unpatched remote access appliance is still listening on the perimeter. The tooling was never the problem. The operating model was.
Where the first scan goes wrong
A first vulnerability scan should be scoped to your externally reachable assets and your domain controllers, not to everything you own. Scoping wide on the first pass produces a number so large it reads as noise, and a finding count that large teaches the team to ignore the report. Scoping narrow risks missing an exposed asset you forgot you had, which is a fair objection and the reason we run a discovery pass first and a scan pass second.
Our practice is to inventory before we assess. Discovery tells you what answers on your public ranges and what lives on the internal network, including the print server nobody has logged into since 2021. Then the first authenticated scan covers perimeter and identity infrastructure, and the second wave covers workstations. If your environment is heavily remote, endpoint coverage moves up, which is where mobile device management earns its place in the program rather than sitting beside it.
Who owns a finding
Ownership is the single control that separates a working cycle from a report generator. A finding with no name attached is a finding that ages. The argument against per-asset ownership at small scale is real, since one generalist may own every asset class and the assignment looks like theater. The counterargument is that the register still records who accepted the clock, and that record is what survives turnover.
We assign by asset class rather than by finding. Network gear and firewall firmware sit with whoever owns network management. Servers and identity sit with the systems owner. Workstations sit with the help desk lead. When one person holds several of those hats, the assignment still names the hat, so the handoff is clean when a hire or an MSP takes one over.
What a Working Vulnerability Management Cycle Looks Like
A working vulnerability management cycle at SMB scale runs on a fixed calendar with four moving parts: scan, triage, remediate, verify. The calendar matters more than the tooling. Our reference cadence is a weekly authenticated scan of perimeter and identity assets, a monthly full internal scan, a same-week triage session against fresh output, and a rescan to close. That is roughly two hours of standing commitment per week, which a generalist can actually hold.
Triage is where most of the value lives, and it is the step SMBs skip. Take the raw output, cut it against three questions, and you will usually reduce several thousand findings to a working list of a few dozen: is the asset reachable from outside, is there known exploit activity against this flaw, and does the asset touch regulated or revenue data. Anything that answers yes twice goes to the top of the list regardless of what the severity score says.
Setting a remediation SLA you can hold
A remediation service level is a written promise about time to fix per severity tier, and it is the difference between a program and a habit. The cadence we recommend for a small firm: 7 days for critical findings on internet-facing assets, 30 days for high, 90 days for medium, and next refresh cycle for low. Those numbers are deliberately slower than enterprise targets, because a target the team misses every month stops functioning as a target.
The case against publishing an SLA at all is that you will breach it and create a paper trail of breaches. We take the opposite view. A missed 30-day window with a documented reason is a management conversation. An undocumented “when we get to it” is invisible until an auditor or an incident makes it visible, and by then the record you needed does not exist. Where remediation crosses into scheduled downtime or vendor coordination, we run it as a tracked workstream rather than a ticket, which is where project management discipline pays for itself.
Handling what you cannot patch
Every small business has at least one system that blocks an update, usually a line of business application pinned to an old runtime or an appliance the vendor stopped supporting. That is not a failure of the program, it is the part of the program most guides leave out. The finding does not get closed and it does not stay open forever. It moves to an exception register with four fields: the asset, the reason, the compensating control, and the review date.
Compensating controls are where judgment enters. Segmenting the asset onto its own VLAN, restricting access to named accounts, adding session logging, or moving the function behind a jump host all reduce exposure without the patch. In regulated environments the exception also needs an owner who can speak to it, since anything touching patient records changes the calculus around healthcare data management and the tolerance for an open exception is much lower.
Verifying the fix actually held
Verification is the step that gets dropped when the week gets busy, and dropping it means your program reports work it did not do. A patch that failed to apply, rolled back after a reboot, or applied to nine of eleven servers all read as remediated in a ticket system and unremediated in a rescan. The rescan is the only evidence that counts.
We close findings on scan evidence, never on a ticket status. That sounds pedantic until the first time a rescan shows a “completed” patch cycle left two domain-joined servers behind. If you are building this from scratch, our walkthrough on how to implement a vulnerability management process covers the sequencing in more detail, and the sector view in healthcare vulnerability scanning shows how the same cycle tightens when regulated data is in scope.
The 7 Risks We See Most Often
The seven risks below map to the cycle stage where each one appears. Read them as a self-audit rather than a checklist, because a program can pass all seven on paper and still fail on the calendar.
- No asset inventory underneath the scan. You cannot assess what you have not enumerated. An unmanaged asset produces no findings at all, which reads as clean.
- Cadence drift. The schedule starts weekly, slips to monthly during a busy quarter, and settles at whenever someone remembers. Nothing announces this failure.
- Unauthenticated scanning only. Credential-less scans see the front door. Authenticated scans see patch level, local accounts, and configuration, which is where most exploitable findings live.
- Triage by severity score alone. A critical rating on an internal asset with no exploit activity outranks nothing. Exposure and exploit context decide order.
- No remediation clock. Without written windows per tier, remediation competes with every other request and loses.
- No exception register. The unpatchable finding either sits open forever or gets silently closed. Both destroy the integrity of the report.
- Closing on tickets instead of rescans. The program reports remediation it cannot prove, and the gap surfaces during an incident or an assessment.
Where to Start This Quarter
If you are standing this up with a small team, the first 90 days do not need a new platform. Run a discovery pass so you know what you own. Scope the first authenticated scan to perimeter and identity. Write the four remediation windows down and put them in front of whoever signs off on downtime. Stand up the exception register as a simple sheet with those four fields. Then hold one standing triage hour a week and let the rest follow from there.
Our team runs this cycle for firms that do not have a security hire to spare, either as a standing program or as a one-time vulnerability assessment that gives you the inventory and the first prioritized list to work from. If you want a read on where your current cycle is leaking, book a free strategy call and we will walk your last scan output with you.
Frequently Asked Questions
How often should a small business run vulnerability scans?
Run authenticated scans of internet-facing and identity infrastructure weekly, and a full internal scan monthly. Quarterly scanning is common at small scale and it is the cadence we most often replace, because a 90-day window means a newly published exploit can sit unseen for most of a quarter. Cadence that the team can hold beats an aggressive schedule that lapses.
What is the difference between a vulnerability assessment and vulnerability management?
A vulnerability assessment is a point-in-time review that produces a prioritized list of weaknesses. Vulnerability management is the continuous cycle that acts on those lists on a schedule, with ownership, remediation windows, and verification. An assessment is a useful entry point and a reasonable annual checkpoint, but on its own it does not change your exposure.
Do we need a dedicated security team to run vulnerability management?
No. The cycle works with one technical generalist as long as scope, cadence, and remediation windows are written down and the triage hour is protected on the calendar. What does not work is an unscoped program that assumes daily analyst attention. Firms without that capacity usually run the scanning and triage through an outside team and keep remediation in house.
How should we prioritize findings when the scanner returns thousands?
Cut the list against exposure, exploit activity, and data sensitivity before you look at severity ratings. Anything internet-facing with known active exploitation goes first, followed by identity infrastructure, then assets holding regulated or revenue data. That filter routinely reduces several thousand raw findings to a few dozen that deserve attention this month.
What do we do about a vulnerability we cannot patch?
Move it to an exception register with the asset, the business reason, a compensating control, and a review date. Segmentation, restricted named access, session logging, and jump host placement all lower exposure while the patch is blocked. An exception with a review date is defensible. An open finding with no record is not.
