Prioritization
Vulnerability remediation: how to fix, mitigate or accept every finding
What vulnerability remediation means, the three ways to close a finding (fix, mitigate, accept), a step-by-step process, and how to prove each fix with a rescan.
By Brandon Sooknanan, Founder, Varaxon Technologies · · 6 min read
Vulnerability remediation is the work of closing the weaknesses a scan finds: installing the patch, changing the setting, removing the software, or putting a control in place when none of those is possible yet. Scanning tells you what is wrong. Remediation is the part that reduces risk, and it is where most programs stall, because a long scan export does not say who should fix what, in which order, or how anyone will know it worked.
This guide covers the three outcomes every finding should reach, a remediation process you can run every scan cycle, and the evidence that shows the work was done.
The three ways to close a finding
People often use remediation to mean any response to a vulnerability. It helps to be stricter, because each outcome needs different evidence.
| Outcome | What it means | Typical actions | Evidence to keep |
|---|---|---|---|
| Remediate | The weakness no longer exists | Install the patch or update, upgrade or replace end-of-life software, change the insecure setting, remove the unused service or package | A later scan that no longer reports the finding |
| Mitigate | The weakness exists but is harder to reach or exploit | Block the port, restrict access to a management interface, isolate the system on its own network segment, turn on a vendor workaround, add monitoring | A record of the control, who put it in place and when it will be reviewed |
| Accept | The business decides to live with the risk for now | No change, or a change planned for a later date | A signed risk acceptance with a reason, an owner and an expiry date |
A fourth outcome comes up often enough to name: the finding is a false positive. That is not remediation, but it still needs a recorded reason so the same item does not come back for review every month. Our guide to false positives in vulnerability scans covers how to check one.
A remediation process that repeats every scan cycle
- Collect the findings. Use the scanner's full export (for example the .nessus file, an OpenVAS XML report or a CSV) rather than a PDF summary, so every host, port and CVE is there.
- Remove noise. Merge duplicate rows for the same issue on the same host, drop informational items from the action list, and flag anything that looks like a false positive for a quick check.
- Prioritize. Put CVEs on the CISA KEV catalog first, then findings with a high EPSS score, then the rest by CVSS. Raise anything on an internet-facing or business-critical system.
- Group into actions. Forty findings on one server often collapse into two actions: apply the monthly operating system update and upgrade one application. Assign each action, not each row.
- Assign an owner and a date. Whoever controls the system owns the fix. Set the target date from your remediation SLA.
- Make the change. Use the normal change process. Test risky changes on one system first, and plan reboots and maintenance windows ahead.
- Verify with a rescan. Run the same scan with the same settings. A finding that disappears from an authenticated rescan is fixed; one that disappears only because the scanner could not log in is not.
- Record the outcome. Mark each finding fixed, mitigated, accepted or false positive, and keep the rescan as proof.
How to decide what to fix first
Severity alone is a poor queue. Most scans contain hundreds of High and Critical findings, and only a small share of CVEs are ever exploited. Three signals together give a much better order:
- Known exploitation. A CVE on the CISA Known Exploited Vulnerabilities list has been used in real attacks. CISA gives US federal agencies a due date for each one, which makes a sensible deadline for everyone else. You can look any CVE up with the free CVE checker or browse the known exploited CVE pages.
- Likelihood of exploitation. EPSS, published daily by FIRST, estimates the chance a CVE is exploited in the next 30 days.
- Impact if exploited. CVSS describes how bad a successful attack would be, and the asset's role and exposure tell you how much that matters here.
The CVSS vs EPSS vs CISA KEV guide shows how to combine them into four simple bands, and risk-based vulnerability management goes further into asset context.
Why remediation stalls, and what helps
| Blocker | What usually helps |
|---|---|
| The report is too long to act on | Group findings into actions per system, and lead with the handful of known exploited items |
| Nobody owns the system | Name an owner per asset group in the plan; line-of-business and vendor-managed systems need a named client or vendor contact |
| The patch breaks something | Mitigate now, record a risk acceptance with an expiry date, and schedule the upgrade |
| The same findings come back | Look for the cause: a gold image that was never updated, an update policy that skips a product, or software reinstalled by users. See why the same vulnerabilities keep coming back |
| Fixes are not visible to the client | Show what was fixed since the last scan, not only what is open, and bill remediation as a line item where your contract allows |
Proving the work was done
Auditors, cyber insurers and clients increasingly ask for evidence rather than assurance. For each finding you should be able to show when it was first seen, what was done, who did it, and the scan that shows it gone, or the signed acceptance that explains why it is still there.
The simplest way to build that record is to compare each scan with the previous one: what is fixed, what is new and what is still open, with the age of each open item. Our guide on proof of fix since the last scan walks through it, and a remediation plan template gives you a format to track actions in between.
We built Varaxon Scan Hub for this loop. Upload a scan export from any common scanner and it ranks the findings using CISA KEV, EPSS and CVSS, groups them into remediation actions and, on the next scan, shows what was fixed, what is new and what is still open. Actions can become HaloPSA or ConnectWise PSA tickets once you have reviewed them. Every new account gets a 14-day free trial, no card needed: see how it works.
Common questions
What is the difference between remediation and mitigation?
Remediation removes the vulnerability, for example by patching or upgrading. Mitigation leaves it in place but makes it harder to exploit, for example by blocking access or isolating the system. Mitigation is a stopgap and should have a review date.
How do you verify a vulnerability has been remediated?
Rescan the same target with the same scanner settings and credentials. If the finding no longer appears and the scan logged in successfully, it is fixed. Keep the rescan report as evidence.
Should every vulnerability be remediated?
No. Low-risk findings on internal systems can wait for the normal update cycle, and some findings are best mitigated or accepted. What matters is that every finding has a recorded decision and an owner.
Is patching the same as vulnerability remediation?
Patching is the most common remediation, but not the only one. Configuration changes, removing unused software and replacing end-of-life systems are remediation too, and none of them is a patch.
Turn your next scan export into a client-ready report.
Run a free pre-flight check