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

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama Security Management

ft:clusterId :

    - security

bundleId :

    - security

workflow :

    - Technology


---

# Vulnerability Response remediation task states

# Vulnerability Response remediation task states {#ariaid-title1}

Release version: Yokohama  
Updated January 30, 2025  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 7 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 Vulnerability Response remediation task states

Vulnerability Response (VR) in ServiceNow manages vulnerable item detections imported from third-party integrations, creating and updating Vulnerability Items (VITs).
The remediation tasks associated with these VITs progress through defined states that reflect the lifecycle of vulnerability remediation.
These states are synchronized with related change requests when Change Management for VR is enabled, ensuring consistent tracking of remediation efforts.
Show full answer Show less  
Starting with VR version 23.0, the Remediation Task State Approval workflow is deprecated and replaced by a Flow Designer flow. The Close button was removed from remediation tasks; task closure is now controlled by scanner confirmation.

## Remediation Task States and Actions

Each remediation task state allows specific actions to manage vulnerabilities effectively:

* **Open:** Initial state. Actions include identifying duplicate VITs, starting investigation, marking false positives, requesting exceptions to defer remediation, resolving tasks, creating or associating change requests, splitting tasks by filtering vulnerable items, deferring tasks with reasons and reopen dates, and deleting tasks.
* **Under Investigation:** Triggered by starting investigation. Allows creating security incidents, change requests, and splitting tasks.
* **Deferred:** Used to postpone remediation with approval required. From here, you can create change requests, split tasks, create security incidents, reopen to Open, or delete. Deferment details are tracked, and tasks reopen automatically on the defer date.
* **Awaiting Implementation:** Indicates remediation is handled outside VR. Actions include creating security incidents, change requests, splitting tasks, deferring, resolving, or deleting.
* **Resolved:** Marked when remediation is complete but pending scanner confirmation. You can create security incidents, change requests, reopen tasks, or delete. Resolution notes are maintained.
* **Closed:** Set automatically by the scanner upon confirmation. Tasks can be reopened or deleted. Closure information is recorded.

## Key Operational Details

* Only remediation owners can mark tasks or VITs as Resolved; closure depends on scanner confirmation.
* Administrators can delete or close multiple manually created VITs as needed.
* Deferring tasks is useful for low-risk items awaiting change windows or patches; exceptions can be requested with documented reasons.
* When VITs reopen, their state resets to Open and they are reevaluated against active remediation rules, preserving historical data while enabling continued remediation.
* State, Reason, and Until fields on remediation tasks and VITs are evaluated and updated automatically, including when tasks are split or VITs are updated.
* If all VITs in a remediation task share a defer reason, the task inherits that reason; if reasons differ, the task's reason is cleared. The earliest reopen date among VITs is reflected on the task.
* Reopening any VIT sets the remediation task state back to Open.
* A scheduled job runs every 15 minutes to roll up and synchronize vulnerability item and remediation task statuses.

## Practical Implications for ServiceNow Customers

This structured remediation task state model enables customers to:

* Track and manage vulnerabilities throughout their lifecycle with clear, actionable states.
* Leverage automated synchronization between remediation tasks and change requests to streamline remediation workflows.
* Use deferral and exception mechanisms to manage remediation timelines and risk appropriately.
* Maintain audit trails and ensure accurate status tracking as vulnerabilities and remediation tasks evolve.
* Integrate with security incidents and change management processes to align security remediation with broader IT and security operations.  
Third-party integrations import vulnerable item detection data that create new vulnerability items (VITs) or update existing VITs. Detection states update VIT states in so far as they're Open or Closed.
For more information on how a detection's state affects a VIT's state, see the [Detections, remediation tasks, and vulnerable item states](https://www.servicenow.com/docs/4WR9cW2cj9Vdp6LqXapDYg "Third-party integrations retrieve the vulnerable item detection data. Detections are distinct occurrences of vulnerabilities as reported by the scanners.").  
With [Change management for Vulnerability Response](https://www.servicenow.com/docs/SErXEDIv9GWGiKB7nIYzDA "As an IT remediation owner, you can create and manage change requests (CHG) directly from remediation tasks (RT) in the Vulnerability Response application. Change requests help you initiate and track change activities on your assets so that you can remediate your remediation tasks and their corresponding vulnerable items."), there's a synchronized relationship between the state fields of the remediation tasks and the state fields of the change requests (CHG) in the Vulnerability Response product. As a change request moves through its life cycle, it also moves the state of any related remediation tasks automatically. After a change request is implemented, the remediation task is automatically resolved. See [State synchronization between change requests and remediation tasks](https://www.servicenow.com/docs/F4IFTs3IkpLLRd_U_1doSQ "There is a synchronized relationship between the State fields of remediation tasks (VULs) and the State fields of change requests (CHG) in the Vulnerability Response product. As a change request moves through its life cycle, it also moves the state of any related remediation tasks automatically.") for more information.  
Note:  
Starting with v23.0 of Vulnerability Response:

* the Remediation Task State Approval workflow is deprecated and replaced by flow Remediation Task State Approval in the flow designer.
* the Close button has been removed for a remediation task and the closure of a remediation task is driven by the scanner.
{#vr-rt-states__ul_sp3_fr2_jcc}

The following table lists the remediation task states and the actions that you can perform on a remediation task at the respective state:  
{#vr-rt-states__table_hsr_mfq_hbb__entry__2}

| State | Description |
|-|-|
| Open | State upon creation. From this state you can: Show Duplicate VIs :   Identify duplicate VITs reported by multiple scanners in the system. You can mark the duplicate VIT as Resolved or Closed. Duplicate entries are only shown when the combination of vulnerabilities is created using Common Vulnerabilities and Exposures (CVE). For more information, see [Vulnerability Response remediation task and vulnerable item states](https://www.servicenow.com/docs/m5MJhHq1V8HbVYRYOkkgWg "With the Vulnerability Response application, you can use the state model to see the status of a remediation task, at any given time. Knowing how each state relates to and affects each other helps you to determine when and how to remediate your vulnerable items (VIs)."). Start Investigation :   Assign this remediation task to a person or group to start investigating. Mark as false positive :   Mark an item or group as false positive if the scanner reports that a vulnerability exists in the system, but in reality there's no vulnerability. Request exception :   Request an exception, a reopen (Until) date, a reason, and optionally, provide additional information. Defers the remediation of the item or group until the date that an exception is requested. Resolve :   Mark as Resolved to move the item or group to a resolved state. Create Change :   Create a change request or associate a remediation task to an existing change request. For more information, see [Create a change request from a remediation task](https://www.servicenow.com/docs/4gow9PFoL9ECSWwG61vQmw "As an IT remediation owner, create a change request (CHG) directly from a remediation task (VUL) for all the vulnerable items in the group. Create a change request with pre-populated information that includes the preferred solution to expedite your investigation for vulnerabilities that require manual intervention.") and [Associate a remediation task to an existing change request](https://www.servicenow.com/docs/VlMk2jIyVhM4EDk8ZxW_YQ "As an IT remediation owner, avoid creating duplicate change requests (CHG) as you work to resolve your remediation tasks by associating a remediation task (VUL) to a change request that is already available in your instance."). Split Remediation task :   For a remediation task with more than one vulnerable item, use a set of conditions to filter out a subset of vulnerable items and split a remediation task. The items that you select are automatically moved to a new remediation task. For more information, see [Split a remediation task in the IT Remediation Workspace](https://www.servicenow.com/docs/A6rnAOhXk139BEtTDSrkNg "From a remediation task (VUL, AVUL, CVUL, or CRG), identify a subset of records and create a new remediation task for them."). Defer :   Select the Deferred state, a reopen date, a reason and, optionally, provide addition information. Defers the remediation task state until the reopen date. Delete :   Confirm the deletion. Removes the group. |
| Under Investigation | Triggered by the Start Investigation button. From this state, you can: Create a Security Incident :   For more information, see [Create a security incident](https://www.servicenow.com/docs/IcK6yvN1M5XMO26dkXUx0g "In addition to automatic methods for creating security incidents, you can create them manually, as needed."). Create Change :   Create a change request or associate a remediation task to an existing change request. For more information, see [Create a change request from a remediation task](https://www.servicenow.com/docs/4gow9PFoL9ECSWwG61vQmw "As an IT remediation owner, create a change request (CHG) directly from a remediation task (VUL) for all the vulnerable items in the group. Create a change request with pre-populated information that includes the preferred solution to expedite your investigation for vulnerabilities that require manual intervention.") and [Associate a remediation task to an existing change request](https://www.servicenow.com/docs/VlMk2jIyVhM4EDk8ZxW_YQ "As an IT remediation owner, avoid creating duplicate change requests (CHG) as you work to resolve your remediation tasks by associating a remediation task (VUL) to a change request that is already available in your instance."). Split Task :   For a remediation task with more than one vulnerable item, use a set of conditions to filter out a subset of vulnerable items and split a remediation task. The items that you select are automatically moved to a new remediation task. For more information, see [Split a remediation task](https://www.servicenow.com/docs/x1jbDx8E4xM4c1fu3SwY_Q "As an IT remediation owner, from an existing remediation task (VUL), identify a subset of vulnerable items (VI) that you want to move to a new group."). Create a Change Request :   For more information, see [Create a change request from a remediation task](https://www.servicenow.com/docs/4gow9PFoL9ECSWwG61vQmw "As an IT remediation owner, create a change request (CHG) directly from a remediation task (VUL) for all the vulnerable items in the group. Create a change request with pre-populated information that includes the preferred solution to expedite your investigation for vulnerabilities that require manual intervention."). Awaiting Implementation :   Changes state to Awaiting Implementation. This state indicates that remediation tasks have been referred outside a Vulnerability Response. Defer :   Select the Deferred state, a reopen date, a reason and, optionally, provide additional information. Defers the remediation task state until the reopen date. Delete :   Confirm the deletion. Removes the remediation task. |
| Deferred | Triggered by the Request Exception button. As part of the approval workflow, the Deferred state is In Review and can't be closed until approved. From this state, you can: Create Change :   Create a change request or associate a remediation task to an existing change request. For more information, see [Create a change request from a remediation task](https://www.servicenow.com/docs/4gow9PFoL9ECSWwG61vQmw "As an IT remediation owner, create a change request (CHG) directly from a remediation task (VUL) for all the vulnerable items in the group. Create a change request with pre-populated information that includes the preferred solution to expedite your investigation for vulnerabilities that require manual intervention.") and [Associate a remediation task to an existing change request](https://www.servicenow.com/docs/VlMk2jIyVhM4EDk8ZxW_YQ "As an IT remediation owner, avoid creating duplicate change requests (CHG) as you work to resolve your remediation tasks by associating a remediation task (VUL) to a change request that is already available in your instance."). Split Task :   For a remediation task with more than one vulnerable item, use a set of conditions to filter out a subset of vulnerable items and split a remediation task. The items that you select are automatically moved to a new VG. See [Split a remediation task](https://www.servicenow.com/docs/x1jbDx8E4xM4c1fu3SwY_Q "As an IT remediation owner, from an existing remediation task (VUL), identify a subset of vulnerable items (VI) that you want to move to a new group."). Create a Security Incident :   For more information, see [Create a security incident](https://www.servicenow.com/docs/IcK6yvN1M5XMO26dkXUx0g "In addition to automatic methods for creating security incidents, you can create them manually, as needed."). Reopen :   Transition back to an Open state. Delete :   Confirm the deletion. Removes the remediation task. Deferment information appears under the Close/Defer tab. On the defer date, the group reopens for remediation. |
| Awaiting Implementation | Triggered by the Awaiting Implementation button. From this state, you can: Create a Security Incident :   For more information, see [Create a security incident](https://www.servicenow.com/docs/IcK6yvN1M5XMO26dkXUx0g "In addition to automatic methods for creating security incidents, you can create them manually, as needed."). Create Change :   Create a change request or associate a remediation task to an existing change request. For more information, see [Create a change request from a remediation task](https://www.servicenow.com/docs/4gow9PFoL9ECSWwG61vQmw "As an IT remediation owner, create a change request (CHG) directly from a remediation task (VUL) for all the vulnerable items in the group. Create a change request with pre-populated information that includes the preferred solution to expedite your investigation for vulnerabilities that require manual intervention.") and [Associate a remediation task to an existing change request](https://www.servicenow.com/docs/VlMk2jIyVhM4EDk8ZxW_YQ "As an IT remediation owner, avoid creating duplicate change requests (CHG) as you work to resolve your remediation tasks by associating a remediation task (VUL) to a change request that is already available in your instance."). Split Task :   For a remediation task with more than one vulnerable item, use a set of conditions to filter out a subset of vulnerable items and split a remediation task. The items that you select are automatically moved to a new remediation task. For more information, see [Split a remediation task](https://www.servicenow.com/docs/x1jbDx8E4xM4c1fu3SwY_Q "As an IT remediation owner, from an existing remediation task (VUL), identify a subset of vulnerable items (VI) that you want to move to a new group."). Create a Change Request :   For more information, see [Create a change request from a remediation task](https://www.servicenow.com/docs/4gow9PFoL9ECSWwG61vQmw "As an IT remediation owner, create a change request (CHG) directly from a remediation task (VUL) for all the vulnerable items in the group. Create a change request with pre-populated information that includes the preferred solution to expedite your investigation for vulnerabilities that require manual intervention."). Defer :   Select the Deferred state, a reopen date, a reason and, optionally, provide addition information. Defers the remediation task state until the reopen date. Resolve :   Add notes. The state becomes Resolved. Notes appear under the Resolution tab. Delete :   Confirm the deletion. Removes the remediation task. |
| Resolved | Triggered from the Resolve button. From this state you can: Create a Security Incident :   For more information, see [Create a security incident](https://www.servicenow.com/docs/IcK6yvN1M5XMO26dkXUx0g "In addition to automatic methods for creating security incidents, you can create them manually, as needed."). Create Change :   Create a change request or associate a remediation task to an existing change request. For more information, see [Create a change request from a remediation task](https://www.servicenow.com/docs/4gow9PFoL9ECSWwG61vQmw "As an IT remediation owner, create a change request (CHG) directly from a remediation task (VUL) for all the vulnerable items in the group. Create a change request with pre-populated information that includes the preferred solution to expedite your investigation for vulnerabilities that require manual intervention.") and [Associate a remediation task to an existing change request](https://www.servicenow.com/docs/VlMk2jIyVhM4EDk8ZxW_YQ "As an IT remediation owner, avoid creating duplicate change requests (CHG) as you work to resolve your remediation tasks by associating a remediation task (VUL) to a change request that is already available in your instance."). Reopen :   Transition back to an Open state. Delete :   Confirm the deletion. Removes the remediation task. Notes appear under the Notes tab. Resolution information appears under the Resolution tab. |
| Closed | Triggered by the scanner. From this state, you can: Create a Security Incident :   For more information, see [Create a security incident](https://www.servicenow.com/docs/IcK6yvN1M5XMO26dkXUx0g "In addition to automatic methods for creating security incidents, you can create them manually, as needed."). Reopen :   Transition back to an Open state. Delete :   Confirm the deletion. Removes the remediation task. Closure information appears under the Close/Defer tab. |
[Table 1. Remediation task states]

{#vr-rt-states__table_hsr_mfq_hbb}

* The remediation owner can only mark a vulnerable item or remediation task as resolved. Based on the confirmation from the scanner, this resolved item or remediation task can be marked as Closed or reopened.
* The Delete button is available for the administrator when there are multiple vulnerable items created manually, and these need to be closed or deleted.
* If you determine that the items are a low risk, waiting for a change window, or a patch, you can change their remediation task to the Deferred state for a defined amount of time. You can request an exception using the Request Exception option.  
  Note:  
  When remediation tasks are deferred or closed, you can specify resolutions to further define the reasons for doing so.
* When a VIT is reopened, either manually or automatically, the following happens:
  * The VIT state changes to Open. The original remediation task state doesn't update.
  * The VIT is reevaluated and put into a new or existing remediation task that is based on the active Remediation Task Rules.

  {#vr-rt-states__ul_akh_bfg_3jb}

  This preserves its history while enabling further remediation.
* When a remediation task is created (automatically or manually), or split, then its State, Reason, and Until fields are evaluated. In case of the split action, these fields are evaluated for both the old and new remediation tasks. When a VIT is updated, then the State, Reason, and Until fields of all its associated remediation tasks are evaluated.
  * If all the VITs in a remediation task are deferred and have the same reason, then the remediation task's state changes to Deferred and the VITs' reason is assigned to the remediation task. If the VITs differ in reason, then the remediation task's reason changes to None.
  * The closest Until date of all the VITs is updated in the Until field of the remediation task.
  * If you reopen any VIT, then the state of the remediation task changes to Open.

  {#vr-rt-states__ul_jlq_fdk_gvb}

  This evaluation is done by the Rollup vulnerability item values to vulnerability and group scheduled job, which runs every 15 minutes.
{#vr-rt-states__ul_w5l_yz1_jbb}