3.5.2. Patching, Change Management, and Risk Decisions
💡 First Principle: Every vulnerability has a response option — patch, compensate, accept, transfer, or avoid — and the right choice depends on the vulnerability's risk in context, the cost of remediation, and the organization's risk tolerance.
Patch and Configuration Management Process:
Testing — Patches are deployed to non-production first (dev → test → staging → production). Critical patches may compress this timeline (emergency change process) but never skip validation entirely.
Implementation — Phased rollout for broad patches; canary deployment (small initial group) for high-risk changes.
Rollback — Every patch deployment needs a defined rollback procedure. If the patch causes issues, what's the plan to restore the system to its prior state? Snapshot-based rollback (VMs) vs. manual rollback for physical systems.
Validation — After patching, re-scan to confirm the vulnerability is actually remediated. Version-based scanner detection confirms the patch was applied; authenticated scanning confirms the vulnerability is no longer present.
Maintenance Windows — Scheduled times for applying changes to minimize business impact. Critical systems may have narrow maintenance windows (overnight on weekends); some systems (HA clusters) can be patched in rolling fashion with no downtime.
Exceptions — When a vulnerability cannot be remediated per standard timeline (legacy system, vendor constraint, critical business process), an exception documents: the vulnerability, the reason remediation isn't feasible, the compensating controls in place, the residual risk, and the exception expiration date (requires re-review).
Risk Management Options:
| Response | When to Use |
|---|---|
| Mitigate | Apply the patch or implement a technical fix |
| Accept | Risk is below threshold, or cost of fix exceeds cost of impact |
| Transfer | Shift risk via cyber insurance or contractual SLA |
| Avoid | Decommission the system/service creating the risk |
| Compensate | Primary control infeasible; implement alternative controls (a form of mitigation) |
SLOs (Service-Level Objectives) for patching define timelines by severity: Critical within 24–72 hours, High within 7–14 days, Medium within 30 days, Low within 90 days. These SLOs vary by organization and regulatory requirement.
⚠️ Exam Trap: Risk acceptance is a formal, documented decision — not ignoring a vulnerability. Accepting risk means a responsible person with authority has evaluated the vulnerability, determined the risk is acceptable, and signed off. Undocumented "acceptance" is simply an unmanaged vulnerability.
Reflection Question: Your vulnerability scanner identifies a critical RCE vulnerability in a custom application used by the finance department. The vendor has released a patch, but the finance team says they cannot take the application offline for patching until after the quarterly close in 3 weeks. What risk management response options are available, and what should be documented regardless of which option is chosen?
