# Windows Patch Management Policy

> Template status: Draft — replace every bracketed field and obtain authorization before production use.

## 1. Document control

- Organization or client: [name]
- Policy owner: [role and name]
- Approving authority: [role and name]
- Effective date: [YYYY-MM-DD]
- Review date: [YYYY-MM-DD]
- Version: [version]
- Related ticket, contract, or risk record: [reference]

## 2. Purpose

This policy defines how [organization] evaluates, approves, deploys, verifies, reports, and, when necessary, rolls back Windows updates across authorized managed endpoints.

## 3. Scope and authority

- Included organizations, sites, groups, and device classes: [scope]
- Explicit exclusions: [exclusions]
- Authoritative patching system: [platform]
- Other update authorities that must be disabled or coordinated: [systems]
- Roles permitted to approve normal changes: [roles]
- Roles permitted to approve emergency changes: [roles]
- Roles permitted to pause or roll back deployment: [roles]

Offline, stale, unsupported, and otherwise unknown devices remain in the reporting denominator until formally removed from scope.

## 4. Update classes and default decisions

| Update class | Default decision | Deadline | Required review | Validation | Notes |
| --- | --- | --- | --- | --- | --- |
| Monthly quality and security updates | [approve/review] | [time] | [owner] | [evidence] | [notes] |
| Out-of-band security updates | [approve/review] | [time] | [owner] | [evidence] | [notes] |
| Feature updates | [approve/review] | [time] | [owner] | [evidence] | [notes] |
| .NET and Microsoft applications | [approve/review] | [time] | [owner] | [evidence] | [notes] |
| Drivers and firmware | [approve/review] | [time] | [owner] | [evidence] | [notes] |
| Third-party applications | [approve/review] | [time] | [owner] | [evidence] | [notes] |

## 5. Deployment rings

| Ring | Authorized scope | Start condition | Observation period | Promotion evidence | Stop condition | Decision owner |
| --- | --- | --- | --- | --- | --- | --- |
| Lab | [devices] | [condition] | [time] | [evidence] | [condition] | [owner] |
| Pilot | [devices] | [condition] | [time] | [evidence] | [condition] | [owner] |
| Broad production | [devices] | [condition] | [time] | [evidence] | [condition] | [owner] |
| Critical systems | [devices] | [condition] | [time] | [evidence] | [condition] | [owner] |

No ring advances while material failures, unknown endpoint states, pending business-application checks, or unresolved rollback concerns remain.

## 6. Maintenance and restart controls

- Workstation maintenance window and IANA time zone: [window]
- Server maintenance window and IANA time zone: [window]
- User notice method and lead time: [method]
- Deferrals and maximum grace period: [rule]
- Forced-restart rule: [rule]
- Active-hours behavior: [rule]
- Signals that must remain visible during maintenance: [signals]
- Authorized maintenance-suppression scope: [scope]

## 7. Emergency changes

An emergency change requires [evidence criteria], approval from [role], an explicit device scope, a communication owner, a rollback path, and a post-change review by [deadline]. Active exploitation, internet exposure, privilege, business criticality, and compensating controls must be considered alongside severity.

## 8. Exceptions

Every exception must record:

- Devices, update, or vulnerability in scope
- Business and technical reason
- Exposure and criticality
- Temporary mitigating control
- Accountable owner
- Approver and approval date
- Expiry and review date
- Permanent-remediation plan
- Evidence required to close the exception

## 9. Predeployment checks

- [ ] Scope reconciled against the authoritative inventory
- [ ] Endpoint check-in and scan data are current
- [ ] Known issues and active exploitation reviewed
- [ ] Representative pilot devices available
- [ ] Recovery evidence verified for critical systems
- [ ] Free space, power, dependencies, and restart state checked
- [ ] Business owner and service desk communication prepared
- [ ] Rollback trigger, decision owner, and action documented

## 10. Validation and failure handling

The patch cycle distinguishes offered, downloaded, installed, failed, pending restart, excluded, paused, offline, stale, and unknown states. Each failed or unknown endpoint is assigned to [queue or owner] with a due date and safe next action.

Successful completion requires:

- Expected update or build verified
- Required restart completed or explicitly tracked
- Endpoint check-in restored
- Business service or application validated
- Original device scope reconciled
- Exceptions and unresolved work assigned
- Technician actions and timestamps retained

## 11. Rollback

- Rollback trigger: [condition]
- Authorized decision owner: [role]
- Recoverable action: [procedure or runbook]
- Maximum recovery time: [time]
- Evidence required after rollback: [evidence]
- Communication path: [contacts and channels]

## 12. Metrics and reporting

Report at least:

- In-scope endpoint count
- Completed by deadline
- Failed installations
- Pending restarts
- Offline, stale, and unknown endpoints
- Active exceptions and exception age
- Unsupported operating systems
- Median and maximum remediation time for urgent updates
- Unresolved devices, owner, and next action

## 13. Review and approval record

Review this policy after a material incident, platform or authority change, audit finding, or at least annually.

| Role | Name | Decision | Date | Evidence or reference |
| --- | --- | --- | --- | --- |
| Policy owner | [name] | [decision] | [date] | [reference] |
| Security or risk owner | [name] | [decision] | [date] | [reference] |
| Service owner | [name] | [decision] | [date] | [reference] |
| Client or business authority | [name] | [decision] | [date] | [reference] |

---

This vendor-neutral template is provided by Nizlo as a planning aid. It is not legal, compliance, security, or operational advice and does not itself authorize any endpoint change.