Remediation service-level agreements live, in too many organisations, in a spreadsheet. Critical vulnerabilities should be fixed in 7 days. High in 30. Medium in 60. The spreadsheet captures the policy. Some poor analyst manually updates it from a scanner export every two weeks. By the time the report reaches the executive briefing, the data is stale, the remediation evidence is in another tool, and the auditor's questions cannot be answered without a fresh scramble.
This is the worst possible place to track SLAs, because the SLA is meant to be a control. A control that nobody can see in real time is not a control. It is a story you tell after the fact. By 2026 there is no good reason to run remediation SLAs out of band from the system that generates the fixes.
What An SLA Actually Is
An SLA is a promise about response time. A critical finding will be remediated within seven days of discovery. The promise has three parts: a definition of "critical" that everyone agrees on, a definition of "discovery" that is precise to the day, and a definition of "remediated" that is verifiable. Each of these definitions is contestable, which is why spreadsheet SLAs are usually wrong.
Critical means different things to different teams. CVSS-only definitions trip on the same problems as CVSS-only prioritisation: a 9.8 in unreachable code is not actually critical. A modern definition of critical layers reachability, EPSS, and asset criticality on top of CVSS, the same way prioritisation does. The SLA inherits that definition rather than inventing a separate one.
Discovery means the moment the finding entered the system. This sounds obvious until you realise that re-introducing a finding on a new project resets the clock in some tools and not in others. The right answer is to anchor discovery to the first time the specific finding-asset pair was seen, not to the most recent scan. A spreadsheet rarely captures this distinction. The pipeline does.
Remediated means the affected artefact no longer contains the vulnerability and the change has shipped. A merged PR is necessary but not always sufficient. A fix that is merged but not deployed is a fix that has not yet remediated the running asset. SLA tracking that ends at merge is incomplete. SLA tracking that ends at deployment is honest.
What Goes Wrong In Spreadsheets
Spreadsheets fail in a few predictable ways.
They drift out of date. Manual updates are weekly at best. Findings discovered between updates are not on the spreadsheet at all. Findings remediated between updates are still on the spreadsheet as open. The view of the world is always lagged by the update cadence.
They lose context. The spreadsheet has a finding ID and a status. The PR that fixed it lives in GitHub. The reachability analysis lives in the scanner. The EPSS score is somewhere else. Reconciling a single finding's status across all these sources is the analyst's job, and it gets done badly because nobody has the time.
They cannot audit themselves. A spreadsheet does not record who changed which cell when. An auditor who asks why a finding was marked closed cannot get a clean answer. The audit trail is in someone's email or Slack, if it exists at all.
They do not enforce. A spreadsheet records SLAs but cannot do anything about them. A finding sits at day 31 of a 30-day SLA and the spreadsheet just shows red. There is no automatic escalation, no auto-PR re-attempt, no notification to the responsible team. The SLA is descriptive, not active.
What In-Pipeline SLA Tracking Looks Like
The fix is to track SLAs in the same system that handles everything else: discovery, prioritisation, auto-PR, verification, review, merge, and deployment. Every finding has a clock that starts at first-seen and stops at deployed. The clock is visible on every surface: the finding's own page, the project dashboard, the reviewer's PR pane, the executive briefing, the auditor report.
The SLA policy is configured once, by tier. Tier one critical findings have a 7-day deadline. Tier two have 30. Tier three have 60. The configuration includes escalation steps: at 50 percent of the SLA, the responsible team is notified. At 75 percent, the security lead is added. At 100 percent, the finding becomes a tracked breach and appears on the executive dashboard.
The SLA is active. When a finding crosses 50 percent of its deadline without a PR open, the auto-PR pipeline re-prioritises it. When a PR is sitting unreviewed at 75 percent of the deadline, the reviewer pool is escalated. When a PR is merged but not deployed at 100 percent of the deadline, the deployment pipeline is queried and the team that owns the deployment cadence is notified. The SLA drives action, not just reporting.
Reporting That Anyone Can Trust
The reports that come out of an in-pipeline SLA system are different from the reports that come out of spreadsheets. They are real-time. They are reconciled with the underlying evidence. They are auditable.
The executive briefing shows current SLA compliance by tier, trend over time, breach causes, and projected compliance based on in-flight remediations. Each number on the briefing is clickable: a click on the breach count lists the findings that are breaching, with their current state in the pipeline.
The auditor report shows the policy, the findings, the timeline of each finding from discovery to deployment, the evidence at each stage, and the identity of every human who approved a change along the way. The report is generated on demand from the underlying data. There is no reconciliation step, no manual cleanup, no spreadsheet to find.
The team dashboard shows their own findings, their own SLA clocks, their own breach rate. Engineers see the same numbers that the executive sees, scoped to their work. The transparency is what builds trust in the policy. Engineers who can see the same data the executive sees stop suspecting that the SLAs are arbitrary.
Handling Breaches Honestly
SLA breaches happen. Pretending otherwise is the fastest way to make a programme dishonest. The right approach is to treat breaches as data, not as failures to be hidden.
Each breach is annotated with a cause. Reviewer queue overrun. Verification failure that took multiple iterations. Cascade complexity that exceeded the planning budget. Breaking-change migration that needed product input. Categorising breaches reveals patterns. A team that breaches mostly on cascade complexity needs more cascade automation, not more pressure on reviewers.
The breach data feeds policy review. If a tier consistently misses its SLA, the question is whether the SLA is unrealistic or whether the pipeline is undersupported. A 7-day SLA that is breached 20 percent of the time across a programme is either too tight or signals a bottleneck worth investigating. The answer is determined by reading the breach causes, not by adjusting the policy reflexively.
Removing The Spreadsheet, Carefully
Teams transitioning from spreadsheet tracking to in-pipeline tracking should not throw the spreadsheet away on day one. Run them in parallel for a quarter. Reconcile differences. The reconciliation usually surfaces interesting bugs in both systems, including findings that were prematurely marked closed in the spreadsheet because nobody was tracking the deployment step.
After a quarter of agreement, the spreadsheet can be retired. The few people who genuinely needed it for ad-hoc reporting will have learned to use the dashboards instead. The annual auditor review will be smoother in every direction.
How Safeguard Helps
Safeguard tracks remediation SLAs as part of the same pipeline that finds, fixes, and merges vulnerabilities. Every finding has a clock anchored to first-seen and stopped at deployed, with tier-based deadlines and active escalation built in. Real-time dashboards for executives, engineers, and auditors all read from the same underlying data so the numbers reconcile by construction. Breaches are annotated with causes that feed back into pipeline tuning. The spreadsheet retires honestly, the auditor gets a clean report on demand, and the SLA finally functions as a live control rather than a quarterly story.