Remediation task state for Vulnerable Items (VITs) in multiple groups

  • Release version: Zurich
  • Updated July 31, 2025
  • 3 minutes to read
  • Summarize
    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 task state for Vulnerable Items (VITs) in multiple groups

    This content explains how the state of a Vulnerable Item (VI) is determined when it belongs to multiple remediation tasks (RTs) within ServiceNow Vulnerability Response. When a VI is associated with multiple groups and its own state is not explicitly set, the VI’s state is determined by the remediation task with the highest precedence state. This logic helps maintain accurate vulnerability tracking across multiple remediation efforts.

    Show full answer Show less

    Key Concepts

    • Precedence of remediation task states: When a VI is linked to multiple RTs, the VI’s state reflects the RT state with the highest precedence.
    • State precedence examples: For instance, if one RT is in "Under Investigation" and another is in "Open," the VI state will be "Under Investigation" as it has higher precedence.
    • Equal precedence states: If multiple RTs share the same state, the VI state remains unchanged.
    • Special cases: If one RT is "Closed (Fixed or Cancelled)" while another is "Under Investigation," the VI state will be "Under Investigation" due to higher precedence.
    • Fixed vulnerabilities: If a VI’s source status is updated to Fixed (via scan or import), the VI state changes to "Closed/Fixed" regardless of RT states, bypassing normal precedence checks.
    • Individually set VI states: When a VI state is set manually, it is considered in precedence evaluation along with RT states to determine the final VI state.
    • Deferred state handling: For VIs deferred in multiple RTs, the deferred state with the latest expiration date takes precedence for the VI’s deferred state.

    Practical Implications for ServiceNow Customers

    • Understanding VI state precedence allows accurate tracking of vulnerabilities when multiple remediation tasks are involved.
    • Automatic state updates based on RT states help reduce manual effort and ensure consistent vulnerability status across groups.
    • The special handling of fixed vulnerabilities ensures closed issues are not mistakenly reopened due to other RT states.
    • Managing deferred states with date-based precedence helps prioritize remediation timelines effectively.
    • Customers can rely on this precedence logic to generate accurate reports and trigger appropriate workflows based on VI states.

    When a VIT is in multiple remediation tasks, (RT in the following tables), and its own state has not been set, the higher precedence group state determines the state of that VIT, as shown in the following table.

    Table 1. Vulnerable item states examples
    Remediation task state Vulnerable item state
    RT 1: Open > Under Investigation

    RT 2: Open

    Under Investigation

    When RT 1 is Under Investigation and RT 2 is Open, the VI changes to Under Investigation. After the search, between RT 1 and RT 2, RT 1 has the state with the highest precedence.

    RT 1: Under Investigation

    RT 2: Open > Under Investigation

    Under Investigation

    When RT 2 is Under Investigation and RT 1 is Under Investigation, the VI stays as Under Investigation. After the search, between RT 1 and RT 2, they have the state with the same precedence.

    RT 1: Under Investigation

    RT 2: Under Investigation > Awaiting Implementation

    Awaiting Implementation

    When RT 2 is Awaiting Implementation and RT 1 is Under Investigation, the VI changes to Awaiting Implementation. After the search, between RT 1 and RT 2, RT 2 has the state with the highest precedence.

    RT 1: Under Investigation > Deferred

    RT 2: Awaiting Implementation

    Deferred

    When RT 1 is Deferred and RT 2 is Awaiting Implementation, the VI changes to Deferred. After the search, between RT 1 and RT 2, RT 1 has the state with the highest precedence.

    Table 2. Vulnerable item in multiple groups special cases
    Remediation task State Vulnerable Item State
    RT 1: Under Investigation

    RT 2: Awaiting Implementation > Closed (Fixed or Cancelled)

    Under Investigation

    When RT 2 is Closed/Fixed or Closed/Cancelled, and RT 1 is Under Investigation, the VI changes from Awaiting Implementation (previously the highest precedence) to Under Investigation (currently the highest precedence).

    RT 1: any state

    RT 2: any state

    If the vulnerable item source status is Fixed (updated by a scan or import), then when the group changes its state, the vulnerable item changes its state to Closed/Fixed. This condition is true no matter what states the other associated groups are in. The vulnerable item search for the group state does not occur.
    When a VI state is set individually, its state is considered when evaluating precedence, as with any other remediation task. When a VI belongs to more than one remediation task, the following table lists the updates that are made.
    Table 3. Vulnerable item state set individually special cases
    Vulnerability item state within a group Vulnerable item final state
    RT 1 state: Under Investigation

    RT 2 state: Under Investigation > Awaiting Implementation

    Original VI state: Under Investigation > (set on the VI)

    Awaiting Implementation

    When RT 2 moved to Awaiting Implementation, and RT 1 remained Under Investigation, the VI changes to Awaiting Implementation (the highest precedence).

    RT 1: Under Investigation

    RT 2: Under Investigation > Awaiting Implementation

    Original VI state: Deferred > (set on the VI)

    Deferred

    When RT 2 moved to Awaiting Implementation, and RT 1 remained Under Investigation, the VI remains in the Deferred state (the highest precedence).

    The following table shows that when two remediation tasks with common vulnerable items are deferred, the state is deferred until the latest date is reached.
    Table 4. Vulnerable item deferred state special cases
    Vulnerability item state within a group Vulnerable item final state
    RT 1 state: In Review (until April 10)

    RT 2 state: Under Investigation > In Review (until April 30)

    Original VI state: In Review (until April 10) > (set on the VI)

    Deferred (until April 30)

    When RT 2 moved to Deferred (until Apr-30), and RT 1 remains Deferred (until Apr-10), the VI changes from Deferred (until Apr-05) to Deferred state (until Apr-30).

    RT 1: In Review (until July 15)

    RT 2: Under Investigation > In Review (until July 10

    Original VI state: Deferred > (until July 15)

    Deferred (until July 15)

    When RT 2 moved to Deferred (until Jul-10), and RT 1 remains Deferred (Jul-15), the VI remains in Deferred (until Jul-15).