Identity Governance 101: Getting Started

A beginner’s guide to getting started with Identity Governance

In today's digital age, protecting sensitive information and ensuring compliance are paramount for organizations of all sizes. One of the key strategies to achieve this is through Identity Governance. For professionals in the Identity and Access Management (IAM) space, Identity Governance and Administration (IGA) is a pillar concept; for organizations new to this acronym-heavy world, however, it can feel more like a maze of jargon than a clear security strategy. This guide was created for those who are just trying to understand what it is and how to get started.

A quick note on evolution: Before analysts like Gartner® consolidated their identity-related Magic Quadrants into the unified Identity Governance and Administration (IGA) space, Identity Management and Identity Governance were distinct categories. Vendors in the space have since acquired or developed new features to align with this broader definition. This is why you may see IGA, Identity Governance and Identity and Access Governance used interchangeably. 

What is Identity Governance?

Ask a tool like ChatGPT or Microsoft Copilot "what is Identity Governance", and you might get a textbook definition like this:

“Identity Governance refers to the policies, processes, technologies, and tools that are used to manage digital identities and ensure that access to an organization's resources is compliant with both internal policies and external regulations. Its primary objective is to manage user identities and their access rights across various systems and applications securely and efficiently.”

All of that sounds great, but where do we get started? Many folks who aren’t experts imagine something like the following AI-generated image when faced with what can be a highly technical and complex challenge:

Because this is a guide for beginners, though, we are going to break Identity Governance down into bite-sized chunks that are easily digestible.

Identities

One of the foundational phases in any identity governance program is to catalogue all identities. The moment we start to execute on this, though, it's possible we will immediately run into some roadblocks. To navigate them effectively, it's helpful to start with a few key concepts:

• Authoritative Sources – exactly as the name implies, it is the source of authority for a given identity.
• Attribute Authority – similar to an authoritative source, but not for the entire identity, just for one or more specific attributes.
• Identity – an actual human being with a heartbeat.
• Account – a thing that can be used to login and do stuff in one or more applications.
• Entitlement – a permission or privilege that is granted to an account or identity.
• Attribute – a characteristic or property of an identity, account or other object.

Let’s give an example of these concepts in a real world example. At our sample company, IG Inc., we have an HR system that acts as the Authoritative Source for all employees and a contractor management system that is used as the Authoritative Source for non-employees. When a new hire is entered into the HR system, their Identity will be created automatically and employee type attribute is set to “E” for employee. Based on this “E” value, we will automatically create an account in our email system, which generates a unique email address for the user. Because the email system is the attribute authority for the email address attribute, it will be synchronized back to the HR System to ensure everything is kept in sync.

In our sample company, we need to go to two independent authoritative sources to get a full catalog of all human beings – the HR system and the contractor management system. This should provide us with a list of every human being in our organization. Once we've compiled this list, we then need to shift our focus to applications—where those identities actually interact with technology.

Applications

Applications are the things people are using on the computers every day to perform various activities, of which organizations can have many. This phase requires us to figure out who owns each and every account throughout all of our applications. Before trying to boil the ocean, let’s break the problem down and tackle it one application at a time with an approach that I like to call the three-bucket solution. 

Step 1 - Correlation

Correlation is just a fancy word for matching. Our goal in this step is to take the full list of accounts in a given application and divide them into two buckets. The first bucket, which we can label “correlated”, are accounts that we can correlate back to an Identity from an authoritative source. We check things like employee number, email address, username, or some other unique value. If we can figure out who owns it, it goes in the first bucket. If we cannot, we drop it into our second bucket, labelled “orphans”.

When using software tools, this correlation process can go very quickly with coded logic. Other processes involve manual or scripted efforts, but ultimately, the goal is always the same: determine who owns the accounts. 

Step 2 - Orphan Management

Once we have made our first pass, we need to deal with everything that landed in that second bucket – the “orphans”. We have three choices for the orphans: 

1. Manual Correlation – if we were using automation in Step 1, this is where an account can be manually correlated to an Identity, even though it didn’t correlate according to the logic we provided the automation. Essentially, have a human being look at it and determine if they know who owns it. If we have an owner, we are essentially moving it over to the first bucket.
2. Non-Human Accounts – many applications can have a classification of accounts that are not owned by an individual, but are required to be there. Some examples are service accounts, builtin accounts, API accounts, BOT accounts and test accounts. These accounts can be moved to our third bucket, labelled “non-human” accounts.
3. True Orphans – we looked and it doesn’t belong in one of the other two buckets. These accounts are truly orphans. 

As a side note, the “non-human” bucket list should probably be provided to our Privileged Access Management (PAM) team as they are usually handled differently, with their own sets of policies and controls. 

Step 3 - Empty the Orphan Bucket

There are only two methods we can use to empty the orphan bucket. The first is to reclassify them as "correlated" or "non-human", but we did that in the previous step of this process, so that just leaves one final alternative - disable them.

Can more be done? Yes, but the answer becomes more advanced, so for the purposes of this beginners guide, we are going to leave it here. So, we create a strategy to turn them off in batches and see who screams or what breaks. If this strategy is not acceptable at your organization, we can work on the more advanced topic, but we are keeping this beginners guide more simplistic and avoiding that rabbit hole. 

Can more be done? Yes, but diving deeper quickly moves us into advanced territory. For this beginner’s guide, we’ll keep it simple: create a strategy to turn them off in batches and see who screams or what breaks. If your organization needs a more cautious or complex approach, that’s a discussion for a more advanced guide or you can schedule a call with our team of experts.

Policies, Processes and Controls

When discussing the topic of Identity Governance, most guides will immediately jump to policies, processes and controls. This guide focused on Identities, Accounts and Classification first. Why? Because now you have a clearer picture of how you can achieve policy and process goals, as well as how you can measure them for your control requirements.

Policies

Our goal up to this point has been to understand who owns every single account across every single application in our organization. By breaking it up into individual applications, we can begin to apply policies as we finish using our three-bucket solution on a given application. Here are some policies we can consider:

• Access Control Policies – defines who can access specific resources under what conditions. These can be further broken down:
  • Role-Based Access Control – Assigning permissions based on role or job function an individual has within the organization.
  • Attribute-based Access Control – uses attributes, such as job title, classification, department or other attribute.
  • Policy-based Access Control – assigning permissions based on policies within the organization.
  • Request-based Access Control – assigning permissions based upon a request being made and appropriate approvals being provided.
• User Provisioning and Deprovisioning – automates the process of creating, updating and removing user accounts and associated access rights.
• Access Certification – reviews user access rights to ensure they are appropriate or no longer necessary.
• Segregation of Duties (SoD) – ensures that toxic access combinations are detected and reported upon.
• Password Policies – enforces the appropriate rules governing passwords are being applied properly, such as expiration periods, MFA requirements and possibly even complexity requirements.
• Audit and Reporting – Tracks and logs who had access, when they had it and when it was observed to have been removed.

Upon quick glance, it's easy to see that all of these policy goals require the prerequisite steps of understanding the ownership and classification of each account and associated entitlements. When we can identify the owner of an account and the authoritative system behind the identity, it becomes much easier for us to answer key questions: Which policy was used to provision the access? Should that access be removed if the person leaves the organization? Or should it be reviewed and recertified when the individual is promoted?

Processes

Identity Governance programs often become the lynchpin for many internal access control processes, including but not limited to:

• Birthright Provisioning – this is the process of automatically assigning access to users upon starting or automatically adjusting the access when an individual changes position or department
• User Access Review Campaigns – many regulations and standards require regular user access reviews, and they are also great for just maintaining good security posture within an organization. These reviews are often a good self-audit of your controls around the removal of access rights.
• User Access Requests – the process by which users can request access to various applications needed to perform their job duties.

Information is a key driver in all processes. By providing a catalog of who has access to what, it can help inform us where gaps in access exist or where access requests are commonly made and granted. None of these can be done without having the underlying data that comes with the Identities and Applications phases.

Controls

Key Performance Indicators (KPIs) are often used by leaders to get a quick snapshot of performance. KPI dashboards work very well to understand how well the organization is adhering to their Identity Governance goals. Some examples of key KPIs that we can monitor to measure the efficiency and effectiveness of our Identity Governance program are:

• Access Certification Removals – how often are we catching access that should be removed in our review process? If frequent, this could indicate a gap or breakdown in our access removal process.
• Average time to provision / deprovision – this will help measure the efficiency of our process to get access provisioned or removed and the associated risk of either use of inappropriate access that should be removed or lack of productivity due to missing access.
• Role-Based Access Control Coverage – How much of our access is provisioned automatically versus how much requires the request and approval process. Automatic provisioning is much more efficient and reduces the amount of time to get access as well as the number of human touchpoints required to request and approve it.
• Number of orphaned accounts – Orphans are accounts that have access to our systems that we do not know who owns them or what they are used for. This is unnecessary risk of a breach.
• PAM Coverage for Non-human accounts – how many of the accounts that landed in our third bucket with the “non-human” label on it are governed by our Privileged Access Management (PAM) program. Privileged accounts with no governance on who can access them can add significant risk to an organization.
• Access certification policy violations – ensure that all accounts covered by a control are being reviewed as often as our control definition says they will. Compliance regulations commonly require regular reviews of access and having a continuous evaluation of adherence can help internal compliance teams sleep better knowing no matter what sample the auditor chooses, they will be in compliance.
• Password policy violations – We are looking for accounts that are in violation of our password policy control requirements, once again providing peace of mind for compliance adherence.

The goal within an Identity and Access Governance program is to understand what our control requirements are, then evaluate those controls against the data we get from all the applications and proactively alert or take action before it becomes a policy violation. Sometimes leaders are concerned about what their auditors are going to find when they do their random sample – the Identity Governance program’s goal should be to evaluate those policies and controls against every single account in every application continuously. This way, no matter what sample the auditor takes, we already know what the results will be. 

Conclusion

It is often a daunting task to start with the requirements and try to create all of the necessary frameworks to meet the requirements. In this brief guide, we worked backwards from best practices and showed how starting with the fundamental goal of understanding where all the accounts are and who owns them can help us arrive at all of the policy goals.

While it can be a large and complex undertaking, it becomes manageable when we break it down - start by identifying all your people, then iterate through your application catalog one application at a time, using the three-bucket solution to understand the purpose of every account.

You can do it! Just start with what you know (your data) and work backwards to fulfill your control requirements from there – not the other way around.