# Vulnerability & Patch Management Policy

**Document owner:** [Owner/Role]  
**Approved by:** [Steering Committee / CISO]  
**Effective date:** [YYYY-MM-DD]  
**Review cadence:** [Annually]

---

## 1. Purpose & Scope
This policy establishes mandatory requirements for identifying, prioritizing, and remediating vulnerabilities across [Organization]'s IT, cloud, and OT/IoT assets. It applies to all systems, including those managed by third parties per the [Vendor & Third-Party Risk Management Policy](vendor_risk_management_policy.md).

---

## 2. Policy Statements

### 2.1 Vulnerability Scanning
- Internet-facing assets **must** be scanned at least **weekly**; internal assets **must** be scanned at least **monthly**.  
- Authenticated scanning **should** be used where supported for accuracy.  
- Kill-chain systems (per [Authentication Policy §2.1](authentication_policy.md)) **must** be scanned continuously where tooling supports it.

### 2.2 Patch SLA by Severity
| Severity | SLA |
|---|---|
| **CISA KEV-listed** (actively exploited) | ≤ 15 days, kill-chain systems ≤ 72 hours |
| **Critical (CVSS ≥9.0)** | ≤ 15 days |
| **High (CVSS 7.0–8.9)** | ≤ 30 days |
| **Medium (CVSS 4.0–6.9)** | ≤ 90 days |
| **Low (CVSS <4.0)** | Next scheduled maintenance window |

### 2.3 Emergency Patching
- A confirmed zero-day or actively exploited vulnerability affecting a kill-chain system **must** trigger emergency change process — patch or compensating control (e.g., network isolation) within the SLA above regardless of standard change windows.

### 2.4 Exceptions
- Missed SLAs **must** be documented with compensating controls and CISO approval, with a review date not exceeding 90 days.  
- Unpatchable legacy systems **must** be isolated (network segmentation) as a compensating control, not left exposed by default.

### 2.5 Kill-Chain Priority (Barbell Principle)
- Vulnerability remediation effort **must** be concentrated disproportionately on kill-chain systems and internet-facing assets; low-criticality internal systems on the standard SLA table do not warrant equivalent urgency.

### 2.6 Enforcement
- Repeated SLA misses without an approved exception **must** be escalated to the CISO and tracked as a recurring finding per [Authentication Policy §2.12](authentication_policy.md) structural learning process.

---

## 3. Antifragility Alignment
This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**.

| Pillar | Applied In | How |
|---|---|---|
| **1. Structural Decoupling** | §2.4 | Network isolation as a compensating control means one unpatchable legacy system doesn't become a standing risk to everything else |
| **2. Optionality Preservation** | §2.4 | Isolation preserves the option to keep a legacy system running without accepting its full risk |
| **3. Stress-to-Signal Conversion** | §2.6 | Repeated SLA misses feed the structural post-mortem process rather than becoming permanent exceptions |
| **4. Sovereign Intelligence** | §2.4 | Exceptions and compensating controls documented and owned, with a forced review date |
| **5. Asymmetric Payoff Design (Barbell)** | §2.2, §2.5 | Tight SLA (≤72h) concentrated on kill-chain + KEV-listed vulnerabilities; low severity gets the lean next-cycle treatment |

---

## 4. References
- **[NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning](https://csrc.nist.gov/pubs/sp/800/40/r4/final)**  
- **[CISA Known Exploited Vulnerabilities (KEV) Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)**  
- **[CIS Controls v8.1 (Control 7)](https://www.cisecurity.org/controls/v8-1)**