IIQ Certification GRC Evidence Bridge

Automatically packages completed SailPoint IIQ certification campaigns as evidence records in ServiceNow GRC — closing the manual loop between quarterly access reviews and compliance documentation.

Date: 2026-07-06 Type: Integration Theme: Recover + Protect Platform: SailPoint IdentityIQ Status: Idea

---

What it is

A lightweight integration that hooks into IIQ's CertificationPhaseChange event and fires an asynchronous IIQ Workflow the moment a certification campaign enters the End phase. The workflow authenticates to ServiceNow GRC via OAuth 2.0 Client Credentials, creates a structured evidence record (sn_grc_evidence) linked to the configured SOX or ISO compliance task, and attaches a CSV of all 1,000+ certification decisions — all within five minutes of campaign close. No manual export, no email chain, no waiting on the IAM team to remember.

---

Who it serves

GRC analysts and IAM engineers at organizations that run SailPoint IdentityIQ for access certifications and ServiceNow GRC for compliance control testing — specifically shops with SOX, HIPAA, or ISO 27001 obligations where every quarterly access review must produce a dated, auditor-readable evidence record. Control owners get an automatic notification in ServiceNow the moment IIQ closes the campaign; they no longer need to track down the IAM team.

---

The IIQ Pain It Addresses

After an IIQ certification campaign transitions to the End phase, the evidence lives inside IIQ's spt_certification and spt_certification_item database tables — inaccessible to the GRC team without an IIQ login or a manual data export. The standard remedy is:

1. An IAM engineer runs the "Certification Activity Report" from IIQ's Reports module and exports it as CSV or PDF.
2. The engineer emails the file to the GRC/compliance team (often days after the campaign closes).
3. The GRC analyst uploads it manually to ServiceNow GRC, annotates the control record, and changes the evidence state to "Approved."

At a 500-app IIQ shop running 12–20 certification campaigns per quarter (Application Owner certs per connector, Manager certs, Targeted certs for sensitive populations), this is 12–20 manual handoff loops every 90 days. Each loop introduces lag during which auditors cannot see confirmed evidence, and each transfer is a vector for the wrong file, the wrong campaign, or missing metadata (which IIQ campaign maps to which SOX control number?). The bridge eliminates all of it.

---

How It Works

Trigger

The IIQ CertificationPhaseChange rule fires synchronously when any certification campaign changes phase. The rule checks newPhase == End; for all other phase changes it returns immediately. For matching campaigns, it reads the campaign attribute snow_compliance_task_sys_id — the ServiceNow GRC compliance task sys_id set at campaign creation. If the attribute is absent (internal review, ad-hoc cert, test run), the rule logs a warning-level AuditEvent and returns without action.

Async Workflow Launch

To avoid blocking IIQ's phase-change transaction with HTTP calls, the rule launches the IIQ Workflow IIQ-GRC-Evidence-Push-Workflow asynchronously, passing the certification ID and bridge configuration as workflow variables. IIQ commits the phase change immediately; the workflow runs in the background.

ServiceNow Evidence Creation

The workflow:

1. Fetches an OAuth 2.0 bearer token from ServiceNow (POST /oauth_token.do).
2. Reads the Certification object (name, type, owner, start/end dates, completion percentage, approved/revoked/mitigated/abstained counts).
3. Computes a PASS/FAIL result: PASS if ≥95% of items are decided and zero high-risk items (tagged SOX-Sensitive) remain approved without a comment.
4. POSTs to POST /api/now/table/sn_grc_evidence with the structured payload — see sample-request.json.
5. On 201 Created, receives the evidence record sys_id and number (e.g., EVD0019832).

CSV Attachment

The workflow iterates certification.getCertificationEntities() → entity.getItems() to build a CSV of every decision: identity name, application, entitlement, decision (Approved/Revoked/Mitigated/Abstained), certifier, decision date, risk score, and comments. The CSV is posted to POST /api/now/attachment?table_name=sn_grc_evidence&table_sys_id=<sys_id> as text/csv. For large campaigns (CSV > 4 MB), the attachment is split into numbered parts.

Audit and Error Handling

On success: IIQ logs a CERTIFICATION_EVIDENCE_PUSHED AuditEvent (target = ServiceNow evidence number, info = certification ID, stats, sys_id).

On failure after two retries: IIQ logs CERTIFICATION_EVIDENCE_FAILED and creates an IIQ Work Item assigned to the IAM operations team. The Work Item contains the campaign name, failure reason, ServiceNow compliance task sys_id, and manual remediation steps.

---

What's in This Folder

• README.md — this file
• cover-image.png — concept art cover
• metadata.md — machine-readable sidecar
• integration-spec.md — full integration contract (auth, endpoints, payload shapes, error model, sequencing, operational expectations, BeanShell rule excerpt)
• sequence.md — step-by-step sequence diagrams for the happy path and two failure cases
• sample-request.json — IIQ→ServiceNow GRC evidence creation payload (Q2 2026 SOX Manager cert, 1,247 items, PASS)
• sample-response.json — ServiceNow GRC 201 Created response with evidence sys_id and attachment follow-up note

---

How to Run / Read It

Read integration-spec.md first for the full contract — it covers authentication, endpoint shapes, error model, retry policy, and the BeanShell rule excerpt. Then read sequence.md for the step-by-step call chain including two failure paths. Finally, review sample-request.json and sample-response.json side-by-side to understand the IIQ→ServiceNow payload contract.

To deploy:

1. Import the IIQ CertificationPhaseChange rule and IIQ-GRC-Evidence-Push-Workflow into IIQ via the IIQ console or an import task.
2. Create the IIQ-GRC-Evidence-Bridge-Config Custom object with your ServiceNow instance URL, OAuth client credentials, and pass threshold.
3. On each SOX-mapped certification campaign definition, populate the snow_compliance_task_sys_id campaign attribute with the sys_id of the corresponding ServiceNow GRC compliance task.
4. Close a test campaign in a non-production IIQ environment and confirm the evidence record appears in ServiceNow GRC within five minutes.

---

Estimated Impact

Eliminates 12–20 manual evidence handoff loops per quarter — each currently taking 3–5 business days of elapsed time from campaign close to confirmed evidence in ServiceNow GRC. At that scale, the bridge saves approximately 40–100 business days of elapsed lag per quarter and removes the risk of mismatched evidence files (wrong campaign exported, PDF instead of CSV, missing decision metadata). For external auditors, the benefit is an always-current evidence record with machine-readable decision detail that doesn't require an IIQ login to read.

---

Why This Fits an IIQ Shop with 500+ Connectors

Large IIQ deployments run certification campaigns at a cadence that mirrors their connector footprint: Application Owner certifications for each of the 500+ connectors (often split into batches by risk tier), quarterly Manager certifications covering all identities, Targeted Access Reviews for sensitive populations (PAM, finance, healthcare data). That is easily 40–80 distinct campaign closures per year. Without this bridge, each closure requires a human to carry evidence from IIQ to ServiceNow GRC — a linear cost that grows with the connector count. The bridge is stateless and event-driven: it fires once per campaign close, requires no polling job, and does not need to know about individual connectors. Adding 50 new connectors (and their associated Application Owner certification campaigns) adds 50 more automated evidence pushes with zero additional configuration beyond adding snow_compliance_task_sys_id to each new campaign definition.

---

Sources

Local IIQ Documentation

• [8.4 IIQ Certifications and Access Reviews](../../Resources/IIQ_Documentation/8.4/identityiq-doc-8.4/8.4_IdentityIQ_Certifications_and_Access_Reviews.pdf) — Certification phases (Staging, Active, Challenge, Revocation, End), CertificationPhaseChange rule type, campaign completion criteria, and decision tracking used throughout the spec and sequence diagram
• [8.4 IIQ Business Processes](../../Resources/IIQ_Documentation/8.4/identityiq-doc-8.4/8.4_IdentityIQ_Business_Processes.pdf) — Workflow launch from a rule (WorkflowLaunch, Workflower) and async execution pattern used in the BeanShell excerpt

External Research

• https://documentation.sailpoint.com/identityiq/help/certifications_and_access_reviews/about_certifications.html — IIQ 8.5 certification lifecycle phases (Staging, Active, Challenge, Revocation, End) and completion semantics
• https://documentation.sailpoint.com/connectors/identityiq/itservice/help/it_service_management_infrastructure_modules/configuring__to_integrat_1.html — IIQ ITSM integration pattern (async workflow launch from provisioning event) used as the architectural model for the async push workflow
• https://www.sailpoint.com/blog/sailpoint-servicenow-certification-review — SailPoint's 2025 "Certification review in ServiceNow" feature (ISC-only), confirming the ServiceNow+IGA integration direction is a recognized industry need; IIQ lacks an equivalent native feature
• https://developer.sailpoint.com/docs/api/iiq/identityiq-scim-rest-api/ — IIQ REST API resource types (TaskResults, LaunchedWorkflows) used in the integration spec