# Risk Acceptance And Sla > Use when defining remediation SLAs and handling the vulnerabilities you won't fix immediately — turning "not fixed" into a documented, owned decision instead of silent neglect. - Skill: `jihedbfr-art/risk-acceptance-and-sla` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add jihedbfr-art/risk-acceptance-and-sla` - Raw SKILL.md: https://api.skillmd.com/api/skills/jihedbfr-art/risk-acceptance-and-sla/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: jihedbfr-art (https://skillmd.com/u/jihedbfr-art) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/jihedbfr-art/risk-acceptance-and-sla --- ## Prerequisites - Target system, dependencies and environment configured. ## Usage ### Purpose A vulnerability programme has to answer two governance questions that pure technical work doesn't: *how fast must each class of finding be fixed?* (SLAs) and *what happens to the ones we won't fix right now?* (risk acceptance). Get these right and the programme is defensible, prioritised, and honest; get them wrong and you either have no accountability for timeliness or a pile of unfixed vulns that are indistinguishable from negligence. This skill covers both. ### When to use it Setting up a vuln-management programme's governance, and continuously as findings that can't be immediately remediated arise. It's what makes the difference between "we didn't fix it" (neglect) and "we made a documented, owned decision not to fix it yet" (risk management). ### Remediation SLAs 1. **Set SLAs by risk tier, not raw severity.** Define how quickly each priority class must be remediated, based on the risk-based prioritisation (severity × exposure × exploitation likelihood): - actively-exploited / KEV / critical-and-exposed → days. - high risk → a few weeks. - medium → the normal cycle. - low → best-effort / next major cycle. 2. **Make SLAs measurable and owned** — each finding has a due date and an owner, and the programme tracks SLA compliance. An SLA nobody measures is a wish. 3. **Tie SLA breaches to escalation** — a finding past its SLA escalates to management, so timeliness has teeth. ### Risk acceptance (for what you won't fix now) 4. **Treat "won't fix now" as an explicit decision, not a default.** Some findings genuinely shouldn't be fixed immediately — a low risk with high remediation cost, an unpatchable legacy system, a fix that breaks a critical function. That's legitimate, *if* it's a documented risk-acceptance decision. 5. **A valid risk acceptance has four parts:** an **owner** (someone with authority accepting it, not the analyst), a **rationale** (why not fixing is acceptable — the actual risk weighed), any **compensating controls** in place, and a **review/expiry date** so it's revisited, not permanent. Missing any of these and it's not risk acceptance — it's neglect with paperwork. 6. **Require appropriate authority.** The higher the risk being accepted, the more senior the sign-off. A critical-vuln acceptance isn't an analyst's call; it goes up. 7. **Review acceptances on their expiry** — circumstances change (an exploit drops, the asset's exposure changes, the compensating control lapses). A risk accepted last year may be unacceptable now. ### Cheatsheet ``` SLAs (by RISK tier, not raw severity) KEV / actively-exploited / critical+exposed -> days high -> weeks medium -> normal cycle low -> best-effort measurable + owned + due-dated ; breach -> escalate to management risk acceptance = an explicit DECISION, needs 4 parts: [ ] OWNER with authority (not the analyst; seniority scales with risk) [ ] RATIONALE (real risk weighed, why deferral is acceptable) [ ] COMPENSATING CONTROLS in place (what reduces the risk meanwhile) [ ] REVIEW / EXPIRY date (revisit — never permanent) missing any part = NOT risk acceptance, just documented neglect. review on expiry: exploit dropped? exposure changed? control lapsed? -> re-decide. ``` ### Reading the governance - **No SLAs** = no accountability for how fast anything gets fixed; findings linger with no defined urgency. Define risk-tiered SLAs with owners and due dates. - **SLAs defined but unmeasured** = a policy nobody enforces; findings breach them invisibly. Measure compliance and escalate breaches. - **Unfixed findings with no risk-acceptance record** = indistinguishable from negligence, and a serious liability after an incident ("you knew and did nothing"). Every deferral needs a documented decision. - **A "risk acceptance" missing an owner, rationale, controls, or expiry** = not a real decision; it's neglect dressed up. All four parts are required. - **Accepted risks that are never reviewed** = decisions made under old circumstances that may no longer hold (an exploit has since dropped). Expiry-driven review is mandatory. - **Risk-tiered measured SLAs plus properly-documented, owned, expiring acceptances** = a defensible, honest programme. ### The fix / best practice - **Define remediation SLAs by risk tier**, measurable, owned, and due-dated, with escalation on breach. - **Require documented risk acceptance** for anything not fixed within SLA — owner with authority, rationale, compensating controls, and expiry date. - **Scale sign-off authority with the risk** being accepted; big risks go to senior management, not analysts. - **Review acceptances on expiry** (and when circumstances change — a new exploit, changed exposure) so deferrals don't become permanent by default. - **Track both SLA compliance and open acceptances** as programme metrics for reporting and governance (feeds the reporting and GRC work). - Recognise the goal: make every "not fixed" an accountable decision, never a silent gap. ### Pitfalls - **No SLAs.** Without defined timeliness, remediation has no urgency and no accountability; findings drift indefinitely. - **Silent non-remediation.** Unfixed vulns with no documented decision are the worst governance failure — legally and operationally indistinguishable from neglect. Document every deferral. - **"Risk acceptance" without the four parts.** An owner-less, rationale-less, unreviewed acceptance is neglect with a label. Require all four. - **Analyst-level acceptance of serious risk.** Accepting a critical risk isn't a technician's call; authority must match the risk. - **Permanent acceptances.** Circumstances change; an acceptance with no expiry becomes a forgotten open hole. Always set a review date. ### References - NIST SP 800-40 and SP 800-37 (risk management framework, risk acceptance) - ISO/IEC 27005 (risk treatment including acceptance) - The cvss-in-context, epss-and-exploit-likelihood, and GRC risk-assessment skills - FAIR / industry guidance on risk-based SLAs ## Inputs - Relevant source code, logs, network traces, or system specifications. ## Outputs - Analysis findings, security audit report, or generated code artifacts.