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 account for 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
- 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
- How Patch Management Policies Work
- Top 5 Benefits of an Effective Patch Management Policy
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 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 Segments below for more details.
How to Create a Patch Management Policy in 4 Steps
Organizations large and small can create a functional Patch Management Policy by following four key steps:
- Determine the Patch Management Policy
- Verify the Patch Management Policy
- Approve the Patch Management Policy
- Review and Modify the Patch Management Policy
Determine the Patch Management Policy
This first step requires the person or team drafting the policy to determine the key rules and steps within the patch management policy. For example some key questions to answer are:
- Who is responsible for the patch management process?
- What assets should be patched and updated?
- What is the priority for patching and updating?
- What is the process for patching and updating?
- What happens when a patch fails or cannot be applied?
- How can the patch management process be validated and verified?
The easiest way to create a first draft is to write down the current practice. Most IT teams have at least an informal process for obtaining and applying updates and patches – even if they are not written down or monitored. This first draft can simply be notes and does not need formal paragraphs.
Verify the Patch Management Policy
With the basic rules in place the policy development team will need to verify the rules in two key ways: against external rules and against practical limitations.
To verify against external rules, the rough policy rules can be compared against necessary compliance frameworks (NIST, PCI DSS, etc.) and industry standards to see if they satisfy any applicable requirements. Any rule that does not meet compliance requirements should be adjusted to comply with requirements.
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.
To test against practical limitations, 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 adjust 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.
Approve the Patch Management Policy
After verification of the basic patch management rules, the rules need to be formalized and approved by the organization’s management. At this point, rough notes need to be changed into formal paragraphs, tables, and appendices.
Once the initial draft is composed, it will need to be passed through management and possibly even legal counsel for approvals. The policy can be modified as required and the final draft signed off by the executives of the organization.
Review and Modify the Patch Management Policy
Even though the first formal Patch Management Policy may be approved by step three, keep in mind that all policies should be living documents that need to change as the organization changes. The policy should be periodically reviewed to verify the existing rules against new regulations, improving tools, changing IT asset mixes, and changing needs of the organization.
Also read: Patch Management Best Practices & Steps
Common Patch Management Policy Sections
Required 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: How long 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 patches will cause business disruption, and some patches 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, how to report, what to report.
Recommended 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 reduce 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 IT Department for failure to execute the patch management process, penalties to employees that interfere with 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 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
When creating any policy, an organization can pursue many different paths and options and emphasize different concepts. To create practical and useful policies, the following five best practices should be followed.
Make Policies Brief
Patching policies can be long or short, but make the policy no longer than it has to be. Some organizations might even attempt to use a policy of only a few paragraphs.
However, such a short policy may not be as useful for other organizations that need to provide more direction. The eSecurity Planet template seeks to be more comprehensive, and organizations can add or remove content to fit their needs.
Make Policies Practical
Policies must satisfy compliance, but they won’t be successful if they do not work for the team responsible for the policy. Don’t reinvent the wheel or add unnecessary details or instructions.
- Use existing practices where possible.
- Use titles instead of names so that the document survives personnel changes or outsourcing.
- Use existing resources such as the Common Vulnerability Scoring System (CVSS) to determine risk.
Tools and processes must fit the true needs of the organization and should not be followed blindly or without thought. 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 exploit and the value of the asset to the organization.
For example, 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.
Policies work best when they reinforce each other, such when combined with an asset management policy and a risk register or risk management program.
Make Policies Verifiable
The patch management policy outlines the plan for patching vulnerabilities. The policy also needs to make sure the plan is followed and the vulnerabilities were actually eliminated.
The patch management process should be measurable and testable to prove compliance with the policy and any relevant compliance frameworks. Reports provide metrics for measurement, log files provide evidence, and vulnerability or penetration testing can test that the patching process was completed correctly.
Beware Overreliance on Tools and Services
Tools and automation 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.
Keep the Policy High Level
The individual sections of a policy should only cover the broad concepts such as “the policy should cover all assets.” Additional details can be covered in the appendices if required, but many implementation details should be left to the implementation team so allow flexibility that can evolve with the organization’s needs.
Details will change over time as technology evolves and the resources of the organization change. A policy with too many details will require constant change to remain accurate and relevant and will become an unnecessary and unwelcome burden.
How Patch Management Policies Work
All companies deploy security strategies, even if the strategies have not been written down. However, when strategies fail to protect the resources, the organization will be compelled to prove that the IT and security teams executed the appropriate cybersecurity and IT policies.
Written policies provide written instructions that can be used to show the intended strategy of the organization. Policies do not directly improve security, but a lack of policy can be seen as negligence.
Many compliance frameworks, such as the U.S. National Institute of Standards and Technology (NIST), consider policies to be a fundamental requirement for even the lowest levels of cybersecurity maturity. Policies help to show compliance with relevant compliance frameworks.
For example, NIST developed the Framework for Improving Critical Infrastructure Cybersecurity and within this framework, a patch management policy would fall under: Information Protection Processes and Procedures (PR.IP) Section 12 which requires that “a vulnerability management plan is developed and implemented.”
An auditor can easily use the policy as a starting point to understand how a company does, or does not, comply with a framework. Of course, the organization will then need to back up the written policy with evidence of action.
Reports and log files can provide evidence of action as well as a metric for the company to measure success. For example, if reports show that the patching of critical updates takes longer than desired, the management can consider adding more resources or outsourcing. Some organizations even switch from locally installed software or even appliances to Software-as-a-Service (SaaS) implementations to eliminate the need for patching and updating.
Also read:
- Is the Answer to Vulnerabilities Patch Management as a Service?
- Best Patch Management Service Providers
Top 5 Benefits of an Effective Patch Management Policy
Many organizations feel that their undocumented patch management processes will not be affected or improved by taking the time to put them into writing. However, this attitude overlooks five key benefits to an effective patch management policy.
- Business Resiliency & Uptime
- Executive & Board Member Peace of Mind
- Litigation and Employment Defense
- Compliance Easy Button
- Improved Operational Efficiency
Business Resiliency & Uptime
An effective patch management process updates systems and seals off cybersecurity vulnerabilities. An effective patch management policy formalizes the process and can help the organization:
- Recognize overlooked systems and software
- Recognize end-of-life hardware and software for replacement
- Prioritize patches that deliver true value and protection
- Minimize downtime
- Document uptime for internal and customer Service Level Agreements (SLAs)
- Provide a checklist for preparation and installation of updates and patches
Like surgeons, IT professionals often see written documentation as a form of weakness. Yet even surgeons find that a checklist can reduce deaths by as much as 47%.
IT processes may not share the life-or-death stakes, but the survival of the business still depends upon uptime and protected assets. Formalized documentation of the patch management process as a policy provides an internal checklist to protect assets, maintain uptime, and minimize mistakes.
Executive & Board Member Peace of Mind
Happy bosses reduce stress for everyone. The formal reports generated by effective patch management policy requirements help explain the status of assets throughout the organization and deliver peace of mind to business stakeholders and decision-makers.
Even though most executives and board members cannot understand the technical details for the IT infrastructure, a step-by-step patching process outlined in a policy eliminates confusion regarding the objectives and targets of the patch management policy. Policies reduce technical details into numeric reports and easy to understand metrics that make the status of the patch management process understandable and accessible to non-technical executives.
Litigation and Employment Defense
Even a fully-updated and patched IT infrastructure can suffer a breach. An organization that suffers a breach due to an unpatched system faces an uphill battle against charges of negligence in any civil or criminal court cases, regulatory action, insurance claims, or even defending an IT employee against being fired.
Judges, juries, and regulators will concede that IT departments cannot be held to unreasonable expectations of perfection. Organizations that can demonstrate that they were in compliance with a reasonable policy will have an advantage. Internally, and even angry executives cannot complain about employees that fulfilled the requirements ratified by other company executives when they signed off on the policy.
The written policy provides the reasonable standards and executive signatures on the policy confirm their expectations. Of course written policies that do not conform to regulatory guidelines may offer less defense.
AT&T notes various regulatory standards for patching and update frequency, but even with variance, the policy must be close to the expectations. For example, if the U.S. Department of Defense (DoD) requires current patches within 21 days, a DoD vendor with a written policy of quarterly patch updates will likely not be considered to have reasonable standards and will likely be accused of negligence in a breach.
Compliance Easy Button
Any compliance framework will establish rules. An organization seeking to comply with the framework must show evidence that they understand the rules and evidence that they comply with them.
Auditors always ask for written policies to help them easily understand the objectives of the organization and the type of evidence they can expect to receive. Fulfilling a written policy that has already conformed to a compliance framework makes it easy for the organization to satisfy the regulatory requirements.
Improved Operational Efficiency
Executing patch management policies can:
- add or enhance asset capabilities
- minimize downtime
- improves overall productivity
However, written policies deliver even more benefits.
First, the written policies help with IT personnel transitions by providing documentation of expectations and reports of past activity. These will combine to save time by helping new IT employees grasp the status and expectations of the organization with less training.
Written policies also help to formalize accountability within the organization and make it more difficult for systems to be overlooked or for business managers to put off updates that might interfere with business operations. The IT Department can point to the executive-approved-policy as a mandate to obtain cooperation.
Bottom Line
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 very helpful part of an overall cybersecurity program but need to be combined with other critical policies and strategies to ensure a resilient organization.
