🌉 IIQ → ServiceNow CMDB Access Bridge

A nightly integration that lights up every ServiceNow Configuration Item with the SailPoint IdentityIQ access surface behind it — turning the CMDB into a single pane where IT Asset, SecOps, and Audit can ask "who has access to this CI?" without leaving ServiceNow.

Date

2026-05-11

Type

Integration

Theme

Identify (primary, NIST CSF) + Observability (secondary)

The IIQ problem this addresses

ServiceNow CMDB is the authoritative catalogue of Configuration Items (CIs) in most enterprises — every application, server, database, business service, and SaaS platform lives there with an owner, a criticality, a lifecycle stage, and a sys_id. SailPoint IdentityIQ, in parallel, is the authoritative catalogue of who has what access — 50k+ identities, 500+ Applications, millions of Links and Entitlements, all keyed to the same underlying systems.

These two systems have no formal connection in a typical IIQ deployment. The consequences show up every week:

1. Asset reviews don't know about access. When the Asset team flags a CI as approaching End-of-Life, they have no native view of "who needs to be off this thing before we cut it." That list lives in IIQ and has to be pulled by hand each time.
2. SecOps loses identity context. When a ServiceNow Security Incident is opened against a CI (say, "SAP HR Production"), the responding analyst has no in-pane answer to "which 47 humans have privileged access to this CI right now?" They open IIQ, search for the Application, sort entitlements, take a screenshot, paste it into the ticket — every time.
3. Audit assembles the same evidence over and over. SOX, HIPAA, PCI, and ISO 27001 access-review controls all ask the same shape of question: "for this critical system, here is the population that had access during the audit window." That answer is a join across two tools the auditor doesn't have access to, fronted by a human who does.
4. CI criticality never reaches IIQ. A SOX-significant CI looks identical to a sandbox CI from inside IIQ. Risk scoring, certification cadence, and SOD policy could all benefit from knowing "this Application maps to a Tier-1 CI" — but the mapping isn't there.

The fix is a one-way push: IIQ knows the access; the CMDB needs to see it inline.

What this integration does

iiq-cmdb-access-bridge is a one-way, post-aggregation bridge from IIQ to ServiceNow that hydrates a custom CMDB extension table — u_cmdb_access_snapshot — with the current access surface for every CI that has a mapped IIQ Application.

Each night, after the daily aggregation cycle completes:

1. An IIQ Workflow (CMDB-Access-Bridge) fires as a post-aggregation TaskCompletion subscription.
2. It assembles a payload by iterating every IIQ Application that has an extendedAttribute named cmdbCiSysId (the operator maps Applications to CIs as a one-time exercise). For each such Application, it pulls every active Link, the Link's owning Identity, and the Link's Entitlements (filtered to those marked privileged=true in the Entitlement Catalog by default; full-fidelity mode includes all entitlements).
3. It batches the payload into chunks of ≤ 500 rows and PATCHes them at /api/now/table/u_cmdb_access_snapshot on a configurable ServiceNow instance.
4. It uses idempotent upserts keyed on (u_cmdb_ci, u_identity_sys_user, u_entitlement_name) — re-runs overwrite the u_last_seen and u_status fields but never duplicate rows.
5. It tombstones missing rows. Any row whose composite key is in CMDB but absent from the latest payload for that Application is patched to u_status="revoked" with u_revoked_at=now() — never deleted, so audit history persists.
6. It writes a TaskResult back into IIQ summarizing payload size, HTTP outcomes per batch, and any rows the bridge skipped (uncorrelated accounts, service accounts, etc.).
7. It dead-letters failures. Any 4xx/5xx response or schema mismatch goes to a local JSON file under /var/iiq/cmdb-bridge/dlq/ for replay; the bridge never blocks on transient ServiceNow errors.

The integration is read-only on the IIQ side and write-only on the ServiceNow side — no provisioning, no certification, no decision-making. It is a projection.

Why this matters (the business case)

NIST CSF mapping

• ID.AM-2 — Software platforms and applications within the organization are inventoried. The bridge makes the CMDB's software inventory access-aware without merging the two systems.
• ID.AM-5 — Resources are prioritized based on classification, criticality, and business value. By landing IAM access on the CMDB row, every existing CMDB-side criticality field now has an identity dimension.
• ID.AM-6 — Cybersecurity roles and responsibilities for the entire workforce and third-party stakeholders are established. The bridge surfaces who holds each access role for each CI.
• ID.RA-1 — Asset vulnerabilities are identified and documented. Joining CMDB vulnerability data to identity access on a CI gives a clean lateral-risk view (a known-vulnerable CI plus its privileged-access list = the actual blast radius).
• DE.CM-3 — Personnel activity is monitored to detect potential cybersecurity events. The snapshot stream gives SOC analytics a daily "who has access to what CI" baseline; deltas become detection signals.

Run it locally (no IIQ or ServiceNow required)

This idea folder ships as a specification, not a runnable build. Everything you need to evaluate the design is in:

• integration-spec.md — the contract: auth, endpoints, payload shapes, error model, retries, security posture, deployment notes.
• sequence.md — the end-to-end sequence diagram (Mermaid), call-by-call narrative, and timing assumptions.
• sample-request.json — a realistic, fully-populated example batch (12 rows across 3 CIs) ready to POST/PATCH against a ServiceNow dev instance.
• sample-response.json — the matching ServiceNow Table API response with mixed success / partial-failure rows so the error-handling path is exercised.

To smoke-test against a ServiceNow PDI:

# Replace <instance>, <user>, <pass> with your ServiceNow developer instance creds.
curl -X POST "https://<instance>.service-now.com/api/now/table/u_cmdb_access_snapshot" \
     -u "<user>:<pass>" \
     -H "Content-Type: application/json" \
     -H "Accept: application/json" \
     --data-binary @sample-request.json

The CMDB-side schema for u_cmdb_access_snapshot is documented in integration-spec.md §3.

What's intentionally out of scope

• Bi-directional sync. This bridge is one-way (IIQ → ServiceNow). A future companion can read CMDB criticality and project it back as an IIQ Application attribute; the schema accommodates it but the workflow doesn't yet.
• Provisioning. Discovering an out-of-policy access on a CI is the bridge's job; revoking it is not. The remediation flow stays in IIQ's certification + provisioning engines, where it belongs.
• Discovery / CI creation. The bridge does not create CIs in CMDB. If cmdbCiSysId is unmapped on an Application, the bridge logs and skips. Mapping is a one-time human decision.
• Real-time event streaming. This is a nightly batch, intentional. A future "delta on aggregation completion per Application" mode is a small extension once the schema is stable.
• Replacing IIQ's own search. Operators still go to IIQ for the deep view (certification history, role composition, request lineage). The CMDB view is the quick view.

Files in this folder

Sources

• Local: My-Library/Apps/IAM-Ideas/Resources/IIQ_Documentation/8.4/8.4 Connector and Integration Guides/SailPoint ServiceNow Identity Governance Connector Guide.pdf — ServiceNow connector model, REST endpoints, OAuth flow.
• Local: My-Library/Apps/IAM-Ideas/Resources/IIQ_Repo_V8.4/WEB-INF/config/integration.xml — canonical IntegrationConfig object shape (TraceExecutor, WebServiceIntegrationExecutor).
• Local: My-Library/Apps/IAM-Ideas/Resources/IIQ_Repo_V8.4/WEB-INF/config/HPServiceManagerIntegrationConfigForRequest.xml — reference for IntegrationConfig-with-Velocity-template style payload assembly used here.
• Local: My-Library/Apps/IAM-Ideas/Resources/IIQ_Repo_V8.4/WEB-INF/config/connector/ServiceNow.xml — reference for the IIQ-side ServiceNow Application config shape (auth, instance URL, mid-server name).
• ServiceNow Now Platform — Table API reference and cmdb_ci schema (operator-known, not reproduced here).