Hello, everyone. Welcome to our cold webinar at trial GRC, adapting to the pace of change in the digital era, how to build a comprehensive approach to GRC for SAP. This webinar is supported by Satar. The speakers today are Dudley car ride, who is CEO of, and me Martin Kuppinger I'm principal Analyst at Ko Cole. Before we start some quick information about upcoming stuff at Koa Cole and about housekeeping for this webinar, and then we'll directly dive into the topics and the subtract of today's webinar. So we have truly, it's interesting to you. We have a series of upcoming virtually events.
They include topics such as perfect access management for the enterprise consumer identity and marketing automation and the future of digital identity talking aboutso and identity and verifiable credentials. Have a look at these at all the other upcoming events. There's a lot of stuff we deliver online and also hopefully starting in autumn again in physical events. So don't miss these events regarding the webinar itself. Audio control is done by us. So you're muted centrally. We do record the webinar and we will make the podcast available by tomorrow.
And we also will provide the slide X of most speakers for download so that you don't need to take too many notes here. And maybe most important, there will be a Q and a session by the end of the webinar. And you can enter questions at any time. So there's some area questions that go to webinar control panel, the rights out of the screen, where you can enter questions.
The more questions we have by the end of the webinar, when we start a Q a the better this, the more interesting it is. Let's have a look at the agenda for today and the subjects of this webinar.
And I'll start as usually in our equipping call webinars. I'm talking about trends in the market for access control and CRC tools for the SAP environments and other business applications and how to bridge the gap between business and it. So having some, providing some insight on the, in the second part, then that Cartright, as I've mentioned, the CEO of Satar will deliver insights from customer deployments and how easy to use business-centric process of GRC tools should look like for a more ad trial business-centric GRC and fast-changing business environment.
As I've mentioned, after that, we will do a Q and a session. So if there are questions under them, so that we have an interesting session here.
So let's look at some of the market trends we see in this space of X control and GRC tools for SAP environments.
So, and beyond SAP environments, but apparently focusing very much on the more, more the SAP set of technologies and how to control, who has access and how to understand the risks, how to mitigate risks, how to support the requirements around compliance. So all this which fits into access control and GRC. So what affects the trials of tools for managing access entitlements and segregation of duties for business applications? And so I think one of the most important things to consider is how can you get beyond checkbox compliance?
So when we go back, the solution started with an audit focus, but today there's, there's more required and there's also more, more possible, more feasible with such solution. So trust passing an audit saying, okay, we've done it good enough might be not enough anymore.
So how, how can you improve by using that these tools? How can you improve the business inside and understand where processes might need optimization and how can you also implement actionable controls, which make it easier, which for instance, reduce cost and burden for, for complying for securing, apparently are some of the elements which are key to success. So the more you are able to deliver inside deliver value, which help you optimizing what you're doing the better it is.
And I think that that is, that is one of the things that it's related to some of the other aspects I'll touch in a, in a second, because while you also comes apparently from supporting what the change of the business, it doesn't very much related to, to the breadths. So we, we have a changing system landscape where the, the pub blade traditional European wheat environments are still very important, but not necessarily norm anymore as the alone, the, the main environment, we see more solutions. We seeing this entire world becoming gradually more hetero.
I think the most important thing beyond which systems are supported is that also the way we manage these business systems is changing. And we, we probably never have seen so much change even to traditional traditional environments as we face today. So business is changing as part of the digital transformation and the current in crisis apparently has increased pressure on digital transformation. That also means it's not only a changing system landscape, but even within the existing business landscapes, things are changing.
Business processes are changing the way we run certain things, the way we, what we prioritized, even the business model might change, which immediately results and changes in our core business system, which means we also need to make the adjustments to the entitlements, to the access, to segregation of duty rules. We need to understand the processes, the change in processes to reflect how entitlements change here.
Another, another trend we see is that there's a, a huge demand, a huge wish for having systems that are lesser technology and admin centric than, than systems commonly are today. So many solutions still are very tech, but to be honest, most business users neither fully understand the world of key codes and authorization objects, nor who they want to deal with, that they understand what they need to do. They have to solve a task and business.
They have to understand the business process, the activities within the business process, but the underlying technical implementation details offer whichever technology at the end is not limited to, to the business applications is not limited to SAP. They should be as, as transparent to them as feasible.
And so, and that goes back again to, to two points. I mentioned that, that we see changes in the way business systems are implemented. So we see more SaaS, we see more heterogeneity, but we also see the need for more agility in business.
And this, as I said, never has been as, as big as it is today. So with SAP landscapes change, but also the user expectations. So users expect the modern UI today.
Things are, are changing, and we need to support that, change this, what we do around access control and QRC.
And so we, we see this, this emerging trends towards leading to, to change in the, the, the way solutions for managing access control and CRC for SAP environments and beyond are constructed. And I started with this checkpoint checkbox compliance aspect, and I've never, never, ever been a believer.
And I'm, I'm in that space for, for many, many years. I've never been a believer in, in any type of checkbox compliance or, or things which are just rubber stamp reviews. I I'm a believer in, in real risk mitigation. And so why, why do do we need more? And I already touched this. We need also different approaches for agility.
So we, we must support business agility. And that means also that we must be able and attach this in the previous slide to adjust entitlements rapidly, to react and changes the business process.
But you also must be able to understand, so have insight into process.
So when, when we look at the way for instanced controls are constructed and they are very much about organization to business processs and business activities. So how do this relate? And if we do it right, we can learn a lot about that. And that also can help us in, in understanding and, and optimizing business process, but also the other way around, apparently if we map this, what we do around access controls around as a de controls, when mapped is the business processes and business activities, the business will be better able to understand it. So why do we factually do it?
So agility is something which is, we must be able to support it. Process optimization is, is really nice to have. And it's a clear winner when it comes to, to a business conversation at the end, we don't do GRC and access control only because of compliance.
Apparently yes, we, we need to comply with regulations and we need to fulfill what the orders are asking for. But at the end, it's also about information security. So it shouldn't be, and that's the point, again, this checkbox compliance, it shouldn't be just checkbox compliance.
It should be more, it should be something which helps you improving our security in which helps us mitigating risk. And we all know from the history of this entire market segment, we, we all know how essential, how important such risk investigations and how, how severe access risk can be to an organization. So when we go, go back to some of the major incidents and banks with, with O D Y a based on over chap to, as a D violation, that then it becomes apparent. There's a huge business risk based on access risk. So information security, risk mitigation, but also audit and compliance are important.
The other thing and us is that we, we have different perspectives. And, and when we look at managing access, then, then we need to understand there are, are different perspectives for, from how the business looks at this, how the business people look at it to what can be done in systems to what does it mean to data? And this is a, a very complex relationship we have, and we, we need to do the right thing for the right audience. There might be different levels. We need as a partner of different manner.
From a user perspective, the user, the individual user at the end looks at business activities because these are the tasks someone has to execute in the organization. So this is the, the perspective of the individual on, oh, what do I need to do many understand how this fits into a business process? So when I do, when I track invoices, then I understand that this is a part of a business process, but the first thing is activity.
And then this is the flow of these activities, the business flow, again, the business understands it's, it's also, it's their perspective on what, who should do what, and that's their perspective on what is relevant at the end. This is the right thing, because at the end, it's about it. It's about business and it trust has to fulfill business processes and the tasks and the activities within business processes than are executed by different purple, which different people, which, which then can be mapped to business roles or other constructs, which are still a business perspective.
And then we, we come to this technical artifacts, and this is really the break point in this entire thing. If we don't manage it, well, things become complicated. And I think this is an experience many have had already past years, these technical artifacts. So the system controls, that's the way a system looks at it.
And as we, we know, and as we can see, this is totally different to what a business user looks at. A business user looks at a process, maybe a role, the activity QA, then start talking about transactions and ization of checks and system roles and so on. And this is not driven by the business. It's driven by a technical architecture and something someone invented sometimes tens of years ago to manage or to implement a business system. And apparently this is frequently hard to understand for business people. And the idea shouldn't be that business, people understand it.
The idea on the target should be that we make it. We trans, we, we translate it. We transform it in a way that works for the business people. And then at the end there there's the data.
And, and what is additional challenge and specifically in, in SSP environments is that data can be accessed in a variety of ways. So it's, it's not there that there's a one to one mapping of data technical artifacts, but there might be various transaction dealing with the same data. There might be various programs, different UIs, etcetera, which all come different way of managing access to all this data. And at the end, what we want to protect is our data. It's our financial data being protected from fraud and leakage. It's our intellectual property being protected from fraud and leakage.
This is what we are really focusing on. So we, you might to take some, some, some, or I think it's, it's helpful to take a perspective which, which looks at business versus technology.
And, and then we have a, a business view. So how, how does business look at business artifacts on one hand and at technical and system artifacts at the, our side. So business artifacts are the business activity. The process technical system artifacts are all these things below, such as neuro authorization object and the business well understands and can define the business artifacts while when we take the technology view. And this is one of the major challenges in many projects around access, it is really hardly able to define the business artifacts.
They just don't know enough about business to do this job well. And, and I feel in so many projects where it was about defining roles, for instance, and then they, it said, oh, they ask us to define the business roles, but we have no clue about how to do that. On the other hand, if you look at the business view and technical system, our it effects the business hardly in reality, understands all the details.
Sometimes they, they learn it for a certain system, but from a broader perspective.
And when we see that, that we have them here is SA solution popping up and here some new technology from vendor P and, and so on, and things are changing though. It's hard for them.
It's, and it's not what they should do. They should do their drop in business.
And, and even, even tech people when looking at the tech technical aspects are challenged by managing this consistently correctly, across all the levels. So, so when we look at the, the world SAPs with all these various elements, even for technical people, it's not easy to, to deal with that. So what we need is we need a translation from, from a technical, into a business perspective, from the technical, into the business artifacts, we need mapping.
So from the, what it can manage and what it manages to what business defines and managers, and we need automation and insight so that this complexity of models we have in it's reduced.
So we need this additional perspective here. So what are key requirements for successful JRC? From my perspective, it's taking a business perspective.
So translate not look at the technical artifacts only have a modern UI for every user, which is easy to use, not only something for the text that we want, dashboards and drilldowns and stuff like that, map technology to business and vice versa business don't want to learn tech terms and don't expect them to do so. So I still remember in, I think my, my very first identity management advisory project many years ago, the situation we, the customer was in and they ask us, oh, we are in trouble. And could you support us and help us, et cetera.
And, and when I go back to, to that, the problem was that they, and this is not kidding. They asked business users to make a re-certification and an access request at the level of SAP T codes and the business users trust that we, we can't do that.
We don't understand it. It's totally unusable. Apparently it was. So we need to map it. We need to translate it. We need to automate whatever we can in management and analytics of entitlements.
We need to provide the details and, and how this things process to transaction, to data map, move to a broader system support and make it easy to install and configure. So run it up, roll it out, easily support, modern deployment models, support, flexible operating models. And this is where I see this entire market moving.
And with that sort of high level insight, I'd like to hand over to Doley who then right now we go into the details and look at how to do that, how to provide a business perspective, a business GRC that works well for the agility needed in today's it environments Dudley's yours.
Thanks Martin.
That was, that was very insightful. I appreciate that's great. Hello everyone. My name is Dudley Cartright from, from, and I'm here today to try and share, share with you why we believe that embracing elements of agile GRC will ensure a more comprehensive GRC capability at, at your organization. So there are gonna be a few slides that are slightly repetitive with, with what Martin has covered, but I think it's important that we just reiterate some of those points because they are important.
So just gonna take a step back and just remind ourselves again, like Martin learned why we need to look at at GRC or access control tools, as we are aware, fraud is on the increase, you know, and this is quite evident by the world economic forums report from last year, which just highlighted, you know, how on the global risk register, just how prominent cyber attacks and data fraud and, and theft is.
We also faced with increasing regulations and for most of us in the cybersecurity space, there's the, the impact of the data privacy regulations are, are now impacting us.
We not only we, we needed to, we just concerned about access risk previously about fraud risk. Now we need to consider a data privacy risk. What personal data do people have? Should they be able to view that access as part of their, their job function? We seeing a global, you know, there's an increase in pressure from all the external audit firms, which is putting more pressure on all the organizations to ensure that their, their security and their authorizations is, is a better shape. We also appreciate that.
Unfortunately, the SAP authorization module is an incredibly technical and complex module. You know, Martin alluded to this, you know, the fact that you've got transaction codes, you've got authorization, objects, authorization fields, et cetera.
So SAP has been brilliant at allowing companies or organizations to control at such a granular level that you can not only restrict the user to execute a transaction code, but you can restrict that user to execute that transaction code for a, a specific organizational level.
But in order to provide that level of granularity, unfortunately, the authorization module becomes a complex and technical module, and it becomes very easy for people to get access, more inappropriate access over and above what they need to perform their, their job functions. It also results in very little visibility as to who can do what in, in the system. Then with regard to lack of business buyin that we believe is possibly the greatest challenge facing most organizations who struggle to derive or extract value from their GRC capability.
It's an area that we at Satur are placing incredibly great emphasis on, in, in trying to address, because we, we strongly believe that if you can enhance business buy-in and accountability, this will go a long way to improving your GRC capability.
And then also as Mon Martin mentioned, you know, the, the rate of change is, is, is greater than ever before. Organizations are, are needing to increase their clock speed just to stay, just to stay relevant and, and to stay competitive.
So, you know, we we've seen or believe that, you know, as companies are increasing the, their clock speed, you know, and embracing these, these changes, it's important that the GRC tools can keep up with this rate of change. And we believe that, you know, you need elements of agile GRC in order to, to keep up with this rate of change or this pace of change, or, or otherwise you, you're just gonna be monitoring risks in your GRC tool that are not relevant to the business.
So when we go to companies, we, we often ask them and we say, you know, do you believe that your current GRC capability is adding value?
You know, or is it as Martin said, are you, is it just rubber stamping? Is it ticking an audit box?
You know, we also ask companies, you know, why is it so little involvement in disinterest from the business in governance, risk and compliance, and how can you change this? So, as I mentioned a little bit earlier, you know, we believe that this is the greatest challenge facing most companies to extract value from the GRC capability. And we often find that, you know, the business users don't get involved in GRC activities because it's, it's too technical for them.
They don't understand the risk reports and often they don't even understand some of the, the access risks that, that, that are being, you know, reported on. So, you know, we, we must remember that access risk is business risk, you know, and, and that vital that the, the organization that as the organizations increase their clock speed to stay relevant, you know, to, to keep up with this, this rapid rate of change that the business users are involved in GRC type activities.
So we must remember that when we, when there's a lot of change around, it'll be much better for the organization to have a team of, of business users associated or involved in GRC activities rather than a very small it team and internal audit team involved in risk activities, rather spread the, the, the number of people who are performing these risk activities, the more, the, the more, the better, okay.
So I'm now just gonna talk through three components of SAP security, and there are more components of this, but I just wanna briefly mention the relationship between the sepal design, the access control solution, and also the identity access governance solution. You know, there's, there's such a, an important interrelationship between these three components and, and, and we're just amazed with how many organizations just forget that the, the forget about this interrelationship between these three components.
Unfortunately, if there's deficiencies in any one of these components, the entire security capability at the company is going to be, sort of is gonna be under par or, or diminished. So what we often see unfortunately, is that a lot of the time companies have invented SAP role designs, and the order firms will report on how much risk the, the company has got, and the company will go and purchase an access control solution and an identity access management solution, or identity access government solution.
So yes, these solutions will help, but until the company goes and addresses the underlying role design, fortunately the, the true value of these, of the access control solution and the identity access management solution will not be realized. It's very important that the company goes and addresses the underlying role design, the role design form forms, the backbone of all things, you know, GRC.
What we also see is that a lot of companies either don't have an access control solution, or they don't have a tool that's a good fit for, for the organ organization.
And I think this slide here is pretty much the, the session or the talk that we on on talking about today. It's, you know, if the company has got a, got a tool that's not adding value, or it's not a good fit for their business or the risk, the risk reporting is just too complex for the, for the business. It's unfortunately gonna end up being heavily underutilized. The company is not gonna extract or derive the value that they should.
And, you know, as I've been mentioning through, you know, the last few minutes of my session is, you know, as companies, you know, organizations are facing this increase rate of change, you know, it's, we believe that it's gonna be very important that, you know, for if to embrace agile GRC in order to, you know, be able to enhance your organizations GRC capability.
So I just wanna just talk through around a few elements of what we believe is, or components of agile GRC.
So, first and foremost, it's about being business centric. As what Martin was saying, it's putting the business user at the center of the process. If we can't get the business users to participate in these GRC activities, we unfortunately not going to get the business or, or we are not gonna extract the value we should. It's also about being iterative and adaptive, you know, as birth Martin. And I've been saying the rate and pace of change is so great these days, that things like the rule sets need to be need to be continuously changing, changing.
We, we surprised with how many companies we get to that implement a standard rule set from the, the GRC vendor. And they never customized that rule set to be specific to their organization.
And for those companies that have done some rule set customization, they may have done it five years ago. They never seem to go back and review that rule set and make and see if it's still applicable or for any new risks that that need to, to be added. And then I think also, you know, we also need to consider managing risk in different ways.
And, you know, one, one of the, the, the ways that need to be considered is managing risks through trust relationships. And I'll sort of in the, the product demo that I'm going to be doing in a few minutes, I'll just sort of show you what, what we doing with, with regards to that. We also feel that it's important to, for, for, for the, for the vendors to, to be able to integrate with each other.
You know, I think that will allow an organization to, to be able to offer or provide more holistic security that you identify the best or breed vendors and ensure that they can integrate with each, with each other.
So like an access risk tool, being able to integrate with, with an identity access management solution.
And like, lastly, it's very important that that agile GRC is about, you know, just quicker or almost immediate return on investment. I think many organizations don't have the luxury anymore of waiting for for six months, you know, for a, a GRC project for the implementation to, to happen in the GRC project.
You know, only for them to find out it's not a good fit for their business. So the more agile GC vendors are, you know, you can implement the product in, in a couple days. And the benefit of that is if that solution is not a good fit for your business, it allows you to fail fast. So you can, you'll see that the product is not a good fit for your, for your organization and you can get rid of it.
And it does, it means you haven't lost six or eight months of implementation and a lot of money implementing a solution.
That's, that's not a good fit for your business. So I just also wanna just, again, maybe just reiterate, you know, the, the, the, the point of, of being business centric it's must probably it's been the sort of primary sort aspect of both Martin and mine session or, or presentations. And I think it's just important to try and, and emphasize why we believe being business centric is, is the most important aspect of, of agile GRC.
So, you know, we believe that in order for the organization to effectively manage their, their current risks, as well as risks, that that they're going, the risks that they're going, new risk that they're gonna have in the future that enhancing the business, buying and accountability is going to be a critical factor for the organization to ensure that they've got effective risk management.
Okay. And I think I'm gonna, you know, just spend a little bit more time on that and saying, why is business being business centric?
So, so important why putting the business users at the center of the, the process important converting the technical language into a language the business users can can understand. And I think, you know, when we look at the audit principle of the three lines of defense, I think this goes a long way to explaining why, why it is so important with the audit principle of the three lines of defense, your first line of defense, or your operational users. They are your business users.
It should be the organization's strongest line of defense, but in most cases, it's actually the company's weakest line of defense. So it's not saying that those business users don't understand the risks. A lot of the time those business users have been at the organization for 15 or 20 years, they understand the business, they understand their process better than anyone else.
They understand it better than the external auditors.
Unfortunately, though, in most organizations, the, the, the second audit of defense and the third line of defense ends up being the company's sort of primary defense mechanism. They rely heavily on the risk and, and sort of GRC teams, or even external audit. So it's important that we start getting the fir the first line, the, the business users to participate in these risk events. They understand the business better than everyone, and it's not that they don't understand what the risks are.
It's just, we believe that they don't have the tools to be able to contribute to what the risks are. The GRC tools are not business friendly in, in that they lend themselves to allow the business to participate in these time GRC activities. So I'm gonna just jump now to a product demo, and I'm just gonna spend sort of 10 or 15 minutes in that before we jump to I'm just gonna quickly make sure we can see the screen before I do jump in.
Okay.
So, so join is a non ever based access control solution. We've got an on-premise offering as well as a cloud cloud offering the two, the solutions are exactly the same. It's just purely up to the client to decide whether they want to go for an on-prem or they want to go for the cloud, the cloud offering. So I'm gonna run through a few views to explain how reports on risk and how we believe that we are agile from the perspective of translating the technical language into a language that the business users can understand.
So once if secur a risk analysis against an SAP system will report on the amount of risk that the users have got based on the roles that have been assigned to the users. And we refer to that as potential risk. That is the, the risk that is sitting in the environment based on what the users can potentially do, based on all the access that's assigned to them.
We report on that in relation to what we refer to as actual risk.
So, so to also terms customers activate the SM 20 logs. So we can identify all the transaction codes that are being used by the users and actual risk is where we have, where we see a user has executed both legs of a segregation of duty violation. So a very common example, there is one of our risks is where a person can create or maintain a purchase order. And that person can also release a purchase order.
So if we see a user has executed me 21 N me 22 N, and that person has also executed me 28, me 29, the release that's what turn will refer to as then an actual risk, but the valuable information and the usage information is if we know what the users are executing, then we can work out what they're not executing.
And in the SAP world, that's quite valuable information because there is a tendency to over allocate access in, in SAP. And so if we have a look at some of these tiles here, there's this blue tile here of 832, that's the number of superfluous roles.
Those are roles that have been assigned to users where the users are not using any of those roles. Likewise, if we look at the next tile here, 643, that's the number of, of transaction codes that are in the rule set that are in roles, but where the people assigned to those roles are not executing those transaction codes.
So, so can identify a number of cleanup steps or cleanup activities based on what's not been used by those users, and then can project how clean you can get your solution. If you were to embark on risk remediation or cleanup activity, by removing all the access that people have got that they are not using.
So just to then show you how we show some of this, this information in tune, I'm now going to the, the S O D detail view looking at which users have got segregation of, of duty violations.
This graph here illustrates the blue dot, represents the amount of S OD violations based on the access that's assigned to the users. And we report on that in, in relation to the actual, the actual risk, that is where the users have executed both legs of a segregation of duty risk. So the difference between these two, the blue point and the orange point is pretty much the difference between what access is, what authorizations or access has been assigned to the user versus what the user is actually using from his or, or her role.
So if we come over a much greater period of time, I'm gonna just go back to a five year period.
And you can see where we started with this client. Like most companies, this, this client had a very inappropriate role. Design users had far wider access than what they needed to perform their job function. So through the Satur functionality, there's some get clean functionality that I'm gonna show you in a minute. This client did a lot of clean up and align the solution with what the users are doing. So it was removing a lot of the superfluous roles and the superfluous transaction codes.
So not only have we then after the cleanup, not only have we, we reduced the potential for fraud, but if the organization needs to do user access reviews, there's far fewer roles that the, the reviewers or business users would need to review as part of a review as part of a user access review, compared to if this company was doing a user access review back at the, the date in, in March, you know, 2016, there, there would be many sort of thousands of user to roll relationships that that business users would need to review, but it's just overallocated access.
It's the purpose access, but yet it would stay still take considerable effort and time for those business users to, to, to go through the review set. So there's a significant sort of cost saving by aligning your solution with what the users are doing to re not only to reduce the potential for fraud.
Yes, that is, that is a critical activity, but it also significantly reduces the effort to, to perform user access reviews. So I'll just go and show how we show some of the, the detail now. So we'll see all these users have got segregation of, of duty violations. And if we just gonna have a look at this one user Anthony Hill, we can see that this user has got three S OD risks, according to our standard rule set, and this particular risk here, we can see that the person's got the ability to do the vendor master maintenance and also to create, create the payment run.
So we can see that the transaction codes, the FB Z O is in the payment run, create function. And it's in conflict with the vendor master maintenance transaction codes. FKO oh one FKO two, et cetera. We can see the role in which the person gets the transaction code from the role description. But the valuable information is actually in the transaction frequency columns, where secur will show how many times this user has executed that particular transaction code. So we can see in this particular example, this user has not executed any of the transaction codes, either F PTO or FK oh one.
Now what Satur also does, if we look at the next column where it says, show the transaction frequency of any transaction in the role materials, also working out the frequency of any other transaction code that may reside in either of these two, two roles.
And so with we indicate that there's a count of zero. That means that it's a superfluous role. The person has got it yet. The person hasn't used any of the transaction codes from that role. I'm just going open one more risk, just to explain, just so we can maybe see this in a slightly different way.
This is another risk here where the same transaction code, the payment creators in conflict there with the, the vendor invoice processing. If we have a look at this Mir seven, although this transaction code has not been used, there's something else in this invoice verification processing role that this the user using 40,000, 40,000 times. And we can just click on that to go and see exactly what that is.
So this just tells your security team, if you were to remove that access from that, that user, yes, you would address this line item, but more than likely this user's gonna have some authorization failures in the coming days, because there's something in that role that that user is executing.
So just to talk about then how we try and report on this in a business friendly manner.
So we, we go to a lot of companies and even the financial managers will say, guys, I don't understand what this OD risk means. I, I, how can you commit fraud fraud with it? So what secur has started doing is we've started illustrating all of the, the risks within a business process flow that if no one, if someone doesn't understand how, where that risk sits within a particular business process flow, you can click on the information button Institute and it will illustrate against the procure to pay business process exactly where does this sod combination exist?
And in this case, we can see if the vendor master maintenance and in conflict with the, the payment run create. And I'll just go and look at the second risk here, where this is the user's got the ability to do the vendor invoice processing, and also with the payment run create.
So again, the idea behind this is just to be able to provide, to, to put it into convert the technical language into a business friendly language in order for the business users to make more informed decisions.
So what S doing is we then shipping standard, the business process flows, and then it's up to the company to go and change. Those business process flows to be more applicable to their, their business. Like we can see in the procure to pay business process flows, we can see manual check processing here. If your company doesn't do manual checks, we can just simply remove manual checks. And we can just go and say, listen, we are only doing EFTs.
And, you know, you can obviously go and change these around. We can go and color code certain aspects of this business process to represent centralized, to master data type type functionality.
So it's as easy as that as, as changing the business process flows, the minute you change the process flows here and you save it the next time you can view it in this view here, it will illustrate whatever change you you've done.
So again, I think quite powerful for, for just trying to present the results in a way the business users can, can understand. So looking at at this.
So, you know, I've gone through how Saturn reports on segregation of G risk Saturn also reports on critical transaction risk. And Saturn also has got a data privacy rule set, where we can report on which users have got access to personal information, either via SC 16, which, which tables contain sensitive information or via the transaction codes that also show personal information. We report on risk at a composite role level at a single role level, and also at a position level.
And obviously we ship the product with, with a, a rule set.
So we strongly encourage all of our clients to go through customized the rule set, to be more, more applicable to their business. There will be a lot of risks in, in the standard rule set. That's not applicable to every organization. And so we encourage our customers to, to continuously review the rule set and ensure that it it's appropriate. So what we've done to support this process because in customizing rule sets and in, and, and reviewing them on a regular basis seems to be, is quite a technical and challenging activity or task.
So what we've got is we we've developed a, a view in which we can go and look at a particular business process flow. And I'm gonna just pick on the procure to pay process again here and what this will do.
It will show you the business process flow, procure to pay, and it'll then list all the risks we've got that associated with procure to pay.
So you, you, if you were interested, you could come and say, listen, I wanna see which risks are associated with vendor master maintenance. What Saturn does there it'll then list all the risks that are associated with vendor master maintenance.
Likewise, we can then go and say, listen, I see there's one risk here. That's got 24 users. They can see what this one risk is. Then Saturn will highlight what that particular risk is. What you could also do is you can also go and say, listen, I wanna see which do we have a risk in the rule set that covers these two processes in my procure to pay process. And I've selected the vendor master maintenance and the purchase order maintenance.
And we see that, yes, there is a risk in the rule set that has that combination. And we've got 10 users that have got that risk.
So this type of functionality will just allow the business to look at what, how, you know, whether the rule set is complete. Does it, does it address the complete business process? And it just is a very user or business friendly way in which the business can start participating in rule set customization type activities. Okay. So I also just wanted to quickly mention, so we've got, you know, let's assume you've identified where the risk is. So turn has got some very powerful cleanup functionality. We identify all the superfluous roles that are in the system.
We can also identify where all the superfluous transaction codes are got a whole lot of wizards that help with this cleanup activity. It's a very important aspect of sat tune is helping the company align the solution with what the users are doing, removing all the superfluous access and Satur can also then project how clean we can get a particular system.
So once the solution is clean, what we've got then is for these companies that then use the simulator as their business, as usual, they simulate all set access, change request.
We've got a whole bunch of simulation types, and I'm just gonna select one. As the example, we've got a user that is requesting particular access, and I'm just going to say, listen, this user is selecting the ability he wants to create purchase orders. Now in the simulator, we can run that this, that analysis will be done against the user existing access to see if this additional or new access would introduce any new risk. And in this case, we see, yes, new risk will be introduced and we can go and see what each of those sod violations are.
If this simulation get gets sent to, to the business owners for review or, or a risk owner for review, when this gets into the business owners inbox, again, if he's not quite sure of what any of these risks mean, he can simply just come and say, listen, what exactly?
What is this risk? Where does it fit within the business process?
And again, this will hopefully just provide more context, allowing him to make a more informed decision. Okay. So what I also just wanted to do in the PowerPoint presentation, I also just mentioned that we also managing risk through trust relationships. And so I'd wanna quickly mention or, or show some of the information that we we are doing there. So what we are doing is we've creating a trust relationship between the user ID and, and the terminal name. And if I just go and select, just gimme a second, I'm just gonna select these two dates here and I'll go O over a weekend.
So, okay. Sorry about that. I have done something wrong here.
Okay. So what the turn is doing is then highlighting any activity that was done from a nont trusted terminal name. And what we can see is we've got dates here. This data represented in red indicates this was activity done on the weekend, and we can go and see, okay, who access from an untrusted terminal name? And we can see that, listen, this was actually some activity that was done by an external auditor O over the weekend.
And we just haven't listed him as we haven't registered his terminal or his PC to his ID as a trusted relationship. So we can start trying to monitor some of the risk via, you know, via trust relationships. Okay. I've got very limited time here. So just lastly, obviously there's a elevated rights module.
We've got a data privacy module, we've got a user access review module and a set licensing module, but I just wanna just the last view that I'm gonna get into before we get into the Q and a section is just talk about a business role module that we've got, where in turn against an org structure, you can go and create business roles.
And as in Martin's presentation, business roles is what business users can understand. They don't understand the technical language, but even the business roles, we need to present that data in a way which will make sense to the business users.
So, as an example, here in turn, I'm gonna just look at this creditor accountant here. We can see all the SEP single roles that have been assigned from the different systems to this business role. We can see all the users who've got this particular role, but what you can do in turn is you can also go and look at this again by the business process flow. What this view is telling us is saying, listen, this creditor content has got access from the, the basis business process, the finance business process, order to cash business process, and also there's access from procure to pay.
So if we wanted to go and say, listen, what is the order to cash access that this business role is able to perform?
What is doing is it is then showing you the business process for order to cash. And it's highlighting all the activities within this business process that this business role is, is able to perform. And we can see all the orange indicates what he can do. All the great art ones are the steps in the business process that this role cannot do. So it's very, it's very visual for the business users to very easily see, okay, I can see that this business role can do customer master data.
They can do sales pricing changes. They can do sales order processing, et cetera.
And, you know, we can go and see all the risks associated with that. We can also then go and see the set single roles that are associated with that business process. And if the business user said, listen, I wanna go and see, which is the SAP single role, which allows this user to be able to do the customer master data.
What, by just selecting on that, that will just filter the roles that allow this business user to, to be, to do the specific function or task of the customer master data. So again, the focus is very much on the business process.
It's, it's a language that we believe that the business users can understand. And then effectively then things like user access reviews, business role reviews can be done at a business process level rather than at a SAP technical level or a SAP role level, which is more difficult for the business users to understand. Okay. So I think I've gone over on my time there, so apologies for that. Martin. Can I hand over back to you? So thank you everyone for listening to that.
I, I hope that was pretty valuable and I will hand over back to Martin now for the full some questions.
Okay.
Thank you, Duley, for all that information you've provided, which was very insightful. And so let's directly come to the Q and a session, as I've said, by the end of the webinar, we always do a Q and a, and there are a couple of questions which, which we already have. So I'll walk through this questions step by step that we can address as many as we can. And I think the, the first question, which might be really of interestes which SAP cloud products do you connect to.
Okay, sure. So what we do, we busy integrating with success factors at the moment, and that should be really next quarter. And then we are looking at Arriba after that. So at the moment in a roadmap, the, the success factors is, is currently being looked at and Arriba is what we're planning on, on doing, doing after that, which, which will be later this year.
Okay. Thank you.
And, and then another question I have here is can you import a customer rule set
Into superior? Yes. Yeah.
No, very much so. So obviously the, the product comes shipped with a standard rule set, but all, you know, we rule set can be imported into the product, whether that's an order firm rule set or whether it's that's any other rule set. Yes. Importing other rule sets is, is a very easy activity within the product.
Okay. And let me pick the next one. How long does a typical implementation take?
I assume it depends very much on deployment model customer chooses, but, but what are, so the average timeframe
You, yeah, so it is also dependent on which modules the, the client goes for, but the, the average implementation for is between three and five days, that will be the implementation and the training of the end user of, of how to use the product. So it typical three to five days for complete implementation and, and training.
Okay. And that that's different much.
I think you have, have a couple of deployment options on premise started differ this deployment time, much with the regard, with respect to the deployment option chosen
Not, not really, because if it's an on-premise implementation, we usually allocate one day to that. And then the rest of the period is for the, for the training. So if it's a, if the client goes for the hosted offering, then we can usually do that, the actual installation part in three or four hours.
So there is a saving, but you know, our on, on premise implementation is also so quick anyway, it's, it's not that much of a saving.
Okay, can you also analyze your access and the associated risk? So I think I touched these various access paths and so analyzing different, different types of access and risk appears to become more and more relevant.
Yes. Yeah.
So yeah, very much so Martin, our rule set is fully fury enabled where we've, you know, so we, we can analyze fury environment. So yes, our rule set is fury enabled.
Okay. And then one of the final questions I have here is, does Satir integrate with, with any identity and access management management solution, maybe also does it integrate with, with solutions which provide new user information and so on?
Yes. Yeah.
So, so yes, we've got an integration with sale point with I, I Q and IDN from an identity management solution. So, so yes, there, there is integration capabilities with, in particular with the SalePoint identity, identity access governance solutions.
Okay, great. I think we are, we're unfortunately running out of time. So no time to cover further questions, we'll reach out to others who have entered questions. So thank you very much to everyone for attending this on call webinar. Thank you very much to you Dudley for supporting us in this webinar and all the information you've provided and hoped to see you soon in one of our upcoming events.
Perfect. Yes. Thank you very much, Martin Martin. Thank you. Attended. Thank you.
