none-thornton-data-services-3tugk

How Many Roles Should I Build?

Wed, 11 Mar 2026 04:18:37 GMT

The Answer is in your data, but there are bounds.

This is the second most common question I'm asked, and a close relative of "What Roles Should I Build?". Sometimes it comes with contextual information like "If I had 10,000 employees" or "We just want birthrights" (which is a wildly overloaded term worthy of its own post). The motivation is clear, the desire to know in advance how much a thing will cost,what it will take to maintain it and what value it will return are all tied up in this surprisingly simple question.

The short, and likely infuriating, answer is: "Build as many roles as add value to your organization.". The reason this question is infuriating is because you do not know how many that is. If you did, you would not be asking the first question. Do not be alarmed by this, it is not a question for intuition and you have not been taught how to determine it. The answer, which will surprise no one who's been following along, is in your data. A formal mathematical evaluation of the relationship between your identities and their access needs to be conducted to determine which potential roles could add value to your organization. Those are the roles, from those with the greatest potential value, to the least, that should be created.

Potential roles that do not add value, because they have too few people, or too little access in common, should not be built. Failing to make this determination prior to role creation is the source of the dreaded "Role Explosion", a term meaning an overabundance of roles that aren't adding any value to the organization. This might seem like a trite observation, but the way in which you avoid building too many roles that don't add value is by not building them. In many cases the automated role creation tools that come with IAM solutions will allow you to create those value-less roles. They should not be used without making your own evaluation first.

The answers above are still unlikely to satisfy, without your Identity and Access data the best I can do is set some boundaries on the problem space and describe the effort required that's based on the number of roles.

The boundaries on the number are simple, the lower bound is zero. There are organizations that will not benefit from a roles program. If there is no discernible relationship between a populations access and their job than there's nothing useful to build a role on. This is a rare edge case but I've seen it in two instances, the first was a company that was clearly in crisis, it had never formally captured its organizational hierarchy beyond reporting, no divisions, no departments etc... While the situation was salveagable it first required an organization generation effort (it would be too generous to call it a re-org, since it had never org'd in the first place) to delineate responsibilities and reporting structures beyond simply "who manages who". The second example was an organization that was so young, effectively a startup, where everyone wore multiple hats meaning that there was no relationship between any identity attributes and the access that a person had, typically because everyone had access to nearly everything.

The upper boundary on role creation is only slightly more complex and its based on a pretty simple calculation, it is an order of magnitude more effort to create and maintain a role than it is to request and review access for a person. Since roles that cost more than reviewing a persons access don't add value, they should not be created. Them maximum number of roles that should exist within an organization should be at least an order of magnitude less than the number of identities that are under management. If you have a hundred people, you should have no more than ten roles. Most organizations ideal role models are significantly smaller than that.

The final hard numerical answer to the question of "How many roles should I build?" can only come as a result of a detailed Role Model Analysis of your organization. This is what we do at Thornton Data Solutions. If your organization is wondering "How many roles should I build?" along with "Which ones?" and "In What Order?" reach out and we'll help you get started reducing the cost of your IAM operations with an Access Consolidation Program.

What Roles Should I Build?

Wed, 18 Feb 2026 06:53:48 GMT

Deciding what roles to build requires you to weigh the benefits of your options.

One of the most contentious questions in an Access Consolidation Project is what Roles (or other Access Consolidation Items) an organization should build. The two most common answers to this question "Job Title Based" and "Department Based" have been argued by their champions and their detractors for years now. These approaches have champions because they have been seen to work by different people, but how can two very different approaches to role creation both be right?

Because they're right for the organizations they were built for. Different companies have different relationships between their Identity Data and their Access Data because they have different growth stories. Even within the same industry vertical (e.g. two banks, two manufacturers or two hospitals) the optimum structure of roles may be very different because the history, structure and access between the organizations will differ. Different people, in different places, at different times, make different decisions, and they all impact the value of role structures. What works for one company will not necessarily work for another.

The key to optimizing a role structure is to look at the underlying data and make an informed decision based on which potential role structure will produce the greatest value for the organization. Any Identity attributes that could have a predictive relationship to granted access should be considered for inclusion in a potential role model. If you're going to dig through "Job Title" and "Department", you might as well dig through everything else as well, "Company" (if you're a conglomerate), "Division" and "Team" (if you have a multi-tiered organizational structure), "Location", "Store" or "Warehouse" (if you have geographically distributed operations) should all be considered. Given the quantity of potential roles that may need to be considered I strongly suggest using automated statistical analyses to filter out candidates that have no chance of adding value to an organization. If it finds for example that there's no relationship between "Location" and the work that a person is doing, as might be the case if an organization was entirely remote, or entirely co-located, there's no reason to further consider building that role.

The short answer to "What Roles Should I Build?" is "Your Data Will Tell You", but you have to be willing to look at the data, and potentially sift through the noise of messy Identity and Access Data (for more on that read here) to see what your options are before coming to an agreement as an IAM organization on what the best Role Model is for you. Your organization may have perfectly valid reasons to reject seemingly valid mathematically superior choices as well, for example, potential roles may depend on corporate structures that may soon cease to be relevant due to divestment.

There is no simple answer to the question "What Roles Should I build?" but the questions and analysis that need to be done to answer it are known. If your organization is considering an Access Consolidation program and wants to make sure that it performs the necessary analysis correctly and chooses the optimum Role Structure. Reach out to us and ask about how Thornton Data Solutions can help them perform a Role Model Analysis. We can't tell you right now which roles you should build, but we can absolutely work with you to figure it out!

How do I prepare for an RBAC program? (Part 2, Socially)

Thu, 05 Feb 2026 15:04:03 GMT

How can I prepare my IAM team for an RBAC project? (Part 2)

In a previous blog post we went through how to prepare your IAM team for an Access Consolidation project technically. If you've read my previous blog posts outlining why an RBAC (or other Access Consolidation program) can be difficult, you'll already know that these projects are as Social as they are technical. That means you'll need to prepare for the social aspects of these efforts as well. And to do that you'll want to...

1. Find and/or create champions beyond your IAM team

You will need to engage people outside of the IAM organization and have them make decisions about the contents of your roles. Sometimes they will be your peers but often they will be your boss's boss's peers (or “Grandboss” to steal a term from my wife). Depending on how your organization views hierarchies it may be necessary to have these conversations initiated by someone senior to your IAM organization. Even if it isn't ultimately necessary it will make your job easier to have support from senior leadership.

2. Identify initial teams to work with for role creation

The first teams that you work with are key to building momentum and refining the skills and deliverables used for further engagement, preferably with amenable partners. Optimally your first engagements should be with teams that you already have a good working relationship with, since IAM teams tend to fall under IT or Cybersecurity departments this may be a good choice. It’s worth noting though that these teams typically are not highly valuable targets for role creation due to their small sizes and heterogenous access. If you have good relations with the leadership of organizations that have high volumes of access requests and/or sizeable access certifications they may be good choices as well, but you will need to weigh their ability to understand the problem and solution against the impact of creating a role for their organization. The unfortunate truth is that the closer an organization is to understanding the solution, the less likely they are to need it.

3. Prepare yourself and your team

Most people in the IAM space come from a a technical background, typically with software or IT backgrounds. The RBAC programs require extensive socialization which I've written about here and here . Your team will need to meet with small teams of relatively senior people to sell them on the value proposition of role creation and ensure that they make decisions on the contents of their roles. You'll want to identify someone who can do this on behalf of your team and make sure they're up to the work.

In my previous post on preparing for an RBAC effort I ended it by saying that the preparation was optional. That's true for the technical details, especially if you intend to bring in expertise to assist in the technical work and don't have the bandwidth to perform them. Unfortunately, the social preparation outlined above is less optional. RBAC is unavoidably a social endeavor, but it is one that you can prepare for, and the payoff is well worth it.

If you're looking to start your organizations RBAC journey or get it back on the right track from a previous effort, and you want to ensure its success, reach out to us and we'll get you started.

How do I prepare for an RBAC Program?

Wed, 28 Jan 2026 20:09:59 GMT

What can I do to prepare for an Access Consolidation Project? (Part 1, The Technical Part)

Professional chefs don’t prepare their ingredients as they cook. They prepare them in advance and then cook, it’s a concept called “Mise En Place” and it allows them to focus on the task at hand when they’re cooking. You can cook without doing it but once you’ve done it you won’t go back. It’s easier to add a diced onion when you need it if you’ve already diced it. An Access Consolidation project is no different, you don’t have to do these steps in advance but if you do you’ll set yourself up for success.

1. Bring as much access data and its provisioning as you can into your IAM system

Automating the provisioning of access is a task that is best performed in an IAM system. Sure, you could leave it up to the legacy scripts and rules built into downstream applications, but your organization will befit in the long run from having a single tool and a single team to deal with when they need to resolve access issues. If you're in charge of an IAM program you will be the person that people,come to for access issues regardless of whether the access is being managed by you and your team or not. Move it in.

There's also a mathematical reason to move the access into your IAM system, so it can be included in an Access Consolidation Item. The more access you can put into an item the more work it will eliminate. Your goal for this should be to put as much access into as few items as possible.

2. Bring as much relevant identity data as you can into your IAM system

Access Consolidation requires information about the identities it is providing access for. You can't assign a role for a bank teller, use a doctor patient relationship for FGA or authorize access for security personnel if you don't have the relevant information about the identities that you're trying to provide the access to. If your IAM system was configured by a third-party there's a good chance they didn't bother to include all relevant identity information. In this case relevant means any information, almost always from an HR system of record, that describes the work a person does, including how they do it, why they do it and where (both physically and in an organization) they do it. You don't need everything from HR, you will not need identity information that isn't relevant to a person’s work, no telephone numbers, social security numbers, emergency contacts and you're certainly better off not having that information in your IAM system. What you will want are things like: Job Title, Work Location, Division, Department or Team. Not every organization has all of those and there might be more that are relevant. If you're unsure reach out and I'll happily tell you what's relevant.

3. Clean up that Identity Data as much as you can

There have been a lot of posts on LinkedIn recently bemoaning the fact that Identity teams are downstream of producers of bad identity data. I have some unfortunate news for you, that "bad identity data" (e.g. meaningless job titles, organizational elements that aren't at all organized, personal identifiers that aren't static), you're going to want to clean that up as much as possible. It might seem unfair but unfortunately you are the only team in your company that can do anything about this because you're the only team in your company that can see it as an issue. Some of this you can handle within your own organization such as normalizing job titles within your own tools, assigning unique personal identifiers or deriving an actual organization from a management hierarchy. Do what you can.

3. Make an effort to clean up your access

Access Consolidation depends on statistics based on relationships between Identity Data and Access. The closer your access is to correct within your organization the more accurate the Access Consolidation calculations will be. Perfection isn't necessary but ideally your organization will have conducted at least an access certification and removed any obviously unnecessary access prior to attempting RBAC. If you know you have vestigial access remaining in your IAM system from failed application onboarding, decommissioned applications, pieces of your organization that have been divested or the single most likely candidate: a long-neglected AD system you'll want to remove as much of it as possible.

4. Make an effort to clean up your access metadata

Your IAM team will have to review your organizations access with other members of the organization. They will need to make decisions about whether to include or not include that access in the Access Consolidation Items intended for their people. This will be a lot easier if that access includes a name that's written for a human instead of for a computer. A DN is not human legible. Access owners, security levels and indicators of additional legal scrutiny may all be appropriate for your access, Access Consolidation Item creation will need all of those, the creation process will go smoother if they are in place prior to kickoff of an Access Consolidation Project.

Everything that I have written above is optional. You don't need to do any of it and I have run successful Access Consolidation Projects with organizations that have done none of them. They all would have been finished a lot sooner though if that work was done in advance. If you're unsure if your organization is ready for an Access Consolidation Project and would like an expert’s opinion on what to do to prepare for one, reach out and we'll be happy to schedule a short, no-cost consultation to figure out what you need to do to get ready for one.

A Task For AI

Fri, 23 Jan 2026 15:34:50 GMT

AI will impact IAM, but not evenly.

Application Onboarding, A Near Term Task For AI

A couple of weeks back a colleague of mine asked me what I saw as the value of AI in IAM. The current state of generative AI is such that it can do much of the work that humans have been doing for years faster and in many cases with the level of quality of top humans in their respective fields. The full set of potential use cases for it is unbounded. What it can do now however is bounded by the amount of data available to it. For AI to do something it must first have been done well by people, and to be trained to do the work it must have been done enough to generate data to train an AI on. IAM is a developing science with a limited knowledge base where the inputs, outputs, and definitions of success are all hidden by the organizations that utilize IAM solutions. That may sound like an insurmountable barrier to AI success in solving IAM problems, but it is not. To understand why we have to go back just a little bit in time.

In the previous decade the big story in IAM and IT wasn't AI. It was the cloud. The majority of the IAM solutions being deployed today are no longer on-premises IAM solutions but on-cloud. The transition from on-prem to cloud-based IAM solutions has removed a technical barrier to utilizing client data to generate training sets for IAM configurations based on the client's data. The EULA of these tools removes any legal barrier, an example of which, from SailPoint is below:

"From time to time, SailPoint may use Customer Data or other aspects of Customer’s use of the SailPoint Offerings to generate patterns, statistics, and similar metadata that does not identify Customer or any of Customer’s Users (“Usage Data”). Usage Data is owned by SailPoint." , SailPoint IdentityCloud Customer Agreement and Terms

Saviynt similarly has a tool improvement clause:

"Customer grants Saviynt, its licensors and subcontractors a non-exclusive and limited license to host, store, transmit, display and process Customer Data as reasonably necessary for the purposes of (i) setting up, providing, monitoring and improving the Subscription Services," Saviynt Customer Responsibilities Conditions of Use

If there are any tools that don't permit their creators to use client data to improve them, I'd be surprised, please let me know .

This may seem ominous but assuming the information is only used to improve their tools in the long run this should benefit their clients by allowing trained AI tools to optimally configure client-specific IAM instances. The losers in this instance would be the people previously responsible for performing the configurations, not the organizations whose primary concern is that the configuration happens.

Any task in the IAM space that has a large dataset based on repeated inputs and outputs is up for grabs, so what's going to go first? My money is on Application Onboarding for common applications. It's worth noting that this application of AI won't be visible to end consumers, what they will see instead is the scope of out-of-the-box connectors for applications drastically expanding and automatic configurations for them becoming the norm.

Aside from access to the data which IAM providers already have, the two other things they need are large datasets and a definition of success, something to train a model towards. The former is why I qualified the type of applications that this will work for as common. Historically they would have had to be considered important enough to justify an effort to create an OOB connector, soon they will just have to exist in quantity. It's worth noting that the types of applications that will be covered by this will be limited to the user bases of the IAM systems in question, so if a toolset is currently heavily favored in manufacturing for example the future connector set will be as well.

The definition of success is a little trickier. As a consultant I've seen a lot of misconfigured application models across many clients. The industry preference for wording application onboarding contract KPIs in terms of "# of applications configured / time" forces software configuration teams to prefer speed to accuracy. There are wrong ways to configure applications in an IAM space and there is a way in which access needs to be modeled for IAM activities to occur. This problem can also be overcome, a simple way to estimate accuracy for example is "durability", if an application model hasn't changed it is likely the correct one. If a client's IAM team continues to fiddle with it, it is likely incorrect. There are probably teams of people working right now on better definitions of success in this area.

Going forward I think the model of "Accessible Data of sufficient quantity and a definition of success" will apply to more areas in the IAM space. This will eventually open up to areas beyond just application onboarding but for the near term that's what I would bet on. In terms of impact on the industry there are two changes I see this bringing, the first is: Application onboarding is going to become a niche capability. It will never disappear as new applications will continue to be created and AI can accelerate that process, potentially to breakeven or even growth although I doubt it. Armies of fresh-faced IAM consultants may no longer find themselves on large application onboarding teams.

The second impact I see is that this will reduce the cost of IAM operations resulting in increased adoption. If you no longer need multi-year million-dollar IAM contracts to move your company into a modern IAM solution you are more likely to do it. This may mean more work for IAM strategists and implementers but shorter contracts.

If your organization is considering implementing IAM or wants to make changes to their existing IAM solution such as reducing the cost, increasing the security and saving a lot of money with an Access Consolidation project, please reach out to us at Thornton Data Solutions.

Roles are social, so what?

Wed, 14 Jan 2026 21:26:19 GMT

Access Consolidation has a social component, so what?

In a previous blog post I started expounding on the topic of what makes RBAC (and all Access Consolidation) difficult. One of the most significant reasons for this is the hidden social aspect of Access Consolidation. Because tool creators want you to buy their toolsets they do not mention this work, and unless you've performed an Access Consolidation effort before you may not be aware of the social effort it takes. So what difference does it make that there's a social component to this work?

1. There is no purely technical / software solution to this problem.

There are a number of providers of Role Mining, IGA and Authorization solutions that feature their own takes on how to solve the access consolidation problem. They are all relatively easy to use in terms of how they acquire and present data and capture the decisions made about implementation. Most of them are capable of demonstrating a sample Access Consolidation Item creation in a couple of minutes. The reason this demonstration takes minutes while RBAC projects can take weeks or months is because they skip over the part where the IAM team has to build consensus on the structure and content of their roles. This part is glossed over for a pretty simple reason: it doesn't happen in their tool, it happens in person, it's a conversation with your colleagues.

2. You will have to have technical IAM discussions with people who are not IAM professionals.

Roles change the behavior of access request and certification. Done properly, people who are used to requesting a dozen things for each of their new employees will only have to request one or two. They are still responsible for the access of their employees however, and they're going to need to provide their consent on both the creation of the role and its contents. This means they need to be sold on the benefits of the solution as well as the technical details of the analysis that suggests what the contents should be. While this information will make sense to your IAM Team, remember that the colleagues you're working with will at times be from very different disciplines within your organization. Your finance team, manufacturing team and customer service representatives for example all have very different perspectives on the business.

If your team is not used to communicating with people who are outside of the cybersecurity / application owner space you may want to consider developing developing or acquiring that capability. The ability to put a value proposition for a role into words that a doctor or a banker can understand will make it a lot easier when you go to review its contents with them. Familiarizing yourself with your access customers concerns will make this process much smoother.

Some things to keep in mind during these conversations:

- The access names that your IAM team uses may not be the ones that your colleagues are familiar with. If your IAM team does not have human legible names for access in your upstream systems you may want to generate those prior to embarking on an Access Consolidation Program. Managers in your HR department for example might not know the DN of the group they're all in that grants them access to their fileshare. Other additional access metadata that may need to be cleaned up include: access descriptions, security levels or owners.

- If you have had particularly contentious conversations with organizational leadership as a result of previous access certifications or access request issues you should consider how best to broach the subject of creating an Access Consolidation Item for them. If they're unhappy with the amount of effort it takes to meet their compliance requirements and/or request access for their people then lead with the reduction in effort. If they're defensive about how previous access certifications have turned out consider working with their trusted peers first in order to generate a success story that can be shared with them.

3. Your piece of the organization is about to become a lot more visible.

An Access Consolidation program is when the IAM Team transforms from a background piece of the Cybersecurity team into a trusted partner that returns value to the organization. While the reduction in risk that a well run Identity Provider provides is certainly important, an Access Consolidation program allows the IAM team to provide something even more tangible: an improvement to a company's bottom line. To do this the IAM team will have to engage with the rest of the organization. This is when your IAM team goes from being a background maintainer of a niche cybersecurity tool to a trusted partner that enhances your business.

If you're considering undertaking any kind of Access Consolidation project including starting an RBAC Program and want to make sure that you return as much value to your organization as possible please reach out to us at john@thorntondatasolutions.com and we'll schedule a complimentary strategy session to get you started on the right foot!

The Dual Nature of a Role

Fri, 26 Dec 2025 19:37:35 GMT

Similar to a butterfly/caterpillar a Role is one thing, with two very different faces.

Why are roles so difficult?

Recently two former colleagues in the IAM Space asked me separately "Why are roles so difficult?". It's a common enough question that I'm surprised that I haven't seen anyone answer. There are multiple reasons and I will address as many of them as I can in upcoming blog posts but I’m going to start by addressing the primary reason why IAM Professionals underestimate the difficulty of an RBAC project: They view it as a software configuration or mathematical exercise.

If you're an IAM practitioner you've likely seen or heard of roles before and the explanation of what they are is simple. They're bundles of access that are granted to individuals when certain criteria are met. This same definition can be applied to any form of Access Consolidation, RBAC, ABAC, FGA others etc... are all combinations of access and criteria that differ only in their numbers and where in the Enterprise software stack they're implemented. You may have even taken a course on how to create roles within your IAM toolset. The technical implementation of a role is deceptively simple, select access, select criteria, publish to test, prove it works and then move it into production.

If the creation of a role is simple, then the creation of roles, the implementation of an RBAC program should be simple also, but If you're reading this you probably already know otherwise. If you're new to this then know that the failure states of RBAC programs are both numerous and likely. A Role is simple, an RBAC program is not, and the single greatest reason why RBAC programs fail is due to a failure to understand that the complexity of creating a role that adds value to an organization is not the same thing as the complexity of creating a role in an IAM tool. One is a software configuration the other is an intra-party agreement between multiple parties within different parts of a business who may have dramatically different objectives, professional viewpoints and professional languages. In terms of understanding the difference between creating a role and a role program a useful analogy is to consider role creation as akin to hammering a nail, whereas an RBAC program is a construction project. You need to learn the former to do the latter, but the latter is so much more.

The simple nature of the role creation interface in most IAM systems hides the complexity required in achieving this consensus and the limited training readily available to cover its usage also hides the complexity behind an RBAC effort. To understand this complexity, you have to realize that an implemented role changes the way in which end-users request, approve and certify access. It changes the professional duties of others in a way that they will have to agree to. That agreement needs to be achieved for every role that is created. A successful RBAC program is not merely a software configuration project, it is also a consensus manufacturing project designed to convince all parties involved to agree to a change that will save their organizations a lot of time and money. Software configurations and consensus building are very different domains and for your RBAC Program to succeed it needs to account for this. You will need to meet with the stakeholders responsible for end users access and ask them to accept your proposed changes to how access is managed, it is worth it but it is also a very different task from what IAM professionals may be used to, especially if they came to their current professions through software development or configuration tracks.

This is what we do at Thornton Data Services. We assist with the creation of your consensus building factory, which includes the software configuration outputs it creates, but it's a lot more than that, there's project socialization, end-user training, review artifacts and review meetings all required to ensure the Role adds value to the organization without adding risk. If you'd like to find out how an RBAC Implementation can help your organization save a lot of time and money, please reach out to me at john@thorntondataservices.com and we'll schedule a free hour consultation to find out if access consolidation is right for your organization.

What are the goals of an Access Consolidation Program?

Mon, 03 Nov 2025 20:49:38 GMT

Without goals your program cannot succeed.

How do you measure success in Access Consolidation?

There are many stated motivations for starting an Access Consolidation Project (sometimes referred to as an RBAC, ABAC, or FGA program, see our previous blog post titled "What is an Access Consolidation Program?" for more details) ranging from a desire to reduce the number of access requests, certification items, certification rubber stamping or simply meeting a higher level of maturity in an IAM implementation. Regardless of those stated objectives they're all achieved by crafting Access Consolidation Items that balance a number of sometimes contradictory objectives.

The value of any set of Access Consolidation items is generated by the amount of access it covers. Each piece of access covered is an item that doesn't need to be manually requested or certified on an identity-by-identity basis. To maximize the value of an Access Consolidation Program the items it produces should cover as many people as possible and as much of their access as possible.

Access Consolidation Items have maintenance costs. They need to be reviewed regularly and updated to align with changes to the access needs of the populations they serve and the toolsets that they use. This imposes a cost on the organizations that implement them that will endure as long as they're maintained. In order to make sure that the organization doesn't bear an unnecessary cost the coverage should be implemented in as few Access Consolidation items as possible. This may require an organization to make tradeoffs in terms of coverage, if a single role can cover 99% of the access that ten roles can cover, it's probably worth only building the single role.

The other cost of an Access Consolidation Program is the time it takes to implement it. The faster that Access Control Items can be created the less the effort will ultimately cost. We'll do a deeper dive into preparations that can be undertaken in advance of an Access Consolidation Program in a future post but broadly speaking the best ways to accomplish this are to align stakeholders within the organization on the need for an Access Consolidation Project, improve the data quality of the access items, specifically names and descriptions and finally reduce noise in the set of access data by conducting user access reviews prior to the start of an Access Consolidation Program.

The final objective that must be balanced with the above is that the Access Consolidation Program cannot undermine existing security and governance objectives. Access that was reviewed before on individual identities will still need to be reviewed as the composition of a role, FGA or ABAC assignment rule, whichever form that Access Consolidation Items take. The creation of the Access Consolidation Items will likewise need to be reviewed and approved by the same stakeholders that provide oversight of individuals access request and certifications.

Balancing these at times opposed objectives in order to achieve optimal outcomes requires a skillset and toolset that comes from the experience of leading multiple Access Consolidation Program. At Thornton Data Solutions we've lead over 25 (and counting) Access Consolidation Projects across industry verticals such as Banking, Healthcare, Insurance, Retail and Industrial. If your organization is ready to take the next step and reduce the costs of its IAM operations reach out to us to schedule a no cost initial consultation to figure out if an Access Consolidation Program is right for you.

What is Access Consolidation?

Thu, 25 Sep 2025 19:38:14 GMT

A Project For Reducing your IAM Costs

Is it time to reduce the cost and complexity of your IAM program?

If your organization is struggling with rubber-stamped access certifications, excessive manual access requests or error-prone onboarding, it may be time to consider an Access Consolidation project.

An Access Consolidation project is exactly what it sounds like, an effort to reduce the complexity of assigning and certifying access within an organization. If you're reading this, I'm assuming you're an IAM professional so you may already be aware of some of the various methods to achieve these results: RBAC (Role Based Access Control), ABAC (Attribute Based Access Control) and FGA (Fine Grained Authorization) are all means of achieving these results. While each of these approaches to access consolidation have their own enabling tools, skillsets and champions, the truth is that they all co-exist because they are all appropriate ways to deal with different relationships between an organization’s identities, access, authorization methods and business requirements.

All organizations are unique, no two have the exact same growth story with regards to people, their access or the way in which it has been assigned. An Access Consolidation program must start with examining the current state of the organization in question and determine which method(s) of Access Consolidation are appropriate. For example, a healthcare provider that segregates user health information by the relationship of its medical professionals to its patients has a very different access organization than an insurer that requires teams of account representatives to be able to access similarly sensitive information. The former benefits far more from an FGA solution for its Electronic Medical Record (EMR) system while the latter would likely benefit more from an RBAC approach. The differences in access requirements across different industry verticals are even more pronounced: a bank isn't organized like a factory, which isn't organized like a retail establishment etc... Each of these requires a different approach to mapping Access Consolidation strategies to their IAM environment.

Mis-applying an access consolidation strategy to an area which it doesn't fit will result in wasted time, effort and money. Attempting to map roles onto the many relationships of a healthcare provider will result in an explosion in the number of roles generated while attempting to use FGA to assign access for bank tellers will require the implementation of an expensive FGA solution that was entirely unnecessary. Expertise in a skillset means knowing how to most effectively use it to solve problems but it also means knowing when it is in the wrong skillset to apply. At Thornton Data Solutions we pride ourselves on our deep understanding of Role Based Access Control, including when not to use it and what the appropriate Access Consolidation solutions are for those areas that it doesn't apply to.

Thornton Data Solutions specializes in helping organizations streamline their Identity and Access Management (IAM) operations. If your organization is experiencing one or more of the following symptoms: Access Certification Rubber Stamping, Incomplete Access Certifications, Excessive Manual Access Requests, Incorrectly Requested Access and Lengthy / Error Prone User-Onboarding experiences then you will benefit from an Access Consolidation Project.

If you’d like to reduce the cost of your IAM Operations please reach out to us and we’ll be happy to schedule a free consultation to help figure out how you can get started on the path towards reducing your IAM Costs and improving your user experience.

In our next Blog post we'll go deeper into the strengths of each of these approaches to Access Consolidation and discuss where they should be used within your organization.