Developing a Patch Management Framework

Observations

ITIL 4 doesn’t have a specific patch management practice. Instead, effective patching is an outcome of several interconnected ITIL practices. To define your patch management framework, consider and consult the following ITIL practices, as each plays a prominent role in choosing how change will impact the organisation.

Define Your Service Level Agreements (SLAs) – Service Level Management

For many organisations, the first inclination is to reach for patch management tools and hope that they solve all issues. This should be the last step in the process. At IBRS, we have observed that the patch management framework should consider SLAs, responsible, accountable, consulted, and informed (RACI) practices, and agreements that drive the requirements for a change window. The patch management tools support the change by executing and automating the required steps. Typically, changes impacting operating systems or core applications must be approved by a change administration board (CAB). For many government organisations, the Digital Transformation Agency (DTA) has created the Essential Eight (E8) mitigation strategies to enable SLAs and service management alignment.

Vulnerabilities are set in three main categories:

• Critical Vulnerabilities: Patch within 48 hours of discovery. This applies to vulnerabilities in internet-facing operating systems and applications that are easily exploitable.
• High-Risk Vulnerabilities: Patch within two weeks.
• Standard/Low-Risk Patches: Patch within one month during a standard monthly cycle.
  These SLAs serve as the performance targets that any patch management framework, tool, or process must meet.

Tie in ITIL Practices Across Your Patch Management Framework

Once vulnerabilities are ranked, your standard operating procedure(s) should reflect the lifecycle for all patching and be updated as the architecture is revised. Relevant ITIL V4 practices can be drawn from Pink Elephant¹ whose definitions are summarised under General Management and Service Management practices attributable to patch management. The relevant ITIL practices include:

General Management Practices

1. Continual Improvement: Continuously improve products, services, and processes to meet changing business needs.

Service Management Practices

1. Change Enablement: Maximise successful IT changes by managing risk and authorising changes.
2. IT Asset Management: Manage the lifecycle of IT assets to maximise value and meet regulatory requirements.
3. Service Level Management: Set clear performance targets and manage service delivery accordingly.

At IBRS, we have observed that clear coordination paths must be embedded in an RACI to support the patch management framework. This provides clarity for those leading the change, and where process dependencies and communication are required. The ITIL 4 practices are expanded below to explain each practice and the actions required in the RACI.

Step 1. Service Level Management (SLM): Defining your SLM or SLA provides several benefits for your patch management framework. Existing systems will have knowledge articles to inform stakeholders, but new applications may need support to align with them. Focus should be on:

1. Minimising Service Disruption: By scheduling reboots, temporary outages, and regular maintenance at times that least impact the majority of users.
2. Ensure a Risk Assessment: Use a risk assessment for each change to ensure it does not breach the SLA and cause downtime, which can impede business performance.
3. Prioritisation: Patching the vulnerabilities according to their importance under the E8 ranking.
4. Communication and Expectation Management: Here, the RACI ensures that both the IT department and the business are aware of and clearly understand the SLAs, thereby adhering to the principles supporting the patch management framework.

Step 2. Identify & Discover (IT Asset Management): You can’t patch what you don’t know you have. The fundamental requirements for a patching tool should include the automation for identification and discovery of devices by constantly scanning your network to discover all installed operating systems and applications (including versions). This is crucial for your random open-source freeware and bespoke applications.

Step 3. Assess & Prioritise (IT Asset Management): The tool requirements should automatically compare the discovered software against a global vulnerability database, like the Common Vulnerabilities and Exposures (CVE) list². Patching can then be prioritised based on severity (Common Vulnerability Scoring System (CVSS) score) and applicability to your environment, aligning with your E8-based SLAs.

Step 4. Test (Change Enablement): All patches, especially for servers and bespoke applications, must be tested. Steps include:

• Create Pilot Groups: Designate a small, representative group of users and servers as a testbed.
• Automated Deployment: Ensure your chosen patching tool can automatically deploy patches to this pilot group first.
• Validation: Monitor for issues (application crashes, performance degradation) for a defined period (e.g., 48-72 hours).

Step 5. Approve & Schedule (Change Enablement): Once testing is successful, the change is approved following the agreed deployment process. The requirements for the patching tools should include the ability to schedule the deployment to the broader environment based on your SLAs and pre-defined maintenance windows to minimise disruption.

Step 6. Deploy (Change Enablement): The tool executes the deployment automatically. The best tools offer policy-based deployment rings, moving from the pilot group to broader groups of workstations and servers in a controlled manner. Microsoft inTune Update Rings enables scheduling of OS and apps in part or in whole³.

Step 7. Verify and Report (Continual Service Improvement): The tool must provide clear dashboards and reports to confirm successful installation across all devices. This is non-negotiable for proving E8 compliance. Reports should show patch status, compliance percentages, and any failed installations for remediation.

Patch Management Solutions

Given that most IT environments include a mix of Intune/Microsoft Endpoint Configuration Manager (SCCM), workstations/servers, and a variety of application types, a flexible tool can integrate and extend your current capabilities rather than just replace them.

Consolidated Recommendation Summary

This table compares five patch management tools to help you align your specific requirements. This market scan is a shortlist of leading, feature-rich patch management tools, and we recommend a detailed review of their features to determine which is most suitable for your needs.

Next Steps

1. Conduct a detailed review of your current change management processes and identify areas for improvement in light of ITIL 4 practices.
2. Facilitate a whiteboard session to map an end-to-end change management framework with your team.
3. Host an advisory call with your team to discuss strategies for integrating ITIL 4 into your patch management frameworks and related methodologies, such as DevOps.
4. Present your existing patch management framework for a complimentary pencil review, including recommendations for ITIL 4 best practices and modern tools that support your organisation’s needs.

Footnotes

1. ‘ITIL® 4 Practices: A Complete Guide – Knowledge Library’, Pink Elephant EMEA, 2025.
2. ‘National Vulnerability Database (NVD)’, NIST, 2024.
3. ‘Configure Windows Update rings policy in Intune’, Microsoft Learn, 2025.