Patch and Vulnerability Management

The Paradox of Known Vulnerabilities

Most successful breaches do not involve zero-day exploits or nation-state toolkits. They involve known vulnerabilities with available patches that were never applied. The 2017 Equifax breach exploited a Struts vulnerability that had been public for two months with a patch available. The WannaCry ransomware spread through a Windows SMB flaw patched 59 days earlier.

The hardest part of vulnerability management is not finding vulnerabilities — scanners do that well. The hard part is building a process that consistently turns findings into action before attackers do.

This module covers CISSP exam objective 7.8. ISC2 expects you to understand vulnerability management as a continuous program — not a scanning exercise — and patch management as a disciplined operational process with testing, approval, and verification stages.

The Vulnerability Management Lifecycle

Vulnerability management is a repeating cycle, not a project with a start and end date. Each phase feeds into the next, and skipping any phase degrades the entire program.

1. Discover

Before you can manage vulnerabilities, you need to find them. Discovery includes:

• Authenticated scanning — Scanners log into systems using credentials to inspect installed software, configurations, and missing patches from the inside. This produces far more accurate results than external scanning alone.
• Unauthenticated scanning — Network-based scans that probe systems from the outside, identifying exposed services, open ports, and remotely detectable vulnerabilities. Useful for seeing what an attacker sees.
• Agent-based scanning — Lightweight agents installed on endpoints that report vulnerability data continuously, even when systems are not on the corporate network.
• Application scanning — DAST and SAST tools that identify vulnerabilities in web applications and custom code.

Scanning cadence matters. Monthly scans were acceptable a decade ago. Most mature programs now run continuous or weekly authenticated scans for critical systems and at least monthly for everything else.

2. Prioritize

A typical enterprise scan returns thousands of findings. Treating them all equally guarantees that critical vulnerabilities sit in queues behind low-risk ones. Prioritization should consider:

• CVSS score — The Common Vulnerability Scoring System provides a standardized severity rating. But CVSS alone is not enough — a CVSS 10.0 on an isolated test server is less urgent than a CVSS 7.5 on an internet-facing payment system.
• Asset criticality — What business function does the affected system support? What data does it process? A vulnerability on a system processing regulated financial data has different urgency than one on an internal wiki.
• Exploitability — Is there a public exploit? Is it being actively exploited in the wild? CISA’s Known Exploited Vulnerabilities (KEV) catalog and threat intelligence feeds inform this assessment.
• Exposure — Is the system internet-facing, accessible from partner networks, or isolated behind multiple layers of controls?
• Compensating controls — Existing mitigations may reduce the effective risk even if the vulnerability exists.

Risk-based prioritization is the exam-expected approach. Questions that present a list of vulnerabilities with different CVSS scores and asset contexts are testing whether you can pick the one that actually poses the greatest organizational risk — not just the highest CVSS number.

3. Remediate

Remediation is the action that eliminates or reduces the vulnerability. It can take several forms:

• Patching — Applying the vendor-supplied fix. This is the preferred remediation when available.
• Configuration change — Disabling a vulnerable feature, restricting access, or hardening settings.
• Upgrade or replacement — Moving to a newer version or different product when patches are not available for end-of-life software.
• Compensating controls — When patching is not possible (legacy systems, vendor dependencies, uptime requirements), applying mitigations such as network segmentation, WAF rules, IPS signatures, or virtual patching.

4. Verify

After remediation, you must confirm the vulnerability is actually fixed. Verification includes:

• Rescanning the affected systems to confirm the vulnerability no longer appears
• Validating that the patch or configuration change did not break functionality
• Confirming that the remediation was applied to all affected systems, not just a subset

Without verification, you have an assumption of security, not evidence of it.

The Patch Management Process

Patching is the most common form of vulnerability remediation, and it requires its own structured process. Applying patches directly to production without testing is reckless. Refusing to patch because of testing overhead is also reckless. The process must balance speed with stability.

Testing

Patches should be tested in a non-production environment that mirrors production as closely as possible. Testing validates that the patch:

• Installs successfully
• Does not break existing application functionality
• Does not conflict with other installed software
• Does not degrade system performance

The depth of testing should match the risk. A critical OS patch on 5,000 workstations warrants thorough testing. A security update for a niche utility on three systems may need less.

Staging

After testing, patches move to a staging environment or a pilot group — a small subset of production systems. This catches issues that only appear at scale or in specific production configurations.

Deployment

Production deployment should follow change management procedures (covered in Module 51). Deployment considerations include:

• Deployment windows — Scheduling patches during maintenance windows to minimize business disruption
• Rollback capability — Having a tested plan to reverse the patch if it causes production issues
• Phased rollout — Deploying to groups of systems incrementally rather than all at once
• Emergency patching — For actively exploited critical vulnerabilities, accelerated deployment may override normal change windows

Verification

Post-deployment verification confirms that patches were applied successfully across all target systems. Automated tools should validate patch presence, and any systems that failed to patch must be identified and addressed.

Zero-Day Response and Virtual Patching

A zero-day vulnerability has no vendor patch available. When one is disclosed — or worse, actively exploited — the organization must act without its primary remediation tool.

Zero-day response typically involves:

• Threat assessment — Determine if the vulnerability affects your environment and whether exploitation is active
• Compensating controls — Apply mitigations immediately: network segmentation, firewall rules, disabling affected features, restricting access
• Virtual patching — Deploying IPS or WAF rules that block exploitation attempts at the network or application layer without modifying the vulnerable system itself. Virtual patches buy time; they do not replace actual remediation.
• Vendor coordination — Engaging the software vendor for patches, workarounds, or timeline commitments
• Monitoring — Increasing detection and alerting for exploitation indicators specific to the vulnerability

The exam tests whether you understand that virtual patching is a temporary measure, not a permanent fix. It reduces exposure while waiting for a real patch, but it must be followed by actual remediation once a patch is available.

Vulnerability Management Program Metrics

A program without metrics cannot demonstrate effectiveness or improvement. Key metrics include:

• Mean time to remediate (MTTR) — Average time from vulnerability discovery to confirmed remediation, broken down by severity
• Scan coverage — Percentage of assets in the inventory that are being scanned regularly
• Patch compliance rate — Percentage of systems that have all required patches applied within policy SLAs
• Overdue vulnerabilities — Count and severity of vulnerabilities that have exceeded the remediation timeline defined in policy
• Recurrence rate — Vulnerabilities that reappear after remediation, indicating process failures in deployment or configuration management
• Exception count — Number of accepted risk exceptions and their age, ensuring they are reviewed periodically rather than forgotten

These metrics feed into management reporting and inform whether the program is keeping pace with the organization’s risk appetite.

Pattern Recognition

Patch and vulnerability management questions on the CISSP follow predictable structures:

• Prioritization scenario — Multiple vulnerabilities with different CVSS scores and asset contexts. The answer is the one with the highest business risk, not necessarily the highest CVSS score.
• “What do you do first?” with no patch available — Apply compensating controls or virtual patches. Never “wait for the vendor.”
• Patch caused an outage — The root cause is a testing or change management failure, not the patch itself.
• Scan results are inaccurate — The likely issue is unauthenticated scanning. Authenticated scans produce more accurate results.
• Vulnerability keeps reappearing — Configuration management or deployment process is failing. The fix is process improvement, not more scanning.

Trap Patterns

Watch for these incorrect answers:

• “Patch immediately without testing” — Even for critical vulnerabilities, some level of testing or validated compensating controls should precede deployment. The exception is an actively exploited zero-day where the risk of not patching exceeds the risk of a bad patch.
• “CVSS score alone determines priority” — CVSS is one input. Asset criticality, exploitability, and exposure must also factor into prioritization decisions.
• “Virtual patching is a permanent solution” — Virtual patches are temporary. They must be replaced with actual vendor patches when available.
• “Accept the risk and move on” — Risk acceptance requires formal documentation, management approval, and periodic review. It is never the default answer when other remediation options exist.

Scenario Practice

Question 1

A vulnerability scanner reports a CVSS 9.8 remote code execution flaw in a web server running an internal HR application. The same scan also finds a CVSS 7.2 privilege escalation vulnerability on the organization’s internet-facing e-commerce platform that processes credit card transactions. Both are on the remediation queue.

Which vulnerability should be remediated FIRST?

A. The CVSS 9.8 flaw on the HR application because it has the higher severity score
B. The CVSS 7.2 flaw on the e-commerce platform because it is internet-facing and processes payment data
C. Both should be remediated simultaneously since they are both high severity
D. Neither, until a formal risk assessment is completed by senior management

Question 2

A critical vulnerability is announced in the database software used by a hospital’s patient records system. Active exploitation has been confirmed in the wild. The vendor has released a patch, but the hospital’s normal patch testing cycle takes two weeks.

What is the BEST course of action?

A. Follow the normal two-week testing cycle to avoid introducing instability
B. Apply compensating controls immediately and accelerate patch testing on a compressed timeline
C. Apply the patch directly to production since the vendor has validated it
D. Disconnect the patient records system from the network until the patch is tested

Question 3

An organization scans its environment monthly and consistently finds the same 200 medium-severity vulnerabilities reappearing on application servers. The operations team reports they are patching these servers each month.

What is the MOST likely root cause?

A. The vulnerability scanner is producing false positives
B. Automated deployment processes are rebuilding servers from unpatched images, overwriting the applied patches
C. Medium-severity vulnerabilities do not have reliable vendor patches
D. Monthly scanning is too frequent and should be reduced to quarterly

Key Takeaway

Vulnerability management is a continuous cycle of discover, prioritize, remediate, and verify. The exam does not care whether you can configure a scanner — it tests whether you understand that CVSS scores without business context lead to bad prioritization, that patching requires testing and change management, that compensating controls are temporary by design, and that a program without metrics cannot prove it is working. When you see a vulnerability scenario on the exam, think about business risk first. The highest CVSS number is not always the right answer.