A ticket for a critical flaw in a file transfer appliance is marked closed on Thursday. The patch job reported success. On Monday the weekly scan shows the finding again: the appliance needed a service restart that never happened, and for four days everyone believed the problem was solved.
On the CompTIA Security+ SY0-801 exam this sits under objective 4.3, which expects you to carry out vulnerability management tasks in scenarios, including everything that happens after a finding has been ranked. This lesson covers choosing a remediation, setting deadlines by severity, verifying that a fix worked, and reporting on the program to people inside the organization and to researchers outside it.
Fixing the flaw itself is the first choice
The best remediation removes the vulnerability. In rough order of preference, that means:
- Patching: install the vendor's update. Most findings close this way, through patch management tools on a regular cycle.
- Upgrading or replacing: move to a supported version when the installed one is end-of-life and will never get another patch.
- Changing configuration: disable a weak protocol such as TLS 1.0 or SMBv1, turn off an unneeded service, close a port, enforce MFA or remove default credentials. Many findings, especially from CSPM tools and benchmark checks, are settings rather than code.
- Removing: uninstall software nobody uses, or decommission a server nobody needs. Unused software is attack surface with no business value, so when nobody needs it, removing it beats patching it: the next flaw can't land on software that isn't there.
Remediation is a change like any other, so it goes through change management, which has its own section. The change record lists the affected systems, the maintenance window, the result of testing on a non-production system and a backout plan in case the update breaks something. For a known exploited flaw on an exposed system, the emergency change process lets the fix go in within hours, with review completed afterward.
Remediation also needs the right owner. The security team finds and ranks; the teams that run the systems usually apply the fixes. A finding assigned to "IT" rather than to a named team tends to sit untouched.
When the fix has to wait, reduce the risk and write the decision down
Sometimes the fix can't happen yet. The vendor hasn't released a patch, the system runs a production line that stops only twice a year, or a medical device's manufacturer won't certify an update. Three approaches cover the gap.
Compensating controls reduce the chance or effect of exploitation without fixing the flaw: an IPS signature or WAF rule that blocks the exploit pattern, a vendor-documented workaround that disables the vulnerable feature, or extra monitoring that alerts on exploitation attempts. The prioritization lesson in the threat intelligence section covers how these change urgency.
Segmentation isolates the system so fewer things can reach it. A legacy Windows server that drives a lab instrument goes into its own VLAN, behind firewall rules that allow only the instrument's workstation and the backup server, with no internet access. The flaw remains, but an attacker would first need to compromise one of two specific hosts instead of any workstation in the building.
Risk acceptance is a documented decision, made by someone with the authority to accept the risk, usually the system or business owner, that a vulnerability will stay open for a stated period. A sound record names the finding and affected systems, the business reason the fix can't happen, the compensating controls in place, the remaining risk, the approver and an expiry or review date. Many organizations track two kinds: a temporary approval that lasts until a fix becomes possible, and a longer-standing one for a system a particular requirement will never fit. Both need an owner and a scheduled review, and an expired approval puts the finding back into the normal queue. How risk acceptance fits into risk treatment overall is covered in the risk management section.
Two shortcuts are never acceptable: marking a real finding as a false positive to make it disappear, and removing a troublesome host from the scan scope. Both hide the risk instead of handling it. On the exam, "accept the risk" is the right answer only when the scenario describes a formal, approved decision and no reasonable fix or compensating control is available.