Patch management.
Updates are not an event but a rhythm. We roll them out in rings, in agreed windows, with documented exceptions — and every failure is followed up, not ignored.
- Operating systems and applications (third-party), not just Windows
- Rings: pilot → subset → everyone, with a gap in between
- Server maintenance windows are agreed, snapshot beforehand
- Exceptions are documented — with reason and end date
- Failures create a ticket, not a silent gap
Patch management
We keep operating systems (Windows, macOS, Windows Server, common Linux distributions) and applications (browsers, Office, PDF readers, runtimes, communication clients) current. Firmware and drivers after approval. Distribution runs through the RMM agent on every device; on Entra-managed devices, Intune policies complement Windows Update control.
Monthly patch report
Documented per device: what ran when — and what is still open. This is the report you can show an insurer or auditor.
- Device and user
- OS version and build
- Missing updates by criticality
- Last successful installation
- Exceptions with reason and end date
- Overall compliance rate
Patch management — the parameters.
Values set per client are marked "agreed per client".
Ring 0: our own devices plus a few pilot devices at the client · Ring 1: a subset of workplaces · Ring 2: everyone. A gap of typically a few days between rings — enough to see side effects.
Microsoft updates after the monthly patch day; application updates continuously after ring-0 approval. The exact cadence is agreed per client.
Actively exploited vulnerabilities (e.g. CISA KEV list, vendor emergency updates) leave the ring cadence: rollout right after ring-0 verification, and we inform you.
Agreed window outside working hours; snapshot or backup check beforehand; reboot inside the window; service check afterwards.
Users are informed and can postpone — up to an agreed deadline, after which the reboot is enforced.
Line-of-business applications with version pinning are excluded — documented with reason, owner and end date. There are no exceptions without an end date.
Automatic second attempt; then a ticket with device, update and error picture. No device is left behind unnoticed.
With what — and what is replaceable.
| Tool | Role | Data location | Replaceable by |
|---|---|---|---|
| RMM-Plattform | Agent on every device: distribution, rings, reboot control, reporting | EU instance | any RMM with a patch module |
| Intune / Windows Update for Business | Update policies for Entra-managed devices | your Microsoft tenant | Group Policy (on-prem AD) |
What we deliberately do not do
- No rollout without a ring — not even for "just a small update"
- No firmware or BIOS updates without approval and backup
- No server updates without a maintenance window and snapshot
- No exception without an end date
Prerequisites on your side
- RMM agent on every device (rolled out during onboarding)
- Complete device inventory
- Agreed maintenance windows for servers
- A contact at the client who approves exceptions
Questions from IT
Our line-of-business app only runs with a specific Java or browser version. What then?
Then exactly that component is excluded on the affected devices — documented with reason and end date — and everything else keeps getting patched. We ask the vendor when the pinning ends and record the date.
What happens with an actively exploited vulnerability?
It leaves the normal cadence: verification in ring 0, then immediate rollout, and we inform you with affected devices and status. If a reboot is needed, we say so.
Do you patch Linux servers too?
Yes — common distributions via the agent or the package manager in the agreed window. Kernel updates with reboot are planned like Windows server windows.
Can employees postpone reboots?
Yes, up to an agreed deadline. After that the device reboots — with warning, but without further extension. An update that never becomes active is not an update.