The Art of Choice: A Guide to Informed Decision-Making

I'm excited for activities today. Hopefully you'll be able to pique your interest and generate more questions than you came in here today in a good way. Yeah. We'll go from there. Okay. Yeah. Matthias Reinwarth. I'm the director of the practice IAM, but more importantly, I'm the head of advisory. We want to talk about the guide to informed decision making. And for the first slides, I want to hand over to Christie, but I want to quickly show the agenda.

So, we are looking into four segments for today. We have 90 minutes planned.

Actually, we have 100 minutes planned because we failed to do the math, but we will make this anyway. So, we will start with the instruction. What is this session about? It's about choosing the right tool. There is no magic about that. At the end of the session, if you want to leave it right now and say, okay, 90 minutes is too long for that, it's not. Do it properly and do it for your organization. That is the main essence of about that.

So, what is at stakes? We will have a look at the five phases that we as KuppingerCole or as analysts or as just people who have done that before suggest for this. We want to do a quick exercise with a team of you. No writing of cards, just talking to us and finding the right solutions and the right questions in defining requirements and vetting vendors. What would be questions to ask to your vendors? And the conclusion would be the informed decision. And with that, I hand over to Kristi. I appreciate it. Thank you. Okay.

This can be entirely rhetorical, but I want you to think about this in your mind. Have you ever been in a situation where you've had a failed implementation of a tool? Why was that? Because if it's not an if, it's a when. Why was that? Have you thought about it since? Are there things that you wish you could have done better? Are there resources that you wish you would have access to? Yes. Those of you who are familiar with KuppingerCole, we do offer resources as such. This is your main guy here, so you're very lucky.

But not only our advisory services, our research, our digital tools, we have several offerings to help you through this process. While buying things may sound fun, because shopping is amazing, it's a very tedious process that has major repercussions. Even if you don't do something, not doing something can have those repercussions. And the last thing that we want to do is to negatively impact our organizations.

So again, those of you who are joining online, feel free to post any responses to questions we have as well in the portal. And then we can engage with you as well. Right. Just for the hand signs, just to answer the question with yes or no, if you say yes, would you kindly raise your hand? Has this happened to you before? Just choosing the right tool before, because you did not. This is safe space, guys. It's okay. We've done it. We've all done it. Come on.

Of course, right? Oh, yes. And not yours. Yeah. Yes. Of course. Yeah. Why is going through this process important? Why can't we just look at a leadership compass and pick the highest ranked tool? I trust our analysts. I think they're smart. If they think it's the best tool out there, then it should work for my company. This isn't always the case. Right. Everyone's company is different. Every industry is different. The impact could be different. And so we need to dig a bit deeper. We need to do our homework, be a little more diligent. It's very tedious.

It's very stressful, time consuming and costly. So how do we mitigate all these risks? Why do we mitigate all these risks? So big elephant room. Why is cybersecurity important? This is a question that you're going to be asked by your business on a daily basis, right? Why do I have to do this at my company? Functionally, we're fine. We've had no incidences. We're not a big target. I don't want to spend money on this. Why is this important to me? Professionals in the room, we know these answers. But how do we articulate that to the decision makers?

What's the impact of not doing something or doing something that doesn't align with your organization? How do you tie that to your business goals? You're a large retailer. It's important for you to be online so that your customers can access your shopping cart. So what does downtime mean to you? Loss of revenue. It all ties back to cybersecurity. And you have to do these exercises to figure out what is the impact of what you want to achieve on the overall business. The complexity and variety out there is insane. More tools, more problems.

You talk to any one of our analysts, and they're tracking any kind of topic area. They're tracking hundreds of vendors all saying the same thing. I don't know if you've looked through companies' websites, but it starts to get redundant, right? Same marketing jargon, same conversations. But how do you dig deeper? How do you understand the truth behind the sales pitch? The strategic alignment piece. How do you align everything, again, with your business? How do you make more efficiency within your organization and free up resources that can accomplish their tasks?

I mean, I don't know about you, but teams are small sometimes. Sometimes folks are doing two, three jobs. These decisions and selecting the right tool impacts that. And then the empowerment through the informed decision process. If you have a clear framework, if you've done your research, you understand what success means for your organization and how to get there, at the end of the day, you're going to look great, right? You're going to accomplish all of your goals and then get more funding next year and enable yourself for success down the road. So I will ask this question.

You sir, I apologize, I didn't get your name. The one who answered the question about you've had a failed implementation. Would you care to share what your experience was with that implementation?

Oh, I'm losing you. Don't worry. Ask yourselves then. What are the issues you've had, experienced with tool selection? This can be rhetorical as well, but think about it.

Right now, on my team, we're going through this process with a particular tool. And I guarantee you, every single department that I talk to has their own requirements, their own qualms, their own issues. It's a difficult process. I'll hand it over to Mr. Matias to talk about how you tackle that process.

Thank you, Christy. I need this one. So what I want to present is something that is at the end of the process. These are learnings that we did or made within Kupinger Coal, outside of Kupinger Coal. It's just lessons that we think are worth sharing because maybe you can re-identify some of the issues that you might or might not have had before. And these are the headlines. I hate animation, so this is all already there. So I just want to talk you through these five key findings because I think these are the mistakes that are made. So first of all, take enough time.

Christy mentioned that these are people who are stressed to have more than one job, who are doing that. And it's not their core business to make such a selection in many organizations, especially in smaller ones, but unfortunately also sometimes in bigger ones where the experts are experts in many areas. So the problem is to underestimate the complexity of such a process, to really get to rushed decisions other than just making sure that you really have the right information at hand. Keeping essential steps within that process is an issue. And we will show these steps that we think make sense.

This is an opinion. This is not necessarily something that you have to agree with, but this is something that we have seen to be working. If you don't do these steps properly, you are compromising on quality. That is an issue. And you are ignoring the long-term impact of such a decision. You are not choosing a tool for today, you are choosing a tool for the next 10 years, most probably. And sometimes you just don't look at what the vendors actually tell you and what their answers are to your questions, if you ask the right questions, and what they mean for your business.

So taking enough time is important for just getting to this informed decision-making process. The third one is really avoid over-emphasizing specific situations or processes. When you are in the situation of choosing a tool, you might have an issue right now. There's an audit issue. There is an efficiency issue, a cost issue. And that is the reason why you are starting that process, but you should not only focus on that. You should make sure that you look at a holistic strategy, looking at what does that mean for the future.

Does this solution, once it is implemented and has solved the problem, the initial one, does it scale to my next problems that these types of products might solve? If you do not do that, if you just buy a thing that helps you in, I am a guy in getting better in recertifications, does that also help when it comes to user behavior analytics later on? Does this do this as well good or not? Is there innovation built into that system? And if you are just looking at what you are needing right now, you are building on your current knowledge.

But I expect all of us to learn from day to day and having a solution that is capable of implementing this stuff later is important. Very closely related to that, but a bit different, is the resistance or the focus on the status quo, that you think, yeah, my processes stay the same as they are because they work for 10 years now. So they won't change. So let's buy a tool that helps me in that. No.

With this, you are negating, neglecting market trends. You are not looking at what sometimes the analysts are telling you, what will be the next good thing that can help you. It doesn't necessarily have to be generative AI. It might be something else, somewhere else. Just pattern matching and good computing power might be something that can help you. So limiting the technological advancements to also make its way into your organisation is really an issue. So not only look at the status quo. I think the most important part is the fourth one. You are not special, full stop.

Every organisation thinks it's special because it's different somehow. Yes, it is. But the bigger picture is not. For many cases, you can learn from best practices. And when you're special, configure, adapt, augment, integrate, but do not choose a solution based on your being special and do not tailor a solution on being special. So I think these are the two most important facts that we usually see.

So if you are creating a solution that just solves your problem because you're special, you will not be able to scale it up, to update it, to increase or to improve your problem solving for the future because sometimes it's just difficult because it's all coded into the product. And in the end, we are talking, for example, later in this event about NIST 2, which is about sharing cybersecurity information about incident information with others. If you have a special solution, that might be difficult because you are special.

Final thought in that context is a new tool will not solve all your problems. The tool can help you, but just by buying a tool does not help you in implementing that. This sounds like a truism, but you need to change your organisation, your target operating model, your policies, your processes, and then use your tool for implementing that. The better you are already for this, the less work needs to be done. But I assume there's still a lot to do to make sure that tool plus processes plus policies plus training plus education together can only help you in solving an issue.

So organisational change might be required and the integration challenge is always often underestimated to say, I buy a scene tool, which is great, now I have all the information at hand. Yep. But they need to get in there. This is integration. So make sure that all this is done properly. And that is the five key learnings in retrospective of projects that we've seen where just things did not go too well.

And as we said, this is a workshop, then I would hand back to Christy and hopefully we are happily enough, we have more people in the room and I will check the comments right now once I have not looked at my notes. But we want to get interactive. So we really encourage you just to provide feedback because we're a little group, we have a bit on site or remote. So let's get more interactive.

Yeah, definitely. I will say, while Matthias doesn't like animations, he makes some good graphics. So the next two are courtesy of Mr. Matthias in chat DPD. So tools can be a double-edged sword, right? It's a fine science. Matthias talked about the methodology around selecting this. I said not all companies are the same. Doesn't it kind of like go against one another?

Yes, it's the same practice over and over again, but for unique instances. So you always have to keep this in mind. So you can have an objective of capability. You want to make sure all of your processes are working functionally, there's no disruption. You want to ensure that if a situation happens, you have a go-to. But this could also create dependency. So maybe your organization is a little more apt for risk. And they went with a startup. Two years down the road, the startup is no longer around, but you're completely dependent on their tool. What do you do then? You have to make these plans.

Innovation versus disruption, great. Everybody wants to do the newest, brightest, biggest thing. Everyone wants to come out with something first. Everyone wants to brag about how they are, the innovators in their organization, market, what have you. But are you taking into account what is functional right now, how your teams work, their day-to-day? Is this going to be more disruptive at the end of the day, or is this cool new tool actually going to enable them? Solutions versus new solutions.

Again, is what you're doing today functionally required or functionally justified? You could be creating new problems. You might not have the resources to manage and monitor these tools. You might not have the intel. I'm thinking of Target, the big one everybody knows. They saw the anomaly, knew something was wrong, didn't know what it was, didn't address it, and it became a larger issue down the road. Empowerment and skill gaps, that kind of leads to that, right? Are you enabling your teams?

Yes, our teams might be small, they might be overworked, but is this going to solve their problems? Or are you creating more problems because you don't have the resources or skills to fill those gaps? Money. In a previous life, I helped assess a large insurance company in the U.S.

who, after previously mentioned breach, got a large funding grant for cybersecurity, and they went tool-happy. And a few years down the road, they find themselves in tool sprawl. No one is talking to anything, creating a larger gap, more money down the road, having to add more resources to manage more tools, buying more tools, subscribing to more tools. Is that really functional for your organization? Are you saving more money down the road? Are you costing them? And scalability versus complexity. Matias mentioned, you have to think about the future, not your today, right?

Where's your organization going to be in three, five years? Yes, something might be functionally okay today. Will it be tomorrow? Will it grow with you? Will it shrink with you? All of these things need to be considered.

Again, this is why you can't just look at an LC and pick the highest-ranked one. You have to do your research, you have to ask the hard questions, you have to seek out help with organizations like Cupping or Coal to really figure out what exactly you need versus what you want and versus what's going to really impact your organization positively down the road. So I'll take it easy on you right now. We can make this rhetorical because I want, yes, please. Could you flip back to the previous one? You know what I miss? Please. The direction. There needs to be a direction statement.

And this direction statement would say, which would, from my perspective, give an answer to many of these ones. This is what I'm thinking for a longer time entering the cybersecurity environment. It's the overarching term of simplicity. Because what we see is, and you can listen to many of the discussions, we always come across complexity, many tools, and as I raised my hand when I said, of course we have experiences what it means to introduce tools. So I remember, for instance, in the company where we have been introducing SAP, it was a nightmare. It was a nightmare. It was a nightmare.

You needed more people after than before. It's a kind of job generation. But I think in order to give it a direction, I would love to measure each and any activity against the target of, is it now more simple than before or not?

For me, this would be a very, very strong direction, a kind of, how do we call it, gradient. You know, developments only happen along of gradients.

And here, we would have to think whether we introduce a term of simplicity and check each and any of our decisions, would it lead to more simple? Because more simple means, by the way, more secure. If it is more secure, then we exactly achieve what we want to achieve. So would you talk in your talk about simplicity at all? I can leave that up to Matthias a bit about the simplicity of it. He'll go more in depth in the topic in a bit. I think simplicity, the term simplicity is not used, but it's hidden inside terms like automation efficiency.

Now, automation could also be very complex. Sure. So that's why my statement is I just make a call, a general, a generic call. Maybe we introduce this term and measure ourself against. I know there's no metric, there's no standard, nothing like that. But maybe it's high time for the cybersecurity community to think about simplicity. Okay. Yeah. But challenge taken. Thank you. Other opinions, especially around this topic of adding simplicity as a criteria and as a metrics regarding measuring cybersecurity, anybody?

No, but I think one aspect that is also not on that slide, but I really will take that because this is why I'm here. I want to learn from you. It's really that this slide might look in the first place to be more too much tool centric, but not too much strategy centric. This is a word. So simplicity might be part of strategy and of measuring how a strategy works and works out and works out within an organization. But if I think on the other hand, as a counter argument, if you think of something like Ms.

Tuk just coming around the corner and adding new levels of complexity, things won't get easier in the first place because you have more requirements, more obligations, more things to do, but they need to be implemented simple. And that's the reason. That's the point where it comes in again. There will be more to do. You've mentioned SAP as an employment machine.

Yes, but you're solving more problems. So there might be a good rationale behind that.

If not, then you have an issue. But simplicity is a good aspect here. If I am interpreting. Copyright.

Copyright, yes. There you go. There you go. It's on camera. It's good. Just kidding. But I really think it comes to my mind if you travel around and 31, 32 years in technologies. And what I see is a growth in complexity. So a little bit away from simplicity. And maybe it's a corrective, just a corrective, it's a counter direction you can always measure against. Okay. Great. But thank you. Thank you for that thought. And it's good to break out. So we have a plan, but the best workshops are those where we scrap the plan. Yes. Okay. But getting back to you. Yeah.

Yeah, absolutely. No. And I think it's completely valid call out.

I mean, simplicity in this sense can go across the board, not only from a tools perspective, but like you mentioned, a business perspective. You know, if you have a low adoption of the implementation, it's not really effective. You could have had a great implementation phase that went beautifully, but then at the end of the day, are people, are you able to, you know, get all the applications that you need on the tool? Are you able to encourage folks to use it properly, train and develop and create documentation around it?

I mean, it could be tedious. And so simplicity should be throughout the entire process. I agree. Thank you for that. Yeah. What I was going to say, this is kind of leading into our broader conversation, but and I keep bringing up the business piece because that's my side of the house. The impacts of tool selection are across the board, right? So when you're going through this process and this is creating your business case, right? How is this going to impact your company? Are you in the requirements gathering phase talking to the different departments that this is going to touch?

Are they understanding what's going to happen? What needs to happen? Are they trained up and equipped to make it happen? Is it going to benefit your organization at the end of the day, or are you just going to cost them millions and sit on a pretty fancy tool? How is it going to impact your team? We talked about this earlier, you know, is it going to free up their time to let them work on projects they were hired to do, or is it going to create a larger skills gap and more problems at the end of the day? How does this impact you?

I mean, if I'm going to get famous, it's not because I had a breach of my company and I didn't do the appropriate research and implementation. And how does this impact your customers? Obviously it's not in any particular order. How is it going to affect them? Is it going to affect their experience with you? Is it going to affect whether or not they want to engage with you? Is it going to make their life more difficult? Is it simple? These are all very important things.

I mean, sometimes I know we can get really bogged down in the technology piece of it, the cybersecurity piece of it. But what you do impacts the entire spectrum of an organization. And so you really need to think about your go-to-market and whether your decisions align with that. Okay. Now the fun stuff. I don't know.

Actually, we have some time left, which is great. Okay. I go back to that picture. We have experienced pros in the room. I'm trying to ask the question. And we're talking about cybersecurity today. So it's the cyber revolution. We are in the pre-conference workshop and sharing expertise from your everything that you want to share. I'm not obligated to do anything like that. But when you look at introducing a tool and out there, there are these vendors and they are selling stuff and this stuff is great, but it needs to be well integrated.

Are there stories that you would like or experiences, do not call it stories, experience that you want to share where you underestimated some of these aspects that are in this dotted list of impact to company, to team, to you, to customers that you had or had not on the radar that really had some influences on your business afterwards that you want to share with us? Anything that somebody wants to dare to share with us? With this picture, this is what you get if you ask many stakeholders and you do not moderate the requirements analysis. This is what you get.

And the question is, what is important of all of these gadgets that are in the Swiss Army knife? Drilling it down to the right selection of these gadgets and getting to a solution that really works for your organization and then has the proper impact to company, team, you and your customers. That is the actual art behind that. And after that workshop, you will get that slide deck and you will get these steps that we suggest to execute. But this is just as a guidance, as a help for you. There's no hidden trap behind that to say, OK, now you have to buy it from us.

No, you don't have to. You can do it yourself. And that's the reason why we're doing the workshop, we want to enable you.

So, again, this question, I've been rambling a bit to give you time to think it over. Any story you want to share with us? Anything in the comments? I'm looking at nothing.

OK, then we have to tickle your tongue a bit more and then let's go to what we consider to be the five important steps regarding, yeah, the phases of an enlightened choice, which is, of course, a bit tongue in cheek from the wording here. But this is the proven methodology that we think you can take home with you. And if you want to have some examples, some questionnaires, some Excel sheets, just ask. We have these and we give them readily away. That's not there. There's no hidden source, secret source, hidden agenda behind that. Five phases.

And I want to talk quickly through these because this is how we do it. And we see that many organizations are doing it similarly. And that also reflects these five mistakes that can be done that I mentioned earlier. So this is really what we want to make sure that you do it properly. So the first thing is an assessment phase, the information collection phase. And this is really where you need to take your time.

This looks at different aspects and this looks at different dimensions when it comes to choosing a right tool or maybe getting to the conclusion that you don't need one, because it might even lead to the message that if you do a proper portfolio analysis, you don't need anything. You just need to use the tools you already have. And if you don't have them, this is part of this analysis phase. Then you can say, OK, what is missing? What do I need to add? Is there something to rip and replace?

Is there something to integrate with, something to augment with or something we just didn't have before because the market is changing? So it's a structured analysis based on a well-defined reference that you can use. There are lots of references around. There has been a workshop in this room, I think, before where such a reference architecture has been presented. Use something like this.

Use ours, use somebody else's. I don't care, but have a reference architecture in place and look at what you really need, what is there, what is fulfilled, what is good, what needs to be added. So structuring into blocks and areas and really assessing these areas, that is very important to really understand what do I need and what is missing. Prioritise. The picture that I've shown before, obviously there was no prioritisation because this thing would not make any sense for any organisation, even if you map that to cyber security technologies. Next step would then be the enterprise analysis.

That is what I'm saying. Where are you? Do you have the needs? Maybe even where can you support your business? Where is the message to tell that the organisation can tell to the outside world? We are more secure than our competitors, which is a good statement. And people are more and more buying this. This has not been the case 10 years ago. Then sexy was good, secure was not. That has changed at least a bit. And on the other hand, do a proper market analysis. Understand the market. Go to those who know, to the analysts, maybe us, maybe others. Don't go to vendors in the first place.

They will tell you what they have. Go to somebody who is neutral. And there are others around. There are us. There's many to use from and use that knowledge and create that and build upon that. So once you have defined this proper understanding of where you are and where the markets are, where the requirements for such a new tool are and how the market looks like, how to fulfil this, this is the end of this first phase, this assessment information collection phase.

And ideally at that point, now you understand market, what everything I have said before, then you can get to something like a short list, a short list of products slash vendors that you might want to assess starting from that. These are the first two phases, enterprise and market analysis and assessment and information collection phase that build upon each other. And that is something without looking too much into actual solution, but just understanding what is required from your perspective.

And only at the end, at this market analysis phase and looking into, yeah, getting to a short list, that is where you sometimes are looking into individual implementations, but hopefully not already having some pros and cons, just understanding, okay, that could fit. So now let's do the proper analysis. Proper analysis also means that you get to a good set of questions that represent your requirements. What is for you important? What is for your team important? What is for your stakeholders important?

And boil that down to a list of questions that you can, in one form or the other, ask the vendors. And this is something that we want to do later with you. Hopefully that works. Just to see what are questions, what are requirements when we pick a typical product of the cybersecurity market that would be on the top five slot of your questionnaire. Just to do that as an exercise maybe later. Once you have these questions, once you have that short list, invite good vendors to talk to. Send out these questionnaires and then make sure that you understand what they're doing.

I'm just trying to check this. This is exactly what I've presented before. So on the first one, is there a...

No, there's not. Okay. To the left, you have the first column, which is your strategic scoping. And strategy might also include simplicity, and that is surely a good point. So really understanding what is your strategic scope and using reference architectures, using reference models and having them in place and mapping your requirements to that is something that really helps from our side.

So you get from the strategic scoping, what is the problem I want to solve, to what does that mean for my organization, the enterprise side, the middle column, and then understanding what is the market providing to me as a solution as of now, or maybe in the next two years. Ask somebody who has a neutral view on what can be expected within the next six months, nine months, 12 months. So really to look at the market sites, to look at the providers and products, at the services, where they come from, that is always an important question. What is this vendor's origin?

Why are they doing what they're doing? Are they maybe focusing on a specific industry? And what is their strategic orientation? Where do they want to go to? Is this something that augments an existing solution? Is this a platform that does everything and that needs to be differently integrated? All these are the aspects that we look at. I've said that before, that it's a more detailed version of what we've seen before. So vendor communication and vendor presentations is the next part.

You have a questionnaire, you understand where you are, you have an understanding of the market, at least a rough one, and then you want to reach out to the individual organizations that provide these services slash products. So traditional work, and I think there are people contradicting that. I have not heard a good point against that is the good old questionnaire, the good old RFI process that helps in understanding and answering the questions that are of importance to you from the two columns to the left on the last pictures.

So have a questionnaire, have a good communication to the vendor, sending out that questionnaire, not 500 questions, 80 will do, 80 important ones. Evaluate that questionnaire, ask the really interesting ones to present today virtually, team session, one hour, one hour demo, and then assess the vendor's presentation and their products. And then now that you're already starting from a short list, getting to a list of just a few ones that you really want to do further work with. After each of these steps, there should be something. I'm saying that just to make sure.

Let's hope somebody is in the room who speaks better English than I do. There is a Solbruchstelle. There is a place where you can say, okay, stop, I don't need this. There is no vendor in place. There is no good solution. Let's wait for a year. Let's check back whether we can do it differently. So there should be a means to say, okay, let's break here and do that again later or never. Just to make sure I've understood, I know I don't want to continue. That is a fully valid solution here as well to move forward here.

If you do the full process, the next thing we really recommend is a proof of concept. Asking and inviting a few, just a few, for a reasonable proof of concept. And a proof of concept is not something that actually already on-site solves real-life problems for you. It demonstrates that they could do it, that they have use cases that they can execute upon that make you confident that this is the right tool, the right team, the right solution, the right organization behind that, and also the chemistry with the people on-site is working well.

So it's really soft factors and hard factors to look into. So key is, and this needs to be done properly, so just, again, take your time to define the right POC use cases. And these should be no more than eight to 10 or something like that. So it's not a real-life solution. It's just making sure, please demonstrate that we want to have a, again, I'm an IAM guy, an immediate access review as an example. And that should be triggered by ABC and demonstrate how does that look like and translate that to the area where you want to look at right now. So these would be the questions.

In the end, then, a presentation to say, okay, yeah, we did it. We had eight use cases. We fulfilled them all. And then you are to assess that. Final phase of these phases is the communication part. This is where the team that does the actual tools choice process, this enlightened communication thingy, actually makes sure that the message is conveyed to those who have the money, who have the influence, who have the power, who can change processes, who can implement, who can make sure that a long-running implementation project can also be spawned.

And I think that is true, and we've mentioned that before. It's not only the price of a piece of software or a service that you have to pay, you need to pay for the implementation process. And that could exceed the actual amount of money to be spent twice, three times, four times, easily. Because just, again, buying a firewall and having the shrink-wrapped box lying there does not make your organization safer. Just as a taking example from the early 2000s, we don't have firewalls anymore, not too many.

But just doing it properly, that's the way that you should move forward and how you should do that. And I think this is, again, let's quickly get back to this slide. So this is the tool selection process that we suggest and that we would like to recommend to you.

Do it, do it on yourself, do it with partners, do it with anybody, have a tool supported wherever possible, but follow these steps and start with a proper assessment on the information collection phase. This is where everything starts. And don't think of tools at that time. Just think of what is my issue, what are my challenges, what I want to achieve.

And achievement could be compliance, difficult to argument towards your management, could be more secure or even more difficult, could be business enablement, could be time to market, could be speed in implementing new solutions and making that secure, much better story to tell.

And then move through the full process, through the analysis phase, through the vendor communication, to proof of concept, well-designed, and to a proper management decision to make sure that they get the information that they want in a one-slide presentation for those who have only seven minutes to spend, a five-slide presentation for those who have 20 minutes to spend, and a good presentation for those who have the money to spend. Moving on. Defining requirements. And this is the interesting part. Now we need your interaction. So what we want to do is we want to have a group activity.

Since we've been talking all the time, we need to make you talking. And I have some colleagues in the room and they will make you talk. So first of all, starting with what is on that slide, what is the next thing that you would like to acquire for your organisation? Make up one, not real-life tools. We made two examples with just a privileged access management tool or a managed detection response tool. What is on your list of the next big thing that you require when you're talking to the vendors outside? Anybody? Come on. So the traditional IGA part?

Who has this in place and it's already well working? Who has a good working IGA, IAM solution that does provisioning, all of lifecycle management? Is this working already within your organisation? So you need one. You need to help me now.

Oh, okay. Okay. Any other opinions? This is cyber revolution, so maybe also something leaning to more modern tools, modern, yeah, looking at the team.

Otherwise, we say something and then you need to find good requirements that you would like to look into, no matter which area you look into. I say we go with MDR. I think this group could have a high capacity for talking about those requirements, right? I'm going to use our, make it simplistic, okay? Okay.

Okay, yeah, so we can take a few minutes to discuss, okay. Is everyone familiar with MDR? Yeah? Okay. So off the top of your heads, and we can do this as a large group if you're okay with that. Yeah? Sure. Along with folks online as well, feel free to message in. What are some requirements? Some whys of implementing MDR? What would be the four first requirements that you would see, okay, an MDR solution needs to fulfill to make sense for your organization? I know this is tough standing here with a microphone waiting for you to speak, but you are experts.

Just one, what are the threats that you want these solutions to counter? What is the first step?

Okay, difficult one. Well, if I was in an organization and I had a small team, but an exorbitant amount of logs coming in on a daily basis, logs that my team probably didn't have the expertise to monitor efficiently and call out incidences or know how to address them, what would be a main requirement there?

Okay, as an example. I'll start with an example. So I would like to have that this MDR solution being managed, M is managed, has a proper set of sources to consume threat information from. So the question would be where are these questions, where are these threats coming from? How actual, how current are they? And how often is this data updated? There you go. So starting from that. Any other thoughts that you have when it comes to an MDR solution? We are all just making that up just right now, just to make sure.

What would be the thinking before we get, so we are in this requirements phase, we're in the first block in understanding what the requirements are. What would be a solution, what would be necessary for a solution that you want to implement right now? Delivery model. Are there? Zero touch. Zero touch? There you go.

Yeah, so really place just as it is. So no configuration at all.

Yeah, good point. So there are lots of people. Ah. Right. So any other questions that you would like to ask the vendor, the provider of the service? Currently we're very close to the actual solution. But there might be other aspects to look into. One aspect for me would be the meantime to remediation.

Right, right. Okay, and what would be a good one? If you apply a metric? It depends on the, yeah, actually on the asset. So it's hard to say, but some vendors are talking about, I don't know, they're communicating MDR times of a couple of minutes. But I don't know how they can, if that's a timeframe that they can really provide. Would you make a difference between different types of threats where the meantime might vary?

And if so, what would be the decision point? What needs to be done quickly and what can wait for an hour? But how should you categorize that type of threat? That's also a hard point. But if that threat comes up and if you only have, I don't know, a couple of minutes to remediate the threat, I think it's, in that timeframe you can't talk about, firstly I start to categorize the threat and then I remediate that threat because the timeframe is too short to dig deep into that categorized area. Okay.

But that would be a, how do you call it, zero hour issue, which you cannot assess beforehand because you don't know it. It comes up, you need to remediate it, okay, then no big choice. But these type of incidents, they are there, but they are only a fragment of the overall threat landscape.

Maybe, just as a thought, maybe such a solution should integrate with your risk management to say, okay, I have, I want to apply my risk management because I know what is at stake in my organization and the threats that attack these assets, which are highly critical, important, mission critical, they should be handled more quickly. Maybe that's a thought that we could also involve in integration. Sorry?

Yeah, but for that you need to have a proper business continuity management in place in your organization and you thus have created a business impact analysis for all, at least for the major assets. And I think for, no, I would say most, but I think that's a hard issue and difficult thing to handle in most organizations. If you're familiar with our research, we address that holistically from a requirement standpoint, right? What are the technical requirements, which more often than not, we think more on rather than the operational requirements.

Operational requirements are just as important to bring up in these early stages. And we have more or less also different perspectives on, at least I have different perspectives. I love this zero-touch aspect, which is great. But if I have to choose what needs to be processed first, which needs to be handled first, I would like to apply a risk-based approach like analysts usually like to do.

So, but this relies on having that risk-based approach and business pay planning and assessment and categorizations and criticality levels and all of this needs to be well integrated. So, and there's a – okay, let's leave it there and I'll hand it over back to – Technically, we are now in the world where we say – No, no, sorry, sorry, all good.

So, this should be also self-learning would be one of the characteristics we would potentially apply. And a heuristic-based recognition, let's say, mechanism of the malware detection and there's a lot of what you can think nowadays, which would link again back to zero-touch because it's self-learning that's most probably zero-touch. But you also have to have, and this is I would respect, you have to have an escalation, human escalation, let's say, path. And there are a couple of requirements I listed now, but I don't want to be the only one.

Consider false positives in this sort of self-learning approach to see how high the false positives and how do you deal with them. It's supposed to be managed, but false positives create interference.

Right, and that should be part of that self-learning as well to make sure that these false positives go away over time by adding more signals to take into account when it comes to assessing these threats. Any other things? We are still close to the actual solution. What we've heard is easy to configure, ideally not to configure, just plug and play. We've heard time to remediate. We have self-learning over time. I've asked the question around what are the sources, what are you actually using from, is this relevant?

I don't want information from an ISP in APAC to be applied to me being a shop in Germany. Yeah, right, localization. So we're getting to the more soft aspects as well of such a solution.

Localized, where is it provided, how is it provided? You mentioned delivery model. Is it a piece of software that you install on premises still? I'm glad we circled back to that. I got real self-conscious when nobody elaborated on that.

True, these are the types of things. You've mentioned remediation time should be part of an SLA. SLA could cover availability, which of course everybody says 99.99 something. But the question is how good is the actual measures and what liability is behind in case they don't meet the SLA, which is also an interesting question always when it comes to that. Isn't it also isolation or, yeah, isolation? Isolating infected, so the capability to isolate.

This one, okay, these isolations. These isolations, so auto-isolation. If there's something detected, then stop everything.

Right, right. Take the endpoint out of the network or something like that. Something like that. Or on the other hand, exactly not doing that, but limiting the footprint of such a, or the explosion.

Yeah, right, right. As you said, isolation, I was thinking of tenancy. On the one hand, you want to consume that data from others. On the other hand, you don't want them to mix up your intel with other intel. So that would be an aspect maybe of isolation, exactly. So we just need to make sure part of that process should be finding proper terms to say, okay, I know what I mean when I say isolation because I need both. Any other aspects that you would want to consider, soft ones, hard ones, technical ones?

Of course, verification. It should be a verified solution against an authority. Right. Something like ISO certification or something like more to NIST or something? More to NIST or more to whatever is locally acceptable or adaptable. And maybe adaptable because if you have a global organization or at least an original one, then you are anyhow bound to several national differences. Right.

I think, and again, I've mentioned I'm an IAM guy. The information that you give them for doing this plug-and-play analysis might contain serious personal identifiable information, PII. That might be immediately a probable cause for a GDPR breach or for whatever breach you are in the region where you are. So that would be also the compliance. So it's a large picture. And once you draw this picture and you look at the individual dimensions of what you're looking into, I think that is where this analysis phase really starts to get interesting. Business model flexibility. Yes.

Because COPEX driven or OPEX driven or a mixture of both or whatever. Right. In the end, price is also always an interesting issue when it comes to providing the solution, providing 24-7 support. 24-7 support, there are more than one flavor to that. Is there just one team somewhere that you wake up in the night to make sure that they answer that question? Or are they on site? Are they close to where you are because you are internationally distributed? That is also an interesting aspect.

Again, soft factors. It's SOS again. How fast do they react in case something goes wrong from a technology platform point of view? I have something weird.

Oh, yes. Please share. Because I'm an old telco guy. So I would always ask, let's say, whether this solution can coexist with others. But you don't have a single vendor login. Absolutely. And vendor login is an important aspect because you don't have to think... Are there sponsors? I don't know. Microsoft C65. So once you are in there, to get out there is an issue. And the same is for cybersecurity platforms. And the bigger the platform is, the more difficult it is to get outside.

So the variation between platform versus best of breed or even having what you said, which is an additional aspect to say, okay, yeah, I just want to make sure that I can switch between different solutions either at run time or as a replacement. Right. So I just repeat you. Resilience says you need to have more than one solution to make sure that if one fails or just deteriorates, the other can step in. Final questions?

Otherwise, then we would move on. I'm always all the time carrying around the clicker, which is not that intelligent. That's okay. You can be in charge of this one. So that would be the first group activity more or less. So just making sure that you... What I wanted to achieve with that is that you think broader and that you think not only of a tool but of a solution that you want to look at. Maybe also segues over to that. When it comes to the enterprise and the market analysis, we have 30 minutes left. I'll make it short.

I mean, this is also just to summarize the activity and why it's important to really do your homework up front. Understanding your organization, your capacity, change management, cost structures, your business model, understanding everything up front, doing this homework could really mitigate a lot of issues down the road.

In my aforementioned previous life, I used to talk to organizations all the time, and I just would feel so bad for them because they would dive into these really cool tools and get money for these really cool tools, and I'm just sitting here thinking, you don't have the capacity, man. I'm going to talk to you in nine months because you're not going to have this implemented. It's not going to have the return that you think it's going to have because you're not setting yourself up for success. You're not asking yourself, why are we doing this? Why are we implementing this?

What's going to be on the impact internally once we do, if we do? And then when you talk to vendors, I really liked what you said earlier within your methodology. Do not talk to vendors up front. Do not. Talk internally. Figure out what your goal is, both technical and operational. Talk to your teams. Gauge where they're at, where you're at, where you want to be, right? And then still don't talk to vendors. Do more research. Figure out what the market is doing. Go to conferences. Talk to peers. Call up Matias.

Say, hey, this is where I'm at. This is what I want to achieve. I don't have the bandwidth to do this assessment. Can you come in? Can you help me out? Can you talk to my guys? Can you figure out what's going to set me up for success? Right? Do your homework first so that you don't look like a fool later because then when you talk to vendors, you'll be driving the conversation. They won't be. And no one's saying they're doing this, but you want to be in the driver's seat because you want to get a solution that's going to set you up for success, your company, your customers, your team. Right?

So understand the why and the impact internally first and then have conversations with these vendors. One additional aspect. What we don't say is, now you're at this great event, the cyber revolution, outside our vendors. We don't tell you, don't go out there and talk to them. That's not what we're saying. What we're saying is gather the information that they give you. That's great. But don't raise your current detailed problem and make them the only ones to reply. Make sure that you have a bigger picture that you get.

And this is the role of analysts to say, okay, yes, really, we want to make sure that you get the right solution and we are happily cooperating with all these vendors outside, which is really great, and having their innovation in place. This is not what we're talking about. The question is, when it comes to the tools choice process that we're just looking at, how do we get to the proper solution? And then you need to understand what the individual vendors provide. You have your own knowledge.

Of course, you can talk to them, but don't say, how would you solve my issue? You can even ask that question, but then to say, let's take a step back. Is this the one solution that I want to have? And maybe I need internal support. Maybe I do some online research, if this is fine and enough. And maybe I need some support from peers. Talk to other customers or organizations who have already done that. Leave the analysts and the consultants out of the game, which is fine. Just make sure that you have a broad view on the topic. So it's not talking to the vendors.

It's getting the broader view of it. That's what we're advocating.

Yeah, don't ask them to solve your problems. Use them for research and understanding what's out there. And then once you know how you can control the conversation, once you know what you need, then engage in a more deep level. And this helps you then in communicating with the vendors because you're reaching out to them afterwards. And ideally, you're reaching out to the right ones. And they can help you better, right? You can shorten that sales cycle as well. They can understand whether or not they need to connect you with a solutions provider and shorten that conversation as well.

Okay, sorry. I'm sorry. Your show again. Here we go again. Here we go again. Second part. This will work better, I'm sure. We've talked about solutions. We've talked about SLAs. When you are in the buyer situation, if you are the ones who are executing such a tools choice, you want to understand also the provider of the service better. So this is the vendor perspective as an organization. And sending these inquiries to vendors, this is something that we do, of course, as analysts because we do these research documents.

So we reach out to them and say, how are you funded and all of this kind of stuff. And maybe we can get to a few interesting questions that you are typically asking, not necessarily us. We want to learn as well. So what would be aspects that were interesting to you as an organization when you are choosing the right vendor for yourself? These questions can be so varying. We see that with our customers as well. I don't want to take away too much. You've mentioned you're a telco guy. So telco is huge. Does this have influence on the type of organizations that you want to work with as vendors?

Or do you have more choice? How does this change? That's really out of interest right now. Now I'm learning. Then you need to know, if you are coming from telco, then many of the cybersecurity thoughts have always been thought implicitly, let's say implicitly already. Now this secret, let's say information secret, is anyhow the top priority. So that's why. But there are other principles which vary from IT. So much of this, let's say, quality and resilience thinking is deeply embedded into the components already.

So any product which has been used in a telco environment has a, let's say for instance, reliability tick, which is much higher than traditional IT. So this gives already some impact. So normally in IT you talk about 99.99. Telco you talk 99.999 at least. So this is already something. The second one was this, let's say, flexibility or this coexistence of different suppliers. This is a typical. Interoperability.

Yeah, interoperability is a typical thinking which comes from ICT. And of course, with that approach, you may have a preference for companies who have been providing already solutions to telcos. So I could write books about that. So when you try, for instance, to build a higher level, you would call it application level. From IT perspective you would call it an application software, which is providing, for instance, core network functions with regard to user authentication, authorization, etc. If you take their solutions from the IT market, they are not prepared for this 99.999.

And if you just take them, you have a lot of difficulties and problems in mutual understanding what you talk about. Because on one side, the telco side is implicitly assuming that you understand, and the IT side is not aware of that. But we could give workshops on that, because this would a little bit explain also where the different thinkings at the moment, even locally, regionally, even globally, collide with each other, and where even principles fight desperately against each other.

That's the reason why we had on the first slide, one of the first slides to say, okay, where are they coming from? What are the industries they are typically serving? Because that has an influence also on the way how they provide services. I know everything about 5G, giving you a very simple example. You build an OT network or an IT network, which is operating for OT in an industrial environment. If you ask for a telco solution, everything is in.

If you ask for an IT solution, then you have to bring the cybersecurity means, you have to bring the key management, you have to bring everything which is already built in on the other side. You see how different that can be.

Or, giving you an example out of the health industry, securing health communication between the practices of doctors and, let's say, the central database of the health insurances. A telco guy was only surprised how it could happen that you have been mixing up your VPN root certificates and then you could not reach 88,000 practices for half a year and you had to do everything by hand. A telco guy says, are you going nuts?

You see, and this is exactly different thinking in this aspect. So you asked, I gave a very comprehensive answer. I only wanted to give a comment. It's much better to be in the buyer's situation than in the seller's situation. That's true, but I just have a simple question, at least for those who are in the buyer's situation, and even the vendors are typically sometimes in the buyer's situation as well. If you think you have found the right solution and it's really a good match, but it's a startup, does that influence the decision? Just yes and no. Have a yes? Would it be different? Yes? Sure.

Right, so you're missing the references. So on the paper it looks good. Maybe even the POC, it looked good, but it's a startup. Do you know they will be there in two years or if there's a technology buyout or whatever? So that would influence your decision. Is there somebody who would not care and say, okay, I'll take them afterwards. If they go from the market, I'll buy them. You would care, so no other opinion in the room. Okay.

You know, this is a perception. If the solution is outstanding, then you would try to safeguard. Then you know it's outstanding, but it's a startup. So you do know the risk precautions. Maybe you even take a share or whatever if you're a bigger enterprise and you can afford it. Take a share or you try to... Or you made them that they give you, let's say, more... or they safeguard the path of transition already. If the ownership changes or whatever, so maybe even escrow. No idea. Something like that. I used to be in a buyer situation. It was lovely.

Yeah, but exactly in that situation, that is also where this workshop aims at. Of course, you can turn the perspective around in the back of your mind and say, okay, what do I need to do to be good in that? So that's a different game, but this is how we used to do it and how we recommend that you just take away that methodology, as I said. You get the slide deck, you get all the notes. Maybe we can give you these questionnaires, but they are not surprising. These are Excel sheets with questions and ratings and weightings, and that's it.

If we look at this list of the areas that I've mentioned here, company details, market details, are there some aspects that you would like to highlight that are important for your organization that you would stress immediately? Maybe...

Sorry, it's great that you contributed, but maybe somebody else? Just looking around?

Otherwise, I give him the microphone. Nope. But I would like to expand on the point that you made, being the buyer versus the seller.

I mean, asking these questions up front can help you out in the negotiation stage as well. So, for instance, if you want to take on your larger organization with the money and you want to take on the risk, okay, if this startup fails, from a business standpoint, are we prepared to take it over?

I mean, I've seen that multiple times, but having that understanding up front prepares you for these conversations down the road. It shortens the sales cycle, which is very important. It's not a fun process. Okay?

So, kind of the reason why I'm here as the digital product manager, we've been talking about ways that you can do this homework up front, and the ways that Cupping or Coal offers you to enable you through this process. We've talked about our advisory services, tool choice, our research.

Last year, or this year, we came out with a new tool on our website to enable you to do a lot of this research on a high level, right? So, you're asking the right questions and you're guided in the right area. We mentioned earlier, you know, not talking to vendors too early. That's only to say that you want to know what you're asking them. They want to help you, right? They want you to be successful at the end of the day, but you need to be able to articulate what success means for you.

And no matter where you're at on your journey, whether you're a very robust, secure organization that wants to modernize or scale or what have you, you know, projects are always new. New projects are always a big task to undertake.

So, where do you find this information? I mean, we talked about security companies popping up left and right.

You know, with that comes more information. You know, you can't really just Google, you know, PAM solutions and hope that the appropriate one comes up for you. You might not want to read a 150-page LC or have that time to weed through it.

So, how do you go out and find information in a way that helps you build your business case? With KC OpenSelect, you can go in and ask those questions, figure out those questions.

You know, what are the technical requirements that I need for this project? What are the operational requirements? How do I put those two together? How do I articulate that to the business? What's the market like? Where is it headed? What appropriate questions are there out there to ask vendors? Giving you a starting point, right? And then what vendors are out there? I've talked a couple times about, you know, not just going to an LC and picking the highest-ranking vendor. It doesn't mean it's the vendor that's right for you, the solution that's right for you, right?

So, understand where you're at today and where you want to be tomorrow, and that'll help you out through the selection process. And to enable you, we offer this free service to discover more, access the latest content out there, all produced by our analysts, backed by a myriad of pieces of our content.

So, not just the leadership compass, the buyer's guide, the market guide. Understanding where this particular area is and where it's going in the future so it could grow with you. And then help you evaluate on a high level.

Again, it's very hard to translate all of these needs into a business case, you know? How are you going to tie your project to your business goals at the end of the day? That'll enable you to get the funding that you need, the resources that you need. And I think I'm going over time, but if you have any more questions about KC OpenSelect or how to use the tool, essentially an area where you can find this information, you can select your criteria, your features, filter them out, and it'll populate a list for you based on those particular requirements.

You can share this content, you can interact with this content, you can reach out further for more questions, but it is just one way to enable you to build this foundation. Okay, and just to mention it again, one could say, okay, now we've come to that part in the workshop and now they're promoting a solution that they own.

Yes, but it's free. You can just use it. That's the good point about it. You can use it and just use it for creating a short list, creating something that helps you in not short-circuiting things, but to help you to answer your questions based on that tool. That's the reason why we wanted to highlight that here. So when it comes to the final 10 minutes, I want to wrap things up. I want to give you a chance for feedback around the whole workshop because this was a test. But nevertheless, we want to also make sure that you know where to get more information and whom to reach out to.

Not to sell anything. We are happy to sell things, but this is not what this workshop is about. We want to make sure that this methodology is well accepted and used. So why are we doing that? Six good reasons, and I'll put them to the left. And I think to the right, it's just the process.

Again, this is what we've seen before. So this is just illustration. Ignore the right part. Six good reasons is, first of all, we do this because we want to ensure functional adequacy. Solve your issue, solve your problem for today and for the next 10 years. Secure commercial viability. Make sure that it fits into your spending situation, that it achieves what you want to a price that you want to pay. Make sure that it fits well into your organization, into your processes, in what you want to achieve. That is the strategic part. That is maybe the simplicity part. Sorry for that.

For the simplicity part that has been mentioned, how does it fit into your organization, into what you want to achieve? We want to make sure that it supports and enhances your cybersecurity processes. This is a cybersecurity conference, and it goes beyond that. So a solution that you choose out of the possible choices that you have should make your overall cybersecurity situation better and substantially better. All of this leads to a management decision. Usually the project leads don't spend millions on a solution and a project. They don't. But they prepare this information.

So we want to enable those who are in the situation to preparing this decision-making process to provide the right information in the right format to the right people. That's what we're aiming at. So facilitate informed management decisions. And this is sometimes difficult. Who has ever written a management presentation that has to have everything on one page and seven minutes or this typical elevator pitch? And then lots of money is spent on these very condensed information. This is not an easy task, but the information that you gather throughout this process can help you in achieving that.

And that's what we're aiming at. And I think the sixth one is the most important one after having stated all of this. What happens if somebody says, hey, you made that decision two years ago. Look what has happened. How could you do that? Why did you do that? This is a documented process. This has agreement by all of those who contributed if there was a company. And this is something that you can use for justification to say, okay, if we would have done it that way, it would have worked. It would have been better. It would have been more efficient. We would be alive nine months ago.

So this is a bit of cover your back, but it helps. It's also important. I think that is an important part of that as well, having a well-documented audit trail of what you did. Summary. I get to the first point at the end. Last minute questions, concerns, clarifications, contradictions against the process. Maybe people don't like questionnaires. I don't like them either. I produced them. So first of all, starting at the below point, these QR codes lead you to research, free research. So the leadership purposes, they are not free, but you can apply for a free account for four weeks, six weeks.

I don't know, four weeks? Four weeks. Four weeks. So you have full access to that. So if you go there, so still nothing to sell.

The video, Philip and I had a podcast around the five most common problems when choosing a new tool. And this is even a bit fun. And OpenSelect, of course, is also there. So these QR codes lead you directly there. And the links should work in the PDF version of the presentation that you get in the app anyway. Are there any last-minute questions from your side regarding today's workshop? I'll take this as a no. If you do have questions, probably most around KC OpenSelect, I will be at our booths later.

Again, it's a free service. It's just to enable you, right, to get you kick-started and to understand what's out there. It's foundational stuff. It's not supposed to be comprehensive. It's not supposed to be groundbreaking. Please do not base all of your buying decisions off of it. But it gives you a jumping-off point, right, an understanding of what's out there. It's a great way to discover vendors, what they have to offer, how they compare, how they'll fit within your particular requirements.

And again, it'll give you an idea of what questions to ask, give you an idea internally and externally. It'll lead to more research, more ways to discover. But it's something good to start with because there's so much information out there. It's hard to weed through it.

It's free, but you do have to register. KC OpenSelect is free to use, but you have to register. But you don't have to be a subscriber. No. Let's make that clear. Free. We've mentioned free. Free tool. We just get your email. Exactly. For some definitions of free. Yeah.

Okay, then go up to the last minute questions, concerns and clarifications. We've mentioned that. Nobody left the room screaming. That is good. Thanks. So was this useful? Just something that you can take away home and say, okay, let's use this for the process that we do. That was my aim. And if you say, okay, that was good that we do anyway, and that is not important to me, that's fine for me as well. But was this useful? Take this as a yes. I skipped the other question because nobody dared to say something like that. Could it have prevented some previous challenges?

Maybe yes, maybe no. But a proper process always helps. Final thoughts. Christy mentioned that already. Feedback is welcome in the app. Keep in touch with us. Write mails. We do answer. Promised. I'm not a sales guy. You're not a sales guy. You're digital services. I'm an analyst special advisor. So we're not selling anything unless you ask us for it. So just reach out to us. We plan to have this workshop together with Shika because that's the reason why there is a third address, but she will reply as well. So just keep in touch with us.

And most important, if you are in the room here right now, and unfortunately the other person had to leave because of the phone, but if you think that was interesting to you, A, and B, you think collaborating in such a group of people, just networking without us is helpful. Networking with the vendors on the level that we just described, this is so helpful and so important and getting in touch. So across industries, share your experiences, even the ones that you did not want to share with us because there is a camera and there is a microphone, which I fully understand.

Just share this with a coffee later or tomorrow or on Thursday. Share best practices. Help each other. This is something that we try to do, and we try to gather these best practices as analysts and advisors. But if you do it on a peer-to-peer basis, on a networking basis, this is so important. So ideally share your contact information with the group of you, leave us out, after the workshop and stay in touch if you think this is helpful and if you can exchange experiences. And if it's not that group, maybe it's that group in that building. That's it from my side. I think we're quite on time.

Yeah, one minute left. Final thoughts?

Three, two, one. Yeah. Thank you very much. Thank you. And enjoy your lunch. Yeah.