Vulnerability Patching Policy

Patches arrive constantly. The policy.

By severity

Vulnerability patching is one of those operational disciplines that everyone agrees is important and most teams perform inconsistently. The discipline that holds up over time is a documented patching policy with severity-based SLAs: each vulnerability gets a deadline based on its severity, and the deadline is enforced.

The standard severity-based SLAs:

• Critical: 7 days.: CVSS 9.0+ vulnerabilities, vulnerabilities with active exploitation, vulnerabilities that allow remote code execution or unauthorized data access. The patch lands in production within a week of CVE disclosure. Anything slower exposes the system to known-active threats for too long.
• High: 30 days.: CVSS 7.0 to 8.9, serious vulnerabilities with no active exploitation yet but high potential impact. The patch lands within a month. The window allows for testing without leaving the system exposed for an extended period.
• Medium: 90 days.: CVSS 4.0 to 6.9, vulnerabilities with limited impact or limited exploitability. The 90-day window provides time for batched patching without urgency. Most vulnerabilities fall in this category.
• Low: 180 days or accept.: CVSS below 4.0, vulnerabilities with negligible practical impact. The patch lands when convenient or the risk is formally accepted. Some low-severity vulnerabilities never get patched because the cost of patching exceeds the risk; the acceptance is documented.
• SLAs documented.: The policy is in writing, agreed by security and engineering leadership, and tracked. Vulnerabilities approaching their SLA generate escalations; vulnerabilities past SLA are explicit policy violations that warrant attention.

The severity-based SLA is the policy backbone. Without it, patching happens on whatever cadence the team feels like; with it, patching happens on a deadline that reflects actual risk.

Test

Patches need to be tested before they reach production. Untested patches can introduce regressions that are worse than the vulnerability they fix. The discipline includes a testing path that produces confidence without delaying the SLA.

• Patches in staging first.: The patched dependency or system runs in staging before production. The team verifies the patch does not break the application; integration tests run against the patched system; smoke tests confirm the deployable artifact.
• Production deploy by SLA.: After staging verification, the patch deploys to production within the severity's SLA window. The deploy uses the team's standard production deploy path: canary, soak, automated rollback. The patch is treated as a normal deploy with appropriate gates.
• Process gated by severity.: Critical patches may have compressed test windows (a few hours of staging soak rather than a few days) because the SLA is shorter. Medium patches can have longer staging soaks. The test depth matches the SLA pressure.
• Automated patching for known-safe cases.: Some patches are mechanical and safe (minor version bumps for dependencies with strong backwards-compatibility guarantees). These can flow through automated update pipelines that test and deploy without human intervention. The automation increases throughput without sacrificing safety.
• Risk acceptance for unpatchable.: Some vulnerabilities cannot be patched (no upstream fix, fix breaks essential functionality, end-of-life software). The risk is formally accepted, documented, and reviewed annually. Unpatchable vulnerabilities are not ignored; they are managed.

Testing is the bridge between identifying a vulnerability and shipping the fix. The bridge is necessary; the discipline is making it efficient.

Emergency

Some vulnerabilities warrant emergency patching that bypasses the standard SLA. Active exploitation in the wild, vulnerabilities affecting widely-used components, vulnerabilities with public exploit code. The emergency path is documented and exercised before it is needed.

• Active exploitation triggers fast-track.: A CVE with public exploit code, evidence of in-the-wild exploitation, or inclusion in known attack toolkits gets the fast-track. Standard SLAs do not apply; the patch ships within 24 to 48 hours.
• Compressed staging window.: The fast-track may compress staging soak from days to hours. The team trades thoroughness for speed; the calculation is that exploitation risk exceeds regression risk for these specific cases.
• Documented emergency path.: The fast-track is documented in the patching policy. The team knows when it applies, who can authorize it, what the abbreviated process looks like. The path exists before it is needed.
• Bypass standard gates when justified.: Some standard deploy gates (deploy windows, approval cycles, change advisory board) get bypassed for emergency patches. The bypass is documented; the rationale is captured. Bypass is the exception, not the routine.
• Post-incident review.: After the emergency patch ships, review the incident: was the emergency justified, did the fast-track work, what could be improved. The review feeds back into the policy and the playbook.

Vulnerability patching policy is one of those operational disciplines where documentation and consistency matter more than any specific number. Nova AI Ops integrates with vulnerability scanners and patch management systems, surfaces vulnerabilities by SLA status, and tracks the team's patching velocity over time.