Managed security
Patch Management
Boring, on a schedule.
Patch management is the routine of applying updates to operating systems, applications, servers and firmware on a known schedule, testing them before the whole fleet gets them, and producing a number showing what is current and what is not. happier IT runs it for Canadian organizations of roughly 15 to 200 people, including the part that is actually hard: the machines that keep failing and the one server nobody wants to restart.
Who it's for
Everyone has patching. Almost nobody has the number.
The gap is rarely a decision. It is that updates mostly apply themselves, so nobody notices the fraction that quietly does not.
Updates apply themselves, or they do not, and nobody knows which. Windows and macOS both patch themselves reasonably well when a machine is on, connected and restarted. The ones that fail fail silently, and a laptop that has not been restarted since March is not an unusual thing to find.
A questionnaire asked for patch compliance and there was no answer. Insurers and clients now ask for a percentage and a timeframe. Producing one requires an inventory of what you own, which is frequently the real gap the question exposes.
One application breaks every time it updates. A design tool, an accounting package, something industry-specific. So updates were paused on those machines for a good reason, and the pause was never revisited.
The servers are the exception nobody comes back to. They need a restart, a restart needs a window, and a window needs planning. So they wait, while holding the most valuable data you have.
Coverage is the number, not the policy
“We have automatic updates enabled” describes an intention. The measure is what percentage of the devices you actually own are current, this week, including servers and the laptops of people who work remotely.
If nobody can produce that figure, the first deliverable here is not patching. It is an accurate inventory.
What's included
What gets patched, and what happens when it fails.
Deploying updates is largely automatic. The service is the exceptions, and the exceptions are where the whole cost sits.
-
Operating system patching across Windows, macOS and Linux
Security updates on a defined cadence for every machine in the inventory, including laptops that rarely connect to an office network and servers that need a scheduled restart to complete anything.
-
Third-party application patching
Browsers, PDF readers, runtimes, conferencing tools, compression utilities. These are the applications most often out of date, because they update themselves only when the person using them clicks the prompt, and people are busy.
-
Server and firmware patching in a booked window
Servers, hypervisors and network device firmware handled inside a maintenance window agreed with you in advance, with a rollback path and someone available during it rather than a script running unattended.
-
A test ring before the fleet
Updates land first on a small deliberately mixed group, a finance machine, a field laptop, a designer, one server, for a short period. That is how an update that breaks a line-of-business application becomes two tickets rather than sixty.
-
Chasing the failures, which is the actual job
A device that reports a failed update, or has not checked in for weeks, gets followed up by a person: the disk is full, the agent is broken, the laptop belongs to someone who left. This is unglamorous work and it is what separates a patching service from a patching tool.
-
A documented exception process
Where a machine genuinely cannot be patched, an application that will not survive it, a system tied to equipment, the exception is written down with a reason, a compensating control such as network isolation, and a date to revisit it. An undocumented exception is just a gap.
-
Emergency out-of-band handling
When a vendor publishes a fix for something being actively used against systems like yours, it goes outside the normal cadence. There is a defined route for that, agreed in advance, so nobody is inventing a process during a busy week.
-
Reporting as a compliance number
Percentage of devices current, by category and by age of the outstanding update, with exceptions listed. Written so it can go straight onto an insurance renewal or into an audit response without being reworked.
How it works
Inventory, ring, chase.
The first month is mostly finding devices. That is normal, and the inventory turns out to be the more valuable deliverable.
-
Baseline the estate
Every device, its operating system, its current patch level, and which applications are installed on it. Reconciled against your asset list and your user directory, so the gap between what you own and what reports in is a number rather than a feeling.
-
Ring the rollout
Test group first, then the wider fleet, then servers in their own window. Cadence agreed with you, with a separate faster path for the urgent updates. Nobody in your organization discovers a maintenance window by finding their machine restarting.
-
Chase, document, report
Failures are followed up by a person until they succeed or become a documented exception with a compensating control. Monthly reporting shows the compliance number, what changed, and what remains outstanding with a reason.
What it costs
Per device, per month, with servers priced separately.
Servers cost more because they carry a maintenance window, a rollback plan and someone awake during it. Any quote that prices them the same as a laptop has not thought about it.
For happier IT managed IT
Our standard cadence is monthly for routine patching, inside a maintenance window we agree with you, and inside 72 hours out of band for anything critical, with notice before we touch it.
Patching tells you what is current. Vulnerability management is the separate practice that independently checks whether the gap actually closed, and prioritises what to fix next. They are different jobs and we price them separately, because marking your own homework is how a patching report ends up looking better than the estate does.
Why it never reaches 100%
Any provider promising complete patch compliance is describing a spreadsheet rather than an estate. There is always a laptop in a drawer, a machine tied to a piece of equipment, an application that will not survive the update.
What good looks like is a high and steady number, a short list of exceptions each with a reason and a compensating control, and a date when each will be revisited.
Why us for this
The tool is a commodity. The follow-up is not.
Every managed provider in Canada uses broadly similar patching tooling, and the deployment half genuinely is close to automatic. The difference between providers is entirely in what happens to the eight percent that fails: whether anyone notices, whether anyone rings the person whose laptop has not checked in since June, and whether the exception list is maintained or simply grows.
happier IT treats that follow-up as the service rather than as overhead, which is why the monthly report leads with the compliance number and the outstanding exceptions rather than with how many updates were deployed. Deployment counts are easy to make look impressive and tell you nothing about your risk.
The other half is judgement about timing. Applying every update the moment it appears occasionally breaks things; waiting a fortnight on everything leaves known gaps open longer than they need to be. We test on a ring, move urgent items faster than routine ones, and tell you which category a given update is in rather than treating them all the same.
Go deeper
- What is patch management? The plain definition.
- Vulnerability management The independent check that it worked.
- Managed IT services Where patching normally lives.
Questions
What people ask before they sign anything.
What is patch management?
Patch management is the process of applying software updates across every device and server you own, on a schedule, with testing beforehand and verification afterwards. Most of those updates fix security weaknesses the vendor has published a fix for. The process matters more than the tool: an inventory so you know what exists, a test ring so an update does not break work, a way to chase the machines that fail, and a report showing what is current.
How quickly should security patches be applied?
Faster for the ones being actively used against systems like yours, and on a steady routine cadence for everything else. That distinction matters more than any single number, because treating every update as urgent guarantees that nothing is. Both are stated in the agreement: monthly for routine patching, inside a maintenance window we agree with you, and inside 72 hours out of band for anything critical, with notice before we touch it. If a framework or an insurer has given you specific timeframes, send them to us and we will match the schedule to them.
What is the difference between patch management and vulnerability management?
Patching applies updates. Vulnerability management independently scans to find what is still exposed, ranks it by what it would actually mean in your environment, and confirms the fix worked. They are related and they are not the same job, and vulnerability management routinely finds things patching cannot fix: a service left enabled, a default configuration, a system nobody remembered owning. Run both, and keep the checking separate from the doing.
Will patching break our line-of-business application?
Occasionally, which is exactly why a test ring exists. A small mixed group gets updates first and sits with them for a short period before the fleet does, so a conflict surfaces on two machines rather than sixty. Where an application is known to be sensitive we hold it in the test ring longer and talk to the vendor. Where an update genuinely cannot be applied, that becomes a documented exception with a compensating control rather than a silent gap.
Do you patch servers as well as laptops?
Yes, and they are priced separately because they are more work. A server usually needs a maintenance window, a restart, a rollback plan and someone available during it. Servers are also the most commonly deferred category, for entirely understandable reasons, they hold the important things and restarting them is disruptive, which is why they end up furthest behind. Booking the window in advance is most of the solution.
How do you patch machines that are never in the office?
Through an agent on the device that works over the internet rather than requiring a connection to your network. That is how it should work now, and it is worth checking whether your current arrangement does: some older setups only patch when a machine is on the office network, which means remote and hybrid staff are quietly the least current in the organization. The check-in report will show that immediately if it is happening.
What does patch management cost?
Inside happier IT’s managed IT agreement it is included rather than being a line item. When comparing quotes, ask what happens when a device fails to patch three months running, whether a person follows it up, or whether it simply stays red on a dashboard.
Related
Where to go next.
Want to know what this would look like for you?
A 30-minute call. No slides, no audit fee, no obligation. We ask what is breaking and tell you honestly whether we are the right fit.