SecurityInsight documentation · Verified against SecurityInsight 3.0.79 on Nov 9, 2026

Handling records and states

This page tells your importer what to do with every record SecurityInsight sends, for every action and every state. The columns are on ServiceNow staging tables and columns; the rules every target shares are on The SecurityInsight data contract.

Rules for every record

1. Import only complete batches. Act on the rows of a batch only when its complete row exists (see Knowing when a sync is complete). Never import a test batch.
2. A missing row is never a deletion. SecurityInsight never asks you to delete anything. A record changes only on a row that says so: u_action on the push, u_si_state, u_state and u_close_reason in the hand-off database.
3. Every row stands alone. Coalesce on the keys, so a row sent twice updates the same record and never creates a second one.
4. held means change nothing. SecurityInsight cannot confirm or close the record in this batch; u_si_reason says why.
5. Only Remediated is a fix. Map every other close reason to a close code that is not “fixed”.
6. Clear only what is listed. An empty column listed in u_si_cleared is cleared; any other empty column is unknown: keep your value.
7. Touch only what SecurityInsight sent. Skip a vulnerable item whose u_source is not SecurityInsight, and let your reconciliation rules decide which CI attributes SecurityInsight may set.

The actions on the push

Every sync sends the full scoped state of each output, one row per record, each with u_action. The action comes from what the record is in SecurityInsight now and what your instance last received for it in a complete batch:

The full table of the action per case is on The SecurityInsight data contract.

Configuration items

CI decision table

In the hand-off database there is no u_action: the row’s u_si_state is the state, and u_changed_at moves when it changes. An asset-keyed row there (u_id_source = asset) creates nothing: the key changes once when the identity ledger mints the CI’s id, and the row arrives again with ledger.

CI states

The CI’s lifecycle in SecurityInsight (u_si_state):

               seen again                         seen again
        +--------------------+          +---------------------------+
        v                    |          v                           |
   +--------+   not seen for     +----------+   not seen past the   +---------+
   | active | -----------------> | not-seen | --------------------> | retired |
   +--------+   the seen window  +----------+   grace period, or    +---------+
        |       (default 8 days)                 an Admin retires        ^
        |                                                                |
        +----------------------- an Admin retires early -----------------+

• Seen window: CI seen-window, 8 days by default.
• Grace period: 30 days by default, set per kind on Configuration > Settings (Days before an unseen asset is retired: client PCs, servers, service principals, users, Azure virtual machines, other Azure resources).
• A kind of asset whose source could not be read in a run is frozen: none of its CIs changes state in that run.

What your CMDB holds for a CI, by the push’s actions:

   (no record) --new--> [ active / not-seen ] --close--> [ retired ]
                          ^   |   ^                          |
                          |   |   +--------reopen------------+
                          |   |        (seen again)
                          |   | out_of_scope (once)
                          |   v
                          +- [ out of scope ]
                 reopen (back in scope)

   update and held keep the CI where it is. A CI that leaves SecurityInsight's
   data gets one held row, then no more rows; your CI stays as it is.

Vulnerable items

Decision table on the push

Decision table in the hand-off database

Vulnerable item states

                    finding first reported
                              |  new
                              v
                         +--------+   update: still reported
              +--------> |  Open  | <----+
              |          +--------+      |
   reopen:    |            |   |  |      | held: absence still counting,
   reported   |  close:    |   |  +------+ CI not delivered, report incomplete,
   again, or  |  absent    |   |           disabled, or left SI's data (once)
   back in    |  enough    |   |
   scope      |  complete  |   | out_of_scope (once):
              |  runs, or  |   | Closed, reason Out of scope
              |  a reason  v   v
              |       +--------+
              +------ | Closed |  with u_close_reason
                      +--------+

Close reasons

When SecurityInsight closes

1. Remediated needs all of: a complete run; the asset seen in this run with its own data; and the finding absent for Runs before a vulnerability closes complete runs in a row (default 2). While the count runs, the item is held (u_si_reason: absent N complete run(s)).
2. AssetRetired when the CI is retired.
3. Out of scope, Linked and Duplicate at once, because the finding is still reported.
4. An incomplete run closes nothing. A report that could not complete in the newest run holds its findings.
5. The SQL vulnerability connector’s safety limits. An empty result closes nothing. When fewer than half of the open records are still reported (Vulnerabilities: share that must still be reported, 0.5), nothing closes. When the closes would be more than 10% of the open records (Vulnerability close limit (% of open records); Vulnerability close limit (number of records), 0 = no number limit), they are held for an Admin to release once on Operations > Guards (safety checks). Closes a fresh Defender assessment corroborates, out-of-scope, linked and retired-asset closes are not counted by the limit.

SecurityInsight never closes a record because your instance says it is closed.

What held means

A held row asks you to change nothing. On the push it arrives with u_action = held; in the hand-off database the record stays as it is. Why a record is held, and until when:

The SQL vulnerability connector (hand-off database) also holds a record while the asset was not seen in this run, while the CI is not-seen, while the collection scope leaves the asset out, while every source of the asset failed, while a twin record waits for its re-key, and while a run is halted by a safety limit.

Tags

Hand-off database only.

Tag decision table

A tag’s row is identified by u_si_correlation_id, u_source and u_key.

Tag states

   (none) --- tag found ---> +---------+   gone from the source    +---------+
                             | present | ------------------------> | removed |
                             +---------+ <------------------------ +---------+
                                           back in the source

Relations

Hand-off database only.

Relation decision table

Relation states

   (none) --- in the VM's    +---------+   gone from the VM's      +---------+
              properties --> | present | ------------------------> | removed |
                             +---------+ <------------------------ +---------+
                                           back on the VM

Proposed CIs

Hand-off database only.

Proposed CI decision table

The proposed CIs are a report. SecurityInsight creates nothing from it, and an importer never needs to read it.

Proposed CI states

   asset no CMDB CI is known to match
                 |
                 v
          +-----------+   a CMDB CI matches   +-----------------+
          | unmatched | --------------------> | not in the      |
          | / unknown |                       | report          |
          +-----------+                       +-----------------+

   u_id_source asset -> ledger: the row's key changes once, when the
   identity ledger mints the CI's id.

Change, hash and duplicates

The row hash

u_row_hash is a fingerprint of a row’s content. Keep it on the record (for example in a field u_si_row_hash) and skip a row whose hash equals the one you keep. On the push, every record arrives every sync, so without this check your transform touches every record on every sync; u_row_hash there covers every content column, u_last_seen included, and never the action, the batch or the run. Skip only update rows on the hash; never skip a close, reopen or out_of_scope row. In the hand-off database, the CI hash covers the identifiers, tier, tier reason, criticality, exposure, data sensitivity, asset type and evidence, not u_last_seen; a hand-off database of your own also hashes the owner and the department. Compare hashes within one route only.

Re-sent rows

Every row can arrive more than once: every sync sends the full state, a failed call is tried again, and the rows of a batch that did not complete go again in the next batch. Coalescing on the keys makes this safe.

Duplicates

• CIs: one row per CI key per batch.
• Vulnerable items: one row per CI and finding per batch. When a finding had two records, SecurityInsight keeps the older one and closes the other as Duplicate.

Order inside a sync

• The CI batch is sent before the vulnerable item batch. A vulnerable item whose CI is not delivered in a complete batch is held (see What held means).
• Rows go in calls of 200, one after the other. Each call is one import set; ServiceNow transforms them asynchronously by default, so do not rely on the order in which import sets transform. Wait for the complete row, then import the batch.

Verified against SecurityInsight 3.0.0.202610261957 on 2026-10-27.

Verified against SecurityInsight 3.0.79 on Nov 9, 2026Download PDF

← ServiceNow staging tables and columnsKnowing when a sync is complete →