Identity and access management programmes report activity, such as applications onboarded and campaigns closed, but rarely run a repeatable audit that shows whether access is actually under control. This health check is that audit: a run sheet of twelve KPIs for workforce identity, each with a formula, a data source type, thresholds, a cadence and an owner, plus a findings log and a remediation map. It is run quarterly by the IAM team, checked by internal audit or the second line, and signed off by the identity programme owner. The programme design itself, its roles, operating model and roadmap, is covered in the Identity Security Programme Guide; this page assumes that programme exists and tests it.
What this health check covers
The Identity Security Metrics Guide lists identity metrics across many areas. This page differs in three ways: it narrows to twelve audit KPIs for an IAM programme, it fixes each one as a numerator over a denominator so two auditors get the same answer, and it adds the cadence, thresholds and findings workflow that turn numbers into closed actions. If you searched for an identity and access management audit checklist or a set of IAM KPIs with targets, this is the working version.
Key takeaways
- Coverage first, then quality: SSO and MFA coverage tell you how much of the estate the controls reach; the phishing-resistant share tells you how strong they are where they reach.
- Lifecycle numbers find the real exposure: leaver disable latency, orphan rate and dormant rate show access that should not exist, which is what attackers reuse.
- Reviews are measured by what they remove: completion alone rewards rubber-stamping, so pair it with the revoke rate.
- The source of truth is a KPI too: if the HR record and the directory disagree, every lifecycle metric built on them is wrong.
- Thresholds are recommendations: the green, amber and red values are NHI Mgmt Group starting points; baseline your own and record the rationale for each change.
How to use this template
Copy the metrics table and the findings log into your own tracker, then run this IAM Programme Health Check at the cadence set out below. Collect each figure from the data sources described, score it against the green, amber and red thresholds, and record every amber or red result as a finding with an owner and a due date. Keep each completed review so you can compare results quarter on quarter: the trend matters as much as any single score.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| Leaver latency and orphan sweep (I5, I6) | Monthly | IAM operations | IAM programme owner | HR leaver extract, directory and application account extracts, reconciliation sheet |
| Authentication coverage (I1, I2, I3) | Monthly | IAM engineering | IAM programme owner | IdP application list, authentication method registration export, sign-in log sample |
| Full KPI run (I1 to I12) | Quarterly | IAM programme owner | CISO | KPI workbook, findings log, sign-off record |
| Review quality and SoD (I8, I9, I10) | After each certification campaign | Identity governance lead | Internal audit | Campaign decision export, SoD rule set version, conflict report |
| Independent re-performance | Yearly | Internal audit or second line | Audit committee | Re-performed samples, variance notes |
Metrics
Scope is workforce identities (employees, contractors, partners with workforce accounts). Non-human identities have their own health checks. NHI Mgmt Group recommended thresholds; adjust to your risk appetite.
| ID | Metric | Formula (numerator / denominator) | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| I1 | SSO coverage | In-scope applications authenticating through the central IdP / in-scope applications in the application inventory | IdP application list; application or CMDB inventory | ≥ 95% | 80% to below 95% | < 80% |
| I2 | MFA coverage | Active workforce accounts for which MFA is enforced at sign-in (not merely registered) / active workforce accounts | IdP policy assignments; authentication method registration export; sign-in logs | ≥ 99% | 95% to below 99% | < 95% |
| I3 | Phishing-resistant MFA share | Accounts whose required sign-in method is phishing-resistant / active workforce accounts; reported separately for privileged accounts | Authentication method registration export; sign-in logs showing method used | Privileged 100%; all users rising each quarter | Privileged 95% to below 100% | Privileged < 95% |
| I4 | JML automation rate | Joiner, mover and leaver events actioned automatically from the HR trigger / all JML events in the period | Provisioning engine logs; HR event feed; service desk tickets | ≥ 90% | 70% to below 90% | < 70% |
| I5 | Leaver disable latency | Median and 95th percentile hours from HR termination effective time to disable of the primary account and IdP sessions | HR leaver extract; directory and IdP audit logs | P95 ≤ 24 h; privileged same day | P95 above 24 h to 72 h | P95 > 72 h, or any privileged leaver active past 24 h |
| I6 | Orphan account rate | Enabled accounts with no matching active HR or sponsor record / enabled accounts (directory and in-scope applications) | Directory and application account extracts joined to HR record | ≤ 0.5% | Above 0.5% to 2% | > 2% |
| I7 | Dormant account rate | Enabled accounts with no successful sign-in in the last 90 days / enabled accounts | IdP and directory last sign-in attributes; application last-login data | ≤ 3% | Above 3% to 8% | > 8% |
| I8 | Access review completion | Review items decided by the deadline / review items issued in the campaign | Certification campaign records | ≥ 98% | 90% to below 98% | < 90% |
| I9 | Rubber-stamp rate | Reviewers who approved 100% of 20 or more items, or decided items faster than a set per-item time / reviewers in the campaign; alongside revoke rate = items revoked / items decided | Campaign decision export with timestamps | ≤ 5% of reviewers; revoke rate above zero in every campaign | Above 5% to 15% | > 15%, or a campaign with zero revocations |
| I10 | SoD violations | Users holding a conflicting entitlement pair with no approved mitigating control / users in scope of the SoD rule set | SoD rule set; entitlement extracts from in-scope applications | 0 unmitigated | Unmitigated, under 30 days old | Unmitigated, 30 days or older |
| I11 | Local account share | Enabled accounts in in-scope applications and systems that authenticate locally rather than via the IdP / enabled accounts in those systems | Application and server local account extracts; IdP application list | ≤ 5%, each one registered | Above 5% to 15% | > 15%, or any unregistered local admin |
| I12 | Identity source of truth match rate | Directory accounts whose status, manager and department match the HR record / directory accounts with an HR link | HR system of record; directory attribute export | ≥ 99% | 95% to below 99% | < 95% |
Notes on the formulas
- I2 means enforced: a user who registered a method but is excluded from the sign-in policy counts as not covered. The MFA Coverage Measurement guide explains exclusions and how to count them, and the How to Find Accounts Excluded From MFA and Conditional Access shows where they hide.
- I3 uses the NIST definition: NIST SP 800-63B-4 states that out-of-band authentication, including push approval, and one-time passwords are not phishing-resistant. CISA's phishing-resistant MFA fact sheet names FIDO/WebAuthn and PKI-based smart cards as the phishing-resistant options. Count only accounts that are required to use such a method, not those that merely could.
- I5 uses the effective time, not the ticket time: latency starts when employment ends in HR, not when someone raises a ticket. Report median and 95th percentile because averages hide the long tail of forgotten leavers.
- I9 needs a fixed definition: set the bulk-approval threshold and the minimum per-item decision time once, publish them to reviewers, and keep them stable so trends are comparable.
- I11 includes break-glass accounts: they are legitimate local accounts but must be in a register with an owner and monitored use. See the Break-Glass Account Guide.
How to collect the data
- Take the HR extract first: all active workers and all terminations in the period with effective dates and times, from the HR system of record. Every lifecycle KPI (I4 to I7, I12) joins to it.
- Export identity stores: directory account list with enabled state, last sign-in, manager, department and HR identifier; IdP application list; authentication method registration export; policy assignments and exclusions.
- Export in-scope applications: account and entitlement lists from each application in scope of SSO, SoD and reviews, including locally authenticated accounts for I11. Use the application inventory or CMDB as the denominator for I1, not the IdP's own list.
- Pull logs for a fixed window: IdP sign-in logs (method used, for I3), directory audit logs (disable events, for I5) and provisioning engine logs (automatic versus manual, for I4).
- Pull governance records: certification campaign decisions with timestamps and reviewer IDs (I8, I9), and the current SoD rule set version with its conflict report and approved mitigations (I10).
- Reconcile and sample: match accounts to HR records using the HR identifier, not display name. Then trace five random records per KPI from source to result; record any variance. The Identity Data Quality and Authoritative Sources Guide covers matching rules.
Red flags that need action now
- Any privileged leaver whose account or sessions were still active more than 24 hours after termination (I5). Treat as a possible incident and follow the Leaver Retained Access Incident Playbook.
- Privileged accounts able to sign in with SMS, voice, OTP or push alone (I3).
- Policy exclusions from MFA with no owner or expiry date (I2). The MFA Exception Register Template gives a format.
- Orphan accounts with recent sign-in activity (I6): someone is using an account nobody owns.
- A review campaign with zero revocations, or reviewers approving hundreds of items in minutes (I9).
- An unmitigated SoD conflict in a finance or payment process (I10).
- Unregistered local administrator accounts on critical systems (I11).
- HR and directory disagreeing on employment status for any active account (I12).
Findings log
| Finding ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-IAM-01 | [Number] leavers with enabled accounts beyond 72 hours | I5 | [High / Medium / Low] | [Role] | [Date] | [Open / In progress / Closed / Risk accepted] |
| HC-IAM-02 | [Number] privileged accounts without a phishing-resistant method enforced | I3 | [Severity] | [Role] | [Date] | [Status] |
| HC-IAM-03 | [Application] outside SSO with [number] local accounts | I1, I11 | [Severity] | [Role] | [Date] | [Status] |
| HC-IAM-04 | [Number] reviewers met the rubber-stamp definition in [campaign] | I9 | [Severity] | [Role] | [Date] | [Status] |
| HC-IAM-05 | [Finding] | [Metric] | [Severity] | [Role] | [Date] | [Status] |
Group accounts with a shared root cause into one finding. Risk accepted findings carry an expiry date and the approver's name and are re-opened at the next quarterly run.
Remediation map
| Finding type | Metrics | Where the fix is explained |
|---|---|---|
| Applications outside SSO | I1 | Identity Provider and SSO Security Guide; Entitlement Catalogue and Application Onboarding Guide |
| MFA gaps and weak methods | I2, I3 | MFA Guide; Phishing-Resistant MFA Guide |
| Manual or slow lifecycle | I4, I5 | Joiner-Mover-Leaver Guide; Identity Lifecycle Event Design Guide |
| Orphan and dormant accounts | I6, I7 | Orphaned and Dormant Accounts |
| Weak certification campaigns | I8, I9 | Access Reviews Guide; Access Review Checklist |
| SoD conflicts | I10 | Segregation of Duties Guide; Segregation of Duties Matrix Template |
| Local and unmanaged accounts | I11 | Local Administrator Password Solution (LAPS) Guide; Privileged Account Discovery and Onboarding Guide |
| HR and directory mismatch | I12 | Identity Data Quality and Authoritative Sources Guide |
Related guides
- Identity Security Programme Guide: the programme this health check audits.
- Identity Security Maturity Model: map the KPI results to a maturity level.
- Identity Security Metrics Guide: the wider metric catalogue, including NHI and AI agent metrics.
- Leaver Retained Access Incident Playbook: when a lifecycle finding becomes an incident.
- Orphaned and Dormant Accounts: background on the two lifecycle KPIs that most often turn red.
References
Framework anchors for the metrics: NIST SP 800-53 AC-2 (Account Management), AC-2(1) (Automated System Account Management), AC-2(3) (Disable Accounts), AC-5 (Separation of Duties), AC-6(7) (Review of User Privileges), IA-2(1) and IA-2(2) (multi-factor authentication to privileged and non-privileged accounts), IA-2(8) (replay resistant access), PS-4 (Personnel Termination) and PS-5 (Personnel Transfer); NIST CSF 2.0 PR.AA-01 and PR.AA-05; CIS Controls v8.1 Control 5 (Account Management) and Control 6 (Access Control Management).
- NIST: SP 800-53 Rev. 5
- NIST: SP 800-63B-4 Authentication and Authenticator Management
- NIST: Cybersecurity Framework 2.0
- CISA: Implementing Phishing-Resistant MFA
- CIS: Control 5 Account Management
- CIS: Control 6 Access Control Management
Related NHI Mgmt Group resources: Identity Security Programme Guide, Identity Security Maturity Model, Joiner-Mover-Leaver Guide, Access Reviews Guide.