How to Conduct an Identity and Access Management Audit

You ran the audit. Three weeks of pulling reports, chasing managers for sign-offs, and stitching together spreadsheets that never quite agreed. You passed. And ninety days from now, you'll do the whole thing again, because almost nothing you found got fixed.

An identity and access management audit is a test of whether your access controls work the way your documentation says they do, across every identity and every app you run. Conducting one means inventorying who and what has access, reconciling that against an authoritative record, testing privileges and authentication, and proving your findings with evidence an auditor will accept. This article walks that method step by step, and makes the case for why the quarterly version of it is the wrong way to work.

What an Identity and Access Management Audit Verifies

An IAM audit verifies that your access controls operate the way they're designed to, not that they exist on paper. That single distinction separates a real audit from a documentation review, and it's where most audits quietly fail. Plenty of teams keep a clean access matrix on a slide and a least-privilege policy in a wiki nobody's opened in a year. The audit's only job is to find out whether the reality underneath matches the story on top.

Four areas sit at the center of what you're testing

Identity lifecycle

How access gets granted when someone joins, changed when their role changes, and revoked when they leave. Orphaned accounts, live credentials belonging to people who walked out months ago, are the most common finding here and the most dangerous. Stolen credentials remain one of the most common ways attackers get their first foothold, per the Verizon Data Breach Investigations Report, and an orphaned account is a credential nobody's watching.

Authentication strength

Whether the way people prove who they are is strong enough for what it guards. Multi-factor authentication on a marketing tool and on a production database are not the same bar, and treating them as one is how high-value access ends up protected by a six-digit text.

Authorization

Whether privileges match documented job functions, whether anyone holds standing admin rights they touch twice a year, and whether a single account can both initiate and approve the same action. This is where least privilege and separation of duties get tested, and where fraud either has room to hide or doesn't.

Access certification

Whether the periodic reviews, the ones where managers sign off on their team's access, change anything at all. A certification cycle that shows full completion and near-zero revocations isn't proof of clean access. It's proof that nobody read the list.

Identity and Access Management Audit Scope and Compliance Frameworks

A defensible audit starts before you pull a single report, with two decisions: what's in scope and what you'll measure access against. Get those wrong and every finding you produce is arguable.

Scope is a question of honesty. Your identity provider is the easy part. The hard part is everything that authenticates around it: cloud platforms, SaaS apps signed up for on a credit card, on-prem applications, databases, and the local and shared accounts every environment accumulates and nobody can quite account for. The accounts you decide to leave out of scope are, reliably, the ones that show up in the next incident report. If you can't justify an exclusion in writing, it's in scope.

Scope also means knowing which rules you answer to. A publicly traded company tests access controls tied to financial reporting under SOX Section 404. A healthcare organization treats access control as a required standard under the HIPAA Security Rule. SOC 2, ISO 27001 Annex A, and PCI DSS Requirements 7 and 8 each carry access expectations of their own. If you map to NIST SP 800-53, identity controls live mostly in the Access Control and Identification and Authentication families: AC-2 for account management, AC-6 for least privilege, and IA-2, IA-5, and IA-8 for authentication. One detail worth getting right, because auditors do: NIST sets no fixed 24-hour deprovisioning clock. Removal windows are organization-defined. Audit against the policy you wrote, not a number someone half-remembers from a certification course.

Then name your source of truth. For most teams that's the HR record for employees, a contractor roster alongside it, and a real inventory of machine identities. Every reconciliation in the audit compares live access against that one authoritative source. Without an agreed source, the audit collapses into an argument about whose export is correct, and arguments don't close findings.

How to Conduct an Identity and Access Management Audit

Here's the sequence that turns access sprawl into findings you can stand behind. Run it in order, because each step depends on the one before it, and a gap early on becomes a hole an auditor finds before you do.

Step 1. Inventory every identity, human and machine

Start with a single list of every account that can authenticate into anything in scope. Employees and contractors, yes, but also service accounts, API keys, and tokens, the credentials holding quiet access to your most sensitive data. If assembling this list takes weeks, you've already found your first finding. Most teams are surprised twice here: the inventory is bigger than they thought, and machine identities make up far more of it than anyone was tracking.

Step 2. Reconcile against HR and your source of truth

Match every active account to your authoritative record of who should have it. Three buckets matter most: orphaned accounts belonging to people who've left, stale accounts past your login threshold, and shared accounts with no owner. Orphaned and stale accounts are pure risk with no offsetting benefit, and they're the cleanest evidence you have that offboarding leaks. Name names. A finding lands harder as "these eleven accounts" than as "some accounts."

Step 3. Assess privileges for least privilege and separation of duties

Compare what each account can do against what its role needs under your IAM policies. Hunt for standing admin rights used rarely or never, permissions that piled up across old roles and never got cleaned out, and any account that can both create and approve the same transaction. Separation-of-duties conflicts are the findings auditors weigh most heavily, because those are the ones that let one person commit and conceal fraud. Build the conflict matrix before you test, so you're measuring against a defined standard instead of intuition.

Step 4. Test authentication strength

Confirm that authentication matches the value of what sits behind it. Check that MFA is enforced where it counts, on privileged accounts, remote access, and high-value targets, not just switched on somewhere in the tenant and assumed everywhere. Be exact about assurance levels: phishing-resistant authentication is a NIST 800-63B AAL3 requirement, and SMS-based MFA does not satisfy it. If your most sensitive access is guarded by codes texted to a phone, write the finding.

Step 5. Read the access certification for what it changed

Pull the records from your last certification cycle and look straight past the completion rate. Revocations are the number that tells the truth. A cycle where every manager certified on time and almost nothing was removed is the clearest rubber-stamp signal there is, because real access always drifts and real reviews produce changes. If reviewers approved bulk lists without ever seeing the entitlements underneath, the certification was theater, and an auditor will treat it that way.

Step 6. Develop findings with evidence and severity

Turn each issue into a finding tied to a specific artifact, then rank it by risk. Vague findings get talked away in the management response; precise ones don't. "These fourteen accounts belonging to departed employees kept production access for ninety-plus days" survives any pushback, because the evidence is attached and the facts aren't in dispute. Severity ranking is what tells leadership where to spend remediation effort first.

Step 7. Assign remediation with owners and deadlines

A finding with no owner and no date is a finding you'll write again next quarter, word for word. Give each one a named owner, a deadline scaled to its risk, and a follow-up check scheduled before you close the engagement. Everything up to this point is diagnosis. This is the only step that changes the patient.

One more thing before you start collecting. Auditors ask for specific artifacts in specific formats, and the moment your identity and access management tools can't produce one the way it's requested, the audit stalls while you build it by hand. Have these ready before anyone asks.

‍

The Accounts Your Audit Will Tend to Miss

Here's the part most audits skip, and it's the part that should worry you most. In nearly every environment, the identities that never appear in a quarterly review now outnumber the ones that do. Service accounts, API keys, tokens, and the AI agents increasingly wired into your stack make up the majority of who, and what, can act inside your environment. Almost none of them get audited the way a human employee does.

They're also the most exposed accounts you own. A service account routinely carries standing privilege, credentials that never expire, and no named owner to ask whether it still needs to exist. An AI agent goes further. It can authenticate, take action, and chain one permission into the next at machine speed, which means an over-permissioned agent isn't a risk sitting still, it's a risk in motion. Practitioners who've started auditing their agents directly keep reporting the same thing: access to their existing tooling rated as zero risk turned out to be anything but.

Bringing these identities into an audit takes a deliberate pass of its own. Discover every service account, API key, and token across all your platforms, not just the ones registered in your primary directory. Map each to an owner and a purpose, and treat anything you can't explain as a finding on its face. Flag credentials with standing privilege or no rotation schedule. Then hold your AI agents to the same standard you hold people to: defined entitlements, an accountable human owner, and a review cadence that doesn't lapse.

The position here is plain. An audit that stops at employees has examined the safer half of the environment and signed a clean opinion on the half it never looked at. The accounts most likely to be exploited, and least likely to be missed by an attacker, are exactly the ones a human-only audit walks right past.

Continuous Auditing Versus The Point-in-Time Access Review

The deeper problem with a point-in-time audit isn't the work it takes. It's that it expires. The day you ship your findings, they begin to rot, because access keeps moving while your snapshot holds still. You certified Tuesday's access on Tuesday; by Friday, half of it is already a different shape.

And the snapshot misleads in both directions. A well-run environment can look alarming at audit time because access happened to spike that week for a launch. A neglected one can look pristine because someone scrambled to remediate the weekend before fieldwork. You're certifying a photograph of something that never stops moving, and then living with that photograph for a quarter.

Continuous auditing has quietly become one of the best practices for identity and access management, and it solves the timing problem by changing what gets reviewed in the first place. Rather than re-examining every entitlement on a calendar, you review only the access that changed since the last review. Risky changes surface when they happen, not three months later buried in a spreadsheet. Evidence accumulates as you go, so you're never reconstructing a year of access decisions the night before an auditor arrives.

This is the model Lumos was built around. Its delta access reviews surface only what's changed since the last cycle, so reviewers weigh real differences instead of rubber-stamping the same unchanged list every quarter, the exact behavior that produces those 100-percent-complete, zero-revocation reports, the identity and access management metrics auditors have learned to distrust. The load comes down fast. Pluralsight went from reviewing 20 apps over two months each quarter to 200 apps in under two weeks, because the review finally moved at the speed access does.

That's the whole argument in one contrast. One approach treats the audit as an ordeal you survive four times a year. The other treats it as a condition you hold, where audit-ready is just the resting state and the quarterly fire drill stops being part of the job.

Turning IAM Audit Findings Into Remediation

A findings list isn't the deliverable. Fixed access is. An audit that ends in a tidy PDF and no follow-through has changed exactly nothing, and you'll rediscover the same orphaned accounts, in the same apps, next quarter.

Start by giving every finding an owner and a deadline scaled to its risk. A departed admin with live production access gets handled this week. A low-risk stale account in a sandbox can wait its turn. Prioritize without flinching, because treating every finding as equally urgent is how the genuinely urgent ones slip through.

Then close the loop so the same problems can't quietly regrow. The findings that recur, orphaned accounts, privilege creep, and offboarding that lags behind the exit, are precisely the ones IAM automation handles better than any human ever will. Time-bound and just-in-time access means privilege expires on its own rather than piling up until a review eventually notices. Joiner-mover-leaver automation means access disappears the moment employment ends, not whenever a ticket finally gets worked.

Then measure what you've done in the numbers leadership already watches. Fewer access tickets. Faster offboarding. Less standing privilege sitting idle, waiting to be abused. A program that pushes those down between audits is doing the real work, and it pays off twice, because the next audit is shorter when there's less drift left to find.

Make Identity and Access Management Auditing Continuous

Boiled down, an IAM audit is a choice between two postures. One is the quarterly snapshot: three weeks of spreadsheet archaeology that certifies a single moment, passes the exam, and leaves the same drift waiting to be rediscovered next time. The other is a continuous program that reviews what changed, covers every identity including the machine and AI accounts that now make up most of them, and treats audit-ready as a standing condition rather than a deadline you sprint toward. That posture is the spine of a modern identity and access management strategy.

The method in this guide will carry you through either one. But once you've run an audit by hand and watched the same findings resurface ninety days later, untouched, the case for running it continuously stops being a preference. It starts being the obvious way to work.

If you're tired of running the same audit by hand every quarter, this is where Lumos earns its keep. It discovers every identity across your apps, human and machine, keeps policy current without the manual upkeep legacy tools demand, and runs access reviews continuously, so being audit-ready becomes your resting state instead of a quarterly scramble. The fastest way to know whether that holds up in your own environment is to watch it run against your real access, so book a demo and see how Lumos works.

‍