ISMS/03-procedures/patch-management-procedure.md

Title: Patch Management Procedure Document ID: [PROC-PATCH-001] Version: 0.1 Draft Status: Draft Owner: CISO (Paul Jenkins) Approver: CISO (Paul Jenkins) Classification: Internal Effective date: [DD Month YYYY] Review date: [DD Month YYYY]

Patch Management Procedure

Purpose

This procedure defines how BlackDice should assess, test, schedule, deploy, and verify security patches and updates.

Scope

This procedure applies to operating systems, applications, dependencies, cloud images, containers, endpoints, managed services, and other patchable in-scope components.

Trigger / When Used

Use this procedure when:

• security patches become available
• emergency patching is required due to active risk
• periodic patch cycles are performed
• vulnerability management identifies missing updates

Procedure Steps

1. Identify relevant patches or updates and the assets they affect.
2. Assess urgency based on severity, exploitability, exposure, and business impact.
3. Determine whether testing is required before deployment and identify any change approval requirements.
4. Schedule deployment according to risk, operational impact, and service constraints.
5. Apply the patch or update through controlled and traceable methods.
6. Validate that the update completed successfully and that the affected service remains stable.
7. Record patch status, timing, failures, and follow-up actions.
8. Where patching cannot proceed, document the reason and apply compensating controls, exception handling, or risk acceptance as appropriate.

Inputs

• patch or update notice
• affected asset inventory
• vulnerability context
• testing and change requirements

Outputs / Records

• patch deployment record
• change record where applicable
• validation evidence
• exception or risk record for deferred updates

Roles and Responsibilities

• [Role] must oversee patch management expectations.
• System owners must ensure updates are assessed and applied to their assets.
• Operational teams must carry out deployment and verification steps.

Escalation / Exceptions

Escalate where:

• critical security patches cannot be applied in time
• patching causes service degradation or rollback
• supplier-managed services require unresolved external action
• testing shows a material incompatibility or business risk

Exceptions must be documented and approved where required.

Related Documents

• Vulnerability and Patch Management Policy
• Vulnerability Management Procedure
• Change Management Policy
• Production Deployment Procedure

Version Control

Version	Date	Description of Change	Author
0.1 Draft	[DD Month YYYY]	Initial draft.	[Name or Role]