15.2 Updates, Patching, and Vulnerability Management

Key Takeaways

  • Patch management identifies, tests, approves, deploys, and verifies updates that reduce known risk.
  • Vulnerability management is broader than patching and includes discovery, prioritization, remediation, mitigation, and tracking.
  • Risk-based prioritization considers severity, exploitability, exposure, asset value, compensating controls, and business impact.
  • Emergency patches may need accelerated handling when active exploitation or critical exposure is present.
  • Verification confirms that remediation worked and that the environment did not break in the process.
Last updated: April 2026

Updates, Patching, and Vulnerability Management

Patching is one of the most practical hardening activities. Software and firmware contain defects, and some defects become vulnerabilities that attackers can exploit. Updates may fix security flaws, stability problems, compatibility issues, or feature defects. Patch management is the controlled process for getting the right updates onto the right systems without creating avoidable outages.

Patch Management Flow

A basic patch process includes inventory, awareness, testing, approval, deployment, and verification. Inventory matters because you cannot patch what you do not know exists. Awareness may come from vendor advisories, vulnerability scans, threat intelligence, managed service alerts, or internal findings. Testing checks whether the patch breaks critical functions. Approval ties the change to business risk and change control. Deployment applies the update. Verification confirms that the patch installed successfully and the vulnerability is reduced.

In a hospital scenario, applying a server patch without testing could disrupt scheduling or patient care systems. But delaying a patch for a remotely exploitable internet-facing system can also create serious risk. Good patch management balances urgency with operational impact.

Vulnerability Management

Vulnerability management is broader than patching. It includes discovering assets, scanning or assessing them, validating findings, prioritizing remediation, assigning owners, tracking deadlines, applying fixes or mitigations, and reporting risk. Some vulnerabilities are fixed with patches. Others require configuration changes, disabling a service, changing permissions, replacing unsupported software, adding a firewall rule, or accepting risk through a formal process.

Prioritization should be risk based. A critical vulnerability on an internet-facing VPN gateway with known exploitation deserves more urgency than a medium vulnerability on an isolated lab system. Factors include severity score, exploit availability, active exploitation, asset sensitivity, exposure, business criticality, compensating controls, and whether the vulnerable component is actually present and reachable.

Emergency Patching and Mitigation

Normal maintenance windows are useful, but emergencies happen. A vendor announces a critical remote code execution flaw affecting a public web server. Attackers are already scanning for it. Waiting a month for the normal cycle may be unacceptable. An emergency change process allows accelerated testing, approval, deployment, and communication.

If a patch cannot be applied immediately, compensating controls may reduce risk. Examples include disabling the vulnerable feature, blocking access at a firewall or web application firewall, removing internet exposure, increasing monitoring, or isolating the system. Mitigation is not the same as permanent remediation, so it should be tracked until the real fix is complete.

Verification and Lessons

Verification is often skipped, but it is essential. A dashboard may say a patch was deployed, while several laptops were offline and missed it. A scanner may still detect an old library because the application bundles its own copy. A firewall rule may block exploit traffic but leave another path open. Verification can include checking patch levels, rescanning, reviewing logs, testing application functions, and confirming service owners sign off.

After a major patch effort, teams should ask what slowed them down. Was the asset inventory incomplete? Were owners unknown? Did testing take too long? Did rollback plans exist? These lessons improve the next cycle.

For CC exam questions, patching is the direct answer when a known software flaw needs a vendor fix. Vulnerability management is the better answer when the scenario asks for an ongoing program to discover, prioritize, remediate, and track weaknesses. Choose compensating controls when an immediate fix is not possible but risk must be reduced now.

High-Yield Checkpoints

  • Patch management identifies, tests, approves, deploys, and verifies updates that reduce known risk.
  • Vulnerability management is broader than patching and includes discovery, prioritization, remediation, mitigation, and tracking.
  • Risk-based prioritization considers severity, exploitability, exposure, asset value, compensating controls, and business impact.
  • Emergency patches may need accelerated handling when active exploitation or critical exposure is present.
  • Verification confirms that remediation worked and that the environment did not break in the process.
Test Your Knowledge

Which activity is part of vulnerability management but broader than simply installing patches?

A
B
C
D
Test Your Knowledge

A critical vulnerability is actively exploited against internet-facing systems, but the patch needs testing. What process is most appropriate?

A
B
C
D
Test Your Knowledge

Why is post-patch verification important?

A
B
C
D