Tools to Manage Vulnerability Response

This domain is about the operational machinery that turns a flood of VIs into prioritized, assigned, time-bound work, plus the escape valves (exceptions, false positives).

Remediation task rules and assignment rules

• Remediation Task Rules (historically "Vulnerability Group Rules") define the criteria by which vulnerable items are automatically gathered into remediation tasks, so analysts do not hand-assign each VI. Conditions can be based on the vulnerability, on VI attributes, or on a filter/condition group. Example: "group all VIs for CVEs of High severity on Windows servers."
• Assignment Rules determine who (which assignment group) gets a vulnerable item; the base rule, Assign to CI support group, uses the CI's support group. Remediation task rules then use the VIs' assignment group for the remediation task. Rules evaluate VIs on import, creation or reopen (or when reapplied), not continuously. Assignment can be driven by CI ownership, business service, location, or, in modern releases, Machine Learning assignment recommendations. There are specific assignment-rule variants for service support.
• Manual addition is still possible: an analyst can manually add a VI to a remediation task and view ungrouped VIs.

Remediation target rules and SLAs

• Remediation Target Rules (a.k.a. "time-to-remediate" rules) set the due date by which a vulnerable item must be remediated, typically based on severity/risk. These rules compute the target date; they are not themselves the SLA.
• SLAs in VR are defined for remediation tasks (task SLAs show in the remediation task related lists). For vulnerable items, the docs point you to remediation target rules instead: the target rule sets each VI's due date and a daily job flags approaching or past target status. Distinguish clearly: VI deadline = remediation target rule; remediation task timer = SLA.
• Remediation target notifications can alert owners as deadlines approach or pass.

Risk and prioritization

• Vulnerability Calculators / Calculator Rules set the Risk Score on vulnerable items (rules evaluated in order, first match wins; only one active calculator per target field). The Risk Rating (Critical to None) is then derived from the Risk Score. The default calculator can be supplemented or replaced with custom risk calculator rules that define fields and weights. The risk score drives prioritization and, often, the chosen remediation target.
• Rollup Calculators aggregate VI-level risk up to the remediation-task and CI level.
• Severity mapping translates each scanner's native severity scale into a normalized ServiceNow severity, so Qualys/Tenable/Rapid7 ratings become comparable. A severity map is configurable per integration.
• Exploit signals (KEV, EPSS) can be fed into the risk calculation to elevate actively exploited CVEs.

States and lifecycle

Vulnerable items and remediation tasks move through defined states (Open, Under Investigation, Awaiting Implementation, In Review, Resolved and Closed, plus Deferred; Closed has substates such as Fixed, Stale and False Positive). The baseline rolls a remediation task's state down to its VIs and rolls VI closure up to the task. Auto-close logic closes VIs when the underlying detection stops being reported (the asset is clean on rescan), when the CI is retired, or when detections go stale. Auto-close rules are configurable. VI age is computed from first detection.

Exception handling, deferral, and false positives

This cluster is heavily testable:

• Deferral: an analyst can defer a vulnerable item or a remediation task for a period (you accept the risk temporarily). Deferred items can request an extension when the deferral window is about to expire.
• Exception Management: a more formal, approval-driven path. You configure approval rules, approval configurations, approval levels (multi-level approvals), and exception approvers. Exception requests can use a questionnaire / Smart Assessment to gather risk justification, and approval routing can run on either the legacy Workflow engine or Flow Designer (the docs explicitly contrast the two).
• False Positive: a separate path with its own approver role, for detections that are not actually true vulnerabilities. Distinguish false positive (it isn't real) from exception/deferral (it is real but we're accepting/postponing the risk).
• Exclusion Rules suppress whole categories of detections from creating VIs in the first place.

Personas and roles

VR uses persona-based, granular roles (e.g., vulnerability analyst, remediation owner, admin). Personas can be assigned through the Setup Assistant. Knowing that VR moved to granular roles layered under personas is a current-release point.