Patching in the Real World

Patching is a process, not a monthly button

Patching sounds simple: an update is released, so you install it. In a real business environment, the difficult part is deciding what needs attention first, what can safely wait, and how to avoid fixing one problem by creating another.

Most organisations have more software than they realise. Operating systems, browsers, Microsoft 365 applications, servers, VPN appliances, firewalls, backup software and line-of-business applications all have their own update cycles. A sensible patching process brings those systems into one operational routine rather than assuming Windows Update covers everything.

The aim is not to install every update the moment it appears. The aim is to reduce known risk while keeping important systems working. That requires ownership, documentation and verification after deployment.

What should be patched, and in what order?

Not every patch has the same urgency. A useful starting point is to separate emergency security issues from normal maintenance and then consider whether the affected system is actually exposed in your environment.

Prioritisation should consider several factors:

• Whether the update fixes a known security vulnerability.
• Whether the vulnerability is being actively exploited.
• Whether the affected service is exposed to the internet.
• Whether the system contains sensitive or critical business data.
• Whether a workaround already reduces the risk.
• Whether the update requires downtime or a restart.
• Whether the affected application has compatibility constraints.

For Windows environments, that may mean treating an actively exploited remote-access vulnerability differently from a routine feature update. For a firewall, VPN appliance or internet-facing application, a high-risk issue may require faster action because the system is directly exposed.

Microsoft environments also need clear distinction between quality updates, feature updates and application updates. A quality update may fix security or reliability issues, while a feature update can introduce broader changes to the operating system. Treating them as identical leads to poor scheduling decisions.

A proper managed IT service should define who reviews patch information, who approves deployment, how failures are handled and how success is verified. Installing updates is the technical part; operating the process is where accountability matters.

What people get wrong about patch management

The most common mistake is measuring success by the number of patches installed. That does not tell you whether the right systems were updated, whether critical vulnerabilities were addressed or whether a deployment caused problems.

Another mistake is assuming that automatic updates remove the need for patch management. Automation is useful, especially for routine endpoint updates, but it still needs oversight. Devices can be offline, updates can fail, restart requirements can be delayed and important software may sit outside the operating system's update mechanism.

Some organisations also delay every patch because they are worried about disruption. Compatibility concerns are legitimate, particularly with specialised business software or older systems. However, leaving everything unchanged indefinitely is not a risk-free decision either; it simply means accepting known weaknesses for longer.

The opposite approach is just as poor: deploying every update immediately to every system. That can turn a faulty update into a company-wide incident. The answer is controlled deployment, not either extreme.

A further weakness is forgetting about third-party software. Browsers, PDF readers, Java runtimes, backup agents, remote-access tools and other applications can all require separate update processes. An organisation can be fully current on Windows patches while still carrying known weaknesses elsewhere.

A practical way to deploy patches safely

The most useful patching process is usually based on groups. You do not need a large enterprise to use staged deployment.

A simple model might include:

• A test group containing selected IT systems and representative devices.
• An early deployment group with users who can report problems quickly.
• A wider business group for normal deployment.
• A separate group for servers and critical systems.

Updates can move through these groups according to their risk and the business impact of the affected systems. Critical security issues may follow a faster path, while feature updates can remain in testing for longer.

Before deploying a significant update, check whether the system has a working backup or recovery option where appropriate. For servers and critical applications, also confirm who is responsible for the application after the update. The IT team may be able to patch Windows successfully while the business application running on the server requires a vendor to confirm compatibility.

This is also where security assessment work can provide useful context. Vulnerability findings can help identify systems where missing patches create real exposure, rather than treating every outstanding update as equally important.

After deployment, verify the result. Do not rely solely on a tool reporting that a patch command was sent. Confirm installation status, check for failed devices, review restart requirements and investigate machines that repeatedly fall behind.

The hard part is exceptions

Every organisation has systems that cannot follow the normal patching cycle. They may run specialised software, depend on old hardware, require vendor approval or have limited maintenance windows.

Those systems should not simply be marked "do not patch" and forgotten. Document the reason for the exception and identify compensating controls.

Depending on the situation, those controls may include network segmentation, restricted administrator access, stronger authentication, application allowlisting or additional monitoring. The correct control depends on what the system does and how it is exposed.

Exceptions also need an owner and a review date. Otherwise, temporary restrictions become permanent because nobody returns to them.

This is one reason patch management cannot be judged only from a compliance percentage. A lower percentage may be reasonable if the outstanding systems are documented exceptions with compensating controls. A high percentage can still hide a serious problem if one internet-facing system remains unpatched.

What to do in order

First, build an accurate list of operating systems, servers, endpoints, network devices and third-party applications that need patching. If the asset list is incomplete, the patching process will be incomplete as well.

Next, classify systems by business importance and exposure. Identify which systems are internet-facing, which support critical operations and which can tolerate maintenance during normal hours.

Then define deployment groups and maintenance windows. Use a small test group before wider deployment where practical, but allow a faster route for security issues that require urgent action.

Review failed patches rather than ignoring them. Determine whether the cause is a device being offline, insufficient storage, an application conflict or a problem with the update itself.

Document exceptions and review them regularly. If a system cannot be patched, record why and apply other controls to reduce its exposure until the issue can be resolved.

Finally, verify and report on the actual state of the environment. The useful question is not simply how many updates were deployed. It is whether important systems are patched according to their risk, known failures are being followed up and exceptions are understood.