IGA Has Failed—What is the Best Path Forward?

Initial Publication Date: 24 April 2025

Abstract

We start with the premise that Identity Governance and Administration (IGA), touted as the way to answer “Who Has Access to What?” has largely failed to achieve the results most enterprises expected over the past 25 years. IGA was initially introduced to improve the provisioning process, but it has evolved over the years to include entitlement discovery, decision-making processes, access request/review workflows and certification, along with risk scoring, identity lifecycle/role management and access compliance reporting. IGA operates at the intersection of business process management and access automation.

To be fair, the expectations of IGA have been really high and the blending of complex technology across heterogeneous environments coupled with direct business impact is really difficult to manage…and it won’t get easier as cyberattacks become more and more sophisticated.

While IGA has not met expectations, we’ll describe some of the key challenges, but more importantly, a path forward for vendors and enterprises to achieve successful IGA programs.

Authors:

Kevin Kampman

Principal Consulting Analyst

[email protected]

Executive Summary & Key Advice

Identity Governance and Administration (IGA), touted as the way to answer “Who Has Access to What?” has failed. We’ll start by describing how and why IGA has not met enterprise expectations over the past 25 years and then put some “stakes in the ground” as to how the industry and enterprises can fix this moving forward.

IGA was introduced to improve the provisioning process, that is, granting and removing access and privileges. It was intended to keep track of those grants, preserve them for inspection, and remove them when they were no longer appropriate. Sarbanes-Oxley made the ability to monitor and track approval for access, when it is in force, and how it is used mandatory for publicly traded companies.

IGA grew tendrils into the management of identities as well as resources. Information Technology Infrastructure Library (ITIL) had an early but inadequate influence on IGA. It captures data about resources but falls short with respect to identities. Many service desk products have their roots in ITIL. A basic tenet in the early days of provisioning was that the process was initiated with a request to the help desk. This technical point of view missed the wealth of decisions and activities that trigger the ticket, such as hiring, promotions, transfers and temporary assignments, suspensions and terminations. Information capture has largely been piecemeal and not necessarily considered in the umbrella approach. This tends to expose insider threat risk, where beyond regulatory compliance, theft of enterprise information such as intellectual property, sensitive customer information, and the like can lead to significant brand damage. TechVision Research discusses this dilemma in-depth in its recent report titled, “Know Your Worker (KYW): The Intersection of Worker Risk and IAM.”

IGA introduces the notion of a closed-loop system, where all activities interact and over-arching information is captured. Concepts such as authority and ownership come into play, for resources and identity as well as the supporting information. Organizations are also becoming awash in data. The need to understand its genesis, sources and sinks, interchange and dependencies is exposed.

Another challenge is that IGA assumes that there is a consistent business model that can be leveraged to aggregate people into collections that are then associated with sets of resources. A common organizational model is a hierarchy, a pyramid-like structure with the owner or CEO at the top and multiple levels of management, authority, and control flowing downward. This is a traditional organizational model that doesn’t always translate to modern organizations that may be flatter or even built on matrix models. An organization is an organism that consists of many related functions, co-existing with many other organisms.

IGA is not just a technical endeavor. What programs lack are people experienced in organizational dynamics, organizational change management, even a business sponsor. You are pushing the Queen Mary (now a museum in Long Beach CA, its’ engines removed) in a new direction, and actually exposing the business aspects of the organization that have been ignored.

IGA deployments suffer from the lack of, or conflicts between, established business processes and owners. Human resources and vendor management handle the bulk of workforce sourcing and assimilation, andgenerally have different timelines and priorities than IT when it comes to bringing people onboard. The life-cycles don’t necessarily match and it is easy to be out of synch in different areas of responsibility, particularly at the edges, such as candidates. Add in multi-national or subsidiary considerations and this becomes even more daunting.

Developing an understanding of what is achievable and agreement on how to do it should precede the selection and implementation of any toolset. Too often, these details are unknown or glossed over because of the imperative and enthusiasm to do “something”. This approach leads to unnecessary expense and likely failures because organizations rarely adapt to the tools. This is not a fault of the developer/vendor, and the buyer should know to beware.

IGA is hard. It has earned a reputation for its difficulties. This track record has spilled out into industry, and clients are rightfully skeptical of IGA’s benefits. Failures have a variety of causes, the most important of which is a lack of understanding about how the organization really works. To learn this requires a commitment of management and personnel to develop the understanding, and the expense of outside resources to collect and document these findings. Good professional services are sometimes hard to qualify; everyone is going to go through some learning curve as the examination takes place.

Governance of a modern IAM program requires three core elements:

· Alignment of business priorities with IAM investments.

· Effective business policies, standards, and processes that can be represented in the IAM model.

· Representation of business functions that harmonize with IAM intent, activities and communications across multiple functional areas.

Moving Forward; An activity checklist

We’ll get into detailed recommendations as to how IGA must evolve over time throughout this report, but we want to start with a series of steps enterprises should consider to immediately assess and improve your IAM governance posture. Technology deployment without appropriate governance simply cannot succeed. TechVision recommends that enterprises immediately begin engaging in the following activities if you are not already on this path:

· Establish a compelling business linkage to identity management.

· Objectively assess your current IAM governance program—using an external resource if possible.

· Establish an IAM Steering Committee (if you don’t already have one).

· Engage a successful executive leader and sponsor for the IAM program.

· Articulate the purpose and authorities of the steering committee, preferably via a formal charter.

· Engage decision-making IAM stakeholders to participate in an IAM steering committee.

· Select people embedded in the different aspects of the organization to represent identity – including Human Resources, Vendor and Partner Management and similar organizational units that have specific insights regarding people, process and technologies supporting these identity-centric areas.

· Manage scope and milestones. Determine what is visible, offers value and is achievable in a realistic time frame.

· Conduct periodic meetings (monthly if possible), with a focus on decision-making rather than information sharing since information-sharing forums tend to lose focus and participation over time.

· Charge working groups as needed to provide input to the steering committee. Many of the same people are likely to be required for multiple working groups, so care must be taken to avoid over-extending individuals by running too many working groups simultaneously.

· Record all meeting minutes and distribute to stakeholders through a formalized communication channel (at minimum, email distribution lists).

· Publish IAM policies and standards that encompass all regions globally.

· Build IAM requirements into the standard set of security requirements for projects, contracts, and procurements.

· Train project managers and IT procurement specialists in implementing new IAM-related checkpoints. Emphasize documentation for decision-making at all levels.

· Educate Developers and Integrators on how to consume necessary IAM and IGA capabilities, their enterprise policies for authentication and authorization, application registration – including agentic AI services, required audit trails and so forth.

· Develop methods to ensure policies and standards are followed. Develop methods to track and record exceptions that assign residual risk ownership to the appropriate business stakeholder(s).

· Review current contracts and agreements where identity data or access to corporate resources is involved to assess whether IAM requirements are clearly and appropriately addressed. Establish a project to implement remedial actions as necessary.

· Agreements should include identification of events and root-cause analysis. Consider this the closing of the life-cycle circle.

This list reflects TechVision Analyst learnings after working with hundreds of organizations over the past several decades supporting client strategies, architectures, vendor selection, process/business integration and other factors within IGA and governance.

As we describe in the TechVision report titled “IAM Reference Architecture”, we provide guidance for how to develop and use a Reference Architecture to:

· Organize business requirements.

· Tie the requirements to capabilities.

· Identify strengths and gaps.

· Measure progress.

In summary, Reference Architectures are standardized frameworks that provide a model for a domain, sector, or field of interest. Reference models or architectures provide a common vocabulary, reusable designs and industry best practices. They are not solution designs and as such are not meant to be implemented directly. Rather, they are used to guide more concrete efforts.

Typically, a Reference Architecture includes common architecture principles, patterns, building blocks and standards. Once a Reference Architecture that defines common architecture principles, patterns, building blocks and standards is developed, your organization can better evaluate vendor solutions and their ability to address the critical needs of your organization.

TechVision Consulting builds off our research with specific projects to help organizations better understand, architect, select, build, and deploy infrastructure technologies. Our well-rounded experience and strong analytical skills help us separate the “hype” from the reality. This provides organizations with a deeper understanding of the full scope of vendor capabilities, product life cycles, and a basis for making more informed decisions. We also support vendors in areas such as product and strategy reviews and assessments, requirement analysis, target market assessment, technology trend analysis, go-to-market plan assessment, and gap analysis. TechVision will subsequently publish a report specifically focusing on developing a modern IGA reference architecture, but the points we list above will be a great starting point to “right the ship”.

IGA Has Failed

Identity Governance and Administration (IGA), touted as the way to answer “Who Has Access to What?” has failed. We’ll start by describing how and why IGA has not met enterprise expectations over the years and then put some “stakes in the ground” as to how the industry and enterprises can fix this.

By introducing processes that covered request, approval, grants, attestation and removal, IGA impacted not only technical processes but also business activities. The intent is to provide a comprehensive understanding of the relationships between entities: people, agentic AI and resources, as well as the entities themselves. This is a tall order, as the boundaries continue to expand. Readers should understand and even see themselves in this discussion: The failures are shared amongst business principals, technology resources and the vendor community. The intent of this report is to move the community forward, not lament about things we can’t change.

Expanding Expectations

While the early days of provisioning had major challenges, we then expanded scope to add the notion of Governance and Administration to the provisioning process. It expanded the reach of the technical activities, and extended integration into areas such as human resource management and the service desk, as well as risk management and security. IGA exposed the need for resource definition and administration, privileged access management, human and non-human profiling and tracking.

Governance

The linkages between human resources and provisioning cried out for better control and management of these relationships, especially as the driver of attestation was added to the mix. IGA introduces the notion of a closed-loop system, where all activities interact and over-arching information is captured.

Concepts such as authority and ownership come into play, for resources and identity as well as the supporting information. Organizations are also becoming awash in data. The need to understand its genesis, sources and sinks, interchange and dependencies is exposed.

Significant lines of demarcation come in to play. Questions arise about the interplay of processes and data in the organization, and the risks and benefits associated with it. The idea that every process has an owner extends to data. Pulling the one thread of identity pulls on many other aspects of how organizations operate, and how these operations are controlled.

The Great Business Divide

At this point, you can see that IGA provides a massive impetus for understanding and change. However, the business is not focused on itself, it is looking outward. It is less interested in the levers of management than it is in driving revenue. Introspection is not a native activity and business principals often reject the idea that they are responsible, even though this is implicit in any organization. They don’t see the relationships between one activity or decision and its downstream affects.

Technologists supposedly rely on guidance from the business. Whenever guidance is absent or withheld, it is likely that technologists will take matters into their own hands. It becomes less of an opportunity to collaborate; more something to finish quickly and move on to the next issue. The opportunity to get things right or to address the bigger picture is lost. IGA becomes a box to check and original motivations diminish. Necessary levels of enterprise risk management are subjugated to time-to-market demands.

Organizations Don’t Always Fit the Models

Matrix management is one where the relationships become more like a mesh or network. One can manage people by projects they work on, for example, while these people report and are accountable to someone else. We are also seeing very flat organizations where decision-making is distributed. In reality, multiple approaches are often in play, particularly as the size of the organization or the markets it serves requires adaptation.

A major challenge actually goes beyond the organizational model. No matter what organizational model is used within an enterprise, it is likely to have many exceptions that are hard to factor into an IGA program. Organizations change internally due to business conditions, they merge or are split off into other companies, and fixed models are challenged. Building a digital twin or template of the organization in an IGA product is fraught with risks, but the reality is that organizations must ultimately deal with this. The tool must adapt to continuous changes, making design decisions, process, policy, data and relationships very vulnerable. Many IGA tools are rarely so flexible, but going forward will need to be.

How did we get here?

While every organization should factor in your unique considerations: Your current technology landscape, major business and technology challenges/initiatives, risk appetite, budgets, Line-of-Business (LOB) initiatives, key technology trends, security posture/risk profile, your response the post-pandemic environment and overall business goals, to name a few. This list and our recommendations in this report can be a starting point. We’ll now look at specific areas that led to the challenges with IGA over the past 20+ years.

Naivete

The people involved in the design and deployment of an IGA tool or its near-cousins, human resource management or service desk usually don’t have the opportunity or insight necessary to understand what parts of an organizational structure are stable and where they are likely to change. Early research by the author found the idea of organizations as organisms interesting, but hardly able to compete with the hierarchical influences by vendors present at the time. Even the idea of matrices wasn’t taken into account. Today a hybrid model, hierarchy plus matrix, is prevalent.

The competing requirements of attestation and accountability, and the fit of the tool to the characteristics of the organization are rarely discussed. It is easier to assume that the organization will adapt to the tool than the other way around. This is a fatal assumption.

Business principals are charged to make attestations happen. Technologists lack insight on organizational dynamics, and don’t have enough influence to push back. They have a box to check and not enough time to do it. It is left to the vendor to make things work, even though the generic models baked into the product architecture aren’t a good fit for the program.

When a tool can’t easily accomplish provisioning because of process or organizational considerations, the model chosen is often the root of the difficulty.

Investment

IGA projects are usually scoped based on insufficient insight and understanding of the organization. Project similarities are cited when describing the work to be done. Good project managers know that it is very difficult to project accurate milestones and predict the costs the first time around. It takes a successful project to understand what all is involved. Evidence shows that whatever the anticipated expenditure, it is rarely enough. This comes from a lack of understanding of the scope and scale of the program.

IGA projects are never done. In fact, as TechVision highlighted in an earlier report on IGA, it shouldn’t be viewed as a project, but as an on-going program. An IGA program must keep up with organizational and technology change. A former Burton Group/Gartner analyst (Lori Robinson, now at SailPoint) characterized it like the laundry: “Wash, rinse, repeat”. IGA and identity management are part of a program where people are a major aspect of organizational management. It is not a technology decision; it is a lifestyle change; it’s a result of introspection and maturity. Until identity is viewed as a pillar of organizations, tremendous investment will be made in tactical solutions. As analysts and consultants we often said that it takes three times to get an IGA deployment right; in fact, this is speculation as many programs are just reaching that third hurdle, along with the splints and bandages to show for it.

Approaches

IGA is never sold to the CEO of an organization, although perhaps it should be. It is usually delegated to a technical manager or director to find a product and get it installed. Again, checking the box. Certain organizations recognize that this is unlikely to succeed. They develop committees to architect, design and implement the solution. There is recognition that an outside resource is needed to assist, this usually comes from a professional services firm specializing in identity management. Experience varies among these firms, and they are careful to share what works and what doesn’t, but it is unlikely that they’ll walk away, even when they should. These firms can also have relationships with specific IGA or IAM vendors and will work to ensure the client fits the tool, rather than deploying the appropriate tool for the client. This results in a square peg in a round hole situation more often than not, with underachievement or failure as the result.

Their motivation to represent a product comes from their own investment in training and experience. Some might argue that the major products on the market are basically the same, the key ingredient is the services capability behind it’s deployment. We’ve noted that over time, these firms consolidate. The reason is to capture the product and project experience. Trust the professional services firms that are willing to say “no” and push back on your assumptions. That is their experience speaking; you should heed their advice.

Missing Components

You should be getting the sense by now that IGA is not just a technical endeavor. What programs lack are people experienced in organizational dynamics, organizational change management, even a business sponsor. You are pushing the Queen Mary (now a museum in Long Beach CA, its’ engines removed) in a new direction, and actually exposing the business aspects of the organization that have been ignored.

Organizations that have invested in consumer identity in digital markets recognize that they are on a new playing field. Whereas the workforce and supply chain forms of identity are rigid, inflexible and dated. I contend that there is really no difference, identity is identity. What has changed is the context and the supporting infrastructure that enables it. Understanding these aspects and how they relate to what you want to accomplish provides flexibility in the design of your solutions. A sidenote, it is important to understand that SAP has deprecated its embedded identity solution. They still offer their Customer Identity Access Management (CIAM) solution. Perhaps they’ve accepted that identity is identity.

Adjacent Technologies

So far, we’ve given lip service to HRMS and Service Desk solutions. IGA is usually positioned in a workstream preceded by these, and followed by specific applications germane to the business. As we recognize that identity is identity, other products fit into the adjacency space, such as ERP, CRM and cloud solutions. Each of these have their own concepts and conventions around identity. It is unlikely that they will converge on standardized approaches, as every environment is fit for purpose. Understanding how each produce and consume identity will be important to fitting IGA into the stream, if not at the center. This will also enhance and simplify the understanding required of identity practitioners.

As this report is published, the discipline of non-human identity has emerged. Many of the same identity management principles apply whether we are dealing with people or things. Anything we manage as an entity is an identity of some form.

Process Establishment

IGA deployments suffer from the lack of, or conflicts between, established business processes and owners. Human resources and vendor management handle the bulk of workforce sourcing and assimilation, and generally have different timelines and priorities than IT when it comes to bringing people onboard. The life-cycles don’t necessarily match and it is easy to be out of synch in different areas of responsibility, particularly at the edges, such as candidates. Add in multi-national or subsidiary considerations and this becomes even more daunting.

IGA tools are designed around best-case, best-effort scenarios. Businesses, on the other hand, must address specific and inconsistent practices that may be one-offs or exceptions. Some companies (in other cultures) have asserted that everyone is unique or special; they need a concierge approach.

*BAC (Star-Based Access Control) Insufficiencies

There are a number of Access Control approaches. They are aligned with the characteristics of the organization(s), policy, data, credentials, separation of concerns, anything which provides insight into the access decisions to be made. Some are dynamic, some are static or established. A good identity analyst needs the freedom and ability to apply one or several to a given situation, not adhere to an approach that may not be optimal or even related to the situation in question. Whichever you choose, the dependencies need to be clear and consistent, and the scope of applicability and effectiveness understood. There is no one-size-fits-all in a global community.

Access control models attempt to categorize relationships between users and resources. These relationships can be one-to-many, one-to-one or many-to-many. The relationships may be static or dynamic, and depend on conditions or policies and other attributes that influence access decisions. Some of the characteristics may not even be articulated until the time of access.

As the IAM industry expanded, simplistic relationships anticipated in the field turned out to be more complex; access decisions and interactions between identities and resources required deeper analysis and customization leading to one-off situations. Sometimes these approaches conflicted with one another. Any expectation of simplicity fell by the wayside as these environments were exposed. Metrics and guardrails to keep projects on track became necessary and grew as deployments increased. Getting a few systems connected was the reality, not the hundreds as anticipated. One company had more developers supporting their enterprise deployment than the product vendor itself; filling the management role appeared to be career suicide.

This realization dampened the enthusiasm for automation for vendors, integration firms and clients. The underlying assumptions fell apart as systems were analyzed and connections attempted. Anticipated similarities and efficiencies did not exist. Legacy approaches used to develop and deploy these systems were limited by product flexibility; sometimes programs had to limit expectations of scope. This is frequently the case for Enterprise Resources Planning (ERP) systems. Client projects to normalize identity across multiple ERPs met with failure. They were not deployed using the same approaches or with any sense of organizational consistency or identity in mind.

The key issue for access control and organizational groupings is that IGA is expected to accommodate tactical decisions made at different times and in different contexts. There are many round pegs and square holes. Any intersections are at a high and abstract level. They do not necessarily apply across multiple contexts or applications.

Moving into products like Microsoft Active Directory and Entra, using security groups as roles is problematic. Often, there is no overarching management strategy, risk ownership, documentation or even naming conventions that help to organize a consistent top-level viewpoint. Access decisions are often ad-hoc and tactical and rarely consider overlaps or possible security errors. Enthusiasm, expedience and a box-checking attitude lead to significant future pain.

Process Absence

Like access controls, there is a lack of consistent and clear definition and processes for identity events. Vendors and services firms offer generic templates for onboarding, suspensions or terminations. But, they admit that the devil is in the process details. None of these templates are complete out of box. Implementors may or may not have insight into the use-cases that exist and the exceptions that arise in the course of implementation.

Transfers are known to be the most difficult event to address, since there are many so considerations to take in to account as someone transitions from one position to another. These include approvals, overlap and termination of access, accumulation of privilege over time, and SoD concerns. As a result we can say with certainty that no two organizations are the same, nor is their identity management.

Lack of Appetite

Management and personnel focused on something else leads to poor commitment and a resulting fulfillment of expectations. Choosing the right management sponsor is critical to the articulation and support of these expectations. You can’t take your eyes off of the goal, and the longer the effort takes, the more likely it will be subsumed by some other priority. It is best to adopt an iterative and learning perspective, there is no “Big Bang”. Better to start small, focusing on bigger risk systems and applications. Trying to boil the proverbial ocean almost always leads to complete failure. This is important to set expectations at the business planning juncture, so as to keep adding small wins that lead to meaningful improvements in risk reduction over time.

Lack of Expertise

If you’ve never done it before, you probably don’t know how to proceed. There are any number of good practices associated with development, program and project management that can be applied to an IGA initiative. There are communities of interest, vendor forums, analysts and consultants to speak to. The only way to get experience is to expect and anticipate failure. Recognition of all successes will improve engagement and collaboration. Rewarding failure and learning from your mistakes is also an imperative.

The Enterprise IGA Path Forward

Typically, organizations have placed too much emphasis and reliance on technology to solve their access management problems. Focusing on incomplete aspects of the problem, and implementing point solutions that only address those part of the problem lead to unmet expectations. As a result, organizations often end up with too many IGA-related tools requiring significant customization to address the organization’s requirements. These may then depend on specialized, technically focused personnel (often on the help desk) to maintain the collection. Unfortunately, this often leads to inflexible deployments that have difficulty adapting to changing business needs. IGA, if executed properly, is about facilitating how people make effective business decisions.

Modernizing IGA: Start with an understanding of the problem

IGA is a process as dynamic as enterprise life itself. That is why modern IGA is not simply a product or a solution. It is a program which touches every key decision maker of the organization, no matter if this person is in senior management, human resources, a line of business, or IT.

That breadth of involvement is why building a successful, sustainable IGA program is critical. It’s not an easy task. TechVision Research offers our IGA Reference Architecture for enterprises to consider. To successfully develop an actionable Reference Architecture for IGA, one must evaluate an organization’s technical architecture, management processes, risk register and overarching organizational governance maturity. This can help set the course for progress in an organization as it rolls out an effective IGA program.

IGA leverages components such as Identity Lifecycle Management and Access Governance to support compliance with regulations, internal controls, audit pressure, and is a powerful means to improve security and reduce enterprise risk. Enterprises can implement an IGA program using both internally developed processes and commercial off-the-shelf (COTS) products. Numerous vendors are offering products that are sophisticated and well thought out, often as a part of a larger IGA suite. Importantly, most organizations can implement IGA in phases that can make it easier to adopt and make auditors and risk managers happy, while providing a solid foundation for reducing compliance risk and improving information security.

Organizations looking to get a handle on how access is being granted and managed over time and would like to evolve toward a “least privilege” approach to issuing access, should consider how IGA can help achieve these goals. Identity Governance Administration requires a fundamental understanding the current state of entitlements across all of the critical systems throughout the enterprise as well as what operations and data to which they actually grant access.

These capabilities include access certification, access request, role management, and the automated fulfillment and enforcement of changes to entitlement settings through identity lifecycle management as well as applying entitlement risk scoring in adaptive access control systems, Just In Time access granting that eliminates “standing privileges”, and aligning roles and activities with privileged access management. Some key characteristics of IGA programs are:

· IGA is a program, not a project. As with most IAM services and capabilities, IGA will continuously need to morph as business and technology evolves. Project milestones are of course necessary, but the program must continue in perpetuity if it is to remain effective.

· Decision factors that drive adoption and implementation of IGA include ensuring data quality, managing the entire data lifecycle as well as the identity lifecycle, and providing meaningful insights to the business to facilitate better access control and risk management decisions.

· Security and compliance generally drive the entitlement management and entitlement catalog efforts.

· Employing access governance and improving role management are deployed to harden identity and security services to mitigate the risk of security breaches and in response to compliance pressures from a variety of regulations.

· Proper establishment and maintenance of entitlement catalogs is key to IGA deployment and efficacy – including use of discovery tools to determine and maintain access entitlements in the most up-to-date manner.

· IGA incorporates the process of collecting and organizing the current entitlement state data and presenting that information to those within the organization that can best determine whether the right entitlements have been issued.

· IGA provides an excellent mechanism for documenting and tracking how enterprise systems work and provide an audit trail for the “access control decision making process”.

· Collecting descriptive information for entitlements creates a deeper understanding of new and legacy systems, insuring against institutional knowledge loss due to retirement, outsourcing, and organizational churn. Entitlement catalogs are a great way to retain entitlement information independent of whoever is serving as the application owner.

· IGA enables the automation of the identity lifecycle through an identity provisioning infrastructure. This helps both fulfillment and the enforcement of access decisions. The automation and enforcement prevent deviation from these decisions and reduces the amount of effort required for the next round of access reviews.

· IGA enables an ongoing means of governance through a set of controls, processes, and actions related to the determination and enforcement of appropriate access throughout the organization’s environment. This is a continuous process of grooming, review, decision making, documentation, and enforcement for how access privileges are issued – and with each iteration through this process, it makes it that much easier to maintain and audit.

· IGA facilitates documenting access policies that are understandable by humans (e.g., developers and integrators) and consumable by AI agents to enforce during runtime.

Take a holistic view of the governance life cycle

A well-organized IAM program provides the necessary structure for all IAM services in a way that addresses the challenges of coordinating technology projects that require identity-related services, ensuring alignment with business needs and providing oversight of ongoing operational activities. We believe the key for most organizations will be to make progress on IAM governance and adopt a holistic view of the governance life cycle per the following graphic:

Figure 1: IAM Governance Activity Cycle

Governance of a modern IAM program requires three core elements:

· Alignment of business priorities with IAM investments

· Effective business policies, standards, and processes that can be represented in the IAM model

· Representation of business functions that harmonize with IAM intent, activities and communications across multiple functional areas

Direction and authority flow from senior management and the board of directors to business and technical management and implementers. Results return from staff in an iterative manner. Governance is NOT “fire and forget”.

Moving Forward; An activity checklist

Technology deployment without appropriate governance simply cannot succeed. Therefore TechVision recommends that enterprises immediately begin engaging in the following activities:

· Establish a compelling business linkage to identity management. (i.e. security and compliance, operational efficiency, business agility, customer engagement, and/or revenue protection)

· Objectively assess your current IAM governance program—using an external resource if possible.

· Establish an IAM Steering Committee (if you don’t already have one).

· Engage a successful executive leader and sponsor for the IAM program.

· Articulate the purpose and authorities of the steering committee, preferably via a formal charter.

· Engage decision-making IAM stakeholders to participate in an IAM steering committee.

· Select people embedded in the different aspects of the organization to represent identity – including Human Resources, Vendor and Partner Management and similar organization units that have specific insights regarding people, process and technologies supporting these identity-centric areas.