IIQ Leaver SLA Watchdog → PagerDuty

Fires a PagerDuty incident when a terminated identity's accounts are still active past a configurable SLA window — wiring IIQ's Lifecycle Manager into IAM on-call so that every missed Leaver deadline becomes a tracked, escalated event.

Date: 2026-06-06 Type: Integration Theme: Respond + Detect Platform: SailPoint IdentityIQ Status: Idea

What it is

A polling integration between SailPoint IdentityIQ 8.4 and PagerDuty that enforces time-bound Leaver processing. A Python script, scheduled every 15 minutes, queries the IIQ REST API for identities whose inactive flag is set (Leaver lifecycle event has fired) but whose account Links are still not fully disabled past a configurable SLA window — for example, 4 hours for identities tagged risk_tier=privileged, 8 hours for standard employees. When a breach is detected, the script posts a PagerDuty Events API v2 trigger event. When IIQ's aggregation eventually confirms all links are disabled, the script posts a resolve event and closes the incident automatically.

Who it serves

IAM engineers carrying on-call rotation for an IIQ deployment at scale. Today, a Leaver workflow that silently fails or stalls leaves no page — the IAM team discovers the breach hours or days later through a compliance scan or a helpdesk report. This integration turns missed Leaver SLAs into first-class, trackable operational incidents indistinguishable from a failed service deployment.

The IIQ pain it addresses

IIQ's Leaver lifecycle event depends on a chain of async steps: the HR system aggregation (e.g., Workday or SuccessFactors) must complete and mark the identity's source attribute as terminated; the Refresh Identities task must run and detect the change; the configured Leaver Business Process must launch and submit a Provisioning Plan with AccountRequest op="Disable" for every connected application; each connector must process its disable request; and a subsequent aggregation must confirm the change, updating Link.disabled = true. At 500+ connectors, any step in that chain can fail silently — a connector timeout, a BPM step that gets stuck waiting on a work item approval, or a Provisioning Plan rejected by a managed system's API. IIQ's native Lifecycle Events Status Report shows completion status but generates no alert when a Leaver event stalls. The SailPoint Developer Community confirms real-world delays of 2–3 days on this exact flow. This integration closes that gap.

How it works

Trigger: A cron job (or Windows Task Scheduler entry) runs iiq-leaver-sla-watchdog.py every 15 minutes.

Step 1 — Identify candidates: The script authenticates to IIQ via HTTP Basic Auth (service account) and calls GET /identityiq/rest/identities with a filter for inactive==true. The response includes each identity's attributes; the script reads the configurable termination date attribute (default: hrTerminationDate) to calculate elapsed time since termination.

Step 2 — SLA evaluation: For each inactive identity, the script looks up the elapsed hours since termination and compares against the tiered SLA map from sample-config.json (e.g., privileged: 4h, standard: 8h, contractor: 6h). Identities not yet past their SLA are skipped.

Step 3 — Link check: For identities past SLA, the script calls GET /identityiq/rest/identities/{name}/links and filters for links where disabled == false and the application is not on the optional exclusion list (e.g., archive systems that are allowed to retain terminated accounts). If any active links remain, a breach is confirmed.

Step 4 — Trigger PagerDuty: The script posts a trigger event to the PagerDuty Events API v2 endpoint (POST https://events.pagerduty.com/v2/enqueue) with:

• dedup_key: iiq-leaver-sla-{identity_id} to prevent duplicate incidents across poll cycles
• severity: warning for standard SLA breach, error for >2× SLA
• custom_details: identity name, termination date, elapsed hours, list of still-active applications (not raw account IDs to minimise PII in the incident)
• A deep-link back to the IIQ identity detail page

Step 5 — Auto-resolve: On subsequent poll cycles, when the same identity no longer has active links, the script posts a resolve event to PagerDuty using the same dedup_key, closing the incident automatically. The resolution time is logged as evidence of remediation latency.

Step 6 — Dead-letter: Any identity whose PagerDuty event fails after three retries is written to a local dead_letter.jsonl file for manual review. The script exits non-zero so the scheduler can alert.

What's in this folder

• README.md — this file
• cover-image.png — concept art cover for the web app card
• metadata.md — workflow and provenance sidecar
• integration-spec.md — full integration contract: auth, endpoint shapes, error model, retry policy, rate limits, sequencing
• sequence.md — step-numbered sequence diagrams for the happy path and two failure cases
• sample-request.json — example PagerDuty Events API v2 trigger payload as sent by the watchdog
• sample-response.json — matching PagerDuty success response

How to run / read it

Read integration-spec.md first for the full contract, then sequence.md for the call flow, then compare sample-request.json and sample-response.json to the spec. To prototype the integration, configure sample-config.json (provided in the spec's appendix) with your IIQ base URL and PagerDuty routing key, then run the companion script against the IIQ REST API.

Estimated impact

In an organisation with weekly Leaver volume of ~50 identities and an average of 12 connected applications each, a single missed Leaver event leaves 12 active accounts open for days. At 500+ connectors, even a 1% connector failure rate on Leaver provisioning means ~5 undetected breaches per week. This integration reduces mean time to detect (MTTD) for a missed Leaver from days (discovered at next compliance scan) to under 15 minutes (next poll cycle post-breach). For SOX and ISO 27001 environments, reducing MTTD to <1 hour directly supports evidence of timely leaver processing.

Why this fits an IIQ shop with 500+ connectors

At scale, Leaver processing is only as reliable as its weakest connector. A flat connector failure rate of 1% across 500 apps means roughly 5 failed account disablements for every Leaver — and that assumes every connector is healthy. Connector version skew, API rate limits, intermittent network partitions, and managed-system maintenance windows all compound the failure rate. IIQ's BPM retry logic can eventually catch most failures, but "eventually" is not a compliance posture. This integration treats Leaver SLA enforcement as an operational concern — same as application uptime — and routes breaches to the on-call queue where they belong. The dedup_key pattern ensures one incident per identity regardless of how many poll cycles it spans, preventing alert storms during a wide connector outage.

Sources

• Lifecycle Events — SailPoint IdentityIQ — Lifecycle Event types, trigger configuration, and Business Process association used in §How it works
• Lifecycle Event-Driven Provisioning — SailPoint IdentityIQ — Provisioning Plan semantics, AccountRequest op="Disable", and the Provisioning Broker chain
• Using Lifecycle Manager — SailPoint IdentityIQ — Leaver configuration and the Refresh Identities task dependency
• Leaver lifecycle event is not triggering on time — SailPoint Developer Community — Community thread confirming 2–3-day real-world delays and the root-cause pattern (HR sync → Refresh task → BPM wait) that motivated this integration
• PagerDuty V2 Events API — Events API v2 contract: trigger/resolve actions, dedup_key semantics, severity levels, and rate limits used in §integration-spec.md
• Integrate Your Monitoring System With PagerDuty Using Events API V2 — Implementation reference for dedup_key lifecycle and retry handling patterns