Identity and access management is one of those disciplines that stays invisible until it isn't. Day-to-day, nobody notices that access reviews aren't running or that offboarding left accounts active. Auditors notice. And the findings that surface in IAM audits aren't usually technical — they're operational. Here's what keeps recurring and what fixes them at the root rather than at the finding level.

No Clear Ownership of the Identity Governance Function

The most common structural IAM audit finding isn't about technology. It's about accountability. Who owns the identity governance program? Who is responsible for ensuring access reviews run on schedule, that offboarding workflows execute completely, that orphaned accounts get remediated?

In many organizations, the answer is "whoever gets asked to run the review before the audit." That's not ownership — it's reactive compliance. Auditors can tell the difference between an access review program that runs continuously and one that gets assembled in the two weeks before the audit window.

The fix is organizational before it's technical: designate an identity governance owner with explicit responsibility for the program, tie that accountability to defined metrics (review completion rates, orphaned account counts, offboarding SLA compliance), and make those metrics visible to leadership quarterly rather than only at audit time.

Overprivileged Users at Scale

Privilege creep — the accumulation of access that users retain from previous roles, projects, and requests — is structurally inevitable in environments without automated mover workflows. Every role change that provisions new access without deprovisioning old access adds to the debt. Over time, users end up with access profiles that reflect the complete history of everything they've ever touched rather than what their current role requires.

Auditors find this in two forms: individual users with obviously excessive access (a marketing manager with admin rights to the production database from a six-month IT rotation three years ago), and systemic role bloat (an AD group that grants access to seventeen applications because it was easier to add applications to an existing group than to create new provisioning logic).

The structural fix requires two things: automated mover workflows that deprovision old-role access when new-role access is provisioned, and periodic access reviews with the actual ability to execute revocations. A review process that identifies overprivileged users but routes remediations to IT tickets that take six weeks to close isn't fixing the problem — it's documenting it.

Access Reviews That Don't Actually Run

The most technically sophisticated access review program is worthless if campaigns don't complete. Incomplete campaigns are an audit finding in themselves, and the reasons they don't complete are almost always the same: reviewers don't understand what they're approving, the review interface is painful enough that managers avoid it, or the review scope is so broad that completing it requires unreasonable time investment.

Auditors distinguish between a completed review and a completed review with meaningful decisions. If 95% of reviewers bulk-approved everything in the last campaign, that's visible in the report data. A rubber-stamp review doesn't satisfy the control intent even if every line item has an approval timestamp.

The fix has three components: scope management (don't review everything at once — prioritize high-risk accounts and stale access), context improvement (give reviewers the information they need to make actual decisions: last login date, permission descriptions, risk flags), and routing (send reviews to people with actual context, not just org chart managers).

Orphaned Accounts After Offboarding

An orphaned account is an active account in a system belonging to someone who is no longer employed or no longer has a valid business reason for access. They're a perennial audit finding because they're easy to identify, clearly indicate a control failure, and represent a persistent security risk — former employees with active credentials is a data breach scenario, not just a compliance finding.

The root cause is almost always the same: offboarding processes that cover SSO-connected applications and miss everything else. When an employee leaves, Okta is disabled, which disables SSO access. But the 23 applications that were never connected to SSO, the contractor accounts that were provisioned outside the standard workflow, the shared credentials that multiple people used — those persist until someone manually cleans them up.

The fix requires visibility first: you can't offboard accounts you don't know exist. SaaS discovery that identifies every application a user has access to — including tools outside the SSO perimeter — is the prerequisite for complete offboarding. Once visibility exists, automated offboarding workflows that cover the full discovered application estate rather than just the SSO-connected stack close the gap.

Missing Evidence for Completed Controls

Organizations sometimes run good processes and still fail audits because they can't produce evidence that the processes ran. An access review campaign that completed on schedule but was tracked in a spreadsheet produces evidence that can be questioned. Did the data reflect the actual state at the time of review? Was the spreadsheet modified after the review? Who approved which lines?

Auditors require non-repudiable evidence: timestamped, system-generated records that show what was reviewed, who made each decision, when, and what action followed. A PDF export from a spreadsheet doesn't meet this standard. A certification report generated by an IGA platform at campaign conclusion — with reviewer names, decision timestamps, and action execution records — does.

The fix is moving evidence generation from manual processes (spreadsheets, email trails, screenshot archives) to system-generated artifacts from the platform that ran the control. This is one of the strongest arguments for IGA tooling even in relatively simple environments: the evidence layer is worth the investment independent of the workflow automation value.

Segregation of Duties Violations Nobody Has Mapped

Segregation of Duties (SoD) violations — cases where one person has conflicting access that would let them initiate and approve the same transaction, or create and pay the same vendor — are a specific audit focus in regulated industries and any SOX-scoped environment. They're also frequently undiscovered because nobody has mapped the SoD rule set against the current access landscape.

Most organizations have intuitions about SoD (the person who approves invoices shouldn't also be able to create vendors) but haven't systematically mapped those intuitions into rules, haven't applied those rules to current access data, and haven't built a remediation process for violations when found.

The fix starts with rule definition — which combinations of access represent unacceptable conflicts in your environment, based on your specific business processes. Once rules are defined, they need to be run against current access data on a recurring basis, violations need to be surfaced for remediation, and preventive controls need to be in place so future provisioning requests that would create a violation are flagged before they're approved rather than discovered in the next access review.

Frequently Asked Questions

What are the most common findings in an IAM audit?

The most recurring IAM audit findings are: orphaned accounts belonging to departed employees, overprivileged users who accumulated access across role changes, access reviews that didn't complete or produced only rubber-stamp approvals, missing or inadequate evidence for completed controls, and Segregation of Duties violations that haven't been mapped or remediated. Most findings are operational rather than technical — they reflect process gaps rather than missing technology.

How do you fix orphaned accounts before an audit?

The immediate fix is a discovery exercise to identify all active accounts across all systems, cross-referenced against current employment records. Any account belonging to a departed employee is an orphaned account requiring immediate closure. The structural fix is implementing automated offboarding workflows with SaaS discovery that covers the full application estate — not just SSO-connected applications — so future offboarding eliminates accounts systematically rather than requiring periodic cleanup campaigns.

Why do access reviews keep failing in audits even when they run?

Access reviews fail audit scrutiny for two reasons beyond not completing: rubber-stamp approvals (reviewers bulk-approved everything without meaningful decision-making, which is visible in the completion data) and inadequate evidence (reviews tracked in spreadsheets rather than system-generated certification reports). Addressing both requires better reviewer context and tooling that generates non-repudiable audit artifacts automatically.

What is privilege creep and how do you prevent it?

Privilege creep is the accumulation of access that users retain from previous roles, projects, and one-time requests over their tenure. It's prevented structurally through automated mover workflows that deprovision old-role access when new-role access is provisioned during role changes, combined with periodic access reviews that have the operational ability to execute revocations — not just identify them and create tickets that take weeks to close.