IIQ Mover Entitlement Residue Auditor

Finds access an employee's old department left behind after a manager or department change — because IIQ's built-in Manager Transfer event prints two names to a log and stops there.

Date: 2026-07-27 Type: Utility Theme: Protect + Detect Platform: SailPoint IdentityIQ Status: Idea

What it is

A Python utility that scans recent Mover events (manager or department changes) and flags entitlements the identity still holds from before the transfer that don't match what their new department's peers actually use. It's read-only: it reports candidates for review and doesn't revoke anything.

Who it serves

IAM engineers running the pre-certification access checks, and the identity governance lead who has to explain to an auditor why someone in Treasury still has AP payment-run rights eight months after leaving Accounts Payable.

The IIQ pain it addresses

IIQ ships a Manager Transfer lifecycle event, triggered on a Manager Change to an identity. Out of the box, it prints the old and new manager's names to sysout and takes no action on identity or entitlements. SailPoint's own documentation says shops are expected to customize it, usually to fire a certification for the new manager or provision birthright access for the new team. Plenty of shops never get around to that customization, or only handle the provisioning half and skip the review.

That leaves a gap Joiner/Leaver tooling doesn't cover: the person didn't leave, so nothing disables their accounts, and nothing about a department change forces a look at what they already have. Access from the old role just sits there. It's not orphaned; the account is active, the identity is active, and none of the usual dormant-account or terminated-user reports catch it. It only shows up if a certifier happens to notice during the next scheduled campaign, which might be months away.

How it works

1. Pull recent Mover events. IIQ's Access History captures Identity Attribute Change events (manager, department) as part of its nightly Dispatch Access History run, alongside Entitlement Added/Removed events for the same identities. The utility reads these from a replica of the Access History database, filtered to the configured lookback window (sample-config.json ships with 150 days so the bundled demo data reads cleanly; 90 days is closer to a real quarterly cadence).
2. Snapshot before and after. For each Mover, it builds the entitlement set held the day before the transfer and the set held as of the extract date. The intersection is what survived the transfer untouched.
3. Check it against the new team. Each surviving entitlement gets compared to the mover's new-department peer group. If fewer than peer_group_min_support of their peers hold it, and there are enough peers to make that comparison meaningful (peer_group_min_report_count), it's flagged. An entitlement everyone in the new team already carries isn't residue; it's probably just typical for the role.
4. Rank by severity. Privileged entitlements held more than 30 days past the transfer come back HIGH. Everything else privileged, or non-privileged past 60 days, comes back MEDIUM. The rest is LOW.
5. Report. Prints a summary and findings table to stdout; writes mover-residue-findings.json unless --dry-run is set. That JSON is meant to feed a targeted Manager Access Review certification for the new manager, or a ticket. The utility stops at detection.

What's in this folder

• README.md — this file
• requirements.md — functional, non-functional, and security requirements
• script.py — Python 3.10+ utility, standard library only
• sample-config.json — illustrative configuration (.invalid host, password sourced from an env var name, not a literal value)
• sample-output.txt — stdout from four sample runs: a full run, a --dry-run, and two failure cases (missing config file, missing required key)

How to run / read it

python3 script.py --config sample-config.json

Add --dry-run to see the findings without writing mover-residue-findings.json. No dependencies to install; it's standard library only. access_history_db.mode is set to "sample" in the shipped config, so it runs against an embedded synthetic dataset with no database connection or credentials involved.

Read sample-output.txt to see all four runs, including what the two failure modes print to stderr and their exit codes.

Estimated impact

The bundled sample (8 Mover events, a synthetic entitlement history across seven applications) surfaces 9 residue findings, 3 of them privileged. Scaled to an organization where Mover events run a few dozen per quarter (a fraction of total JML volume, since most lifecycle activity is Joiner/Leaver, not internal transfer), this utility turns a gap that's currently invisible between certification cycles into a short list a manager or IAM engineer can clear in one sitting, instead of waiting for the next scheduled campaign to catch it by accident.

Why this fits an IIQ shop with 500+ connectors

Movers don't stay inside one connector. A transfer from Accounts Payable to Treasury touches SAP ECC, Workday, and an Active Directory group in the sample data alone; a transfer from Field Support to Cloud Platform Engineering touches ServiceNow, AWS IAM, GitHub, and a PagerDuty-managed AD group. At 500+ connectors, the old-department access a mover keeps is scattered across whichever applications that department used, which means no single connector's aggregation task or certification campaign is positioned to catch the leftover access on its own. A cross-application check run off Access History, rather than off any one connector's data, is the only vantage point that sees the whole picture.

Sources

• Local Resources directory not present on this checkout. Canonical references below are the web-accessible equivalents of the SailPoint IdentityIQ 8.4 documentation this idea draws on.
• Lifecycle Event-Driven Provisioning — SailPoint IdentityIQ 8.4 documentation — confirms the Manager Transfer event's default behavior ("prints names of the old and new manager to sysout. No actions are taken on identity or entitlements") and its trigger ("Manager Change"), and that Leaver/Reinstate are Attribute Change triggers on the Inactive flag
• How Access History Works — SailPoint IdentityIQ documentation — the Dispatch Access History task, its daily default schedule, and the spt_hist_* table family this utility's production data source queries
• Event Timeline — SailPoint IdentityIQ 8.4 documentation — confirms Identity Attribute Change and Entitlement Added/Removed as distinct, queryable event types on the same identity timeline
• 8.4 IdentityIQ Access History guide (PDF) — the full reference this idea's data model is built against