Patching and updating devices can be a hassle and can cause business disruption. Yet, unpatched vulnerabilities provide attackers with open opportunities to cause great damage — with studies showing unpatched vulnerabilities estimated to contribute to 30-60% of all breaches!
A patch management policy formalizes the fundamental IT requirement that all systems and software should be patched and updated in a timely manner with rules that explain the requirements for patching and updates, clear processes that can be followed, reported on, and confirmed, and standards that can be tested and verified.
This article can help organizations of all sizes start the process with a fundamental overview and a template:
- Free Patch Management Policy Template
- How to Create a Patch Management Policy in 4 Steps
- Common Patch Management Policy Sections
- Top 5 Patch Management Policy Best Practices
- Top 6 Benefits of an Effective Patch Management Policy
- Bottom Line: Patching Policies Promote Premium Processes
Also read: 11 Key Steps of the Patch Management Process
Free Patch Management Policy Template
To kick start any patch management policy development, eSecurity Planet has developed a template that can be downloaded and modified. Notes of explanation or how to use the template are enclosed [between brackets] and these sections should be removed from final drafts.
Access the Sample Patch Management Policy Template.
The sample patching policy contains many sections, but not all sections will be required for all organizations and others might require more details. See Common Patch Management Policy Segments below for more details.
How to Create a Patch Management Policy in 4 Steps
All security policies share the same four key steps to create a policy, and they are explored in detail in IT Security Policies: Importance, Best Practices, & Top Benefits. For a functional patch management policy, we summarized these steps as:
- Determine the Patch Management Policy: Identify responsible parties, who or what is covered, basic processes, validation methods, and reports; these often will be based on the current practices.
- Verify the Patch Management Policy: Formally check to ensure basic policy developed in step 1 satisfies the complete needs of the organization and any compliance requirements.
- Approve the Patch Management Policy: Draft official language and circulate the policy for approval by affected stakeholders and executives.
- Review and Modify the Patch Management Policy: Periodically review the policy to ensure it remains updated and continues to satisfy the evolving needs of the organization.
Although the basics remain the same, patch management is a frequently regulated requirement and organizations will need to apply extra caution in verifying compliance requirements. Any rule that does not meet compliance requirements should be adjusted.
For example, a fire department might apply patches quarterly in practice. However, they might find that their state’s cybersecurity requirements require monthly patching and will therefore need to change their patching frequency to monthly to comply.
Practical limitations also will be very important and the policy team should work with the patching team to test the rules. If the IT team cannot comply with standards and requirements with their current resources, should the organization adjust the rules or the resources?
In the fire department example above, perhaps the volunteer fireman who used to apply the patches in their spare time will need to be replaced or assisted by a patch management tool or service that can meet the monthly regulatory requirements.
Common Patch Management Policy Sections
When writing your patch management policy, consider the required, recommended, and bonus (aka nice-to-have) sections.
Required Policy Sections
These core sections should be part of every policy related to patch management:
- Scope: What assets are covered by the policy and how to identify software and devices to be covered.
- Patch Management Authority: Who is in charge and responsible for the patch management policy and its execution.
- Patching Priority: How to determine the priority of patches and the basis for that determination based on severity, risk, and other factors.
- Patch Scheduling: The length of time between the patch release and the organization’s installation based upon priority.
- Patch Management Preparation: Backups and other system preparation that needs to be in place in case a patch fails and systems need to be restored.
- Manual Patch Management: How to apply patches manually — especially for systems that require downtime for maintenance. Explain the process for scheduling and obtaining approval for business system downtime.
- How to Handle Exceptions: Some patches will fail, some will cause business disruption, and some will simply not be needed. Explain how to recover systems and track exceptions and the process for mitigations to protect open vulnerabilities.
- Patch and Update Reporting: How to measure success and compliance with patch management with reports, including how and what to report.
Recommended Policy Sections
These sections help to flesh out the patch management policy with additional rules to protect the organization and to help prepare the IT department:
- Asset List: A list of resources or links to asset lists to help define the scope of systems and software tracked for patching and updating.
- Patch and Update Acquisition: Outline where to obtain valid patches and updates.
- Patch Testing: Test environments or testing of patches to verify they work and do not affect other business systems.
- Automated Patching: Organizations often express a preference for automated patching processes to reduce patching delays and burdens for IT teams.
- Audit Controls and Management: Outline what reports, logs, and information can satisfy internal and external auditors to track patch management success and verify patches have been successfully applied.
- Enforcement: Penalties to the IT department for failure to execute the patch management process, penalties to employees that interfere with the patch management processes, and how to handle assets that do not comply with the patch management policy.
- Distribution: Who must or should receive the patch management policy.
- Policy Version: Tracking versions and approvals of the patch management policy.
Bonus / Nice-to-Have Policy Sections
These sections do not change the core elements of the patch management policy, but can make the policy more usable or comprehensive:
- Overview: sets expectations and goals for the policy.
- Compliance Appendix: Copies or links to relevant compliance frameworks with which the organization must comply.
- How to Deal With BYOD and personal equipment.
Top 5 Patch Management Policy Best Practices
All security policies share the same five best practices to create a policy, and they are explored in detail in IT Security Policies: Importance, Best Practices, & Top Benefits. For a functional patch management policy, we summarize these steps as:
- Focus on What to Do, Not How: By focusing on goals and objectives, a policy can set standards while allowing the patch management team the flexibility to determine the best solution to meet those goals and objectives.
- Make Policies Practical: The patch management team needs to be able to understand and implement the policy.
- Right-size Policy Length: Too short and the policy may not have sufficient requirements to be verified; too long and the policies may become over prescriptive or hard to understand.
- Keep Policies Distinct: Overlapping policies can introduce conflicts or become more difficult to keep current.
- Make Policies Verifiable: Effective policies require reports that prove the policy is both in place and effective.
The eSecurity Planet template seeks to be more comprehensive than some organizations may need, so every organization should review the template and add or remove content to fit their needs.
Beyond the standard best practices, patch management benefits from additional considerations. For example, when making patch management policies practical, use existing resources such as the Common Vulnerability Scoring System (CVSS) to determine risk and prioritize patches, but balance those resources with consideration of the organization’s specific context.
For example, some organizations only patch vulnerabilities with a score of 7 or above. Yet these ratings only show the risk of the vulnerability and must also be combined with the likelihood of exploitation and the value of the asset to the organization.
A data exfiltration bug of 8.0 on the marketing web server that only contains publicly released documents shouldn’t have higher priority than a 6.5 remote code execution vulnerability on the server with the company’s Active Directory (AD) services. The impact to the organization of a fully compromised AD simply would be too great to risk even modest possibilities of exploitation.
As a special consideration for patch management, many organizations deploy automated tools. These solutions work well and should be used; however, they tend to focus on certain parts of the IT ecosystem such as operating systems and common software such as Microsoft Office or Adobe Acrobat.
Tools often lack comprehensive coverage of third-party applications, firmware, internet-of-things (IoT) devices, networking equipment, backup applications, and more. The policy should not rely upon the tools or a patch management service to determine the asset list for the patching policy. The IT department must ensure that all resources that need patches are tracked and patched, even when applying the patch is difficult or may require manual patching.
Top 6 Benefits of an Effective Patch Management Policy
Many organizations feel that their undocumented patch management processes will not be improved by taking the time to put them into writing. However, this attitude overlooks six key benefits to any security policy:
- IT Hardening: The process of creating or reviewing security policies forces the evaluation and potential improvement of security practices.
- Employment Defense: Compliance with an executive-approved written policy provides coverage for the IT and security team in the event of a breach.
- Executive and Board Member Peace of Mind: Executive stakeholders can easily understand the organization’s security posture from plain-language reports required by effective policies.
- Litigation Protection: Reports and other evidence showing compliance with policies that encompass reasonable security efforts can provide protection against lawsuits and regulators in the event of a breach.
- Compliance Easy Button: Policy-required reports will automatically be available for auditors if the policy already encompasses the compliance requirements.
- Improved Operational Efficiency and Resilience: Effective policies, especially patch management policies, can detect end-of-life assets and ensure the installation of the latest features for ease of use and capabilities.
Bottom Line: Patching Policies Promote Premium Processes
A good patch management policy can provide a helpful checklist to help create an efficient, and reliable patch management process. The reduced cybersecurity risk from the patching and the improved communication from the reports will improve overall business processes and executive confidence.
However, patching cannot solve all problems. Patch management does not cover whether or not an organization has the correct software in place for their needs or if the software settings are properly configured.
Patch management policies provide a helpful part of an overall cybersecurity program but need to be combined with other critical policies and strategies to ensure a resilient organization.
More information on Patch Management and Related Topics:
