· cyber security · 4 min read

Vulnerability Scanning Finds the Problems: Who Fixes Them?

A scan produces a list. Fixing the list takes owners, priorities, and a monthly review. Here is how co-managed IT turns thousands of findings into a short queue that gets worked.

A scan produces a list. Fixing the list takes owners, priorities, and a monthly review. Here is how co-managed IT turns thousands of findings into a short queue that gets worked.

A vulnerability scan is easy to buy. It runs on a schedule, it produces a report, and the report goes into a folder.

Picture a defense subcontractor with 150 employees whose scan returns 4,000 findings. The IT manager opens it, sees the length, and closes it. Nobody is lazy here. A list that long has no obvious first step, and the person holding it has a company to keep running.

The scan is the cheap part. This post covers the work after it, and how co-managed IT divides that work.

Scanning and fixing are different jobs

Scanning checks your computers, servers, and network gear against a database of known software flaws and reports what it finds. Fixing means installing an update, changing a setting, retiring a device, or accepting the risk on purpose.

Different people usually do each part. The MSP (managed service provider) runs the scanner and cleans up the data. Your internal IT team knows which findings are real, which devices are about to be replaced, and which servers cannot be touched until Friday night. Neither side can do the other’s half.

Why huge reports get ignored

Most findings are low impact, duplicated across devices, or tied to one old app installed everywhere. When everything is flagged, people stop reading.

A useful report is short. It groups findings by the fix that clears them, so one browser update covers 80 entries. It drops noise. It puts the few things that need action this week at the top.

Prioritize by what attackers use

The common scoring system, CVSS (Common Vulnerability Scoring System), rates how severe a flaw could be. It says little about whether anyone is exploiting it. A flaw rated 9.8 that needs unusual conditions can matter less than a 7.5 that criminals use daily.

Two other sources help:

  • CISA’s Known Exploited Vulnerabilities (KEV) catalog lists flaws that attackers are using in the wild. A KEV match on a device that touches the internet goes to the top of the queue.
  • EPSS (Exploit Prediction Scoring System) estimates how likely a flaw is to be exploited soon. It works well as a tiebreaker.

Then add context only your team has. Is the device reachable from the internet? Does it hold customer data or controlled government information? Is it a spare workstation in a closet? The same finding ranks differently on each.

End-of-life software

Some findings have no fix because the vendor stopped producing patches. A Windows version past its support date, an old server operating system, and a firewall that no longer gets firmware updates all fall here.

These need a decision, not a ticket. Options are to replace, to isolate the device from the rest of the network, or to document the risk and set a retirement date. Any of the three can be right. Leaving it blank is the only wrong answer, and it reads badly to an assessor or an insurer as a known gap with no plan.

Assigning findings to owners

Every finding in the working queue needs a name and a due date. In co-managed IT, a split that usually works:

  • The MSP owns operating system and common application patching, and flags what it cannot fix remotely
  • Your IT manager owns vendor-controlled systems, hardware replacement, and exceptions
  • Leadership approves budget for end-of-life replacements and signs off on accepted risks

Findings with no owner by the next meeting go to the person who can unblock them, which is often a department head or the CFO.

The monthly trend review

Thirty minutes a month beats an annual panic. Bring three things: the count of open high-priority findings compared with last month, the oldest open items, and anything on the KEV list. Fresh findings appear whenever new flaws are published, so a rising count is normal. The question is whether the old ones are closing.

Keep notes on what was fixed, what was accepted, and why. For a defense contractor, that record supports NIST SP 800-171 and CMMC (Cybersecurity Maturity Model Certification) work, which expects vulnerabilities to be found and dealt with on a schedule. Other organizations will find it useful when a customer or insurer asks how they manage vulnerabilities.

If you want a second opinion on your current report, ask these:

  • How many findings are tied to software we no longer need?
  • Which ones are on the KEV list today?
  • Who is named on the oldest open item?

We scan every device and rank the findings by what attackers are actually exploiting, then assign each one to an owner. In a co-managed IT arrangement we work through the MSP-owned items while your IT manager handles the rest. Our vulnerability scanning service sits within our wider cybersecurity services.

Call us at 405-253-5101 or schedule a discovery call to get on the calendar.

Back to Blog