Digital Sovereignty: The IAM Risk Nobody Budgets For

Welcome everybody and thanks for joining this webinar about Digital Sovereignty, the IAM Risk Nobody Budgets For. My name is Reiner Mertens, I'm Lead Advisor at KuppingerCole, and with me is Christopher Schütze, our Chief of Advisory and CISO. Today we will talk about why digital sovereignty matters for your business, and we will structure that into three parts. So decide what needs sovereignty, enforce it when you select products, and sustain it over time.

With this, I want to hand over to my colleague, Christopher, for the housekeeping. Welcome, also from my side.

Thanks, Reiner, for kicking the webinar off. For the typical, well-experienced KuppingerCole webinar participants, this slide is not you. For the other ones, four things before we start. So you are centrally muted, there is no need to hunt for the mute or unmute button. If you have any questions, you can go to the right panel in the Livestorm app and answer your questions anytime. We can see this on screen, there's also some kind of voting mechanism if we have many questions.

And also, we will have two short pauses within this webinar and discuss, as always, the results at the end as well. But for sure, you can see in real time the answers. But I think the most interesting part is talking about that.

For sure, you will also get the recording and the slides by the end of today or beginning of the next day. And that is basically the starting point for today's webinar.

So, slide number three. Perfect. Last Tuesday, so the 21st of October, you might have realized that in the Internet, many websites didn't work as expected. We had Germany's Federal IT Service Provider, we had Dutch Cyber Security Center, something in Finland, Belgium, Czech Republic. But nobody reported a breach in that case. They switched themselves off as a precaution. And that was because of a critical flaw in PHP. More or less 70% of the viewable Internet you use is working with that language. Keep that in your mind for this webinar.

And going back one year and one day earlier, 20th of October in 2025, we had a DNS problem in a single AWS region. For hours, users of many, many software as a service providers couldn't log in. And the applications behind that login are still running somehow. The data was there, but people just could not get in. Someone had lost the only key to the front door.

So, here's the question for the rest of the webinar. If your identity provider went dark tomorrow, or your identity access management vendor, any of them, got acquired or dropped your product line, how long until your business stops? Are we talking about hours, days, or the truth? You don't know 100%. Because whoever controls authentication controls access. No matter if your data is sitting in Frankfurt or somewhere else. If the login is controlled from somewhere else, so is the key. And most organizations treat this as an IT problem. And we think that's more a decision.

So, let's jump into the agenda. As mentioned, digital sovereignty is a risk decision. And that's our core message for today. You enforce it when you buy, and you keep it alive through architecture and operations. And this gives us mainly the three parts we will talk and utilize as an agenda for today. The first one is decide. I will talk about regulation and the dependencies that can cut you off. Rainer will talk in the second part about how to ask vendors questions they don't want to answer on that level. And in the sustain part, what happens after the contract is signed.

And for sure, as mentioned, we will discuss at the end about your questions, ideas of how to solve that, and things how to start. And now we can jump into the first poll. A very interesting one, and I mentioned that at the beginning. If your primary identity and access management provider is for now unavailable for the next 72 hours, do you have a tested plan? We are talking about more than one weekend. And one hint from someone who does business continuity management and things like that every day. If this plan you have written down somewhere never tested, that's a hypothesis.

Just a beautiful document that doesn't work. 100% maybe. As mentioned, we will discuss this at the end, and now can jump into part one, talking about decide. So sovereignty doesn't start with a vendor list. It starts with a risk decision. So which identity functions must never fail, and which must never be reachable from outside our jurisdiction. And then we talk about that not all identity and access management is equally critical. And that's the key point of this slide. The first one is talking about access management SSO and MFA. This is really a critical thing.

If this goes, everything integrated in applications, you're locked out. That was exactly the example I mentioned at the beginning. If you think for consumer identity and access management, if the consumers can't log in, imagine Black Friday, financial industry or something before Christmas. That's revenue stopping in real time if it's not working. And in privileged access management, there's one thing people forget. That's your break glass account. And you need something for break glass exactly when everything else is broken.

And a privileged access management that only works when the cloud works. You can phrase this as a fire extinguisher that only works when there's no fire. And then it's basically useless. Another thing is identity governance and administration.

So, revenues can pause. Requests can go manual as we did or some companies still do in the past. But not for months, not for days. And it really depends whether it's first of January, end of year, or somehow middle of the month.

And still, a lever who isn't deprovisioned is a real risk. But just a bit more quiet than the other ones. The next slide is talking about three dependencies that you can cut off from your identity. The first one is unavailability. We know the technical versions.

So, AWS, Azure, Cloudflare, all have had a bad day. And identity went down with everything else.

Last week, the example I mentioned, switching yourself off because of staying online is the biggest risk. And as always, there's a commercial version. Nobody puts in a risk, which is in that case. We've seen the polite letter in practice. You pay substantially more or the service ends in X month. Perfect uptime and you're cut off by a spreadsheet.

So, that is a real thing here. The second one is the jurisdiction.

So, for instance, let's use the US Cloud Act. It can reach identity data that is hosted in the European Union. Because it asks who has possession, custody, or control, not where the server stands. We will see some more details about that later. And the third one is talking about vendor business events. Like acquisition, consolidated product lines, maybe also new licensing models. That's simply how the identity market works. But your identity and access management roadmap is now part of someone else's integration plan. And each of these dependencies has a price at the end. And next slide.

Pricing. Ask your chief financial officer where the entry is of leading our identity provider.

So, in enterprise risk management, there isn't usually one. But you must consider those four numbers and topics here on that slide. The first one is accident migration. If you leave or move your identities to another platform, there is a gap of knowledge if something was built in 2019. We all know documentation is sometimes lacking. That's a thing and that's expensive. You might need some kind of free engineering. The second one is if you have the case that you leave your identity provider, you need to have a second system in parallel. Because it's nothing you can do within one weekend.

Maybe considering some AI fancy stuff in the background, still we are talking about weeks or months. And another kind of expenses that are relevant here is the self-operation. Coming back to this PHP stuff, you are responsible. All that stuff we decided 5 to 10 to 15 years ago, let's go into cloud or self-managed stuff is now going back. We have those 3 a.m. calls. And we need to have disaster recovery and all that stuff again.

And also, this was one of the things mentioned. It was the previous slide. The expenses. If you have a single day without your consumer identity access management, and if you are working in retail, ask your head of e-commerce what the costs are for one day not being accessible. As mentioned, like Black Friday or things like that. We are talking about a huge amount of money here.

And so, you have a huge level of costs in dependencies. And this is very often not very visible within this organization.

So, let's look how regulations are dealing with that. We have DORA in place if you are in a financial industry. It describes if your IDP is down, one of your critical functions is down. And that meaning says that you must have some kind of exit strategy. And you have some kind of concentration risk.

So, you need to do something. That's what they say. But you can deal with that on a certain level. And just having a contract and some kind of entry.

Okay, my key is there. The risk is not sufficient. If we have a look at the NIS2. Traditional Identity Access Management Provider is a supply chain dependency. And you need to have a management of that. Then we have the Data Act. It is January 27.

So, 11 weeks, 10 weeks. Cloud providers are not allowed for specific charging fees. What you can take with you or not.

So, you need to have mechanisms for user configuration. But the credentials, that's another thing. We started to transform or still ongoing everything into direction of pass keys. And that's a good point. Do you really own the pass key or not? Is it registered to your provider or to your local domain? And what happens if the provider is not there anymore?

So, this is something you need to consider here. And then for sure we have GDPR as well. That is not directly paying into that topic.

So, none of these four regulations or five. It just raises the bar for showing control on a certain level. And the Identity Access Management implications here are more or less not concrete written down. Especially around DORA, things like that.

So, the question is. Okay, we have ESO, we have TSACs and all that other stuff. Is there some kind of certification that can solve that? And many people hope for some kind of sovereignty label on the next slide. But I have to disappoint here. There are many ideas but nothing concrete out there right now.

So, the European Cyber Security Certification Scheme for Cloud Services is more or less stopped regarding the sovereignty level. This was more in the beginning of 2024. We have the Cyber Security Act. Also ongoing but doesn't dive deeper into this sovereignty level. Then we have two proposals. We have the CADA and the Public Procurement Act. Also on or both of them are on proposal level. But not really solving or not specifically solving enough what you want to have.

Okay, I want to be sovereign. I want to take care of my stuff. And that is not dealt with here.

So, for you participating in this webinar. The first quick win written down here. We will have three of them during the webinar. For the next week, assess your stack. Classify your identity and access management components by criticality. And ask who operates it. Who holds the keys? Could I exit and leave it? If you can't answer, especially the last one in a sentence. You found your first project for the next month or years in the worst case. You can also participate on our website. The reference architecture with the building blocks and the descriptions. To structure a bit.

Is this important and not? And how to figure out. Do I have the sovereignty about this kind of service or not? And with that, I would like to hand over to Rainer. Thank you very much, Christopher.

Yes, so now that we decided where sovereignty actually matters. The next question is how to enforce what matters to you when you choose a product. Either when you are setting up a new solution for your identity management. Access management or custom identity and access management. Or if you try to modernize things. Or once you have done your research.

Find out, okay, I need an exit strategy. And maybe that might also then involve choosing a new product.

So, let's look at how sovereignty then fits into selection criteria for such products. So, sovereignty is only one way to glance. It's not a veto by definition.

So, functionality is one important lens. You need to understand that the product needs to cover the required use cases.

Of course, suitability is an important lens. Where you need to look into industry and integration. And that the scaling fits to your environment.

So, it makes a difference if you need an access management solution. More like for a mid-sized company. Or if you need that for a large enterprise company. It also depends on the number of identities you need to manage there.

Of course, you also look into quality. Which means looking into security, maturity, the reliability of your vendor. And the vendor support as such. And then finally, we have the sometimes overseen sovereignty here.

So, what are the legal requirements you have there? How is your data treated? How is the operation and model? How does the supply chain actually look out? And this is not by definition a knockout criteria. It really depends on what you define yourself. What kind of sovereignty level you actually want or need to achieve. For your company and organization. And that often is different for, for example, public sector companies. Than it is for that kind of private owned businesses. Or normal industry organizations in that area.

So, it is a deliberate decision then. Derived from your classification and your risk assessment. Which we have discussed in our first Act 1. Which was about Decide.

So, a product that supports digital sovereignty. But doesn't fit your functionality. And doesn't suit your business at all. In the end is no solution at all.

So, even if you have all the digital sovereignty checked there. But it doesn't fit your functionality and suitability. It can't be a good choice there.

So, why does sovereignty need its own lens at all? And what does the law or the US regulations actually say about that? In the end, US law reaches your data wherever a US company controls it.

So, control in the end about your data. So, holding the keys to your data beats the location. No matter if that is on a software as a service from a US vendor. If that is on a EU software as a service. On a US hyperscaler such as AWS, for example. Or if that is a software run on premise with your own keys. And if you look through the table here. We have done our best to give some indication. And that is our company cold assessment here. How much data access exposure you have based on. For example, the cloud act here. And of course, for the first line. The software as a service from a US vendor.

That is the highest risk. So, certainly they have the permission then to access your data. Which you have stored in the software as a service. Which you are buying from that US vendor. Still you have remaining risk like operations.

Updates, the terms of service. And this famous kill switch everybody is talking about.

So, what happens if Mr. Trump decides to ask Microsoft. To simply stop Microsoft Office 365 operating in Europe. I think then we all have a real problem here. When you then look at EU software as a service providers.

So, the software is provided by a vendor. Who is located in the European Union. But it is operated on a US hyperscaler. Then I think the data access exposure is probably medium. And it really depends on who holds the keys. Then the infrastructure layer is the way to access the data. It will not go through the software as a service. But who stops then someone from this US hyperscaler. To access the data in your database for example. If you have the keys for this. And it is finally encrypted. Everything is fine and then the access risk is medium. If not low in the end.

Then looking at US software running on premise with your own keys. I think we are then already somewhat in the safe space.

So, the risk that this data gets accessed by someone else is quite low. And the lowest is then obviously when you run open source software. Or software from a European Union vendor. Which then finally runs on premise.

So, the operating model and who is holding the key. Actually decides the risk allocation exposure. More than where the data is actually hosted or where the vendor is headquartered.

So, it might be perfectly okay to buy software from a US vendor. And then run it on premise with your own keys.

So, that nobody else has access to that. So, how do you measure then the sovereignty of a certain tender in your selection process. In your RFPs. And the European Union already has a method to actually do that. Which I will try to give you some idea of on the next slide.

So, as we already heard from Christopher. There is at the moment no binding regulation requirement. Or something in place from the European Union. Which asks you to follow a certain framework or something. But what we have seen is that at least two frameworks are quite used already. And seems to involve into a kind of binding standard. At least for public sector organizations in the future. One of them is the European Union Cloud Sovereignty Framework. Which is talking about the so called sea levels. And the sovereignty objectives in that place. And they have eight of them.

Which you can see on the right hand side. So, there are strategic aspects, legal aspects, data and artificial intelligence. There is operational aspects of course. There is supply chain, technology, security compliance and environmental environments. And the interesting thing is that the highest number or the highest weight in this framework here. Has the supply chain.

So, where is this software coming from? Who has access to this? How is the update process running? Who is developing the software? Who has access to the source code during update processes and maintenance here? And it works in a way that there is a gate first.

So, you need to reach a certain sovereignty level per the objective or category here. And then there is an overall ranking of all of them. Based on the weight which we have seen here on the right hand side. Which then provides the overall sovereignty level. I think there are four out of them. There is sea level 0 to 4. Which also are kind of a one by one mapping to the CADA levels. Which some of you might know here.

So, but the score is only as good as the answer. So, if you then answer a vendor.

Okay, how good are you at these answers here? They probably come back with certain, I don't know, certifications or self-assessments. Or they simply have some kind of labels or badges on their product. And there is then one thing which we would explain to that.

So, evidence in this case beats badges. And we ask you to simply stop trusting the labels.

So, what vendors sometimes claim and what then the reality actually turns out to be. Might be quite different. And we have a couple of examples here. Which is based on our experience in an advisory. Especially when we support tool selection processes. For example, or if we are going into proof of concepts. Then together with customers. And also what we see of course in our leadership compasses.

So, for example, when the vendor claims. Okay, of course we support on-premises deployment options. You might find out that they basically support it. But if you then look into the number of on-premises installations in the last 12 months. We'll find out that there is almost no installation at all. Or maybe just a handful compared to hundreds of installations. Maybe based on their software as a service. And you then can question yourself. Whether this deployment option really is a deployment option. Or if you should shy away from this vendor then.

If you need on-premises support for your product. Same turns out to be okay. What does enterprise ready mean? You need to have reference customers then in place. And running the same operating model. Like in your region and your sector. To actually really make yourself a picture. What enterprise ready means. Also when we look into full feature sets. We found out that especially when you look on on-premise installations. And then compare this to software as a service installations. We see a lot that these are not feature complete. Or do not support the same features.

So what we see a lot is that software as a services. Let's say kind of features are ahead. Of what is actually available on-premises then. And that might turn into a problem. If you are looking into an on-premises option here. Also interesting enough. I thought it was not a question anymore. But if you have license checks or telemetry. And updates which need internet access. From your production environment. And they avoid it. And it says then the software runs air-gapped. You need to carefully look what that really means. So does it mean you just need that when you want to do an update.

Does it mean it checks the license every time it boots up. And starts the software. So what does it mean running air-gapped here. Another interesting topic is then obviously something like. I am ISO whatever certified. Or they do some kind of a self-assessment. And name this then to be certified. You really need to be carefully looking into the certification scope. And one thing also that means. When it comes to cloud to digital sovereignty. Sometimes I hear then okay. Yeah we have a C5 at the station. But that means you have security controls in place. For your cloud solution here.

Which does not mean that your digital sovereignty requirements. Are finally met. Also when we talk about supported. It could mean very different things. I mean if you look into okay. Maybe it is natively supported. There might be a connector. Maybe you can configure that through an API here. Maybe you need professional services to do that. And they just claim yeah of course we can do that. And sometimes you even have third-party products. In your locking chain for example. For identity verification. And you need to ask yourself then okay. Do I really want that.

And how reliable is this third-party service then. Which is bound into that process. So in the end. Ask for proof on the operating model. You will then finally actually run. And to support this. We have some lessons learned for you. From an actual anonymized project. Where we have done some more deeper analysis. Of the B2B EIM market. The B2B EIM market in Kumpinga Coal. Is a new market element or segment. Where we also have a leadership compass for. Which has been derived from the SIAM market actually. And is pointing to products. Which support like.

Kind of identity governance administration features. Like recertification and additional approvals. And things like this. Combined with typical. Custom identity access management features. Where a large scaling for example is important. And you need to talk about. You need to talk about the. You need to ask the customers to actually. Comply to using your data to consent. And so on and so forth. And what we have seen is that then. Sovereignty requirements. Can really change the shortlist. So in that following project. We have seen that if you look into the B2B EIM market.

And you have decided that you want. Non-premise deployment options. That the leadership compass. Leaders quadrant is not necessarily. Then on the shortlist right. Because they also need to provide. Proven based on evidence. That they can run on-premises then. And that significantly. Has then changed the. The shortlist here. Also then as I already mentioned. On-premises is not the norm anymore. So what we have really seen is that. A lot of I think would say. Basically maybe 50%. Provide software as a services. Solutions or deployment options only. They do not longer provide.

On-premises options in that area. While at the same time. We see an increasing. Request or increasing. Number of companies. Especially in the public sector. Asking for on-premises options. Rather than software as a service options. Also the certain dependencies. Which I have also described on the other slides. Like license checks, telemetry and support access. Can then also already. Have an impact. On the shortlist. However that really is sometimes. Something which you will not find out. Based on information from. The leadership compass for example.

This is really something where you need to ask. For evidence and some explanations. From your vendor. So in the end. That means really. The criterias are based on capabilities. And weighted with the scoring. Like the seal. Or the cloud sovereignty framework. From the European Union. And you need to explicitly. Must have or define the knockout criterias. If you have one based on the digital. Sovereignty. So the quick one then. Out of this for you is. Put evidence-based sovereignty questions. Into your next request for proposal. Or the contract renewal in the end. To make sure that you have.

This exit path. And also to make sure that you really understand. Who holds the keys to your data. And what happens. If business events. Shift the market around. Or if crazy. Presidents in the United States. Do crazy decisions. With that. We can then switch to the final chapter. Of this presentation which is. Even if you then have decided. For a certain vendor. Or you have renewed your platform or whatever. You need to maintain. Your digital sovereignty. And take a look into. Login and resilience. Of your solution. And what that means is. Sovereignty wears away after the contract.

So there are kind of hidden. Dependencies and also then. Especially business events. Which might really change the picture. Over time. So acquisitions or licensing changes. Can really change the picture at any time. And we have seen that. Over time. And already years ago. The kind of wave. Of acquisitions and mergers. Started and we still see. A lot of mergers and acquisitions. And also consolidation. In the market. So our advice is to check. And selection and do this every year. So check on the licenses. Check what happens if updates. Change the methodology here.

You need to look into telemetry. What happens to the vendor support. So they might decide to. Stop the vendor support from Germany. Or the European Union. And provide just from India. The support. And you always need to check the update path. In isolated environments. And look into third party services. Especially if they are integrated. Into your login flows. Like identity verification. Risk scoring or push notifications. Via SMS for example. And then finally. Our advice really is to contract the exit. So really make sure. That data and configuration exports. Are available in usable formats.

For example. Think about asking for exit support. So migration help. At agreed rates. Or making sure that this exit support. Is available. Even if they stop a certain project. Or if this vendor has been. Acquired by another company. I think notice periods. Then are also very important. I mean if they just tell you in four weeks. Things will dramatically change. Then you basically have no time. To do something right. So you want to know that. Maybe three months or even six months. Before something changes here. And sometimes then also the right. To keep things running. Also without updates.

Is also important. So recheck dependencies. Every year and contract for the exit. Before you actually really need that. Also Christopher already said that. And with that. Christopher also has one final. Thought for you about. Sovereignty without resilience. Unmute is important. So let's have a look at this. Matrix here it shows. Resilience and sovereignty. And the. Top left. Level is resilient. But dependent. And that's many of us. Today on the big. Software as a service platform. What we really. Don't want to have is. Bottom right. And bottom left. Bottom right is more or less a trap.

We are sovereign but fragile. Good example is. Also you've written down on the right side. South Korea. 2025. They had some kind of fire. In their sovereign data center. It took down. Almost 700. Services for the government. And they lost almost 900. Terabytes of data. And as they haven't had a second site. No backup. They are sovereign. And lost 900. Terabytes of data. Congratulations. And the target level. We want to achieve for sure is. Top right corner. So maximum level of resilience. And the maximum level of sovereignty. But on the other hand. This brings back all the responsibility.

Of testing the resilience. Of our plan B. I mean. You can basically go. Through a risk based approach. You need to ensure. That your most critical assets. Are accessible. Via a fallback IEP. For instance. You run this by yourself. You don't put it on one of those two hyperscalers. You put it somewhere else. But you need to test that. You need to patch that. In the worst case. Coming back to this PHP example. Not example case. If it would be running on PHP. You also need to take care of patching. And if two nightmares come together. You need to patch something. It is security relevant.

And you have an incidence. So everything last Thursday. No Tuesday. Thursday happened. At the same time. You have a real problem. So it is not that easy. And this goes back. To the question. Or more to a quick one. First you need to test your fallback. As Rainer mentioned. You need to contract your exit. And you need to review this. Every time. Very often. As Rainer mentioned. This identity access management market. Is very. Much active. And companies are acquired. Services are extended. Especially around AI. And all that stuff. Companies are acquired. And you need to take care of that.

And this is nothing the IT department. Can solve by themselves. So let's jump into. The next slide. Three steps. That can start next week. This is more or less the summary. Of all the three quick wins. The first one. So step number one is. Assess your stack. Block an hour next week. And list your identity. And access management components. How critical are they? Who operates it? Who holds the keys? And could you exit? Yes. And then next is number two. Which is about enforcing. Your digital sovereignty requirements. So if you're in the situation. Of buying a new solution. Or if you find out.

After accessing your current stack. That you need to modernize. Or want to switch to another vendor. Or provider. Make sure that you have. Evidence based questions in your request. Or proposal. And not just rely on badges. Or kind of self-assessments. And the last one. Put a real break glass in your calendar. And look for the exit clauses. In your IDP contract. If you can't find them. That's your homework. And. That is a perfect handover. For the last question. Asked by Rainer. Yeah. So first. What we want you to remember. Control beats the location. Evidence beats the badges.

And sovereignty is not resilience. So you need finally both. And with that. We have a final poll for you. Which is about. Okay. Which quick win will you actually start with? I think there's an obvious one. But you can choose between. The number one assess your current stack. You can ask for evidence. Or test and contract the exit. Yeah. As you have now some time. To actually answer the polls. We will give you some time here. Before we then show. And discuss the results. So with that. We are at the end. And I think we will then go into a combined session. Of looking into the poll results.

And then also. Accepting some questions. I think we have some. Maybe 10 minutes. If not even 20 minutes time left for Q&A. But yeah. Let's see. Perfect. Thank you. And I will start to discuss. Or maybe two of us can discuss. The poll number. First one. You can also see the results. In the polls tab on the right side. The first question was. If your primary. Identity and access management provider. Were unavailable for 72 hours. Do you have a tested plan? The good thing is. Most of you answered yes. Tested within the last 12 months. The bad news is. If you do like. In voting parties.

The other view. Don't change it while I'm talking about it. 60% said. Someone voted. I know. You might remember. We played that game. At the ESC workshop as well. In real time. 40% says yes. We tested within the last 12 months. But on the other hand. 60% did not test it. At least 30%. Have something like a document. Beautiful document. Somewhere in your ISMS folder. Or wherever you deal with that. Or in the enterprise risk management. Or wherever. But not tested. And. 44% do not have a plan. Or don't know. And that's a high level. And something you need to change. While I'm talking.

It switches more. Like 44% tested it. Plus minus. It shows there is some need to do that. At least to take care of that. And also on the other thing. Something to add from your end. Honestly. I'm surprised it is 44%. I expected an even lower number. We haven't tested that. Just our vendor. Nothing will happen. But it seems people already understand. There is a risk. They have already looked into that. However when I look on the results. Of the second poll. I'm asking myself. If you already tested then. And then most of you. First want to assess your current stack again. I ask myself.

How does that fit together? Maybe Christoph you also have some idea. Potentially the one thing. Is taking care about the primary one. And the other one. About one of your identity and access management stack. Maybe. Interesting. Good thing. Start with access. I always want to say access. Identity and access management. Assess your current stack. Is a good starting point. Make some kind of inventory. And double check it. As mentioned. You can use the reference architecture. If you then know. You can jump into. Ask for evidence. Or even start to do. Some kind of testing. If you don't have a test.

Protocol. Or something like that. You should create one. On the other hand. It is the obvious choice. I was talking about. I think one option. Out of the three is obvious. And that is the assess your current stack. As you said. Everything starts with assessing your current situation. And that is what people plan to do. That is good to see. And then we have. Some questions. Let's see if they are. Good to answer. I think the first one. Is already answered by me. In the chat. That is a good question. For you. By Willem. I wonder. Does the category European. Union software as a service.

On European Union hyperscaler. Not exist. This was slide number. 14. There is a category. For US vendors. A European Union. On US hyperscaler. And no. EU hyperscaler. If this exists. In something like that. I am asking myself. The question is. Whether we can name a vendor. Which is from European Union. And providing services. Based on IWS. I think. I have to take this question with me. To be honest. I want to double check. I am not telling the truth here. If you have some vendor in mind. Christopher. Feel free to jump in. That is totally fair. Willem. Would help. If you buy the mail.

You can scan the QR code. It is written on the screen. I will take a note. The other question. That is a good one. How can organizations. With limited IT. And cybersecurity resources. Strike a pragmatic balance. Between pursuing. Digital sovereignty. And leveraging the high availability. Of the cloud. I have an idea. That is a philosophical. Discussion. In Germany. Maybe not. How can organizations. With limited IT resources. Strike a pragmatic balance. To pursue digital sovereignty. To get digital sovereignty. While still having something like AWS. Or something else in place.

I think you are perfectly in this. Medium range for the cloud access. Data access. Which I was mentioning. The magic thing is holding the keys. I think it is important. You can use. A United States or US. Hyperscale. As long as you hold the keys. And make sure you have access. To the data. I know there are vendors. Who natively support that. They have proxy technology. Encrypting your data. Before it goes. Into any data center. For the final storage. Everything is encrypted. And stored safely. You have all the benefits. Of using the hyperscale. While still being sure.

That you are holding the keys. Because the encryption. Happens in your data center. On a proxy service environment. Which is controlled by you. In the United States. Or if you want in Germany. That can perfectly fit. Restricted or limited IT. And cybersecurity resources. I would add. In that case. Going to a higher level. A risk based approach. If you are limited in time. And resources. You need to consider. What are the most relevant. Processes within your organization. What kind of software is needed. If you are a retail company. Potentially not that small. But most important.

Is that GDPR relevant. So privacy is ensured. What Rainer mentioned. Ensuring that you hold the key. But on the other hand. That your IDP. Is running here. And for sure the invoicing stuff. In the background. And then you need to prioritize. If I am limited in budget. Which is always the worst thing. I need to see. How long can I live without that. So traditional business. Continuity management. Doing a business impact analysis. And then driving down. When do I need to focus. And if you realize at the end. Honest truth. If you take. Whether it is Google workspace. Or Microsoft 365.

As a whole thing. And you rely on everything. On that service. And they decide. This US president. Or someone else. That it must be shut down. That is a nightmare. And then at least. The bare minimum is. If you take Google. And Microsoft in that case. That you have your data. So you need some kind of backup of the data. The typical files. And then you can go to some. Plan B thing here. And basically the answer is risk based. Depending on what you do. What is most important. And break it down from there. If you are limited here. Okay. Something in the chat. This is for everyone. This was Oscar.

Then I would say. Willem please get in touch with us. Then we can answer the question via mail. And with that I would say. Thank you very much for participating. This webinar. Recording will be live. End of this day. Or maybe tomorrow. You can also receive the slides there. And if you have any kind of questions. They are beautiful QR codes. I think one of them is leading to the. Microsoft booking page. Where you can. Book an appointment. With me as well. If needed. Right now. Yeah. Then also thank you very much for my site. Thanks for joining this webinar. And wish you a nice rest of the day.

Have a nice evening. Take care and bye bye. Goodbye.