Patch Management Procedure

1. Purpose

This procedure describes how software and firmware updates are identified, assessed, tested, approved, deployed and checked across the Organisation's technology estate. It makes sure vulnerabilities are closed within timelines proportionate to their severity and the exposure of the system, while keeping production services stable. It implements the Patch Management Policy.

2. Scope

• In scope: operating systems, firmware, hypervisors, containers and base images, databases, middleware, applications, libraries and dependencies, network and security devices, endpoints, mobile devices and cloud-hosted components that the Organisation manages.
• In scope: third-party software on Organisation systems, and software delivered by suppliers for which the contract places patching on the Organisation.
• Out of scope: software the supplier patches entirely on its own platform, such as multi-tenant software as a service; for these the Supplier Relationship Management Procedure requires evidence of the supplier's own patching.

3. Terms and Definitions

4. Roles and Responsibilities

5. Patch Management Procedure

5.1 Inventory and sources

• The asset register lists every system with its operating system, software versions, owner, class and environment. Without a register entry, a system is not on the patch schedule and is treated as a finding.
• The patch coordinator subscribes to supplier advisories, national alert services and the sources named in the Threat Intelligence Policy, and checks them at least [daily] for Class 1 technologies.
• Authenticated vulnerability scans run [weekly] on Class 1 systems and [monthly] elsewhere to confirm what is actually installed, using the Vulnerability Assessment and Penetration Testing Procedure.
• Developers keep a list of third-party components and are alerted to vulnerable ones by dependency scanning on every build.

5.2 Patch severity and timeline

Severity is the vendor rating or CVSS score, raised by one level if the system is reachable from the internet, holds Restricted data, or the vulnerability is actively exploited. The Head of IT Security decides in doubtful cases. Timelines run from the date the patch or a workaround is available.

5.3 Standard patch cycle

1. IdentifyThe patch coordinator lists new patches that apply to the estate, from advisories and scans, and opens a patch ticket per system group. Output: patch list. Time: [daily for advisories, weekly for review].
2. RateThe Head of IT Security assigns the severity and the deadline from the table. Time: [1 working day].
3. PlanThe coordinator agrees a window with owners, checks dependencies and prepares the change record with the test and rollback plans. Time: [2 working days].
4. TestPlatform engineers apply the patch in a test environment that mirrors production, and the owner runs functional checks. Time: [3 working days] for Critical, [5 working days] otherwise.
5. ApproveThe Head of IT Operations approves Normal patches; the change advisory board approves those with downtime or risk.
6. DeployEngineers take a backup or snapshot, deploy in phases (pilot group, then wider rings), and watch monitoring. Time: within the window.
7. VerifyA rescan or version check confirms the patch is in place, and the owner confirms the service works. Time: [1 working day] after deployment.
8. CloseUpdate the asset register and ticket; report any systems not patched on time.

5.4 Maintenance windows

6. Testing and Rollback

6.1 Test requirements

• Patches for Class 1 systems are tested in an environment that matches production in version and configuration; endpoint patches are tested on a pilot group of [5 percent] of devices first.
• Tests cover start-up, login, core functions, integration with dependent systems, performance, and monitoring and logging still working.
• Test results are recorded in the change ticket with the tester's name and outcome. Failure stops the rollout until resolved.
• Patches from unofficial sources are never installed. Checksums or signatures are verified.

6.2 Rollback

1. PrepareBefore deployment, take a verified backup, snapshot or image of the system and the configuration. Write down the rollback steps and how long they take.
2. DecideA rollback is invoked if the service fails its checks, performance degrades by more than [20 percent], or the owner requests it. The change manager decides within [30 minutes] of the failure.
3. ExecuteEngineers restore from the snapshot or uninstall the patch, then test the system.
4. Record and recoverLog the cause, keep affected systems protected by compensating controls, and plan a new attempt. Open a problem record if the patch was defective.

7. Emergency Patching

The Head of IT Security declares an emergency when a vulnerability is being actively exploited, or when delay would expose Restricted data or Class 1 services. The emergency path shortens the cycle but does not skip testing, approval or backup entirely.

1. DeclareThe Head of IT Security informs the Head of IT Operations, the incident manager and system owners by [phone and message] and opens an emergency change.
2. MitigateIf a patch is not ready, apply a workaround, block the vulnerable service at the boundary, or isolate affected systems, within [4 hours].
3. Test fastTest on a representative system for the critical function only, within [8 hours].
4. ApproveThe Head of IT Operations and the Head of IT Security approve; the change advisory board is informed and reviews afterwards.
5. DeployPatch Class 1 and internet-facing systems first, in rings, with engineers on standby. Target: within the emergency timeline above.
6. ReviewWithin [5 working days] hold a review: what was exposed, whether exploitation took place, and what to improve. If compromise is suspected, follow the Incident Management Procedure.

8. Patching Exceptions and End-of-Life Systems

Where a patch cannot be applied in time, the system owner requests a time-limited exception using the patch exception form (Annexure B). It must state the reason, the risk, compensating controls and the date by which the system will be fixed or replaced.

• Exceptions are recorded in the risk register and reviewed [monthly] while open. A renewal is not automatic and needs a fresh risk assessment.
• Unsupported software is not connected to the internet; it is isolated in a restricted segment, has extra monitoring and is on a replacement plan with a date.
• Compensating controls must be verified; for example, an unpatched web server must be behind a web application firewall with a virtual patch rule.

9. Special Cases

• Cloud and container images: rebuild and redeploy from patched base images rather than patch in place. Images older than [30 days] are rebuilt.
• Firmware and hardware: track firmware versions in the asset register; apply security firmware updates under the same timelines, with extra backup of configuration.
• Mobile devices and endpoints: enforce update deadlines through the mobile device management and endpoint tools; non-compliant devices lose access after [14 days].
• Supplier-managed systems: obtain written confirmation of patch level [quarterly] and require notice of delays.
• Customer-managed environments: provide customers with patch advisories and status as the contract requires.
• Patching of security tools and the patching system itself follows the same cycle and is monitored for tampering.

10. Measures

11. Records and Evidence

Annexure A: Patch tracking register

Annexure B: Patch exception request

Annexure C: Emergency patch record

12. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

13. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

14. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 27001:2022 references

Related documents

• Patch Management Policy
• Vulnerability Assessment and Penetration Testing Procedure
• Change Management Policy and Procedure
• Secure Configuration Policy
• Threat Intelligence Policy
• Malware Protection Policy
• Asset Management Procedure