cisspSecurity Operations· 10 min read· 20 May 2026
Vulnerability and Patch Management: The CISSP Manager’s Approach
Vulnerability and patch management is the systematic process of identifying weaknesses in systems and eliminating or mitigating them before they can be exploited. For the CISSP exam, these are tested as management processes — not as technical procedures — with emphasis on the lifecycle, governance requirements (especially change management), and strategic decisions like zero-day response. The exam rewards candidates who understand that patch management without change management is as dangerous as no patch management at all.
Vulnerability Management Lifecycle
The vulnerability management lifecycle is a continuous cycle of four core activities.
Discover: identify assets and their vulnerabilities through automated scanning, manual assessment, threat intelligence, and vendor notifications. Discovery tools (Nessus, Qualys, Rapid7) scan systems against databases of known vulnerabilities (CVE, NVD) and identify misconfigurations, missing patches, and weak configurations. Asset discovery is a prerequisite to vulnerability scanning — you cannot scan what you do not know exists.
Prioritise: rank discovered vulnerabilities by risk to determine remediation order. Not all vulnerabilities can be remediated simultaneously, and not all vulnerabilities pose equal risk. Prioritisation factors include severity (CVSS score), exploitability (is there a public exploit? is it being actively used in the wild?), asset criticality (is this vulnerability on a system that supports critical business functions?), and exposure (is the vulnerable system internet-facing or isolated on an internal network?).
Remediate: apply the appropriate fix. Remediation options in decreasing order of preference are: patching (applying the vendor-supplied patch), configuration change (changing settings to eliminate the vulnerability without a patch), compensating control (implementing a control that reduces the risk without eliminating the vulnerability), and risk acceptance (formally accepting the residual risk when remediation is not feasible).
Verify: confirm that the remediation was successful. Re-scan the system after patching to verify that the vulnerability no longer appears. Verification is a critical step that is often skipped under operational pressure. Unverified patches may not have been applied correctly, may have been rolled back by another process, or may not have fully addressed the vulnerability.
For the exam: the lifecycle is discover → prioritise → remediate → verify, and it repeats continuously. Verification is as important as remediation.
CVSS Scoring and Prioritisation
The Common Vulnerability Scoring System (CVSS) is the industry-standard framework for rating the severity of security vulnerabilities. CVSS scores range from 0.0 to 10.0 and are based on three metric groups.
Base metrics describe the intrinsic characteristics of a vulnerability that are constant regardless of environment: attack vector (how the vulnerability is accessed — network, adjacent, local, physical), attack complexity (how difficult the attack is to execute), privileges required (what level of access the attacker needs), user interaction (whether a user must take an action for the exploit to succeed), scope (whether exploitation affects components beyond the vulnerable one), and impact metrics (confidentiality, integrity, and availability impact).
Temporal metrics adjust the base score based on factors that change over time: exploit code maturity (is there a working exploit? is it widely available?), remediation level (is a patch available?), and report confidence (how certain is the vulnerability's existence?).
Environmental metrics allow organisations to customise the score based on their specific environment: is the vulnerable component critical in this environment? Are compensating controls already in place?
For the exam: CVSS provides a standardised severity rating. However, CVSS base score alone is not sufficient for prioritisation — organisations must also consider asset criticality and whether the vulnerability is being actively exploited. A CVSS 10.0 on an isolated, non-critical system may be lower priority than a CVSS 7.5 on an internet-facing system storing sensitive customer data.
Change Management Gates: Why Patches Fail When CM Is Bypassed
Change management is the governed process for reviewing, approving, scheduling, implementing, and verifying changes to IT systems. Effective patch management must integrate with change management — patches are changes, and they carry risk.
A patch that is applied without testing or change approval can:
Break critical business applications (a patch to the Windows kernel may affect line-of-business applications that depend on specific system behaviours)
Cause unexpected outages (patches sometimes require reboots that are disruptive if unscheduled)
Introduce new vulnerabilities (patches can contain bugs, though this is rare)
The change management gate requires that patches be: tested in a non-production environment first (to identify application compatibility issues), approved by a Change Advisory Board (CAB) before production deployment, scheduled during a maintenance window with appropriate stakeholder notification, documented with a rollback plan (in case the patch causes issues and must be reversed), and verified post-implementation.
Emergency change procedures exist for critical patches that must be applied immediately (due to active exploitation). Emergency changes bypass the normal CAB approval cycle but still require documented authorisation from an appropriate authority, post-implementation review, and formal documentation.
For the exam: change management is not bureaucratic overhead — it prevents outages caused by untested patches. When a question describes a patch being applied without approval or testing, the correct answer identifies the missing change management step.
Patch Testing in Non-Production Environments
Patch testing in non-production (test/staging) environments validates that patches do not break applications before they are applied to production. A proper testing environment mirrors the production environment as closely as possible: same OS versions, same application configurations, same data (or representative test data).
The testing process: apply the patch to the test environment, execute test scripts (automated regression tests) to verify that existing functionality is not broken, check application performance metrics, and document the results. If testing passes, the patch proceeds to the change management approval process for production deployment. If testing reveals issues, the patch is held and the vendor is notified of the compatibility problem.
For exam scenarios: when asked about the correct sequence for patch deployment, the answer is: test in non-production → get change management approval → deploy to production → verify.
Zero-Day Management and Compensating Controls
A zero-day vulnerability is a vulnerability for which no vendor patch is yet available — either because the vendor does not know about it or because a patch has been developed but not yet released. Zero-days are high-risk because the vulnerability window is open with no direct remediation.
Zero-day management relies on compensating controls — security measures that reduce the risk of exploitation without eliminating the vulnerability:
Network segmentation and access control: restricting access to the vulnerable system limits the attacker population that could exploit the vulnerability. If the vulnerable service is only accessible to internal users, internet-based attackers cannot exploit it.
Application whitelisting: preventing execution of unauthorised code limits the damage even if the vulnerability is exploited.
Intrusion detection and prevention systems: tuning IDS/IPS signatures for the attack patterns associated with the zero-day can detect and block exploitation attempts even before a patch is available.
Virtual patching: WAF rules or IPS signatures that block the specific requests or traffic patterns associated with the zero-day attack. Virtual patching is a temporary measure that provides protection while awaiting an official patch.
Increased monitoring: elevating the monitoring and alerting on the vulnerable system to detect exploitation attempts promptly.
For the exam: when a patch is not available (zero-day), the CISSP answer involves compensating controls that reduce risk. Risk acceptance with compensating controls and enhanced monitoring is the correct approach.
Exam Tip
CISSP tests the management process, not technical details. For vulnerability management: discover, prioritise, remediate, verify — in that order. For patch management: test, approve (change management), deploy, verify. Change management prevents patches from causing outages. Zero-days require compensating controls when patches are unavailable. The exam will distinguish between correct process (with change management and testing) and shortcut process (deploying without testing) — the shortcut is always wrong.
// PRACTICE_THIS_DOMAIN
Test your knowledge on Security Operations
AI-generated practice questions mapped to this domain. Get instant explanations and track your progress.