Vulnerability Management Framework

The remediation contract between security and IT

September 22, 2026·9 min read·Chris Boker
Two facing rectangular panels labeled by shape rather than text, a left green Security panel with a stack of five ticket rectangles feeding a routing gate and a right green IT panel with a stack of five change window rectangles feeding a maintenance gate. Between them a large surface contract page with two rows of five clause lines, a rust seal on the security side and a gold seal on the IT side, and two curved arrows crossing the page. The upper arrow runs green from Security to IT and carries a check mark for a fulfilled clause. The lower arrow runs rust from IT back to Security and carries an X mark for a breach clause, so the consequence runs in both directions.

Between June 10 and July 29 of this year, CISA added 39 CVEs to the Known Exploited Vulnerabilities catalog. Thirty-four landed under BOD 26-04's three-day-or-less tier: a federal directive telling an infrastructure team to complete an emergency change every thirty-six hours for seven straight weeks. No security lead can commit an IT team to that pace alone. Either the two sides negotiate what it costs and what gets displaced, or the deadline is fiction that lands on the same handful of engineers.

Somewhere in that gap, an unwritten contract gets signed. IT accepts the ticket, security keeps sending, and because neither side ever agreed to the terms, both walk away convinced the other is unserious the moment those terms break. Every neighbouring discipline solved the problem decades ago; vulnerability management pretended not to notice.

What we should be calling this

ITIL already has the name for a bilateral, non-customer-facing agreement between two internal teams. It is the Operational Level Agreement, the sibling of the SLA, the thing that says what the network team owes the app team so the app team can meet its customer promises. Vulnerability programs have SLAs coming out of their ears and almost never write the OLA. The one-way SLA is what security drafts and hands across the aisle; the bilateral OLA is what nobody bothered to write down.

Google's SRE book sharpened the same shape with the error budget. Product development gets a fixed allowance of unreliability per quarter, and when the budget is gone, feature velocity yields to reliability work (SRE, Embracing Risk). Both sides agreed to the tradeoff, both sides pay when it breaks. The vulnerability-specific version has never been written down; every published artifact in this space is a one-way SLA that security imposes on IT.

What security owes IT

Half of the contract is intake quality. Security promises to route only work that clears a specific bar, with enough context that an engineer can act without a second round of interpretation. The bar is a small set of clauses a team can paste into a wiki this week.

  • Every ticket names a real asset in the CMDB, with a real owner resolved before the ticket lands in a fix queue.
  • Deduplication has already run against the previous batch, so the same finding does not arrive twice in seven days under two different scanner IDs.
  • Exposure band replaces raw CVSS on the ticket. If a finding is Sev1 in a scanner and Tier 4 by exposure, the exposure decides.
  • A validated fix path is attached, whether a patch version, a config change, or a documented workaround, that reproduces on the target platform.
  • Change windows are suggested against the affected asset's real maintenance calendar, not an arbitrary policy clock.

Security also owes IT a false-positive clause, because intake is a security-side function and a noisy ticket is security's failure. The clause names how a false positive gets reported (a checkbox on the ticket, not a Slack message that vanishes), what security does with it (investigate the intake rule, not the individual finding), and what happens when the same rule crosses a defined false-positive rate (quarantined pending re-tuning, its findings held out of the fix queue until it clears the gate again). Nothing corrodes trust faster than an engineer spending a Saturday on tickets that turn out to have been noise.

What IT owes security

The other half of the contract is committed windows and honest blockers.

  • Window commitments per exposure tier, negotiated locally against real MTTR data rather than copied from a framework. Verizon's 2026 DBIR, drawing on more than 13,000 organizations, reported only 26 percent of KEV entries fully remediated and a median time to full remediation of 43 days, alongside roughly 50 percent more critical findings per organization than a year prior. Edgescan's 2026 stats put high and critical mean MTTR at 54.81 days for app and API and 39 days for network and device, with 45.4 percent of findings unresolved at twelve months and a wide sector spread (software 63 days, construction 104). Those are the numbers a real OLA gets negotiated against.
  • A blocker path with named escalation, so a stuck ticket routes to a business or risk owner within a defined window rather than dying inside a comment thread.
  • Change evidence at closure. Not a comment saying it was patched, but a rescan artifact, a config diff, or a BAS result showing the target state achieved. If closures without evidence were rare, the DBIR remediation rate would move faster than critical finding volume; it does not, which says the gap is already common enough to distort the metric.
  • An honest declaration of capacity. If the queue is arriving faster than the team can service it, that is a fact the OLA needs to see, not a Slack complaint that dies on Friday.

Both sides get a symmetric right to say no. Security can refuse work IT tries to push back without an exception path; IT can refuse work security routes without an owner or a clear fix path. The refusal is not a personality clash; it is the contract functioning as intended.

Breach in both directions

The clause that makes an OLA real is the consequence, and it has to run both ways.

If IT misses a committed window on a tier-one exposure, the finding escalates automatically to the named risk owner (usually a VP or the CISO's counterpart on the IT side), the miss is logged, and the ticket does not close without a documented reason. Repeated misses trigger a joint review of that team's capacity, not a shame comment on the ticket. The point is to surface a real constraint, not to blame the engineer holding the pager.

If security misses on intake, the reverse happens. A false-positive rate above the agreed threshold pulls the offending intake rule until security re-tunes it. A ticket routed without a real owner routes back with a note, not a re-assignment to the last engineer who touched a similar system. Repeated intake failures trigger a joint review of the enrichment pipeline; the engineer on the receiving end does not eat the cost of the design flaw upstream.

Bilateral consequence is what separates an OLA from the fantasy SLA every vulnerability program already has. When only one side breaches, only one side ever pays, and that side eventually leaves. Per Help Net Security's 2026 workforce data, 76 percent of practitioners reported burnout in the past year, US practitioners logged an average of 10.8 extra hours a week with nearly half at eleven or more, and 70 percent of SOC analysts with under five years of experience are gone within three years. An unwritten contract is how that bill gets paid silently.

Renegotiation when capacity is the ceiling

Windows are negotiated against real MTTR data, and the contract expires. Every quarter the two sides sit down with the previous quarter's SLA performance data (percentage met per tier, breach reasons, false-positive rate, backlog trend) and adjust the windows against reality. If the environment shipped 34 three-day-tier findings in seven weeks and IT met 62 percent of them, the contract has a number to argue about instead of a mood.

Renegotiation is also where the tier definitions themselves shift. When a platform team lands a segmentation change that drops a whole class of finding into a lower exposure band, the contract acknowledges the new capacity and absorbs more work; when identity attack path exposure rises across the estate, it cedes some tier-three capacity to prioritize the harder class. Our earlier piece on SLA clock mechanics owns the timing arithmetic underneath a tier; this post owns who negotiated the tier and what happens when either side blows one. OWASP's Security Champions Guide is a useful primer at the developer end of the translation layer, and it solves a related but distinct problem.

What this does not fix

An OLA does not manufacture engineers. If arrival rate structurally exceeds service rate, no clause will drain the backlog; that is a hiring conversation, and no wording in a wiki substitutes for headcount. What the contract does is make the mismatch visible on a schedule, which is a precondition for fixing it, not a fix. It also does not replace the operating model underneath the tickets. Our earlier remediation operating model owns the four-owner model and the ticket contract as a data structure; this post owns the bilateral agreement around it. The operating model is what a ticket carries; the OLA is what the two sides promised each other about the flow of those tickets.

Where CVEasy fits

CVEasy AI is the local-first CTEM platform that runs enrichment, exposure banding, and validation on hardware you own, so the intake side of the contract can be audited by both parties instead of trusted by one. TRIS is the score the exposure band is drawn from, keeping tier definitions grounded in a stable rubric rather than the mood of the week.