CIS-VR Study Guide — ServiceNow Certified Implementation Specialist: Vulnerability Response

ServiceNow, the ServiceNow logo, Now, and product names are trademarks of ServiceNow, Inc. This is an independent, original study aid produced for exam preparation. It is not affiliated with, authorized, endorsed, or sponsored by ServiceNow, Inc. All explanatory text below is written from scratch and grounded in publicly available official ServiceNow product documentation; no exam content or course material is reproduced.

How to use this guide

The CIS-VR exam has 45 scored questions over 90 minutes, using single-answer and multiple-select items. The blueprint divides the content into five domains with very uneven weighting. This guide is ordered by weight, heaviest first, so that your study time mirrors where the questions actually come from. Spend the most time on Getting Data Into Vulnerability Response (29%) and Tools to Manage Vulnerability Response (22%); these two domains alone are roughly half the exam.

A note on terminology drift: the official VR exam blueprint dates from an older release era (around 2018-2020), while the live product (current family releases such as Washington DC and Xanadu/Yokohama) has renamed several objects. The most important rename to internalize: what older material calls a "Vulnerability Group" is now called a "Remediation Task" in the product UI and data model. Both names appear below; the underlying table is still sn_vul_vulnerable_item_group historically, surfaced as remediation tasks. Where the exam likely tests the older label, this guide flags it.

Domain 2 — Getting Data Into Vulnerability Response (29%)

This is the single largest domain. It is about how external scanner and feed data lands in the platform, becomes meaningful records, and is matched to the right configuration items.

Core record types

Three record types form the spine of VR. Keeping them straight is the most testable single concept in this domain:

Vulnerability (Vulnerability Entry): the abstract definition of a weakness — for example a specific CVE. These live in the Third-Party Vulnerability Entries table (third-party entries are scanner-vendor-defined, such as a Qualys QID) and the National Vulnerability Database (NVD) Entries table (the authoritative CVE library). A vulnerability is not tied to any one host; it is the catalog definition.
Vulnerable Item (VI): the intersection of one vulnerability with one configuration item (CI). A VI is "CVE-X is present on Server-Y." This is the unit of remediation work. Every VI created by an integration is the join of a detection (what the scanner reported) and a CI (what it maps to in CMDB).
Remediation Task (historically "Vulnerability Group"): a grouping of many vulnerable items so they can be triaged, assigned, and worked in bulk rather than one VI at a time. Grouping is driven by rules (see Domain 3), not manual effort, although manual addition is possible.

A useful mental model: a vulnerability is a kind of problem; a vulnerable item is an instance of that problem on a specific asset; a remediation task is a batch of instances handled together.

Scanner integrations: Qualys, Tenable, Rapid7

VR ingests detection data from third-party scanners through dedicated integration applications installed from the ServiceNow Store and configured (in current releases) through the Setup Assistant. The three you must know cold:

Qualys Vulnerability Integration — pulls QIDs and host detections from the Qualys Cloud Platform. Qualys vulnerabilities are identified by QID; these become third-party vulnerability entries.
Tenable Vulnerability Integration — supports Tenable.io (cloud), Tenable.sc (on-prem), and Tenable.cs (container/cloud security). Each Tenable product has its own connector flavor and supported-records list.
Rapid7 Vulnerability Integration — supports both the InsightVM cloud API and the Rapid7 data warehouse path.

All three rely on IntegrationHub / REST messages to call the vendor API, an import/transform layer to land raw data, and scheduled integration runs that you can monitor through integration-run (VINTRUN) records and run-status dashboards. You can also trigger a manual import and, for several scanners, initiate a rescan from within ServiceNow.

Key shared behaviors to remember:

Each integration creates vulnerable item detections — the per-scan evidence records — which roll up into vulnerable items.
The vulnerable item key controls deduplication: it defines what combination of fields makes two detections "the same" VI. You can configure the key (and, for Rapid7, add "proof" to it).
Detections from multiple scanners can be correlated/deduplicated so the same real-world weakness on the same host is not counted twice.
Imports can be domain-separated for MSP/multi-tenant deployments; a user in the target domain runs the integration.

NVD and other enrichment feeds

NVD (NIST National Vulnerability Database) integration imports the authoritative CVE library and CWE (Common Weakness Enumeration) records on a scheduled job. NVD entries provide CVSS base scores and descriptions that enrich the scanner-supplied third-party entries. Scanner QIDs are linked to CVEs so that one NVD entry can relate to many third-party entries.
CWE records categorize weakness types; a scheduled job keeps them current.
Exploit enrichment feeds raise the real-world urgency of a vulnerability beyond its static CVSS score:
- CISA KEV (Known Exploited Vulnerabilities) integration flags CVEs that CISA confirms are being actively exploited in the wild — a strong signal to prioritize.
- EPSS (Exploit Prediction Scoring System) integration adds a probability that a CVE will be exploited; EPSS score can be wired into the risk calculator business rule.
- Shodan Exploit integration correlates exploit availability/exposure data.
You can add CVEs to third-party entries manually so that vendor entries lacking a CVE mapping become enriched.

CMDB matching: CI lookup rules, reconciliation, and unmatched CIs

When a detection arrives, VR must decide which CI it belongs to. This is where exam questions concentrate inside this domain.

CI Lookup Rules (a SecOps-common construct) define, in priority order, how an incoming detection's host identifiers (IP, DNS name, MAC, NetBIOS, hostname, cloud instance ID, etc.) are matched to an existing CI in the CMDB. Rules run in sequence; the first match wins.
Detections that match become vulnerable items tied to the right CI. Detections that do not match any CI are held as Unmatched CIs / Discovered Items rather than silently dropped. An analyst can view, reclassify, and reconcile these.
VR can create CIs for genuinely new assets using the Identification and Reconciliation Engine (IRE) — the same CMDB engine that enforces identifier rules and reconciliation rules so duplicate CIs are not created and the authoritative data source wins on each attribute.
Housekeeping options: ignore CI classes, filter decommissioned CIs, auto-promote CIs, reapply CI lookup rules on selected discovered items, and de-duplicate existing CIs. Knowing that lookup rules can be reapplied (not just applied once at import) is a common test point.
Unclassed hardware can be reclassified into the proper CMDB class.

Manual ingestion

Beyond automated integrations, VR supports manual ingestion of vulnerabilities (via a provided template), manual creation of vulnerable items, and the generic framework to define a brand-new custom vulnerability integration (single-call vs. multiple-call patterns, report processor strategies, integration factory scripts).

Domain 3 — Tools to Manage Vulnerability Response (22%)

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.

Domain 1 — Vulnerability Response Applications and Modules (20%)

Foundational orientation: what VR is, how it installs, and how it sits inside Security Operations (SecOps).

Vulnerability Response is part of the Security Operations product family, alongside Security Incident Response (SIR), Configuration Compliance, and Threat Intelligence. VR shares SecOps-common components (CI lookup rules, calculators) with its siblings.
VR is delivered as a Store application with dependent plugins/components, installed and then configured through the Setup Assistant, which walks an implementer through enabling features, assigning persona roles, and configuring integrations.
Companion applications you should recognize:
- Configuration Compliance — tests CIs against policy (e.g., CIS/SCAP benchmarks); shares the SecOps-common plumbing with VR.
- Container Vulnerability Response (CVR) — extends VR to container images.
- Application Vulnerability Response (AVR) — for application-layer findings.
- Vulnerability Solution Management (VSM) — maps vulnerabilities to vendor solutions/patches (Microsoft MSRC, Red Hat, Rapid7 solutions) so remediation knows what fix to apply.
CMDB is a hard dependency: VR cannot meaningfully match detections without configuration items. Performance Analytics powers the dashboards (Domain 5).
Core navigation surfaces: the Vulnerability Response application menu, the Vulnerability Manager / Vulnerability Analyst Workspace, and homepages/dashboards. Records live in tables prefixed sn_vul_*.

Domain 4 — Automating Vulnerability Response (20%)

This domain covers reducing manual toil through orchestration, flows, and integrations to downstream systems.

Flow Designer & IntegrationHub are the modern automation engines. VR ships flows/subflows for tasks like creating scan records, triggering scans, routing exception approvals, and creating downstream tickets. Older material references Vulnerability Response Orchestration workflows/activities (e.g., "Scan vulnerability" workflow); current releases increasingly favor Flow Designer. Expect questions that contrast workflow vs. flow.
Change Management integration: remediation can generate Change Requests so that patching follows the organization's change process (CAB approval, scheduling). VR integrates with ITSM Change so a remediation task can spawn a change record and track its state back.
CMDB integration is automated end-to-end: detections auto-match via CI lookup rules, IRE auto-creates/reconciles CIs, and retired-CI logic auto-closes related VIs.
Patch Orchestration: integrations such as Microsoft SCCM, HCL BigFix, and others let VR drive actual patch deployment and read patch state back, so a vulnerable item can move toward closure automatically once the patch lands.
Solution Management automation: VSM pulls vendor solution data (MSRC, Red Hat via CSAF, Cisco via CVRF, Rapid7) so remediation tasks are pre-populated with the fix.
Agile/ticketing integration: the Jira integration can auto-create and synchronize Jira issues from vulnerable items for dev-owned remediation, on a scheduler.
Automated triage / auto-assignment / ML: rules and ML models can triage and assign VIs without human routing. Auto-close, auto-promote, and bulk-edit actions also reduce manual work.

Domain 5 — Vulnerability Response Data Visualization (9%)

Smallest domain, but easy points if you know the surfaces.

Performance Analytics (PA) for Vulnerability Response is a separately installed/configured content pack providing indicators (KPIs) and dashboards that trend remediation progress, open VI counts, overdue items, SLA attainment, and risk over time. PA enables historical/trend reporting, versus list/report views which show point-in-time data.
Dashboards & homepages: out-of-box VR dashboards visualize the security posture — open vs. closed VIs, aging, top vulnerabilities, exposure by business service. You can add vulnerability significance charts to the homepage.
Security posture / exposure views: reporting can be sliced by service classification and business service so leadership sees exposure where it matters.
Roles gate who can see/build PA content (PA viewer/admin roles plus VR roles).
Reports and dashboards are also used operationally to monitor integration run status and import health.

Fast-recall cheat list

Vulnerability = the definition (CVE / scanner QID). Vulnerable Item (VI) = one vulnerability on one CI. Remediation Task = a group of VIs (older name: Vulnerability Group).
Three scanners to know: Qualys (QID, Cloud Platform), Tenable (.io / .sc / .cs), Rapid7 (InsightVM / data warehouse).
NVD = authoritative CVE library + CVSS base; CWE = weakness categories; both on scheduled jobs.
Exploit enrichment: CISA KEV (actively exploited), EPSS (exploit probability), Shodan (exposure). KEV/EPSS can feed the risk calculator.
CI Lookup Rules match detections → CIs in priority order, first match wins; non-matches become Unmatched CIs / Discovered Items. IRE creates/reconciles CIs and prevents duplicates. Lookup rules can be reapplied.
Vulnerable item key controls deduplication; multi-scanner detections can be correlated/deduplicated.
Remediation Task Rules auto-group VIs (by vulnerability / VI condition / filter). Assignment Rules set the owner (CI-based or ML).
Remediation Target Rules = set the due date; SLAs = measure whether you met it. Don't conflate them.
Vulnerability Calculators / Risk Calculator Rules compute risk (fields + weights); Rollup Calculators aggregate up; Severity mapping normalizes scanner severities.
Three "don't fix now" paths: Deferral (real, postpone, can extend), Exception (formal, approval rules/levels/approvers, Smart Assessment questionnaire, Flow vs. Workflow), False Positive (not real, own approver). Exclusion rules stop VIs being created at all.
Auto-close triggers: clean rescan, retired CI, stale detection. VI age = from first detection.
VR is a Store app in Security Operations, configured via Setup Assistant, with granular persona roles; siblings: SIR, Configuration Compliance, Container VR, App VR, VSM.
Change Management integration spawns Change Requests for patching; Patch Orchestration (SCCM, BigFix) deploys/reads patch state; Jira integration for dev remediation.
Flow Designer / IntegrationHub = modern automation; older VR Orchestration workflows still referenced.
Performance Analytics for VR = trends/indicators/dashboards; PA gives historical posture, lists give point-in-time.

Always validate object names against the documentation for the specific release your project or exam targets — several VR objects (notably Vulnerability Group → Remediation Task) have been renamed across releases.