Hello, again, everybody. Yes. I've entitled my presentation. Don't reinvent the wheel. And more specifically is don't reinvent IGA because that's already been invented and taking very good care of itself. So align I TSM with Ida instead. So that's kind of just the overall arching message that I want to get across today. And we'll start with a, a look at the agenda, the content and things we gonna look at, and we'll start with an introduction. So an overview of why it's not a good idea for organizations to undertake rebuilding IGA functionality on top of I TSM systems.
Now this is something that Martin Kuppinger covered in his keynote this morning and talked about the reasons for not really wanting to do that. And I'll go into that in a little bit more detail. So then we'll discuss a slightly better approach, which in our view is to align IGA and I T SM systems by following five key principles. And then to wrap up, we'll just give, go through a brief summary of the key points.
So in the overview, I just wanted to give you an idea of where this conversation will is going to go.
And then you can get an idea of, of, of where our point of departure and, and, and arrival is. And we'll look into some of the more detail a little bit later, but first some of the key points. So the first point is that a single interface for all service requests is an attractive proposition for most businesses. And that's for two reasons. The first reason is improved user experience. It's just easier, more familiar, convenient to go to one place, to satisfy all your user requests. And secondly, business is looking to get more value out of their investment in I TSM.
So if you bought this or invested in this bright, shiny I TSM system, you want to get more out of it. So as a result, we are seeing that many organizations are building or attempting to build functionality into their I T SM systems to respond to all employee requests. So this is including identity provisioning and access entitlements. So that's number one. Number two is we think that this is a risky strategy from a security and compliance point of view.
And the reason is that failure to fulfill IGA related requests through dedicated IGA systems, we think will inevitably result in a failure to monitor log document, and manage these activities. And of course that can lead to security and compliance risks.
And then related to that, then this is challenging and costly. Or in addition to that is cha it's challenging and costly because I T SM does not come with sufficient IGA capabilities, but it's challenging and costly in the long term to actually build and maintain highly customized I T SM systems.
And another long-term risk is that when problems arise in the future or somewhere down in, in, in the future, the original developers and system integrators who understand the code may long, no longer be available. So that could be a problem. So while we believe there is value in having a single Porwal that everyone in an organization can use for all service requests, it needs to be done in a way that is secure and compliant, but we believe that is possible. And the way it is possible is by aligning I T SM and IGA systems, according to five key principles.
So in the next section, we'll go through each one of those five principles and look at them in more detail. First up is use the right tool for the job. When I was preparing this presentation, that's made me think of Maslow's hammer. I'm not sure if you're familiar with this idea that if the only tool you have is a hammer, everything looks like a nail. So while you may be able to, to drive home a screw with, with a hammer, it would be much more effective to use a screw driver.
So similarly, if you have an I TSM tool that you're trying to get more value out of, then you may use it to do something that's not quite the right thing that it's been designed to do, cuz at the heart of it, I T SM is designed to manage it services and that's what they're dedicated to. And that's what they're good at. But IGA is designed to manage digital identities, access rights, and access rights in a secure and compliant way.
IGA includes functionality to provision store, track, monitor, manage, and retire digital identities.
In addition, it includes functionality to issue, monitor, manage review, and withdraw access rights to it. Resources and IGA is designed to meet all the necessary requirements, both from a security and compliance point of view. So this require, this ensures that if you're doing something like a password change request, for example, IGA would include who requested it, who approved and executed the change and when the change was executed. But if you're doing that in, I T SM it might not necessarily include all those things.
And if it does, it will require a GA great deal of effort to get those things in place. So again, back to the theme of not reinventing will. So fundamentally we've just gotta recognize the fact that IGA is something different to I TSM I T SM should not be extended to deliver something that is outside of I TSM.
So not to put two finer point on it. I T SM is not equivalent to, or not equal to IGA closely related to that first principle of using the right tool for the job is number two, don't build an IGA tool using I T SM.
So again, this was something that Martin keeping had touched on in his keynote presentation earlier today, I TSM and IGA have very specialized yet different functionality that shouldn't be mixed. In addition to some of the differences that we've already discussed, we can say that I SMS main difference is that it focuses on course grain requests. I need a new PC.
I need, I need a new application put on that PC. Whereas IGA is focused on more fine grain access entitlements. And these have to take things, things into consideration, like the identity, the membership of specific groups, roles and things like segregation of duties, controls, all these things are highly complex and are very difficult to build or recreate in.
I TSM. So in other words, the granularity required by IGA is simply not available in I TSM IGA then built within I TSM will inevitably lack things like automatic deprovisioning, which could be problematic.
I mean, this is something that if it's done properly and taken care of, there is not that, that security risk of people having access rights way beyond the time that they should. But if you're building something in, I T SM it, it wouldn't automatically happen. And unless it's specifically built, which could be challenging, it won't, it won't be taken care of. There won't be complete audit trails, which is also extremely important to be able to track who's doing what and when, and sometimes why there won't be effective data protection and there won't be security and privacy enforcement.
So now, if you looked at all these things that potentially won't be included in, I T SM they, they're very important because in this day and age with, with cyber attacks, increasingly a problem for just about every organization you need to have be on top of who is accessing what and where, and when, because most attacks we, we have seen are originated by hijacking people's identities.
So everything around identity provisioning and control and access control needs to be that step better than in the past, because this is the main way attackers are getting into, into systems.
So all these things are highly important aspects of IGA and need to be taken care of. And the other thing of course, is that we are seeing all around the world, emerging data protection regulation, and so organizations who are not able to, to provide complete audit trails and effective data protection and so on, could run into problems with complying with these data protection regulations. So for those two big reasons, it's a good idea not to not to do run the risk of, of building something that's not gonna deliver on those things.
So the bottom line here is IGA built in, I T SM by end user organizations typically lacks the depth functionality and the security of a dedicated IGA system.
Moving on to principle. Number three, use I an I TSM Porwal as a single point of entry. So while it's, Inad advisable to use, I T SM as a front end to IGA systems using custom code that is difficult and expensive to maintain an I TSM Porwal could be a common way of accessing all the services. And this is an important idea because it satisfies one of those business needs that we mentioned in the beginning of the user experience.
And I think also experiences come up a couple of times earlier today through through the presentations, it's provides a familiar way for employees to access the services. They've got a single Porwal to go through. They don't have to say, well, is this an I TSM request? Is this an IGA request? Where do I need to go with this?
So it, it removes all that complexity makes it easier, makes it more convenient.
So if you do it this way, an I TSM request will trigger an I TSM workflow as normal.
However, when the employee comes with an IGA request, they can go through the same Porwal, but the request should link to an IGA Porwal with the same look and feel as the I TSM Porwal. And that will trigger a workflow in IGA systems. And so a request that involves both I T SM and IGA components will trigger workflows in both I T SM and IGA systems. So the result is that an IGA request is handled within IGA system with all the necessary safeguards.
So now, if we look at the diagram, you can see how that works. The services made in the I, the, the employee comes to the, I T SM Porwal makes the service request, but if it's for IGA, it goes through to the IGA Porwal and it feels like the same thing. And the workflow gets triggered in the IGA. The important thing here is that the IGA processes are, are done securely and compliantly and are done within the IGA system. And then there's the feedback loop to, to the I TSM.
And you have that, that feeling for the end user, that it's all happened, but in the background, other things are being going on that are not, are not that obvious to the end user. It just happens automatically in the background. And we think that's a really important point.
The next principle that we want to discuss is integrate when and where necessary. So while it's important to keep I T SM and IGA systems separate, there are times when integration may be necessary. For example, when manual fulfillment is needed. And perhaps I should say, particularly when manual fulfillment is needed.
And this is a point that Martin Kuppinger made several times in his keynote presentation earlier today. It's really important for all manual fulfillment to go through an ITM system so that there is a way of keeping track on it.
You know, what the status of the request is and so on. So if we look at an example, requesting access rights to an application, not connected to an IGA system, this has to be assigned manually by an administrator. So we think that the best approach is to integrate IGA provisioning with I T S M to ensure that the access request goes through the IGA system, which acts as a single point of control.
So this is another important I idea is that all IGA requests must go through the IGA system so that there is that necessary oversight with all the safeguards to enable the provisioning of access rights to an unconnected system, an I T SM ticket could also be raised and issued to the administrator. So, and then the I T SM system sends the updates with the change requests back to IGA for audit and governance checks. So if we look at the diagram, we can see how that flow would work.
And again, we can see that I TSM is taking care of the service side of things that the, the, the service management is taken care of because as we've been discussing, I T is designed for that very thing to take care of the workflow around I TSM, and to, to do the service managing. And in this case, the service is IGA, but at the same time, IGA is the, is the single point of control around the IGA services.
And there is the feedback loop and to make sure that there is sufficient audit and governance checks.
Another example is for example, password resets, where the IGA system lacks functionality such as access reviews. So again, organizations should not be tempted to attempt to implement access review functionality within the I T SM the best approach we believe is to integrate with a specialized access review system and initiate access reviews by raising a ticket for the access review system.
So again, you can see in the diagram how the ticket is raised and then sent through for the manual performance side of things. Then the thing to remember when approaching it this way is that wherever ticketing is used, and we think it's important to use ticketing for all manual processes. It's essential that the ticketing system is integrated to auditing, to ensure proper audit Contra and audit trail, and that's for all manual activities.
So hopefully that's all clear to you. And then we'll go onto the file principle, which is IGA and I, TSM teams must work in tandem.
So the best way to achieve alignment between I TSM and IGA processes is by encouraging teams responsible for those functions to work together. And one way of doing that is by setting up regular meetings between I T SM and IGA teams to discuss things like interfaces, responsibilities, and accountability. And this is something that I've seen in business continuity management and cybersecurity, where these two teams tend to work in silos, but if they work together, there is better synchronization between the two.
And in terms of technology investments and processes, both teams are working in the same direction. So we need to achieve the same thing for IGA and I T SM teams because by defining things in tandem, it will ensure that processes and policies are aligned and it'll promote better understanding between these two groups, excuse me. So the result is that IGA systems are kept as separate as possible, but integrations are identified when and where necessary.
So now, now we can just summarize what we've been talking about. I guess one of the key principles is avoid building your own IGA functionality within the I TSM. And the other one is align. I TSM systems through greater collaboration between I TSM and IGA teams. And the results of that will be ensuring better consistency in processes and policies, which is really important. It'll be easier to keep systems largely separate, which is what we're aiming to do so that each one can do its specialized functionality.
And it enables efficient integration where necessary, how it's a better user experience, but at the same time, it minimizes security and compliance risk. And just again, to recap on the five, five key principles use the right tool for the job, do not build IGA tools within I TSM use the, I TSM Porwal for the common point of entry and use integrations when and where necessary many IGA tools come with preconfigured integration to major ITM solutions, plus APIs for custom integration to others. So there's really no excuse for not doing integrations when necessary.
And then finally develop I T SM and IGA processes in tandem for better alignment. So in closing, the watch words are align and integrate. And the goal of aligning I T SM and IGA is to automate when possible and evaluate risk when necessary. And with that, it's back to you, Annie,
