My organization is extremely reluctant to patch or reboot Windows servers. We currently patch about once a month, but roughly 60% of our servers are excluded from automatic patching, leaving many systems without regular updates. Several servers have unresolved vulnerabilities rated 9 or higher.
I was reprimanded for trying to patch systems and even for raising the issue. I understand that patches can occasionally cause outages, but leaving critical vulnerabilities open also creates a serious security and business risk. Should vulnerability patching in production always go through a formal change request, and how should I handle management refusing or delaying the work?
4 Answers
Yes, production changes should normally have a change record, especially when reboots or application downtime are possible. The request should identify the affected systems, vulnerabilities, maintenance window, testing plan, rollback steps, backups, and the business owner’s approval. If management declines the change, ask them to document the exception, its business justification, an owner, compensating controls, and a review date. That makes the risk decision visible instead of leaving it assigned informally to the administrator.
Treat this as a business risk and governance problem rather than something you can solve by quietly patching servers. Prepare a short report listing the affected hosts, critical CVEs, exploitability, exposure, operational impact, and recommended remediation dates. Include particularly urgent vulnerabilities, such as those known to be actively exploited. If leadership still chooses not to patch, request written risk acceptance from the appropriate senior decision-maker. Do not bypass your manager’s instruction without following the organization’s escalation process.
Build a repeatable patching process instead of handling every server as a special case. Group systems by criticality, identify an owner for each application, patch a small pilot group first, use a defined maintenance window, and verify services after reboot. For important services, redundancy or clustering can allow one node to be patched while another keeps the service available. Exceptions should never be permanent settings; they need a reason, an owner, compensating protections, and a date for review.
Do not assume cyber insurance or compliance requirements will automatically protect the company, but check the policy and any applicable regulations. Some policies require reasonable vulnerability management, timely remediation, or documented exceptions, and failure to meet those conditions can complicate a claim. The same applies to audits. Keep records of the vulnerabilities reported, the recommendations made, approvals received, and any decision to defer remediation. The goal is to ensure leadership knowingly accepts the risk rather than allowing it to disappear into an automatic exclusion list.
That makes sense. We have multiple domain controllers, but many other systems were built without redundancy as the company grew. I’m going to focus on documenting ownership, maintenance windows, and exception reviews rather than arguing about individual servers.