Patch Management Policy

1. Purpose

This policy makes sure that known vulnerabilities in software and firmware are fixed before they can be used against the Organisation. It sets patch deadlines linked to risk, the testing and deployment approach, and the way that systems which cannot be patched are protected.

2. Scope

The policy covers operating systems, firmware, hypervisors, databases, middleware, applications, libraries, containers and images, network and security devices, endpoints, mobile devices and cloud-hosted systems for which the Organisation is responsible for patching under the shared responsibility model.

• In scope: the Organisation's own systems and systems run for it by suppliers, where the contract makes patching a supplier duty and the Organisation checks evidence.
• In scope: third-party and open source components in software that the Organisation builds.
• Out of scope: systems fully managed and patched by a SaaS provider; the provider's patching is reviewed under the Supplier Relationship Management Policy.

3. Terms and Definitions

4. Roles and Responsibilities

5. Policy Statement

5.1 Identification and rating

• Vulnerability information must be collected from supplier advisories, security bulletins, scanner results and threat intelligence, and reviewed at least [daily] for internet-facing systems and [weekly] for others.
• Each vulnerability is rated by the patch manager using the base severity and adjusted for exposure, exploit in the wild, asset criticality and compensating controls. The adjusted rating sets the deadline.
• All systems must be in the asset register, with version and patch level, so that an advisory can be matched to affected assets within [1 working day].

5.2 Patch deadlines

The clock starts when the patch is available. Where only a workaround exists, it must be applied within the same period and the patch applied when released.

5.3 Testing and deployment

1. Patches must be tested before production use, in a test group of at least [5%] of systems or a test environment that matches production. Emergency patches may use a reduced test with documented risk acceptance.
2. Production deployment follows the Change Management Policy and Procedure. Routine patching is a standard change with a pre-approved template, and high-risk systems need a normal change.
3. Deployment uses waves: test group, then low-risk systems, then production, with a pause of at least [24 hours] between waves unless urgency demands otherwise.
4. Each deployment has a rollback plan. A backup or snapshot is taken first for Tier 1 and Tier 2 systems.
5. Automatic updates are enabled for endpoints and for services where a failure is tolerable. Servers are patched in scheduled windows.
6. After deployment, the engineer verifies that the patch is installed, services work, and a vulnerability scan no longer reports the issue within [7 days].

5.4 Systems that cannot be patched

• If a patch cannot be installed in time because of compatibility, vendor support or business need, the system owner must raise an exception with the risk, compensating controls such as network isolation, virtual patching or monitoring, and an end date no later than [90 days].
• End-of-life software must not be used for Tier 1 or Tier 2 systems. Where unavoidable, it must be isolated, monitored, listed in the risk register and scheduled for replacement.
• Firmware and appliance patches are included. Vendor support contracts must cover security patches for the system life.

5.5 Software that the Organisation builds

• Dependencies and base images must be scanned on each build. Critical and high findings block release unless an exception is approved.
• Dependency updates are applied within the deadlines above, counted from the release of the fix, and the application is rebuilt and redeployed.

6. Patch Cycle and Worked Example

7. Compliance and Monitoring

Detailed steps and forms are in the Patch Management Procedure.

8. Measures

9. Records and Evidence

• Advisory log with severity decisions, kept [2 years].
• Patch test and deployment records linked to change records, kept [3 years].
• Scan results and compliance reports, kept [2 years].
• Exception records and compensating controls, kept [3 years] after closure.

Annexure A: Patch exception request

10. 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.

11. 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.

12. 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 Procedure
• Change Management Policy and Procedure
• Vulnerability Assessment and Penetration Testing Procedure
• Secure Configuration Policy
• Malware Protection Policy
• Threat Intelligence Policy
• IT Asset Management Policy