The what, where, and how of a patch management policy

Patch management policy

In the complex world of IT patch management, organizations must deal with many steps in a patch management lifecycle to ensure patch management is executed effectively. 

The patch management policy ensures this is possible by documenting the critical success factors of patch management:

• The process and mechanism for identifying patches and tracking them

• Policies governing the prioritization of specific patches

• Testing to be performed before a patch is rolled out

• Timeframes for testing and deploying patches, based on patch urgency

• Mechanisms for dealing with exceptions

• Individual team members’ accountabilities and responsibilities concerning patches to their environments

• Best practices for IT patch management

Without a patch management policy, the act of deploying patches to systems and applications may have to be done primarily manually, resulting in the chaotic application of critical updates. Hence, organizations need a documented patch management policy, patch management process, and patch management plan, working together to ensure success and consistency. 

The IT patching policy should contain governing statements on why patch management is critical to the organization and the specifics of how the organization will carry out the activities of the IT patch management program. Effectively, the IT patching policy is a document that spells out how the IT patch management process will be executed, and the consequences if it is not followed. In a managed service provider (MSP) organization, this ensures that proper steps are taken to ensure client endpoints are sufficiently protected. The patch management policy document represents the IT patch management program at a strategic level so that patch management operations can be carried out effectively.

There are two main functions of patch management: addressing security vulnerabilities and maintaining systems and software, each of which will be addressed separately.

Security patching policy and importance

Cyber attacks affect daily operations and bring negative attention to an organization (particularly when it is an MSP). The minute a breach occurs in a known company, it’s all over the news. The frequency and costs of ransomware and malicious intrusions make security patch management policies a critical effort on behalf of the business. Left unmanaged, it could take weeks to months for patches to be applied. Security Magazine reports it takes an average of 256 days to patch systems with known vulnerabilities, exposing the organization unnecessarily.

The cost of a ransomware attack can be in the millions combining lost business revenue, productivity, and recovery costs. The security patching policy is a key means to address this rapid deployment, and by establishing a strategic goal for addressing security vulnerabilities through a security patching policy, executives make the importance of such activities clear to internal IT teams and supporting vendors like MSPs.

In addition to setting clear goals for the security patching policy, it’s important to set out the consequences for non-adherence, including the possibility of cyber attacks and not being able to meet industry compliance requirements if acceptable security patching policy is not in place and enforced. Personnel also need to understand that ignoring or delaying the deployment of security patches could also lead to disciplinary action, which should be made clear in the consequences section of the IT patch management policy.

System patching policy and importance

Routine patches are also important as they include fixes provided by vendors of operating systems and applications that address security vulnerabilities and known errors, as well as enhanced features and functionality. The system patching policy provides background on how these patches will be prioritized, tested, approved, and deployed. It is helpful to have both a security patching policy and a system patching policy to address the greater urgency of security patch management.

The system patching policy recognizes that testing and deploying the volume of routine patches in a large environment can be daunting, and prioritization can include a process for comparing required patches against known errors in the environment. Identifying those that are impacting end users can help the organization execute the most important patches first. In many ways, a system patching policy makes it easier to prioritize and deploy patches in a way that provides value to the business.

The patch management policy defined

An effective patch management policy calls out how the patch management program will be designed within an organization and the time frames within which activities will occur. It will include strategic statements governing how the following activities occur, which are further defined in the patch management plan:

• System and application discovery and inventory 

• Configuration standards, or OS and software versions to be installed

• Cataloging and prioritizing patches

• Testing

• Approval to deploy 

• Patch rollout 

• Exception management

• Consequences of non-adherence to the policy, including disciplinary actions

The patch management policy should clearly state the purpose and scope of the patch management policy. The scope should call out those patch types that fall under the patch management policy, such as security patches, operating system (OS) patches, software and application updates, and bug fixes. 

For a patch management policy to be complete, it should include a separate section referencing the higher urgency of security patches and how their patch management process might differ from more routine patching.  

Patch management policy template

The patch management policy should be a robust document calling out all the needs for the patch management plan in concrete details that can be audited after adoption. It should also reference the process for governing changes to the policy.

The following sections should be included in the patch management policy template:

• Overview and purpose stating why the patch management policy is being put into place and its importance to the organization and its employees.

• Scope of the policy, including all systems, environments, and patch types to be covered under the patch management policy.

• Security patch management policy documenting the need to secure systems by patching known vulnerabilities rapidly and including acceptable timeframes.

• General patch management policy documenting the response for the operating systems, applications, and software patch management program.

• Patch management process lifecycle describing in detail how discovery, prioritization, testing, approval, and deployment of patches will be managed, including guidance on managing failures.

• The roles and responsibilities of all staff members involved in the patching process should be clearly defined, including overall accountability for the IT patch management process.

• Response and timing should call out the expected timeframes for each stage within the lifecycle once a patch has been identified, based on the priority of the patch, considering its urgency.

• Procedures should document the need for automation and where automation will be used to ensure the smooth execution of the patch management plan, as well as spelling out expectations for some day-to-day patch management best practices:

• Documentation on how discovery will be performed, how often it will be run, and how often the results will be reviewed to find missing patches.
• Ways in which production systems will be standardized, where the standards will be documented, and how often they will be reviewed.
• Policies regarding exceptions, where an environment will not be configured to standard due to the inability of the software to operate properly within the most recent versions of an operating system, for example.
• How security vulnerabilities will be discovered, cataloged, and prioritized and how the remediation of these vulnerabilities will be tracked through the patch management process.
• Needs and ways in which approvals will be gathered, including information on which patches require approval. Sometimes low-risk, routine patches will skip the approval process assuming positive test results.

• Exceptions documentation needs to be decided upon and the risk of not patching the environment evaluated and accepted, including who must accept that risk.

• Audit controls and change management for the patch management policy and plan.

• Consequences of not following the patch management policy including disciplinary actions that might result if team members do not follow the policy.

• Policy version history detailing changes made to the policy and when they were made.

It is also recommended that the patch management policy template include a glossary of terms that may be included as an appendix. This glossary should define the systems and environments, patch management terminology, and other terms that may not be universally recognized.

For commercial data centers and MSPs, the use of a patch management policy template that is completed as part of each new contract ensures each policy is complete and contains all the details necessary for a complete patch management process. The creation of the client’s patch management policy should be performed as part of the client’s onboarding process. It should also align with any internal patch management policies the client already has in place, ensuring compliance with regulations that could lead to fines.

Benefits of a patch management policy

Policies ensure the work gets done and that it gets done within the timeframes expected. The patch management policy lays out how the system, application, and security patching will get done, drive process automation, and set patch management as a critical need in an IT organization. By having a patch management policy, an organization ensures that their staff understands the importance and need to perform patching promptly:

• Addressing potential vulnerabilities quickly to protect the organization’s computing environment from ransomware and other costly cyberattacks.

• Enabling innovation within the organization by ensuring the latest software features and updates have been applied.

• Stabilizing system performance by ensuring all hotfixes are applied. 

• Lower support call volume by installing bug fixes and addressing software defects.

There is another less visible aspect of the patch management policy. By including automation needs in the policy, the organization is chartering programs to automate the patch management process using best-of-breed tools to help manage many aspects of the process. Opportunities for automation that should be included in the patch management policy include:

• Use of security vulnerability databases that will be downloaded and updated regularly to track known vulnerabilities.

• Automated comparison of vulnerabilities and identification of patches that apply to the environment.

• Automated creation of work orders for patching activities that enable the work to be prioritized.

• Tracking the status of patches through the patch management lifecycle including the following components:

• Identification of assets to be patched

• Status of the testing on the assets (by class)

• Approval to deploy the required patches

• Automated patch deployment once approval is gained and automation of the approval workflow.

• Tracking the success of patch deployment.

Many patch management tools can leverage rules, scripted policies, and artificial intelligence algorithms to determine health scores for each device. The health scores can be configured to check for adherence to version standards as well as the presence of expected patches based on the hardware and operating system. By using automatically set thresholds developed by the patch management policy, work orders can be opened to remediate devices that are not meeting expected health standards due to missed deployment or late discovery of the device.

Another benefit of a patch management policy is that it documents how a patch management program will be run in detail for compliance purposes. Audits can be performed against the documentation in the patch management policy, demonstrating adherence to any standards or laws affecting the organization. By setting the expectations in writing, IT personnel know exactly what they are expected to do to meet compliance needs. The availability of automated auditing at the asset level, along with reports showing the patches applied to each asset, helps demonstrate that the work called out in the patch management policy has been performed. The ability to pass audits protects the organization from fines and other regulatory actions that could result from non-compliance. 

The patch management policy is a critical way to ensure the successful operation of the digital environment, protecting the organization from cyber-attacks, addressing repetitive issues that can arise from defects in operating systems and software, and making new features and functionality available by ensuring system administrators keep their environments up to date when they are already overwhelmed with day to day support and growth needs.