Redefining Application Governance: How Munich Re Unites IAM Strategy and Application Onboarding for the Next Era of IGA [Intermediate]

Thank you for the opportunity. This is going to be more an overview of what we are planning to do, so if you have any questions, please feel free to ask. Just to give you an idea of who we are, Munich Re as a company, and then we move on to the initial approach, how we started, and what are the challenges we faced, and the target picture, what we want to achieve, and then how we managed to start the journey.

So we started the journey yesterday, so now we are going forward, and I hope I can give you a better feeling how we are proceeding next year or year after, and expected benefits at the end of the day. So Munich Re is one of the largest reinsurance companies, and we are a huge global footprint. We have like 50-plus global footprint with 43,000 or 44,000 employees in the group in the reinsurance segment alone.

And the primary insurance, we have another 35,000-something, and we do special insurances for rocket launches and cyberattacks and renewable energies, so we are having a history of 145-plus years. So it's mostly reinsurance, it's not very sexy, it's always in the behind the back. We are insurance for the insurance you hear about. So we work in three different segments. One is the reinsurance, as I already told you, like we have New Re, Munich Re, as such, in general. And then you have primary insurance, Group belongs to us. And then asset management is MIAC.

Today I'm going to talk about Munich Re as reinsurance and asset management. And primary insurance, we are in the process of consolidating it together. So right now, that 43,000 what I mentioned about is Munich Re segment alone. So as you know, Munich Re is a financial services company, which means like it's highly regulated. Buffering regulation is always there. So we also have a banking license, therefore, which means like VIT and KIT is applicable for us. Now it's DORA. So it's now, instead of multiple things, we have DORA in general one.

Since we have 50-plus global footprint, we have to work with all the regulators across the globe, especially Singapore. Mass is absolutely amazing. They have a stronger regulatory requirements and you have APRA in Australia.

In US, you have individual states have their own regulatory requirements. So we have to make sure that everything is taken into consideration. DORA is for the Europe very important.

Therefore, we took all the regulatory requirements. We took the minimum, what is the maximum requirement we need to satisfy, and then we defined internal guidelines. And these guidelines, we now broke it down to six different segments. Identity management, access management, privilege access management, authentication, segregation of duties, and recertification reconciliation. So it's not, it's very straightforward, not so sexy. It's everybody knows it.

I mean, so I don't want to go in detail, but today I'm going to talk about application because identity is already done. It's automated. It's well done in our case. So I'm happy to confirm that. The application is a little bit tricky part because it involves many connectors. So you don't, you need to make sure that there are governance piece into it. And then you have to also make sure everything is properly documented and imported into the IGA so that the proper approval workflow works out and you need to understand what entitlement is for what. So the previous presentation was amazing.

I think this is something we would like to also think about in future. So what we need in general, the first thing we need is a central repository of all the business applications, which is easy said than done. We have two repositories. One we call, one is the LenaX one, which is basically where we document all the application information. When it is a proof of concept, projects, whatever it is, if you are going to use it in the Munigree infrastructure, it should be documented there. The second one is the CMDB.

If it goes into production, if it's something we need to maintain it for the BCM, DRP, it should be in CMDB. So this is first rule we stick to. It's an organizational control and then we strictly implement it. The second piece is application governance workplace, where we have to take care of the authorization concept documentation. Anything documentation, Word document is always a mess because paper is very patient than any technical controls. So in this case, we do have to keep it. At the same time, it should be consistent with what we have technically implemented.

So that's the more important, more biggest pain point we have. So the authorization concept, then you have to talk about the user access rights and other technical documentation.

Basically, if you are talking about a solution design document, you have the same architecture repeating in multiple documents. So you don't have to, if you have a proper set of controls in place, you don't have to do it multiple times, you just reference it. But it is important, even though it is boring, it's not sexy, but you should do it. The last but not least is a technical one. It's basically at the end of the day, it should be technically onboarded and then it should reflect what it has been described in the documentation.

And we should also make sure what has been onboarded is also reconciled. So make sure that the IAM is the single source of information for everything. So initial approach. So we said, OK, we have to do this. That's the idea.

We start, I just give you a very brief idea of where we come from because we have too much history behind it. So it's not too long, but nevertheless, in the IAM field, it is like really a long, long ago. It's almost like 13 years we've been actively using IAM and we started off with the SAP systems. And then we started off, we created a template and then we, since 2019, after the Buffin audit, we said, OK, we have to do it now. We cannot postpone it anymore. So we pulled our socks and made everybody follow the requirements. So challenges.

So as I said, the three major block, it's easy said than done. What we realized is every month we have like 15 onboarding, 15 offboarding is what we require minimum. And in some cases it's 25, 25. And now with Ergo coming in, we will end up having like 50 onboarding, 50 to 60 onboarding per month, plus 30 to 40 offboarding. So it's going to be a challenge. For Munigree alone, we have around 1,500 applications, active applications we are using. The documentation is a bigger, bigger headache because anything we, when we start documenting, we have an idea that it should be like this.

It's always a wish that it should be like this. But when we start implementing in the system, then we say, OK, we make compromises. And then what is implemented in the system is different from what has been documented.

Therefore, there's a pure mismatch between documentation and the technical onboarding. So we have to do some input validation. It's error prone because of the human error. They do the mistypes. And they also have no version controls. So it's very, very messed up. So that's a bigger challenge we have. The last but not, not the last, but the second, the third one is basically the biggest pain point I have is because the technical onboarding also depends on an Excel document where we actually say what entitlements, which approval groups, and all kind of things are all documented in Excel sheet.

And then we create a service request to a technical team and they say, OK, this is what they want. We will do it manually. So there's a lot of room for error. And by doing this, we also need to make sure that everything is approved at each stage. So it's not done just somebody requests, somebody does it. It should be approved by the respective application owners and also the IT responsible people. So every application has four people assigned to them. One is the business product owner who is responsible for the application. This is already defined at the beginning.

He or she is the one who will take the risk, whatever happens, whatever is done with this application. The second one is the IT responsible person who will do all the technical aspects of the application in consultation with the BPO.

The BPO, I mean business product owner. The third one is an enterprise architect who is responsible for the architecture part, which is a strategic one, also for the tactical one. The fourth one is the IT management, so with whom we escalate if there is some problem. And you can actually add all the product members and everything if required. It's fine. But these four people are always there. And based on this, they have to always approve at each step. So right now we do it through ServiceNow tickets, which is not the best way, but this is what we do so that we are still compliant.

But in the future, we are going to change. So that's something I'm going to explain. And since we are a large company, even though we say three segments, we have more than 300 plus subsidiaries and companies across the globe, which is a lot of changes every time. Every month, every second month, we have some organizational changes. This has to be reflected in the IAM. So therefore, everything needs to be updated and regularly changed.

So Linux, generally every day I do update, which means like it's an automated script which runs and it checks every day. I see minimum of 60 changes every day, just to give you a feel how dynamic it is with us. So target picture is basically how we want to do it. We need to standardize it. We don't want kind of manual interference in it. If you start with it, it goes through everything in a sequence. We don't want to do any kind of manual work involved. It should be end-to-end integration. It should also enable the business user.

So far, it's a lot of manual work. They get very frustrated. At the end of the day, the business is more for the functional requirement. It should do what it's meant for. They don't worry about the security aspects or they don't worry about the business community topic. They want to make sure that it works and it should do what it is intended to do. And we as IT should be an invisible person behind and we should enable them. So therefore, it should be also very professional. We cannot also say, hey, it's too much, we can't help it, and we should support them in a more professional way.

So what we did is we now have a very, we decided first the IGA is one identity. So SailPoint is with the Ergo. So it will be consolidated to one IGA, which is one identity. We now are glad to partner with Nexus for the governance piece. So we are happy that we finally signed the contract and we started to work with them. They will be the key part for this end-to-end process. So what we did is, so Linax is our inventory where we actually do the complete documentation of all the application with the roles and responsibilities clearly defined.

And every day we pull the data from Linax, put it in the Nexus, and Nexus creates wherever there is manual work to be done. There are certain criteria, we define certain criteria. If the certain criteria doesn't meet, manual work has to be done. It creates automatically a ticket in Azure DevOps. And then we pick it up on a team. We have a small team of five to 10 people. And they pick it up and say, okay, this is a ticket I received today. I will put it in my backlog. They have a week's time to respond and we proceed in this direction.

If it is, in some cases, it requires a technical change or a technical requirement, then it also creates a ServiceNow ticket automatically. So basically that's also defined in the rule set. We want to have it in Nexus.

So Linax, we put it in data so it does an everyday thing. And then we create the ticket. It also creates both Azure DevOps ticket or ServiceNow ticket, depending on what kind of action has to be done. And if everything is done, also then we do the entitlement design and management in the Nexus. And then once it is done with approval from the ITPM and BPO, we should publish it to the One Identity Manager. So basically that's one of the key reasons why we also prefer Nexus because they have out-of-the-box connected to the One Identity and SailPoint.

And once it is published, there is another check where we say if everything is done, if it is tested, then you have to do a declaration that they will fulfill all the requirements we have as a company. They have to undersign. The last but not least, they also have to activate reconciliation because at the end of the day, what we realize is we start with the onboarding and we forget about the reconciliation. Reconciliation is the last step we should activate. So that's basically the overarching flow.

And on a daily basis, we also push the data to the Azure Data Factory together with the information from the IGA to the Azure Data Factory to do the KPI monitoring and reporting. So these are steps basically. Whatever I explained to you in the previous slide, I just put it in a more readable fashion. But most of the cases, we need to follow each every step. We cannot skip any of them. If there's an exception, we still have to do an exception and compliant, non-compliant approvals by the BPO and ITPM. Without these two, you cannot move to the next one.

We also have roles and responsibilities defined. So it's clearly defined and it's been published together with the guideline and work instruction. So everybody who works with us needs to adhere to this one. And that's basically how we start off. We start off with the user awareness because the biggest problem we also have is user acceptance. So since we are moving from a very traditional way to a modern way of doing things, we are traditionally a reinsurance company. We are not a technology company, but we are moving towards this direction.

And to make them understand what they are doing, what we are doing, why we are doing it and how we are doing it is very difficult. So we are starting off with awareness. With awareness, we also tell them, hey, you are in the driver's seat. We are just enabling you. We are not reinventing the wheel. So please do it because that way you don't have to worry about any of the regulator issues. So that's basically what we start off with. And then we do Q&A sessions on a weekly basis. We try to educate a new manager when I come in.

Or we also do sessions with people who don't understand what we are doing and how we are doing it. And it's a larger problem we have because IAM is a very technical topic. Not many people understand it. So that's where we are struggling with in the beginning. But I hope at some point with some initial initiative, we will get there where people start to accept it, what we are doing. And with AI, it's also a boon in disguise at the same time a problem for us in the future because that's also a topic of non-human identities which we'll have to tackle in the future.

So I have one slide which is not displayed. But OK, basically, the reason why we also have Nexus as a key topic is it has an end-to-end scenario. We start off the ITPM and PPO, start off with the registration, and then it goes till the end. So until it's onboarded and reviewed and signed off, we have an end-to-end chain there. And that's something which we were looking for. And it also has the AI capability involved which actually helps us to improve the quality of description of the entitlements, also to help the user what they are doing is right or not.

So basically, that's my presentation today. You're welcome to ask me any question if you have two minutes. I didn't want to rush it through. But if you have any questions, please feel free. Thank you very much, first of all. I do not have any questions on my tablet. Are there any questions in the room to use the two minutes?

Otherwise, I do ask a question. No question. Do we apply any kind of clustering for the application so that you onboard or migrate separate types or clusters of applications at once? So we don't cluster it. The problem is each and every application is different. The entitlement, the granularity of the entitlements is also different. So it depends on the business owner and the ITPM who decides on this. We let them have the complete freedom to decide on it. We only consult them. So it's also important that we onboard it as per their wish rather than we say they have to do it this way.

We are already forcing them to do things which is not part of their core business. So therefore, we are letting them give some freedom to do this by themselves. So there is no clustering happening here, unfortunately.

Okay, great. Thank you very much. And I distanced myself from this not being sexy. It was because this works and it really looks good. Thank you very much. Thank you.