In Safeguard 7.1, we discussed the difference between running a vulnerability scanner and operating a vulnerability management program. A scan may identify weaknesses, but the organization still needs a documented process that explains what happens next.
That brings us to CIS Safeguard 7.2: Establish and Maintain a Remediation Process. The safeguard calls for a documented, risk-based remediation strategy that is reviewed at least monthly. The phrase “risk-based” matters. Most organizations have more vulnerabilities than they can address immediately. The purpose of the remediation process is to make sure they’re addressed in the right order, by the right people, within timelines the organization has deliberately established.
The report is only the starting point
A vulnerability scan can produce hundreds or thousands of findings. Some are urgent. Some are routine. Some may be inaccurate or no longer applicable. Others may affect systems already scheduled for replacement.
This is where vulnerability management becomes a business process rather than a technical exercise. Someone has to evaluate the findings, determine which ones create the greatest risk, assign responsibility, and track what happens next.
Without that structure, organizations often fall into one of two patterns. They try to fix everything at once and quickly become overwhelmed, or they focus on whatever is easiest and leave the more important issues sitting in the queue. Neither approach is risk-based.
Severity and risk are not the same thing
Most vulnerability tools assign severity ratings to their findings. Those ratings are useful, but they shouldn’t be the only factor driving the remediation process.
A critical vulnerability on an isolated test system may not create the same level of risk as a medium-severity vulnerability on an internet-facing system containing sensitive information. A weakness affecting a system scheduled for retirement next week may require a different response than the same weakness on a platform expected to remain in service for five years.
The organization also needs to consider whether the vulnerability is being actively exploited, how accessible the affected system is, what information or services it supports, and what other safeguards may already reduce the likelihood or impact of an attack.
That doesn’t mean every finding requires a lengthy risk assessment. It means the process should consider the environment in which the vulnerability exists rather than blindly following a number generated by a tool.
Asset context matters
A risk-based remediation strategy depends on knowing what the affected asset does. If the report identifies a server only by an IP address, the reviewer may not know whether it supports payroll, a public website, a manufacturing process, or an abandoned test application. Without that context, prioritization becomes guesswork.
At a former organization, we maintained a separate criticality rating for the assets being scanned. That rating considered what the system supported, the types of data it stored or processed, its confidentiality requirements, and the potential business impact if it became unavailable or compromised. We then considered that asset rating alongside the technical severity of the vulnerability when prioritizing remediation.
That combination produced a much more useful picture of risk. A critical vulnerability on an isolated development machine might not require the same response as a medium-severity vulnerability on an internet-facing system containing sensitive customer or financial data. The scanner could tell us how serious the technical weakness was. The asset criticality rating helped us understand how much the affected system mattered to the organization.
This is another reason the earlier inventory controls matter. Asset inventories, software inventories, data inventories, and ownership information give vulnerability findings meaning. A vulnerability doesn’t exist in isolation. It exists on a system that supports something the organization cares about.
The remediation process should define how findings are connected to the assets they affect and how the business importance of those assets influences the response.
Someone has to own the finding
Security may discover the issue but not control the affected system. Internal IT may manage the operating system while an application owner manages the software running on it. An MSP may maintain the device while the organization retains responsibility for approving changes.
The remediation process should make it clear who receives the finding, who evaluates it, who’s responsible for addressing it, and who follows up when the expected action doesn’t occur.
Assigning a vulnerability to “IT” isn’t always enough. If several teams share responsibility, the issue can move from one queue to another without anyone owning the outcome. Ownership doesn’t mean one person must perform every task. It means someone is accountable for making sure the finding moves forward.
Timelines should be defined before the crisis
A remediation strategy should establish expected timelines based on risk. The exact timeframes will vary by organization. A small business with a straightforward environment may use a simple set of categories. A larger enterprise may define different expectations based on severity, asset criticality, exposure, contractual requirements, or regulatory obligations.
What matters is that the organization decides in advance how quickly different types of findings should be addressed. Without defined timelines, every vulnerability becomes a negotiation. One team believes the issue is urgent. Another believes it can wait until the next maintenance window. The business owner is concerned about operational disruption. Weeks pass while everyone discusses what “soon” means.
A documented strategy gives those conversations a starting point. It doesn’t eliminate judgment, but it prevents every finding from being handled as an entirely new problem.
Not every vulnerability can be fixed immediately
Sometimes a patch isn’t available. Sometimes applying one would interrupt a critical business process. A legacy system may not support the required update, or a vendor may need time to test a change.
A mature remediation process accounts for those situations rather than pretending they don’t happen. The organization may use temporary safeguards, isolate the affected system, change a configuration, restrict access, or accept the risk for a defined period. The specific response will depend on the circumstances, but the decision should be documented, approved by someone with the appropriate authority, and revisited rather than allowed to remain open indefinitely.
Review keeps the process moving
CIS 7.2 requires the remediation process to be reviewed monthly or more frequently. That review is an operational check on whether the strategy is working and whether findings are moving through the process as expected.
It should help the organization identify overdue items, unresolved ownership questions, recurring exceptions, and vulnerabilities that need to be reprioritized because the threat or business environment has changed.
A finding that appeared routine three weeks ago may become urgent after active exploitation is discovered. A system scheduled for retirement may remain in production longer than expected. Risk changes, and the remediation process has to account for that.
A place to start
Define how findings will be evaluated, what factors determine priority, who owns them, and what timelines apply. Establish a way to document exceptions and risk acceptance. Then create a recurring review to identify overdue findings and confirm that the process is producing action rather than simply generating reports.
The safeguards that follow address specific activities such as operating system patching, application patching, vulnerability scanning, and remediation. Safeguard 7.2 provides the strategy that keeps those activities from becoming disconnected technical tasks. Finding a vulnerability is important. Deciding what it means, who owns it, and how quickly the organization needs to respond is what turns that finding into a managed risk.
