Harness IGA and GRC Synergies for Effective ID Management and Access Control

Welcome. I'm Martin Kuppinger. I'm Principal Analyst at KuppingerCole Analysts and I'm your host today for our webinar, Harness IGA and GRC Synergies for Active Identity Management and Access Control. This webinar is supported by Fastpass and the speakers today will be Matt Berdine, who is Senior Director, Product and Solutions, Fastpass, Mike Cassady, Chief Product Officer at Fastpass, me, Martin Kuppinger, and I'm Principal Analyst at KuppingerCole Analysts. Before we dive into the agenda of today's webinars and the content, a little bit of housekeeping first.

We are controlling audio, so you don't need to control the audio features when we're doing this. We will run two calls during the webinar and if time allows, we will discuss the results during Q&A and that already means we will have a Q&A session. For today's webinar, it will be maybe a bit mixed in the sense of that we may pick your questions during a longer sort of conversational part of the webinar, so you can enter questions at any time. The more questions we have, the better it is.

There's on the right-hand side of the app, there's an there's an area for entering your questions and we are recording the webinar, so we will provide recording and slide decks, that slide deck in that case, relatively shortly after the webinar. So, what I want to do first before we go into the content of the webinar is raising a first poll, a question to you, and I hope that a lot of you will respond. The question is, who in your organization is responsible for application access control for line of business applications?

So, for all that stuff, who can do what within your ERP and all the other types of line of business applications you have? So, are these different departments depending on the application? Is it the SAP department? Is it the IAM department? Or are it others?

So, looking forward to your responses. We leave this open for some 30 seconds or so.

Okay, thank you. That brings me back to the webinar and as I've mentioned, we have a bit of different structure than we have many of our other webinars.

So, what we will do is that I give a quick intro, a bit of talk about the intersection I see between IHA and application access control, or IHA and GRC, however you want to phrase it terminology-wise. In the second part, then Mike and Matt from Fastass and me, we will have a discussion about the synergies that can be leveraged by integrating IHA and GRC.

So, we will look at what can be the benefits of really bringing these two domains together for various types of organizations, but also with a bit of an emphasis on the medium-sized market world. And then, we do the Q&A as I've said. It may be that we merge up into sections two and three. The more questions come during the conversation, we'll try to pick them up soon and immediately so that we can cover them.

What I see as an analyst, so I'm observing this market for quite a while, and what I see as a very important point in this entire market is that the world of line of business applications is really changing. So, this change basically goes into a couple of directions. The one is that we are increasingly going away from traditional on-premises solutions towards sort of real cloud services. Not only lift and shift, but also more and more real modern architect solutions, which is a bit of a mixed trend.

So, it's a journey for these different types of applications, which are for your finance, for your sales, for your production, for different parts. So, all these different types of line of business applications. The other thing is that, and that is I think to some extent related, that we also see a more heterogeneity in the number of vendors.

So, from very monolithic approaches, we see more uptake of, or we pick a specialized solution for this use case, we pick one for that, etc. So, more vendors coming in.

So, while we still see that many organizations say, okay, there's at the core, there's SAP or Oracle or whoever else. I don't want to leave anyone out, but just pick some of the very big ones. There is usually some more around that.

So, it's more a few vendor hybrid state currently on average, with surely some organizations being more on the multi or single vendor side, some more on the on-prem or pure SaaS side. But it's a shift from the sort of the traditional way we look at line of business applications.

So, this is one of the important things. What we then need, not only because we have more line of business applications, but also because we have not only a line of business application, we also have IGA, we need to think about the breadth. And the point is, these two technologies aren't the same yet, at least not until they're fully converged. And some vendors like FastPass are in this convergence.

So, we have the IGA part, which is really supporting wide range of applications beyond the line of business applications. There's the Azure Active Directory, there's Active Directory. There are a lot of other things in there. While application access control goes more into specific things, deep into SAP, providing rule books, etc. And then there are things that are in common, provisioning user lifecycle, access review, certain level of SAP control.

So, there's a significant overlap, probably bigger than this is when the diagram I have created here indicates. So, at the end, we need to understand we have a breadth of the depth challenge and we need to cover both. And I think when we go a bit more into details, I don't want to read out this entire metrics. As I've said, we will provide the slide, I guess, for download. But I think it becomes very clear, there are things where both are strong. There are areas where one of the two technologies access. There are areas where both are okay, but overlapping.

And so, there's a launching and saying, we look at both types of capabilities. I believe, and this will be part of our conversation later on, that there's a significant potential also that going closer here, bringing these things together. And there are many reasons for that.

There's a, as I've said, the overlap. So, let me look at it more from a technology perspective. When you are in a super big organization, that also it's a matter of who can care for what.

And so, how do you sort of use the people you have in an optimal manner, that work together, joining forces can be a very good approach here. Another point is also that, I think, historically, I know it is a fact, a matter of fact, that historically, emphasis has been mainly on financial data when it comes to segregation of duty controls, when it comes to compliance, when it comes to audit. And this is really changing. But we have way more technology risk aspects, et cetera, which go down more into the non-LOB world beyond what we did in the LOB world.

So, we need to understand, bring our sort of our audit and compliance efforts also together. I think this is also a very important aspect within this convergence.

So, with all these overlaps, there's a lot to bring things together. And when I put together just some aspects that I don't claim just to be a comprehensive and complete list, but there are a couple of things a modern GFP approach requires. And I think one of the things is it needs to take a business perspective.

So, we not only need to look at technical artifacts, we need to translate this. So, an SAP transaction code must be translated. And we need a modern UI for every user.

So, not only looking at a text every once. And the more systems we look at and we have to look at, the more we need this. Something people can work easily. Map business and technology, vice versa. Automate whatever you can. And I think this is a very important aspect we must keep in mind. Automation is key to success as always. We need then also, but aside of this high-level perspective and the business-centric view, we need to be able to drill into the details. We need a broad system support beyond what we traditionally looked at.

I believe we really should take a very comprehensive perspective here. Modern operating models. And finally, you really think about also how does this GRC thing relate with IAMS, IGA, the Identity Governance Administration specifically. This ITS MR enterprise service management with business process management with cybersecurity. There's a lot to integrate with. And I believe a very important starting point, a very good starting point, is really looking at how IGA and GRC integrate and which synergies this can deliver. As I've said, this will be really the talking point.

So, we need brass integration. So, we connect to, we need to analyze in depth the stuff, but we also need to deliver this in an effective and efficient manner with a good degree of automation and integration. And integration really helps us also very much ideally in effectiveness and in efficiency.

So, with that, another quick poll. And that is really about application access control versus IAM or GRC versus IGA, however you'd like to phrase it. Is there a common ownership or are these areas still split?

Again, looking for your responses. And so, please provide your answer here. Great. Thank you.

With that, we'll come to our next part of the webinar, which is really our conversation with Matt and Mike. Matt and Mike, welcome.

Thanks, Martin. Hi, thanks for having us.

So, maybe the two of you introduce yourself quickly and maybe give a very quick first impression about FastPass. So, Mike, you want to start? Sure. I'm Mike Cassidy. I'm the chief product officer at FastPass. I've been with the company for 16 years. Traditionally, we started out in the access control space. And over time, we started getting into more of the governance and IGA space and identity management.

And so, now we offer products across IGA access control spectrum, and it covers a lot of areas that we're going to go through today. And Matt? Excuse me.

Hi, I'm Matt Berdeen. I've had a long career in the IGA space.

So, my background is with consulting, doing IGA implementations for a few different vendors, and finally came on with FastPass to flush out the IGA capabilities within FastPass. So, it's been exciting to see the kind of the convergence of IGA and GRC here at FastPass, and excited to talk about that and share that today.

Okay, great. I think when we look at this, I got touches conversions and potential synergies between IGA and GRC quickly in my talk. But when we look at this, I think in many organizations, as we know, IGA and GRC still operate in different silos. And sometimes, there are multiple GRC silos, even so that things, even so to speak, become more complex here.

So, what do you see as the sort of the challenge first that comes from such a siloed approach? Yeah, I think the challenge we see there a lot, you know, as you mentioned, a lot of times, it's owned by the line, the access control side zone by the line of business owner, or it's owned by finance, maybe audit. And that's really separate from the IGA side, which is oftentimes owned by the IT department.

So, and really, when you get into those line of business applications, sometimes it's different processes per line of business application. So, you have no consistency across that. It becomes really difficult to understand the identity and the risk across the enterprise, because we're looking in very small windows in these different areas.

So, the convergence of identity and access control and bringing that together really gives us a better picture of that identity and their risk across the entire organization. And it starts breaking down those silos, right?

So, now we have, maybe the rule book is managed by audit or finance, but the provisioning process is managed by IT, but now that's all integrated. So, everybody's talking together, and it really facilitates automation across that and a better understanding of the risk across the organization.

So, why do we need this better risk understanding? Or how is it broken frequently today?

Yeah, I think if you look in today's world with all the cybersecurity risk and the risk from external and internal factors, it becomes even more important that we secure our identities. And so, if we have people coming into our organization or moving throughout the organization, it's important that we really restrict the access they have.

Obviously, that's the point of IGA, is that we automate that, and we also restrict their access. But when those things are separate, and maybe your provisioning in certain areas is not covered, or your risk isn't covered by the IGA system, it really breaks that down.

And so, we start losing that automation, we start losing the ability to make sure we follow that principle of least privilege. And I think to add on to that, in the siloed approach, each of those silos has a very narrow view of what's going on in the world. They care about their line of business, their applications, and that's where they're looking for risk. And more and more, we're seeing risk show up across applications that you have access in one area, plus access in a completely different silo would generate a risk where each of those independent silos wouldn't see that risk at all.

They'd only see their piece of that application, their piece of the pie. So, by bringing all that together, and looking across those applications, we can start to surface risks that you wouldn't see before. Yeah. And I think that the point is also that Mike, you brought up the process perspective as well, the integration perspective. The point is surely, I think, very clear to everyone, when processes are broken, when they don't work well, then we end up with risks.

And I think the very simple point here is, when we look at it from an IGA perspective, if we are not good in mover and lever processes, and ensuring that entitlements are revoked, that whatever line of business applications learn about someone has left, someone has changed the job. If this process is broken, then inevitably, the risk goes up, because then we are in a state of over-entitlement, per se.

Yeah, that's very true. In my consulting career, I was always shocked to see how many companies actually continue to grow that access. If somebody's been with the organization for 10 or 20 years, they just accumulate more access as they move across different jobs.

And then, to make matters worse, if they don't have their joiner processes well-defined, they will copy that access for a new joiner and say, well, he's going in to do Bob's job, and Bob has this access, so that must be what he needs. So they'll just grant that access, and it just exacerbates that problem and continues to grow.

So yeah, that's very true. Is this entire thing, then, really about breaking down silos? I would be reluctant with that, because I don't think that we say, okay, we put all into a single organization. What I think is the point, and I think that it's very important to be clear for the people listening to us, at the end, I think there are certain types of silos we must think about.

So should we put different applications in the line of business space that overlap into different organizational responsibilities, like an SAP department, et cetera, or better keep this as a more from a financial perspective or as an overall line of business responsibility? But on the other hand, audit versus IT versus finance, as organizational units will remain, I think when I get it right, the breaking down or changing silos thing is really about making them more open, making them talk with each other, work with each other, having processes that span the boundaries.

It's about normalizing processes, getting processes to be standard across those silos, getting communication open between those silos, having data flow, and normalizing tool sets and technologies across those as well. So what does it mean when we look at processes, control, ownership, responsibility? How do we deal, so to speak, with shared responsibility? I think shared responsibility is not easy. So accountability, anyway, we can't share, so someone is accountable.

Responsibility, we can split, but how do we manage that still in this world, everyone knows what to do and not just say, oh, I assumed that they already have done this, because that's the other side of the coin, isn't it? Yeah, I think part of that comes down to the processes in place, because a lot of it is, you know, even if IT owns this and they're going to manage the provisioning side of this, I mean, there still is the aspect of someone has to understand, you know, what is the rulebook? How do we build that risk? Where does that fit into the process?

That has to be kind of, again, as you mentioned, working across teams to understand where that fits in. But ultimately, you still have to have your other processes in place. You still have to have your controls in place. You recognize the risk. You need to make sure that's being mitigated, but also you have to do your governance processes, right? You have to have your certification to go in and make sure that, you know, people truly do have the access that they're supposed to, excuse me, supposed to have. And so it's not just, you know, one thing that solves all of your problems.

The automation helps, but we do have to still have our other traditional processes to support this as well. Okay. So when I look at this, where do you see the efficiency gains come from? I think one big efficiency I would see is interjecting the access control and your risk analysis into a preventative step inside of your provisioning process and your approval process on the IGA side. Because traditionally, you know, access is provisioned. Maybe IT grants that access or someone grants access, let's say, to a line of business application.

And, you know, we have a detective control on the GRC side from an access control perspective. That detective control may not run for, you know, a month or a quarter. And so access could be out there and we didn't realize it.

You know, there was risk in our environment that we didn't recognize for a quarter. By putting these in place, we start to recognize that risk much faster. It goes to the appropriate approval. So we gain efficiencies there that we don't have that risk in our environment. And you also can gain efficiencies of that. Those controls that I talked about earlier to mitigate that risk, they can be documented upfront. That can all be done today. So when we get to our quarter end, we're not, our quarterly review, we're not spending time doing that.

It's already been done as part of the onboarding provisioning process. Matt?

Yeah, I agree with that. And I think the traditional efficiencies that you see with an IGA solution, you know, provisioning accounts, deprovisioning access, you get all those traditional efficiencies that you always get with IGA. But in addition to that, by looking down into the GRC space and getting into the specific access that's available, you're also, in surfacing that into your IGA solution, you're also able to more efficiently understand risk. You're not going, spilling through spreadsheets to think, what does this entitlement really mean?

What access am I giving when I grant this entitlement? What access is, does this user have when they have these things? It makes whoever's in charge of controlling risk, it provides all that information directly when they're approving that access. So they don't have to, one, they don't have to do any research to figure out what's being granted.

And two, like Mike said, that becomes at the start of the process. And when the access is reviewed, you already have those risks defined and you can make an informed decision without provisioning that access and then coming back later to go take it away and change things. I would also dare to say that if we integrate this, there's more communication collaboration between the different departments. When I look at IGA, my experience is one of the biggest challenges in every IGA project is that business rarely is fully involved.

So I've seen so many IGA projects where IT teams try to come up with what could be meaningful business roles, which is hard to do because it's really not their responsibility, it's their job at the end of the day. And I would envision, so maybe you can respond from your experience, from your practice, that in an integrated approach, you automatically know the people to ask to bring in here to say, okay, and how do we really do that correctly? So what does it mean?

So when you have a process where IT and finance and audit and others talk with each other, I think then there are a couple of obvious advantages, including that IT and business are on the same table, so to speak. And maybe also that audit is so close that it's easier to understand which controls really do we need to have in place. So what's your perspective, your experience from practice here?

Yeah, that is a really good point, that the earlier you bring on all of the business units into the IGA process, the better everything's going to work, not only from a role definition, but also defining your automations, defining your business processes that you're trying to automate, and what does a mover really do, and what are the processes that need to occur. We definitely see the more active the business units are during the IGA implementation, the more fruitful that is, the more efficiencies you gain overall.

Mike, anything to add here? Yeah, I think the automation and kind of the consistent view across these different applications and across your processes is a big advantage. I mentioned earlier, a lot of times you're siloed by line of business, even when you're doing access control.

So having a consistent approach where when your auditors go in to evaluate a system or even a manager that we go in and they're reviewing access, it's consistent, whether it's line of business one or SAP or line of business two, you can begin to understand what the data I'm consuming is, it's not a different spreadsheet for each one. And then also the automation on the ownership side of this, right?

All the ownership can be built into this process, so it's all dynamic and everything comes into play, so when we are automating these approvals in these processes, we are getting the right people reviewing these up front, the right people are reviewing access for risk related to their area, rather than going through a generic approval or just a manager, we can make sure that the right owners of these things are in the process.

Yeah, and isn't it also that I think when you want to do that, so as in, let's take standard SAP ECC has a very different entitlement model than Active Directory, than Salesforce, than SuccessFactors, than whatever else, so you have, I think this is one of the challenges in all of these major systems from different ends of the spectrum, you have a great range of entitlement models, which is a cause of challenges because if you then say, okay, I'm somewhat familiar now as a manager with SAP, then the next system comes up and you say, okay, I don't understand this concept, I've learned the hardware, what an authorization object is or so, isn't the consequence of an integration that you also need to sort of have some normalization of these models, at least the layer of the business people see?

Yeah, I would say like the translation, right, that's an important part here where we're going in and we're giving, instead of taking a technical approach and saying you have access to T-code one and SAP, we're actually going in and taking a functional approach. And we can talk to anybody and say, do you know what it means to maintain a vendor or maintain a supplier? And they probably have an idea of what that means. If you're asking what T-codes and authorization objects they need in SAP to do that, that may be a little more of a challenge.

So really part of that process is as you surface that data to it, to your point, normalize it, make it more functional and understanding to the end user versus the technical artifacts. And if there is something that needs to be dived into the technical artifacts, then you can take that next level and pull in the technical folks that go to that level and understand that. Okay. And I think I'm for the wisdom because we need to make it simple. Unification makes sense. The more we also from an audit perspective, I think we have the same tendency on both sides of the pond.

So we see way more emphasis over here on technology risk, for instance, now on other types of risk. And this is all related surely also to even always to a certain extent of access and it goes just beyond the financial risk. So that the spectrum of what is audit becoming scope of it or which was in scope of audits is getting bigger. And so we need to think about probably in a more unified manner to be able to serve these needs. Before we maybe hop on the next part, which is really how do we make this work?

It might be interesting to have a look at the first of the two polls we've been raising, which was who's in your organization's responsible for application access control for line of business applications. This might be, no, I think it's not biased. So let's have a look at this. So what we have is that different departments, depending on the application as one response. So really multiple responsibilities were 46% and 15%. And it's saying, oh, we don't know or adverse. So it's run about some 60%, which said it is probably a bit split.

We didn't have the situation that someone said, okay, it's just the IAM department, just the SAP department, because usually others are involved. We at least had some 39% which said the IAM department is in charge. I think this is where probably organizations have either a broad definition right now of the IAM department, which really does more things when it comes to the entire management access control. And we see more, for instance, also CISOs being in charge of all the line of business application entitlement side, the access side.

But it also reflects probably a bit to smaller organizations where they say, okay, we anyway have that one responsibility when it comes to access and all the reviews. So thank you for displaying this. And maybe we go a bit back to our conversation here. So when we look at how to make this work, and I bring up a slide you've brought from the FastPass team, this is a bit of a perspective, and maybe this can be helpful for some of the explanations we have in this sort of second part of our conversation here.

But where I want to start is really what are, to your perspective, the key components and technologies involved in the best of breed framework we are applying here? And before we jump right into the technology, one thing I want to point out on this slide is it's kind of how the breakdown works between the access control side and the IGA side traditionally. And then that will kind of lead into where these fit from a technology perspective. Just at a high level, if you look at this, traditionally, IGA was more enterprise-wide top down.

So they were looking, as you mentioned earlier, the breadth was very wide, but not as deep. And so you had your job or position roles at the top or your job or position for the employee at the top, your enterprise roles, which were intended to grant access to multiple applications and entitlements. And then you get to that entitlement level, and that's where you really stopped was that entitlement level. That's where we provision some IGA solutions do, separation of duties at that level. But you really didn't have any insight into what's in those entitlements.

We didn't understand the objects, the permissions, and any risk associated to that. An entitlement was just a label. It could say inquiry only and give full access to the system, and we would never know that unless we dove in and actually understood that. So access control was what I would describe a little bit more bottom up. It came from that line of business, from the ERP, from other systems, and it really was focused on that detailed object level, doing deep, fine-grained risk analysis to understand where your risk was.

And so if you start at the bottom there and you see your SAP and Salesforce, and you go up, it kind of stopped at the entitlement level. So that's really the kind of the conjunction of the two platforms was, excuse me, access control had a very siloed view of specific applications up to the entitlement level. Sometimes they could look between applications, but not really the full picture. So it had the depth, but not the breadth, to your point earlier. And so then now we look at, back to your question of how do we actually integrate these things together? So what's the technology to do that?

And I really think you have to make sure that they can talk, right? They're two different systems, so you have to understand that identity and then have applications that are very tightly coupled to provide this level of depth.

And Matt, do you want to add a little bit on the technology side from the IGA perspective? Yeah, technology is always a challenge, but your traditional IGA vendors, like Mike said, are going to stop at that entitlement. And when you look at the technology, most technologies stop at the entitlement from an IGA perspective as well. Things like SCIM, SCIM-1, SCIM-2, they have facilities for entitlements. So that's one thing that we're focusing on right now at FastPath is how do we extend that? How do we extend those technologies to be able to look at a deeper level, look at the objects?

The big challenge is, as you mentioned earlier, the security model in SAP versus D365 versus Coupa, they're very different. Each of those vendors has a very specific, very unique security model. So we're really looking at how do you normalize that? How do you bring that data forward into an IGA solution without losing the fidelity? And that's the big challenge that we're tackling now. And there's a lot of different ways we can do that.

I don't want to geek out too much and get down in the weeds, but using things like schema extensions, using other normalization techniques in the data, we can start to normalize that and bring it forward and present it in a way that the business analysts and the risk analysts can actually make sense of it. So that's the challenge. Yeah. And I think we need to be clear that it's not about, it's not without challenges. So it's not that you say, okay, wait, I have to do one single bullet thing here that solves everything. I think it still is. You have a lot of applications.

And I think that's this graphic depicts. It's a very complex world we're living in. So I have some history in several of these areas and being familiar with several of the authorization models. Some of these are definitely very complex. You know what I have sometimes to say, I prefer a complex model over an oversimplified model. So the yes, no thing is always worse than the one which gives you the option to be a bit more granular. So maybe when we look at this and maybe go back to the agenda slide, for our discussion.

So what are sort of common obstacles you're facing when going for an integrated approach? I'm sorry, was it common obstacles?

Obstacles, yes. I think the big one there is just, like I said, the different security models in each of those ERPs and each of those systems. Besides the technology, going back to the very start of our conversation, a lot of times those different systems are managed by different departments in the organization. So you have the technology problems. In my mind, those are the fun ones to solve. Then you have the people problems, the organizational and business problems.

And a lot of times those are the most difficult to solve because you're really talking about getting those processes normalized, the people to talk to each other. A lot of times you have budgetary constraints for different groups on different budgets. And those are some of the more challenging obstacles to overcome versus the actual technology of making it work. On the other hand, I have to say, sometimes it is that people are super happy when they are finally brought together on the same table.

Because I think, you know, the other side of the coin, it's frequently frustrating for someone to say, hey, oh, they don't do it right. But then understanding, okay, what are the reasons and how could we potentially, by working together, help fixing this? And I think this is the other side. So sometimes my experiences also can be very encouraging and very positive when you see, hey, fostering the conversation really helped them and they felt very positive with it. Because as I've said, as you brought up there, there are a lot of dependencies also between the different groups.

And as I've said, when, you know, when am I the owner of a business application? And the auditor says, hey, you have so many And the auditor says, hey, you have so many over entitlements because you have whatever, didn't reflect the movers, et cetera, correctly.

And, you know, you don't get the data, then you're frustrated. But when you can fix that, then it's positive for both.

Yeah, and that's very true. And, you know, the challenge here is proving that we actually have a solution that works. And a lot of times our implementation approach is to start small, get some small wins and prove that out.

So, you know, nothing helps break down those silos and nothing helps convince each of the business units to work together more than seeing some success in another department or another site. So as we start to implement and we see some processes working, some efficiencies gained, some audits that just go really smoothly, the other departments take notice of that. And they say, oh, yeah, that's really working. I want to be part of that. So we often take that incremental approach to implementations where we start getting some successes and wins. Sorry. Okay.

I have a question that goes back to the the graphic we've been showing previously. In order to get further down from entitlement level to object level, what information is needed from the applications itself? Are the applications capable of providing those integrations point to read and understand granular access versus just sort of labels here?

Sorry, it wasn't bringing up the graphic again. So going further down below the entitlement, that was the question here, basically. So do you have the integration points usually or is it something where you say, okay, someone needs to enter it manually or whatever?

Yeah, I think, you know, integration automation is always the key, right? So you always want to make sure that's an automated process where you're pulling that data in. It is a big challenge. And that's part of the reason I think IGA probably traditionally stopped at that level is because a lot of times you have to go build a specific connector that goes in and every ERP is, or not ERP, line of business and ERP and the cloud systems, they all have different security models and different implementations.

And sometimes you're going to a database, sometimes you're going to an API, sometimes you're building packages or bundles to put in those systems to expose the data you need. And one, it's been a challenge and that's where access control has been very strong because they were very, as I mentioned, bottom up. They were focused on that. They had those deep integrations. And what we did years ago is we started looking, instead of just at specific systems, we really started looking across multiple systems. But that gave you the advantage of doing that.

And now when you start tying that together with IGA, you really start getting that ability to surface that data all the way up to the identity where that's always been kind of a broken step in the past. So when we look at this, and I think we already started going because I'm constantly into the Q&A, but when we look at this, so what are your most relevant structure recommendations for end-user organizations to move forward to that direction?

For me, I want to get back to the point I made a few minutes ago, which is don't try to boil the ocean. Don't try to do everything at once. Start small. Pick your most highest risk applications. Pick the business processes where you're having either the most risk or the most trouble. And get those initial wins under your belt and grow the solution from there. I have seen large organizations make the mistake of saying, we're not going to go live with our solution until we have everything automated. And there's the technology challenges that it's hard to do everything.

But then there's also the business challenges that where you're trying to get everything done and then there's an acquisition or reorganization and suddenly all your processes are changing and you have to change the project as well. So it kind of puts you in a position, a no-win position. So start small, figure out your highest priorities and then grow it from there is I think the biggest key to success. Mike?

Yeah, kind of echo off Matt. I think the starting small thing is key. The other thing is to remember when you are talking about the access control side is make sure you're taking a risk based approach. Focus on the highest risk areas, the highest risk systems. And remember, we talked about this fine grained data and going to the object level. You don't necessarily have to do that for every application that you're going to have in your IGA. You need to do it for your core applications where your risk is going to be most prevalent.

The reason finance comes up a lot is because that's where cash is and that's where your first risk is typically found. But really, even when you roll out your rule book, focus on those high risk areas, get those addressed first and then you can move on to lower and medium. And you'll see that when you build out your processes and your approvals. You may require a different approval for critical or high risk areas versus low risk you may not be as concerned with. Couldn't there be another angle which goes more from where can I have a sort of a relatively fast win and demonstrate it works?

So sometimes the high risk areas unfortunately tend to be the most complex areas. Yeah, I think that approach is valuable, especially if you're in an organization that has a lot of doubt about the technology or something they've never implemented before. Then that is a really good approach to get something, get a win under your belt and then move on from there. Yeah. So out of practical advice, best practices you would bring up here? Best practices from the process overall?

Yeah, for this, how do you embark on that journey? How do you make it a success?

Yeah, I think first off, obviously there's evaluating the applications that can automate this, right? There's what vendors are out there. It's not something you can do just manual. The whole point is automation. So you want to look for solutions that are going to give you the breadth that you talked about, but also give you the depth in the areas you specifically look for. So you want to look for the wide number of connectors.

And again, you may not implement all of those day one, but you want to look at what is our long-term strategy? Where are we going to go with this solution? So as we start small, how are we going to be able to expand and are these systems going to allow us to expand? And really identify ways that you can do that and do it efficiently. Sometimes there's things that are so big and it's like, well, this can do everything, but can you actually implement it? Can you implement it on budget in a reasonable amount of time?

Those are all things you have to take into consideration based on your organization and your goals. Yeah. And will you ever need it? I think this is the point. I think requirements analysis and really having the right understanding of requirements. So what do you really need? What is more or should have, what could have. Understanding also probably what you never will do. I think this is very important when you're looking at it. So we have a couple of more questions here to look at. So one question that is basically the question is, doesn't IGA already have SOD capabilities?

You can read this question also as why do I need more than IGA? Yeah. I touched on that a little bit earlier when we talked about the entitlement level and it's just a label. And what I meant by that is, a lot of times in IGA, they do have SOD capabilities, but they're just looking to say, if you have entitlement one and entitlement two, is that a risk? And remember, those are just labels. So if you ignore all of your inquiry only response or entitlements, maybe you're not recognizing risk. There could be unrecognized risk.

There could be unrecognized risk in your environment because you didn't build a rule around that. The other thing you end up with is a lot of rule set churn because every time an entitlement changes, the objects below that, the access below that changes, you have to reevaluate your rule set to say, do I need new rules? And it really becomes unmanageable at that level to accurately report risk. When you take this approach of integrating access control at an object level, you don't really care the name of the entitlement.

What you want to know at the end of the day, I want to know, can Martin maintain a vendor and can he pay that vendor? And I want to do that based on the permissions assigned to him, regardless of the name of the entitlement and really getting down to that level that facilitates that. And from an audit perspective, you go talk to any of the big four, they're going to say best practice is to go down to that object level to really truly understand your risk.

Okay, let's look what we also have in questions here. Will analyzing at this level of decay create issues in the provisioning process? So is it maybe that we go over the top for what we should do in IGA when we pretty much emphasize on all the details and entitlement provisioning, etc. So does it make the process complex?

Yeah, I think there are challenges there. Especially if you take Matt's boil the ocean approach, right? If you go in and try to recognize every risk and worry about every little detail. And this goes, again, a little bit of the risk based approach of, you know, make sure you're kind of focusing on the crucial critical areas, whether that's based on application or even within application, what are the key risk areas you want to focus on. So make sure you really identify what your needs are. And that will help you with on the performance side.

So that way, you're processing less data, you're not interjecting as much into the, you know, noise into the system. And you also end up with better results. Because if you're truly looking at the highest risk areas, you get better review by your your employees, the owners, versus if they're just getting overloaded with with, you know, data, and approvals, a lot of times that starts becoming just a rubber rubber stamp on those. So you want to make sure you're truly focusing.

Okay, go ahead. Well, I'm sorry, I think the other thing to add to that is, if it does expose issues with provisioning, then that that's often an indication that the security models are set up incorrectly in those target applications. So if you have entitlements that you can just never provision because they expose too much risk, maybe that's not a very good entitlement, maybe that there's too much access or too broad access being provided by that.

So it exposes some of those issues earlier than, you know, when you get into an audit and realize, oh, we've given everybody too much access, because we've set things up incorrectly. Okay, two, two more questions there. In the interest of time, I'd like to get a very short answer. The one is, who would, from your perspective, be the right owner for this combined IGH ERC? I think that's often what we see a lot of customers doing now is creating a risk group or an identity team that owns this.

Somebody, an organization that has cross department, cross organization responsibility and authority to standardize, define those processes, normalize things. I think that's probably the best approach that I've seen.

Otherwise, you start getting into interdepartment politics and things like that. Okay. And final question, access reviews, will they become better and easier or will they become just too complex? I think ultimately they become better and easier. I think you have the ability, you're still going to do your traditional, you know, review of entitlements, but I think it also gives you the ability to certify beyond entitlement. And you can start looking at some of that object level information.

So if I want to certify risk, certify sensitive access, if I want to, you know, dive in and see any of that object level data, I have it to get a better understanding. So it makes us more knowledgeable while still allowing us to do our traditional process. I would say unifying things. So unification makes things simpler. And when we have a sort of homogeneous view across different types of entitlements from different applications, life definitely becomes easier. So what I see is definitely a very strong potential.

I think that's something I'm also telling for quite a while in really closing the gaps, bringing these things closer together. And I feel that we had a lot of insights and practical advice here also on how to do that and how the journey could look like. It involves a lot of things, the right organization, technical integration, some work in more unifying entitlements, but I think it's worth to do that journey. Also in light of today's risks we are facing.

So Mike, thank you very much for all the information provided. Thank you very much to FastPass for supporting this clinical analysis webinar. Thank you to all the attendees for being here, for listening to us, for raising questions and participating in the polls. So thank you very much and enjoy the remainder of your day.

Thanks, Martin.