Building a Patch Management Policy

Unpatched software is one of the most exploited attack vectors. CISA's Known Exploited Vulnerabilities (KEV) catalog tracks vulnerabilities actively used by attackers — and many of them have patches available for months or years before organizations apply them. The cost of not patching is severe: - Ransomware groups specifically scan for unpatched systems (MOVEit, Log4j, Exchange vulnerabilities) - Cyber insurance carriers ask about patch management practices during underwriting - Compliance frameworks universally require timely patching (FTC Safeguards, NIST CSF, CIS Controls, HIPAA) - The average time from vulnerability disclosure to active exploitation has dropped to under 15 days A patch management policy formalizes your approach: what gets patched, how quickly, by whom, and how you verify it was done. Without a policy, patching happens inconsistently — and inconsistency creates the gaps attackers exploit.

Define Service Level Agreements (SLAs) based on vulnerability severity: Critical (CVSS 9.0-10.0) — Patch within 14 calendar days. These are actively exploited or easily exploitable vulnerabilities with severe impact. If a CISA KEV entry exists, prioritize even faster. High (CVSS 7.0-8.9) — Patch within 30 calendar days. Significant risk but may require more testing or have lower exploitability. Medium (CVSS 4.0-6.9) — Patch within 60 calendar days. Lower risk, but don't ignore these — they can be chained with other vulnerabilities. Low (CVSS 0.1-3.9) — Patch within 90 calendar days or during the next maintenance window. Prioritization factors beyond CVSS: - Is the vulnerability in CISA's KEV catalog? (Prioritize immediately) - Is the affected system internet-facing? (Higher priority) - Does the system handle sensitive data? (Higher priority) - Is there a known exploit in the wild? (Higher priority) Document exceptions: If a patch cannot be applied within the SLA (compatibility issues, system criticality), document the exception, the compensating control, and the planned remediation date.

Automate patching wherever possible to ensure consistency and reduce the burden on IT staff: Operating system patches — Use Windows Update for Business, WSUS, or Intune for Windows. Use built-in update mechanisms for macOS and Linux. Enable automatic updates for workstations; use controlled rollout for servers. Third-party applications — Tools like Ninite, PDQ Deploy, or your RMM platform can automate patching for common applications (browsers, PDF readers, Java, etc.). Firmware updates — Network equipment, firewalls, and IoT devices need firmware patches too. These are often forgotten but critical — especially for edge devices. Compliance framework requirements: - FTC Safeguards Rule: Requires maintaining security of systems, including patching - NIST CSF: ID.RA (Risk Assessment) and PR.IP (Information Protection) include patching - CIS Controls: Control 7 (Continuous Vulnerability Management) requires patching - HIPAA: Requires addressing known security vulnerabilities - Cyber Insurance: Carriers ask about patch management practices and may require specific SLAs Verification is critical: After patching, verify the patch was applied. Run vulnerability scans, check system versions, and maintain an audit trail. Cyber Defense Agent's external scans can help verify that internet-facing systems are running current software.