Exception rules in Vulnerabiltiy management
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-21-2026 03:33 AM
One of my observations is that a specific Exception Rule in ServiceNow Vulnerability Response was supposed to expire on 24 June 2025. However, a new Vulnerable Item (VIT1XXXXX) created this month still went into Deferred state, and it appears to have been deferred because of this expired exception rule.
A similar issue is happening with another exception rule (valid until 30‑09‑2025) which is also still marking new VITs as Deferred, even though the expiry date has passed.
This suggests that ServiceNow VR is continuing to apply expired exception rules to new VITs, causing them to inherit a Risk Accepted / Deferred state even when the exception should no longer be active.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
Hi, do not assume the end date alone stops the rule. In Vulnerability Response, what the engine applies to a new Vulnerable Item is the rule's current state and conditions, so check those two things first, in this order.
First, prove which rule deferred the new VIT. Open one of the newly created Deferred VITs and check its exception-related fields and related exception record to confirm the rule that is actually linked to it. If a different, still-active rule has overlapping conditions, the expired rule is a red herring, and fixing the wrong rule will not change anything.
Second, open the suspect rule itself and check its State, not just its valid-to date. If it still shows as Active, that is why new VITs are still being deferred: the date passing does not by itself flip an Active rule to inactive if that state change never happened. Set the rule to Inactive, or to the expired state your instance uses, and then test with a newly created VIT to confirm it no longer goes to Deferred.
If the rule already shows as expired or inactive and new VITs are still deferred, then look for a second cause: another active rule with the same conditions, or a customization that sets Deferred independently of the exception rule. That is also the point to raise with Support, because an inactive rule should not be applied.
Note that deactivating the rule will not automatically reopen VITs that were already deferred. Those already-deferred items need to be reviewed and moved back to remediation separately.