Skip to content
Made in the UK

Vulnerability Remediation

How do you prove a patch actually fixed the vulnerability?

By , CEO, CybaVerse. Last reviewed

You prove a patch fixed a vulnerability by rescanning the device and confirming the finding has gone, checking the software version or setting the vendor says closes it, and making sure any required reboot has happened. Keep the before and after scan results as evidence for the client and for Cyber Essentials Plus assessors.

This page is part of our vulnerability remediation guide.

Why is a deployed patch not proof?

A patch tool reports that an update was sent or installed. It does not always show whether the vulnerable code is gone. Some fixes need a reboot, a service restart or an extra configuration change before they take effect. Others install alongside an older vulnerable version that stays in place.

The Cyber Essentials Plus test specification checks software updates through authenticated vulnerability scans of sampled devices, not through patch reports. NIST SP 800-40 also treats verification as part of the patch process, not an optional extra step.

How do you prove a fix, step by step?

The steps below work for most MSPs and give evidence that stands up to client and assessor questions. Run them for high and critical findings at minimum, and ideally for every finding you close. They take minutes per device once scanning runs on a regular schedule.

  1. Step 1: Record the finding

    Save the scan result showing the vulnerability before the fix.

  2. Step 2: Apply the fix

    Install the patch or apply the vendor's prescribed configuration change.

  3. Step 3: Complete any reboot

    Confirm the device has restarted if the vendor requires it.

  4. Step 4: Rescan the device

    Run an authenticated scan and confirm the finding has gone.

  5. Step 5: Check the version or setting

    Confirm the installed version or setting matches the vendor's fix.

  6. Step 6: Store the evidence

    Keep the before and after results with the date and device.

Why do fixes sometimes not stick?

Fixes fail to stick for a handful of predictable reasons. Most are visible in a rescan, which is why rescanning is the real test. We hear from MSPs that pending reboots and old software versions left installed alongside new ones cause most of the false sense of security after a patch cycle.

ReasonWhat you seeFix
Reboot pendingFinding still open after installSchedule the reboot
Old version left installedScanner finds the old filesRemove the old version
Configuration change neededPatch installed but finding openApply the vendor's setting
Wrong patch for the editionFinding unchangedInstall the correct update
Scan ran too earlyResults not yet refreshedRescan after the change

What evidence should you keep?

Keep enough evidence that someone else could confirm the fix without asking you. A simple record per finding is enough for most clients and assessors. Store it with the client's other compliance records so it is easy to find at renewal time, and keep it for at least the certification year.

  • Device name and client
  • Vulnerability identifier, such as the CVE
  • Scan result before and after the fix, with dates
  • Who applied the fix and how

Where does CybaOps fit?

With internal scans running several times a day, the next CybaOps scan shows whether a finding is still open, without anyone remembering to rescan. The CybaOps Remediation Engine can fix security issues automatically, so gaps get closed rather than just reported.

  • Internal scans run several times a day and external scans run daily.
  • CybaOps ties vulnerabilities to the assets they affect, so teams fix what matters first.
  • The CybaOps Remediation Engine is live today: it can fix security issues automatically, so gaps get closed rather than just reported.
  • Vulnerability data can be exported from CybaOps reports.

Proving a fix

How to prove a fix closed the vulnerability

You prove a patch fixed a vulnerability by rescanning the device and confirming the finding has gone, checking the software version or setting the vendor says closes it, and making sure any required reboot has happened.

01 Findings from

Multi-tenantPartner / MSP CustomerCustomerCustomer+
CybaOps by CybaVerse

Proving a fix

02 The 6-step path

  • Role-based access
  • UK-based analysts
  • ISO 27001

03 Outcomes

Explore

Hover or tap any part of the diagram to see what it does.

  • Remediation in
  • CybaVM
  • CybaRemediate

What else do MSPs ask about proving fixes?

These are the follow-up questions MSP engineers ask most about verification.

How soon after software updates should we rescan?

After any required reboot has completed. Rescanning too early can show a fix as failed when it simply has not taken effect yet. With continuous scanning, the next scheduled scan usually picks it up.

Do assessors accept patch reports as evidence?

The Cyber Essentials Plus test relies on the assessor's own authenticated scans of sampled devices, so patch reports alone are not enough. Rescan before the assessment so you see what the assessor will see.

What if the scanner still shows the finding?

Check for a pending reboot, an old version left installed or a configuration change the vendor requires. If none apply, check the scanner's detection logic and record your reasoning before treating it as a false positive.

What should you do next?

See CybaOps vulnerability scanning and the Remediation Engine on the CybaOps platform page. MSPs can read about the CybaVerse partner model for MSPs.

Related: How do MSPs track and fix failed patches? and patch management vs vulnerability remediation

See a fix tracked from finding to closed.

Book a CybaOps demo