Vulnerability Response remediation target rules
Summarize
Summary of Vulnerability Response remediation target rules
Remediation target rules in Vulnerability Response define the expected time frames for remediating vulnerable items (VIs), similar to SLAs for vulnerabilities themselves. These rules help vulnerability managers set deadlines based on criteria such as asset sensitivity or compliance requirements (e.g., PCI DSS mandates fixing vulnerabilities on PCI data assets within 30 days). The rules specify remediation and reminder targets, notification recipients, and how remediation dates are recalculated when risk ratings change.
Show less
Key Features
- Remediation and reminder targets: Define specific deadlines and notification schedules for vulnerable items.
- Notification recipients: Specify who receives alerts when items approach or exceed remediation deadlines.
- Recalculation methods: Administrators can configure how remediation target dates update when a VI’s risk rating changes, choosing from options to retain, update, or adjust to the earliest applicable date.
- Visual indicators: The remediation target date is color-coded on VI list views—green (no notification yet), orange (approaching target), red (past target)—for quick status recognition.
- Automated scheduled job: The “Evaluate remediation targets” job runs daily to apply or update remediation dates based on active rules, excluding VIs in Closed, Deferred, or Resolved states.
- Rule management: Rules can be deactivated or deleted; deactivation clears associated remediation dates, and deletion preserves dates on closed VIs but clears them on active ones.
- Handling multiple rules: When multiple remediation rules apply to a VI, the most restrictive (earliest) remediation target date is enforced.
- Reapplying rules: Changes to remediation target rules require reapplication across active VIs via an “Apply Changes” button, with concurrency considerations when scheduled jobs are running.
- Workspace efficiency: Vulnerability Manager Workspace provides a more efficient way to obtain updated remediation target dates for selected VIs than reapplying rules across all items.
Practical Implications for ServiceNow Customers
ServiceNow customers can use remediation target rules to enforce compliance and risk management policies by establishing clear remediation deadlines tailored to asset sensitivity and vulnerability risk. The rules enable proactive notification workflows to ensure responsible teams are alerted before remediation deadlines are missed. The ability to configure how remediation targets adjust when risk ratings change helps maintain realistic and risk-aligned remediation schedules.
Administrators should regularly review and update remediation target rules, use the daily evaluation job to maintain accurate remediation dates, and leverage the Vulnerability Manager Workspace for efficient remediation status tracking. Understanding how multiple rules interact and how to manage rule lifecycle (activation, deactivation, deletion) ensures that remediation targets remain accurate and actionable.
Remediation target rules define the expected time frame for remediating vulnerable items (VI), much like SLAs provide a time frame for remediating the vulnerability itself. For example, if an asset contains PCI data (credit card data) then the vulnerability on that item must be fixed within 30 days according to PCI DSS.
- The remediation target
- The reminder target
- The reminder and notification recipients: Who should be notified when the vulnerable items (VIs) are past the reminder or remediation target date and haven’t been remediated.
- The recalculation method: How the system updates the remediation target (RT) date when a vulnerable item’s risk rating changes.
Vulnerability analysts and managers can see the remediation target date in the vulnerability item form and list views, as long as the vulnerable items aren’t in Deferred, Resolved, or Closed state. Remediation target rules are run on import and rerun if a VI is reopened.
- Vulnerable items that haven’t reached their notification date are shown in green.
- Vulnerable items approaching the remediation target date are shown in orange.
- Vulnerable items past the remediation target date are shown in red.
A summary email, per remediation target rule, is sent when one or more VIs are either approaching their remediation target date or the remediation target date has passed.
Recalculation of remediation target date
Starting with Unified Security Exposure Management version 30.1.4 and Vulnerability Response version 26.4.4, administrators can configure how the system recalculates the remediation target date when a finding’s risk rating changes.
- Under normal conditions, the system calculates the RT date as:
Remediation Target = Target from (date) + Target (days)
- When the risk rating changes, the system calculates a new RT date using the formula below. The selected recalculation method determines whether this new date replaces the existing RT date.
Recalculated RT date = Field change time + Target (days)
Field change time captures when the risk rating changed. Target (days) uses SLA of new risk rating.
| Recalculation method | Description |
|---|---|
| Default calculation | Retains the existing RT date. The recalculated date isn’t applied. |
| Recalculate from risk change date | Updates the Remediation Target date to: Field change time + Target (days) based on the new risk rating. |
| Recalculate from risk change date and always set to earliest target date | Compares the existing RT date with Field change time + Target (days) and applies the earlier date. |
| Recalculate from risk change date and set to earliest target date only when risk rating increases | If the risk increases: Compares the existing RT date and the recalculated RT date and applies the earliest date. If the risk decreases: Applies Field change time + Target (days) without comparison. |
For configuration steps, see Recalculate a remediation target date.
Remediation target rules can be deactivated or deleted
When a rule is deactivated, the current remediation target dates for the VIs it was applied to are cleared. If a VI satisfies any active rule that rule is applied, otherwise the VI has no rule or target date, and its status is No Target.
When rules are deleted, the Remediation target date and related fields on closed, deferred, or resolved VIs are preserved. The Remediation target date and related fields on non-closed VIs are cleared and any dependent rules are reapplied.
Remediation target rule scenario
Starting from V17.1, remediation targets are calculated from the Target from (date). The default value remains Last opened date.
For example, if a vulnerable item meets the condition for two remediation target rules:
- Remediation target rule 1: Last opened on 03/07/2018; remediation target is 15 days since it was last opened; calculated remediation target date is 03/16/2018 10:00:00.
- Remediation target rule 2: Last opened on 03/10/2018; remediation target is 10 days since it was last opened; calculated remediation target date is 03/11/2018 10:00:00.
About the Evaluate remediation targets scheduled job
Evaluate remediation targets runs once at 4:00:00 daily.
- Aren’t in a Closed, Deferred, or Resolved state.
- Have no remediation target date.
- Have a remediation target date that is later than the date in the remediation target rule.
Evaluate remediation targets adds a remediation target date, if one doesn’t exist, or if a rule results in an earlier date than the one in the record, it updates the existing target date. Finally, it updates the Remediation target and Remediation status fields in the vulnerable item form.
Once the Evaluate remediation targets runs, available notifications are sent.
Evaluate remediation targets clears the remediation fields on the VI and stops sending notifications.
The sn_sec_cmn.evaluate_targetmissed_records property, when enabled, prevents the Remediation Target Rules scheduled job from evaluating missed VIs. This property is enabled by default.
Reapplying remediation target rules
If the scheduled job, Evaluate remediation targets is running, you can’t initiate a reapply process. However, if a reapply process is already running, and the scheduled job it triggered, they run in parallel.
The reapply processes in Vulnerability Response and Application Vulnerability Response are independent and can run in parallel.