Remediation Status on VIT ignores SLA if Deferred?

[AC12]

We are in the process of updating our platform to Zurich and updating VR to version 26.0.13.

In the update it appears ServiceNow is adding a new functionality within "Transit to Closed" business rule for VIT:

In this new update, a VIT could be defined an SLA via Remediation Target Rule, and then get associated to a Policy Exception and put in a deferred state.  Instead of freezing the Remediation Status, or allowing the Remediation Status to continue tracking the prescribed Remediation Target Rule SLA, it negates that and will leverage the associated Policy Exception so that the VIT could show Remediation Status of Target Met well after the actual SLA per Remediation Target Rule set it.

Example:
VIT Created and assigned Remediation Target Rule: 01JAN2026

Remediation Target - 15JAN2026

VIT Deferred date: 14JAN2026

VIT actually Closed (remediated) - 15OCT2027

Remediation Status - Target Met

I am concerned by this implementation, 1) this is not optional, meaning for me to not use this I have to introduce a customization and 2) this provides overlapping timelines/timestamps for when something was due, was done.

[QM_SSJ4]

From a process standpoint, I think once an exception is approved a new remediation target is set outside of the standard rule configuration. All parties agree that the original remediation target can't be met (the reason for the exception) and a new target date (expiration of the exception). As long as the VIT is closed prior to the exception expiring, you've met the target.

You could always create a report to track the issue you referenced with a query something like

Active = True & State = Deferred & Remediation Target < Today

For closed VIT's you could look at Remediation Target < Closed & Deferral Count > 0

[AC12]

That could be a business level of acceptance, but that is not our business level of acceptance.

A vulnerability has a defined SLA, and is measured against it.  If it goes into an exception, this means it is deviating from pre-defined 'Standard'. The originating SLA is still relevant and should still be measured.  By allowing an external table to introduce a new SLA, like the policy exception table, we lose the ability to track, measure adherence to said Standard. 

What should happen, like within SIR for incidents, is another or several SLA are created and associated so that all aspects of the vulnerability (VIT) lifecycle are captured and can be measured and tracked.