IIQ Connector Configuration Change Ledger

A biweekly report that reconciles who changed an Application connector's configuration against whether a change ticket backs it up — and flags the ones that touched auth, correlation, or provisioning without one.

Date: 2026-08-11 Type: Report Theme: Detect + Identify Platform: SailPoint IdentityIQ Status: Idea

What it is

A recurring report built from IIQ's own audit trail: every time someone edits an Application object's connection parameters, correlation rule, provisioning policy, or schema, it shows up, who did it, and whether a change ticket is attached. The report doesn't try to stop the edit — IIQ has no native gate for that — it makes the edit visible on a schedule instead of leaving it buried in a task log nobody reads until something breaks.

Who it serves

IAM engineer or GRC analyst responsible for connector governance across a 500+ application estate, plus whoever owns the quarterly access-control walkthrough for SOX or a similar audit.

The IIQ pain it addresses

An Application object in IIQ is a live piece of production config — connection parameters, correlation rules, provisioning policy forms, schema — and any capability-holder with edit rights can change it directly, at any time, with no required change ticket and no attribute-level diff shown anywhere in the product. IdentityIQ's Audit Configuration page can log Class Actions against the Application class, which records who touched it and when, but that's a name and a timestamp sitting in spt_audit_event, not a report anyone reviews. A community thread on the SailPoint Developer forum ("Multiple Connector Aggregation Failing") shows the failure mode this produces at scale: aggregation broke across AD, JDBC, ServiceNow, and Oracle HCM connectors at once, and the fix — restarting the Virtual Appliances — came from trial and error in the thread, not from a config-change record anyone could point to. At 500+ connectors, a correlation rule quietly edited on a mainframe RACF bridge or a provisioning form losing a required field on a CI/CD-driven JDBC app is exactly the kind of change that surfaces three weeks later as a broken certification or a provisioning failure, with no record of who did it or why.

How it works

• Who/when source: AuditEvent records from IIQ's Class Actions auditing on the Application class.
• What-changed source: a nightly export of every Application object's XML, diffed against the prior night's snapshot. IIQ's audit log doesn't carry attribute-level before/after values on its own — see the design-assumption note in report.md's Methodology section.
• Every change in the reporting window is classified high-risk (touched Connection Parameters, Correlation Rule, Provisioning Policy, or Schema) or routine, then cross-checked against the change-ticket system for a match within a ±24-hour window of the audit event.
• High-risk changes with no matching ticket lead the report. Everything else — ticketed high-risk changes, routine changes, category breakdowns, new-application onboarding, and any gaps where the nightly export itself failed to run — follows.

What's in this folder

• report.md — the rendered biweekly report, as it would land in an inbox: 4 unticketed high-risk changes, 5 ticketed high-risk changes, a category breakdown, a diff-coverage-gap section, and the methodology note.
• report-template.md — the same report parameterized with {{placeholders}} for every value a data layer would need to supply.
• sample-data.json — the synthetic dataset (512-application estate, 37 changes, 9 high-risk, 6 diff-coverage gaps) that report.md renders from and report-template.md's placeholders map to.

How to run / read it

Open report.md for the rendered version. See report-template.md for the placeholders a real data layer would fill in, and sample-data.json for the shape of the source data — summary, high_risk_unticketed_changes, high_risk_ticketed_changes, category_breakdown, diff_coverage_gap, and new_applications_onboarded.

Estimated impact

No hours-saved figure here, because there's no baseline — this is a report that doesn't exist today, not a faster version of one that does. The credible claim is narrower: it turns "we'd have no idea a correlation rule changed on the mainframe bridge until a certifier flagged bad access" into "we know within two weeks, with a name attached." Whether that's worth building depends on how often unticketed config changes have actually caused downstream incidents in a given shop — track that for one quarter and the report earns or loses its slot.

Why this fits an IIQ shop with 500+ connectors

At a dozen connectors, an admin can eyeball every Application object weekly. At 500+, most edits happen on the long tail — the 148 custom JDBC apps, the 226 miscellaneous flat-file and script-based connectors — where nobody is watching by default and a change can sit unnoticed until the next certification or a broken aggregation forces the question. A report scoped to the whole estate, sorted by risk and ticket status, is the only way to keep that long tail visible without staffing someone to review 500 Application objects by hand.

Sources

1. Official documentation:
   • https://documentation.sailpoint.com/identityiq/help/system_configuration/identityiq_global_settings/audit_configuration.html — Class Actions auditing and the requirement to explicitly enable which actions IIQ logs, used to ground the who/when data source.
   • https://documentation.sailpoint.com/identityiq/help/application_configuration/application_concepts.html — Application object composition (connection parameters, correlation rules, provisioning policies, schema, rules) used to define the report's "high-risk attribute class" list.
2. Community / current research:
   • https://developer.sailpoint.com/discuss/t/multiple-connector-aggregation-failing/28433 — SailPoint Developer Community thread describing simultaneous aggregation failures across AD, JDBC, ServiceNow, and Oracle HCM connectors, resolved by VA restart rather than a traceable config-change record — the pain point this report targets.