Risk reduction not working as expected for newly linked VITs after the risk reduction has been approved - Known Error

Risk reduction not working as expected for newly linked VITs after the risk reduction has been approved Description Customers may experience an issue where, after a Risk Reduction (Mitigating Control in Place) has been approved on a Remediation Task, newly added or newly ingested Vulnerable Items linked to that task do not automatically inherit the reduced risk rating. Vulnerable Items that were already associated with the task when the reduction was approved are updated correctly; only items added afterward retain their original (higher) scanner risk rating. This can lead to incorrect risk ratings and SLA timelines for the new items until they are manually adjusted. A temporary workaround is available to resolve this.

Steps to Reproduce

1. HOP to instance. 2. Navigate to Security Exposure Management workspace

3. List > Remediation tasks > All. 4. Select any Remediation Task with Risk Rating (1 or 2) and State is not "Closed". 5. In Overview Section observe the VIT risk rating is high (1 or 2). 6. On Remediation Task form click on "Request Exception" and Select Reason as "Mitigating Control in Place" > Select "Request for Risk Reduction". S 7. Fill in mandatory fields and select Desired risk rating as P3 - P5. 8. Approve the approvers from "Requested Approvals". Open any Approval record > Approvers and "Approve" Refresh and Approve all remaining approvals. 9. Observe the record in "Change Approvals" move to "Approved" state. 10. Refresh page and observe VIT record on Overview section of Remediation task risk rating is reduced. (this is working for already associated VIT's). 11. Now add a new VIT with same Remediation task (I created a manual VIT with high risk rating). 12. I opened the "Remediation Task" in classic platform, and under related list > Vulnerable Items > Create a new VIT with P2 or P1 risk rating. OBSERVATION: The risk rating is not reduced automatically on newly attached VIT. EXPECTATION: The risk rating should be reduced automatically as stated in below doc: https://www.servicenow.com/docs/r/store-release-notes/store-secops-rn-vulnerability-response.html

Workaround Whether this issue affects you — and the fix required — depends on whether Exception Management plugin for Unified Security Exposure Management (USEM) is active on your instance.

Instances without Exception Management for USEM plugin (standard / non-USEM instances)

This issue is fully resolved in Vulnerability Response (sn_vul) application version 26.7.1 and later . On these versions, newly linked Vulnerable Items already inherit the approved reduced risk rating automatically — no action is required. If your instance is non-USEM and running an earlier version (26.6.2 up to 26.7.0) , you may still experience this issue. The 26.6.2 release introduced the underlying trigger for this feature, but a required supporting method was not completed until a later release. On versions prior to 26.7.1, this can cause the propagation to silently fail with no error shown to the user. Please upgrade your Vulnerability Response application to version 26.7.1 or later to resolve this.

Instances with Exception Management for USEM plugin active (USEM Instances)

Apply the following temporary update so that risk-reduction inheritance uses the Exception Management approval records and handler:

1. Log in to your ServiceNow instance as an administrator. 2. In the navigator, go to All and open sys_script_include.list. 3. Search the Name column for CompensatingControlUtils and open the record whose Application is Security Support Common (API Name sn_sec_cmn.CompensatingControlUtils). 4. In the script, locate the inheritRiskReductionForNewItem function. Find the approval-lookup and risk-application block:

4. Old: var approvalGr = this.fetchApprovalRecordForRiskReduction( taskGr.getTableName(), taskGr.getUniqueValue(), 'sn_vul_change_approval', 1 ); if (!approvalGr) return false;

try { (new sn_vul_cmn.VulnerableRecordBase(itemGr)).matchMitigatedRiskScore(approvalGr, taskGr); } catch (e) { gs.error('CompensatingControlUtils.inheritRiskReductionForNewItem failed for task={0}, item={1}: {2}', taskGr.getUniqueValue(), itemGr.getUniqueValue(), e.message); return false; } return true;

4. New: // Route based on whether Exception Management is active on this instance. var isUSEM = new GlidePluginManager().isActive('com.snc.sec.exception');

var approvalGr; if (isUSEM) approvalGr = new sn_sec_exception.CompensatingControlUtils().fetchApprovalRecordForRiskReduction( taskGr.getTableName(), taskGr.getUniqueValue(), 'sn_sec_exception_change_approval', 1 ); else approvalGr = this.fetchApprovalRecordForRiskReduction( taskGr.getTableName(), taskGr.getUniqueValue(), 'sn_vul_change_approval', 1 ); if (!approvalGr) return false;

try { if (isUSEM) (new sn_sec_exception.CompensatingControlHandler(itemGr)).matchMitigatedRiskScore(approvalGr, taskGr); else (new sn_vul_cmn.VulnerableRecordBase(itemGr)).matchMitigatedRiskScore(approvalGr, taskGr); } catch (e) { gs.error('CompensatingControlUtils.inheritRiskReductionForNewItem failed for task={0}, item={1}: {2}', taskGr.getUniqueValue(), itemGr.getUniqueValue(), e.message); return false; } return true;

5. Save the record. 6. Confirm the risk-rating weights are configured for your items: go to All → sn_sec_calculator_risk_score_weight.list and ensure entries exist for table = sn_vul_vulnerable_item (values 1–5). These are present by default; if empty, risk reduction cannot compute a reduced score.

After the update, newly linked Vulnerable Items on a task with an approved Risk Reduction will automatically inherit the reduced risk rating.

This issue will be permanently resolved in an upcoming Aug 2026 release; the workaround above is a temporary measure for USEM instances until you upgrade.