Identity is the control plane of everything else. Every application control, every segregation of duties rule, every privileged action and every audit trail rests on the organization knowing who each identity is, what it is allowed to do, and that the person or process behind it is who it claims to be. When identity and access management fails, it fails everywhere at once: a terminated employee who keeps a directory account keeps single sign-on to a dozen systems, a service account with a password that never expires is a permanent back door, and a role that accumulated permissions through five job changes is a segregation of duties conflict nobody designed. Most audits touch IAM one system at a time, through a user access review here and a privileged access test there. The program audit looks at the whole thing, because that is the level at which it breaks.
This guide was rewritten in September 2026 and expanded from the original August 2026 version. It sets out the seven domains of an IAM program and the frameworks that define them, works through the joiner-mover-leaver chain and why movers are the hardest case, covers authentication against NIST SP 800-63B-4 and how to measure multi-factor coverage rather than assert it, treats role design and least privilege, non-human identities, and program governance, gives a sixteen-test program and an analytics catalog, and finishes with a worked example at MidState Beverage, whose FY27 ERP user access engagement became a program audit when the same root cause surfaced in three systems. The domain guides sit beneath it: the user access review, privileged access, and the ERP segregation of duties analysis each cover one domain in depth; this guide is the map that connects them.
In this guide
- The seven domains of an IAM program, and the frameworks behind them
- Joiner, mover, leaver: the integrity chain and where it breaks
- Authentication: NIST SP 800-63B-4, multi-factor coverage and the legacy paths
- Authorization: role design, least privilege and role sprawl
- Privileged access, briefly
- Non-human identities: service accounts, keys, bots and cloud roles
- Governance: ownership, policy, metrics and monitoring
- The sixteen-test program
- The analytics catalog
- Worked example: MidState Beverage’s access engagement becomes a program audit
- Common mistakes
The seven domains of an IAM program, and the frameworks behind them
An IAM program is the set of processes, systems and governance by which an organization establishes identities, authenticates them, authorizes what they may do, manages the privileged ones, governs the whole through certification and rules, controls its non-human identities, and runs the infrastructure that makes all of it work. Seven domains, each with its own objective, key controls and characteristic failure, and each mapped to the frameworks auditees cite. NIST SP 800-63-4, published in 2025, sets the digital identity model of identity assurance, authentication assurance and federation assurance levels, and its 800-63B volume on authentication is the reference for password and multi-factor practice. NIST SP 800-53 Rev. 5 carries the control statements in the access control and identification and authentication families. ISO/IEC 27001:2022 spreads identity across Annex A controls 5.15 to 5.18 and 8.2 to 8.5. The IIA’s Cybersecurity Topical Requirement, effective 5 February 2026, makes identity and access one of the control areas an engagement must assess when cybersecurity is in scope, and the Topical Requirements guide covers the applicability rules. The table gives the domains.
| Domain | Objective | Key controls | Characteristic failure |
|---|---|---|---|
| 1 Identity lifecycle | Every identity exists because an authoritative source says it should, with the access its current role requires, and is removed when the source says so | HR as source of truth; provisioning on approval; mover re-provisioning; same-day leaver disable; contractor end dates | Terminated staff with live accounts; movers accumulating access |
| 2 Authentication | The party using an identity is the party it belongs to | Password policy per 800-63B; multi-factor authentication, phishing-resistant for privileged; single sign-on and federation; legacy protocols disabled | MFA claimed at 100 percent, measured at 60; service accounts and legacy protocols bypassing it |
| 3 Authorization | Each identity holds the minimum access its role requires | Role-based access with a catalog; least privilege; request and approval; birthright access limited; segregation of duties rules | Role sprawl; copied users; permissions granted directly outside roles |
| 4 Privileged access | Administrative capability is separated, vaulted, time-bound and monitored | Separate admin accounts; vault and check-out; break-glass; session recording; service-account governance | Standing domain-administrator rights for daily work; shared admin passwords |
| 5 Access governance | Access is periodically certified and conflicts are prevented or mitigated | User access reviews by tier; SoD analysis and provisioning check; exception management | Reviews that approve everything; rulesets nobody acts on |
| 6 Non-human identities | Service accounts, keys, bots and cloud roles have owners, purposes, rotated credentials and no interactive use | Inventory with owners; secrets management; rotation; least privilege for automation; monitoring of interactive use | Passwords that never expire; keys in code; bots with administrator roles |
| 7 Identity infrastructure | The directory, identity provider and HR feed are themselves controlled and resilient | Directory administration under change and privileged access control; HR feed integrity; identity provider configuration; logging and backup of the directory | Directory administered by everyone in IT; HR feed silently broken |
Joiner, mover, leaver: the integrity chain and where it breaks
The lifecycle is a chain from an authoritative source to every system, and its integrity is the single most important property of the program. The source is the HR system for employees and a contractor register, or the vendor management system, for everyone else; every identity in every system should trace to a record in one of them with a status and a manager. Joiners are the easy case: access is requested against a role, approved by the manager and the application owner, and provisioned; the tests are that approval preceded provisioning and that what was provisioned matched what was approved. Leavers are the urgent case: a termination in the source should disable the directory account the same day and remove application access within a defined window, and the test is elapsed time from termination date to disable in each system, computed for every leaver in the period, not sampled. Movers are the hard case: a transfer should remove the old role’s access and grant the new role’s, and in most organizations it only does the second half, because nothing in the process triggers the removal. The mover test compares each transferred employee’s current access to their new role’s catalog entry, and the accumulated access it finds is where segregation of duties conflicts come from.
| Lifecycle event | Control | Evidence | Metric to compute for the period | Common failure |
|---|---|---|---|---|
| Joiner | Request against a catalog role; manager and application owner approval; provisioning by an administrator or an automated feed | Request, approvals dated before provisioning, provisioning record matching the request | Percentage of accounts created with no request; time from approval to provisioning | Accounts created by copying a colleague’s profile; approval after provisioning |
| Mover | Transfer triggers removal of prior role access and grant of new; manager confirms residual access | HR transfer record; access before and after; removal evidence | Movers whose prior-role access remains; average entitlements per tenure | Only additions performed; nobody owns the removal |
| Leaver | HR termination disables directory and application access within policy; contractor end dates enforced automatically | Termination date versus disable timestamp per system | Median and maximum days to disable; leavers active beyond policy; leavers who logged on after termination | No HR feed; managers forget; applications with local accounts missed |
| Contractor and third party | Sponsor, end date, access limited to engagement; extension requires re-approval | Register with sponsor and end date; account expiry set | Contractor accounts past end date; accounts with no sponsor | No register; accounts created as employees |
| Rehire and name change | Reactivation follows the joiner path; identities are not duplicated | Reactivation request and approval | Duplicate identities per person | Old account reactivated with old access |
The leaver metric deserves its own paragraph because it is the one that tells the audit committee whether the program works. Computed for every termination in the period across every in-scope system, it produces a distribution: most leavers disabled within a day, a tail of days or weeks, and a handful never. The tail is the finding, and its shape is the root cause: a uniform delay means the feed runs weekly; a scatter means the process is manual; a set of never-disabled accounts in one application means that application is outside the feed. The root cause method is worth applying before the recommendation is written, because “remind managers to notify IT” has never fixed a leaver process and an HR-to-directory feed with application connectors usually has.
Authentication: NIST SP 800-63B-4, multi-factor coverage and the legacy paths
Authentication practice changed more in the last decade than in the three before it, and many corporate policies have not caught up. NIST SP 800-63B, in its current revision, favors password length over composition rules, drops mandatory periodic rotation in favor of change on evidence of compromise, requires screening of new passwords against lists of known compromised values, and treats multi-factor authentication as the baseline for anything that matters, with phishing-resistant methods, hardware keys and platform authenticators rather than one-time codes delivered by text or push, expected for privileged and high-assurance use. An auditor who tests a password policy against a ninety-day rotation and three-character-class rule is testing a policy that the reference standard now argues against; the test is whether the organization’s policy has been consciously set against the current guidance and whether the systems enforce what the policy says.
Multi-factor coverage is asserted far more often than measured. The measurement has three parts. Which identities are enrolled: every human account in the directory compared with the identity provider’s enrollment records, producing a percentage and a list of the unenrolled. Which applications enforce it: each in-scope application’s authentication path traced to the identity provider with a conditional access or enforcement rule, or identified as a local login that bypasses it. And which paths remain that do not require it: legacy authentication protocols still enabled on the mail platform, VPN profiles with password-only access, service accounts with interactive logon, application programming interfaces accepting basic credentials, and administrative consoles reachable without step-up. The finding is rarely that MFA is absent; it is that it is present for the front door and absent for the three side doors, and the side doors are where attackers go.
| Authentication element | Current expectation | How to test it | Typical finding |
|---|---|---|---|
| Password policy | Length-first; screening against compromised lists; rotation on compromise, not on a calendar; lockout and rate limiting | Policy compared with 800-63B; directory and application settings inspected; screening mechanism demonstrated | Policy unchanged since 2015; applications with weaker local settings than the directory |
| Multi-factor enrollment | All human identities; phishing-resistant for privileged | Enrollment extract reconciled to the user list; privileged accounts checked for method | Enrollment gap in the tail; privileged users on one-time codes |
| Application enforcement | Every in-scope application authenticates through the identity provider under an enforcement rule, or local access is justified and controlled | Authentication path per application; conditional access rules inspected; local accounts inventoried | ERP and legacy systems with local passwords and no MFA |
| Legacy and side-door paths | Legacy protocols disabled; VPN and remote access behind MFA; APIs on tokens; consoles with step-up | Protocol settings; remote access configuration; API authentication inventory | Legacy mail protocol enabled “for one printer”; VPN profile for a vendor with password only |
| Single sign-on and federation | Federation trusts limited and reviewed; session lifetimes appropriate; token signing keys rotated | Trust inventory; identity provider configuration; key rotation evidence | Abandoned federation trusts; session lifetimes of weeks |
| Recovery and reset | Help-desk resets verify identity; self-service reset requires strong factors; resets logged and reviewed | Reset procedure walkthrough; sample of resets; social-engineering test where permitted | Resets on caller’s say-so; the classic entry point for account takeover |
Authorization: role design, least privilege and role sprawl
Authorization is the domain where the program’s design quality shows. A well-designed program grants access through roles that correspond to jobs, described in a catalog in business language, with a small set of birthright entitlements everyone receives and everything else requested and approved against the catalog. A poorly designed one grants access by copying the profile of someone in a similar job, which propagates every accumulated permission that person ever received, and by direct assignment of individual permissions outside any role, which no review can interpret. The tests are structural before they are transactional: does a catalog exist and is it reconciled to the systems; what proportion of access is granted through catalog roles versus direct assignment; how many roles exist relative to jobs; how many users hold more than the median number of entitlements for their job; and, for a sample of joiners, was the access granted the catalog role or a copy of a colleague. Role sprawl, more roles than jobs and roles that differ from each other by a single permission, is the measurable symptom, and role mining, the analysis of actual entitlements to propose consolidated roles, is the remedy, usually a project rather than a finding.
Least privilege is tested against use. Entitlements held but never exercised over a long window are candidates for removal, and the proportion of them is a program metric; the user access review guide describes the data pack that puts usage in front of reviewers. Segregation of duties is authorization’s constraint, and the ERP SoD analysis is the method for finding the combinations that role design or accumulation created; at program level the test is whether a preventive check exists at provisioning so that the analysis stops finding the same conflicts every quarter.
Privileged access, briefly
Privileged access is the domain with its own guide, and the privileged access audit covers inventory completeness, vaulting, break-glass, service accounts and cloud administrator roles in depth. At program level four questions place it in the map. Is administrative capability held in separate accounts from daily-use identities, so that a phished user account is not also a domain administrator? Are those accounts vaulted, checked out for a purpose and a time, and recorded? Is the population of privileged accounts complete and owned, including the local administrators, the database and application administrators, the cloud roles and the backup console? And is standing privilege being reduced, through just-in-time elevation, over time? The worked example below shows why the answer to the first question decides the severity of everything else: eleven accounts in a domain administrator group used for daily work meant that eleven ordinary phishing successes were each a full compromise.
Non-human identities: service accounts, keys, bots and cloud roles
In most organizations the non-human identities outnumber the human ones and are controlled less. Service accounts run applications, interfaces and scheduled jobs; API keys and tokens authenticate integrations; robotic process automation bots log on as users; cloud roles and managed identities let workloads act; certificates identify machines. Each is an identity with access, and the failures are consistent: passwords set never to expire because rotation would break something; credentials stored in scripts, configuration files and code repositories; interactive logon possible with a service account whose password four administrators know; bots granted administrator roles because it was quicker; cloud roles with permissions no workload uses. The program controls are an inventory with a named owner and a stated purpose for every non-human identity, credentials held in a secrets vault and rotated on a schedule the vault enforces, interactive logon denied where the platform allows it and monitored where it does not, least privilege reviewed annually by the owner, and monitoring of non-human identities behaving like humans, logging on interactively, from workstations, outside their schedule. The tests follow the controls, and the inventory completeness test is the one to start with: reconcile the service accounts the security team lists to the accounts of that type in the directory, the databases and the cloud platforms, and the difference is the population nobody owns. The cloud audit guide covers cloud roles and managed identities; robotic process automation bots, whose audit uses are described in the RPA guide, are treated here as service accounts with a scheduler and audited the same way.
Governance: ownership, policy, metrics and monitoring
A program has an owner or it is not a program. The IAM function, whether a team or a role, owns the policy, the catalog, the tooling, the metrics and the exceptions; the security function owns the authentication standards and monitoring; IT operations executes provisioning; application owners own entitlement appropriateness; HR owns the source of truth. The governance tests ask whether those responsibilities are written down and whether the evidence of each shows up: a policy reviewed within the last two years and aligned to the current standards; a metrics pack reported at least quarterly, with leaver time-to-disable, MFA coverage, orphan and dormant rates, privileged account counts, review completion and revocation timeliness, and open exceptions with expiry dates; an exception process where every departure from policy has an owner, a compensating control and an end date; and monitoring of identity events, privileged group changes, mass permission grants, impossible-travel logons, service accounts used interactively, feeding an alert queue that someone works. Identity governance tooling makes most of this measurable; its absence makes it laborious, not optional. The IT audit plan is where the program’s coverage across the estate is decided, and the identity infrastructure itself, the directory and identity provider, is an in-scope system in its own right with change, privileged access and backup controls to test.
The sixteen-test program
The program below covers the seven domains for an organization’s in-scope systems, and it is written to be scoped down: a first engagement may take the lifecycle, authentication and privileged tests and leave role design and non-human identities for the following year. Populations are computed in full where the data allows, which for the lifecycle and analytics tests it usually does; where sampling is needed the standard sizes apply and the rationale goes in a sampling memo. Evidence standards follow the audit evidence guide, and the extracts are treated as IPE.
| # | Test | Population | Evidence | What a failure looks like |
|---|---|---|---|---|
| 1 | Reconcile every in-scope system’s user list to HR and the contractor register through the identity map | All accounts, all in-scope systems | Extracts with queries; identity map; reconciliation with dispositions | Orphans; terminated persons active; no identity map |
| 2 | Compute leaver time-to-disable per system for every termination in the period | All leavers | HR termination dates; disable timestamps per system | Tail beyond policy; never-disabled accounts; post-termination logons |
| 3 | Test joiner approvals before provisioning and match to request | Joiners in the period; 25 to 40 | Requests, approvals, provisioning records | Accounts with no request; profile copies; approval after provisioning |
| 4 | Test mover access removal | Transfers in the period; all or 25 | Access before and after; catalog role for new job | Prior-role access retained |
| 5 | Test contractor end-date enforcement and sponsorship | All contractor accounts | Register; account expiry settings | Accounts past end date; no sponsor |
| 6 | Compare password and lockout settings with policy and with 800-63B | Directory and each in-scope application | Configuration inspection; policy | Applications weaker than the directory; obsolete rules |
| 7 | Measure MFA enrollment and enforcement, and inventory the side-door paths | All human identities; all in-scope applications; remote access and legacy protocols | Enrollment extract; authentication path per application; protocol and VPN configuration | Enrollment gap; local logins; legacy protocols enabled |
| 8 | Test privileged account separation, vaulting and completeness | All privileged accounts across layers | Inventory reconciled to platform group memberships; vault enrollment; check-out records | Daily-use accounts with admin rights; unvaulted admins; incomplete inventory |
| 9 | Evaluate role catalog and grant path | All roles in in-scope systems; sample of joiners | Catalog; proportion of direct assignments; sample tracing | No catalog; direct assignments dominant; copied profiles |
| 10 | Run or review the SoD analysis and the provisioning check | All users; the check configuration | Analysis results with noise sequence; provisioning check demonstrated | No preventive check; the same conflicts every quarter |
| 11 | Test the user access review by tier | Reviews in the period | Completeness records, decision-quality measures, revocation completion checks | Approve-all; revocations not executed |
| 12 | Reconcile the non-human identity inventory to the platforms and test ownership, rotation and interactive logon | All service accounts, keys, bots, cloud roles | Inventory; directory and cloud extracts; vault rotation records; logon type logs | Unowned accounts; never-expiring passwords; interactive use |
| 13 | Test identity infrastructure controls: directory administration, HR feed integrity, identity provider configuration, directory backup | The directory and identity provider | Privileged group change log; feed monitoring; configuration review; restore evidence | Feed failures unnoticed; directory administered widely; no directory restore ever performed |
| 14 | Test exception management | All open exceptions | Register with owner, compensating control, expiry | Perpetual exceptions; no compensating control |
| 15 | Test identity monitoring and alert handling | Alert rules; alerts in the period; 25 | Rule inventory; alert dispositions | Rules absent for privileged changes; alerts unworked |
| 16 | Evaluate governance: ownership, policy currency, metrics reporting | Program documentation; reports in the period | RACI, policy with review date, metrics pack | No owner; policy from 2015; no metrics |
The analytics catalog
Most of the program’s tests can be run as analytics over full populations rather than as samples, and once built they become continuous monitoring the organization can run itself; the continuous auditing guide covers the transition. The catalog below lists the ones that pay back fastest. Each requires the identity map, which is the reason the map is built first in every engagement.
| Analytic | Data | What it finds |
|---|---|---|
| Terminated but active | HR terminations joined to each system’s active accounts | Leaver process failures per system |
| Post-termination activity | Terminations joined to logon and transaction logs | Accounts used after the person left; the finding that goes to the audit committee |
| Dormant accounts | Last logon per account per system | Accounts unused for 90 or 180 days; removal candidates |
| Orphan identities | System accounts not in HR or the contractor register | Unowned access; generic accounts |
| MFA gap | Human identities joined to enrollment records | Unenrolled users by department and privilege |
| Privileged without vault | Privileged group memberships joined to vault enrollment | Standing administrators outside the vault |
| Daily-use accounts with admin rights | Privileged memberships joined to interactive logon and mail use | Administrators reading email with domain-admin tokens |
| Never-expiring and stale service credentials | Service account password-last-set and expiry flags | Rotation failures; credentials older than policy |
| Service accounts logging on interactively | Logon type per service account | Humans using service credentials |
| Access granted without request | Provisioning events joined to requests | Administrator-granted access outside the process |
| Mover accumulation | Transfers joined to entitlements before and after | Prior-role access retained; SoD risk |
| Cross-system leaver lag | Disable timestamps per system per leaver | Applications outside the feed |
Worked example: MidState Beverage’s access engagement becomes a program audit
MidState Beverage, the three-state drinks distributor with twelve depots and roughly 1,400 employees that appears throughout this site’s IT guides, planned its FY27 ERP user access engagement at 550 hours plus 140 co-sourced, scoped to the ERP and its route-accounting module. The identity map built in the first two weeks, linking HR employee identifiers to accounts in the ERP, the directory, the payroll provider’s portal and the banking portal, changed the scope: the same terminated employees appeared active in more than one system, and the CAE re-scoped the engagement under Standard 9.4 as a program audit across the four systems, with the ERP still the center of gravity.
The lifecycle tests told the story. Of 96 terminations in the nine-month period, the directory account was disabled within one day for 61, within a week for 22, within a month for 9, and never for 4, because the process depended on the depot manager emailing IT; nine former employees remained active in the ERP and three in the payroll portal, and two of the ERP accounts had logged on after termination, in both cases former depot administrators who had been rehired as seasonal drivers under new accounts and used the old ones out of habit. The banking portal, administered by two people in treasury who removed leavers from a monthly HR list, had none. Movers were worse than leavers in aggregate: 38 of 44 transferred employees retained their prior role’s access, which was the origin of most of the 214 segregation of duties hits the SoD analysis found. Authentication tests measured MFA enrollment at 100 percent for remote access through the directory but found the ERP reachable over the VPN with its local password only, a legacy mail protocol enabled for a depot label printer, and a vendor VPN profile with no second factor. Privileged access found eleven accounts in the domain administrator group used for daily work, including reading email, and no vault. Non-human identities found 38 service accounts, 14 with passwords set never to expire, 6 able to log on interactively, and the route-accounting interface account’s password recorded in a shared spreadsheet.
| Domain | Result | Finding and rating |
|---|---|---|
| Identity lifecycle | 4 of 96 leavers never disabled; 13 beyond a week; 9 active in ERP, 3 in payroll portal; 2 post-termination logons; 38 of 44 movers retained prior access | Leaver process without an HR feed (High); mover removal absent (Medium) |
| Authentication | MFA complete for directory remote access; ERP local passwords over VPN; legacy protocol and vendor VPN gaps | Side-door authentication paths (Medium) |
| Authorization | No role catalog; 61 percent of ERP access by direct assignment or profile copy; 74 roles for 31 jobs | Role design (Medium); catalog built during the engagement |
| Privileged access | 11 daily-use domain administrators; no vault; backup console in the same group | Standing privilege (High) |
| Access governance | Review approving everything; SoD ruleset unused | Covered in the review and SoD workstreams |
| Non-human identities | 38 service accounts; 14 never-expiring; 6 interactive; interface password in a spreadsheet | Service account governance (Medium) |
| Identity infrastructure | Directory administered by the 11; no HR feed; directory restore never tested | Combined into the privileged and lifecycle findings; restore test scheduled with the backup review |
The report was organized by domain with one root cause at the top: the absence of an authoritative feed from HR to the directory and the applications, which the lifecycle, governance and review findings all traced back to and which the payroll provider’s report review had found from its own side. The recommendations were correspondingly few: build the HR feed with connectors to the ERP and the payroll portal, separate administrative accounts and stand up a vault, close the three side-door authentication paths, and adopt the role catalog and the rebuilt review that the engagement had produced. The audit committee received the leaver distribution as a chart, the two post-termination logons as a sentence, and a program metrics pack that the IT manager agreed to produce quarterly. The engagement closed at 604 in-house hours against the 550 planned, the excess reported as the cost of the re-scope, and the FY28 plan carried a follow-up of 120 hours to re-run the analytics catalog once the feed was live.
Common mistakes
- Auditing one system at a time. The program breaks across systems; build the identity map first and test the lifecycle across all of them.
- Sampling leavers. Compute time-to-disable for every termination; the tail is the finding and its shape is the root cause.
- Forgetting movers. Accumulated access from transfers is where segregation of duties conflicts are born.
- Testing passwords against 2015 rules. Compare policy and settings with current NIST SP 800-63B guidance and test what the systems enforce.
- Accepting “MFA is at 100 percent.” Measure enrollment, enforcement per application, and the side-door paths.
- Treating privileged access as an IT hygiene item. Daily-use accounts with administrator rights make every phishing success a full compromise; rate accordingly.
- Ignoring non-human identities. They outnumber humans and are controlled less; reconcile the inventory to the platforms.
- Reviewing the review without the data pack. A review with no usage or conflict data is a signature exercise however well it is evidenced.
- Writing seven findings with one cause. Find the root cause, usually the missing feed or the missing owner, and write the recommendation once.
- Leaving the identity infrastructure out of scope. The directory and identity provider are in-scope systems with change, privileged access and backup controls of their own.
Related guides
- How to perform a user access review that works
- How to audit privileged access
- How to run an ERP segregation of duties analysis
- Segregation of duties beyond the ERP
- Auditing cybersecurity programs
- Auditing cloud computing
- IT general controls: the complete primer
- The IIA Topical Requirements
- Building the IT audit plan
- How to audit backups and recovery
- How to review a SOC 1 report
- Root cause analysis for audit findings
- Continuous auditing vs. continuous monitoring
Leave a Reply