Patched on a schedule
you approved.
Patching is the maintenance everyone agrees is necessary and nobody has time for, so it slips until an audit or an exploit forces it. We run it as a routine: a known schedule, a tested order, a window you signed off on, and a record of what changed on which host.
Routine patching.
Plus a path for urgent ones.
Most updates can wait for the next window. A few cannot. Treating both the same way is how estates end up either permanently behind or permanently disrupted.
Patching cannot be planned against an unknown inventory. We establish what exists, which distributions and versions are in play, and which hosts carry workloads that constrain the window.
- Host inventory with distribution and version state
- Package and kernel drift across the estate
- End-of-life releases flagged for upgrade
- Dependency and reboot-order mapping
- Maintenance windows agreed per workload
Updates land on a test tier first, then production in an order that respects clusters and dependencies. Reboots are coordinated so a patch never becomes an unplanned outage.
- Test-tier validation ahead of production
- Cluster-aware ordering and rolling reboots
- Kernel and live-patch handling where supported
- Documented rollback position before each window
- Change records written as the work happens
When something is being actively exploited, the schedule stops mattering. We assess whether it reaches your estate, decide with you, and move out of band when it does.
- Advisory triage against your actual inventory
- Exposure assessment before anyone panics
- Out-of-band patching with your approval
- Mitigations when a patch is not yet available
- Written follow-up on what was changed and why
What patching solves.
What it doesn't.
- Known vulnerabilities with a vendor fix available
- Package and kernel drift across the estate
- End-of-life releases that no longer receive fixes
- Audit findings about unpatched systems
- Reboot coordination for clustered services
- A change record showing what moved and when
- Hardening, since a patched server can still be wide open
- Backups, because an update can go wrong like anything else
- High availability, if you cannot afford a reboot window
- Application-level fixes in code you own
Patching closes known holes on a schedule. Hardening changes the baseline itself, and high availability is what lets you reboot in the middle of the day.