Analyst Chat
Analyst Chat #49: There is More to IAM Processes than JML
When asked to describe IAM processes, managers tend to think first of traditional lifecycle management processes such as Joiner, Mover and Leaver (JML). While these are clearly essential for identity governance in interplay with authoritative sources, a comprehensive process framework for IAM and beyond encompasses many other areas. Martin Kuppinger and Matthias Reinwarth explore some of these additional areas between convenience and compliance.
Welcome to the KuppingerCole analyst chat. I'm your host. My name is Matthias Reinwarth, I'm an analyst and advisor at KuppingerCole analysts. And my guest today is Martin Kuppinger. He's the founder of KuppingerCole and principal analyst. And today we want to talk about IAM identity and access management processes and why there's more than joiner mover leaver. I Martin. Great to have you again. And as I've mentioned already, um, there's more than joiner mover leavers. So identity and access management processes, I assume are one key of being successful. When doing IAM,
I would even say processes are important for virtually everything you do within it. So success very, very frequently is based on defining processes. And if you don't have these processes, the risk of failing of also investing far, far, too much into customization, because you then do it more in a trial and error effort is far too high. So processes are key to success. Yes.
Okay. When I talk about identity and access management processes, I usually start with a statement that independent of the industry independent of what an actual organization is really doing identity and access management process in general are not that different if you'll go from one industry to the other. So there will be always joiner movers and leave us in, in general. But what makes these processes more complex? What are the aspects that real life organizations should look like? Should they cover their individualities? There, there are specifics friends, it comes to defining the IAM processes.
So let's first look at the standard process and then maybe at which types of processes do we need. So yes, there's trying to desk mover there modern one lever because that's usually the standard and at least the emergency leaf and these processes, and many other of the process we will talk about today are not the difference between different industries, between different organizations, as you already mentioned, people try and during a session, people change that drops, et cetera. That is one part of it. And we can work from my perspective very well as a set of standard processes as we had KuppingerCole after fine, by the way, which then can be adapted to the specifics of an organization and where you also can work with a set of standard processes within this process, having some flexibility, for instance, for various entities of your organization and different geographies, et cetera.
So you might give them some flexibility, but at the high level, these processes are pretty much equal and they are a good starting point coming through the second aspect. I think when we look at China mover leaver, you should understand that this is only about one part of the broad identity and access management, which is the IGA identity governance administration part or life cycle management. And if you look at trying to move the lever only to very little accent, maybe access governance. So it's only a portion because you also have access management, access management is Federation. We have privileged access management and where we are more mature in our implementation. We might have couple of other areas for seeing that identity and access management, all of them need processes. So there are two things within that. One is it's not only about ITA proposals, so they're trying to move live size, but even within that area. And I said, you can provide a lot of insight on that even within the area of IGA. It's more because trying to move a, leaver's only a small portion. It doesn't cover things like application onboarding, access, governance processes, and many other areas.
Yeah, I think that is also an, a very important aspect that is usually forgotten application onboarding. That is really, there should be a standard or a set of standards, processes for onboarding the different categories, different types of applications, to make sure that these are quickly onboarded, ideally in a, in a self-service fashion so that the entitlements and the requirements for an application are well understood and quickly onboarded. So that access management access provisioning can happen very quickly. Maybe one other question. Um, you usually, when you talk about joining a mover leavers to get back to that point for at least four, for a second, again, that heavily relies on well-defined upstream processes, which are maintained in an HR system, which are maybe maintained in a system that handles external users or freelances, et cetera. Many organizations are not mature in that area. And identity and access management has to work around that and find processes that heal actually HR deficiencies. What would you recommend to organizations that have not one central HR, but say 50 and have more than one system maintaining external users that could easily ruin IAM processes.
So you're referring to that a very common situation where you say, okay, what about HR? And to say, oh, we on our way to sort of consolidating and unify buying our HR. But unfortunately currently we still have 87 different HR systems, meaning you need to deal with a lot of systems and then you detach it. Partners, externals is even more complex. Um, so anyway, the first thing would be the first recommendation would be to start talking this HR and the other entities frequently. The challenge arises more from the fact that HR and I am trusting and talk much with each other. And this is where no one knows who's responsible for which type of data, et cetera. So if you are in a scenario where you need to deal as a lot of different sources and different levels of identity information quality, then it means you need roses, help you consolidating and processes that help you improve the quality of that information by maybe reaching out again, back to people who are responsible for that information, et cetera, that might be something you build in identity and access management, even while it would be better to have the unit such as HR, um, solving that challenge.
Um, there's a lot of technology where you can do that, but that would sort of lead a discussion beyond the process topic we have. Now,
We usually recommend as a first golden recommendation to say, IAM should not solve problems, which are not IAM problems. So really focus on what I am is actually four, but there usually have to be compromises made to make sure that the overall process framework, including all partners, upstream, downstream systems are properly maintained and included in an overall process framework. But as you said, complex processes usually do not arise from these organizational challenges within HR, within other up and downstream systems. But it's really about making sure that the overall framework works well. So we've talked about application onboarding. We talked about the joiner mover leavers. What are other processes that should be considered when we talk about, um, I am processing.
So, um, first was the NYCHA. You need processes to manage your, um, title nine models. So if you've worked with rows to create roles, to modify roles, to retire roles, if you use other types of artifacts then for these artifacts, so you need this sort of speed model maintenance processes, you should always also work with a set of standard processes. So approvals at maximum, you have a single step and a multi-step approval, but that Mercer don't have an approval process defined for every single individual process of Toronto for mover, for whatever else, call out to standard process for approvals for escalation, for many other aspects, you need all these X governance process around access reviews, around reporting, et cetera. These processes need to be defined as, so you will then add up with some way bigger framework for processes and then the RDX access management process.
So who defines the policies for, for access management who defines how federations handled again, application onboarding application onboarding is the one thing which is sort of unifying the processes for ITA, for access management, for privileged access management, but talking about privileged access management or Pam there also, you have a lot of processes. So for instance, session monitoring, session recording, who reviews session recordings in which will be when again, approval process and many other things. And some of them will be quite similar than process, not an area, some are very specific. So it's really important to take a broader perspective on that and to have the process in place. And that also leads them to, you also need them to policies, which are in fact, the foundation for the processes and the processes are the foundation for efficiently rolling out and operating your technologies.
Yeah, I would fully agree. And I think all processes that are well managed and can be automated are of course, processes that can be executed very quickly. Processes take long when people are involved. And you've mentioned that very briefly. And I think that is an aspect many organizations should have look at, and that is delegation that is as collation. If it process usually takes longer when somebody is just not doing his or her work, because she's not there she's ill, she's not available, she's on vacation, she's on leave. And that has not been well managed. So if somebody is an approver, that should be a mechanism that makes sure that this task can be delegated for some time for being absent. But also if it's not planned, that should be something like a, a quick, and well-defined escalation process building on organizational hierarchies to make sure that there is a line manager that can take over that role if it's required. So really thinking about who can take over this task as a deputy, as a stand in, I think that is something that is, can be defined very centrally once for all, and then can be used in many of these processes that involve user interaction.
Three things on that first is if you define the processes, you will also have to discussion about what is the right way for the allegation. So you define, uh, what can be delegated, whatnot. All these things are then if you do it right, they are discussed and they are defined afterwards. The second point you brought up very briefly at the beginning of what you said is automation. So yes, we need to care for things that can't be automated, but you also should try to automate as much as we can, because if we automate, for instance, the assignment of entitlements, you as can simplify the access reviews, because what is assigned based on an automated policy, doesn't need to be reviewed manually only the policy. And it needs to send a review, which also means you need to have processes for defining, for approving, for changing, for retiring policies, again, a set of frozen, but if you do it right, you will end up as a well-structured set of processes, whichever usually a long lifetime.
So a process should stand for instance, a change in the tools you are using because process should be in, must be very stable. And the certain as you've mentioned was about a manual work. And that is another area for us is we need, we need a well defined integration into it, service management for all the manual fulfillment tasks, which we will have in our, I am infrastructure, but there are some similar I would from my experience, say, logically comes out when you start defining processes because you then see, okay, that is missing. I need to let as well. And, and if you do that, maybe with some proper guidance or building on a, on a set of established standard processes, then you will be far more efficient in both the rollout and implementation and the operations of your entire identity and access management. It will save you a lot of money,
Right? And usually I ask what is available at KuppingerCole this time. I can answer that question, myself being lead advisor here at KuppingerCole. We have executed a lot of projects already when it comes to assessing and looking at existing IBM systems are planning for upcoming new versions of IBM systems. So we have quite some experience in assessing existing process frameworks and being the guy who is we commending help and guidelines for defining a new process framework. So if somebody of the audience is interested in just having a first talk about their process framework, having an assessment of their existing processes, or just in learning more about this might be improved. Um, we will be happy to get in touch for a first informal call, um, to talk about your existing process framework for upcoming challenges in all these new changing hybrid architecture that we are looking at right now. So we would be happy to get in touch with those who are really facing challenges here. And, um, of course, there's also lots of research about that. Anything to add from your side margin?
No, I think you've said everything well, so thank you for this talk.
Thank you very much. And, uh, looking forward to, uh, another episode with you Martin, and looking forward to getting in touch with everybody. Who's interested in learning more about improving I am processes. Thank you very much margin and bye-bye. Bye.
I would even say processes are important for virtually everything you do within it. So success very, very frequently is based on defining processes. And if you don't have these processes, the risk of failing of also investing far, far, too much into customization, because you then do it more in a trial and error effort is far too high. So processes are key to success. Yes.
Okay. When I talk about identity and access management processes, I usually start with a statement that independent of the industry independent of what an actual organization is really doing identity and access management process in general are not that different if you'll go from one industry to the other. So there will be always joiner movers and leave us in, in general. But what makes these processes more complex? What are the aspects that real life organizations should look like? Should they cover their individualities? There, there are specifics friends, it comes to defining the IAM processes.
So let's first look at the standard process and then maybe at which types of processes do we need. So yes, there's trying to desk mover there modern one lever because that's usually the standard and at least the emergency leaf and these processes, and many other of the process we will talk about today are not the difference between different industries, between different organizations, as you already mentioned, people try and during a session, people change that drops, et cetera. That is one part of it. And we can work from my perspective very well as a set of standard processes as we had KuppingerCole after fine, by the way, which then can be adapted to the specifics of an organization and where you also can work with a set of standard processes within this process, having some flexibility, for instance, for various entities of your organization and different geographies, et cetera.
So you might give them some flexibility, but at the high level, these processes are pretty much equal and they are a good starting point coming through the second aspect. I think when we look at China mover leaver, you should understand that this is only about one part of the broad identity and access management, which is the IGA identity governance administration part or life cycle management. And if you look at trying to move the lever only to very little accent, maybe access governance. So it's only a portion because you also have access management, access management is Federation. We have privileged access management and where we are more mature in our implementation. We might have couple of other areas for seeing that identity and access management, all of them need processes. So there are two things within that. One is it's not only about ITA proposals, so they're trying to move live size, but even within that area. And I said, you can provide a lot of insight on that even within the area of IGA. It's more because trying to move a, leaver's only a small portion. It doesn't cover things like application onboarding, access, governance processes, and many other areas.
Yeah, I think that is also an, a very important aspect that is usually forgotten application onboarding. That is really, there should be a standard or a set of standards, processes for onboarding the different categories, different types of applications, to make sure that these are quickly onboarded, ideally in a, in a self-service fashion so that the entitlements and the requirements for an application are well understood and quickly onboarded. So that access management access provisioning can happen very quickly. Maybe one other question. Um, you usually, when you talk about joining a mover leavers to get back to that point for at least four, for a second, again, that heavily relies on well-defined upstream processes, which are maintained in an HR system, which are maybe maintained in a system that handles external users or freelances, et cetera. Many organizations are not mature in that area. And identity and access management has to work around that and find processes that heal actually HR deficiencies. What would you recommend to organizations that have not one central HR, but say 50 and have more than one system maintaining external users that could easily ruin IAM processes.
So you're referring to that a very common situation where you say, okay, what about HR? And to say, oh, we on our way to sort of consolidating and unify buying our HR. But unfortunately currently we still have 87 different HR systems, meaning you need to deal with a lot of systems and then you detach it. Partners, externals is even more complex. Um, so anyway, the first thing would be the first recommendation would be to start talking this HR and the other entities frequently. The challenge arises more from the fact that HR and I am trusting and talk much with each other. And this is where no one knows who's responsible for which type of data, et cetera. So if you are in a scenario where you need to deal as a lot of different sources and different levels of identity information quality, then it means you need roses, help you consolidating and processes that help you improve the quality of that information by maybe reaching out again, back to people who are responsible for that information, et cetera, that might be something you build in identity and access management, even while it would be better to have the unit such as HR, um, solving that challenge.
Um, there's a lot of technology where you can do that, but that would sort of lead a discussion beyond the process topic we have. Now,
We usually recommend as a first golden recommendation to say, IAM should not solve problems, which are not IAM problems. So really focus on what I am is actually four, but there usually have to be compromises made to make sure that the overall process framework, including all partners, upstream, downstream systems are properly maintained and included in an overall process framework. But as you said, complex processes usually do not arise from these organizational challenges within HR, within other up and downstream systems. But it's really about making sure that the overall framework works well. So we've talked about application onboarding. We talked about the joiner mover leavers. What are other processes that should be considered when we talk about, um, I am processing.
So, um, first was the NYCHA. You need processes to manage your, um, title nine models. So if you've worked with rows to create roles, to modify roles, to retire roles, if you use other types of artifacts then for these artifacts, so you need this sort of speed model maintenance processes, you should always also work with a set of standard processes. So approvals at maximum, you have a single step and a multi-step approval, but that Mercer don't have an approval process defined for every single individual process of Toronto for mover, for whatever else, call out to standard process for approvals for escalation, for many other aspects, you need all these X governance process around access reviews, around reporting, et cetera. These processes need to be defined as, so you will then add up with some way bigger framework for processes and then the RDX access management process.
So who defines the policies for, for access management who defines how federations handled again, application onboarding application onboarding is the one thing which is sort of unifying the processes for ITA, for access management, for privileged access management, but talking about privileged access management or Pam there also, you have a lot of processes. So for instance, session monitoring, session recording, who reviews session recordings in which will be when again, approval process and many other things. And some of them will be quite similar than process, not an area, some are very specific. So it's really important to take a broader perspective on that and to have the process in place. And that also leads them to, you also need them to policies, which are in fact, the foundation for the processes and the processes are the foundation for efficiently rolling out and operating your technologies.
Yeah, I would fully agree. And I think all processes that are well managed and can be automated are of course, processes that can be executed very quickly. Processes take long when people are involved. And you've mentioned that very briefly. And I think that is an aspect many organizations should have look at, and that is delegation that is as collation. If it process usually takes longer when somebody is just not doing his or her work, because she's not there she's ill, she's not available, she's on vacation, she's on leave. And that has not been well managed. So if somebody is an approver, that should be a mechanism that makes sure that this task can be delegated for some time for being absent. But also if it's not planned, that should be something like a, a quick, and well-defined escalation process building on organizational hierarchies to make sure that there is a line manager that can take over that role if it's required. So really thinking about who can take over this task as a deputy, as a stand in, I think that is something that is, can be defined very centrally once for all, and then can be used in many of these processes that involve user interaction.
Three things on that first is if you define the processes, you will also have to discussion about what is the right way for the allegation. So you define, uh, what can be delegated, whatnot. All these things are then if you do it right, they are discussed and they are defined afterwards. The second point you brought up very briefly at the beginning of what you said is automation. So yes, we need to care for things that can't be automated, but you also should try to automate as much as we can, because if we automate, for instance, the assignment of entitlements, you as can simplify the access reviews, because what is assigned based on an automated policy, doesn't need to be reviewed manually only the policy. And it needs to send a review, which also means you need to have processes for defining, for approving, for changing, for retiring policies, again, a set of frozen, but if you do it right, you will end up as a well-structured set of processes, whichever usually a long lifetime.
So a process should stand for instance, a change in the tools you are using because process should be in, must be very stable. And the certain as you've mentioned was about a manual work. And that is another area for us is we need, we need a well defined integration into it, service management for all the manual fulfillment tasks, which we will have in our, I am infrastructure, but there are some similar I would from my experience, say, logically comes out when you start defining processes because you then see, okay, that is missing. I need to let as well. And, and if you do that, maybe with some proper guidance or building on a, on a set of established standard processes, then you will be far more efficient in both the rollout and implementation and the operations of your entire identity and access management. It will save you a lot of money,
Right? And usually I ask what is available at KuppingerCole this time. I can answer that question, myself being lead advisor here at KuppingerCole. We have executed a lot of projects already when it comes to assessing and looking at existing IBM systems are planning for upcoming new versions of IBM systems. So we have quite some experience in assessing existing process frameworks and being the guy who is we commending help and guidelines for defining a new process framework. So if somebody of the audience is interested in just having a first talk about their process framework, having an assessment of their existing processes, or just in learning more about this might be improved. Um, we will be happy to get in touch for a first informal call, um, to talk about your existing process framework for upcoming challenges in all these new changing hybrid architecture that we are looking at right now. So we would be happy to get in touch with those who are really facing challenges here. And, um, of course, there's also lots of research about that. Anything to add from your side margin?
No, I think you've said everything well, so thank you for this talk.
Thank you very much. And, uh, looking forward to, uh, another episode with you Martin, and looking forward to getting in touch with everybody. Who's interested in learning more about improving I am processes. Thank you very much margin and bye-bye. Bye
Video Links
Stay Connected
How can we help you