How to Build a Patch SLA Policy That Developers Will Actually Follow

CVSS scores measure the theoretical severity of a vulnerability in isolation. They do not account for whether your environment is actually exposed to the attack vector, whether exploit code is actively circulating, or whether your existing controls reduce the practical risk. A CVSS 9.8 remote code execution vulnerability in a library running only on an internal server with no external network access is significantly less urgent than a CVSS 6.5 authentication bypass in your public-facing login system.

When SLAs are built on CVSS alone, two failure modes emerge. First, engineering teams receive critical tickets for vulnerabilities that are not actually critical in their environment. After responding urgently to several of these and finding the fix did not meaningfully change their security posture, engineers begin treating critical tickets as routine noise. Second, genuinely dangerous vulnerabilities with lower CVSS scores due to specific scoring methodology decisions get deprioritized below less dangerous findings with higher scores.

The Exploit Prediction Scoring System (EPSS), published by FIRST, provides a probability score for how likely a vulnerability is to be exploited in the next 30 days based on threat intelligence data. CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities actively exploited in the wild. Using a combination of CVSS, EPSS score, and KEV status to determine SLA tier produces a more accurate priority signal than CVSS alone. A CVSS 7.5 vulnerability with an EPSS score above 0.5 and a KEV listing should be treated as critical regardless of its CVSS tier.

Before writing a patch SLA policy, interview three engineering leads and ask two questions: how far in advance do you plan your sprint backlog, and what is the fastest a security ticket has moved from "created" to "in sprint" in your current process?

The answers typically reveal two constraints standard policies ignore. First, sprint backlog planning happens 2 to 4 days before each sprint begins. A ticket created on day 3 of a two-week sprint has effectively missed the planning window. It will enter the backlog for the next sprint at the earliest, meaning the remediation clock has already consumed 10 to 12 days before engineering has even committed to the work. A 15-day SLA is operationally a 3 to 5 day SLA for the engineering team -- an impossible standard.

Second, most engineering teams have a release train or change window process. Production changes require testing, peer review, and approval steps that add 3 to 7 days to any fix. A patch that takes 2 hours to write and test may require 5 additional days to deploy safely. Patch SLA policies that treat development time and deployment time as equivalent set up compliance failures from day one.

The language change that accommodates these constraints: "Critical vulnerabilities must enter the next sprint planning session following discovery and be resolved within one sprint from that entry point." This gives the engineering team the actual time available while creating a clear, auditable commitment. It also surfaces the bottleneck correctly: if a critical finding is not entering sprint planning within 3 days of discovery, that is an alert routing or ticket creation failure, not an engineering compliance failure.

A three-tier SLA built on exploitability context rather than CVSS score alone:

Tier 1 -- Emergency (fix before next sprint, maximum 7 days): Vulnerabilities on the CISA KEV list, CVSS 9.0+ with EPSS score above 0.7, or any vulnerability with active exploitation confirmed by your threat intelligence sources. These require out-of-cycle response and bypass normal sprint planning.

Tier 2 -- Sprint-priority (enter next sprint planning, resolve within 2 sprints, maximum 28 days): CVSS 7.0 to 8.9 with EPSS above 0.3, or any CVSS 9.0+ without active exploitation evidence. These enter the sprint backlog at next planning as non-deferrable items.

Tier 3 -- Backlog (resolve within 90 days, or formally risk-accept with a review date): CVSS below 7.0, or higher-CVSS findings with mitigating controls already in place. These enter the normal engineering backlog and compete with other work.

Each tier must specify: who assigns the tier (security team, within 24 hours of scan completion), who owns the fix (a named engineer or engineering lead), what the escalation path is when the window is missed, and what documentation is required for exceptions. The policy should also state that Jira tickets are auto-created by the scanner integration with tier, owner assignment, and deadline pre-populated before the engineering team sees the finding. Removing the manual handoff step eliminates the most common single point of failure in SLA compliance.

Bringing a new patch SLA policy to an engineering VP or CTO without preparation produces one of two outcomes: blanket approval with no actual enforcement plan, or a negotiation that results in timelines so long the policy is meaningless.

The negotiation conversation works better when you start with data rather than policy language. Before the meeting, pull the last 90 days of scanner data and answer: how many criticals were remediated within the current informal standard? How many are still open beyond 30 days? What is the oldest open critical finding and what is blocking it?

This data reframes the conversation from "I need you to commit to 15-day patch windows" to "We currently have 12 critical findings open beyond 30 days. Three of them are on the CISA KEV list. I want to show you what process change closes those 12 and prevents this from recurring." Engineering leadership responds to documented operational problems differently than to compliance requirements.

The three specific commitments that produce the most compliance improvement: a standing 10% sprint capacity reservation for security findings, a named security liaison on each engineering team who attends security triage meetings, and agreement that tier-1 findings can interrupt sprint commitments with manager approval rather than waiting for the next planning cycle. These commitments change the workflow more than any SLA language change.

A patch SLA policy should be short enough that the people it applies to actually read it. Target length: two pages. Anything longer gets read once during onboarding and ignored permanently.

Include:

• Scope: which systems and finding types the policy covers
• SLA tiers with clear definitions of what qualifies for each tier
• Ownership assignment process: who assigns tiers, who receives tickets, and how fast
• Exception process: what justification is required, who approves, and the maximum exception duration
• Escalation path: what happens when an SLA is missed and who is notified automatically
• Compliance reporting: what metric is reported, to whom, and how often

Leave out:

• Definitions of CVSS, EPSS, or CVE scoring methodology (link to documentation instead)
• Justification for why patching is important (engineers know; this language reads as condescending)
• Process steps for how the security team performs scanning (irrelevant to the engineering audience)
• Legal or compliance language unless your organization requires it for regulatory reporting

Attach a one-page quick reference card with the tier definitions and the Jira ticket fields that indicate tier assignment. This card is what engineers actually consult when they receive a security ticket -- not the full policy document.

SLA compliance tracking fails when it is used primarily to assign blame. It succeeds when it is used to identify process failures before they become chronic.

Track four numbers weekly, not monthly: open criticals past SLA by team, open highs past SLA by team, exceptions created this period, and exceptions expiring within 14 days. Share this report with engineering managers before it goes to the CISO or leadership team. Giving managers the opportunity to resolve issues before they appear in a leadership report changes the dynamic from "security catches engineering failing" to "security gives engineering teams the information they need to succeed."

Monthly, calculate the remediation rate trend: what percentage of tier-1 and tier-2 findings were resolved within SLA this month compared to last month. A trend improving by 5 to 10 percentage points per month indicates the process is working. A flat or declining trend indicates a structural problem that needs investigation.

Quarterly, review tier assignment accuracy: were any findings classified as tier 3 that were later identified as more urgent? Were tier-1 assignments contested by engineering teams as overstated? Tier calibration reviews prevent the policy from drifting toward either over-alarming (everything classified as critical) or desensitization (criticals treated as mediums).