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

The SecurityInsight data contract

SecurityInsight hands its data to other systems under one contract: the same keys, the same values, the same batch states and the same rule for when a reader may act. This page is the contract. It applies to every data-out target:

The ServiceNow pages describe the ServiceNow side in detail: ServiceNow integration overview, ServiceNow staging tables and columns, Handling records and states and Knowing when a sync is complete.

The rule

Act only on rows of a complete batch. A batch is writing while SecurityInsight writes it, then complete, failed or held. Import a complete batch once; never import a writing, failed or held batch, and never a batch in mode test.

                     +--> complete   import it, once
                     |
   writing  ---------+--> failed     do not import; the rows go again
                     |
                     +--> held       do not import; nothing changes

Each batch moves one way. A batch id never comes back. There is never more than one writing batch per output: when a sync starts and finds a batch of the same output still writing, it ends that batch as failed with the reason a later sync started while this batch was still writing, and the rows of that batch go again in the new one.

How each target makes a batch:

snowstage.vImportBatch in SecurityInsight’s own database lists the batches of the CI hand-off and of both SQL connectors, with the same words as the staging status table: u_si_batch_id, u_output (servicenow-ci for the CI hand-off (u_connector = cmdb-handoff) and the CMDB SQL connector, servicenow-vulnerable-item for the SQL vulnerability connector), u_state, u_started_at, u_finished_at, u_batch_time, u_reason, u_si_contract_version, u_si_mode, the counts per action and u_landed_rows.

The reader rule for the SQL vulnerability connector: read snowstage.vImportVulnerableItem, and act on a row only when its u_si_batch_id is a complete batch in snowstage.vImportBatch. Skip the other rows; the next complete batch carries them. A record the newest run did not write keeps the id of the batch that last wrote it, which is complete.

The reader rule for the SecurityInsight database’s CI views (snowstage.vImportCi) is the same: act on a row only when its u_si_batch_id is a complete batch in snowstage.vImportBatch. Each run writes the views as one batch of its own, <run id>:cmdb-handoff: while it writes, the rows it has written carry that batch’s id and the batch is writing, so you skip them; the rows it has not reached yet still carry the id of the complete batch before. A row the newest run did not write keeps the id of the complete batch that last wrote it.

The contract version

Every batch carries u_si_contract_version (SQL: ContractVersion). The version is 1.

The rule for a version: columns and values are only ever added. Renaming or removing a column, or changing what a value means, comes with a new contract version. A reader that checks the version and ignores columns it does not know keeps working when a column is added.

Keys

Coalesce on the key. A row sent twice then updates the same record and never makes a second one.

The columns on every pushed row

Every row of both ServiceNow push outputs carries these columns, whatever else an admin changes in the output’s columns:

The columns on every database row

The hand-off databases carry the same contract on their import views. Each column is added after the columns a view already had, so an existing data source and transform map keep reading what they read before:

u_action on a database row is the record’s action in the batch that last wrote it:

u_si_cleared follows the same rule as on a pushed row (below), over the same clearable columns. A held vulnerable item carries no clear marker.

Every sync sends the full state

Every sync of a ServiceNow push output sends the full current scoped state of that output, as one batch: every CI in scope, every vulnerable item in scope, open and closed, each with its u_action. The CI output runs before the vulnerable item output.

The action of each record comes from what the record is in SecurityInsight now, and what your instance last received for it in a complete batch (the base):

What the rules mean:

• A missing row is never a deletion. SecurityInsight never deletes a record, and closes one only on a close row.
• Closes come only from complete runs. A finding closes as Remediated only after it was absent for the required number of complete runs in a row (default 2) on an asset SecurityInsight saw. While that count runs, the item is held.
• A scope never fixes anything. A vulnerable item that leaves the scope closes as Out of scope, once. It reopens when it comes back in scope.
• A record that leaves SecurityInsight’s data gets one held row with its last values, then no more rows. The record in your system stays as it is.
• A vulnerable item whose CI is not delivered in a complete batch (this one or an earlier one) is held, or not sent when your instance never had it, reason its CI is not delivered yet. When the CI output is switched off, this check is off and the run’s log says so.

One set of values

Only Remediated is a fix. Map every other close reason to a close code that is not “fixed”. The hand-off database, the ServiceNow push and the SQL vulnerability connector use the same values.

Clear or unknown

The Import Set API cannot tell an empty value from a value that was not sent, so the push leaves an empty value out of the row. u_si_cleared says which empty values are real:

The clearable columns:

SQL targets: SecurityInsight writes the whole row, so NULL on a row SecurityInsight wrote is the clear. A held record is not written.

Who wins

Re-keying

A device that is re-onboarded, or two records that turn out to be one asset, can give a CI a new key. Then:

1. The row under the new key carries u_si_replaces = the old key. For a vulnerable item: <old CI key>|<finding key>.
2. Your importer moves the record found by the old key to the new key (it does not create a second record).
3. A CI’s old key is never dropped: it keeps its own row on every run - u_si_state = retired, u_action = close, u_si_reason naming the CI that replaces it (merged into <id> (<name>) - the same machine; use that CI, or replaced by <id>). A vulnerable item’s old key gets no row of its own and leaves the state once the batch with u_si_replaces is complete.

Import every complete batch, oldest first: a re-key, an out_of_scope row and the held row of a record that left SecurityInsight’s data arrive once.

Scope

An admin sets what each target receives on Configuration > Connectors > Scope. The scope is applied when sending:

A scope that cannot be read fails the output: a scope set by an admin never silently becomes “everything”.

Full resync and test batch

On Configuration > Connectors > Setup, the card ServiceNow: one route offers two buttons. Each proposes the setting SI_DataOut_ServiceNowRequest on the settings page; an admin reviews and saves it there (change-logged). The next sync carries it out once.

A test batch needs the staging status table.

The import result, read back

At the start of each sync of an output, SecurityInsight reads ServiceNow’s own import result for its newest complete live or resync batch that has none yet (up to 3 days old): the import set rows of the batch’s import sets, counted per import state. It writes a feedback row to the staging status table with the same u_si_batch_id:

The integration user needs read access to sys_import_set_row for this. Without it, the run logs a warning and the batch is not affected. SQL connectors record the rows the batch wrote (LandedRows).

Field ownership

• SecurityInsight owns every u_si_* column and every column it fills in the staging rows. Which of them may change your records is your reconciliation rules’ decision: make SecurityInsight authoritative for its security attributes and the lowest-priority source for the rest.
• SecurityInsight only inserts staging rows. It never writes a cmdb_ci* or sn_vul* record, never deletes anything, and never touches a record it did not send.

Personal data

• Identity CIs and their vulnerable items carry the names and user principal names of Entra identities (u_name, u_asset_name) and their Entra object ids.
• An identity SecurityInsight no longer sees moves to not-seen and retired like any CI. Once it is no longer in SecurityInsight’s data, it gets one held row and then no more rows.
• SecurityInsight never deletes a staging row or a record. How long the import set rows are kept is yours: ServiceNow’s Import Set Deleter removes them (see Knowing when a sync is complete).

Volumes and limits

Example: 20,000 CIs and 150,000 vulnerable items in scope, one sync a day: about 170,000 data rows and 6 status rows a day; kept seven days, about 1.2 million import set rows.

Dates

Every date and time in every column is UTC, as yyyy-MM-dd HH:mm:ss: ServiceNow’s own date-time format, so a field map needs no date format. The SQL views give datetime2 values in UTC.

Verified against SecurityInsight 3.0.0.202610261957 on 2026-10-27.

Verified against SecurityInsight 3.0.79 on Nov 9, 2026Download PDF

← SecurityInsight 3 beside 2.2ServiceNow integration overview →