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] |