Managed IT
Security budgets tend to go toward the things that are interesting to buy. Patching is not one of them. It has no dashboard worth showing the board, it never prevents an incident anyone can point at, and it is the single most reliable way attackers get in. Most businesses believe they are doing it. Fewer can produce a report showing what is currently unpatched, which is the same thing as not doing it.
Ask a room of IT leaders whether they patch and every hand goes up. Ask how many devices are more than thirty days behind right now and the room goes quiet. That gap between the policy and the fleet is where most breaches actually happen, and it is almost never caused by anyone deciding patching does not matter.
Why patching outranks everything else
The evidence here is unusually one-sided, which is what makes the neglect strange.
Verizon's Data Breach Investigations Report identifies unpatched vulnerabilities as the leading exploit method in confirmed data breaches. Not novel attacks, not zero-days, not sophisticated tradecraft. Known problems with published fixes.
The Ponemon Institute puts a finer point on it: 57% of breaches are linked to a known vulnerability where a fix was available and never applied. Somebody had already done the hard part. The patch existed, was tested, was shipped, and sat there.
And when something does go down, Gartner's figure for unplanned IT downtime is around $5,600 per minute. Most outages of that kind are preventable, and a meaningful share of them trace back to maintenance that kept getting deferred.
The zero-day distraction
Security conversations gravitate toward novel threats because they are more interesting. They are also rarer and much harder to defend against. Meanwhile the attack that actually works is a scan for an unpatched service that has had a fix available for eight months. Defending against that requires no threat intelligence and no new product. It requires knowing what you have and keeping it current, which is unglamorous work that nobody gets promoted for.
Why it fails in practice
The Failure Modes
Nobody sets out to run unpatched systems. Patching fails for three specific reasons, and they need different fixes, which is why "we should patch more" never works as a remediation plan.
Symptom
You cannot patch what you cannot see
Unmanaged devices · Remote laptops · Forgotten servers · Stale inventory
Patch compliance reports are calculated against the devices the tool knows about, which makes them structurally optimistic. The laptop belonging to someone who left in March, the server running one legacy application that nobody wants to touch, the machine that has not checked in since the office moved: none of those drag your reported percentage down, because none of them are counted. A patch report showing 98% compliance across a fleet that is missing a fifth of its devices is not a good number. It is a measurement of the wrong population.
Symptom
Fear of breaking something
One bad update · No test group · No rollback plan · Indefinite deferral
This one is rational in origin and disastrous in effect. An update breaks a line-of-business application, the team spends a weekend recovering, and the lesson learned is to wait. Waiting has no defined end, so deferral quietly becomes policy. The underlying problem is not the risk of a bad patch, which is real. It is that there is no staged rollout to catch it and no rollback plan to recover from it, so every update is an all-or-nothing bet and the safest-looking move is always to postpone.
Symptom
Everything that is not the operating system
Third-party apps · Browsers and plugins · Firmware · Network devices
Windows Update solved one part of this well enough that people mistake it for the whole job. Attackers did not stop at the OS. Document readers, browsers and their extensions, runtime frameworks, and the firmware on firewalls, switches and printers are all reachable and all patched on entirely separate schedules by entirely different mechanisms. Network device firmware is the most commonly neglected of the lot, partly because updating it usually means planned downtime that somebody has to approve.
They compound
These rarely appear alone. Incomplete inventory hides how far behind you are, which makes deferral feel less costly than it is, which means third-party software goes years without attention because nothing is flagging it. By the time anyone looks properly, the remediation list is long enough to be its own project, and projects get scheduled rather than done.
What good patch management looks like
Five things, and none of them require a product you do not already have access to.
An inventory you trust
Everything starts here, because every other number is calculated against it. That means automated discovery rather than a spreadsheet somebody maintains, a defined owner for each device, and a process for retiring machines that leave. If your inventory is manual, assume your patch compliance figure is higher than reality by roughly the number of devices nobody remembered to add.
A cadence, and a faster lane for emergencies
Regular patching on a predictable schedule handles the routine flow. Alongside it you need an out-of-band path for the handful of vulnerabilities each year that are being actively exploited and cannot wait for the next window. Most organizations run something like a monthly cycle for standard updates with an emergency route measured in days. Treat those as common practice rather than a standard, and set your own intervals against your risk and your change-control reality.
Staged rollout
Deploy to a small pilot group first, then a broader ring, then everything. This is the single change that breaks the fear cycle, because it converts "this update might break production" into "this update broke twelve machines in the pilot ring and we stopped." Pick a pilot group that actually resembles the fleet, including the awkward line-of-business applications, or you will validate nothing.
A rollback plan you have tested
Knowing you can reverse an update is what makes it possible to apply updates promptly. An untested rollback plan is a hope. Test it on the pilot ring occasionally so that when you need it under pressure, it is a procedure rather than an experiment.
Reporting somebody actually reads
A monthly report showing what is outstanding, how old the oldest unpatched item is, and which devices are consistently missing windows. The age of the oldest gap is the most useful single number, and it is the one most reports omit in favor of a compliance percentage that flatters.
Where automation fits
Patching is repetitive, time-sensitive and unrewarding, which makes it exactly the kind of work that gets deprioritized when a person owns it and something urgent arrives. Automating deployment across the fleet removes the failure mode where a patch is skipped because the person responsible was pulled onto an outage. It does not remove the need for inventory, staged rollout or someone reading the reports. Automation fixes the execution, not the process around it.
IT Health Assessment Checklist
The Checklist
Fifteen questions across patch status, monitoring, inventory and the gaps between them. Tick the ones you can answer without going and asking someone, and the score updates as you go. Use it yourself or share it with your team.
Tick what you can answer without checking. The blanks are the gaps.
Patch Status
What is the oldest unapplied patch in your environment right now?
The single most revealing question on this list, and the one most patch reports quietly avoid answering.
Do you patch third-party applications, not just the operating system?
Document readers, browsers and their extensions are reachable and are patched on entirely separate schedules.
When did you last update firmware on firewalls, switches or printers?
The most commonly skipped category, usually because updating it needs planned downtime somebody has to approve.
Is there a faster path for vulnerabilities being actively exploited?
A few each year cannot wait for the next window. If everything goes through one cadence, those wait too.
Monitoring Coverage
Would you know if a device simply stopped reporting in?
Silence reads as healthy on most dashboards, which is exactly how machines fall off the map.
Does anyone see alerts outside business hours?
Monitoring that nobody watches overnight is logging. It is useful afterwards and prevents nothing.
Are alerts triaged, or does everything page with equal urgency?
When everything is critical, people start ignoring the queue, and the real one arrives into that habit.
Do you usually find out about failures before the user calls?
If the help desk is your monitoring system, you are detecting outages at the slowest possible point.
Device Inventory
Is your inventory automated, or maintained by hand?
A manual inventory is a snapshot of what someone remembered, and it only ever drifts in one direction.
How many devices have not checked in for thirty days?
Those are the ones missing patches, and they are also the ones missing from the compliance number.
Is there a process for retiring a device when someone leaves?
Without one, the fleet accumulates machines that are nobody's responsibility but still hold credentials.
Does your compliance percentage include devices the tool cannot see?
It does not. That is the point. A high score across a partial fleet is a measurement of the wrong population.
Support Gaps
Who patches when the person responsible is away?
If patching depends on one person's calendar, it has a scheduled outage built into it every time they take leave.
Is there a documented rollback for a bad update, and has it been tested?
An untested rollback is a hope. Knowing you can reverse an update is what makes it safe to apply one promptly.
Could you produce a patch report for an auditor or insurer this week?
Cyber-insurance questionnaires increasingly ask. Assembling the answer after the request is the expensive way to do it.
Frequently asked questions
Patch management is the process of tracking, testing and applying updates that fix security vulnerabilities and bugs across every device and application in an environment. It covers operating systems, third-party applications such as browsers and document readers, and the firmware on network hardware like firewalls, switches and printers. The process matters as much as the tooling, since it also involves maintaining an accurate device inventory, staging rollouts to catch bad updates, and reporting on what remains outstanding.
Because unpatched vulnerabilities are the leading exploit method in confirmed data breaches, according to Verizon's Data Breach Investigations Report. The Ponemon Institute found that 57 percent of breaches are linked to a known vulnerability where a fix was available and had never been applied. These are not novel attacks. They are published problems with published fixes, which makes patching the highest-impact security work available to most businesses and also the least visible when it is working.
Most organizations run a regular cycle for routine updates alongside a faster out-of-band path for vulnerabilities being actively exploited, which cannot wait for the next scheduled window. A monthly routine cadence with an emergency route measured in days is common practice rather than a formal standard, so set your own intervals against your risk profile and change-control reality. What matters more than the interval is that both paths exist and that somebody owns each of them.
Vulnerability management is the broader discipline of finding, assessing and prioritizing weaknesses across an environment. Patch management is the part that applies fixes. A vulnerability scan tells you what is exposed and how serious it is, including issues with no patch available that need a configuration change or compensating control instead. Patch management is how the fixable subset actually gets closed, which is why a scanning tool alone tends to produce a long report and little change.
Three reasons, and they need different fixes. Incomplete inventory means the devices missing patches are often the ones missing from the tooling, so compliance figures look better than reality. Fear of breaking a business application turns one bad update into indefinite deferral when there is no staged rollout or tested rollback. And coverage tends to stop at the operating system, leaving third-party applications and network firmware on separate schedules that nobody owns.
Yes, through a staged rollout rather than a separate test environment for every update. Deploy to a small pilot group first, then a wider ring, then the rest of the fleet. This converts the risk from an all-or-nothing bet on production into a problem that surfaces on a handful of machines while you can still stop. The pilot group needs to resemble the real fleet, including the awkward line-of-business applications, or it validates nothing useful.
It needs deliberate coverage, because operating system updates handle only part of the attack surface. Browsers and their extensions, document readers, runtime frameworks and network device firmware are all reachable by attackers and all update on their own schedules through their own mechanisms. Firmware on firewalls, switches and printers is the most commonly neglected category, largely because applying it usually requires planned downtime that somebody has to approve in advance.
Yes, and it suits outsourcing well because the work is repetitive, time-sensitive and easy to deprioritize when the person responsible gets pulled onto an outage. A managed provider can run discovery, deployment, staged rollout and reporting across the fleet continuously. What does not transfer is ownership of the decisions: which systems can tolerate a maintenance window, what the emergency threshold is, and who approves downtime for firmware. Agree those in advance rather than discovering them during an incident.
Not sure what's actually unpatched?
Get a free IT health assessment. We'll walk the checklist with you and show you what the reports aren't counting.
