Patch Tuesday Meets the Change Advisory Board

The patch was available on Tuesday. The next approved change window was three weeks away. Between those dates sat an internet-facing remote access gateway and a change record marked “pending vendor confirmation.” By Friday, scanning IP addresses were hitting the perimeter.

The Change Advisory Board is doing exactly what it was chartered to do. It exists to prevent unvetted change from reaching production. The board was built to stop an administrator from taking down the ERP system on a Tuesday afternoon. Today, that same mechanism protects vulnerabilities from being patched. A process designed to prevent operational risk is generating security risk.

The dysfunction is structural. Security optimizes for time-to-patch. Operations optimizes for time-to-restore. When both teams are forced through a single change process, they fight over the same slot. The CAB treats a routine browser update and a core banking database migration with the same level of scrutiny. Both get four minutes on the agenda. Both get deferred.

The debates in these meetings usually revolve around numbers and schedules that do not reflect the actual risk. CVSS is not a prioritization scheme. A 9.8 on an internal, authenticated, segmented system and a 7.5 on an internet-facing, unauthenticated VPN concentrator are not the same problem. Most enterprises still sort by score because it is the only number everyone agrees on.

Vendor certification is another false constraint. When an application vendor says a patch is certified on their next quarterly release, they are stating their release train schedule. They are not conducting a risk assessment. Waiting forty-five days for a compatibility statement forces the customer to choose between voiding a support SLA and facing a breach. The risk decision still belongs to the enterprise. Waiting for vendor certification is how you document your way into a breach.

Then there is the spreadsheet of systems that cannot be rebooted. Every large shop has one. It lists the servers and appliances that run critical workloads but have not been restarted in three years because nobody knows if they will come back up. “We can’t patch it” usually means “we won’t staff it” or “we haven’t tested failover.” The system can be rebooted. Someone just has to be awake at 2 a.m. with a rollback plan and the authority to pull the trigger. The vulnerability exposes that operating condition. It did not create it. An un-rebootable server is a hostage situation you have accepted as normal.

Edge devices break every assumption built into the standard change process. You cannot agent them. You cannot easily stage them. The staging environment for a load balancer or an email gateway rarely matches production. Teams end up running patches through useless non-production environments simply to generate the screenshots required to pass a CAB audit. For an appliance, “patched” is not a state. It is a state plus a reboot plus a validation.

This reality exposes a deeper problem: you cannot tier what you cannot enumerate. Most large shops do not have an accurate, current list of internet-facing assets with firmware versions. The prioritization debate is often a proxy for that gap. A security analyst finds a newly disclosed flaw on an inventory report, only to discover the listed owner left the company, the appliance is managed by a network vendor, and its public IP address sits in a separate spreadsheet. The first hours of the incident go to establishing who is allowed to change it.

Fixing this requires separating the classes of change and deciding the rules during peacetime. You cannot draft an emergency bypass procedure while an exploit is actively scanning your perimeter. Defining paths during the incident is just an emergency change with extra steps.

The first step is tiered change authority based on exposure and blast radius, not department. An internet-facing, unauthenticated gateway with no compensating control belongs in Tier 1. It gets patched within 72 hours via a pre-authorized path. An internal, segmented database with compensating controls in place belongs in Tier 4 and follows the normal monthly cycle. The tier assignment is the risk decision. The patch is just execution.

This requires pre-authorized emergency paths with explicit guardrails. The path must exist before the incident. It includes a standing approval for a defined class of changes, a named approver on call, a rollback plan on file, and a post-implementation review. If the emergency change process is harder to use than the normal one, people will route around it. That is a process design failure, not a discipline problem.

When a patch must be deferred, the compensating control needs an owner and an expiry date. A risk acceptance without an owner is just deferral. If a compensating control has no named owner and no expiry, it is a permanent unfunded project with a security-sounding name. When the date passes, it escalates.

For vendors that will not certify a patch on your timeline, the enterprise needs a formal policy. The business can accept the risk of voiding support SLAs in exchange for closing the vulnerability window, or it can isolate the system, or it can replace the vendor. Waiting for the vendor is an unowned decision.

The metrics that matter are in the tail of the distribution, because the mean hides the systems that are actually exposed. Track the time from patch availability to production deployment by tier. Track the percentage of emergency changes that followed the pre-authorized path, and count the compensating controls that have passed their expiry.

The time to decide which systems get patched first is before the vulnerability drops, not during the incident bridge.