Expand your GRC Controls to Cover all Systems - How to Make SAP GRC Work in a Heterogeneous World

Good afternoon, ladies and gentleman, welcome to our KuppingerCole webinar. Expand your RC controls to cover all systems, how to make arc work in a heterogeneous world. This webinar is supported by cross ideas. Our speakers today are me Martin, our founder and principle Analyst at Ko co and Marcou vice president alliances at the cross ideas. Before we start some general information on some housekeeping call Analyst company, providing enterprise it research wise services, decision support, and networking for it professionals through our research services, our advisory services and our events.

Our main event is the European identity and cloud conference, which will be held next time, May 14th, two 17, 2013 in Munich, an event you definitely shouldn't miss it's about so leadership and best practice digital ID, cloud, and GRC regarding the webinars and guidelines. You are mute centrally, so you don't have to mute or unmute yourself. We will control these features. We will record the webinar and the podcast recording will be available latest tomorrow, by the way, the slide X also will be available latest tomorrow. And finally questions and answers will be at the end.

So you can ask questions using the questions through the right side of the screen at any time. Usually we'll pick them at the end if appropriate. We might pick questions during the webinar. There's a lot of research at our website. So have a look at a call com slash reports. And several of these reports are related to this webinar, including our GE reference architecture. Our scenarios are understanding the future of it organizations and understanding it service and security management and our product report on cross ideas. S so let's directly move over DM agenda.

This is split into three parts like usual. The first part will be done by me. I will talk about sort of complete GRC picture the role, a GRC blazer in and how to expand approach to hetero environment. The second part, then mark will talk about how to extend a GRC in practice to implement and manage access governance and heterogeneous environment.

Finally, we will then have our Q a session like I've said before to start with these things and to set sort of the bigger pictures, the ones of you who have attended other webinars probably are very familiar with these slides. I think there, the fundamental, those are view, the fundamental thing influencing it in these days is what we call the computing or cloud computing with new deployment model, social computing, with new user populations, mobile computing with new device types. That also means that we have to, to change this code for information security. We have new users.

We have also new users accessing enterprise systems. We have other deployment models. We have hybrid models where we have to integrate cloud and internal models. We have to access our environments with mobile devices, etcetera, et cetera. And that is a change, which means we have to manage information security in a far more complex world than before. And the scope is bigger.

We need new approaches, and we need to think in this big picture, instead of application centric or system centric approaches, which are focused on only in specific areas of our entire environment, that those in line with what we call the need to share, moving from centralized infrastructures, like in the old mainframe days, or PCs, internet, business partner integration towards tight integration of customers and others, where we share far more information where we have to manage this information in a consistent way across all our environments.

It's not about our central core business system itself anymore. That's a major part for sure, but it's not the only thing. It's the situation that we, the fact that we have information everywhere used by many different devices, different users, and we have to manage information security and access in this increasingly complex environment, which also leads to a situation which I think many organizations observe, which is the gray line, sort of auditors are looking at these things. They look at access, they look at information security, they've have their findings. There's a lot of investment.

There's switch to panic mode. Findings are addressed costs, go down a little, the next audit happens.

And again, it starts. And what you have to do is to address these things strategic. So you have to understand how to deal with it in a way that you are working to the business, that your business gets better instead of always running behind the auditor. So move away from these tactical things from being pushed by audits, work toward business, by implementing a strategic solution, moving forward. There's always, then one of these, these problems there is that you frequently are in the struggle where the business has.

We need speed, agility, flexibly, change, and things done short term, whereas it, if it right, things about stability, security control standards, long term things. And I think it's important to find the balance between these things. So supporting business as good as possible, but having in mind how you can move forward towards more stability, more security, more control, more standards.

So having this long term perspective in mind when doing short term steps, when doing short term actions, and I think what we shouldn't underestimate is that it sometimes is more risk aware that area than businesses, at least when it comes to it risks. So it's a difficult balance we are in and building a QRC infrastructure definitely helps in moving forward. In many of these areas, our general view on this is what we have described in our future. It paradigm the guideline for the future of it.

So how to structure it, which is around how do I do you manage all the deployments models in the consistent way? So they are just down there. These are deployment models on premise cloud and all the mixed approaches in between and in the middle there's service management there's information management and information management is first of all, managing this information, which then is supported by the information security on the left hand and the it governance on the right hand. And it governance part is a very important thing. And it's at the core of what it has to do.

We need to manage information. We have to enforce information governance. We have to enforce information stewardship. And by the way, there's a new report out there around information stewardship, which is available to our website. And when I take this it governance and look at the sort of the next level, then, then we have this bigger picture of enterprise governance where we have more, the it governance part services and information. And on the other hand, the business governance part process management, risk management, enterprise governance, then providing the dashboards.

And we have to think about the entire she CD in a consistent way. It's about understanding that enterprise governance is not done by process management or risk management for some few enterprise systems or even abstracted from these systems sort of replacement of, of excels files. It's not done that. It's done by having an integrated view in this. That will be sort of the, the key theme of my presentation within the next few minutes and risk amongst all these things we are looking at from sort of the pure business perspective to everything we do in it. That's the common element.

It's the common element was in regulations. It's beyond regulations. So many regulations, which most regulations deal with risks. Auditors look at risks. And if we don't fulfill regulations, it's the risk.

And, but beyond those, there are also risks, which are not regulation, which are trust, purely business risks, where we can lose money, et cetera. We have to look at risks. That's where we start. And that's something which is the same for it for business. It's the same for our systems where we might share just some word documents with some customers or whatever. As for a business system. It's always about risks. Risks are when we look at risks, then it's about threats. We are facing about probability of them, about the impact they have on our assets and on our business processes.

And when we look at the, this, the different types of risks, which usually are distinguished, and there are the strategic risks and the operational risks, even more frequently, see reputational risks as a specific form of this, where you might say the strategic org operational and it risks that it risks in fact are from business perspective, frequently handled sort of separately. However, the only reason why we look at it risks is that they are either operational reputation or strategic, or maybe even strategic and reputational, or are combinations of this.

So that's the reason why we look at it. And within these risks, access risks are one of the most important things. So we have to understand that access risk is one of the most risks. I recently at a survey where the, the managers, the CEOs estimated the value of information assets has run about 50% of the overall corporate value. So information risk is one of the biggest risks you are facing in the organization.

And you not need to know about information, understand the risk associated specific information, mitigate these risks, especially the biggest risk by setting focus and where the balance of risk and reward fits. And what's important around this is again, that's not something which is just related to very few core business systems. That's related to a broad number of systems. So every type of information can be at risk. And if it's CAD inform, then this is a specific part of the risk. There might be things which you write down in your invert documents.

So new concepts, cetera, which are a high, highly valuable information assets. You have to look at all of them and understand where risk it's not only single system. So moving forward to, to QRC itself, I've took this picture out from the QRC reference architecture. I've mentioned before a report we've published around 2009, which explains the standard approach on, on how to deal with QRC. And it's always the same. It's about requirements modeling about status investigation, about improvement activities, and having a crisis, an incident management in place.

The more you can do preventive, the better you are from the other hand, your reactive part as well. And you need to support this by tools. There's no way to successfully implement a GRC organization, a GRC environment, GRC ecosystem in the organization without adequate to support. So it's not only about manual controls because manual controls where you ask some managers from time to time, whether they see a risk cetera, or how they rate risk. That's something which needs a risk real time nor reliable. So if there are several risks, people sometimes tend to lie.

And if you detect the risk too late, you have an issue. So you need the right combination of automated controls, run all types of risks, access, risks, and all the other types of risks you're facing. And you need manual controls. You need to mix it and you need to support this because automated means tools. You need to support it by tools.

However, hi, I've heard the reality is that the world of GRC is sort of pretty yeah. Done by very separate solutions. So you have your tools which are called enterprise GRC. In most cases, they are more business GRC. So they're focusing on the small portion of a business view, lacking the automated control support. You have the it risk management, you have operational risk management, access governance, and a lot of other of these bubbles like CCMS. So continuous controls monitor.

You could add steam when it's more about really security incidents and other things, which is also part of the share because it's about threats. It's about impact. It's about something that can damage your business and doing this is really ignoring risks. So you need to understand that there's a relationship between it risks and business risks. And you need to understand that operational risks can turn into strategic risks and that they're just looking at it risks because they have some effect on the business.

I think that's something we all have learned over the last years, that pretty bad things can happen there. So CRC finally has to be consistent. We need to have a consistent view on these things. And it's really about many. If you separate these approaches, it's about ignoring risks within it. So business processes never rely on SAP system, only sensitive information isn't held in SAP systems only think about experts from SAP systems, think about documents and all the other things sods can cross multiple systems.

Especially if you look at finance industry, for example, where you frequently have a lot of core business systems, which are another SAP, then it's within it, doesn't make sense to separate it fully. You have to integrate it. You have to understand how can you build an integrated approach within it and beyond it. That's what you really have to look at. And for that, you have to also to understand the complexity of these genius environments. You have business processes, which are spanning multiple systems information held in multiple systems.

And in fact, there are different systems with different approaches. You need to understand that is a more complex world where SAP is very important in many, many organizations. And there is a good reason for, but where not everything happens in SAP. And so that means from a GRC perspective, you have to look at it in a way which there's okay, there's SAP, but there's more. And if you look at SAP GRC, what it provides, then it's risk management. There's a D controls process controls and more industry, or, or, or regulation specific solutions, global trade, environmental, et cetera.

What it lacks is a full support for heterogeneous environments doing central dashboards, industry specific oration risk management features specific it risk management, especially again for heterogeneous environments. And it also doesn't provide the sort of the point solutions are you. You want to call it like access governance, cetera. So the more specific, more in detail, more in depth solutions you have in the it space. How can you, those, there are there's opportunity for custom build solutions. So there are web services which are provided by SAP GRC.

There we can build other types of customer solutions. You can deal with Greenlight versus SAP partner, which extends the reach of especially SD controls of SAP GRC to other business systems. You have some support in the area of that. We identity management. I discussing provide you for example, full access governance for other systems. So there are different ways to do it. And in reality, it's sort of, you have different things you can reach.

So there is sort of a QRC readiness of information, which you have, for example, in an access governance, which is more cross-platform or in systems specific solutions like SAP GRC, a P GRC has a very much depth within the SAP world, but not that much in the rest of the world. Access governance tools of other vendors usually are very good cross platform, but not necessarily that much in depths like SAP arc, besides the fact that they don't support things like process controlled usually. And then you have the lower level tools, which like usually the GRC readiness.

So you have definitely, you definitely have to do something around specific GRCs users, but the questions, what do you do? So it's the dilemma between detail as for particular systems and the coverage of all systems, where you have to find your way in, from our perspective, a complete GRC ecosystem really looks at the framework policy, organization, controls framework, business GRC, and the it GRCs occurred. So CCM I T risk management, access governance, scene, cetera, bringing these things together and around an ICP GRC.

It's where we need a GRC framework where we need enterprise dashboards support for specific regulations, in some cases, specification or risk management, heterogeneous it risk management. So really diving deep into the details of the rest of the it world.

In fact, heterogeneous it GRC. So that's the view. We should have understanding that this is a bigger story with a lot of different elements on within these elements. Access governance plays wider role where access governance, in fact integrates with business GRC and there potentially with an SAP GRC you might have, or you might want to implement to really provide the bigger picture, but also to provide very specific functions around the in depth functions. You need to manage access and information security across a multitude of systems.

So how to manage access risk in a heterogeneous environment. I think there are two sides to the organizational side, the technology side, organizational wise, it's about building a common framework. So one approach for processes and policies, one terminology, consistent role approach derive from business process, cetera, really having a framework here, responsibilities and all that stuff. Technology side go beyond SAP support ensure that they're good in SAP, but look for the good citizens, which help you to form the big picture of cheer C beyond that. And they are good citizens out there.

They're good citizens which provide you some more, maybe enterprise dashboard things. There are good citizens which can integrate information into SAP GRC, and especially there where SAP GRC plays an important role. It's important to look for these good citizens. Yeah. And I think that's really the thing and what you also should keep in mind.

That's my, my final slide. We'll send this quick walk through, through my slide deck. It's not only about compliance. It's also about business performance. So by doing RC, right, you also have a lot of strategic value, risk mitigation, deeper insight into what happens in the business, analyze issues and depths quickly business performance also understand where business doesn't operate well, where business controls are met. And that's what QRC finally has to provide across all of your environment. So continuous well blend structured, GSEs key.

It has to be something which done by a combination of automated manual controls and which is really built to serve your entire enterprise. Not only a part of it and SAP GRC is for a good reason, a cornerstone of this, but what is important from our perspective is you need to add the right elements around it. So that's where I hand over to Marco Auti. Who's right now talking about how to extend SAP GRC S practice to implement and manage access governance and heterogeneous environments. Okay.

Thank you, Martin. And thank you all for joining us today. Yeah. My name is mark Vinti and I'm responsible for alliances at cross ideas in the following currently minutes. I'd like to briefly tell you something around our company around cross ideas, which is a name that probably most of you never heard before. And then I'd like to touch on our dualism, our preferred topic, which is control versus simplicity, and also rising the key question that in our opinion need to find a meaningful answer. Then we'll look at the sort of control, meaning the sort of control types and possible approaches.

That really makes a difference in the way the topic get addressed. And then we'll look at how to extend beyond the SAP boundaries, the same sort of control we have been talking of, and this will bring us to conclusion. So a few words around cross ideas.

Again, cross ideas is probably for most of you, new name he's a Italian player is the European player is one of the few European players in the identity access governance arena. And we are consistently recognized as innovator in the way we approach the topic. And we believe that we do really enable organization to achieve compliance, audit and access risk management. Objective is a new name, but the company itself dates back already 10 years used to be called web security at the beginning.

And it changed name only one and a half year ago when the management buyout turned into turned the company into a European international player while before it was only original, only an Italian one. But since the beginning, the company has been approaching the topic from bottom up in a bottom up approach, I should say.

So starting as an authorization management solution provider, and then moving on, what is identified usually is identity management space in terms of capability and only more recently getting to the access governance, but still keeping the entire stack of solution into one single current model one single current solution approach. That being said, today's conversation is around as I anticipating the agenda around the dualism between control and simplicity.

What I mean with that is that obviously we do need to have confidence in meeting our compliance objective, putting in place the right side of control that we are required to, to deliver. But at the same time, also making sure that we can actually maintain control on the controller itself because the stacking of software layer to implement those control is growing over and over more complex. And this is supposedly challenge itself. So it's a sort of recursive things about the complexity of the overall infrastructure that I need to take under, under control.

This brings us to what we call the successful compliance control implementation checklist. There are three things that really drive what we, what we design. First of all, implementing control. I should try to minimize the number of moving parts, meaning the number of software component that I need to deal with. Obviously they'll lower the number, the easier, the maintain, the maintenance of the infrastructure. Then I should try to minimize the number of configuration item that I need to deal with to implement the control I'm required to, to fulfill. And finally, that's very important.

I should make sure that those control are implemented in a way which are easily readable to who whom is ultimately required to check them on a, on a timely basis. And this is again something which is not really so straightforward for some of the solution that you find on the market. So let's have a look what it means if we kind of drop those question on the SAP specific world and to put it differently. The key question that I would like to address in the following slides is that SAP required dedicated approach to be properly addressed in terms of compliance.

And if yes, I'll do then address the known SAP world, or maybe to put it differently, can I reuse, can I leverage the investment in terms of modeling of what I've been doing in, on applying your on SAP also for other application? That's what is going to conclude our presentation in terms of answer, but before getting there, we need to spend a few more words around access control, themself, what are access control? Because we keep on talking on them, but many people are not really, let's say consistent to referring to the same thing with the same wording.

So just to be on the same page, let me just up, what is our view on access control? So, first of all, there are calls of multiple types and this side with this, I mean, things applicable both to SAP, but also to non SAP world controls like segregation of duty and sensitive access. That's probably no needs to go into details about this and they, we will have more details later in the presentation, but then we have other sort of things like out of role control.

So meaning how far am I from the distribution that I'm expecting on the current organizational structure of remission, just to drop an example, is there anybody outside the finance division that can do purchase or recreation or out sort of control like out of bank changes? Am I sure that I can detect if somebody inappropriately or inadvertently change, what is a, a role composition like that sort of things then other regarding the so-called orphan or service account?

So those user, which are not necessarily bound to an identity, I need to keep an eye on them and they deserve special attention because they can be easily exploited for attacks. And finally, so monitoring the sheer number of things that are flowing in and out and dropped on each user or another entity, just because sometimes they reveal behavior that are suspicious. Those sort of control are the key things that I need to put in place. And I'm not saying that each and every customer is implementing the mold, but rather than priority may lead to one or more of this source control.

Anyway, what I see when I look at the use cases, when I look at the functionality that is the analysis control system is delivering is one or more counter measure. So things like notification and reporting Orion assignment or recertification campaign or workflow processes are the tools that are used to enforce the control presented in the blue pillar.

Now, if I look at this side of control, well, this probably most of you would, would, would recognize that sod. Sod's probably the one that is prominent in terms of numbers. At least it's by far out numbering, all the other combined because the number of constraint that I usually face whenever I had to implement an sod sod policy is easily in the hundreds okay.

Range, so that it deserves special attention. And that's why if we want to minimize the number of item, which was the middle item in my checklist, that's where we need to focus. That's where we need a special attention. So let's have a look closer, look on what is so like, first of all, sod has to do with business role sod coming usually from auditor recommendation. And they think around SLD in terms of conflicting business activity, that's where they do start from.

So here I have an example of what an auditor did provide to one of our customer in terms of recommendation about SLD constraint to be enforced, to be put in place. And if you, well, if we had the time to read through what is this Excel spreadsheet is, is including well. And so you need to trust me here.

Well, it complain, it includes that details around one business activity. In this case, something regarding trading, the trading business that is in conflict with another three business activity and with some specific details around what is the conflict severity and details about. But in other words, what I have here is an absolutely known it description of what is an necessarily conflict.

Now, this sort of input from an auditor is what the auditor is gonna check later on when we will be done in terms of implementing the so constraint. So the way we proceed from here is to pick this sort of input and to convert it into a tree like representation of the various activity, the various business processes, I should say, that has been listed in that, in that recommendation spreadsheet.

Or maybe if I don't start from in order recommendation spreadsheet, I can start from other system already in place in large company, maybe other RGO system or process management system to build this three, or if no, there's no such thing I can reuse templates of similar industry company. Okay. So as a starting point to build up my business process three and adding this three is the, to model the SLE constraint.

Again, most of the time coming from the recommendation that the ABI auditor compliance officer came up with, and this is again, a pure business conversation, nothing to do with the at, and thus the question becomes, okay, so what is the at involvement like if this is the starting point, what is it gonna be the at contribution to this?

Well, first of all, the at tends to think in terms of roles, that really the key when it comes to talk to, to talk to D at roles are obviously well known and absolutely wonderful way to properly manage provisioning to properly minimize the number of assignment or user clustering commonalities along on similar permission to be delivered to similar user. But unfortunately most of the time Porwal don't care about roles or more, more appropriately. They don't trust the roles that the company's been putting, putting up over time.

And there is a very good reason behind it because very frequently, if you, if you wish I, I can, I can go through this, my geographical like analogy, you have roles that for instance are named Germany, but in reality, they cover much more than just Germany. So what I'm saying is that they auditor tends not to trust world because it's not true that they spell, they include exactly what they spell like. So they tend to, to skip it, to ignore them, to go and check directly what user are entitled to do regardless.

The name of the role they are assigned to, or maybe just to include role themselves as part of the thing that should be checked, that should be monitored. That should be part of the audit. Now this means that roles which were originally meant to provide a business abstraction, a business, readable abstraction out of the it title, the name are not trusted. So that translation again is not trusted too. And then I need to find another way to make some sense out of the it jargon that it permission exposed.

That's why, what usually is the path like is to go through the notion of technical transformation. And again, here is a plea with, of the business activity tree that I introduced earlier. So that tray needs to be translated into what it permission are serving each and every meaningful business activity. And that's the task.

And again, that is about doing logical links between things like purchase order creation and the relevant permission that serves that specific business activity. This is something that may vary in the way it perform depending on the application I'm looking at. And that's where SAP is a different animal compared to other. So what are this entitlement like? What level of granularity should I be looking at? If I look at a generic application?

Well, the, the, the rule of thumb is just pick the finest possible grain that you can get access to. So if you talk at directory, you should probably look at Brooks. If you have customer application, well, that's a case by case description definition that it really varies, but if you talk SAP and if you have SAP within the boundaries of your ring, well then notion of entitlement is not just a single thing, but rather a combination of transaction plus authorization object plus specific parameters. For those of you who are familiar with the optimization model of SAP. So it's a complicated thing.

It's something which is not really straightforward to be defined. And the good news is that there are some products, including for instance, SAP, G CS controls. There are chipping with predefined description of what this business translate, sorry, this technical translation is like. So they include already a mapping between the business processes and the authorization details at the finest grain in SAP language of what is required to actually perform a specific business activity.

So this means that I'm not just talking technology, I'm just also talking of content that is speeding the approach and is keeping it simple, as simple as it can possibly be. So putting the pieces together, the approach that we, we, we follow and that we look at is made up, is made up of multiple components.

Well, first of all, there are users and roles made by the company. And that's where the, as is status that we do find in each and every customer we visit and that what the auditor are typically looking at that, where they do apply their analysis. Then there is the activity three, that's the one coming from, from the auditor recommendation, from pre defined content.

And what we need to do is to deploy the technical transformation, asking the application owner to do that, or using existing content coming from solutions that are specifically addressed in the European or D SAP environment to speed up the process. So once I have this model in place, I have the ability to perform a analysis on users. So really identifying user, which are involved or are in a loop. If you look at the graphical representation here in a loop that starts through an sod violation.

But what is interesting is that I can do the same on roles I can identify which roles are actually including natively some violation and thus delivering violation to user if they get assigned to it, which is a far different conversation, which involves different player in the company to, to, to make it better. So this is not something for, for the business manager is something for the application owner in terms of relevance that is increasingly relevant for most of our customer.

But bottom line, what I we describing here is a dual model that cleanly separate access delivery, which is managed through roles versus access control, which is managed within the notion of activity and the clean separation between delivery and control is really what is key here, because this is really what can, what can be applied in the most effective way, both to SAP, into the no, the known SAP world. So that most of the time we get a question, but why do I need this dual approach? Can I just use role also for sod purposes?

Well, the answer is that yes, you can, but you are going to be far away from doing a good job in terms of minimizing the number of control and to keep it readable. Let me, let me explain you why in a few slides, let's say that you use roles as a hook point to model sod constraint. First of all, roles will probably change along with change an organizational structure. So you have time to change.

Well, the, the, the, the time that you need to spend in maintaining the model while is similar to the changes you get in the organizational information of the company. But even if you have this very static company and you just do that, if you want to enforce the constraint, I'm depicting there in my chart.

Well, unfortunately the notion of inheritance through rules fall follow in the same flows in the wrong direction with respect to sod. So if I really want to enforce this constraint, I need to explode into the all underlying combinatorial set of links among the underlying hierarchy. So in this chart, one logical constraint to be enforced, require six constraint to be managed.

Otherwise, I always find an alternative way to deliver the same constraint violation to user. Now, if I look at the activity model, that's exactly the opposite. In that case, I don't have an inheritance. I have propagation that flows in the right direction for sod, and there's no surprise given that it's designed to play, to play correctly on sod. So one single constraint is to be managed and to be, and is enforced to multiple constraint, which are automatically propagated and maintained by the system.

So to say that this is in this example is a one to six configuration item, but in reality, there are one or two order of magnitude in terms of number of constraint on roles versus number of constraint or activity to have the same degree of control. So that is far more compact in terms of activity modeling. So bottom line, why have been bringing you through this description? First of all, because a lot of people, especially in the it world tend to think about role as something, not just to serve provisioning and that's where role are Bon for, but also to serve segregation of duty.

And that's what role are not designed for. And indeed, if you do a follow alternative approach, like the one I just described to business activity, where you have multiple benefit, first of all, you speak the same language that auditor come up with, which is already value. Then you can benefit from redefined content in terms of business activity, description, and link onto the technical transformation, at least on your PS.

Third, you minimize the number of sod roles, one or two order of magnitude comparing to alternative approach, like the role one. And also you do provide both user role analysis, which is not really the case. If you do sod roles and finally, well, interesting enough, that's exactly same model that SAP GC access control do follow, and this is not happening by accident, obviously. So this is really the contact point between cross areas and GC access control. Let me explain you a bit more about that.

If I represent graphically, how they compare one, each other, we can distinguish between what sort of predefined content they have and what sort of reach they allow and talking of European system, and anything else for the reach and talking of activity, hierarchy, and technical transformation for content.

So GRC access control is something that does a great jobs, and that's the best possible solution on the E P world on SAP specifically, and with the partnership with green light, also another E P system beyond SAP, but still talking of E PS, because this includes already content pre-canned for the activity description. So the business process modeling, and also the book onto the SAP specific transaction authorization AB and so forth, but it doesn't have the real incredible play outside the SAP boundaries.

That's where we have something to say, and we have a good integration with system and role management capability. And by way, we do also have a full identity life cycle management set of feature. So just to complete the slides, I just need to tell you more about the overlap area, okay. Of this two solution. So is that an overlap, meaning do we replace somehow zero C or we just integrate with it? And if we do, what do we do?

Well, the way we look at this is that we reuse the content that we can take out of it to extend it to in terms of reach to entire enterprise. So basically we look at SAP GRC as the modeling point where should be maintained the activity hierarchy, that's the master of the activity. And from there, we take it and we extend it in terms of book point to include the technical transformation.

So the link onto the at, for systems outside the, so that's the way we look at the integration with, with SAP G C axis control, which in terms of capability is the closest to what we liver, even if, as you noticed from this slide still very complimentary. So back to my checklist, if we look at the combination of SAP, G C axis control will cross plus cross areas, well, we believe that we fully hit each and every take of this checklist, we minimize the number of moving parts. We believe that compared to other solution that will be required, we kind of make it as more or as possible.

There is no other solution that is including this degree of integration with SAP while keeping enterprise wide connectivity and full identity like cycle management, not even in SAP itself, then the minimizing, the number of configuration item again, that has to do with the specific nature of the sod model we implement the model we do implement, which is the same that SAP GRC implements is the one that guarantees the lowest number possible of configuration item. And by the way, and then getting to the third point, this is what the auditor talk.

This is what the, or auditor express themselves like. So it's by definition readable to them. But the other pieces in the SAP GRC suite is not just about access control. There is also process control and risk management and well to keep it, to keep it right on track is not really that we do have similar degrees of integration with process control and risk management. But yet we have something to say about that integration as well, while we were attached on what we do on SAP access control and no need to say anything more on that. But what about process control?

Well, process controlling plan, those sort of control, which are not really access related. For instance, whenever I change a supplier payment terms, I should trigger process a workflow process to approve that change. Okay. Which maybe is not natively part of the SAP implementation. That's an example of control perform by process control. So what we do to that end well, we can automate the feeding to process control the detection of some of the changes, which are not occurring into SAP itself. And that's already something that process control is expecting.

Process control is not really automating any sort of detection okay. Expecting from external system to feed back to it, information about them. And we are among those. And then we can also complement process control, allowing the production of alternative mitigation measure, which are not there. For instance, the notion of access recertification, same applied risk manager, risk manager is obviously something which is far broader than the notion of access risk is a risk in general enterprise risk.

But again, as part of the enterprise risk, there are the access related components. And so to that end, we play a role in that space being the access risk monitor point or the feeder, the feeder for key risk indicator, access related, obviously back to risk manager. Okay. So feeding the risk monitoring component of it. So bottom line and closing my speech with the three question that we started with does SAP require AED approach?

Oh, wow. Absolutely. It does for multiple reason, including the very specific nature of his authorization model and also to be able to leverage the predefined content that the product, that address that specific space are coming with. First of all, SAP, G C access control.

Second, how do I then address the non world? Well with any identity access governance solutions such as cross ADSS, for instance. And the final question is can I reuse my investment in terms of modeling for other application?

Well, yes, right away, if you use cross ADSS reason being that we use exactly the same model, so it's not a reuse, it's just, well, it's stretching of it out of the SAP real itself. And with that, I pass it back to you, Martin. Yeah.

Thank you, Marco, for this very interesting presentation. And we also have just the first question. So I want dive directly into the Q and a session and ask the other participants if there are any questions, these questions, I think the question which came up is a very, very important one. It is.

Does that, what you've talked about the Mar does it mean you provide an alternative to green light for non SAP solutions to be integrated with tier C access controls? Well, that's, what's best way. Very nice way to put it. Yes. Green light is complimenting SAP GRC access control, unknown SAP system, like is bringing the same model onto other European, Oracle and others.

Well, that's, that's a nice analogy. Yeah. We can kind of play the same role, not on ERP, but on agen system.

Yes, we do. You can play also other E P systems then, Or no, no, no, no.

Well, again, it would be just like saying that we do play the same role as SAP GRC access control. We don't. Okay. Just not because of technology capability, but because of the content of the credibility of the insight and on the knowledge of the subject from a technology standpoint, we could even say that we could be possibly doing the same sort of thing from a pure technology standpoint technology capability, but with this, we don't even claim to be, to be that refined. Okay.

So we don't have the core piece, which is the content in terms of providing predefined models for the technical transformation that what SAP GRCs control does for SAP and grid light does for ban and for our call and for others. Okay.

We don't, what we do is that we have streamlined the approach to do, to extend that, that approach onto system. So do we provide the tool and the processes to speed up the logical onboarding and not just the technical onboarding of OUS application into the model I just described. Okay. Thank you for this.

Very, very open, fair answer. Any other questions here, as of now, just having a look. So trust me little further. I think it was a very interesting conversation and very interesting information.

We, we had here in this webinar. I think it was our last a cold webinar. That's another question I'll just pick, it's just the answer to the other question. It was our last, a cold webinar for 2012. So from my perspective, unless there are no further questions, it's time for me to thank you for attending the could be a cold webinar today and probably a lot of our called webinars who did this year and hope to see you next year, European identity conference, and have you as an attend them, attend the, at our upcoming webinars. There will be a lot of webinars again next year. Thank you.