Part 1 of 3

By Vidyaa Ganesh

Five independent sources, 2,000+ respondents, one conclusion: most organizations cannot measure their IAM maturity. And that is a problem.

Identity and access management has become one of the most consequential areas of enterprise security. The IDSA’s 2024 survey of 521 security professionals found that 90% of organizations experienced at least one identity-related security incident in the prior 12 months, with 84% reporting direct business impact. IBM’s 2025 Cost of a Data Breach report, based on 600 organizations and over 3,400 interviews, puts the global average breach cost at $4.88 million, with compromised credentials remaining the most common initial attack vector.

These numbers create obvious pressure for organizations to invest in IAM. And they are investing. But a harder question follows: how do you know whether your IAM program is actually working? How do you measure where you stand relative to your industry, track improvement over time, or communicate your posture to a board of directors in terms that hold up to scrutiny?

The honest answer, as of early 2026, is that most organizations cannot do any of these things reliably. There is no widely accepted, vendor-neutral framework for measuring IAM maturity. What exists instead is a patchwork of vendor-specific models, consultant-developed scorecards, and ad hoc approaches that vary from one engagement to the next. The measurements produced by these approaches cannot be compared across organizations, across time, or even across different consultants assessing the same organization.

This is the first installment in a three-part series examining this problem. In this piece, we look at what the published research actually says about where organizations stand. In Part 2, we survey the frameworks currently in use and analyze why no standard has emerged. In Part 3, we propose design principles that a credible, community-adopted standard would need to follow.

What Published Research Tells Us

Before discussing what a standard should look like, it is worth understanding what the data actually says about where organizations stand. Several independent research efforts have attempted to measure IAM maturity across large populations, and their findings tell a remarkably consistent story.

SailPoint Horizons of Identity Security (2025-2026)

SailPoint’s annual Horizons research surveyed 375 IAM decision-makers across North America, Europe, Asia, and Latin America. The study evaluates organizations across four enablement areas (strategy, technology and tools, operating model, and talent) covering 60 IAM capabilities, then assigns each organization to one of five maturity horizons using a clustering algorithm.

The headline finding is striking: over 40% of organizations remain at Horizon 1, the lowest maturity level. These are organizations where identity is not a strategic focus, capabilities are highly immature, and there is no centralized operating model for managing identities across the organization. When you include Horizon 2, the number climbs to roughly 63% of organizations stuck at the bottom two tiers.

Industry breakdowns reveal meaningful variation. In financial services, 34% are at Horizon 1, with 13% reaching Horizon 4 or above. In technology, the distribution is bimodal: 46% at Horizon 1, but 15% at Horizon 4 or higher, reflecting a split between early-stage companies with minimal IAM investment and mature enterprises with sophisticated programs.

Ponemon Institute and GuidePoint Security (2025)

The Ponemon Institute, in partnership with GuidePoint Security, surveyed 626 IT professionals on the state of IAM maturity in 2025. On a 10-point effectiveness scale, only 50% of respondents rated their IAM tools as effective (scoring 7 or higher). Just 23% qualified as high performers, rating their effectiveness at 9 or 10.

The study also found that 50% of organizations experienced an identity-related incident in the prior 12 months. Even among high performers, 39% still experienced incidents, compared to 58% for others. Manual processes remain dominant: 34% of organizations still use spreadsheets for access reviews, and only 17% use an identity governance platform for this purpose.

IDSA Trends in Identity Security (2024)

The Identity Defined Security Alliance surveyed 521 qualified security professionals at organizations with 1,000 or more employees. The findings reinforce the pattern: 90% experienced an identity-related incident, 84% reported direct business impact, and 91% invoked their incident response plans for identity-related events.

When asked to self-assess their maturity, only 8% of respondents placed their organization at the highest level. The majority clustered in the middle tiers, suggesting widespread acknowledgment that current capabilities are insufficient.

Other Sources

Bravura Security, in partnership with Gartner Peer Insights, conducted a smaller study of 100 IT leaders across North America and EMEA using a four-level maturity scale. Their finding: the average organization falls between levels 2 and 3 on a four-point scale, consistent with the other sources.

Simeio’s State of Identity research, covering 80 measures across industries, found a cross-industry average maturity of 2.4 on a five-point scale. Financial services scored highest at approximately 2.6, with healthcare and public sector trailing.

What the Data Tells Us

Five independent research efforts, using different scales, different sample sizes, and different methodologies, converge on the same conclusion: the majority of organizations, somewhere between 60% and 70%, remain at early-to-mid stages of IAM maturity. The consistency across sources is significant. This is not one vendor telling a convenient story. It is a pattern that holds up regardless of who is asking the question or how they frame it.

Table 1. Cross-source validation of IAM maturity findings

NEXT IN THIS SERIES

Part 2: A Landscape of Incompatible Approaches

Several maturity frameworks exist in the IAM space. Each offers something useful. None has achieved the status of a shared standard. We examine why.

Endnotes

1. Identity Defined Security Alliance, 2024 Trends in Securing Digital Identities (IDSA, 2024), 521 respondents.

2. IBM Security, Cost of a Data Breach Report 2025 (Ponemon Institute Research, 2025), 600 organizations, 3,470 interviews.

3. SailPoint Technologies, The Horizons of Identity Security 2025-2026 (SailPoint, July 2025), 375 IAM decision-makers.

4. SailPoint, Horizons 2025-2026, Exhibit 7, p. 15.

5. Ponemon Institute and GuidePoint Security, The State of Identity and Access Management (IAM) Maturity (May 2025), 626 IT professionals.

6. Identity Defined Security Alliance, 2024 Trends in Securing Digital Identities (IDSA, 2024).

7. Bravura Security and Gartner Peer Insights, IAM & PAM Maturity Survey (Bravura Security, 2024), 100 IT leaders.

8. Simeio, State of Identity 2024 (Simeio Solutions, 2024).

Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.

About the Author

Vidyaa Ganesh is a Senior IAM Engineer and a solutions architect with over six years of experience delivering identity governance programs for financial services, energy, telecommunications, and public sector clients. She holds a Master of Engineering from Concordia University, is a member of IDPro, and is the creator of AXIS (axis.identara.ca), an open IAM maturity assessment framework.

The post The Measurement Problem appeared first on IDPro.

Role: Cybersecurity Executive | “Identity-First” Security Leader

What IAM practitioners need to understand about the human cost hiding inside your compliance checklist…

The Pattern Nobody Talks About Out Loud

Every major regulatory framework you work against was written in response to something that already went wrong. Not hypothetically wrong. Catastrophically, publicly, irreversibly wrong. We don’t build policy proactively in this industry; we build it reactively, after the damage has been done and the headlines have forced someone’s hand.

Think about what’s sitting underneath the frameworks you navigate daily.

• HIPAA didn’t emerge from healthcare executives deciding patient data deserved protection. It emerged from a landscape of rampant insurance fraud, discriminatory data practices, and medical record abuses that left real people with real consequences – lost jobs, denied coverage, destroyed privacy. The law was the cleanup crew, not the prevention.
• SOX didn’t come from auditors deciding financial controls needed tightening. It came after Enron and WorldCom vaporized billions in investor value and shredded retirement accounts for thousands of ordinary people who trusted the numbers they were shown. The Act is a forensic document masquerading as a compliance framework.
• GDPR wasn’t a vision for a privacy-respecting digital future. It was a regulatory response to years of data harvesting, unconsented profiling, and cross-border data abuses that regulators finally couldn’t ignore after Facebook’s Cambridge Analytica exposure became impossible to contain politically.
• The Amber Alert system is named after Amber Hagerman, a nine-year-old murdered in Arlington, Texas in 1996. The system that now protects children didn’t exist until a child was killed and her community demanded something change.
• PCI-DSS exists because card fraud became so pervasive and so costly to the financial ecosystem that the major card networks had no choice but to mandate baseline controls across every merchant touching card data. The standard didn’t anticipate the breach, it was written after thousands of them.

This is the pattern. Harm occurs. Harm scales. Harm becomes undeniable. Regulation follows. And then we all inherit the compliance framework and treat it like it arrived from nowhere, like it was always just the way things were.

It didn’t arrive from nowhere. It arrived from graves.

IAM Is No Different – Here Are the Breaches That Wrote Your Policies

The identity space follows the same pattern exactly. The controls we build and enforce today weren’t invented in a vacuum by forward-thinking architects. They were demanded by specific, named failures that exposed how badly we were underinvesting in identity fundamentals.

• Target (2013): The breach wasn’t a sophisticated nation-state attack. An HVAC vendor with network access and no meaningful segmentation became the entry point for 40 million stolen card records. The core failure was third-party identity governance, an external account with far more privilege than its function required, and no monitoring to detect its abuse. Every time I review a vendor access policy, this breach is in the room.
• SolarWinds (2020): Supply chain compromise at massive scale, enabled in part by service accounts operating with excessive privilege across thousands of customer environments. The attackers didn’t force their way in, they walked through doors that were left open by over-permissioned build pipeline identities and inadequate separation between production and development access.
• Colonial Pipeline (2021): A single compromised VPN account with no MFA enforced. One identity. No second factor. Fuel supply disruption across the eastern United States. Every MFA mandate that landed in your organization after 2021 has this incident’s fingerprints on it.
• Uber (2022): A contractor’s credentials obtained through MFA fatigue, repeated push notifications until the user accepted to stop the noise. The attacker then moved laterally through internal systems because access controls weren’t scoped tightly enough to limit blast radius. The failure wasn’t technical sophistication. It was operational immaturity in how MFA was implemented and how privilege was bounded.
• Microsoft (2023): A stolen MSA signing key used to forge authentication tokens across cloud tenants. The identity trust model itself became the attack surface. When cryptographic key management fails, every downstream access decision built on top of it is compromised.
• MGM Resorts (2023): Attackers identified a senior employee via LinkedIn, called the IT help desk impersonating them, and convinced the agent to reset credentials and MFA with no callback protocol, no strong out-of-band verification. Caesars Entertainment was hit the same month by the same pattern. The failure wasn’t in the authentication stack. It was in the help desk itself. The layer where humans prove humans and deepfake voice and video now make that layer trivial to defeat at scale.

Each of these is an IAM failure. Excessive privilege. Missing MFA. Orphaned accounts. Poor federation hygiene. Inadequate key lifecycle management. Help desk identity verification. The controls that now appear in your compliance frameworks have these incident names written invisibly inside them.

What Compliance Actually Tells You (And What It Doesn’t)

Here’s the uncomfortable truth about compliance frameworks: they are lag indicators by design. They codify the minimum bar required to prevent the breach that already happened. They say nothing reliable about the breach that’s being planned right now.

The gap between a compliance checkbox and mature IAM posture is where the next incident is living. I see this gap constantly, and it’s worth naming directly.

• MFA enabled versus phishing-resistant MFA enforced at the authentication policy layer hardware-bound, not just a push notification toggle sitting in a dashboard that nobody monitors for fatigue patterns.
• Privileged access documented versus PAM operationally enforced with just-in-time provisioning, session recording with active review, and standing access treated as a policy exception rather than the default.
• Access reviews completed versus access reviews that actually reduce privilege, where the outcome of the review cycle is measurably fewer entitlements per identity, not just a signed-off spreadsheet that nobody acted on.
• Service accounts inventoried versus non-human identities continuously monitored with behavioral baselines, anomaly alerting, and rotation schedules enforced by automation rather than calendar reminders.
• Zero Trust policy adopted versus a network architecture where identity is actually the control plane, not a slide in a board presentation, and where access decisions factor not just who the user is, but where they are, what device they’re on, and whether their current behavior looks like their baseline.

Identity used to answer “are you allowed?” It now has to answer “does this access attempt even look like you?” Impossible travel, high-risk geographies, session risk, device posture — these belong inside the authentication decision, not inside a dashboard someone reviews on Mondays.

• IAM capabilities deployed versus IAM KPIs tracked and trended over time because what doesn’t get measured doesn’t improve, and the maturity of an identity program shows up in the shape of its metric curves, not in the inventory of tools on the license schedule. If you can’t tell me whether entitlements-per-identity is declining, whether standing privilege has shrunk quarter over quarter, or how long a new joiner waits for correct access – you don’t have a program posture, you have a tool stack.

Compliance tells you what the floor looks like. It does not tell you where the ceiling is. And in my experience, most organizations have stopped somewhere between the two and called it done.

The Dangerous Comfort Zone: When Your Team Mistakes Compliance for Security

The organizational behavior this creates is one of the most persistent problems I work against. When audit cycles become the primary driver of the IAM roadmap, the team’s incentive structure warps in a specific and dangerous direction.

You stop optimizing for threat reduction. You start optimizing for evidence collection.

I’ve seen this show up in recognizable patterns across organizations of every size.

• Quarterly access reviews conducted as rubber stamps, certifiers clicking approve on hundreds of entitlements in minutes because the process was designed to generate a record, not to generate a decision. The question being answered isn’t “does this person need this access?” It’s “how quickly can we close the certification campaign?”
• Role proliferation allowed to compound year over year because the current roles passed the last audit, so nobody wants to touch them. The organization is carrying thousands of roles, most of which are poorly defined, overlapping, and impossible to audit meaningfully but the audit passed, so the conversation doesn’t happen.
• PAM tools deployed, licensed, and documented and operationally ignored. The vault exists. The accounts are technically onboarded. But privileged sessions aren’t being reviewed, standing access is still the default, and the tool that was supposed to transform privileged access management is functioning as an expensive credential repository.
• IGA platforms configured to enforce policy at provisioning and then left unmonitored for drift. Accounts created with the right access on day one, accumulating entitlements through ad-hoc requests for three years, and nobody has looked at the aggregate picture because the provisioning workflow is compliant.

If any of this feels familiar, I’m not judging the team rather I’m naming the system. When compliance is the primary success metric, this is the rational response to the incentive structure. The problem is that rational compliance behavior and effective security behavior are not the same thing, and the gap between them is where attackers operate.

IAM practioners shoould put it plainly to leadership: Audit Ready is not the same as Breach Proof. A team optimizing for closing the certification campaign rather than reducing the risk the entitlement actually carries will produce a clean audit and a vulnerable organization at the same time. The moment those two phrases get conflated above the CISO’s head, the program inherits a mandate that looks like security but isn’t.

How to Get Ahead of the Grave – A Practitioner’s Operating Model

Diagnosis without direction isn’t useful. So here is the operating model I apply when I want to move an identity program from reactive compliance posture to proactive threat-informed design. This isn’t theoretical, it’s what actually works in practice.

The list is structured deliberately: the first six harden your posture against breach patterns already on public record; the seventh forces your program to keep pace with threats no auditor has yet catalogued.

1. Threat-model your identity fabric before you scope your controls. Start with adversary behavior, not framework requirements. Map the specific identity attack paths relevant to your environment — credential theft, privilege escalation, lateral movement via federated trust, non-human identity abuse. Then ask which of your current controls actually interrupt those paths and which ones only satisfy an auditor.

• A frame worth internalizing here, from John Lambert: defenders think in lists, attackers think in graphs, and as long as that’s true, attackers win. Your access review spreadsheet is a list. The web of trust between your identities, groups, federations, service accounts, and privileged resources is a graph, and that graph is the terrain your adversary is actually traversing.

2. Define your identity tiers and map blast radius per tier explicitly. Not all identities carry equal risk. A tier-one privileged identity with access to production infrastructure and administrative federation capabilities has an entirely different blast radius than a standard user account. Your controls, monitoring intensity, and response playbooks should reflect that difference. If they don’t, you’re applying uniform protection to non-uniform risk.
3. Run tabletop exercises scoped specifically to identity failure modes. Most tabletops I’ve participated in simulate perimeter or endpoint compromises. Run the scenario where your IdP is compromised. Run the scenario where a service account with excessive privilege is abused by an insider. Run the scenario where MFA is defeated at scale through fatigue or SIM swapping. The gaps that surface in those conversations are the gaps that matter.
4. Red team your identity layer – don’t wait for a real incident to find the gaps. Tabletops surface the failures you can imagine; adversarial testing surfaces the ones you can’t. Commission identity-focused red team engagements on a recurring cadence — credential theft, session hijack, federation abuse, privilege escalation, help desk social engineering and feed what they find back into architecture rather than filing it as a report. Gaps that never appear in access reviews or audits almost always appear under someone actually trying to break in.
5. Instrument your IGA for behavioral anomaly, not just policy violation. Policy enforcement catches known-bad. Behavioral analytics surface unknown-bad. If your identity governance platform is only alerting when a provisioning rule is violated, you’re blind to the user whose access pattern changed three months ago in ways that no individual action violated policy but the aggregate behavior is deeply suspicious.
6. Build your access review process around privilege reduction as the measurable outcome. Track entitlements per identity over time. Make the success metric a declining curve, not a closed certification campaign. If your access reviews aren’t resulting in access removal, they aren’t reviews, they’re rituals.
7. Treat non-human identity with the same rigor as privileged human identity. Service accounts, API keys, OAuth tokens, pipeline credentials – these are the identities attackers are targeting at scale right now because they’re often under-governed and over-privileged. If you don’t have a comprehensive non-human identity inventory with ownership, purpose, and lifecycle enforcement, this is the highest-priority gap in most environments I’ve seen.
8. Plan for the attacks your compliance framework hasn’t named yet. The controls in your baseline were written against breaches that have already happened. Deepfake-assisted help desk impersonation, AI-generated vishing, synthetic identity fraud, ML-enhanced MFA fatigue — these are landing in production right now and appear in no auditor’s checklist. Build a forward-looking layer into your program that tracks emerging identity threats quarterly, runs tabletop exercises against them, and lands the control before the framework tells you to.
9. Rehearse the recovery, not just the detection. Assume the breach has already landed. Do the right people know their roles, and are they reachable at 3 a.m. on a holiday? How fast can you rotate privileged credentials at scale, sever federated trust, and re-establish a known-good authentication plane? Most programs have never actually measured how long identity recovery would take under real conditions. Find out before an attacker makes you find out.
10. Plan for the attacks your compliance framework hasn’t named yet. The controls in your baseline were written against breaches that have already happened. Deepfake-assisted help desk impersonation, AI-generated vishing, synthetic identity fraud, ML-enhanced MFA fatigue – these are landing in production right now and appear in no auditor’s checklist. Build a forward-looking layer into your program that tracks emerging identity threats quarterly, runs tabletop exercises against them, and lands the control before the framework tells you to.

The Obligation We Carry as IAM Practitioners

I want to end with something direct, because I think it matters.

The people building identity infrastructure today are either providing the incident report that writes the next regulation, meeting the one that already exists, or for the few doing this exceptionally well, quietly setting the bar that tomorrow’s framework will codify as the new minimum, not because something went wrong but because it got done right first.

There is no neutral position. The access controls you enforce or fail to enforce, the privilege you scope or over-grant, the MFA you deploy meaningfully or deploy performatively, all of it is making a real-world determination about whether the next catastrophic breach happens on your watch and in your environment.

That’s not meant to be dramatic. It’s meant to be accurate.

Reframing what good IAM work actually means is worth doing explicitly.

• Good IAM work is not completing a certification campaign on time. It is ensuring that the humans approving entitlements are actually examining them and removing the ones that shouldn’t exist.
• Good IAM work is not deploying a PAM tool. It is operationalizing privileged access controls to the point where standing access is genuinely exceptional and every privileged session is visible and accountable.
• Good IAM work is not enforcing MFA across the enterprise. It is enforcing phishing-resistant MFA in the places where a compromised credential would have catastrophic blast radius, and knowing specifically which those places are.
• Good IAM work is not a team drowning in manual toil. It is using the automation and AI capabilities now available to us to surface dangerous privileges, inform access review decisions, and detect the identity patterns no human reviewer will ever catch at scale, freeing human judgment for the decisions that actually require it.
• Good IAM work is not passing an audit. It is building an identity posture that would survive an attacker who has never read your audit report and does not care about your certification timeline.

The frameworks we operate inside exist because somewhere, at some point, someone’s identity infrastructure failed publicly enough to force a regulatory response. The question I carry into every architecture decision, every policy review, and every control deployment is a simple one: am I building something that prevents that, or am I building something that looks like I prevented it?

The difference between those two things is where real harm lives and where the next regulation is quietly being drafted.

Build identity infrastructure that makes the next compliance framework unnecessary.

Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.

References

– [1] U.S. Department of Health and Human Services, “Health Insurance Portability and Accountability Act of 1996 (HIPAA),” Public Law 104-191. https://www.hhs.gov/hipaa/index.html

– [2] U.S. Securities and Exchange Commission, “Sarbanes-Oxley Act of 2002,” Public Law 107-204. https://www.sec.gov/about/laws/soa2002.pdf

– [3] European Union, “Regulation (EU) 2016/679 (General Data Protection Regulation),” Official Journal of the European Union. https://eur-lex.europa.eu/eli/reg/2016/679/oj

– [4] PCI Security Standards Council, “Payment Card Industry Data Security Standard (PCI DSS).” https://www.pcisecuritystandards.org/standards/pci-dss/

– [5] U.S. Department of Justice, AMBER Alert Program, “About AMBER Alert.” https://amberalert.ojp.gov/about

– [6] Krebs, Brian, “Target Hackers Broke in Via HVAC Company,” KrebsOnSecurity, February 5, 2014. https://krebsonsecurity.com/2014/02/target-hackers-broke-in-via-hvac-company/

– [7] Cybersecurity and Infrastructure Security Agency (CISA), “Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations (SolarWinds),” Alert AA20-352A, December 2020. https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-352a

– [8] Cybersecurity and Infrastructure Security Agency (CISA) and FBI, “DarkSide Ransomware: Best Practices for Preventing Business Disruption from Ransomware Attacks (Colonial Pipeline),” Alert AA21-131A, May 2021. https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-131a

– [9] Uber Technologies, “Security update,” Uber Newsroom, September 19, 2022. https://www.uber.com/newsroom/security-update/

– [10] Microsoft Security Response Center, “Analysis of Storm-0558 techniques for unauthorized email access,” Microsoft Threat Intelligence, July 14, 2023. https://www.microsoft.com/en-us/security/blog/2023/07/14/analysis-of-storm-0558-techniques-for-unauthorized-email-access/

– [11] U.S. Securities and Exchange Commission, MGM Resorts International Form 8-K, September 12, 2023. https://www.sec.gov/Archives/edgar/data/789570/000119312523237814/d551104d8k.htm

– [12] Lambert, John, “Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win.,” GitHub, 2015. https://github.com/JohnLaTwC/Shared

About the Author

Nishad Sankaranarayanan is a cybersecurity executive with 20+ years of experience building and leading enterprise security programs in complex, regulated environments. He serves as Global Director of Cybersecurity at Genuine Parts Company — a Fortune 200, $20B+ global enterprise — where he leads a program spanning workforce and customer identity, cloud security, AI governance, and cyber defense across 17 countries. Previously, he was part of the post-breach security transformation at Equifax, contributing to FedRAMP authorization and NIST 800-53 compliance across a large-scale financial data environment. Nishad holds a CISO Executive Certificate from Carnegie Mellon University, serves on advisory boards for several cybersecurity startups, and founded the Atlanta IAM User Group. He is a recognized speaker at Gartner IAM Summit and Identiverse, a 2025 Constellation Research SuperNova Award recipient for Cybersecurity Leadership, and a three-time Ping Identity Excellence Award winner.

The post Most Regulatory Frameworks are Built on Top of Graves appeared first on IDPro.

This model made sense when access was mostly static. In many systems, access was granted through roles, groups, or direct assignments. A user joined a role such as Finance Analyst or Database Admin, and that role determined what they could do. Reviewing access meant reviewing those assignments. 

But modern systems are changing how access actually works. 

Increasingly, access is not something a user permanently has. It is something the system decides in real time. 

In policy-driven authorization models such as PBAC, attribute-based access control, and zero trust architectures, access decisions depend on many factors beyond a simple assignment. Policies may consider user attributes, device posture, location, time of day, risk signals, or temporary elevation. The system evaluates these inputs at runtime before allowing an action. 

In these environments, access becomes dynamic. A user may be allowed to perform an action in one situation but denied in another, even if their role has not changed. 

This raises an interesting question. 

What exactly are we reviewing during a traditional access review? 

Most reviews focus on artifacts like roles, group memberships, or entitlements. For example, a manager might see something like this: 

User: Alice 

Group: Engineering 

Application Role: Build System Developer 

The manager approves or revokes the assignment. The review is complete. But the assignment alone does not actually explain what Alice can do. 

Consider a simple policy-driven system. A developer may be allowed to access a production build environment only if several conditions are true: 

• The user belongs to the engineering group 
• The device is a managed corporate device 
• The request occurs during business hours 
• The risk score is low 

The access decision might look like this: 

Access allowed if: 

User in Engineering AND Device trusted AND Time within work hours AND Risk score below threshold 

In this model, the engineering group membership is only one input into the decision. The final access outcome depends on multiple conditions evaluated at runtime. 

Now imagine a manager reviewing Alice’s access. They see that she belongs to the Engineering group and approve the assignment. But that review does not answer several important questions. 

Can Alice access the system from a personal device? 

Can she access it after hours? 

What happens if her device posture changes? What if the risk engine flags unusual activity? 

The review confirms the presence of one artifact, but it does not fully explain how access decisions are actually made. 

This is where many organizations are starting to feel a gap between traditional governance practices and modern authorization architectures. 

In practice, many organizations have adapted access reviews to serve a different but related purpose: validating software entitlements in seat-licensed products. This is a real and legitimate use case. But it is worth separating from the question of governing access decisions, which is a distinct problem.

Access reviews were designed to govern static assignments. But many modern systems rely on dynamic decisions. And those decisions are largely invisible to the people who understand the business context behind them. A manager may have a legitimate reason to want Alice to access a system from a personal device, or outside business hours. But if the policy engine is making that determination silently, the manager has no surface to exercise that judgment. The review confirms an assignment. It says nothing about whether the decision logic itself reflects business intent.

This does not mean access reviews are useless. They remain valuable in environments where access is directly tied to roles, groups, or application assignments. Many enterprise applications still operate this way, and reviewing those assignments is still a meaningful control. 

However, as organizations adopt policy-driven authorization and zero trust principles, reviewing assignments alone becomes incomplete. 

Instead of focusing only on who holds certain artifacts, governance may need to shift toward understanding how access decisions are made. 

One way to think about this shift is through a concept we might call decision governance. 

Decision governance focuses on governing the mechanisms that produce access decisions rather than only reviewing the artifacts associated with users. 

In a decision governance model, organizations would ask questions such as: 

Are authorization policies defined and reviewed regularly? 

Are the attributes used in policies accurate and trustworthy? 

Are policy changes tracked and approved? 

Are access decisions logged and observable? Are exceptions or overrides monitored? 

Instead of only reviewing who has access, governance begins to examine how access decisions are produced. 

This approach aligns more closely with modern authorization systems where policies, attributes, and contextual signals determine outcomes dynamically. 

The natural home for decision governance is the authorization platform where policies are stored, evaluated, and logged. These platforms can make access decisions provable and auditable in ways traditional tools cannot. The identity inputs feeding those decisions, whether managed through an IGA platform or directly through an identity provider, still need to be accurate and trustworthy. But the accountability for how decisions are made sits with the system making them.

For security teams, this shift also reflects a broader change in how systems are designed. Many organizations are externalizing authorization logic into centralized policy engines. DevOps teams are adopting policy-as-code. Machine identities and automated workflows are multiplying across cloud environments. Access is no longer just about users and applications. It is about systems making continuous decisions. 

As this shift continues, governance models may need to evolve alongside it. 

But they may no longer be sufficient on their own in environments where access is dynamic and contextual. 

If access is calculated at runtime, governance may need to focus less on reviewing assignments and more on understanding and governing the decision systems that ultimately determine who can do what. 

In other words, the future of identity governance may not be about reviewing access. 

It may be about governing access decisions. 

Disclaimer: The views expressed in the content are solely those of the author and do not necessarily reflect the views of the IDPro organization.

About the Author

Vatsal Gupta is a Senior Security Engineer at Apple, where he focuses on authorization architecture and enterprise access governance. His work sits at the intersection of identity systems, security policy, and  agentic AI, with a particular interest in how AI systems can be governed within defined authorization boundaries at scale. Outside of Apple, he contributes to open standards through the OpenID Foundation’s AuthZEN and SSF working groups, serves on the ISSA Journal Editorial Advisory Board, and has published across academic and industry venues on topics ranging from access governance frameworks to AI-driven policy generation. He is an IEEE Senior Member and an active contributor to the Cloud Security Alliance’s IAM working group.

The post From Access Reviews to Decision Governance appeared first on IDPro.