Oh, thank you, thank you for KuppingerCole to having me and also Women in Identity tools. Thank you, Kay and Angelica for making this happen. I'm Silvia Knittl. I started working in IT 20 years ago in directory services, then I was as a consulting working in identity consulting, supporting tool integration projects, and recently a more broader focus on transformation, transformation into cloud or other flavors of managed services. Quite often or almost always I work in regulated environment like public sector, financial services or defense.
So this talk today was inspired by my daily work and what I see there. And I'd like to talk from Angelica because I think purpose, intent and ownership and all the principles that you have now stated for AI agents, I think applying it to a world of identity cloud world is a new halfway down the road also for the governing of this kind of environment.
So when, oops, that's it. So what I see today, I'm working for Capgemini and we are quite often in the machine room doing this kind of operational transformation and across Europe, we see there's a kind of high demand and need for cloud transformations and ask from clients.
However, when we talk with the business and with the clients, what I also see coming along that there are rising concerns around sovereignty and sovereignty and control. And sometimes the clients start to question, are we able to use cloud services or not?
And well, of course, it's fostered by the given geopolitical situation, but there's still a pressure for innovation. So yesterday I was in the last keynote talk by Köppinger-Kohl and Daron and Matthias and they mentioned, OK, still identity and it could be identity transformation, cloud transformation needs to be at the speed of the business. But what I see when I'm talking with my clients, they're completely overwhelmed. So overwhelmed by the sheer number of regulation that's out there.
I've just put in some regulations, but also controls, compliance controls, that's like the ISO standards on the slides. And this is what I as myself, but also the clients have to digest and have to bring it into operation, which means organisation must balance the need for innovation with this kind of compliance overhead. And what I see quite often, it results in a rising architectural and governance complexity. And while there's still a wish from the business to have it faster at the speed of the business, as Köppinger-Kohl was and the colleagues were talking yesterday.
At the same time, there's this kind of concern. Am I still able to use cloud services as I intended to have it? And when we look at the regulation, within these two regulations, there comes some personal liability with the upper management. And still here we see some kind of concerns when we talk about cloud or even managed services as a whole. And when this also, when we have the organisation and governance as a key principle also here, when we are an organisation where there are unclear responsibility models, there even also the complexity rises.
And this is where our projects are going to tend to slow down. And in the introduction, I was talking about lost in translation. And as I said, I'm today I'm working in transformation project and currently I'm working on a transformation project to the cloud with the Greenfield approach, which is the first time in 20 years that I have a Greenfield project with my software development colleagues. And we started here also from the tech perspective. I'm working also from the regulatory part. My dear software developer, please start to your homeworks.
We need a list of processes because from the security perspective, we have to do criticality classification when it comes to confidentiality and credibility and availability. So we sent him this homework. It was quite a couple of days a week, two weeks, and it was still quite after two weeks. So I was calling him back and asking, hey, you had this homework was listing up the processes from the business perspective because we have to touch the criticality. And then he said, yes, I was really thinking along and I came to the conclusion of developing a software. It's all automated.
We do not have processes, which means here is where we have already, I was my dear colleague, have this kind of lost in translation where we have then started having workshops, doing the translation work. What does it mean? A process for a business, the software is meant for a purpose for this client. So if you do not have the client, what is the client telling to his children or to grandparents what the software is meant to do?
And so we had some kind of translation work with my software development colleagues to have this list of processes, to have this regulatory homework, to have the foundation for the criticality. So keep your fingers crossed in two weeks. We will discuss with the client if we have a fit to his processes that we have done our own homework right. And that's what I see quite often, this kind of gaps. And I'm just talking about a business perspective, not yet talking about the sovereignty as well.
And quite often this kind of different definitions of what do you mean even in the simple process list homework says unclear responsibilities. We had also discussion with the client and some kind of also transformation to manage services like, OK, manage service. It's like you're providing me a taxi service. I'm sitting in the taxi, you're driving and that's the service I would like to do. But honestly, I would like to have the control. And what are you doing in the data center and what kind of tools and technology are you using?
So it's this kind of understanding of a common operational model on who is responsible for what. It's still with this client and ongoing discussion where the client from the business is in charge of control and operation control and when it's on us. And that's some kind of discussion that has to be taken. And what I see quite often in complex organizations, quite often we have a loss of translation syndrome in one of the organization. One last example here was when tech and business were having brainstorming sessions, several brainstorming session about the modern design of this organization.
And tech was like, oh, this is going to be a cool project. Business was happy because they have the feeling from their business needs, innovation topics were covered.
Well, there was a sign of the high level design and there was one person not in the room. So guess who? It was someone from this organization, from the regulatory side. And then when the project started to stop in this organization, they called him also Mr.
No, because he was looking at this design and said, no, you can't do this. And the business said, yeah, but we would like to do that. And we from the tech perspective, yeah, we are able to do this. We are all happy because we came to a design which all fits to the business needs and the tech needs. And he came, no, the regulatory side does not allow you to go into cloud.
Well, I was in the room then and I'm working with the German regulator, BSE, and I know that in the cloud, they're using cloud service on their own and say, hey, I'm working with the regulator. Here is the control set for using cloud. And even because then the discussion is, yes, but we are different. We are different, we are special. We have really hard protection needs. And if you look at the German regulator cloud control set, it's also here for your more restricted environment, the cloud needs.
And then there was a coffee break and in the coffee break, one of the business architects came to me sneaking and even whispering, Sylvia, did I understand you correctly? It's not the regulators that is hindering us to use cloud. And I said, yes. And this was a shocking news for him. It was a positive, shocking news for him. So that's the kind of translations that I see. And sometimes it's a gap and sometimes it's more a candle. What we have to tackle in the projects. And now let's talk about sovereignty. Do you really want to have sovereignty?
If yes, in which dimension? When we talk about cloud sovereignty, it's not the one thing. Quite often we talk, OK, it's a location where my data is in Europe, as in Germany. It's a multiple dimension of control and responsibility. Looking at the data sovereignty, do I want to have or do you want to have control of where you store your data, where you process it, who is allowed to access it? What about operational sovereignty? Who is operating it? Do I want to have control over the operating, monitoring, respond to events and incident, the technical controls?
Do I have or do I want to have control over the design, configuration, securing all the infrastructure and also from the legal part? When we look at the contracts, OK, am I able to go to court in Munich where I live or do I have to claim my rights at Fiji or somewhere else in the world? So those are the kind of dimensions that we have to take into consideration. And sometimes also I have discussion, oh, this client wants to have access to this monitoring tool.
And I say, OK, why we are in charge and responsible by the contract to run and operate it based on this SLA. So why does this client want to have access to a technical monitoring tool? For what purpose? And does he have the skills to handle those? And those are the discussions that we have to deal when we talk about and discuss about sovereignty. So keep in mind, it's not the one thing. It's a multidimensional control and responsibility part. And it's just easy, as Angelika said, it just defines the roles, responsibility and ownership. I think you mentioned it.
Yeah, that's that's also what I would say afterwards. And but first start with some kind of translation, translate the regulation into requirements. And I've just called out a few of this regulation GDPR. Here it's about data sovereignty, access control. I just put in a few examples. And but all this kind of regulation and standards have to be translated into requirements, requirements for your technical and architecture and also governance requirements. So the regulation just purely sets what must be controlled.
And so cloud model models define how much control is possible and technical possible. Now, how do we overcome this kind of gap between regulation, business technology and here governance is the unifying layer, it's as simple as that. It's the core elements. It's this kind of translation work, reads the regulation, involves the lawyers, get a unique interpretation and put this into policy and standards, defines the roles and responsibilities in your organization. Defines the control mechanism.
And as me, for example, as a security architect, I'm doing the linkage between the architectural designs, the operational part and the compliance and governance part. As simple as it is. When I start projects in transformation, OK, we have to start. We need from the client side also some kind of stakeholders to work with us. Who is your Mr. and Mrs. Identity Management? And you have to be able to say, OK, and Coping a Call has this identity fabrics, a capability model. I think it's 40, 50, whatever roundabout capabilities.
So I ask, OK, who is your Mr. and Mrs. Identity and Access Management as a role? It could be a whole group, whatever. So who is doing the directory service? And one of my client initially said, yeah, directory service. Willi is doing this. Yeah. Who is doing the authentication part? Willi is responsible for this. Who is doing the application onboarding authorization?
Yeah, we have Willi for doing this. And who is doing the PAM part, administrative account?
Yeah, Willi, of course. So why do you ask that? And while I was also a couple of Willis, some other client was kicking me like, stop asking this question, because we also observed roles and responsibilities as easy as it sounds like. Quite often organizations misunderstand what does it mean from an identity fabric, but we could bring it in a broader context. Security architecture factor to operate all those and having 50, 40, 50 capabilities may only in the identity and access management domain, which is Willi and someone, if Willi is on vacation, have to work on and set some kind of...
I also say sets where projects slow down or even fail because that's underestimated. So role and responsibility part. At the end, it all has to fit together.
Of course, the compliance, the translation from the regulation. And also yesterday, Matthias Reinhardt and Darren said, OK, identity is they mentioned it as an enforcement pillar, but also the control layer from the access control policies, from the roles decision. And of course, from the technical implementation identity and also technical controls with inscription locking. So pillars that you need for the enforcement and technical enforcement. So having said that, identity is.
In a cloud and sovereign cloud environment, one of the important pieces to think of the 40, 50 capabilities with help of identity and access management and also identity governance perspective, you're able to turn all this legal and regulatory requirements into technical controls, but also technical enforcement. With the help of identity and access management, it's defined who is trusted under which justification and with what kind of permissions. And of course, it helps you ensure the control and that the control remains with the data owner.
In one of my projects, we are heading also in a cloud environment. And so incumbent provider is not giving us the data. And here's the regulation helps us because it's the client who per regulation and GDPR regulation is the data owner and controller.
Of course, it's not nice if you have to involve some lawyers to get the data. However, here also regulation helps us. And in this audience for identity and access management audience, I think it's crystal clear the key principles that we have in identity and access management, like identity based access decision, building explicit trust, least privilege, and also context aware identity decision as a kind of key principles that help us also in a sovereign cloud environment. So in our practice, what does it mean?
We have to go away from this checklist based compliance to dynamic and automated control, which means having a policy based governance in place using the cloud native access controls and automation sets here, but also look at because hardly any of the organizations that I see are pure cloud hybrids as a mixture. So for the practical implementations, there's still challenges. So what I see quite often is still some kind of fragmentation in tooling, which brings also some kind of fragmentation of the organizational and responsibility model. And one of my clients says, oh, we have cloud.
We have all flavorful slides. It's an international organization. It's automotive sectors. We have also hyperscalers, AWS, Azure, Google, and all our brands and organizations have their own flavors. And here they ask us, help us, help us get some kind of end to end visibility in this multi cloud environment. Critical for success is. Knowing where to go, define your target architecture before to start.
Of course, implement an identity centric governance and involve compliance right from the start, not as the scenario with Mr. No, involve compliance right from the start when the design starts, which means governance is an enabler, not a blocker, and it's support enabling innovation with control. We are in the woman and identity stream here. That's why I want also to bring some kind of thoughts or brainstorming for you. So a woman identity perspective. Cloud for me is infrastructure as a service, platform as a service, software as a service, identity as a service.
Would it help to have greater diversity, including more women to actually improve cloud ecosystems? How they are designed and governed? Because as I observe it, there's a lot of translation need and communication relevant to implement and transform to cloud and to sovereign cloud. So what do you think? With this kind of thought and question, I would end my talk. Thank you for being here. Thank you for listening. Thank you. I'm happy to take your questions. Yeah. Any questions out there? I guess one thing I would have done with if I were Willie, there should be Willie, William and Wilhelm.
So it sounds like at least three people. Yeah, yeah. So how did you overcome Dr.
No, you know, who said no regulations, we can't do it. Still working on it. So keep also your fingers crossed. How would you overcome Dr. No?
Well, what we are, what we are trying to do, because it's also on this client side, where we also put some kind of risk catalogue. OK, in this kind of project, there's one person missing. All this Mr. No is coming from IT technical security. What's missing from their organisational structure is the CISO perspective. They had no times and no vacations, and someone left the organisation. And for me, it's very difficult.
I mean, it's very difficult. No vacations and someone left the organisation. And for me, the CISO or ESB in Germany, we call it, that's the person who is balancing chances and risk. At the moment, we have mainly the risk perspective and that's the person coming from defence sector where you have, OK, there's some kind of enemies.
Of course, we have to look at the risk. It's important.
However, what's missing here, and that's why we're talking with the client, you have to establish from the governance side someone who is balancing chances and risk because there's not only the technical risks, there's also the compliance part, and so someone has to pay for it. That's the argument I would often make in companies I've been at with our legal team. I was like, no, you're not the decider, you're the advisor. The advisor, not the decider. But some people don't understand the difference between that.
And that's a kind of purpose, intent, and ownership and responsibility which quite often are not clear defined because this Mr. No has quite a... Powerful. Seems to be powerful because there's some operational link missing. Makes sense. Excellent. Thanks again. Thank you. Next up.
