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.