State roll-up and roll-down scenarios
Summarize
Summary of State Roll-Up and Roll-Down Scenarios
State roll-up and roll-down scenarios in ServiceNow facilitate the automatic synchronization of remediation tasks (RTs) and vulnerable items (VITs). This feature provides real-time updates, improving accuracy and efficiency in vulnerability management, and enables users to make informed decisions swiftly.
Show less
Key Features
- Roll-Up Behavior: Changes in VIT states can influence RT states. For instance, if a VIT transitions to a non-final state, the corresponding RT remains open.
- Closure conditions: If all associated VITs are closed, the RT will also close with the same sub-state.
- Roll-Down Behavior: Changes in RT states can propagate to associated VITs unless manually overridden. For example, if an RT is marked as resolved, the associated VIT state will change accordingly.
- Precedence Rules: Specific conditions dictate how state changes affect VITs, ensuring consistent tracking across both entities.
Key Outcomes
By implementing these roll-up and roll-down scenarios, ServiceNow customers can expect:
- Reduction in manual tracking efforts, leading to improved operational efficiency.
- Real-time visibility into the status of remediation efforts, enhancing decision-making capabilities.
- Streamlined vulnerability management processes, allowing for quicker responses to threats.
State roll-up and roll-down scenarios automatically sync the status of remediation tasks (RTs) and vulnerable items (VITs), ensuring real-time updates across both. This dynamic interaction reduces manual tracking, enhances accuracy, and provides users with an up-to-date view of progress, making vulnerability management more efficient and helping users make informed decisions quickly.
Roll-up behavior
When vulnerable item (VIT)states change, these changes may propagate up to the remediation task (RT)level. The following table summarizes key roll-up scenarios where changes in vulnerable item (VIT) state may influence the associated remediation task (RT) state, based on closure conditions, reassignments, and deferrals.
| VITs State | Condition | RT State |
|---|---|---|
| Open → Under Investigation / Awaiting Implementation (any sub-state) / In Review | VIT transitions to any non-final or non-actionable state | Remains Open |
| Open → Closed | All associated VITs have the same sub-state | Closed – <same sub-state as VITs> |
| Open → Closed | All associated VITs have different sub-states | Closed – <no sub-state> |
| Open → some Closed VITs and some Deferred VITs | All associated Deferred VITs have the same sub-state | Deferred – <same sub-state as VITs> (Until date = earliest of all VITs) |
| Open → some Closed VITs and some Deferred VITs | All associated Deferred VITs have different sub-states | Deferred – <no sub-state> (Until date = earliest of all VITs) |
| Open → Closed–Fixed (after next scan) → Resolved | VITs marked as fixed but pending verification | Remains Open |
| Closed–Fixed → Open | VIT reopens after being Closed–Fixed | Remains Closed–Fixed |
| Closed–Stale → Open | VIT reopens after being Closed–Stale | Remains Closed–Cancelled |
| Under Investigation → Closed–CI Decommissioned | Multiple RTs (e.g., RT1, RT2) exist for related VITs | Each RT transitions to Closed–Cancelled |
| Resolved → Open | If a resolved VIT reopens and the previously associated RT was assigned to a user | Resolved → Under Investigation |
| Resolved → Open | If a resolved VIT reopens and the previously associated RT was unassigned to a user | Resolved → Open |
Roll-down behavior
When the state of a remediation task changes, the state is often propagated to the associated VITs unless overridden by manual updates or specific exceptions. The following table summarizes key roll-down scenarios where changes in remediation task (RT) state may affect the associated vulnerable item (VIT) state, based on precedence rules and special conditions.
| RT State | Condition | VIT State |
|---|---|---|
| Open → Under Investigation / In Review / Closed–False Positive | RT transitions to a non-final or non-actionable state | Mirrors RT state change (Open → <same state as RT>) |
| Open → Deferred (Sub-state: Reason Given) | RT deferred with a specified reason | Open → Deferred (Sub-state: Reason Given) |
| Open → Resolved | RT marked as resolved | Open → Resolved |
| Open → Closed–Cancelled / Closed–Fixed with Exceptions | RT closed without full resolution | Remains Open |
| RT1: Open → Under Investigation; RT2: Open | One RT moves to Under Investigation while another remains Open | Open → Under Investigation |
| RT1: Open → Under Investigation → Awaiting Implementation; RT2: Under Investigation | One RT progresses to Awaiting Implementation | Open → Under Investigation → Awaiting Implementation |
| RT1: Awaiting Implementation → Deferred; RT2: Awaiting Implementation | One RT deferred while another remains Awaiting Implementation | Awaiting Implementation → Deferred |
| RT1: Awaiting Implementation → Closed–Cancelled; RT2: Under Investigation | One RT cancelled while another is Under Investigation | Awaiting Implementation → Under Investigation |
| Open → Closed–Fixed with Exceptions | Mixed outcome: one VIT closed as fixed with exceptions, another remains open | VIT1: Open → Closed–Fixed; VIT2: Remains Open |
| Open → Resolved | Mixed outcome—one VIT closed as fixed and another resolved | VIT1: Open → Closed–Fixed; VIT2: Open → Resolved |
| Resolved → Open | RT reopens after resolution | VIT2 reopens; VIT1 remains Resolved |