Patch management is something every organization has to do. But keeping every system patched and secured against every vulnerability can become a tedious, never-ending task in itself. And we know what happens when a task gets tedious…the chances of making a mistake or missing something go up exponentially.

That’s one big reason why we’ve started to write about our own patch management checklist: To share the steps necessary for good patch management, and to help others not miss important decisions and steps. (If you follow this checklist, you’ll be in a better position to automate your patch management, too.)

Of course, planning is a huge part of a good patch management strategy. In this first installment on the topic, we’ll go through some of the initial decisions that have to be made before you even start the patching process. Subsequent posts will cover how these decisions are shaped into a more concrete patch management strategy.

Step 1: Define goals and success metrics

There are a lot of reasons to keep up with the latest patches in a systematic way. (I discuss many of those here.) It helps to know exactly which reasons are driving your patch management strategy, and how you will measure whether those goals have been successfully met when going down your patch management checklist.

For example, many industries—like legal services and financial services—have heavy requirements when it comes to compliance. You may measure success, then, by the percentage of machines that are in compliance… once you have a clear definition of what compliance means. Does compliance pertain to critical updates only? All available updates? Important updates? Office updates? These options need to be thought through.

Another common metric is speed of patch deployment once a patch is available (for example, knowing which servers have patches that are non-compliant over 60 days since release). Understanding your requirements and business/compliance tolerance is important.

Step 2: Identify targets

This next step seems simple but is crucial: Identify the list of things that need patching. At the very least, this will include which workstations, servers, and devices will need patching, both on-premise and out-of-office. (Hopefully, these have already been identified as part of your overall Unified Endpoint Management strategy. If not, talk to us.) It should also include a separate list of applications that will need regular patching.

Remember, though, that apps and devices are different, and have different testing functionality, than workstation packages. For example, a workstation that is patched and gives no response often means that it has passed all tests, whereas a “no response” response from an app could mean trouble.

Step 3: Identify how the list of available patches is determined

How do you determine which patches are available, and what subset of those are necessary or critical?

One way, of course, is to have the point of authority determine this for you. Automate that, and it will help ensure everything is up-to-date with the latest patches (depending on the policies you set, of course).

Another way is to have your own internal security team do this. There are many scenarios where you might not want to trust the point of authority at all times. For example, if you are a law firm that depends day-to-day on certain Microsoft Office add-in’s, you might not want to run the risk that a patch breaks that those add-in’s. Sometimes, there is a trade-off between showing compliance and overall compatibility.

Step 4: Start thinking through deployment rules

This is the point at which you should review deployment rules as well. Some updates, such as security updates, might need to be deployed quickly and broadly. Rules will need to be defined (or tweaked) to reflect this.

Let’s say, for example, that you are automating the patching process using SCCM. This will allow you to define rules for automatically finding and deploying patches; these are called Automatic Deployment Rules (ADRs). Each time an ADR runs, it can add software updates to a new or existing software update group. For example, you can have all machines save for mission-critical ones receive all critical security updates a week after “Patch Tuesday” and deploy automatically. You can read more about ADRs from Microsoft’s own article on the topic. (There’s a nice example here, too.)

From here, you can begin to craft your specific patch management strategy. That strategy will look a little different for workstations than it does for servers, however. Different questions need to be asked and answered. For that reason, I am going to break up discussion of each into two separate articles. Stay tuned.