Vendors release their fixes, the security team reminds everyone of the deadlines, and operations starts emailing service owners. When can the application servers be rebooted? Is Tuesday night acceptable, or does it have to wait for the weekend? What about the system that took longer than expected to come back last time? Answers arrive late, some not at all. In the end, part of the estate gets patched and the rest is pushed “to next month”.
This cycle repeats every month and drains energy on both sides. Administrators are frustrated that they cannot do the work they are responsible for. Service owners feel that operations is always asking them for something. And security watches the backlog of deferred fixes grow.
Why the same question keeps coming back
We often see patching run as a series of one-off events. Each month brings a new server list, a new set of outage requests and a new round of approvals. Yet most of the answers do not change from month to month: the service still has the same business hours, the same redundancy and the same owner.
So the problem is not that people are unwilling to agree. The problem is that the agreement is never written down, and next month everyone starts from scratch. Other weaknesses add to it:
- it is unclear who decides for a service, so the request bounces between several people,
- servers are patched one by one from a list, not by service and its dependencies,
- redundant nodes are sometimes rebooted at the same time, because only a few people know they are redundant,
- a critical fix waits in the same queue as a routine monthly update.
How to approach it
Rather than negotiating every month, it is better to reach one agreement with the service owner that stays valid until someone deliberately changes it. The agreement states when patching may happen, whether patching within that window is pre-approved, and how redundant nodes are handled. Monthly planning then stops being a question of “may we?” and becomes simply “what is next?”.
The second principle is to separate the routine path from the urgent one. A critical vulnerability should not wait for the next standing window, but it should not bypass the service owner entirely either.
How Eywo Stratum handles it
Eywo Stratum introduces a patch agreement between operations and the service owner. It covers:
- a standing window – a regular time when the service may be patched,
- pre-approved patching within the window – changes covered by the agreement do not need a fresh outage approval every month,
- rolling patching of redundant nodes – nodes in a redundancy group are patched one at a time so the service stays available,
- an expedited mode for critical issues – a shorter path for severe vulnerabilities, agreed in advance by both sides.
A proposed patch agreement lands in the service owner's single “To approve” queue, alongside change outages and requests. One rule defines who the owner is; if a service has no owner, the change manager decides. A rejection always comes with a reason, so operations knows what to adjust.
Patch agreements feed into a wave-based patching plan. Servers are grouped into waves according to their services and windows, and the plan generates the corresponding changes in a single step. Those changes go through the same checks as any other change in the system: impact on services, maintenance windows, freezes and collisions. The vulnerability and remediation dashboard then shows how the work is progressing.
Agree once, rest easy every month
Patching does not have to be a monthly negotiation. Once it is agreed when and how a service gets patched, administrators can work to a plan, service owners know what to expect, and security can see fixes actually reaching production. The conversation with the service owner happens occasionally and is about what matters, not the same question every month.
Patch agreements, wave-based patching plans and the remediation dashboard are included in the Business edition.
Eywo Stratum Business
For operations that want to connect monitoring, security and vendors.