Creating a Patch Management Playbook: 6 Key Questions

As cyberattacks continue to grow, organizations face increased pressure to protect their assets and close the software vulnerability gap. Unfortunately, many organizations still struggle to get patch management right. In fact, a Ponemon Institute study found that 42% of organizations that suffered a data breach knew that patches were available but struggled to apply them. Now, more than ever, having the right patch management playbook (or strategy) is crucial to protecting data, employees, partners, and the broader business.

The reality is that creating a strong patch management playbook relies on important factors like the size of an organization, the complexity of an IT environment, the criticality of its systems, and the number of resources allocated to manage it all. Success relies on proper preparation and meticulous execution.

As IT and security teams work to create (or update) a patch management playbook, they should be asking — and answering — these six key questions.

Question #1: Which updates should I install first?

It's important to rank updates. Organizations should prioritize updates with the highest severity of non-superseded vulnerabilities and the highest exposure in each environment. For example, you might deprioritize an update that affects one device out of 5,000 and instead prioritize patching a vulnerability that impacts 1,000 devices. Tackle critical updates first, as they often impact security, privacy, and the reliability of key systems.

Next, move on to important updates that address non-critical problems or help enhance the computing experience. Finally, optional updates are more or less a dealer's choice. These can include updates to drivers or new software to enhance the computing experience. While implementing these updates is recommended, they may not need to happen in the first 24 hours. Still, every organization should consider applying all vulnerability patches.

If you're struggling to assess risk levels, consider leveraging the Common Vulnerability Scoring System (CVSS) to help prioritize updates. It shows the severity level of a vulnerability from 0 to 10. Vulnerabilities with a base score in the range 7.0–10.0 are high (critical), those in the range 4.0–6.9 are medium (important), and 0.0–.3.9 are low (optional).

Question #2: How can I test these updates before pushing them into production?

No one wants to break their systems. Which is why many organizations test before applying new patches. This can be done by installing each missing update on at least five devices to be tested against proven success criteria. Always record the evidence, which should be independently reviewed by someone other than a tester for overall approval. Note that while IT and security teams might be tempted, never use an in-house (or on-network) machine to test updates. Find out if the update has an uninstaller and use it to ensure complete and safe removal of outdated programs. Take this process in stages. First, research the potential criteria of each update, then identify which components require testing, then compare that against your predetermined success criteria.

Question #3: How many updates should I install at once?

The more updates installed at any given time, the greater the risk of end-user disruption. For example, the more updates needed on a system, the greater the volume of data needing to be downloaded to the device, and the longer the resulting installation time. Moreover, sometimes updates require a reboot, and when many updates are deployed together as part of a patch, it may trigger multiple independent reboots, thereby increasing the end user disruption. To assess a system's bandwidth for updates, calculate the total number and size of missing updates against the total number of devices by device type. This will prevent system overloads and unwanted interruptions. The rule of thumb is to start with five updates and then reassess bandwidth.

Question #4: How can change management be easier?

Whether you follow Prince2, ServiceNow best practices, or ITIL best practices, change management normally requires documentation on which updates are needed, the impact on the user, evidence of testing, and go-live schedules. Without such data, an official approval process cannot be followed. Within large organizations, change management is the single source of truth for approved changes, so keeping proper reports on those changes makes the process easier and auditable.

Question #5: How do I safely deploy my updates?

Creating a patch management calendar is a crucial step in building a playbook. It should be used when making change requests and when scheduling or reviewing new patch updates. Next, work to define baselines for the number of updates to be deployed at one time and in which order (and verify the change management process). This should be based on answers from the previous questions about severity and bandwidth and be appended monthly. Once that baseline is set, schedule the deployment and automate where necessary.

Question #6: How do I gauge the success of my playbook?

Success can be measured in a variety of ways. For example, by the number of incidents raised to the help desk following deployment, the ease at which the process can be followed or repeated, or the number of positive reports generated through the toolset you might be using. Ultimately, the main criterion for success is the swift deployment and updating of patches across the environment, followed by a streamlined process that reduces the manual requirements to keep an organization safe.

Patch management continues to be a challenge for organizations both large and small. But as the vulnerability gap continues to persist, IT and security teams can play a major role in reducing their attack surface by implementing great patch management playbooks. Being able to answer these six questions is an important part of that process.