Ask a vendor risk team for their remediation SLA and most will produce a table: critical in 15 days, high in 30, medium in 90. Ask what happened the last time a vendor blew through the 15-day clock and the answer is usually a follow-up email. An SLA without a consequence is a suggestion with a deadline, and vendors learn very quickly which of their customers' deadlines are suggestions.
This article is about designing remediation SLAs that get met, which is a different problem from designing SLAs that look rigorous in a policy document. The design has four parts: clocks that vendors can actually run, an escalation ladder that changes something at each rung, contract language that makes the ladder real, and an explicit exit for the cases where accepting the risk beats forcing the fix. We have covered why most vendor remediation efforts fail; treat this piece as the constructive half of that argument.
Part 1: Severity-based clocks that survive contact with vendors
Two design errors dominate. The first is calibrating clocks to your anxiety instead of the vendor's change process. A 15-day clock for a finding that requires the vendor to re-architect authentication is not rigor, it is a guaranteed breach, and a guaranteed breach on day one teaches the vendor your clocks are decorative. The second error is a single clock per severity regardless of vendor tier, which spends your escalation energy equally on a critical vendor and a marginal one.
A workable baseline crosses severity with tier. The numbers below are illustrative starting points to negotiate from, not industry law:
| Finding severity | Tier 1 vendor | Tier 2 vendor | Tier 3 vendor |
|---|---|---|---|
| Critical (actively exploitable, your data exposed) | Containment plan in 72 hours, fix or compensating control in 14 days | Plan in 5 days, fix in 30 days | Plan in 10 days, or accept and re-tier |
| High | 30 days | 60 days | 90 days |
| Medium | 90 days | 120 days | Next assessment cycle |
| Low | Next assessment cycle | Next assessment cycle | Log only |
Three refinements make this table work in practice. First, split the clock for criticals: demand a containment plan fast and allow the durable fix a realistic window, because "plan in 72 hours" is achievable and creates immediate engagement, while "fix in 72 hours" creates silence. Second, start every clock from the date the vendor acknowledges the finding, and separately SLA the acknowledgment itself (5 business days is reasonable). Unacknowledged findings are their own failure mode and deserve their own metric. Third, let a vendor propose a compensating control that stops the clock pending your review. You want vendors negotiating with you inside the process, not avoiding it.
Tier assignment quality determines whether this matrix helps or hurts, so if your tiers are stale, fix that first using a structured tiering framework.
Part 2: An escalation ladder where every rung changes something
Escalation fails when every rung is a louder version of the same email. Design the ladder so each step changes either the audience or the stakes, never just the tone:
- Rung 1, clock at 75 percent: automated reminder to the vendor's named remediation contact. Audience: the person doing the work.
- Rung 2, clock expired: your vendor owner contacts the vendor's account manager, not their security team. Audience change: the person paid on your renewal now knows. This rung alone resolves a large share of stalls, because commercial teams move engineering teams in ways security teams cannot.
- Rung 3, 30 days past expiry (critical or high, Tier 1 or 2): formal written notice invoking the contract clause (Part 3), copied to your procurement lead and the vendor's executive sponsor. Stakes change: this letter is now part of the renewal file.
- Rung 4, 60 days past expiry: business decision meeting with the internal service owner. Options on the table: restrict the vendor's data access or scope, freeze expansion of the relationship, begin exit planning, or formally accept the risk (Part 4). The vendor is told which option was chosen. Stakes change again: the relationship itself is now the variable.
Notice what is absent: threats you will not execute. Never put "termination" on a rung unless the business has pre-agreed it is a live option for that vendor tier. An escalation ladder collapses entirely the first time a vendor calls a bluff and wins.
Part 3: Contract hooks that make the ladder real
SLAs negotiated after a finding exists are negotiated from weakness. The time to install remediation obligations is at signature or renewal, when you have leverage and nobody is defensive about a specific finding. Four clauses do most of the work:
- Remediation commitment clause: vendor agrees to remediate verified security findings within timeframes by severity, with your severity definitions attached as a schedule. Without written severity definitions, every finding becomes a taxonomy debate.
- Right to verify: you may request evidence of remediation, not just attestation. A closure email is not closure; a configuration screenshot, retest result, or updated audit report is.
- Escalation contact clause: vendor maintains a named security contact and a named executive escalation contact, refreshed annually. Rungs 2 and 3 die without this.
- Renewal linkage: unresolved critical or high findings at renewal entitle you to renew for a shortened term, adjust scope, or exit without penalty. This is the clause that converts the remediation file into commercial leverage, and it costs vendors nothing if they simply perform.
You will not get all four from every vendor, and large providers will offer their standard terms and little else. Get what you can, record what you could not get as a known limitation on the vendor record, and weight it in tiering. Mid-article honesty break: tracking acknowledgment dates, clock states, evidence, and escalation history across dozens of vendors is exactly the bookkeeping that collapses in email, and it is why platforms such as ThirdSentry run remediation items as workflow objects with owners, clocks, and an audit trail rather than as spreadsheet rows.
Part 4: When accepting the risk beats forcing the fix
A remediation program without a risk-acceptance path fills up with zombie findings: items nobody will fix and nobody will close. Acceptance is not failure. Unmanaged acceptance is. Force the decision through four questions:
- Is the exposure real in our specific usage of this vendor, or only in a configuration we do not use?
- Is a compensating control on our side cheaper and faster than the vendor's fix?
- Does the vendor's roadmap genuinely address it, with a committed date we can hold?
- Would we still choose this vendor today knowing this finding exists?
If acceptance wins, it gets a named accepter senior enough to own the consequence, a written rationale, an expiry date of no more than 12 months, and automatic re-review at the next assessment. An acceptance without an expiry date is not a decision, it is a burial.
The quiet metric behind all of it
Track one number monthly: the percentage of findings that closed inside their clock, by severity. Illustratively, programs that add real escalation and contract hooks tend to see meaningful movement within two or three quarters, not because vendors got better, but because your deadlines stopped being suggestions. That is the entire design goal.
ThirdSentry tracks remediation items on the same vendor record as assessments and continuous monitoring, with severity clocks, owner assignment, evidence attachment, and a full audit trail built in, so the escalation ladder runs on data instead of memory. If your current SLA lives in a policy PDF and a hopeful inbox, that is the gap worth closing first.
