An IAM checklist is only useful if it tells you something you can act on. Most don't. This one is built around the four questions every auditor asks, and whether your program can answer them for every application, including the ones outside your IdP.
The IAM checklist problem is a format problem. Most IAM checklists are best-practices lists organized as checkboxes: "implement MFA," "enforce least privilege," "conduct regular access reviews." These are correct recommendations. They tell you what your program should do. They don't tell you whether it's actually doing it, or whether the doing covers the full scope of your identity environment.
An audit-ready checklist is different. It asks verifiable questions about current state: not "do you conduct access reviews" but "can you produce a completion record for every access review cycle in the past 12 months, with evidence that flagged items were remediated." Not "do you deprovision departed users" but "can you show a timestamp for when access was revoked for every departure in the past quarter, across every application the user accessed."
The difference matters because auditors ask the second type of question, not the first type. And because the gap between "we do this" and "we can prove we do this" is where most compliance programs find their findings.
This checklist covers 8 control areas. Each includes the verifying question, the evidence it requires, and the common gap that produces audit findings. A downloadable version is available at the bottom of this article.
8-Point IAM Audit Readiness Checklist
1. Identity Inventory Completeness
Verify: Can you produce an accurate, current inventory of every human and non-human identity in your environment, including identities outside your IdP's catalog?
Evidence required: A complete identity roster that includes: all SSO-federated users, all non-SSO application accounts, all contractor and partner identities, all service accounts and API credentials, all OAuth tokens granted by workforce members to external applications.
Common gap: Most organizations can produce their IdP's user list. The shadow applications, contractor accounts provisioned outside the standard workflow, and non-human identities are absent. An inventory that covers 70% of the actual identity estate passes the "we have an inventory" check and fails the "the inventory is complete" check.
Indicator of readiness: The inventory includes identities discovered through multiple methods, not only what the IdP already knows. Discrepancies between the IdP roster and the full inventory are documented and have remediation plans.
2. Provisioning Authorization Records
Verify: For every access grant in the past 12 months, does a record exist showing who approved it, under what authority, and when?
Evidence required: Provisioning logs with timestamps, approver attribution, and approval basis (role-based, manager-approved exception, IT-direct provisioning). The record should exist for all access grants, not only those processed through a formal ticketing system.
Common gap: HRMS-triggered provisioning events are logged automatically by mature platforms. Access granted informally (by a manager via email, by a department head directly in the application, by IT outside the standard workflow) may have no audit record at all. Auditors who pull a sample of user access and trace back the approval chain frequently find gaps here.
Indicator of readiness: All provisioning events, including exceptions and out-of-band grants, are logged with approver identity and timestamp. The provisioning log and the current access roster reconcile without unexplained discrepancies.
3. Deprovisioning Completeness and Timing
Verify: For every departure in the past quarter, was access revoked across every application the user accessed, including non-SSO-connected ones, within the organization's defined SLA?
Evidence required: Deprovisioning records for each offboarding event, showing: which applications were deprovisioned, the timestamp for each revocation, and the trigger event (HRMS departure, SSO status change). Evidence should show that deprovisioning covered the full access inventory, not a subset.
Common gap: Deprovisioning automation typically covers the applications the IdP manages. Non-SCIM applications, shadow IT tools provisioned outside the standard workflow, and service accounts created by the departing user are frequently missed. These produce the orphaned accounts that appear in access reviews and audit samples.
Indicator of readiness: Deprovisioning records show coverage across all application types, including non-SCIM integrations. SLA compliance rate (percentage of offboardings completed within the defined window) is tracked and at or near 100%. Periodic orphaned account checks find no accounts belonging to departed users.
4. Access Review Completion and Remediation
Verify: Did every scheduled access review cycle complete on time, with documented reviewer decisions, and was every flagged item remediated within the defined window?
Evidence required: Access review completion records showing: review cycle dates, populations covered (application, group, or user scope), reviewer identity, completion date relative to scheduled date, flagged items, and remediation status with timestamps.
Common gap: Two separate gaps, both finding-producing. First: reviews that were scheduled but completed late or not at all, particularly for lower-priority applications or during busy periods. Second: reviews that completed with 100% reviewer participation but where flagged items were not remediated, meaning access was certified as inappropriate but the revocation never ran. Auditors look at both completion rate and remediation rate.
Indicator of readiness: Completion rate is 100% across scheduled review cycles. Remediation rate for flagged items is 95%+ within the defined window (typically 30 days). Review scope covers the full identity inventory including non-standard identity types.
5. Privileged Access Controls
Verify: Is every privileged account (administrator credentials, infrastructure access, directory admin rights, financial system elevated access) individually attributable, subject to enhanced review, and deprovisioned within an accelerated SLA on departure?
Evidence required: A privileged account inventory separate from the general user roster. Privileged access review records showing more frequent certification than standard access (monthly or event-triggered rather than quarterly). Deprovisioning records for departing privileged users showing same-day or immediate revocation. MFA enforcement evidence for all privileged account access events.
Common gap: Privileged accounts that were created for a specific project and never deprovisioned after project completion. Shared administrator credentials where attribution is impossible. Privileged accounts excluded from access review cycles designed for standard users. Service accounts with admin-level permissions that have never been reviewed.
Indicator of readiness: Every privileged account is individually attributable (no shared credentials). Privileged access review runs on an accelerated cadence with separate records from standard user review. No privileged accounts belong to departed users. All privileged access events show MFA enforcement in logs.
6. Least Privilege Enforcement
Verify: Does each user's current access reflect what their current role actually requires, not what they've accumulated across multiple role changes?
Evidence required: Role definitions mapped to specific application entitlements. Evidence that provisioning grants role-appropriate access (not broader). Access review records showing that over-permissioned identities were identified and remediated. Mover event logs showing that access from previous roles was revoked at role change, not just that new-role access was added.
Common gap: Privilege creep is the most common finding in this area. Users who have changed roles retain access from previous roles because mover processes add new-role access without systematically removing old-role access. Access reviews may flag this but remediation may be incomplete. The gap widens over time as role changes accumulate.
Indicator of readiness: Access review findings data shows declining privilege creep over time, not a stable or growing backlog. Mover event logs show both addition of new-role access and revocation of previous-role access in the same event record. The current access roster for a sample of multi-role-change users reflects only their current role requirements.
7. Segregation of Duties (SoD) Enforcement
Verify: Has the organization identified all conflicting permission combinations relevant to its financial and operational risk profile, and can it demonstrate that no current user holds both sides of a conflicting combination, or that compensating controls are documented for approved exceptions?
Evidence required: SoD ruleset documentation listing the specific conflicting combinations the organization monitors. SoD violation detection records showing conflicts identified during the audit period. Remediation records for violations resolved through access modification. Compensating control documentation for any violations that were accepted as exceptions rather than remediated.
Common gap: SoD analysis is most commonly conducted within a single application (ERP access controls, for example). Cross-application SoD, where the conflict exists between permissions in two different systems, is frequently absent. A user who can approve purchases in the procurement system and create vendors in the financial system holds a conflicting combination that single-application SoD analysis won't catch.
Indicator of readiness: SoD ruleset covers cross-application combinations, not just within-application conflicts. Violation detection is continuous or at minimum quarterly. Exception documentation exists for every accepted violation, with compensating control description and approval record.
8. Non-Human Identity Governance
Verify: Are all service accounts, API keys, OAuth tokens, and bot credentials in the environment inventoried, scoped to minimum necessary permissions, reviewed periodically, and deprovisioned when the purpose they were created for is no longer active?
Evidence required: A non-human identity inventory that is separate from, but linked to, the human identity inventory. Creation records showing the purpose and approved scope for each non-human identity. Periodic review records showing that non-human identities were assessed for continued necessity and appropriate scope. Deprovisioning records for non-human identities retired when their purpose ended.
Common gap: Most organizations have no systematic non-human identity inventory. Service accounts appear in individual application admin consoles but are not aggregated into a governed register. API keys exist in developer tools and code repositories. OAuth tokens exist in each application's authorization grant records. None of these are included in standard access review cycles. The inventory, to the extent it exists, is incomplete and unreviewed.
Indicator of readiness: A non-human identity inventory exists and is maintained. Non-human identities are included in periodic access review alongside human identities. Deprovisioning records exist for non-human identities retired during the audit period.
How to Use This Checklist
Run through each of the 8 areas and answer honestly: can we produce the evidence listed, right now, for the full scope of our identity environment?
Areas where the honest answer is "no" or "partially" are the program gaps that will produce audit findings. Prioritize them by two factors: which compliance frameworks you're operating under (SOX ITGC and PCI DSS have tighter requirements in several areas; start with the strictest applicable standard), and which gaps represent the largest current security exposure (deprovisioning completeness and non-human identity governance are typically the highest-risk gaps in most programs).
The downloadable checklist version below is formatted for team use, with space for current-state ratings, evidence location, gap notes, and remediation ownership.
How Zluri Supports IAM Audit Readiness
Producing audit-ready evidence across all 8 areas requires an identity program that operates continuously rather than periodically. Zluri's four IGA modules are designed to produce that evidence as a byproduct of normal operations.
IVIP discovers the complete identity inventory, human and non-human, through 8 discovery methods, producing the inventory completeness that checklist item 1 and item 8 require. The inventory is not bounded by the IdP.
Access Management logs every provisioning and deprovisioning event with timestamps and approver attribution, producing the records that checklist items 2 and 3 require. Deprovisioning workflows reach every application in the governed estate, including non-SCIM applications, so deprovisioning completeness is systemic rather than dependent on manual checklist execution.
Access Reviews run at application, group, and user level on defined schedules, producing the completion and remediation records that checklist item 4 requires. Privileged account review runs on a separate, accelerated cadence with separate records (checklist item 5).
Segregation of Duties runs continuous cross-application conflict detection, producing the SoD evidence that checklist item 7 requires without a manual analysis project before each audit.
IRIS continuously surfaces over-permissioned identities and access anomalies, supporting the least-privilege verification that checklist item 6 requires.
Book a demo to see how Zluri closes the gaps in your IAM readiness
Frequently Asked Questions
What is the difference between an IAM checklist and an IAM policy?
An IAM policy is the governing document: the principles, rules, and standards that define how identity and access should be managed in the organization. An IAM checklist is the verification tool: the list of questions that confirm whether the policy is being implemented as written. The policy says "access should be revoked within 24 hours of departure"; the checklist item asks "can you show deprovisioning timestamps for every departure in the past quarter that confirm the 24-hour SLA was met." Both are necessary; neither substitutes for the other. See Zluri's IAM policy template for the governing document.
How often should an IAM checklist be run?
Quarterly is the minimum cadence that produces useful program oversight. It aligns with the access review cycle required by most compliance frameworks and catches gaps before they become audit findings. Many security programs run a lightweight version monthly (covering the highest-risk areas: deprovisioning completeness and privileged account status) and a full checklist review quarterly. Pre-audit runs should happen 60 to 90 days before any external audit to allow time for remediation before auditors arrive.
What is the difference between an IAM audit and an IAM assessment?
An IAM audit is a formal evaluation against a defined standard (a compliance framework, an internal policy, or an external auditor's control set) producing findings and a formal opinion on control effectiveness. An IAM assessment is a broader evaluation of program maturity and gaps, often without a fixed standard, focused on identifying improvement opportunities. A checklist like this one serves both purposes: run against a compliance framework's requirements, it functions as audit preparation; run as a general program review, it functions as an assessment.
Does this checklist apply to cloud-only environments?
Yes, with some adjustments in scope. Cloud-only environments typically have stronger SCIM coverage than hybrid environments, which can close some of the non-SCIM gap in checklist item 3. However, the shadow IT gap (applications outside the standard provisioning path), non-human identity governance, and cross-application SoD analysis are as relevant in cloud environments as in hybrid ones, often more so, given the rate of SaaS adoption in cloud-first organizations.
What should I do if my program fails several checklist items?
Prioritize by risk and compliance obligation. Deprovisioning completeness and privileged access controls are typically the highest immediate-risk gaps and the most likely to produce findings in any compliance framework audit. Identity inventory completeness is foundational. Most other items are only partially answerable without a complete inventory. Start there, then work through SoD and access review gaps. A realistic remediation timeline for moving from "significant gaps" to "audit ready" with the right tooling is 90 to 120 days.
.svg)
