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 or owner) gets a vulnerable item or remediation task. 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 then measure performance against those targets and against task lifecycles. VR ships SLA definitions for remediation tasks and for vulnerable items. Distinguish clearly: the remediation target rule sets the deadline; the SLA tracks whether you hit it.
• Remediation target notifications can alert owners as deadlines approach or pass.

Risk and prioritization

• Vulnerability Calculators / Calculator Rules compute the risk rating on vulnerable items. 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 → In Review/Under Investigation → In Progress → Resolved/Closed, plus Deferred). 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.