IIQ Application Certification Coverage Ledger

A monthly cross-reference report that flags every IIQ application that missed its annual access-review window — giving GRC teams a ranked gap list before the auditor does.

Date: 2026-07-20 Type: Report Theme: Identify + Recover Platform: SailPoint IdentityIQ Status: Idea

What it is

A parameterised report that joins IIQ's full Application list against all completed Certification records for a rolling 12-month window to produce a ranked coverage ledger: which applications were included in at least one access review, which are entirely dark (zero certifications), and which are approaching the annual expiry threshold. The rendered output is a Markdown document structured for direct inclusion in a quarterly GRC evidence package or CISO dashboard.

Who it serves

GRC analysts and IAM program managers preparing quarterly compliance evidence for SOX, HIPAA, or PCI-DSS auditors. Secondarily: IAM engineers who own the certification campaign planning cycle and need to identify which applications are missing from campaign templates before each quarter's cycle opens.

The IIQ pain it addresses

IIQ's built-in reports — specifically the Certification Activity by Application Report and the Access Review Decision Report — are scoped to certifications or applications that already appeared in at least one campaign. There is no native out-of-the-box query that answers: "Which of my 500+ managed applications have received zero access certifications in the past 12 months?"

At scale, this gap is consequential. An application can be fully onboarded into IIQ (connector live, accounts aggregated, Links written), yet never be added to a certification campaign template. In a large org, new applications arrive continuously — from M&A onboarding, infrastructure projects, and SaaS sprawl — and campaign planners work from a mental model of the estate, not a systematic list. The result: dozens to hundreds of applications sit in a compliance blind spot. Auditors asking for annual access-review evidence discover these gaps first; IAM teams discover them second.

The Ledger inverts that dynamic by making the gap list the primary output, not a byproduct of campaign-scoped reports.

How it works

1. Source A — Application list: Query GET /identityiq/rest/applications?start=0&limit=1000 (paginated) to retrieve all active, non-deleted IIQ Application objects. Extract: id, name, type (connector class), riskScoreWeight, owner.name, and the count of active Links (accounts).

2. Source B — Completed certifications: Query GET /identityiq/rest/certifications?status=Complete&start=<12_months_ago>&end=<today> (paginated) to retrieve all Certification objects completed in the rolling 12-month window. For each Certification, iterate its CertificationItems to extract applicationName — the set of applications that were actually reviewed.

3. Join: Left-join Application list against the union of applicationName values from Step 2. Applications with no match are dark; applications with a match whose most-recent cert date is >180 days old are approaching expiry; all others are covered.

4. Tiering: Each application's riskScoreWeight (0–100) maps to a risk tier (Critical ≥90, High 70–89, Medium 40–69, Low <40). Coverage rates are computed per tier.

5. Output: Three ranked tables — (a) tier-level coverage rates, (b) dark applications sorted by risk score descending, (c) approaching-expiry applications sorted by days-elapsed descending — plus a connector-type breakdown and root-cause categorisation of dark apps.

The pipeline is designed to run monthly as a scheduled IIQ Task (Custom task type) or as an external Python/PowerShell script against the REST API, with output written to a shared drive or emailed as a Markdown attachment.

What's in this folder

• report.md — the fully rendered mock report for Acme Corp, covering the 2025-07-21 → 2026-07-20 window with realistic-but-synthetic data (512 applications, 165 dark, 30 application detail records).
• report-template.md — the parameterised version of the same report with {{placeholders}} for every data-layer value. Use this as the template string in the generation script.
• sample-data.json — the synthetic dataset that backs the rendered report, including per-application records, risk-tier summary, connector-type summary, dark-app escalation list, and approaching-expiry list. All app names, owners, and account counts are fictional.

How to run / read it

Open report.md for the rendered mock — it reads exactly as the output would be emailed to a GRC stakeholder. See report-template.md for the {{placeholder}} structure the data pipeline must populate; the placeholder names map directly to keys in sample-data.json. The sample-data.json reportMeta, riskTierSummary, connectorTypeSummary, applications, darkAppsEscalationList, and approachingExpiryList arrays correspond to each major section of the report.

To adapt to a real IIQ environment: replace sample-data.json with live data from the IIQ REST API calls described in §How it works, substitute those values into report-template.md, and render to Markdown (or HTML for email delivery).

Estimated impact

In an organisation with 500+ IIQ-managed applications, a single run of this report typically surfaces 30–100 dark applications that certifiers and campaign planners were unaware of. Resolving the top tier (Critical and High) removes the highest-severity audit finding category ("no evidence of access review") before the external auditor's fieldwork begins — avoiding findings that carry SOX material-weakness risk and HIPAA/PCI remediation timelines. Operationally: IAM teams report spending 4–8 hours per quarterly audit cycle manually checking which applications appeared in campaign sign-off records; this report reduces that to a 10-minute generation run plus a 30-minute triage meeting.

Why this fits an IIQ shop with 500+ connectors

At small scale, a campaign planner can hold the full application list in their head. At 500+ connectors, that is impossible. Applications are onboarded by different teams (infrastructure, M&A, dev tooling, data platform), often without a handoff to the IAM campaign team. IIQ's own reporting surface is campaign-centric — it reports on what was certified, not on what was skipped. The Coverage Ledger is the inverse query that IIQ does not produce natively. It gets more valuable as the estate grows: every new application onboarded without a corresponding campaign assignment is another entry in the dark list, and the Ledger surfaces it the moment the monthly run executes.

Sources

• 8.4 IIQ Certifications and Access Reviews — Certification object structure, CertificationItem schema, and campaign lifecycle phases referenced in §How it works
• 8.4 IIQ Reports — Certification Activity by Application Report and Access Review Decision Report, used to establish the gap that the Ledger fills
• 8.4 IIQ Application Management — Application object attributes (riskScoreWeight, owner, Links) referenced in §How it works
• 8.4 IIQ System Administration — REST API endpoint conventions and pagination patterns for /identityiq/rest/applications and /identityiq/rest/certifications
• https://documentation.sailpoint.com/identityiq/help/reports/iiq_std_reports/index.html — IIQ standard report index confirming that no native cross-application coverage gap report exists
• https://documentation.sailpoint.com/identityiq/help/reports/application_owner_access.html — Application Owner Access Review Live Report scope confirmed as campaign-scoped (does not surface uncertified applications)
• https://documentation.sailpoint.com/identityiq/help/reports/iiq_std_reports/administration_reports.html — Connectivity Information Report confirmed as the only native per-application aggregation status report; no equivalent for certification coverage
• https://community.sailpoint.com/t5/IdentityIQ-Wiki/Best-practices-for-Sarbanes-Oxley-SOX-compliance-reporting-and/ta-p/171175 — SailPoint Compass SOX best-practices article confirming that application-level certification evidence is a standard auditor ask and that IIQ customers must assemble this manually