I'm Martin Kuppinger. I'm Principal Analyst at, and I'm your host today for our webinar harness, IJ and G R C, synergies for Active Identity Management and Access Control. This webinar supported by FastPass and the speakers today will be Mike ine, who is Senior Director of Product and Solutions, FastPass. Mike Cassy, chief Product Officer at FastPass. Me Martin. Said, I'm Principal Analyst. Analyst. Before we dive into the agenda of today's webinars and the, the content, a little bit of housekeeping. First, I'm, or we are controlling audio, so you don't need to control the audio features. We're doing this, we'll run two polls during the webinar and if time allows, we'll discuss the results during q a and the already means we will have a q and A session for today's webinar. It'll be maybe a bit mixed in the sense of that. We may pick your questions queue a longer sort of conversation part of the webinar so you can enter questions at any time.
The more questions you have, the better is there's on the right hand side of the app, there's some, there's an area for entering your questions and we are recording the webinar. So we will provide recording and slide or slide deck in that case relatively shortly after the webinar. So what I wanna do first, before we go into the content of the webinars, raising a first poll, a question to you, and I hope that a lot of you'll respond. And 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 E R P and all the other types of line of business applications you have? So are these different departments depending on the application? Is it the s a p department? Is it the IMM department or are it others?
So looking forward to your responses. We leave this all 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 in many of other, our other webinars. So what, what we'll do is that I give a quick intro, a a bit of talk about the intersection I see between I j and application access control, or I I J and G C, however you wanna phrase it terminology wise. In the second part, Mike and Matt from me, we will, will have a discussion about the synergies that can be leveraged by integrating I H A A and G R C. So we'll look at what can be the benefit of really bringing these two domains together for various types of organizations, but also with a bit of an emphasis on the medium sized mid market world. And then we do the q and a as of that, it may be that we merge of it, the sections two and three, the more questions come during the conversation, we'll try to, to pick them up sooner and immediately so that we can cover that.
What I see as an Analyst. So, so I'm observing this market for, for quite a while, and what I see as a, a very important point in, in this entire market is that the, 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 the real cloud, real modern architect solutions, which is a bit of a mixed trend. So it's, it's a journey for, 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 that is, I think to a certain extent related that we also see 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, et cetera. So more vendors coming in. So while, while we still see that, that many organizations say, okay, there's at core there's is a pr, Oracle, 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 more single vendor side. Some more on the on-prem audit, pure SaaS side. But it's, it's, it's a shift from the sort of the traditional way we looked 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 line of business application, we also have I g A, 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 like fastas are in this convergence. So we have the I G A part, which is really supporting wide range of applications beyond the line of business applications.
There's the actual 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 SS A p providing rule books, et cetera. And then there are things that are uncommon provisioning, user life cycle access review, certain level of s a d control. So there's a significant overlap, probably bigger than this when diagram I have created here indicates. So it's in the end we need to understand, we, we, we have a breadth and a 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 accurate, as I've said, we'll provide this slide also a download, but I think it becomes very clear there are things where or both are, are strong. There are areas where really one of the two technologies access, there are areas where both are okay but overlapping.
And so there, there's a logic in saying we, we look at both types of capabilities and I believe in this certain part of our conversation later on, there's a significant potential also that going closer here, bringing these things, those together. And there, there are many reasons for that. There's a, as I've said, the overlap. So when look at it more from a technology perspective when you are at a super big organization that also it's a matter of who can care for what. And, and so how do you sort of use the, the, the people you have in optimal manner that work together. Joining forces can be very good, 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 audits.
And this is really changing, but we have way more technology risk aspects, et cetera, which go then more into the non l o B world, beyond what we did in the l o B world. So we need to understand, bring our sort of our audit compliance efforts also together. I think this is also very important aspect within this convergence. So with all these overlaps, there's a logic to, to bring things together. And when I put together just some, some aspects, I don't claim this to be a comprehensive, a complete list, but there are a couple of things a modern g p approach requires. And I think one of the things is needs to take a business perspective. So we not only need to look at technical artifacts, we need to translate is, so an SS P transaction code must be translated and we need a modern UI for every user.
So not only looking at the text that we want and the more systems we look at and we have to look at them 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, we, we must keep in mind, automation is key to success as always we need then also, but aside of this, this this high level perspective and the business centric you, we need to be able to drill into the details. We need a process and 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 this. I'm with iga, identity governance administration specifically this, it is enterprise service management with business process management with cybersecurity.
There's a lot to integrate with. And I believe a very important starting point and a very good starting point is really looking at how IG and G R C integrate and which synergies this can deliver. As I've said, this will be the really the the talking point. So we need breadth and integration. So we connected, we need to analyze in depth 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 I believe in effectiveness and in efficiency. So with that, another quick poll and that is really about application access control versus I or T R C versus i j 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, so may maybe the two of you introduce yourself quickly and may maybe give a very quick first impression about FastPass. So Mike, you wanna start? Sure.
Mike Cassy. I'm the Chief product officer at fastpath. I've been with the company for 16 years. We traditionally, we started out in the access control space and over time we, we started getting into more of the, the governance and I g a space and identity management. And so now we offer products across I g a access control spectrum and it covers a lot of the areas that we're gonna cut go through today.
Matt,
Excuse me. Hi, I'm Matt bde. I have had a long career in the I G A space, so my background is with consulting doing I g a implementations for a few different vendors and finally came, came on with FASTPATH to do, flush out the I g A capabilities within fastpath. So it's been exciting to see the kind of the convergence of I G A and G R C here at fastpath and excited to talk about that and share that today.
Okay, great. I, I think when, when we look at this, I, I'm, we touchless conversions and potential for synergies between IG and GRC quickly in my talk, but, but when we, when we look at this, I think in many organizations as we know, I g and GRC still operate in different silos and sometimes there are multiple G R C silos even so that things even so to speak become more complex here. So what, what do you see as, as the sort of the, the challenge first that comes from such a siloed approach?
Yeah, I think the, the challenge that we see there a lot, you know, as you mentioned, a lot of times it's owned by the line, the access control side's owned by the line of business owner or it's owned by finance, maybe audit. And that's really separate from the I G A side, which is oftentimes owned by the IT department. So, and, 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 and it becomes really difficult to understand the identity and the, the risk across the enterprise because we're looking in very small windows in these different areas. So the convergence of 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, 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, the risk across the organization.
So, so why, why, why do we need this better risk understanding or, or how, how is it broken frequently today? Yeah,
I think if, if you look in today's world with all of the cybersecurity risk and, and the, 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, or moving throughout the organization, it's important that we really restrict the access they have. Obviously that's the point of iga A is that we automate that and we also restrict their access. But when those things are separate and maybe you're provisioning in, in certain areas not covered, or your risk isn't covered by the I G A 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, of least pri privilege.
And, and I think to add onto that, the, in the siloed approach, each of those silos has a very narrow view of what's going on in the world. They, 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, 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 would, 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, we can start to surface risks that you wouldn't see before.
Yeah, and and, and I think that the point is also that, Mike, you brought up the, the process perspective as well, the integration perspective. The point is surely I think very clear to everyone when, 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 I g A perspective, if we are not good in mover and legal processes and ensuring that entitlements are revoked, that whatever line of business applications learn about someone has left, someone has changed the job. If if this process is broken, then inevitably the risk goes up because then we are in a state of or entitlement per se.
Yeah, that that's very true. And i, I, in my consulting career, I was always shocked to see how many companies actually continue to grow that access. If somebody's been been with the organization for 10 or 20 years, they, they just accumulate more access as they move across different jobs. And, and then to make matters worse, if they don't have their joiner processes well defined, they will copy that access for, for a new joiner and say, well Bob, 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, it it exacerbates that problem and continues to grow. So, yep, that's very true.
Is, is this entire thing then really about breaking down silos? I I would be reluctant with that because I don't think that we, we say, okay, we, we, we put into, into a organization what I think is the point and important for, for the people listening to us at the end, I, I think there, there are certain types of silos we, we, we must think about. So, so should we put different applications in the line of business space that overlap into different organizational responsibilities like an SS a P department, et cetera, or better keep this as a more from a functional 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 that when I get it right, breaking down or changing silos thing, it's really about making them more open, making them talk with each other, work with each other, having processes that span the boundaries. Yeah,
It's, it's about normalizing processes, getting processes to be standard across those silos, getting communication open between those silos, having, having data flow and use and normalizing tool sets and technologies across those as well.
So what does it mean when we, when we look at processes, control, ownership, responsibility, how do we deal, so to speak this, this shared responsibility, I think shared responsibility is so not easy. So when we, so accountability anyway, we can share, so is accountable responsibility, we can split that. How do we manage them that still in this world, everyone knows what to do and not just says, oh, I assumed that they already have done this, because that's the other side of the coin, isn't it?
Yeah, I think, I mean, I think part of that comes down to the processes in place because a, a lot of it is, you know, even if it owns this and, and they're gonna manage the provisioning side of this, I mean there still is the aspect of someone has to understand, you know, what is the rule book? 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 you, 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 there, it's not just a, 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, where do you see them efficiency gains come from?
I think one big efficiency I would see is, is interjecting the access control and your risk analysis into a preventative step inside of your provisioning process and your approval process on the I G A 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 G R C 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, we didn't realize it, you know, there was risk in our environment that we didn't recognize for a quarter. By, 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, or our quarterly review, we're not spending time doing that. It's already been done as part of the, the onboarding provisioning process.
Matt?
Yeah, I I, I agree with that and I, I think the, the traditional efficiencies that you see with an I G A solution, you know, provisioning accounts, provi, deprovisioning access, you, you get all those traditional efficiencies that you always get with I G A. But in addition to that, by looking down into the G R C space and getting in into the, the specific access that's available, you're also in surfacing that and into your I G A solution, you're also able to more efficiently understand, understand risk. You're not going spilling through spreadsheets to see what does this entitlement really mean? What, what access am I giving when I grant this entitlement? What access is, does this user have when they have these things? It makes who, 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, do any research to figure, figure out what's being granted. And two, like Mike said, that that becomes at the start of the process and when the access is is reviewed, you already have those risks defined and you can make an informed decision without, without provisioning that access and then coming back later to go take it away and change things. Yeah,
I I I, I would also there to say that if we integrate this, there's more, more communication collaboration between the different departments. And when, when I look at, I experience one of the biggest challenges in every i, that business really is fully involved. So, so I've seen so many I j a 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, their responsibility that their, their job at the end of, of the day. And I, I would envision so from 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, and how do we really do that correctly? So what does it mean? So when, when you have a process for IT and finance and audit and others talk with each other, I think that there, there are a couple of office 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, what what's your, your perspective, your experience from practice here? Yeah,
That, that is a really good point. The, the earlier you bring on all of the business units into that, into the I G A process, the, the better everything's gonna work, not only from a role definition, but also defining your automations, defining your business processes that you're, you're trying to automate and you know, what does a, what does a mover really do and what are the processes that need to occur? That, that's, we definitely see the more active those business units are during the I G A implementation, the more fruitful that is, the more efficiencies you gain overall.
Mike, anything to add here?
Yeah, I think, I think the, the automation and, and kind of the, the consistent view across these different applications and across your processes is a big, big advantage. I mentioned earlier, a lot of times you're, you know, you're siloed by line of business even when you're doing access control. So having a consistent approach where when your auditors go into evaluate a system or even a manager that we go in and, and they're reviewing access, it, it's consistent, whether it's line of business one or s a p or or line of business two, it's, they, they, you, you can begin to understand what the data I'm consuming is. It's not a different spreadsheet for each one. And then, 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 upfront. 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, are in the process.
Yeah, that I think when, when you want to do that, so as it, let's take standard, S A P E C has a very different entitlement model than active directory, than Salesforce, than SuccessFactors, than whatever else. So you, you have, I think this is one of the challenges in, in all of these major systems from different ends of the spectrum, you have a, a great, great range of, of entitlement models and which is, which is a, a, a cause of, of challenges. Because if you don't say, okay, I'm somewhat familiar now as a manager with s a p, then the next system comes up and then you say, okay, I don't understand this concept. I've learned the hardware, water authorization object is, isn't isn't the consequence of an integration that you also need to sort of have some normalization of these models, at least at the, the layer the business people see.
Yeah, I would say like the translation, right? That 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 s a p, we're actually going in and taking a functional approach and, you know, we could talk to any pe 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 ask 'em what t codes and authorization and objects, they need an SS a P 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, and if there is something that needs to be dived into the technical artifacts, then you can take that next level and, and, you know, pull in the technical folks that, that go to that level and understand that.
Okay. And I think I'm, I'm fully with it because we need to make it simpler. Unification makes sense. And as I said, the more we also from an audit perspective, I, I think we have have the same tendency on both sides of the pond. So, so we see way, way more emphasis over here on, on technology risk, for instance, now on, on other types of risks. And this is all related truly also to imo, always to a certain extent access, and it goes just beyond the financial risk. So the, the spectrum of audit is audit becoming scope of, or which, what in scope of audits is getting bigger. And so we need to think about probably in a, in a more unified manner to be able to serve these needs be before we maybe hop on the next part, which is really how do we make this work.
It might be interesting to, to have a look at the, the first of the two poles we've been racing, 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, what we had is that different departments depending on the application as as one response. So really multiple responsibilities were 46% and 15%. And it's saying, oh, we don't know or adverse. So it, it's round about some 60%, which said it's probably a bit split. We, we didn't have, have, have the situation that someone said, okay, it's just the IM department, just the s a P department because usually others are involved. We at least had some, some 39%, which said the IM department is in charge. I think this is where probably organizations have either a broader definition right now of the IM department, which really does more things other when it comes to the entire access management, access control.
And we see more, for instance, as the CSOs being in charge of all the land of business application entitlement side, the access side. But it also reflects probably a bit to smaller organizations that where they say, okay, we anyway have the that one responsibility when it comes to access and all the reviews. So thank you for displaying this and maybe we go a bit a bit back to that our, our conversation here. So when, when we look at how to make this work, and I I I bring up a slide you, you've brought from the fast pass team, this is a bit of a perspective, and maybe this can be helpful for some of the explanation we have in this sort of second part of our conversation here, but where, where I wanna start is, is really what are to your perspective, the key components and technologies involved on a, in a best of breed framework, we are applying here.
Yeah. And, 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 I G A side traditionally. And then that will kind of lead into, you know, where these fit from a technology perspective. Just at a high level, if you look at this, traditionally, I g A was more enterprise-wide, top down. So they were looking as, as you mentioned earlier there, the breadth was very wide but not, not as deep. And so you had your, 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, you know, multiple applications and entitlements. And then you get to that entitlement level and, and that's where you really stopped was that entitlement level.
That's where we provision some i g a solutions. Do you know, se separation of duties at that level, but you really didn't have any insight into what's in those entitlements. You know, we didn't understand the objects, the permissions and any risk associated to that. And entitlement was just a label. It could say inquiry only and get 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 e r p, from other systems and it really was focused on that detailed object level doing deep fine grain risk analysis to understand where your risk was. And so if you start at the bottom there and you see your, you know, SS a P and Salesforce and you go up, it kind of stopped at the entitlement level.
So that's really the, 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, you know, back to your question of how do we actually integrate these things together? So what's the technology to do that? And, and I really think you have to make sure that they can talk, right? They're, they're two different systems, so you have to understand that identity and then have applications that are very tightly coupled to provide this, this level of, of depth. And Matt, do you wanna add a little bit on the technology side from the IGA perspective?
Yeah, technology is always, is, is a challenge, but you know, your traditional I g A vendors like, like Mike said, are gonna stop at that entitlement. And when you look at the technology, most technology stop at the entitlement from an iga, a perspective as well. Things like Skimm, Skimm one, Skimm two, they, they have facilities for entitlements. So we're, you know, 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 challenges as, as you mentioned earlier, what the security model in SS a P versus D 365 versus Coupa, they're, 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, a solution without losing the fidelity? And that, and that's the big challenge that, that we're tackling now. And there's a lot of different ways we can do that. I don't wanna geek out too much and get, get down in the weeds, but, you know, using things like ischemic extensions, using other normalization techniques in the data, we, we can start to normalize that and bring it forward and present it in a way that, that the business Analysts and the risk Analysts can actually make sense of it. So that, that's the challenge.
Yeah, and I, I, I think it, it's, it's not easy. I think what I think we need to be clear, it's not about, it's not without challenges. So it's not that you say, okay, wait, I have the one silver bullet thing here that solves everything. I think it, it still is, you have a lot of applications and I think as this graphic depicts, it's, it's a very complex world we're living in. And so I I have some history in several of these areas and being familiar with several of the, the authorization models, some of these are definitely very complex. Even what I have sometimes to say, I, I prefer a complex model over an oversimplified model. So the yes no thing is, is always worse than, than the one which gives you the option to be a bit more, more granular. But so, so, so maybe when we look at this, and then I maybe go back to the, the agenda slide and Okay. For our discussion, so what, what, what are sort of common obstacles you're facing when, when going for an integrated approach?
I'm sorry, what was it? Common obstacles.
Obstacles, yes.
Yes. I, I think the big one there is just, like I said, the, the different security models in each, in each of those ERPs in each of those systems. Besides the technology, going back to the very start of our, our conversation, a lot of times those different systems are managed by different organ, different departments in the organization. So you have the technology problems. In my mind those are, those are the fun ones to solve. Then you have the, the people problems that the organizational and business problems. And a lot of times those are the most difficult to solve. 'cause you're, you're really talking about getting the, the, those processes normalized, the people to talk to each other. The, a lot of times you have budgetary constraints for different groups, own different budgets, and those are some, some of the more challenging obstacles to overcome versus the actual technology of making it work
On, on the other hand, I have to say sometimes it's that people are super happy when they are finally brought together on the same table because I, I think, you know, the other side of the coin, it's, 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, by working together help fixing this? And I think this is the other side. So sometimes I, my experiences also can be very encouraging and, and very positive when you see, hey, fostering that conversation really helped them and, and they felt, 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 process. And as I said, when, when, when, you know, when I, when I'm at the owner of a business application 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 then you can fix that, then, then, then it's, it's positive for both.
Yeah. And, and that's, that's very true. And you know, the challenge there 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, in another department or another silo. So we, as we start to implement and we see some, some processes working, some efficiencies gain some audits that just go really smoothly. The other, the other departments take notice of that and they say, oh yeah, that's, that's really working. I want, I want, I wanna be part of that. Yeah. So we, we often take that incremental approach to implementations where we get the door and start, start getting some successes and wins. Sorry.
Okay. I I, I have, I have a question that goes back to the, the, the graphic 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 read and understand cranial access versus just sort of labels here? So it, it wasn't bring up with traffic again. So going, going down further down beyond the, 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, I someone needs to enter it manually or whatever.
Yeah, I think, you know, integration automation's always the key, right? So you always wanna 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 I g a probably traditionally stopped at that level is because a lot of times you have to go build a specific connector that goes in and, and every E R P is ha or not e r p, line of business and E R P and the cloud systems, they all have different security models and different implementations, and sometimes you're going to a a database, sometimes you're going to an a p i, sometimes you're building packages or bundles to put in those systems to expose the data data you need. And, 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, they had those deep integrations and what 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. But, and, and now when you start tying that together with I g A, you really start getting that ability to surface that data all the way up to the identity where that's always been a kind of a broken step in the past.
So when, when we, when we look at this, and I think we, we already started going a bit of constantly into, into the q and a, but when we look at this, so, so what are your most relevant stretch recommendations for, for end user organizations to move forward to the direction?
For me, I, oh,
Go ahead Matt.
Well, I, I want to get back to the, the point i I made a few minutes ago, which was don't try to boil the ocean. Don't try to do everything at once. Start small, pick your most, your highest risk applications, pick the business processes where you're having the most, either the most risk or the most trouble, and get those initial wins under your belt and grow the, grow the solution from there. I, I have seen large organizations make the mistake of saying, we're not going to go live with our, with our solution until we have everything automated. And, you know, there's a technology challenges that, that it's hard to do everything, but then there's also the business challenges that where, you know, you, you're trying to get everything done and then there's an acquisition or a reorganization and suddenly all your processes are changing and you have to change the project as well. So it, it kind of puts you in a position a, a no win position. So start small, figure out your highest priorities and then grow it from there. Is is I think the biggest key to success.
Mike?
Yeah, kind of echo off Matt. You know, I think the starting small thing is, is key. The other thing is to remember when you, 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, you know, we talk about this fine grain data and going to the object level, you, you don't necessarily have to do that for every application that you're going to have in your I G A, right? You need to do it for your, your core applications where your risk is going to be most prevalent. The reason finance comes up a lot is because that's, you know, where cash is and that's where your first risk is, is typically found. But really, you know, even when you roll out your rule book, you know, focus on those high risk areas, get those addressed first, and then you can move on to lower and medium and, and you'll see that when you build out your processes and your approvals, you may require a different approval for critical or high, high risk areas versus low risk you may not be as concerned with,
Couldn't it be on another angle? 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 to be the, the most complex areas.
Yeah, I, I, I think that approach is valuable, especially if you're in an organization that has a lot of doubt about the technology or it's something they've never implemented before, then that is a, a really good approach to get something, get a win under your belt and then move on from there.
Yeah. From, so outta practical advice, best practices you, you would bring up here,
Best practice just from the process overall?
Yeah. For, for this, how do you embark on that journey? How do you make it a success? Yeah,
I think, you know, first off, obviously there's evaluating, you know, the applications that can then au that can automate this, right? There's, you know, what vendors are out there, you know, 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 that you specifically look for. So you wanna look for, you know, who had the, the wide number of connectors and, and again, you may not implement all of those day one, but you wanna look at what is our long-term strategy, where are we gonna go with this solution? So as we start small, how are we gonna be able to expand and are these systems going to allow us to expand and, and really identify, you know, ways that you can do that and do it efficiently. Sometimes there's, there's things that are, they're 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, in a reasonable amount of time? Those are all things you have to take into consideration based on your organization and, and, and your goals.
Yeah. And will you ever need it? I think this is the point, I think re requirements analysis and, and really having to write understanding of requirements. So what do you really need? What is more, more or should have what is a could have? Yeah. Understanding also probably what you never will, will, will do. I think this is very important when, when you're looking at the, the right tool. So we have still a couple more questions here to look at. So one question that is basically the question is, doesn't I g A already have s o d capabilities? We can read this question also as why do I need more than I g a?
Yeah, I, I touched on that a little bit earlier when we talked about, you know, the entitlement level and it, it's just a label. And what I meant by that is, you know, a lot of times in i a they do have s o d 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 risks, there could be unrecognized risk in your environment because you didn't build a rule around 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, and it really becomes unmanageable at that level to accurately report risk. When you take this approach of integrating access control at a object level, you, 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, and from an audit perspective, if you go talk to any of the, the big four, they're, they're gonna 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. Well analyzing at this level of dk create issues in the provisioning process. So is it maybe that, that we go over the top for, for what we should do in I g a when we put much emphasize on, on all the details and entitlement provisioning, et cetera? So does it make the process to complex? Yeah,
I think there are challenges there, especially if, if you take Matt's boil the ocean approach, right? If you go in and try to recognize every risk and, and worry about every little detail, and this goes again, a little bit of the, 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, the key risk areas you wanna focus on? So, 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, 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 then it starts becoming just a, a rubber rubber stamp on those. Okay. So you wanna make sure that you're truly focusing
And I I would, okay, go ahead. Well,
Sorry, I, I 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 entitlement. So it, it exposes some of those issues earlier then, you know, when you get into an audit and realize, oh, we've given everybody too much access because we set things up incorrectly.
Okay. Two, two more questions. Where in the interest of time I, I'd like to get a very short answer. Iwan is who, who would, from your perspective, be the right owner for this combined I G H G R C?
I think that's often what we see a lot of customers doing now is creating a, a risk group or an identity team that owns this. Somebody, an organization that has cross cross department, cross organization responsibility and authority to standardize, define those processes, normalize things. I, I think that's probably the best approach that I've seen. Otherwise you start getting into interdepartment politics and, and things like that. Okay.
And final question, access reviews, will they become better and easier or will they become trust too complex?
I think ultimately they, they become better and easier. I think you have the ability, you're still gonna do your traditional, you know, review of entitlements, but I think it also gives you the ability to, to certify beyond entitlement and you can start looking at some of that object level information. So if I wanna 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, I would say also have us 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 a worth to do that journey also in light of today's risks we are facing. So Mike and Matt, thank you very much for all the information provided. Thank you very much to FastPass for supporting this call Analyst webinar. Thank you to all the attendees for being here, for listening to us for raising questions and taking so.
