Fides x ServiceNow — the compliance loop, proven

Two planes, one system of record.

Fides advises · ServiceNow decides.

Every build feeds ServiceNow on two planes at once — operational telemetry into ITOM, and evidence-backed risk verdicts into ITSM — over a governed, bi-directional MCP link. ServiceNow stays the system of record; Fides supplies the proof. This page shows the loop as it runs today, end to end, and the real-world scenarios it unlocks.

How the two systems connect

Fides is the evidence and provenance engine: it records trails, artifacts and attestations, and scores change risk against control coverage. ServiceNow is the system of record: Event Management, CMDB, Change and GRC — the decision and approval authority.

⛶ Fullscreen

flowchart LR
  subgraph F["Fides — evidence & provenance"]
    direction TB
    F1["Records trails, artifacts, attestations<br/>Scores change risk vs control coverage"]
  end
  subgraph SN["ServiceNow — system of record"]
    direction TB
    SN1["Event Management · CMDB · Change · GRC<br/>Decision & approval authority"]
  end

  F1 -->|"ITOM: build & scan events -> Event Mgmt"| SN1
  F1 -->|"ITOM: service CI create/update -> CMDB"| SN1
  F1 -->|"ITSM: change-gate verdict + 0-100 risk -> Change Request"| SN1
  F1 -->|"ITSM: HOLD -> ServiceNow Incident (INC)"| SN1
  SN1 -->|"ITSM: CAB approval -> unblocks the deploy"| F1
  SN1 -->|"ITSM: Now Assist evidence grounding (reads Fides)"| F1

  F1 <-.->|"Governed MCP (OAuth) — no backdoor"| SN1

  classDef fides fill:#f5e7cc,stroke:#c9903a,color:#152029
  classDef sn fill:#d2ece6,stroke:#2a9e88,color:#152029
  class F1 fides
  class SN1 sn

Bi-directional and governed. Fides reads CMDB CIs, change requests and GRC controls through ServiceNow’s native MCP server over OAuth — no backdoor. ServiceNow’s Now Assist reads back through Fides’ grounding endpoint. Neither side bypasses the other’s governance.

The compliance loop, proven end to end

This is the headline. A single commit flows from CI evidence, through a Fides change-gate that writes a verdict onto a ServiceNow Change Request, through two independent human approvals, to a deploy — and the portal shows the compliance frameworks moving to 48 of 48 controls passing, 0 failing.

⛶ Fullscreen

sequenceDiagram
  autonumber
  participant Dev as Developer
  participant CI as GitLab CI
  participant Fides as Fides (Evidence Vault)
  participant SN as ServiceNow
  participant Portal as SARC Portal

  Dev->>CI: Open MR, a 2nd human approves it
  Note over CI: peer_review evidence recorded
  CI->>Fides: attest sast/secret/dep/container/iac
  CI->>Fides: attest sbom, audit, rollback, sod, pull_request
  CI->>Fides: change-gate --trail <sha>
  Fides->>Fides: score risk 0-100 vs control coverage
  Fides->>SN: write verdict onto Change Request (CHG)
  alt evidence incomplete OR no human sign-off
    Fides->>SN: raise Incident (INC) — deploy blocked
    Fides-->>CI: recommendation = HOLD (exit 2)
  else evidence complete + human sign-off
    SN->>SN: CAB approves the CHG
    Fides-->>CI: recommendation = APPROVE
    CI->>CI: deploy to environment
  end
  Portal->>Fides: read trails + attestations
  Portal->>SN: read CHG approval by u_commit_sha
  Note over Portal: 48/48 controls · 0 fail

What each control family is satisfied by (the gates):

Gate family	Evidence source	System
sast, secret, dependency, container, iac	scanner jobs → Fides attestations	Fides
sbom	CycloneDX SBOM generator → Fides attestation	Fides
audit	fides attest provenance / in-toto	Fides
rollback	compliance:rollback-plan job (atomic Helm rollback)	Fides
sod	compliance:sod-check job (four-eyes)	Fides
peer_review	GitLab merge-request approval	GitLab → Portal
cr_approved	ServiceNow Change Request in Approved state	ServiceNow → Portal

The first nine are produced automatically by the pipeline. The last two are human sign-offs by design — a reviewer approves the merge request, and a CAB member approves the ServiceNow change. That is the segregation-of-duties control: no machine can self-approve its way to green.

Real-life scenarios

Concrete, end-to-end walkthroughs of what the integration does. Each one is something the platform performs today.

Scenario 1 — a compliant change ships to QA

1. A developer opens a merge request. A second engineer approves it in GitLab (four-eyes) — this is the peer_review evidence.
2. On merge, the pipeline builds, scans, and attests every result to Fides: SAST, secret, dependency, container, IaC, SBOM, plus audit / rollback / SoD / pull-request attestations.
3. fides change-gate scores the change (e.g. risk 35 / medium), checks it against the enforced controls, and writes the verdict onto a ServiceNow Change Request (e.g. CHG0032615), embedding the commit SHA, risk score, and evidence links.
4. A CAB member approves the Change Request in ServiceNow — the cr_approved evidence.
5. With peer review + CAB approval both present, the gate flips HOLD → APPROVE and the deploy proceeds.
6. The SARC portal reads the trail and the approved CR and shows the frameworks at 48/48, 0 fail — auditor-ready, in real time.

Scenario 2 — a non-compliant change is blocked (and everyone knows why)

1. A change reaches the QA gate without the required sign-off (or with a failed control).
2. The Fides change-gate returns recommendation=hold and the qa/prod promotion is hard-rejected by scripts/ci/promote.sh. (The per-push pipeline itself is advisory — enforcement is scoped to promotions, where a human signs off.)
3. Fides raises a ServiceNow Incident (e.g. INC0010235, urgency 2): “Non-compliant deploy blocked.” The block is now a tracked, assignable ITSM record — not a silent CI red X.
4. The verdict is also written onto the Change Request as HOLD with the missing-evidence list, so the reviewer sees exactly what’s missing (“Change approval (PR + sign-off): missing approval”).
5. The developer fixes the gap (gets the review, completes the evidence), re-runs, and the gate clears. The incident closes.

Scenario 3 — an auditor asks “prove SOC 2 CC6.6 is met”

1. Open the portal’s Compliance view. Every framework (SOC 2, ISO 27001, PCI-DSS, PSD2, NIST 800-53, SOX, DORA) shows per-control pass / fail / skipped.
2. Drill into a control. It maps to a pipeline gate, which resolves against the deployment trail’s evidence — the exact attestations and the approved Change Request that satisfy it.
3. For cr_approved controls, the portal shows the ServiceNow CR number, approver, and timestamp — joined to the deployed commit by u_commit_sha.
4. Export the evidence pack (/compliance/evidence) — a time-boxed, control-by- control bundle an external auditor can read without touching the pipeline.

Scenario 4 — operations sees the delivery as it happens (ITOM)

1. Every build and scan event flows into ServiceNow Event Management; the service’s CMDB CI is created or updated automatically — no manual updates.
2. When a change is blocked, the Incident correlates to the affected service CI, so on-call sees the impact in the same place they triage everything else.
3. Now Assist, asked “is this change safe to approve?”, answers grounded on Fides evidence — coverage, attestations, risk score — without the approver leaving ServiceNow.

Feature catalogue — what you’re showing off

Fides (Evidence Vault)

• Trails + artifacts — every build is a trail keyed by commit SHA; artifacts keyed by SHA-256 digest.
• 12+ attestation types — sast, secret-detection, dependency, container, IaC, k8s-manifest, SBOM (CycloneDX), audit/provenance, rollback, SoD, pull_request, approval — each chained into a tamper-evident hash chain.
• Change-gate — turns evidence + control coverage into an approve/hold verdict + 0-100 risk score; refuses to approve without a human session approver (SoD enforced server-side).
• Control coverage — adopt a framework, enforce its controls, watch coverage rise as evidence lands.
• ServiceNow write-back — the gate writes its verdict, risk and evidence onto the Change Request, and raises an Incident when it blocks.
• verify-chain — proves the attestation chain is intact and untampered.

ServiceNow

• Change Requests created from the pipeline, enriched with commit SHA, risk score, target cloud/env, pipeline URL and u_fides_* custom fields.
• CAB approval as the cr_approved control — a real change-management sign-off gating the deploy.
• Incident Management — blocked changes raise tracked, assignable incidents.
• CMDB — services registered/updated as CIs from delivery events.
• Event Management — build/scan telemetry as operational events.
• Now Assist grounding — AI approvals grounded on Fides evidence.
• Governed MCP — Fides reads CMDB / CRs / GRC through ServiceNow’s own MCP server over OAuth.

Before you run it live

What’s needed

• Fides configured (FIDES_EVENTS_ENABLED=true, fides servicenow config …); the change-gate is hard-enforced at qa/prod promotion time by scripts/ci/promote.sh (the per-push pipeline records the verdict as advisory evidence).
• The ServiceNow connection wired on the demo instance (calitiiltddemo3), with a CAB approver who is distinct from the change author (true four-eyes).
• A GitLab merge-request approval rule so peer_review is enforced.

Beats 1-2 (ITOM events + CMDB) and the change-gate → CR → approval loop run against the deployed portal today. Now Assist grounding + bi-directional MCP depend on the ServiceNow-side MCP work — confirm it’s enabled on the instance or narrate those two beats.

See also: the ServiceNow integration deep-dive for the technical design, and the pipeline showcase for the full stage-by-stage flow.