How to use this template:
Comments intended to guide understanding and use of this patch management policy template will be enclosed in brackets “[…]” and the ‘company’ will be listed as [eSecurity Planet] throughout the document. When converting this template to a working policy, eliminate the bracketed sections and replace “[eSecurity Planet]” with “YourCompanyName.”
This policy will reflect a generic IT infrastructure and needs. It can be modified as needed to reflect a specific company’s IT infrastructure and needs.
To use this template, copy and paste the website text or download the Microsoft Word Template below.
[eSecurity Planet (or your company name here)] Patch Management Policy
1. Overview
Vendors regularly deliver feature updates, correct malfunctions, and issue security patches to improve the performance and eliminate security vulnerabilities in their products. Prompt adoption of these updates protects against threats and potentially improves the experience for users and can improve productivity for the organization.
Unpatched resources expose users, data, and other company resources to unacceptable risk. This Patch Management Policy:
- Outlines the expectations, requirements, basic procedures to maintain [eSecurity Planet] systems and software
- Defines reports to verify compliance with this policy
- Provides penalties for failure to comply with this policy.
[The purpose of this section is to introduce the reader to the policy purpose and what to expect later in the document. Policy defines what MUST be done, but not HOW it must be done. IT managers need the flexibility to accomplish the goals within their resources as they see fit.]
Learn more about patch management policy
2. Scope
This policy applies to all [eSecurity Planet] resources that connect to the organization’s network, enable the organization’s mission, or host the organization’s data. The organization will maintain and track a formal list of resources within the scope of this policy as defined in as defined in Appendix I: IT Resource Asset List of our downloadable template.
Patch management relies upon accurate lists of existing systems and software for updates. The scope should be verified [as per the asset management policy / monthly / quarterly] to ensure all assets can be accurately assessed for patching and updating.
[This is the most aggressive version of the scope. Some organizations do not attempt to update or monitor their employee’s devices connected to the network or ignore Internet of Things (IoT) devices. While this is risky, some organizations tacitly accept these risks for simplicity or because of resource constraints (budget, IT staff, time, etc.).
Scope should define what will be monitored for updating and patching. If the IT department will only patch operating systems for servers and endpoints, then edit the scope to say that – and accept the risks for the unmonitored systems.]
3. Patch Management Policy & Procedure
A. Patch Management Authority
[The Chief Information Officer (CIO) of eSecurity Planet] is designated as the Patch Management Authority that holds the ultimate responsibility and authority to plan, execute, authorize, or delegate any and all sections of this patch management policy and procedure to internal resources or third-party tools or vendors.
While the Patch Management Authority maintains ultimate responsibility, it is acknowledged that the [IT Department] will generally execute the Patch Management Authority’s plans to comply with the Patch Management Policy. The use of IT Department elsewhere in this policy refers to the Patch Management Authority, the [IT Department], and delegated representatives.
The Patch Management Authority also verifies and approves:
- Patch Management Policy Scope
- Patching priority
- Patching testing and approval
- Any maintenance downtime needed for applying patches and updates
- Any mitigations or exceptions needed
- Patch management reports
- Enforcement
[This section defines who needs to sign off on the budget and manage the patch management process. It is best to use a title because people sometimes change and the policy should not need to be revised with every personnel change.]
B. Patch and Update Acquisition
The IT Department will continuously monitor and scan a variety of sources to obtain information regarding the release of updates and patches for all assets within the scope of this policy. Sources may include, but are not limited to: security mailing lists, vendor notifications, and websites.
When a patch or update becomes available, the IT Department will find and verify the validity of the source prior to downloading the update. The preferred method is to obtain patches directly from the source vendor (company or organization that developed the resource for which the update was released) or from a service provider that obtains updates directly from the source vendor.
Patches and updates from other sources must be scrutinized and tested carefully prior to their introduction into the organization’s environment.
[This section is designed to enforce vigilance and prompt recognition of available updates and patches. Best practices suggest that specific individuals be assigned the task of researching, locating, and verifying the source of updates and patches.]
C. Patching Priority
Multiple patches and updates may become available simultaneously. If necessary, the IT Department will determine the priority for patching and updates and create a hierarchy based upon:
- The Common Vulnerability Scoring System (CVSS) Score of the patched vulnerability
- The risk value of the asset
- The likelihood of exploitation
The CVSS assigns vulnerabilities a score between 1 and 10. The CVSS version 3.0 ratings correspond to:
- 9.0 – 10.0 = Critical Severity
- 7.0 – 8.9 = High Severity
- 4.0 – 6.9 = Medium Severity
- 0.1 – 3.9 = Low Severity
- 0.0 = No Severity (Informational)
These scores do not suggest likelihood of exploitation, but do suggest a level of how much an attacker can affect a system or how much effort may be required. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) maintains a list of known exploited vulnerabilities that can be referenced to check for active exploitation.
[eSecurity Planet] uses risk analysis to create a Risk Assessment of internal systems that is recorded and updated in a Risk Register on a scale from 1 (low impact/value) to 10 (highest impact/value). Similarly, the IT Department needs to evaluate the current environment, the current IT architecture, and the nature of the vulnerability to determine the likelihood of exploitation, which should also be evaluated on a scale from 1 (low likelihood) to 10 (high likelihood). Adding all three of these factors will create a value between 2 (low priority or no action needed) and 30 (urgent action needed) for the patch to be applied.
When outsourcing to a service provider or using a patching tool, some patching will be performed automatically and no patching priority may be necessary. Patching priority will be required for updates and patches that:
- Require resource shut-down for maintenance
- Conflict with other patches and updates
- Cause problems with other systems or business processes
The manual patching queue may contain older, less urgent patches. New patches released should replace outdated patches in the queue. The replacement patch can take the same priority as the old patch or be re-prioritized at the IT Department’s discretion.
[This section assigns a priority to help determine which patches should be applied first in the patch management process. Weighting patch priority by CVSS tends to be the most common method used for prioritization and some organizations strictly use that method.
The value to the company and the likelihood of exploitation should also be considered when determining a priority. Still, be careful that no one manipulates the exploitation risk and value of the asset as a matter of casual convenience to avoid dealing with the update.
Managed patching services and tools will likely use CVSS values because they are tangible and neither the service nor the tool generally has visibility into asset values to the organization.
This section references Risk Assessments and a Risk Register. Organizations of all sizes can and should produce a Risk Register. The risk register assesses the value of a resource and how large an impact on the organization may occur if that resource is impaired, becomes compromised, or fails. If no Risk Register is in place an organization will need to make a qualitative estimate of the value of the resource to the organization.]
D. Patching and Update Schedule
Based upon the patching priority rating of 2 to 30 the IT Department will be required to apply the patch:
- 24.0 – 30: within [7] days of patch release
- 18.0 – 23.9: within [14] days of patch release
- Security patches below 18.0: within [30] days of release
Non-security patches (upgrades and bug fixes) shall be applied on a normal maintenance schedule as defined by normal systems maintenance and support operating procedures, but not to exceed [90] days. Lower-rated patches and updates can be applied along with higher priority patches or updates upon the discretion of the IT Department.
For example:
- A non-critical software bug fix rated 8.4 can be installed simultaneously along with other vulnerability fixes rated 25.3 and 28.0.
- A non-critical feature upgrade to a router rated 15.4 may be delayed in installation because the IT Department may need to work on manually updating 50+ routers for a 13.0 rated security vulnerability and the upgrades cannot be performed simultaneously.
In practice servers and endpoints will be patched monthly, with expedited patching for critical vulnerabilities, especially where there is a publicly disclosed method of attack. Security updates for all systems must be installed and systems rebooted (if needed) within the required timeframes.
[The exact rating system and urgency will be up to the organization. The schedule based upon priority should ensure prompt action on the most critical patches and updates on the most critical resources. The 90 day maximum for applying upgrades and patches should prevent any system or software from being overlooked or ignored entirely or for updates to pile up.]
E. Patching Guidelines
Once a patch has been obtained and prioritized, the following steps should be followed.
i. Patch Testing
For high value resources, the IT Department may decide to test the patch in a test environment to check for possible business disruption or other issues. Patches that fail the testing process may be excluded from the patching process so long as the IT Department follows the Exception and Mitigation process (See Paragraph 3.F, below).
[Third-party vendors and patch management services or tools will test patches in generic environments. However, unintended consequences may be experienced for specific IT architectures or dependent systems.
Testing patches in a test environment allows the IT Department to discover those issues in an environment that will not affect business processes. Not all organizations have the resources to perform patch testing and patch testing for low value resources may not be a cost-effective use of time or resources.]
ii. Patches Management Preparation
Not all patches will be applied successfully or without issue. In some cases a patch may render a device unusable or cause cascading problems to other IT systems or software. To prepare for this possibility, the IT Department must ensure that [the Disaster Recovery Policy has been executed prior to the Patch Management process.
At the very least]:
- A full system backup has been performed prior to the application of the update
- A full data backup has been performed prior to the application of the update
For firmware updates to critical systems (routers, servers, etc.), a backup system may be required to be in place should the firmware update render the original device non-functional.
For unsuccessful updates, the IT Department will attempt to roll back the system or software to a previous version to recover functionality. Systems that cannot be rolled back will need to be restored from backup or replaced promptly.
The IT department may attempt multiple times to apply patches and updates. For patches or updates that cannot be successfully applied, the IT Department must follow the Exception and Mitigation process below.
[This section acknowledges that not all patches work as intended and the IT Department must prepare for that possibility before applying patches of any kind. We recommend referring to an established Disaster Recovery Policy that should cover backups and recovery systems in detail, but organizations without such a policy can delete that text and simply require backups to be performed.]
iii. Automated Patch and Update Management
Many vendors enable automated patching procedures for their individual applications. Additionally, there are a number of third-party tools and service providers to assist in the patch management process.
Where practical and possible, the IT Department should use appropriate options to automate the patch management process. Automated services can relieve the potential burden from the IT Department and enable prompt application of patches throughout the IT environment without delay.
The IT Department must ensure that all patch management preparation (See Section 3.E.ii above) has been completed successfully prior to allowing any automated processes to proceed.
It is acknowledged that firmware, IT appliances (routers, etc.), and software vendors may require manual patching and updating. Vendors and tools used for automated patching should explicitly list what they do and do not cover for patching and updating and the asset list should reflect which items require manual updates.
iv. Manual Patch Management
Some patches and updates (especially firmware) will require a manual process. For updates that do not disrupt business processes the IT Department may apply the patch at their discretion within the allocated time given the urgency of the patch and update.
Some patches may require the shutdown of critical business systems. To avoid excessive disruption, these Maintenance Windows need to be scheduled and approved in advance by the Patch Management Authority, preferable with the consent of the appropriate business managers affected by the disruption.
To obtain approval, the IT Department must [issue a ticket / fill out a form / send an email] issued to the Patch Management Authority with the following information in a Maintenance Window request:
- Details regarding affected systems
- Details regarding the urgency of the patch and risk
- Preferred maintenance window and at least one alternative window
- Details regarding rollback procedures should the patch fail
For emergency patches required in the absence of the Patch Management Authority, the next available executive in the organization chart can approve the maintenance window.
Should an emergency patch need to be applied and no executive can or is willing to authorize the patch in a reasonable timeframe given the urgency of the patch, the IT Department may document their efforts to obtain approval and apply the patch or update without formal approval. It is acknowledged that emergency patches and maintenance disruptions may occasionally be required, but the IT Department should always minimize disruption.
[This formally written part of the patching process requires those responsible for implementing the patch to request a maintenance window for when the software update will cause downtime for users or systems in active use.]
v. Patch Verification and Testing
Once the patching and updating process completes, the IT Department should check that the patches applied successfully or report and fix unsuccessful patches. The IT Department should also verify that vulnerabilities addressed by the patch have indeed been mitigated or eliminated by the patch.
Vulnerabilities that remain exposed must be addressed as required under Exceptions and Mitigations (Paragraph 3.F, below).
F. Exceptions & Mitigations
Exceptions can occur in the patching and updating process. These exceptions will be categorized as:
- Failed Patches: Patches and updates that fail to install correctly
- Disruptive Patches: Patches and updates that will cause unacceptable business disruption if installed
- Unneeded Patches: Non-security patches or updates that enable or fix unneeded or unwanted features
- Unpatched Vulnerability: Some assets may also have vulnerabilities that remain unpatched by vendors for various reasons (end of life, vendor out of business, etc.)
All categories must be recorded into an exceptions list. Unneeded patches will simply be recorded and checked [quarterly] to ensure they remain unneeded.
Failed, Disruptive, and Unpatched Vulnerabilities will require mitigation. The IT Department will develop and propose appropriate mitigation measures to limit the risk and potential damage of the unpatched vulnerability to the organization. Each mitigation plan must be approved by the Patch Management Authority and include:
- Details regarding affected systems
- Details regarding the urgency of the unpatched vulnerability
- Details regarding the mitigation and how it addresses the unpatched vulnerability
- Preferred deployment window and at least one alternative window. Note if any business systems will need to be taken down to implement the mitigation.
The mitigation and exception list will be reviewed on a [quarterly] basis to determine:
- If patches have been released so the mitigation may be discontinued
- If assets should be or have been retired or replaced so mitigation may be discontinued
- If any mitigations may be improved in any way
The Patch Management Authority must approve the [quarterly] review of the mitigation and exception list.
[If a patch cannot be applied, a different approach to mitigating the risk must instead be developed and approved in writing. Most organizations can perform a quarterly review as outlined in this document. However smaller organizations may only have resources for twice-annual or annual reviews and larger organizations may be more aggressive and want monthly or weekly reviews.]
G. Patch & Update Reporting
The IT Department will issue [monthly] reports on patching and updating. The monthly reports must include:
- Date of last asset scan and number of assets tracked
- The percent of systems covered by automated patch management
- The percent of systems monitored for patching
- The number of patches vendors issued or the organization acquired in the period
- The number of patches in the period that failed quality checks
- The number of patches that failed to install correctly
- The number of patches that resulted in incident tickets
- The number of successful patch implementations vs # of unsuccessful patches
- Average time elapsed between patch availability and deployment by CSV rating and by asset risk or value category
- The number of exceptions added to the exception report
- The total number of exceptions on the exception report
[The IT Department must issue reports so that the organization can verify that the patch management procedures are followed properly and that patches and updates are made on a timely basis. Regular reports may eliminate the need for special reports for compliance.
The data in the report should also be used to help improve the patch management process. For example, the number of patches that result in tickets can be used to determine if additional patch testing is needed or if the current testing needs improvement.
More mature organizations may also use regular vulnerability testing and pen testing to verify patches have been properly installed. These testing reports can be added to the regular patch and update reports.]
4. Audit Controls and Management
[eSecurity Planet] executives and auditors may request documented procedures and evidence of the patch management practice on-demand. Examples documented procedures and evidence include:
- Approved Maintenance Window Requests
- Approved Exception Lists
- System updates and patch logs for all major system and utility categories
- Logs should include system ID, date patched, patch status, exception, and reason for exception
- Demonstrated infrastructure supporting enterprise patch management across systems, applications, and devices
- Patch Management Reports
[This section acknowledges occasional needs for executives and auditors to need off-schedule reporting on the Patch Management processes. To verify Patch Management reports, some auditors may also require system logs that confirm successful system or software updates.]
5. Enforcement
Employees found in intentional policy violation may be subject to disciplinary action, up to and including termination The job performance of IT Department staff responsible for executing this policy will be evaluated based in part or in full on their ability to fulfill the expectations of this policy.
Regular inability of the IT Department to meet the requirements of this Patch Management policy may be considered negligence and result in disciplinary action. Falsified reports or gross negligence in execution may be grounds for immediate termination or disciplinary action.
Devices containing operating systems, software, and firmware that do not comply with patching requirements should be excluded from accessing resources critical in value or function and should be limited to DMZ or segregated network sections.
[For policies to be effective, there should be penalties for non-compliance. Although briefly mentioned here, a Network Security Policy should explicitly determine how and what non-compliant devices may access within the organization.
This document assumes that organizations that fail to meet the update standard due to lack of resources will not hold their IT Department accountable when overworked or overloaded. Organizations that apply unreasonable expectations will likely experience high IT Department turn-over and difficulty in retaining experienced or competent staff.]
6. Distribution
This policy is to be distributed to all [eSecurity Planet] executives and IT Department staff responsible for Patch Management Policy support and management.
[Anyone that will need to work on patch management (IT Department staff) or be affected by the policy (at least executives, but possibly other relevant employees) should receive this policy. Employees responsible for execution may need to formally acknowledge receipt.]
7. Policy Version
Version 1.0
Approval Date: 11/15/2022
Description: Initial Policy Drafted
[This section can also be made into a Policy Version History with a table of previous versions and approvals.]
8. Signatures
Approved By: ____________________________________________
[Patch Management Authority Signature]
Approved By: ____________________________________________
[CEO or other applicable Executive]
[A signature by the Patch Management Authority acknowledges the requirements of the policy and becomes a de facto pledge to meet the requirements. A signature by the CEO or other executive acknowledges that the policy meets the needs of the organization. The executive that signs should be senior enough that their signature will compel other departments to comply with the policy.]
Appendix
I. IT Resource Asset List
[As per the Asset Management Policy,] the asset list of the organization should cover all systems, software, firmware and devices of the organization. The asset list may also include devices outside of the control of the organization, but connected to the network such as BYOD, leased equipment with access, contractor’s equipment, etc.
Examples of resources on the asset list include, but are not limited to:
- Network equipment
- Firewalls (and installed software, firmware, security features that require updates)
- Network switches (and installed software, firmware)
- Routers (and installed software, firmware)
- Servers (websites, application hosts, virtualization platforms, etc.) and installed operating system
- stalled operating system, installed software, firmware)
- Workstations
- Tablets
- Laptops
- Cellular devices
- Internet of Things (IoT) and installed software and firmware
- Voice over Internet Phones (VoIP)
- Security Cameras
- Wi-Fi Connected TVs
- Wi-Fi Printers
- Network Printers
- Storage Array Networks (SAN)
- Voice-activated devices (Amazon Alexa, etc.)
- [Heart monitors and other medical devices]
- Solar panel systems
- Door security badge-readers
- Operational Technology (OT) and Connected Infrastructure and installed software or firmware
- 5G-connected conveyer belt
- Connected HVAC equipment
The asset list should include:
- Type of asset (Server, PC, software, router, etc.)
- Device assigned owner (if a shared resource, the head of the associated department is the defacto assigned owner)
- Core OS, Firmware, or Software version
[Note: tracking and maintaining specific versions can be useful, but burdensome for organizations using a manual tracking system.] - Manual or automatic update?
- Updated by IT Department, automatic software update, third-party tool, or third-party service provider?
- Last updated
- Update successful (Y/N)
- Associated devices (IE. for Adobe Acrobat software: installed on associated device: PC4362)
While the [IT Department] maintains responsibility for maintaining the asset list, department heads must inform the IT department about new assets (devices, installed software, etc.) deployed. Devices or software deployed without informing the IT department will be considered rogue devices and subject to blocking and removal.
The [IT Department] will conduct [continuous/monthly/daily/quarterly] scans of the IT environment to verify that the asset list remains current and to detect rogue devices or software.
The current asset list is stored:
[List the Asset database, Excel spreadsheet, asset management tool here.
Note: using an excel spreadsheet can be vulnerable to accidental or intentional corruption or changes. A version controlled Google Spreadsheet or an Excel file stored in OneDrive or Sharepoint would be better options.
Organizations should develop and maintain an Asset Management Policy. Development of the policy and an example asset list is beyond the scope of this sample document.
BYOD devices should not be tracked in an asset list. The maintenance of BYOD devices should be enforced using network access control features or tools that check devices for minimally accepted security profiles.]
