📊 Cert Decision Velocity Report

A quarterly SailPoint IdentityIQ report that turns access certifications from a paper exercise into a measurable control — quantifies rubber-stamp risk, surfaces high-risk fast approvals, and ranks certifier behavior so audit can defend the trail.

Date

2026-05-10

Type

Report

Theme

Protect (primary, NIST CSF) + UX (secondary)

The IIQ problem this addresses

In a mature IdentityIQ deployment with 50k+ identities, quarterly user-access certifications spawn tens of thousands of line items spread across hundreds of certifiers. SailPoint's own Compass guidance and customer case studies (PG&E, Integral Partners) call out the same failure mode: certification fatigue ➜ rubber-stamping ➜ audit failure. The pattern is well known but most IIQ shops measure only what the native UI shows: completion percentage and SLA. That tells you whether a campaign closed. It does not tell you whether the decisions inside it were real.

What the native IIQ certifications UI does not surface today:

1. Per-certifier decision velocity. Median seconds between item open and decision. A certifier who burns through 800 items in 22 minutes is mathematically not reading them.
2. Rubber-stamp sessions. Sessions where >95% of decisions are "Approve" issued in under 5 seconds per item, with no comment, often back-to-back at end-of-quarter.
3. High-risk fast approvals. Privileged entitlements (admin groups, SOX-bounded apps, production-database roles) approved in under 5 seconds — the exact items auditors will pull-test.
4. Trend across campaigns. Revocation rate quarter-over-quarter — SailPoint and auditors agree this is the single best signal that controls are tightening. IIQ does not graph it.

Auditors increasingly ask for evidence that the certification process worked, not just that it ran. This report is that evidence.

What the report contains

Cert Decision Velocity Report — Q1 2026 is a quarterly artifact emailed to the IAM lead, the GRC/audit partner, and the CISO. Each issue:

1. Executive summary — campaigns covered, items reviewed, approval rate, revocation rate, rubber-stamp risk score (0–100), and the QoQ trend on revocations.
2. Per-campaign breakdown — for every active certification campaign (Quarterly User Access, Privileged Access, App Owner, SOX Quarterly): items, approval/revocation/delegation/forwarded mix, median seconds per item, % of decisions under 5 seconds, % of decisions accepted from an AI recommendation.
3. Top 10 rubber-stamp-risk certifiers — anonymized certifier IDs, campaign, total items, % approved under 5s, longest streak of consecutive sub-5s approvals, recommended action (coach / re-train / re-assign).
4. Top 10 high-risk fast approvals — every privileged entitlement approved in under 5 seconds during the quarter, with identity, entitlement, application, certifier, decision time in seconds. Each row is a candidate for audit pull-testing.
5. Trend chart — quarterly revocation rate over the last four quarters. A flat or falling line means certifications are not finding anything; a rising-then-stabilizing line is the healthy curve.
6. Recommendations — three concrete, mechanical actions for next quarter (e.g., "split Campaign X into per-app sub-campaigns", "re-train 4 certifiers", "exclude read-only entitlements from CAMP-002").

Why this matters (the business case)

NIST CSF mapping

• PR.AC-1, PR.AC-4 — Access permissions and authorizations are managed, incorporating principles of least privilege. The report measures whether the control that enforces this is working.
• PR.IP-7 — Protection processes are improved. The Recommendations section is the explicit improvement loop.
• ID.GV-3 — Legal and regulatory requirements regarding cybersecurity are understood and managed. SOX, HIPAA, and ISO 27001 access-review obligations all require evidence the review was substantive.

How the report is produced

The report is generated from three IIQ data sources, joined and aggregated in a scheduled job (Python or PowerShell — out of scope for this idea, this artifact defines the shape of the report, not the pipeline):

1. spt_certification / spt_certification_item — campaign definition and per-item state.
2. spt_certification_action — every decision, with timestamps, decider, and (since 8.3) the recommendation source.
3. spt_audit_event — fallback for older IIQ versions and for delegation/forwarding history.

The query joins on certification_item.id ➜ certification_action.certification_item_id, computes decision_time_seconds = action.created - item.opened, then aggregates per certifier and per campaign. Rubber-stamp risk score is a weighted blend (40% pct-under-5s, 30% pct-approve-bulk, 20% pct-no-comment, 10% longest-streak).

This folder ships the report contract — a rendered mock (report.md), a parameterised template (report-template.md), and the synthetic source data (sample-data.json) — so an engineer can stand up the pipeline in a day without arguing about the schema.

Run / preview locally

No code to run. The deliverables are:

report.md            # the rendered Q1 2026 mock — read top-to-bottom
report-template.md   # the {{placeholder}} version a templating engine fills
sample-data.json     # the exact data that, fed into the template, produces report.md

To preview, open report.md in any markdown viewer (GitHub renders it directly, VS Code's preview pane renders it inline). To extend, edit report-template.md and add fields to sample-data.json.

What's intentionally out of scope

• The data pipeline itself. This idea defines the report contract; the SQL/Python that builds it is a separate utility week.
• Real-time alerting. This is a quarterly artifact. Within-quarter rubber-stamp alerts belong in a separate Detect-themed report or dashboard.
• Identity- and entitlement-level remediation. The report surfaces the fast approvals; revoking them is a follow-on workflow.
• Cross-IGA portability. The schema assumes IdentityIQ (on-prem Java). An IdentityNow / Identity Security Cloud variant would map to a different data model (the high-level metrics carry, the SQL does not).
• Personally identifying certifier names in the public artifact. The rendered mock uses anonymized IDs (CERT-101); in production the report flips them to real names behind audit-controlled distribution.

Files in this folder