Patch Management Process: Implementation & Best Practices

Patch management process

This blog post is meant to provide details on patch management including the importance of a documented patch management process, how to implement the process successfully, and some common issues and roadblocks to avoid when doing so.

What is a Patch and Why is Patching Important?

A patch is a piece of code that is implemented to correct a coding flaw (system vulnerability). Patching is a very important part of an organization’s cyber hygiene to ensure its systems do not fall victim to those looking to exploit known vulnerabilities.

Given the very public breaches related to exploited vulnerabilities (e.g. Equifax, Yahoo, Facebook, Marriott, etc) it is very important for organizations to reduce the risk of breach and to review (or create) their patch management processes, to make sure that it is being followed, and that gaps are identified and filled.

Developing a Patch Management Process and Policy

When patches to vulnerabilities are needed to be implemented it is very important that a consistent and repeatable process is followed to ensure all patches are reviewed and tested and validated prior to implementation. Developing a patch management policy should be the first step in this process. A patch management policy outlines the process an organization is to take to update code on a consistent and reliable basis to ensure systems are not negatively affected by the change.


Successful implementation of patch management process

Implementing a Successful Patch Management Process

To reiterate a flexible and responsive security patch management process is critical to maintaining proper cyber hygiene.

There are many different methodologies and guidance to help with building a quality patch management process; but the key takeaway is to make sure you implement a process that aligns with your organization’s people, processes, and resources.

The process implemented must be repeatable and there must be buy-in throughout the entire organization, from the administrators installing the patches all the way up to the executives and board of directors. If there is no buy-in, it does not matter how great your process is because the chances of the process is being followed are very low.

If you do not have a process in place or are taking this time to review and update, the SANS Institute InfoSec Reading Room has provided a good methodology on how to implement a patch management process. At a very high level the methodology is:

  1. Baseline and Harden
  2. Develop a Test Environment
  3. Develop a Backout Plan
  4. Patch Evaluation and Collection
  5. Configuration Management
  6. Patch Rollout
  7. Maintenance Phase – Procedures and Policies

Another guidance provided by Microsoft is very similar and focuses on:

  1. Detect
  2. Assess
  3. Acquire
  4. Test
  5. Deploy
  6. Maintain


Best practices of patch management process

Patch Management Procedures & Best Practices

Quality Inventory Management Process

If you do not know what you have in your environment, then how are you supposed to protect against threats?

Most organizations maintain a very basic asset inventory which usually includes Operating Systems, IP Addresses, location, and sometimes the owner. While this is helpful and way better than not having an inventory at all, it does not include enough details to properly understand the organization’s threat vectors.

A best practice is to expand the inventory list to include at least the OS version, installed applications and their versions, the function of the asset (i.e. Domain controller, web server, database), interfaces/services/protocols, and a criticality score. Feel free to include additional details that are helpful to your organization, if it can help in the discovery, assessment, testing, and patching of an asset then add it in.

Reduce Threat Vectors

This is much easier said than done. As organizations grow, so do the number of assets and applications they must manage. Some organizations can have distinct operating systems and applications and other just a handful. Both scenarios can lead to a breach or increased risk if the assets and apps are not patched and maintained, but the organization with thousands has a lot more work to do and they have far more threat vectors to manage and monitor.

Best practice is to periodically review the operating systems and applications and work to reduce the number as much as possible. While Bob from accounting may really like using MS Works, it may not be in the best interest of the organization to continue to allow him to use it. Even if there is one legacy system or application in your environment that is unknown, out of date, or no longer supported, it can expose protected data and lead to an increased risk to the environment.


You can’t secure what you don’t know about. The best way to know if a vulnerability exists is to employ discovery and scanning capabilities. A proper discovery service uses a combination of active and passive scanning features and the ability to identify physical, virtual, and on and off-premise systems.

In addition to scanning the network, you also should define a reliable system for identifying new vulnerabilities. Waiting for the operating system or application to release a patch is not sufficient. In some cases, a new vulnerability may not have a patch available and the organization must mitigate or remediate the risk by other means.

Best practice is signing up for notifications for all the operating systems and applications that you have in your environment that provides this feature, as well as subscribing to security bulletins or vulnerability reporting services that can help you identify emerging threats and new vulnerabilities. Review these notifications and compare them against your inventory to ensure you are up-to-date.

Patching is Not Just for the Operating System

It is surprising to see how many organizations focus their patching on operating systems and either ignore or prioritize application patches much lower than the actual risk warrants because operating system patching is “easy” and everything else is perceived as hard. As was the issue at Equifax during their 2017 breach, an application vulnerability was identified but it took months and a breach for the organization to patch it.

Therefore, don’t just focus all efforts on the operating system but also take into consideration installed applications, services, libraries, and devices. With the growth of easy to install apps, IoT, and connected devices, everything matters. Review the threats and vulnerabilities to determine the risk and prioritize. Don’t just lower the priority or not patch something because is hard or complicated.

Metrics and Verification

How are you doing with your patching? Without measuring your performance, it is hard to determine if you are meeting your target and organizational goals. Metrics can help to validate that your patch process is effective and provide valuable information that can demonstrate the security posture to the business in a meaningful way. Metrics like percentage of systems up-to-date, percentage of failed patches, number of hours/days to patch, etc. are all valuable to the organizations.

Along with the metrics, an additional item that often gets missed is to verify the patch actually remediated the vulnerability. Many organizations just assume that once a patch has been installed, they are good to go, without going back to verify. Ideally, this is done in testing before the patch is installed but if not, rescanning the environment or testing a few machines after the patch was installed is necessary to determine if the vulnerability has been remediated.


Common patch management issues and roadblocks

Common Issues and Roadblocks with Patch Management

Without getting into too much detail, below are some high-level issues and roadblocks originations may run into when trying to implement and following a patch management process.

  1. Not reviewing exceptions: Exceptions are generally written when something can’t be patched but many times these exceptions are never reviewed after they have been written. Remember to go back and reassess all exceptions periodically to make sure they are still necessary and not introducing additional risk that was not originally defined.
  2. Being forced to support aging software: This is touched upon above. Sometimes you must support old software. If that is the case, work on trying to limit access, network segregation, adding additional monitoring to reduce the risk.
  3. Not viewing risk as a whole: Most risks are written for each threat or vulnerability, but no one took a look at all the risks as a whole. A low risk somewhere else in the organization may increase the risk for a given threat or vulnerability. Also, if you have hundreds of low risks, maybe the overall risk is now medium or even high.
  4. Not enforcing a patch management policy: If you have a policy but don’t follow it or don’t enforce it, then why have it? Be sure to hold teams accountable for not meeting the targets and goals.


In summary, implementing a patch management policy and patch procedures are critical to ensure that vulnerabilities are being rectified in a timely manner to ensure the risk of a breach is greatly reduced.

Linford & Company provides multiple services like SOC 1, SOC 2, FedRAMP, and HIPAA audits that are designed to assess an organization’s security management and regulatory compliance effectiveness. Contact us if you would like to discuss our services further.

Leave a Reply

Your email address will not be published. Required fields are marked *