3.14.1 — Patch Your Systems

The One-Liner

An unpatched critical vulnerability on a CUI system is a ticking clock — and the assessor will compare your vuln scans against your patching records.

What It Says

Identify, report, and correct system flaws in a timely manner.

What It Actually Means

You need a complete patch management lifecycle — not just “we patch when we can.” Three phases, each with defined timeframes:

1. Identify. You have a process and schedule for discovering flaws — vulnerability scans, vendor advisories, CISA KEV catalog monitoring. The assessor will ask: “How often do you scan?” and “How soon after a flaw is published do you know about it?” Your policy defines the frequency — weekly scans is standard, daily for internet-facing systems.

2. Report. Identified flaws are assessed for severity and reported to the people responsible for remediation. Not buried in a scan report nobody reads — actively triaged, prioritized, and assigned. Critical flaws escalated immediately.

3. Correct. Patches are applied within defined timeframes based on severity. Industry standards for DIB:

   • Critical/CISA KEV: 48–72 hours
   • High: 14 days
   • Medium: 30 days
   • Low: 90 days or next maintenance window

The assessor will compare your vulnerability scan results against your patching records. If a scan from two months ago shows a critical vulnerability and this month’s scan shows the same vulnerability still present, that’s a finding — regardless of how good your policy looks.

This covers everything: operating systems, applications, firmware, network devices, and cloud services. Patching just Windows and ignoring third-party apps, firmware, or cloud configurations is incomplete.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Is the timeframe for identifying system flaws specified?	Policy defines scan frequency and flaw discovery SLAs
2	Are system flaws identified within that timeframe?	Scan results showing regular execution per the defined schedule
3	Is the timeframe for reporting system flaws specified?	Policy defines how quickly identified flaws are triaged, prioritized, and assigned
4	Are system flaws reported within that timeframe?	Triage records showing flaws assessed and assigned per the SLA
5	Is the timeframe for correcting system flaws specified?	Policy defines remediation SLAs by severity: critical, high, medium, low
6	Are system flaws corrected within that timeframe?	Patching records showing remediation within SLAs — validated by follow-up scans

---

What to Have Ready on Assessment Day

Documents they’ll review: System and information integrity policy; patch management procedures; vulnerability scan results (recent and historical); patching records; list of system flaws and remediation status; CISA KEV tracking; system security plan; change control records for patch deployment

People they’ll talk to: System or network administrators; information security personnel; personnel responsible for patch management; personnel configuring and maintaining systems

Live demos they’ll ask for: “Show me your most recent vulnerability scan results.” “Show me your patching schedule and records.” “Pick a critical vulnerability from last quarter — when was it identified and when was it patched?” “Show me CISA KEV items and your response.”

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “What is your defined timeframe for identifying system flaws? Show me the policy.”
• “Show me your most recent vulnerability scan. When was it run?”
• “Pick a critical flaw from the last scan — how quickly was it patched?”
• “Do you track CISA Known Exploited Vulnerabilities? Show me.”
• “What’s your patching SLA for critical vs. high vs. medium?”
• “Are third-party applications patched, or just the OS?”
• “Show me firmware patching records for your network devices.”

Real-World Example

A defense contractor runs weekly vulnerability scans via Defender Vulnerability Management across all CUI systems. Scan results are triaged within 24 hours by the IT Security Lead — each flaw is assigned a severity rating and a remediation owner. Critical vulnerabilities and CISA KEV items get emergency change tickets with a 48-hour remediation SLA. High flaws are patched within the next weekly patch cycle (Tuesdays). Medium flaws go into the monthly patch cycle. Low flaws are scheduled for the quarterly maintenance window. Third-party applications (Adobe, Chrome, Zoom) are patched via Intune alongside OS updates. Firmware updates for the Palo Alto firewall and Cisco switches are scheduled quarterly. A follow-up scan runs 72 hours after each patch cycle to validate remediation. The assessor reviews three months of scan results and patching records — critical flaws are closed within 48 hours, and no critical vulnerability persists across two consecutive scans.

---

Where Companies Trip Up

No defined schedule. Patching happens “when we get to it.” The assessor asks for your patching SLA and there isn’t one. Define severity-based timeframes in your policy and stick to them.

Critical patches delayed. A critical vulnerability sits unpatched for weeks because change management moves slowly. Emergency changes exist for a reason — critical flaws bypass normal scheduling. Define an expedited path for critical patches.

Incomplete coverage. Windows gets patched but third-party applications (Java, Adobe, Chrome, Zoom) don’t. Firmware on firewalls and switches hasn’t been updated in years. Cloud configurations aren’t scanned. Your patching program must cover all system components.

No validation. Patches are deployed but nobody verifies they were applied successfully. A patch that failed to install on three workstations doesn’t count as remediated. Run follow-up scans to validate.

Scan without action. Vulnerability scans run weekly but the results sit unreviewed. The scan is the identification step — without triage, assignment, and remediation, you’ve identified flaws but not reported or corrected them.

---

How to Talk About This

To a CEO or Board

We identify vulnerabilities through weekly scans, prioritize by severity, and patch within defined timeframes — critical flaws within 48 hours. Our patching covers the OS, applications, firmware, and cloud services. We validate every patch cycle with follow-up scans.

To an Engineering Team

Weekly Defender Vulnerability Management scans. Triage within 24 hours. SLAs: critical/KEV 48h, high 7 days, medium 30 days, low 90 days. OS + third-party via Intune. Firmware quarterly. Cloud configs via Defender for Cloud. Follow-up scan 72h post-patch. Compliance dashboard tracks SLA adherence. CISA KEV integrated into triage workflow.

---

Connected Requirements

Requirement	Why it matters here
3.14.3 — Act on Advisories	Security advisories feed the flaw identification process
3.11.2 — Scan for Vulnerabilities	Vulnerability scanning is the identification mechanism for this requirement
3.4.3 — Control Every Change	Patches are changes that go through change management
3.4.2 — Harden Everything	Patching maintains the security baseline established in hardening

---

Implementation (coming soon)

Step-by-step setup for Microsoft 365 / Entra ID, AWS, Azure, and GCP — console steps, CLI commands, and evidence screenshots.

---

CMMC Practice ID: SI.L2-3.14.1 | SPRS Weight: 5 points | POA&M Eligible: No