“Remind me tomorrow” is an understandable choice when an update appears in the middle of a deadline. It becomes a problem when tomorrow keeps moving. A patching plan has to account for the person trying to work and the vulnerability that still needs to be fixed.
Patch management means finding updates, deciding what needs attention first, deploying them, and checking that they actually installed. NIST describes it as preventive maintenance for technology. That is a useful way to think about it: planned upkeep usually gives you more choices than dealing with a failure during the working day.
Source: NIST SP 800-40 Revision 4, enterprise patch management
There is more to update than Windows
Operating systems matter, but so do browsers, business applications, remote access tools, and device firmware. A firewall or wireless access point can need a security update even while it seems to be working normally. Start with an inventory so the patching conversation covers the systems you actually use.
Some products update automatically. Others need a scheduled maintenance window or a vendor’s involvement. A specialist application may need testing before a change. Record those differences. “It updates itself” is a claim worth verifying, particularly when a device has been offline or an installer keeps failing.
Prioritize by exposure and business impact
A vulnerable internet-facing gateway and a low-risk update to an isolated workstation do not automatically deserve the same timetable. Consider active exploitation, whether the affected feature is enabled, the device’s exposure, and what a failed update would interrupt. CISA’s Known Exploited Vulnerabilities catalog can inform prioritization; it is not a complete list of every vulnerability that matters.
Source: CISA Known Exploited Vulnerabilities catalog
- Define a normal update cadence and a faster path for urgent security fixes.
- Choose maintenance windows with the people whose work will be affected.
- Make a recovery or rollback plan for systems where interruption matters.
- Track devices that fail to update, remain offline, or keep postponing restarts.
A deployment report is not the finish line
Sending an update is different from confirming installation. Some updates need a restart. Some machines run out of space. Others are no longer reporting correctly. Useful reporting shows the exceptions and who is working on them, rather than presenting a green dashboard while the same few devices stay behind.
RIKR uses Ninja RMM for remote management, patching, and support. It gives our team a way to manage supported devices and investigate issues centrally. The tool helps carry out the work; judgment is still needed for application compatibility, scheduling, and the devices that need a different approach.
Know when maintenance is no longer enough
An end-of-support product may no longer receive the fixes it needs. Keeping it powered on does not extend its support life. Plan replacement early enough to review dependencies, migrate data, and avoid forcing the purchase during an outage. When immediate replacement is not practical, document the risk and the temporary controls rather than quietly accepting it.
The practical outcome is fewer unmanaged exceptions and fewer technology chores landing on someone whose actual job is running the business. If you are the person chasing every restart, that is a reasonable point to bring in help.
Related: why your firewall needs maintenance too
Explore RIKR managed IT support
Written by Joshua Price
Back to the blog