My organization is extremely cautious about server downtime and reboots. We patch roughly once a month, but about 60% of our servers are excluded from automatic patching, leaving many systems without regular updates. There are currently numerous servers with actively exploitable, high-severity vulnerabilities, including CVEs rated 9 or higher. I was reprimanded for trying to patch systems and even for raising the issue. I understand that patches can disrupt production, but I'm trying to keep the environment secure. Should vulnerability patching go through a formal change request, and how should I handle management's decision not to patch?
4 Answers
Do not bypass your organization’s approval process just because the patches are important. You have already done the right thing by identifying and raising the risk. Keep the written instruction not to patch, document the affected vulnerabilities, and escalate through the appropriate security, compliance, or senior-management channel. If there is no formal change process, proposing one is better than making undocumented production changes, even though the lack of patching remains a serious security problem.
Treat this as a risk-management problem, not just a technical argument. Put together a short summary of the affected systems, exploitability, whether any vulnerabilities are actively being used, business impact, and the likely consequences of a compromise. Management may not react to a CVSS score alone, but they usually understand ransomware, data loss, recovery costs, and unplanned downtime. Also check whether your cyber-insurance requirements or industry regulations require timely patching; failing those requirements could affect coverage or compliance.
Yes, production changes should normally have a change request, especially when a reboot could affect an application. The request should identify the affected hosts, the vulnerabilities, the maintenance window, testing plan, backup or recovery steps, and who approved it. If leadership still decides not to patch, ask for that risk acceptance and the reason for the exception in writing. That makes the business owner accountable for the decision rather than leaving the risk attached to the administrator.
Make sure exceptions have an owner, a documented reason, compensating controls where possible, and an expiration or review date. Otherwise a temporary exception easily becomes permanent.
Build a repeatable patching process instead of handling every server as a separate emergency. Group systems by criticality, identify application owners, patch a small test group first, schedule a regular maintenance window, and define rollback and validation checks. For important services, use redundancy or clustering so nodes can be patched one at a time. Backups and VM snapshots can help with recovery, but snapshots should be temporary and should not replace tested backups.
Redundant domain controllers and clustered services can usually be maintained without taking the whole service offline. The long-term fix is designing systems so routine maintenance is expected rather than avoided.
If the organization chooses not to patch, get formal sign-off from someone authorized to accept that risk. A verbal instruction from a direct manager may not be enough if there is later an audit or incident.