Most patching programs fail for a boring reason: they depend on someone remembering. A patch policy that lives in a document and a person’s good intentions will drift within a quarter. What works is a small routine with a fixed calendar slot, a short list of things it covers, and a clear rule for what jumps the queue.

Start With What You Actually Run

You cannot patch what you have not listed. Before designing a schedule, write down the categories of software that need updates, because each one patches differently:

• Operating systems on laptops, desktops and servers
• Browsers and their extensions
• Business applications installed locally
• Network gear such as routers, firewalls and access points
• Server software, libraries and container base images
• Mobile devices that touch company data

In practice, the category that gets forgotten is network equipment. Firmware updates on a router or firewall are rarely automatic, and these devices sit in front of everything else. Put them on the list explicitly.

Automate the Boring Majority

Operating systems and browsers on managed laptops should update automatically wherever your management tooling allows it. Don’t spend human attention on work a setting can do. Reserve manual effort for the systems where an update can break something: servers, line-of-business software, and anything with a custom integration.

A common trap is turning on auto-update and then never checking that it worked. Machines that are asleep, offline for weeks, or low on disk space quietly fall behind. Once a month, pull a report from your management tool (or check a sample of machines by hand) and look for devices that are well behind the rest.

Decide What Jumps the Queue

Not every patch deserves the same urgency. Agree on a short set of rules in advance so that nobody has to debate it while a headline is running.

Situation	Suggested response window
Vulnerability is being actively exploited and affects something you run	Treat as urgent; patch or mitigate within days, not weeks
Internet-facing system with a serious flaw	Next available maintenance window at the latest
Internal system, serious flaw, no known exploitation	Regular monthly cycle
Low-severity or hard-to-reach flaw	Fold into the next routine cycle
End-of-life software with no patches	Plan replacement; isolate in the meantime

The windows above are a starting point, not a standard. Your own tolerance depends on what the system does and how exposed it is. Check each vendor’s current security advisories for severity ratings, and consider whether a public vulnerability catalog lists the flaw as exploited in the wild.

A Monthly Rhythm That Works

Pick one recurring slot. Many teams use the week after the vendors’ regular monthly releases, but any consistent day works. A workable cycle looks like this:

1. Collect. Review vendor advisories for the products on your list.
2. Triage. Sort items with the rules above.
3. Test. Apply updates to a small pilot group first.
4. Deploy. Roll out to everyone else after a short waiting period.
5. Verify. Confirm the update landed, not just that it was sent.
6. Record. Note exceptions and who owns them.

The pilot group matters more than it sounds. Pick a handful of people across different roles, including at least one who uses the awkward software, and let them run the update for a few days. If something breaks, you find out from five people rather than fifty.

A Hypothetical Example

Imagine a twenty-person company with one part-time IT administrator. Laptops update automatically. A finance application, however, depends on an older runtime, and the last two updates broke its report export.

The administrator does not skip those updates. Instead, they set a test copy of the application on a spare machine, apply the update there first, and run the three reports finance depends on. If they pass, the update goes out. If they fail, the administrator records an exception with an owner, a date to revisit, and a compensating control, such as restricting which machines can reach the application. The point is that “we can’t patch this yet” becomes a tracked decision rather than a silent gap.

When You Genuinely Cannot Patch

Sometimes you can’t. The vendor is gone, the software is old, or an update would break something the business needs. Don’t leave it unmanaged. Options, roughly in order of preference:

• Apply the vendor’s workaround or mitigation if one exists.
• Reduce exposure: remove it from the internet, segment it, limit who can reach it.
• Add monitoring so unusual behavior around it gets noticed.
• Set a replacement date and put it on a real plan.

Write the exception down. A documented, time-limited exception is a risk decision. An undocumented one is an accident waiting to be found.

Mistakes to Avoid

• Patching only the operating system and ignoring third-party applications and plugins.
• Skipping the verification step, so a failed rollout looks identical to a successful one.
• Letting “temporary” exceptions run for years.
• Having no rollback plan for servers, such as a snapshot or backup taken beforehand.
• Treating the pilot group as optional when the update touches something critical.

Frequently Asked Questions

How often should a small team patch? Run a regular cycle on a fixed schedule, usually monthly, and keep a separate fast lane for serious or actively exploited flaws. Automatic updates on endpoints cover the rest.

Should we patch immediately when an update is released? Not always. For ordinary updates, a short delay with a pilot group catches breakage. For flaws known to be exploited, speed matters more and the delay should shrink or disappear.

What about devices employees own? If personal devices access company data, require basic standards such as supported operating system versions and automatic updates. Your management tooling or access policy can enforce this for sign-in.

Do cloud services need patching? The provider patches the underlying platform for managed services. You are still responsible for what you control, such as virtual machine operating systems, application dependencies and container images. Check the provider’s shared responsibility documentation.

How do we prove we are patching for an audit? Keep the monthly records: what was reviewed, what was deployed, verification output and exceptions. Requirements vary by jurisdiction and framework, so confirm specifics with a qualified compliance professional.

Next Step

Block one recurring hour on the calendar this week, and use it to list every category of software you run, flagging the ones that don’t update on their own. That list is the whole foundation of the routine.