On this page
The Remediation Roadmap section at the back of every Violet report puts a calendar deadline next to every finding. Some teams treat those deadlines as commitments. Others treat them as suggestions. Both are wrong. The dates are a forecast — useful only if you understand what they're forecasting.
Why SLAs matter
SLAs exist so the people receiving the report can predict when their problem gets fixed. That's it. They are a communication tool, not a punishment mechanism.
Nobody reads the SLA column on the day the report lands. They read it three weeks later, when something is overdue and they want to know whether it should have been fixed by now. That's the moment the SLA either earns its credibility or loses it.
The SLA is the contract between you and the person who'll read this report next quarter.
The 24h / 7d / 30d / 90d framework
Violet's report uses four remediation buckets, one per severity level:
| Severity | Recommended timeline | Rationale |
|---|---|---|
| CRITICAL | 24 hours | Active exploitation risk; immediate patching required |
| HIGH | 7 days | Significant risk; prioritize current sprint |
| MEDIUM | 30 days | Moderate risk; schedule in next release cycle |
| LOW | 90 days | Minor risk; address during regular maintenance |
24 hours (Critical) — assume someone is exploiting this right now. The exploit is network-reachable, unauthenticated, and proven to work. Drop everything. A Critical finding open past 24 hours is a business risk, not a security risk. Brief your leadership if the fix will take longer.
7 days (High) — fits in your current sprint. The window is one week, not one sprint cycle. Don't let it slip to the next sprint because this sprint is already full. If your sprints are two weeks, the High SLA is still 7 days.
30 days (Medium) — goes in the next release window. If your release window is longer than 30 days, you have a separate problem worth solving. Medium findings are exploitable, just not trivially. They get worse when left alone.
90 days (Low) — bundle with regular maintenance. The point is not to deprioritize Low findings permanently, but to not lose track of them. 90 days is long enough to schedule properly. It is not long enough to forget.
Reading the tracking table
The Remediation Roadmap is a table with five columns: finding number, title, severity, SLA deadline, and status. Each row maps a finding to a calendar date.
Sort the table by SLA deadline ascending. The top of the list is the next two weeks of work. That is your queue. Work through it in order.
Don't sort by severity. Severity tells you how bad a finding is. The SLA deadline tells you when it's due. Those are different orderings. A Medium due tomorrow outranks a High due in five days.
The Status column has four valid values: Open, Mitigated, Fixed, Accepted. Open is the only one that should not be sitting there at the SLA deadline. The other three mean you made a decision. Open means you haven't.
Running the re-test
The verification block in each finding is your re-test recipe. Copy it. Run it. Confirm it fails in the secure direction.
If the verification step says “Expected (secure): HTTP 200 with Invalid credentials” and you now get HTTP 200 with Invalid credentials, the fix worked. Mark Fixed. The re-test took two minutes. The proof is in the response.
Re-run every verification step in the finding, not just the first one. A fix that passes step 1 and fails step 3 is not a complete fix. The verification block is the full bar, not a partial one.
Communicating slippage
An SLA will slip. That's normal. What matters is whether you tell the person who will read this report next.
- Missing by less than 7 days: update the Status column with a one-line note. Example: “Mitigated via WAF rule on 2026-04-18, full fix in next sprint.” One line. Date it. Move on.
- Missing by more than 7 days, or deciding not to fix: change the Status to Accepted and write a one-paragraph rationale. Who approved it, what the compensating control is, when it will be revisited. No rationale means no Accepted.
Silent slippage destroys the report's usefulness. The next person opening this in October will trust the Status column or they will trust nothing.
Closing a finding without lying
The temptation: mark Fixed because the ticket is closed. Tickets and findings are not the same thing. A closed ticket means someone shipped something. A Fixed finding means you ran the verification and the exploit no longer works.
The honest test: can you re-run the PoC from the report and watch it fail?
- Yes, here's the verification log — close it. Mark Fixed.
- We shipped a config change but didn't re-run the PoC — don't close it. Mark Mitigated. Re-test before marking Fixed.
- We decided this is fine as-is — mark Accepted. Write the rationale. “We decided this is fine” is not a rationale.
Three legitimate end-states. Pick the right one. Future you is reading.
The SLA isn't a deadline. It's a promise that someone will know what state this finding is in.