---
sourceDocument: Brazil Security Management
sourceDocumentLink: https://www.servicenow.com/docs/r/security-management

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Security Management

ft:clusterId :

    - security

bundleId :

    - security

workflow :

    - Technology


---

# Remediation tasks and vulnerable item states

# Remediation tasks and vulnerable item states {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Remediation tasks and vulnerable item states

This content explains how remediation task states and vulnerable item (VI) states interact within ServiceNow's vulnerability response process.
It details how VI states typically follow the highest precedence remediation task state in a group, exceptions to this rule, and how deferrals and manual updates affect state synchronization.
Show full answer Show less  

## Key Features

* **State precedence hierarchy:** Closed \> Deferred \> Resolved \> In Review \> Awaiting Implementation \> Under Investigation \> Open. The highest precedence remediation task state updates associated VIs.
* **Group state synchronization:** VIs in a remediation task without individual state changes mirror the remediation task's state. For example, when a remediation task moves from Open to Awaiting Implementation, all VIs update accordingly.
* **Deferral tracking (from version 16.5):** The system tracks how many times VIs or remediation tasks are deferred using a scheduled job that updates deferral counts daily. This is visible in the Multiple Deferrals modules for VR, AVR, and CVR.
* **Exceptions when VIs do not follow remediation task states:**
  * If a remediation task is Closed with resolution Canceled or Fixed with Exception, VIs take the state of other remediation tasks containing them or revert to Open if none.
  * VIs marked Closed/Fixed by scans or imports remain in that state regardless of remediation task changes.
* **Individually updated VIs:** VIs manually set to a state (e.g., Closed or Deferred) do not automatically adopt the remediation task state but the system uses state precedence across all associated remediation groups to determine the effective state.
* **Remediation task auto-closing:** If all VIs in a remediation task are Closed/Fixed, the remediation task is automatically marked Closed/Fixed.
* **Assignment field considerations:**
  * If a VI state changes from Resolved back to Open, the remediation task state changes to Under Investigation unless both 'Assigned to' and 'Assignment group' fields are empty, in which case the remediation task stays Resolved.
  * If a VI's assignment group is manually updated while in Open state, it is not overwritten by remediation task assignment group updates to preserve intentional manual changes.

## Practical Implications for ServiceNow Customers

Understanding these state relationships helps ensure accurate tracking and reporting of vulnerability remediation progress. Customers can rely on scheduled deferral counts to monitor repeated delays, and they must be aware that manual VI updates can override remediation task states. Proper assignment settings are important to maintain correct task state transitions, especially when reopening issues.

This knowledge enables customers to effectively manage vulnerability workflows, maintain clear audit trails, and optimize remediation task handling within ServiceNow Vulnerability Response.  
Remediation tasks and vulnerable items states can affect each other. Most of the time, a
remediation task state updates the vulnerable item state, with the highest precedence task state
used to update the vulnerable items in the group.

The state precedence is as follows.

ClosedDeferredResolvedIn ReviewAwaiting ImplementationUnder InvestigationOpen

* When a group of vulnerable items are in one remediation task and aren't altered at an individual level, they have the same state as their remediation task.
* When the remediation task goes from the Open state to Awaiting Implementation, all the VIs in the remediation task move to the Awaiting Implementation state.
* When the remediation task is deferred, the VI is likewise deferred. Starting with version 16.5, you can track the number of times that a vulnerable item, application vulnerable item, container vulnerable item, or a remediation task is deferred. The scheduled job, set deferral counts, runs daily to post counts for the records that are deferred more than once in the Deferral count column in the Multiple deferrals modules for VR, AVR, and CVR. All counts for VIs that are associated with a remediation task are collected and posted if a remediation task is deferred more than one time.

{#vr-rt-vi-states__ul_upz_pqj_mdb}  

Vulnerable items updated only by remediation tasks
:   Items match the state of the remediation task, if they haven't been updated individually,
    with these exceptions:

    * If the remediation task state changes to Closed, and its resolution to Canceled or Fixed with Exception, the item is not affected and takes on the state of any other remediation task that contains it. If the vulnerable item is in no other remediation task, it reverts to the Open state.
    * If the vulnerable item state is Closed/Fixed (updated by a scan or import), then when the remediation task changes its state, the vulnerable item remains in the Closed/Fixed state. This condition is true no matter what state the remediation task is in.
    {#vr-rt-vi-states__ul_nq4_r4t_bdb}

Vulnerable items in states set individually
:   Vulnerable items, in a state updated on the item, such as those items closed or deferred
    individually, don't match the state of the remediation task automatically. Instead, it
    compares its state to all associated groups to find the state with the highest precedence to
    apply.  
    Note:  
    The Closed/Fixed state is a special case. For the vulnerable items that are set to the Closed/Fixed state, if all vulnerable items within a remediation task are set to Closed/Fixed --- such as when a scanner finds that all the vulnerabilities have been remediated --- the remediation task is automatically marked as Closed/Fixed.

Remediation tasks contain empty assignment fields

:   If the state of the VIs in a remediation task changes from Resolved to Open, the state of the remediation task is also updated from Resolved to Under Investigation.However, if both
    the Assigned to and Assignment group fields in
    the remediation task are empty, the remediation task remains in the Resolved state and does
    not move to Under Investigation.

Assignment group for vulnerable items is not always updated when their remediation task is updated
:   If the assignment group for a VI in Open state is updated manually, it is not updated again when the assignment group for its remediation task is updated. This information is not overwritten because the assignment group
    for the VI has been updated intentionally, and might be a part of another remediation task.

*[\>]: and then