In VR: When would you use SLAs rather than Remediation Targets

[LeslieC]

Hello,

We have the API integration with Rapid 7's InsightVM and are ready to set timelines on vulnerability remediation. We have  4-5 tiers for remediation timelines and I'm trying to determine if we should use SLAs or Remediation Targets. It seems like Remediation Targets are easier to set up, but we can get more granular with SLAs. Also, we already use Vulnerability Groups/Remediation Tasks to assign these to CI Support group. This is who we'd want the notifications to go to, but I don't see this option for Remediation Targets. 

Does anyone have any best practices or use cases for either SLAs or Remediation Tasks?

Thanks,

Leslie 

[Eliz Skogquist]

The solution works the same for Remediation Targets, 3 years later.

[chrismcdevi]

An important point to consider is that SLAs usually have a human component behind them. There is an "issue" that a human is waiting to be solved. When I think of Vulnerabilities, there is not a human behind the scenes waiting for this to be addressed so they can get on with whatever they are doing before the issue comes up. The second interesting thing is that humans are desensitized to urgency if they are overrun with stuff like SLAs. SLAs create a lot of unnecessary noise unless they are reserved for very select critical events.
If you think about it, there is zero difference between an RTD and an SLA if leaders don't take action. At the scale of VR, leaders must rely on RTD by reviewing their dashboards and determining how things are going. I think that MBWA is a very, very, very important job for leaders. I see many organizations try to have SN "manage" their employees' behavior through complex workflows, SLAs, and notifications.
Reserve the SLA for mission-critical events that involve humans.
Has my guidance changed on RTDs vs. SLAs? Nope. If anything, it is now leaning more towards RTD and having leaders review their dashboards and understand what is happening on the floor of their organizations.

[OlafNg]

Hello Chris, we are currently considering using SLAs instead of RTR because we want to exclude weekend days in the calculation. From our point the only way to use RTR and exclude weekend days is by customizing the script include for the RT calculation but we would like to avoid this solution. 

With SLA definitions we can select schedules where weekend days are excluded. Would you also consider SLAs to be the best way to implement this? 

[Branimir Morfov]

I think the discussion may be mixing two different governance concepts that actually serve different purposes.

Remediation Target Rules (RTRs) on Vulnerable Items are essentially a vulnerability exposure aging mechanism - effectively a desired remediation timeframe or “due date” for a specific vulnerability exposure (VIT). In that sense, I fully agree they should primarily support leadership visibility, dashboarding, and overall risk posture governance.

SLAs on Remediation Tasks, however, measure something different entirely: the operational performance of the resolver teams handling the remediation effort itself. They are closer to traditional operational metrics such as:

- Time to Own (TTO)
- Time to Resolve (TTR)
- Remediation execution accountability

In other words, the SLA is not necessarily measuring the vulnerability exposure duration itself, but rather the agreed operational response and execution expectations for the remediation team, regardless of implementation dependencies, CAB windows, vendor delays, etc.

From that perspective, both models can coexist perfectly well because they track different dimensions of the process:

- RTRs - security exposure aging and governance
- SLAs - operational remediation execution and team accountability

I would also agree that excessive SLA notifications can create noise and desensitization. In practice, I would lean toward:

- lightweight/no notifications on RTDs,
- while reserving SLA-driven escalations for selected operational remediation workflows or critical exposures.

That separation actually aligns quite well with the modern USEM direction, where exposure tracking and remediation operations are increasingly treated as separate governance layers.

[Eliz Skogquist]

OOB RTs assign on VIs and roll up to VULs.  SLAs only work on Task tables, so will be limited to VULs, as the VI table doesn't extend from Task.  Targets are commonly set in alignment with compliance requirements.  Curious, do they exclude weekends?  It's possible you aren't building against them, which is allowing you this leeway.  Could you simply add the weekend count (+2/week) to the duration you are considering in the RTR?