How to Build a Patch Management Program From Scratch

You cannot patch systems you do not know exist. The asset inventory is the foundation of every other patch management component: and it is almost always less complete than IT believes.

What the inventory needs to track:

• System hostname and IP address
• Operating system version (exact build number, not just 'Windows 10')
• Installed software and versions (critical for third-party patching)
• System owner and business function
• Production vs non-production classification
• Network location (internet-facing, internal, DMZ, OT)
• Patch management tool enrollment status

Building the inventory:

# Windows: Export all enrolled systems from Windows Update for Business / WSUS
Get-WsusComputer | Select-Object FullDomainName, OSDescription, LastSyncTime |
    Export-Csv -Path C:\inventory\wsus_systems.csv

For cloud infrastructure:

# AWS: List all EC2 instances and their patch state
aws ec2 describe-instances --query \
  'Reservations[*].Instances[*].{Name:Tags[?Key==`Name`]|[0].Value, \
  InstanceId:InstanceId, State:State.Name, OS:Platform, PrivateIP:PrivateIpAddress}' \
  --output table

# AWS Systems Manager Patch Manager: compliance report
aws ssm describe-instance-patch-states --output table

Gap identification: After building the inventory from managed sources, run a network scan against your IP space to find systems not in the inventory (common causes: shadow IT servers, legacy systems removed from management tools, cloud instances not enrolled in SSM):

nmap -sn 10.0.0.0/8 -oG - | grep 'Up$' | awk '{print $2}' > live_hosts.txt
# Compare live_hosts.txt against your known inventory

Any IP with a live host that is not in your inventory is an unmanaged system: either enroll it in patch management or decommission it.

A patching SLA defines how fast each vulnerability severity class must be remediated. Without an SLA, every patch is theoretically urgent: so none are treated as urgent in practice.

Recommended patching SLA tiers:

Using CISA KEV as an emergency trigger:

CISA's Known Exploited Vulnerabilities catalog lists CVEs with evidence of active exploitation. Every CVE added to KEV should trigger an emergency review regardless of CVSS score: some KEV entries have CVSS scores below 7.0 but are being actively exploited at scale.

# Download the latest CISA KEV catalog
curl https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  -o /tmp/kev.json

# Count new additions in the last 7 days
cat /tmp/kev.json | python3 -c "
import json,sys
from datetime import datetime, timedelta
data = json.load(sys.stdin)
cutoff = (datetime.now() - timedelta(days=7)).strftime('%Y-%m-%d')
new = [v for v in data['vulnerabilities'] if v['dateAdded'] >= cutoff]
print(f'{len(new)} new KEV entries in the last 7 days')
for v in new:
    print(f"{v['cveID']}: {v['vulnerabilityName']}")
"

Documenting exceptions: When a patch cannot be deployed within the SLA (incompatible application, no maintenance window, vendor has not released a patch), document:

• The CVE and affected system
• The reason the SLA cannot be met
• The compensating control in place (WAF virtual patch, network isolation, monitoring)
• The expected remediation date
• The risk owner who approved the exception

Exceptions without documentation become permanent. Every exception needs an expiry date.

Patches that break production are a patch management program killer: one incident that requires a 3 AM rollback creates organizational resistance that takes months to overcome. A testing process prevents this.

The deployment pipeline for standard patches:

Stage 1: Patch validation (lab/non-production) Deploy the patch to a test environment that mirrors production as closely as possible. Run application smoke tests: key user journeys, critical business processes. Hold for 24-72 hours after deployment; most compatibility problems appear within the first day of use.

Stage 2: Pilot deployment (5-10% of production systems) Deploy to a representative sample of production systems: not the most critical, but a cross-section that reflects the diversity of your environment (different OS versions, different software stacks). Hold for 48-72 hours and monitor for errors, crashes, and application failures.

Stage 3: Broad deployment (remaining production) If Stage 2 completes without incident, deploy to all remaining systems within the SLA window.

For Emergency patches: The testing process is compressed but not eliminated. Emergency patches should still go through a 4-hour test environment validation and a 2-hour pilot before full deployment. Skipping testing entirely for emergency patches is the most common cause of outages.

Tooling for Windows environments:

# Microsoft Endpoint Configuration Manager (MECM/SCCM): phased deployment
# Create deployment rings:
# Ring 0: Test servers (immediate after Patch Tuesday)
# Ring 1: Non-critical workstations (T+7 days)
# Ring 2: Production servers (T+14 days)
# Ring 3: Critical production systems (T+21 days after validation)

# Windows Update for Business via Intune: deferral policy
# Quality updates: 0 days for Ring 0, 7 for Ring 1, 14 for Ring 2

Tooling for Linux endpoints:

# Ansible playbook for staged patching
# hosts file separates test, pilot, and production groups
ansible-playbook patch.yml -l test_servers --check  # Dry run first
ansible-playbook patch.yml -l test_servers
# Wait 48 hours, validate, then:
ansible-playbook patch.yml -l pilot_servers
# Wait 48 hours, validate, then:
ansible-playbook patch.yml -l production_servers

A patch management program without metrics is not a program: it is intentions. Track four metrics, report them monthly.

Metric 1: Mean Time to Patch (MTTP) by severity The average number of days from vulnerability disclosure to patch deployment, segmented by severity tier. Compare against your SLA targets. If MTTP for Critical patches is 21 days and your SLA is 14 days, you are out of compliance.

Metric 2: Patch compliance rate by system tier The percentage of systems patched within SLA for each vulnerability severity. Target: 95%+ for Critical, 90%+ for High, 85%+ for Medium.

-- Example query for WSUS/MECM database
SELECT 
    CASE 
        WHEN CVSSScore >= 9.0 THEN 'Critical'
        WHEN CVSSScore >= 7.0 THEN 'High'
        WHEN CVSSScore >= 4.0 THEN 'Medium'
        ELSE 'Low'
    END AS Severity,
    COUNT(*) AS TotalSystems,
    SUM(CASE WHEN DaysToApply <= SLADays THEN 1 ELSE 0 END) AS WithinSLA,
    ROUND(100.0 * SUM(CASE WHEN DaysToApply <= SLADays THEN 1 ELSE 0 END) / COUNT(*), 1) AS ComplianceRate
FROM PatchDeployments
WHERE PatchDate >= DATEADD(month, -1, GETDATE())
GROUP BY Severity

Metric 3: Unmanaged system count Systems in the network scan that are not enrolled in patch management. Target: zero. Any non-zero number requires an explanation: what is the system, who owns it, and what is the plan to enroll or decommission it.

Metric 4: Open exceptions count and age The number of active exceptions (systems with patches outstanding beyond SLA), their age, and whether compensating controls are documented. Exceptions older than 90 days without a remediation plan represent accumulated technical debt that needs escalation.