IGA KPIs and KRIs to Report to the Board: Access Review and Joiner-Mover-Leaver Outcomes

Boards are usually shown identity governance as campaign completion rates and applications onboarded, numbers that can look perfect while leavers keep access and reviewers approve everything. This guide sets out a small set of board-level key performance indicators (KPIs) and key risk indicators (KRIs) for an identity governance and administration (IGA) programme: what each one tells a director, how to define and calculate it, what threshold should trigger escalation, and how to present the trend. It covers access review quality, joiner, mover and leaver timeliness, and the orphaned and excess access that accumulates between reviews. It is written for IGA programme owners, CISOs and the risk and audit teams who prepare committee packs. Operational platform measures such as connector failures and catalogue ownership belong in the quarterly Identity governance and administration (IGA) platform health check; the wider identity metric catalogue is in the Identity Security Metrics Guide.

Key takeaways

• Report outcomes, not activity. A board needs to know whether inappropriate access is shrinking and how long it survives, not how many campaigns ran.
• Separate KPIs from KRIs. KPIs show whether the programme is performing; KRIs show exposure against risk appetite and need tolerance thresholds agreed in advance.
• Eight measures are enough. NIST SP 800-55 Volume 1 counts only quantitative results as measures; pick eight, define each precisely and keep them stable for at least four quarters so trends mean something.
• Show the tail, not just the average. A median leaver removal time of hours can hide privileged leavers still active weeks later; report the 95th percentile and the named exceptions.
• Independent data or no data. Figures computed and approved only by the team that runs the platform are weak assurance; have the second or third line sample them.

KPIs, KRIs and what a board should see

NIST SP 800-55 Volume 1 (December 2024) defines four measure types: implementation (progress of controls, usually as percentages), effectiveness (whether controls achieve the desired outcome), efficiency (how timely controls are) and impact (the connection to mission and objectives, the type executives most seek). It also says that only quantitative results count as measures, and that reports should state whether findings fit the organisation's risk appetite. A board set for IGA should therefore lean on effectiveness and efficiency measures and frame each against appetite.

Board measures and operational measures should be different but connected. The health check tracks twelve platform and process measures every quarter; this page keeps only two of them (orphaned accounts and leaver disablement within service level) and adds the outcomes a director can act on. When a board measure turns amber, the health check figures explain why.

The board set at a glance

B1 corresponds to health check measure IGA-08 and B7 to IGA-03; the others are not in the health check. Keep the IDs fixed in every pack so trends can be compared quarter to quarter.

Defining and calculating each measure

Every definition below states scope, formula, source and the reporting cut. These are NHI Mgmt Group recommended definitions, not requirements of any standard; adjust them, write them down and change them only with a note in the pack.

B1 Leaver access removed within service level

Formula: leavers whose accounts in every critical application were disabled within the agreed service level after the HR effective date, divided by all leavers in the quarter. Report: the percentage, the median and 95th percentile hours to last account disabled, and privileged leavers separately. Source: HR effective dates joined to disablement events in the directory and critical applications, including those fulfilled manually. Measure to the last account, not the first: disabling the directory account while a SaaS account stays live is a partial removal. See the Joiner-Mover-Leaver Guide.

B2 Leaver accounts used after the leaving date

Formula: count of leaver accounts with a successful sign-in, token use or API call after the HR effective date, in the quarter. Report: the count, each case with its investigation outcome, and whether it was the former employee, a shared credential or an attacker. Source: sign-in and audit logs for critical applications joined to the HR leavers feed. This is the outcome B1 exists to prevent; one case is a red result and is handled under the Leaver Retained Access Incident Playbook.

B3 High-risk access removed through review

Formula: high-risk entitlements revoked in certification campaigns that closed in the quarter, divided by high-risk entitlements reviewed. Report: the rate by business unit and the count confirmed removed in the target system. Source: decision-level campaign export filtered on the entitlement risk rating. A long run at zero across a large population is a warning, not a success. Organisation-wide revoke rate is a supporting figure in the health check; the board version restricts it to high-risk access so it reflects exposure removed.

B4 Access found inappropriate after certification

Formula: entitlements removed for being inappropriate (by audit, incident, SoD analysis or the next review) within 180 days of being certified, divided by entitlements certified in that window. Report: the rate and the reviewers or applications that drive it. Source: removal reasons in the IGA platform joined to prior certification decisions. This is the most direct measure of review quality a board can see: it counts approvals that later proved wrong, rather than inferring rubber-stamping from speed. See the Access Reviews Guide.

B5 Mover privilege accumulation

Formula: average number of high-risk entitlements held by people who changed role in the last 12 months, divided by the average for peers in the same current role who did not move. Report: the ratio, where 1.0 means movers look like their peers, plus the top five accumulations. Source: HR job change events, role or job code, and current entitlements. A ratio well above 1.0 means mover processing grants new access without removing the old.

B6 Unused high-risk entitlements

Formula: high-risk entitlements not used in the last 90 days, divided by all high-risk entitlement assignments, for applications that log usage. Report: the percentage, the applications in scope and the trend. Source: application activity logs or IGA usage analytics. State coverage honestly: if only half the critical applications provide usage data, say so beside the figure. See the Orphaned and Dormant Accounts guide.

B7 Orphaned accounts

Formula: accounts in critical applications not correlated to a current identity, as a count and percentage. Report: privileged orphans as a separate count with age. Include service accounts and API clients whose owner has left. The health check reports this measure across all connected systems; the board version limits it to critical applications so the number means exposure.

B8 Joiner time to productive access

Formula: business days from the start date to the date the joiner's birthright and role-based access is fully provisioned, median and 95th percentile. Report: the figure alongside B6, because the quickest way to improve B8 is to over-grant. Source: HR start dates and provisioning completion events. This is the business benefit measure, and it is the one most likely to keep IGA funded.

Setting tolerances and targets

SP 800-55 describes a target as a range or an upper or lower bound with a threshold for a satisfactory rating, with interim targets allowed on the way. KRIs need tolerances tied to the cyber risk appetite statement; KPIs need targets with dated milestones. The values below are example starting points from NHI Mgmt Group, to be calibrated against your baseline and appetite.

B2 has no amber band on purpose: post-departure use is an event to investigate, not a trend to manage. Record a reason for every threshold change so a board can see that tolerances were not moved to turn a measure green.

Presenting IGA to the board

One page is usually enough, with the detail in an appendix.

• Headline: one sentence on whether identity governance exposure is inside appetite, and what changed since the last pack.
• Measures: the eight measures with current value, previous four quarters as a trend line, status against tolerance and the owner.
• Exceptions: every red item with cause, action and date; every accepted risk with expiry. Name applications, not people.
• Coverage statement: which applications and identity types are in scope, so a 99% figure is not mistaken for 99% of the estate. State whether non-human identities are included, and link to their own measures in the NHI Programme Metrics where they are reported separately.
• Decisions requested: funding to connect a critical application, approval of a risk acceptance, or a policy change such as shorter leaver service levels.

The structure of the wider cyber pack is in the Board Cyber Risk Reporting Guide; IGA is usually one page within it rather than a separate paper.

Data quality and assurance

• Authoritative sources: HR effective dates, not the date a ticket was raised, are the reference point for B1, B2 and B8. Contractors need an equivalent authoritative record or they fall out of every measure.
• Target-system truth: confirm removals in the application, not only in the IGA platform. A revocation marked complete while a connector was failing gives a false green.
• Independence: the people who administer the platform should not be the only ones producing and approving the figures, consistent with separation of duties in SP 800-53 AC-5. Have the second line recalculate one measure per quarter from raw exports, and include the set in internal audit's plan.
• Stable definitions: keep a measure dictionary with the formula, scope and source for each ID. If a definition changes, restate the prior quarters or mark the break in the trend line.
• Denominators: always show the count behind a percentage. A fall from 40 to 20 orphaned privileged accounts is good news even if the percentage barely moves.

How to implement

1. Agree the risk statements first. Link each KRI to a risk in the register, such as unauthorised access by former staff, so tolerances come from appetite rather than from what is easy to measure. See the Cyber Risk Appetite Statement Template.
2. Fix the scope. List the critical applications in scope, usually those that hold regulated data, move money or grant administrative control, and the identity types covered.
3. Build the measure dictionary with formula, source, owner and reporting cut for B1 to B8.
4. Run two quarters as a baseline without thresholds shown to the board. Expect data problems: missing HR dates, applications without usage logs, removal reasons not recorded.
5. Calibrate tolerances against the baseline and the appetite statement, and have the risk committee approve them.
6. Report for four quarters unchanged, then review: retire measures that have stayed green with low variation and replace them with the next exposure, for example SoD conflicts in financially significant systems.
7. Roll back if the data is wrong: when a source breaks, show the measure as "not reported" with the reason rather than carrying forward the last value.

Small and large organisations

A smaller organisation without a full IGA platform can still report B1, B2, B7 and B8 from the directory, HR records and a short list of critical SaaS applications; B4 to B6 need decision history and usage data that usually arrive with a platform. A large or regulated organisation should report by business unit and legal entity, add SoD exposure for financially significant applications, and expect internal and external auditors to test the figures. The stage your programme has reached is described in the Identity Governance Maturity Model.

Framework mapping

Frameworks require that security performance is measured and reviewed but do not prescribe these measures; the mapping shows which controls each measure evidences.

Common failure patterns

• Completion as the headline: reporting 100% campaign completion with no measure of what was removed or later found wrong, which rewards fast approval.
• Leaver time to the first account: measuring directory disablement while SaaS, code repository and cloud console accounts stay live.
• No usage evidence for B2: reporting leaver timeliness without ever checking whether any leaver account was used, so a real incident never reaches the board.
• Tolerances moved to stay green: widening an amber band in the quarter it would have gone red, without a recorded reason.
• Scope that shrinks silently: a critical application drops out of the data feed and the percentage improves.
• Human identities only: service accounts, API keys and agent identities are left out, although they make up much of the orphaned and excess access. See the NHI Ownership Guide.

Practitioner checklist

• Choose no more than eight board measures, mixing KPIs and KRIs.
• Link every KRI to a register risk and a tolerance approved by the risk committee.
• Write a measure dictionary with formula, scope, source and owner.
• Use HR effective dates and target-system evidence, not tickets.
• Report the 95th percentile and privileged cases, not only medians.
• Investigate and report every post-departure use of a leaver account.
• Show denominators, coverage and definition changes beside each figure.
• Have the second line recalculate one measure each quarter.
• Keep the platform health check for operational drift and link the two.

Standards and references

• NIST: SP 800-55 Vol. 1 Measurement Guide for Information Security, Identifying and Selecting Measures
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations
• NIST: IR 8286 Rev. 1 Integrating Cybersecurity and Enterprise Risk Management
• NIST: SP 800-53A Rev. 5 Assessing Security and Privacy Controls
• CIS: Critical Security Controls v8.1
• NCSC: Cyber Security Toolkit for Boards

Related NHI Mgmt Group resources: Identity Security Metrics Guide · Identity governance and administration (IGA) platform health check · Identity Governance and Access Reviews Executive Briefing · Segregation of Duties Guide