Most policies say patch promptly and nothing else. The useful ones say what happens in rings, what happens when an update breaks something, and when an exception expires.
Open most patch management policies and you will find a sentence committing to apply critical updates within a stated number of days, a sentence about testing, and a paragraph about roles. It is not wrong. It is just not a policy anybody can follow, because it does not answer the two questions that come up in practice: what happens when an update breaks something, and what happens when a system cannot be patched at all.
A policy that answers those two is a page longer and worth having.
Rings, not a date
A single deployment date means every machine gets the update at once, which means a bad update affects everybody at once. The alternative is deployment rings, where the fleet is divided and each group gets the update a few days after the one before.
Two details that make rings work rather than just exist.
Ring 1 is a cross-section, not volunteers. The useful ring 1 deliberately includes the heaviest users of your line-of-business software, because they are the people who will notice the incompatibility. A ring of enthusiastic early adopters who mostly use a browser tells you nothing.
Ring 3 is last on purpose. Executives, the finance team during month end, and anything attached to production. Not because they matter more, but because the cost of disrupting them is highest and by the time the update reaches them it has run on ninety percent of the estate.
The gaps between rings should be long enough for a problem to surface. Three days, a week, a fortnight is a reasonable default. Compressing to a day defeats the purpose.
The monthly cycle
The step most often skipped is the first, and skipping it is usually fine until it is not. Twenty minutes reading the release notes for the handful of systems you actually depend on will, two or three times a year, tell you about a change that would have broken something. That is a good return on four hours a year.
Exceptions, with expiry dates
This is the part that separates a real policy from a document.
Some things cannot be patched on your schedule. The application vendor has not certified the new version. The machine controls a press and the manufacturer's support agreement forbids it. The server runs software that stopped being supported in 2021 and the replacement project is funded for next year.
Pretending otherwise produces one of two outcomes: the policy is ignored, or somebody follows it and breaks production. Instead, make the exception explicit and make it expire.
Every exception needs four things: what is excluded, why, who owns it, and when it is reviewed. The review date is the critical one. An exception without an expiry becomes permanent by default, and in five years nobody remembers whether the original reason still holds.
And an exception is not an accepted risk on its own. It needs a compensating control: network isolation, application allow-listing, restricted accounts, additional monitoring. Write down which control covers which exception. That mapping is what an insurer or an auditor will ask for, and it is also the honest answer to whether you are actually exposed.
Measure one thing
Patch reporting can generate enormous quantities of data that nobody acts on. One number is enough for a monthly review: the percentage of the estate running a current, supported version.
Report the trend rather than the absolute figure. Ninety-four percent is not meaningful in isolation; ninety-four following three months at eighty-eight is a working process, and ninety-four following three months at ninety-nine means something has started going wrong.
Add one list alongside the number: devices that have not checked in for thirty days. These are not a patching problem, they are an inventory problem, and they are where unmanaged risk accumulates.
Emergency patching
Occasionally something is actively being exploited and the normal cycle is too slow. The policy should say who can invoke this and what changes.
What changes is the ring schedule compresses, typically to same-day for everything, and testing is reduced to a smoke test on ring 0. What does not change is that somebody makes the decision deliberately and writes down that they made it.
Name the person who can declare an emergency patch, give them a deputy, and make it explicit that getting this wrong occasionally is acceptable. The failure mode is an organisation where nobody is sure they have the authority, so the decision waits for a meeting.
Third-party software, which is where the gap usually is
Operating system patching is largely solved by tooling. Browsers mostly update themselves. The gap is everything else: PDF readers, Java runtimes, the design suite, the old client application for a vendor portal, the conferencing tool three people installed themselves.
Historically, this category accounts for a large share of exploited vulnerabilities on endpoints, and it is the part your patching report probably does not cover. Check whether your tooling updates third-party applications or only the operating system. If it does not, that is a real gap and closing it is usually a configuration change rather than a purchase.
The policy, in outline
One page, in this order: the rings and their schedules; the monthly cycle with named owners; the exception process including the expiry requirement; the emergency process and who can invoke it; the single monthly metric; and the scope statement saying explicitly which categories of device and software are covered and which are not.
The scope statement is worth writing carefully. A policy that implies it covers the plant floor when it does not is worse than one that says plainly that control systems are out of scope and handled under a separate arrangement.
