Patch Management Template

Overview

Unpatched systems are the easiest targets. The Equifax breach, WannaCry, and countless other incidents were caused by known vulnerabilities that had patches available for months. Most teams patch reactively after a breach. This template creates a proactive patch management workflow: identify, test, schedule, deploy, and verify—before attackers exploit the gap.

When to Use

Use this resource when:

• Your security audit flagged unpatched systems or outdated dependencies
• You are building a vulnerability management program from scratch
• Production patches have caused outages in the past due to inadequate testing

Solution

# Patch Management Plan: `<System / Service>`

## 1. Patch Inventory

| CVE / Advisory | Severity | CVSS | Affected Systems | Patch Available | Current Version | Target Version | Owner |
|----------------|----------|------|------------------|-----------------|-----------------|----------------|-------|
| CVE-YYYY-NNNNN | Critical | 9.8 | `list` | `YYYY-MM-DD` | `X.Y.Z` | `A.B.C` | `@sre-team` |
| GHSA-YYYY-NNNNN | High | 7.5 | `list` | `YYYY-MM-DD` | `X.Y.Z` | `A.B.C` | `@platform-team` |

## 2. Patch Classification

| Severity | Criteria | Test Requirement | Deployment Window | SLA |
|----------|----------|------------------|-------------------|-----|
| Critical | RCE, privilege escalation, data exfiltration; actively exploited | Minimal: smoke test in staging | Emergency: within 24 hours | 24 hours |
| High | Remote attack vector; no known exploit yet | Standard: full regression in staging | Next maintenance window | 7 days |
| Medium | Local access required; complex exploit chain | Standard: full regression in staging | Next maintenance window | 30 days |
| Low | Denial of service only; no data impact | Deferred: test with next release | Next release cycle | 90 days |

## 3. Testing Checklist

- [ ] Patch applies cleanly without manual intervention
- [ ] Application starts successfully after patch
- [ ] Core user journeys pass (smoke test)
- [ ] Integration tests pass against patched environment
- [ ] Performance benchmarks within 5% of baseline
- [ ] No new errors in logs during 30-minute soak test
- [ ] Rollback image / snapshot available before production deploy

## 4. Deployment Schedule

| Environment | Window | Pre-approval Required | Rollback Ready |
|-------------|--------|----------------------|----------------|
| Staging | Anytime | Team lead sign-off | Previous image tagged |
| Canary (5% traffic) | Low-traffic hours | Manager notification | Instant rollback via LB |
| Production — Batch A (non-critical) | Tuesday 10:00 UTC | CAB for Critical patches | Snapshot + runbook tested |
| Production — Batch B (critical) | Immediate after staging pass | Security + manager | Snapshot + runbook tested |

## 5. Verification

| Check | Method | Owner | Timeline |
|-------|--------|-------|----------|
| Vulnerability scan post-patch | Nessus / Trivy / Snyk | `@security-team` | Within 24 hours of deploy |
| System health metrics | Grafana / Datadog dashboard | `@sre-team` | 1 hour post-deploy |
| Error rate baseline comparison | APM tool | `@sre-team` | 4 hours post-deploy |
| User-facing functional test | Synthetic monitoring | `@qa-team` | 4 hours post-deploy |
| Dependency audit | `npm audit`, `pip-audit`, OS package manager | `@platform-team` | Weekly |

## 6. Exception Log

| CVE | Reason for Delay | Risk Accepted By | Expiry Date | Compensating Control |
|-----|------------------|------------------|-------------|----------------------|
| | | | | |

Explanation

The template separates patch inventory (what needs fixing) from patch workflow (how you fix it safely). The classification table prevents every patch from being treated as an emergency—most teams burn out if they emergency-patch weekly. The testing checklist catches the most common patch failure: a library update that breaks a subtle integration. The exception log is critical for compliance; auditors will ask why a CVE was not patched, and “we forgot” is not an acceptable answer.

Variants

Context	Patch Source	Testing Approach	Notes
OS (Linux / Windows)	Package manager (apt, yum, WSUS)	Reboot test in staging; verify services start	Kernel patches often require reboot
Container base images	Docker image rebuild	Integration test with new base image	Use distroless or minimal images to reduce surface
Application dependencies	npm, pip, Maven, Cargo	Unit + integration test suite	Pin versions; use lock files; automate with Dependabot
Cloud-managed (RDS, EKS)	Provider-managed	Verify application compatibility after platform update	AWS / GCP notify in advance; schedule maintenance windows
Third-party SaaS	Vendor-managed	Monitor vendor status page; verify your integration	You cannot patch SaaS; verify their SOC 2 includes patch SLAs

Best Practices

1. Automate dependency scanning in CI; catch new CVEs before they reach production
2. Maintain a staging environment that mirrors production for patch testing
3. Tag rollback images before any production deployment
4. Document the exact patch command or pipeline; do not rely on one person’s memory
5. Review exception log monthly; delayed patches should not become permanent

Common Mistakes

1. Treating all patches as emergencies; this creates fatigue and increases error rates
2. Patching production without testing in staging; even minor updates can break things
3. Not verifying the patch actually closed the vulnerability (re-scan after deploy)
4. Patching during peak traffic without a maintenance window
5. Ignoring container base images; application dependencies get attention, OS libraries do not

Frequently Asked Questions

How do I handle a zero-day vulnerability with no patch available?

Activate compensating controls immediately: WAF rules, network segmentation, disabling the vulnerable feature, or adding rate limiting. Document the mitigation in the exception log. Monitor the vendor’s security advisory daily. When the patch drops, treat it as Critical severity regardless of its CVSS score—attackers are already prepared for it.

Should I automate patch deployment to production?

Automate only Low and Medium severity patches after they pass staging. Critical and High patches should have a human approval gate, even if the pipeline is automated. The approval should be a documented sign-off (Slack acknowledgment is acceptable) that verifies the patch was tested and the rollback plan is ready.

What is the difference between patch management and vulnerability management?

Patch management is the operational process of applying fixes. Vulnerability management is the broader program: discovery (scanning), risk assessment (CVSS + business context), prioritization, patching, and verification. This template covers the patching phase; you also need a scanning tool (Trivy, Nessus, Snyk) and a risk scoring process to feed the inventory.