Rapid7 InsightVM | Vulnerability Management Series Issue #03 | The Priority Is Clear. But Who Will Fix It, and By When?

The upgrade you planned for the weekend is complete. The change record has been closed. Application teams have confirmed that services are running. IT has reported that the work was successful.

On Monday morning, the same vulnerability still appears in the vulnerability report.

Are you looking at an old result, or is remediation genuinely incomplete?

Some systems may have been left out of scope. A server may be awaiting a reboot. An older component may still be running alongside the updated application.

If you cannot make this distinction, there is still uncertainty between completed work and reduced risk.

Sending the Report Does Not Assign the Work

In the previous article, we explored which remediation action could deliver greater risk reduction. Now that action needs to move forward within the organization.

But sending a vulnerability report to Infrastructure, Network and Application teams does not mean that every finding has an owner. One team is responsible for the operating system. Another manages the application version. Making the change requires the service owner's approval and a suitable maintenance window.

A vulnerability everyone knows about can become a task no one owns.

That is why a remediation plan must clarify responsibility for execution as well as the technical solution:

• What needs to be done, and on which systems?

• Who will own it?

• By what date will it be completed?

• How will the outcome be validated?

Without this information, you have a priority list; you do not yet have an operational process.

Remediation Projects: Turning a Solution into Trackable Work

InsightVM's Remediation Projects feature lets you group solutions for specific assets within a project, assign an owner and set a due date.

Consider, for example, an upgrade across a group of application servers. The systems in scope and the solution to be applied can be tracked within the same workstream, and progress is monitored alongside the remediation status of the relevant assets.

This replaces "We have passed this to IT" with more concrete information:

On which systems is the work complete, where is it still in progress, and which systems are awaiting verification?

Updating one server does not mean that risk has been eliminated across the entire group. A project-based approach shows what has been completed while keeping the remaining work visible.

The Process Must Continue Where IT Works

While Security uses InsightVM, IT may manage its day-to-day work in Jira or ServiceNow. Moving the remediation process between these environments through email and Excel requires the same work to be updated in multiple places, and over time the ticket status and the security finding can drift apart.

InsightVM's Jira and ServiceNow ticketing integrations support bringing remediation work into existing work-tracking workflows. Configured status mappings help ticket and remediation statuses progress together. IT can work in its own queue while Security follows the progress of the relevant solution.

The benefit is not just opening another ticket; it is preserving the connection between that ticket and the security outcome it is meant to deliver.

Steps such as change approval, application testing and maintenance windows follow the organization's existing processes. Remediation tracking makes the security outcome of that work visible.

"Resolved" Should Not Be the Final Checkpoint

IT's confirmation that the work is complete is valuable. It should trigger the validation step.

In InsightVM, the Awaiting Verification status makes this distinction visible: the solution has been reported as applied, but the security outcome still needs to be verified. In a properly configured ticketing workflow, the resolved status in the ITSM system can be mapped to this stage, and the next assessment or validation scan checks whether the vulnerability has been remediated.

If validation succeeds, the solution is closed. If the vulnerability is detected again, the work continues.

Closing a ticket is a process record. Verifying that a vulnerability has been remediated is technical evidence.

This is where the actual outcome of the weekend upgrade becomes clear. It matters not only that the system is running, but also that the targeted vulnerability is no longer present.

A Better Answer at Monday's Meeting

It is easy to answer "Was the upgrade completed?" with "Yes." A more valuable answer is:

"It has been completed and verified on this subset of the systems in scope. Work continues on the remaining systems because of this dependency; the owner and due date are clear."

This answer shows Security the remaining risk, IT the remaining work, and management where the process is waiting. Vulnerability management then becomes an organizational capability whose outcomes are tracked, rather than an activity that merely produces reports.

Managing a vulnerability does not end when you send it to someone. It requires bringing ownership, a schedule and evidence of remediation together in the same process.

Zero Second | Rapid7 – Vulnerability Management.

Rapid7 InsightVM | Vulnerability Management Series Issue #03, prepared by Zero Second.