Most organisations cannot say with confidence who, and what, has access to their critical systems and data, and their access reviews often certify the answer without checking it. This briefing is for directors, chief executives, audit and risk committee members, CISOs and CIOs who own access risk and answer to auditors and regulators for it. It explains identity governance in business terms, why rubber-stamped access reviews give false comfort, why non-human identities often outnumber people in the scope, how to test management's answers and what a credible first 90 days looks like. It stays at board level. The operating detail is in the Access Reviews Guide and the Joiner-Mover-Leaver Guide.
The risk in one paragraph
Identity governance is the set of processes that decide who and what should have access, grant it, change it when roles change, remove it when it is no longer needed and prove all of that to an auditor. Without it, access accumulates: people who change jobs keep old permissions, leavers keep accounts or tokens, contractors outlast their contracts, and service accounts, API keys and AI agents are created with broad rights and no owner. Each of these is a ready-made route for an attacker with stolen credentials or a disgruntled insider, and each one turns a small compromise into a large one. Access reviews are meant to catch the drift, but when managers are asked to approve hundreds of entitlements they do not understand, they approve them all. The board's risk is not that the organisation lacks an identity governance tool; it is that nobody can show that access matches need, especially for privileged, financial and machine access. The board influences the outcome through three choices: who owns access risk for each system, whether leaver and mover processes are automated from an authoritative source, and whether non-human identities are inside the same governance as people.
Why this is a board-level issue now
- Attackers log in rather than break in. Stolen credentials remain one of the most common ways into organisations: Verizon's 2026 Data Breach Investigations Report places stolen passwords second only to vulnerability exploitation as an initial access route. MITRE ATT&CK tracks this as Valid Accounts (T1078). Excess access determines how far an attacker gets with one account.
- Former staff keep access longer than anyone thinks. In the Coupang breach a former engineer's unrevoked signing key exposed 33.7 million accounts, and in the Ledger Connect Kit compromise a former employee's unrevoked package registry access was used to ship malicious code. Leaver processes that cover the directory but not keys, tokens and third-party platforms leave these doors open.
- Forgotten accounts are a favoured target. In the Microsoft Midnight Blizzard breach, a forgotten test tenant and an OAuth application with excessive rights led to executive mailboxes. Unowned identities never appear in a manager's review.
- Machines and AI agents are a growing share of identities. In our experience at NHI Mgmt Group they often outnumber people. Service accounts, workload identities, API keys and AI agents are created by engineers and automation, often outside the joiner process, and are rarely in scope for access reviews. See the Board Briefing: NHI Risk.
- Auditors and regulators expect evidence. NIST SP 800-53 AC-2 (account management) and AC-6 (least privilege), NIST CSF 2.0 PR.AA-05 and ISO/IEC 27001:2022 Annex A 5.18 all expect access rights to be reviewed and adjusted. User access reviews are a routine focus of financial statement and regulatory audits, and failed reviews become audit findings that reach the audit committee.
The parts of identity governance, in business terms
| Process | What it does | What goes wrong without it | Evidence management should hold |
|---|---|---|---|
| Joiners | Grants access based on role on day one | Copy-a-colleague access that inherits years of excess | Role-based access packages approved by system owners |
| Movers | Changes access when people change role | Privilege creep; toxic combinations across old and new roles | Automatic removal of old access on transfer, with a short grace period (NIST SP 800-53 PS-5) |
| Leavers | Removes all access on departure | Former staff and contractors keep accounts, tokens and keys | Disable within hours, driven by HR data, covering SaaS and keys (PS-4, AC-2(3)) |
| Access requests | Grants extra access with approval | Standing access that is never removed | Time-limited grants, approver records |
| Access reviews (certification) | Owners confirm access is still needed | Rubber-stamping; reviews that miss non-human and privileged access | Review completion, revocation rates, reviewer decisions |
| Segregation of duties | Prevents one person holding conflicting rights | Fraud and errors in payments, procurement and code release | A conflict matrix and detected violations (AC-5) |
| Non-human identity governance | Owners, purpose and expiry for service accounts, keys and agents | Orphaned machine credentials with broad rights | Inventory with named owners and rotation dates |
See IAM and IGA Basics and the Segregation of Duties Guide.
Why access reviews fail, and what works instead
| Review design | Typical result | Better approach |
|---|---|---|
| Every manager reviews every entitlement of every report, quarterly | Fatigue and near-100% approval | Risk-based scope: privileged, financial, sensitive data and external access reviewed more often; low-risk access by exception |
| Raw technical entitlement names | Reviewers cannot tell what they approve | Entitlement catalogue with plain descriptions and risk ratings. See the Entitlement Catalogue Guide. |
| Manager-only reviews | Nobody checks what the system owner considers appropriate | Combine manager review of people with owner review of systems and privileged groups |
| People only | Service accounts, keys and agents never reviewed | Owner-based review of non-human identities with usage data. See How to Run an Access Review for Service Accounts. |
| Review marked complete when signed | Revocations requested but never carried out | Closed-loop remediation verified in the target system |
A revocation rate close to zero across many reviews usually signals rubber-stamping, not perfect access. Usage data (last login, last use of an entitlement) is the single most useful aid to reviewers.
Five questions for the board to ask
- How quickly is all access removed when someone leaves, and how do we know it covers keys, tokens and SaaS? Expect a measured time from the HR leaving date to disablement, and evidence that personal API keys, code repository and cloud console access are included.
- What share of our identities are non-human, and how many have a named owner? A credible answer counts service accounts, API keys, workload identities and AI agents, with ownership coverage as a percentage.
- What did our last access review actually change? Ask for revocation rates by system and evidence that revocations were carried out. A review that changed nothing is a warning sign.
- Who owns access risk for our most critical systems? Each critical system should have a named business owner accountable for who has access, not only IT administrators (NIST CSF 2.0 GV.RR-02).
- How many dormant and orphaned accounts exist today, including privileged ones? Expect numbers, a threshold for dormancy and a trend. CIS Controls v8.1 safeguard 5.3 sets 45 days of inactivity as the point to disable dormant accounts where supported. See Orphaned and Dormant Accounts.
Red flags in management answers
- "Reviews are 100% complete every quarter": completion says nothing about quality. Ask for revocation rates and time spent per decision.
- "HR tells IT when people leave": manual tickets miss contractors, delayed notifications and third-party platforms. Ask for automation from the authoritative source.
- "Service accounts are managed by the platform team": without an inventory, owner and review, that usually means nobody governs them.
- "The IGA tool covers it": tools cover only the applications connected to them. Ask what share of critical applications are onboarded.
- "Privileged access is handled separately": it should be reviewed more often, not left out of governance. See the Privileged Access Management Guide.
What good looks like
- An authoritative source: HR and contractor records drive joiner, mover and leaver changes automatically, with single sign-on so revoking the work account revokes linked services, as the UK NCSC recommends.
- Role-based access: access packages per role, approved by system owners, replacing copy-a-colleague provisioning. See the Role Mining and Role Design Guide.
- Risk-based reviews: frequent review of privileged, financial and sensitive access with usage data; automated removal of unused access.
- Non-human identities in scope: every service account, key and agent has an owner, purpose, minimum permissions and expiry or rotation date. See the Service Account Security Guide.
- Segregation of duties enforced: conflicts prevented at request time and detected continuously in finance and release processes.
- Evidence on demand: audit-ready records of approvals, reviews and revocations, so audits become checks rather than projects.
Where to invest first
| Priority | Investment | Why first | Typical owner |
|---|---|---|---|
| 1 | Automated leaver process from HR data, covering SSO, SaaS, cloud and keys | Closes the most common and most embarrassing gap | CIO with HR |
| 2 | Inventory and ownership of privileged and non-human identities | These carry the highest blast radius and are least reviewed | CISO |
| 3 | Onboarding critical applications into identity governance | Reviews and automation only work for connected systems | IAM team with application owners |
| 4 | Risk-based access reviews with usage data | Turns reviews from a ritual into risk reduction | IAM team and internal audit |
| 5 | Role model and segregation of duties rules for finance and engineering | Reduces excess at the point of grant and prevents fraud | Business owners with IAM |
Smaller organisations can get most of the value from single sign-on for all SaaS, an HR-driven leaver checklist that includes keys and tokens, and a quarterly owner review of privileged and service accounts, without a dedicated platform. Larger organisations with hundreds of applications and many acquisitions need an identity governance platform, application onboarding at scale and role engineering. See the IGA Buyer's Guide and the Identity Governance Maturity Model.
Metrics to track
| Metric | What it shows | Good direction |
|---|---|---|
| Median time from leaving date to full access removal | Leaver control strength | Hours, not days |
| Critical applications connected to identity governance (%) | Coverage | Rising towards 100% |
| Non-human identities with a named owner (%) | Machine identity governance | Rising towards 100% |
| Revocation rate in access reviews, by system | Review quality and access drift | Non-zero, falling over time as hygiene improves |
| Dormant and orphaned accounts, privileged shown separately | Unused attack surface | Falling, near zero for privileged |
| Open segregation of duties violations | Fraud and error exposure | Few, each with an approved mitigation |
A 90-day plan
- Days 1 to 30, measure the gaps: reconcile HR and contractor records against active accounts in the directory and the top critical SaaS and cloud platforms; count leavers with active access, dormant accounts and unowned service accounts and keys.
- Days 1 to 30, remove the obvious: disable accounts of confirmed leavers; disable or assign owners to dormant privileged and service accounts; revoke unused OAuth grants with broad scopes.
- Days 31 to 60, set accountability: name a business owner for each critical system; approve an access governance policy with leaver timelines, review frequency by risk and non-human identity ownership rules.
- Days 31 to 60, fix the leaver path: automate disablement from the HR source for single sign-on and the most critical platforms; add keys, tokens and code repositories to the leaver checklist. See the Leaver Retained Access Incident Playbook.
- Days 61 to 90, run a better review: run a risk-based review of privileged, financial and non-human access with usage data, and verify that every revocation was carried out.
- Day 90, report: present the first metrics pack to the risk or audit committee, with a funded roadmap for application onboarding and role design.
Common failure patterns
- Tool first, process later: buying a platform before ownership, roles and authoritative sources exist. See Top 10 IGA Mistakes.
- Directory-only leavers: disabling the main account while personal access tokens, SSH keys and third-party platform accounts stay live.
- Reviewing the wrong things: spending reviewer time on low-risk access while privileged and machine access go unexamined.
- Movers forgotten: new access granted on transfer, old access never removed.
- Unowned machines and agents: service accounts and AI agents created by projects that have ended. See Ownership for Orphaned and Abandoned AI Agents.
Framework mapping
| Framework | Reference | Board relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01, PR.AA-05, GV.RR-02 | Identities managed, access reviewed with least privilege, roles and authorities |
| NIST SP 800-53 Rev. 5 | AC-2, AC-2(3), AC-2(4), AC-5, AC-6, PS-4, PS-5, AU-6 | Account management, disabling accounts, audit actions, separation of duties, least privilege, termination and transfer |
| CIS Controls v8.1 | Control 5 Account Management, Control 6 Access Control Management | Account inventory, dormant accounts, granting and revoking access for user, administrator and service accounts |
| ISO/IEC 27001:2022 | Annex A 5.15, 5.16, 5.18 | Access control, identity management, access rights |
| MITRE ATT&CK | T1078 Valid Accounts, T1098 Account Manipulation, T1136 Create Account | The attacker behaviours that governance and monitoring should limit and detect |
Practitioner checklist
- Drive joiner, mover and leaver changes from authoritative HR and contractor data.
- Include API keys, tokens, SSH keys, code repositories and SaaS in the leaver process.
- Name a business owner for every critical application and privileged group.
- Inventory non-human identities with owner, purpose, permissions and rotation or expiry date.
- Scope access reviews by risk and give reviewers usage data and plain-language entitlement descriptions.
- Verify every revocation in the target system before closing a review.
- Disable dormant accounts after a defined inactivity period and report privileged ones separately.
- Maintain and enforce a segregation of duties matrix for finance and release processes.
Standards and references
- NCSC: 10 Steps to Cyber Security, Identity and Access Management
- CIS: Control 5 Account Management
- CIS: Control 6 Access Control Management
- MITRE ATT&CK: T1078 Valid Accounts
- Verizon: Data Breach Investigations Report
- NIST SP 800-53 Rev. 5: AC-2, AC-5, AC-6, PS-4, PS-5; NIST CSF 2.0 PR.AA-01, PR.AA-05; ISO/IEC 27001:2022 Annex A 5.15, 5.16, 5.18
How NHI Mgmt Group can help
We provide independent board briefings and identity governance assessments that bring non-human identities, service accounts, API keys and AI agents into the same ownership, review and leaver processes as people. Our NHI Foundation Level Training Course helps IAM, security and engineering teams govern these identities. Contact us to arrange a briefing.
Related NHI Mgmt Group resources: Access Review Checklist · Identity Governance for AI Agents Guide · Identity Threat Executive Briefing · Securing the identity governance and administration (IGA) platform itself