Segregation of Duties for Oracle ERP Cloud
420,000 Oracle Cloud ERP Segregation of Duties violations to zero unexpected conflicts: A case study in Best Practice SoD Optimization
Unaddressed segregation of duties conflicts increase the risk of fraud, error, and rework and pose risks to financial statements, operational activities, and the alignment of roles and responsibilities. In recent years, auditors have increased their focus on the remediation and mitigation of segregation of duties conflicts. However, many organizations struggle with how to address remediation issues.
Remediation is crucial in addressing access control incidents where policies have determined the existence of a violation. Remediation involves multiple participants from the business, audit, and I.T. to choose the appropriate corrective action.
In this session, learn how a global household name was able to effectively address SoD remediation with SafePaaS for improved governance.
Join industry experts Matt Luscombe (CEO Systems Risk Services) and Adil Khan (CEO SafePaaS) in the second part of this series of sessions, as they share their Strategies to remediate segregation of duties in Oracle Cloud ERP.
Matt and Adil will discuss:
Challenges with assessing Segregation of Duties in Oracle Cloud ERP
Approach for identifying and removing false positives
Remediating Role design and user conflicts
Suggestions for influencing teams to amend their operating model
Identification, definition, documentation, and implementation of mitigating or compensating controls
Providing assurance that there are now zero unexpected conflicts
TRANSCRIPT
Emma - Hello, and welcome to today's session, “Best Practice Segregation of Duties Optimization for Oracle ERP Cloud.” My name is Emma, for those of you who don't know me, and I'm delighted to be joined by the CEO of Systems Risk Services and SafePaaS CEO and Adil Khan, who will briefly introduce themselves in a moment. So just a few housekeeping items before we get started. The session will be recorded for online and on-demand viewing and if anyone does have any questions, we would love to have questions from you, obviously. If anyone does have any questions, then please feel free to send those across in the control panel. So, Matt, would you like to briefly introduce yourself before we get started?
Matt - I´ve spent years 25 almost. It's pretty depressing when that anniversary at that point when it comes around in September focused on Oracle security controls. That is absolutely everything that my firm does. We've been working together with SafePaaS helping clients improve access controls, segregation of duties, and business process controls.
Adil - Great, Adil Khan and welcome everybody to our event. And if you're listening to the recording, I look forward to sharing some insight with you. Matt and I have worked together for a long time. Like I said, I've been in the space for about the same time, maybe I´m a little older than him. So I hate to admit it, but a long time. Decades of focus on internal controls for Oracle customers. I have written a book on this topic as well. So, yeah, I'm here to share an exciting case study that Matt and I recently worked together on and we look forward to getting your questions and your thoughts.
Emma - Great. So this is the agenda we'll be following today. Everything from, as Adil just mentioned, the case study to segregation of duty role updates all the way down to mitigating controls. And then hopefully, as I said, we'll have time for some Q and A at the end. So what is segregation of duties, Adil? Matt?
Adil - Matt, You take that?
Matt- Sure. So, to me, it's one of the key controls. It's just part of a repertoire of things that an organization needs to ensure to enforce good practice risk management within business processes. Often seen as an IT control, but really is about business process activities to make sure that two conflicting privileges are not given to the same user. With a view to reducing fraud error, free work, those are typically and each individual process will have its own different separation of duties from each different system will have its own nuances within that. So, an example that is included on this slide is around authorization and approval. So, normally, you wouldn't normally expect somebody to do the actual transaction creation plus the approval of that be in terms of an invoice, an AP invoice being created. You wouldn't normally expect the approver to be the same person.
Adil - Great. Just to add to that. I think that this framework and we´ve talked about our journeys over many decades. You know, we started off thinking of segregation of duties as just one of the many controls. Let's say, a 100 controls a company has most of those are business controls - your three-way match is working and your procure-to-pay cycle, your credit limits, shipping etc..
So, it started as a small problem, in my mind, anyway, and it has grown into a very central part of running a controlled business that is functioning well, and has good controls in place. And the reason is because I think our lives have become digital. In my career, in the last decades, like I said, has become digital, right? Whether it's your phone or the tools you use to do work, everything is digital now. And so segregation of duties, which was this kind of a little control on the side that you've documented, and you basically ask people questions about their access and all that. Which spreadsheet do you use for this, or what program do you use for that has now become totally digital. So as this control has become digital, it has become very central to protecting risk in your financial statements, because everything we do today is through the digital process. Folks like Matt have built this depth of knowledge that is required to control risk in your major ERP systems, like the one we're going to talk about today, Cloud ERP. Because there are so many ways and I learn every day, working with folks like Matt and others on our teams, on how many different ways users get access that we haven't thought through. I don't want to give away the punchline of the important points that Matt's going to make. But you'll hear today in this session on how this simple control that's been in place for decades has transformed into a very central part of your operations and efficiencies in the business.
Matt - Yeah, you're absolutely right. I mean, in one sense, this is no different to how it used to exist 20 years ago, when it was all on paper. You still wouldn't expect the same person to be tracing a transaction and approving it as an example. However, with it all being within a system, nowadays, if you don't get your access right, then, it's very easy to get both sides of that different activity.
Adil - That covers our definition. What are we talking about next?
Emma - So, Matt, how can an organization define their access risks?
Matt - So each organization will have its own different set of processes that are in different activities. So, this is an example I've included for conversation, happy to discuss it with anybody after the session. Really, it's about saying, OK, on their own, there are certain activities that are high risk. So, for example, if I can maintain suppliers - that is high-risk. In Oracle cloud, there are a limited number of additional things that are really high risk as well. So for example, there's a box on, near the bottom right, that says FBDI one-time Payment Upload. So, this is absolutely specific in Oracle Cloud that allows me to do one-time payments avoiding all the approvals. I don't need to be set up as a supplier. I don´t need to be set up loading in invoices. So, it's about understanding, on their own, which ones are high risk, in combination which ones are high risk. So, for example, a classic one might be supply maintenance, plus invoice entry as been high risk now. I would hope that, within Oracle Cloud, there are approvals built-in. But typically, those are mitigating controls. So, normally, we would expect from an access control point of view, that you'd want to restrict users that can access both sides of that. And if that's not possible, then we'll look at some mitigation, which we'll talk about later. This is the type of thing that normally an organization would have to think about themselves, agree with their internal audit functions, their compliance functions and risk functions. Probably try and have a conversation with external auditors as well, certainly for the organization that we'll talk about later, And they had a large accounting firm who provided input into what they thought were their required segregation of duties requirements as well.
Emma - Great insight there. So let's dive into the case study. Adil?
Adil - Yeah, so we're excited to share a success story I call it. One of our joint customers that Matt and I and our teams worked on. It's a global household brand name. We're working with the PR folks to get disclosure rights so we can publish this with the company name, and look forward to doing that. It operates around the world, essentially, in most countries in the world. And they were on this journey when we engaged with them. This is now four years ago, when we first started talking to them. They were on the journey to adopt this cloud transformation that many of your organizations might also be doing because cloud seems to be the next thing, or has been the next thing for the last few years. So, many companies are moving on this journey. It's a difficult one because most of the CIOs and CFOs have grown in this world of on premise, where everything is tucked away nicely behind firewalls. And people come into the office to do their job 9-5. And so, when this company was moving into the cloud, one of the concerns they brought to our attention was, how are we going to control risk? Because, it's a different operating model essentially, that's got a lot of efficiencies and promises. Digital transformation is the buzzword that you hear a lot, but that journey has many challenges for people that had, essentially, quote, unquote more control over their business, tucked away behind a firewall and people in the office.
They also had many applications. So we're going to focus on Cloud ERP, but, as you might imagine, a company like this that operates around the world, has many hundreds of applications. And so, we're going to talk about a couple of the important ones. So, for example, they're using ServiceNow for ticket management, which we are seeing big adoption among our customer base. Not only from the basic ticketing but also just ITGC control aspect of how ServiceNow has adopted those capabilities. And then they also had an IGA or IDM system, which they use SailPoint in this case to do user access provisioning in their previous systems. And the plan was two to bring that forward into the cloud as well.
So, we engaged with the organization that is responsible for operating the application, and the IT systems for the company. So the operational side, there's another side of the organization that does basically the deployments of these applications. So what made this customer unique for us, is that, we typically would engage with somebody in the compliance team, “hey, I've got these controls. I want to make sure you can lift and shift them into the new ERP system.” What made it, frankly exciting for me and challenging was that they also wanted to go to this kind of, what I call hyper-automated approach because this organization outsources a lot of their IT functions, business functions like many organizations of this scale. It's very important, to streamline your entire controls, especially the access controls because you have vast amount of third parties involved in providing those controls. I mean, from your perspective, how would you characterize this customer´s needs Matt from a compliance, an audit perspective, I guess?
Matt - They are in a high level of requirements in terms of control and risk appetite. There were opportunities for improvement, post go live.
Adil - So, that's where the challenges come in. And, the challenges that we discovered talking to them was around, how they were getting by in the current world versus what would not work in the new world. Auditors, external auditors had made it very clear to them, happened to be that, we worked with that same audit firm on a similar account prior to acquiring this customer. So, know, we sort of have a laundry list of what auditors would look for, even though they're unique and each business case. I'm not saying they always go with same list, but we had a good idea of what would not be acceptable to a modern auditor in a modern audit platform or modern operating model.
Absolutely necessary is the fine-grained SoD. You cannot get away doing a role-based analysis of SoD anymore because, ecosystems like Cloud ERP, which Matt will talk more about, has so many nuances that you can´t just say that if you have payables, you can have GL role. That's not sufficient. So fine-grained was a big challenge for them. They had gotten away with it in the previous world, in the legacy world because they have really good audits in place, manual audits in place, but they were paying a huge price for that. Because you have armies of people just verifying and re-verifying things manually in spreadsheets. They ended up with some challenges in reporting results. The timeliness and remediation was a big challenge. So, just how long it took to really understand what the problem is and then resolve it. For example, taking someone's privilege out. So if you think about Cloud ERP, and we'll talk about the hierarchy. If you take access away from one user, does it impact all the other users who do need that access? And really, it's a complex challenge they were facing. Not unlike many other customers we talk to that are looking to modernize their internal controls overall and segregation of duties in general, specifically.
Increasing scrutiny from the auditor that I mentioned already. That was basically the guidance coming in to the highest level, the Board Audit Committee level, to the Chief Audit Officer that there's a new requirement and in the middle of that was, not mentioned here the PCAOB guidelines got updated as well. So, just around completeness and accuracy, which is where the regulatory complexity comes in. So those are some of the challenges that we heard from them.
And then, to solve the problems we asked Matt, to help us and come in, and join the team to help us to solution this. And so, Matt, if you want to say a few things about, high level, how you see the solution put together, how you architected the solution, using SafePaaS tools, and so forth.
Matt - Yeah. I mean, it really is a combination of SafePaaS, sitting as the hub. So, it pulls in data from, from Cloud ERP, but also from ServiceNow and SailPoint, and fires it out in different directions, and makes sure that from an automation point of view evidence is captured within SafePaaS and retained, and, I mean, and we'll talk about it later. It gives quite a lot benefit for most organizations.
Adil - That's a great, good point. So the “Hub” is an important way of looking at a modern access solution today, and the orchestration of your identities across the enterprise becomes part of that scope, especially if it impacts financial statements in our world, because that's where we focus most. So having that knowledge was critical, because you couldn't, in other words, the old systems, you couldn't just get rid of them, because they contain such useful information about user access provisioning, and approvals, and certification, and all that. So you can´t replace the system. You have to integrate into these systems, because you'll want to be able to extract as much information about the role and identity as you can which tells the control owners eventually, or the role owners, as we call them the full picture of the controls so they can make better, effective decisions. It's not a rubber stamping exercise, which is a big no-no under the new guidelines. So, success. We can see the light at the end of the tunnel, I think, we've come a long way. And it's been a challenging journey, but now we can see that, as the customer is deploying cloud globally, deploying it outside of the initial regions. They will have the benefit of this global footprint that will enable them to not only roll out this application, but use that global footprint to really set the standard for rolling out future applications, for specific business cases, or point solutions.
Their accuracy has gone up, and I'll let, Matt take the credit for that. There are some big savings, from the number of issues that we got out of SafePaaS. And Matt spent a lot of times, I'm sure, looking at our reports and cursing us on how difficult it was to get through because we had a lot of data to get through and to get them to a size where, the false positives are all cleaned out, the mitigations are in place, and so, I think technology certainly helped accelerate that.
We did some enhancements to the product, frankly, that are in our newsletter, to meet the requirements. And that made us a better company to help other customers, because of the volume, and the complexity of this organization. So, that, to me, is a big success not only our customer and our partners, but also SafePaaS, in terms of success that we can take to the rest of the market.
Remediation has become a lot more timely. We have extended some of the workflow capabilities that make it easier to go all the way into your ServiceNow ticketing system, and post the corrective actions, and, I think, we're going to see the customer really reduce the risk, because what is the risk, is the amount of exposure you have. It's not just the impact, but also the exposure. How long the risk stays open, in case of access reviews and access controls. That's a big challenge, because you may agree to take someone's access away. But, when does it actually happen? The lock is not on the door until that happens.
One last thing and I think is the most important point, and Matt, I think that's where you can talk more, drill down into it, is that the number of control violations that have been reduced significantly.
Matt - Yeah. I mean, the headline is, it´s gone down by 99.1%,
Adil - That's awesome.
Matt - The number of violations, and that 0.9 %, are all known, all mitigated, as we'll talk about soon.
Adil - Absolutely. So, I mean, when you think about that. So, that's just the number or percentage. But what that means to an organization of this size and magnitude is a significant amount of hours and dollars in reduction. And not only that, but also people can go home on time, hopefully, and be with their families. Because that's also important - balance of life. This is not the job most people do as part of their day job. This is the stuff they do between their day jobs. And so, if you introduce this kind of risk in a business, not only the business works better, but the people see a benefit directly to them because everybody's engaged in access controls these days, because everybody has digital access.
Emma - OK, Now, let's dive into the Oracle ERP Cloud security model.
Matt - Cool, OK. So, I won´t fill too much time for everyone, but a user within Oracle Cloud will have two different streams. You've got the functional security, which is really inherited via whatever job / data roles, if we're talking about HCM are assigned, and then, it might be abstract, as well. And then those will inherit Duty roles, and they in turn have more privileges. But then, wrapping around that, you've got some data security, both for the role and for the user. So around the roles, it might be, that's really about, OK, the Jobs Roles, and Data Roles will define what screens I can see. And the data security then says, OK, I've got access to that screen, but what data can I see within that screen? So, an example might be that if I'm talking about an AP Manager role, then that might allow me to see the AP invoices screen through the role. And then my data security might say, OK. I can see the US ledger, or the UK ledger. Really, from a segregation of duties point of view, typically, the focus is normally on the left-hand side, funcional security around, OK, what screens can I see. And then, within that, data security creates some challenges sometimes. We'll talk about that in a second, but there's some certain false positives as it might look like I can access a screen but actually, unless I have data security applied, I can´t actually do anything.
Emma - OK, so how can you analyze user roles segregation of duty conflicts Adil?
Adil - Yeah, so, as we said earlier, and I think Matt had a good chart there, I think it's fundamentally the controls haven't changed. And it doesn't matter which system you use, creating supplier, paying suppliers, the risk that existed on some piece of paper 100 years ago, and it's still the same problem. It's just like I said, it's all digital. So, basically, what these examples show is how you would conduct that type of analysis within the Oracle framework that's in that diagram that Matt just covered. So, examples are, procurement managers, these are the examples of roles. Procurement manager is a role that you may assign to a user. Now, I think, if you have been working with Cloud ERP for some time, you know that seeded roles or out-of-the-box roles, as many call them, have not been tested or built for controls, segregation of duty controls to be specific. So, what you're seeing in that first column, there are examples of out-of-the-box roles, which are nice. They get you up and running for your conference room pilots. Or your first kind of exposure to Oracle, but there are significant toxic combinations underneath it. Those are the privileges that you see in sort of the second column there. So, being able to create purchase orders, approve purchase orders, create suppliers, we're kind of working with that example but you can apply that to the general ledger - creating journal entries, reversing journal entries, so the toxic combinations can go up from there. The last piece is what really authorizes that privilege to become active? So, one of the items is, if you're not a buyer, can you actually approve purchase orders? So, they fall into the category of false positives, or exceptions, in that category. But you have to set up your controls properly. So, in the context of Oracle security model, you have to think in terms of privileges that make up the roles. And then go to the next level of detail, which is the data security.
And I'll let Matt talk more about the security in the next few slides, but basically, there are many different ways that data security, security context, etc can contextualize the privilege. So in the old days, it was enough to say, “OK, I got it down to privilege. I'm fine-grained SoD, I'm done.”
That's no longer the case with Cloud. We're trying to build these systems for our customers so that they survive, not only the compliance risk of financial statements, compliance, and risk, and so forth that's guided by Sarbanes Oxley, for example. But also, you've got GDPR in Europe, but many companies in the US operate in Europe. So you've got all these data protection capabilities.
Now, the vendor in this case, Oracle, has to provide that capability, but that also, that flexibility, and that capability creates different loopholes for segregation of duties, which makes the problem really hard to do in a spreadsheet.
Matt - Yep. And as Adil mentioned from a segregation of duties point of view, it starts at a privilege level. We'll come up with a set of activities, business activities, and so taking examples on the example privilege, there might be one around enter purchase orders, there might be one around purchase to pay, configuration, you then get a roll up a number of different privileges, you want them all, but normally it's going to be a bucket between 5 and 10. Because Oracle provides lots of different ways to be able to do a similar activity. From there, we'll then build the rule, the segregation of duties rule that allows us to make it simplified from a business point of view, without having to go and report at each individual privilege level as a separate rule.
Emma - What are we seeing here, then?
Matt - So, these are a few examples of data security settings within the system that can impact on business processes. So, the top left one, read-only users. So, each of these are very specifically Oracle Cloud. So, the top left one is around read-only user. So, a new piece of functionality that didn't use to exist in E- Business Suite, but does exist in Oracle Cloud, is that I can set a whole user being read-only. Now, if I look purely at the privileges assigned to that user, it looks scary.
However, in practice, if somebody has set as a single setting, as read-only, it means that from a user interface point of view, I cannot make any changes. Depending on how organizations build their segregation of duties matrix and the roles that they've chosen to include, that could mean that no SoD issues for any read-only user. And certainly for the organization that we were working with, there were no rules in their matrix that would have been impacted and therefore we could take out literally thousands of lines of segregation of duties findings by excluding read-only users. The top right and the bottom left one are the opposite to each other. One´s on procurement, the one´s on accounts receivable. that is saying unless I am set up as a procurement agent or if I have an adjustment limit in AR I can't do the activity. In the bottom, left one unless there's a little tick box I´m just staring at my screen as it´s a little bit small. This is a tick box against manage purchase orders. It might look like, from a pure, functional point of view, I have access to enter purchase oriders privilege. Actually, I can get into the screen, I just can't see any data, and therefore, it's a false positive. I can't actually create or amend any purchase orders.
The same in the top right, which is around AR adjustments. There are specific privileges that will allow me to maintain or create AR adjustment, unless I am set up with…. And then around Security Context, that is where I link a user, and their role to a particular security context. I might link it to a ledger, I might link it to a business unit, data access, etc…
And unless I am linked to that, then I cannot see anything. So the bottom example that I've got there, this same user has access to accounts payable invoice supervisor and supplier administrator. Normally, you'd say, OK, that would allow me to create supplies plus create AP invoices. But as you'll see on the screen, supplier maintenance is for the United States business unit and the AP invoices is for the Canada ledger. That's not really a separation of duties issue then because I can't create a supplier and record an invoice against that same supply. That won't be possible if I don't have access to the same ledger / business unit for both sides. So these are the types of things that we've actually ended up building into SafePaaS to be able to filter them out. And what we found is for the organization, that allows us to remove thousands of lines.
Emma - Absolutely. The false positives Adil? How can organizations address false positives?
Adil - Yeah. So I think this just takes that idea to the next level that we just heard from Matt on the previous slide. By providing customers the ability to create these simple Boolean logic, but make it so it´s flexible where they can, in this example, you're seeing on the screen in the background, where you have an and condition. This ensures that only if the user has been assigned this procurement agent as a type of access on top of a privilege, only then this would be considered a risk. So this helps reduce thousands of lines of SoD violations, potentially, because you might give many people in your, everybody in the company has some sort of requisition access. And we all want to be able to buy stuff in our job roles, only a few people can possibly approve. But even that's a big list, because every manager has approval authority. So, when you get into these kinds of applications, purchasing is a good example where there's a wide usage of a certain function within the enterprise, and then by tweaking these privileges based on the context or the security attributes, you can limit that access. So, now in SafePaaS, you can limit that by creating these special conditions, which combines the privilege with the authorization.
That's the outcome, one of successes, I talked about is now that our other customers, that use SafePaaS, because we're on network and we´re a cloud company, so it becomes available to all our customers. These kinds of enhancements that we make, become available to all our customers that want to do the same thing immediately. So, for example, this has already been live, I know you and I talked about it in our newsletter, so this has been live for months, and it took us, a few months to get it right, and Matt helped us make sure it's working correctly and so forth, testing it. So now it´s live, everybody can use it. It's a big success.
Matt - And what I would say is, it might look a little bit complicated, but it's actually quite easy to implement.
Emma - Do you want to talk us through this table Matt?
Matt - Yes, so after we took out the false positives, we still ended up with probably a quarter of the total number of SoD violations were still genuine. And then it came about, “ OK, well, what do I need to do to tidy those. And, I kind of split it between six different teams, because different teams get impacted in different ways. So, an example being around the External Implementation Team, we were post-go-live at that point, or how do we approach those ones as well. For those ones, we disabled the account, as you'll see why later futher down.
So other ones then typically it was a bit more complicated and that might be around segregation of duties rules amendments themselves, around the role design, around role assignments, around the user accounts themselves. Then all of that helped us to get to the point that we had a clean set of roles. We had a clean set of assignments, but there were still some challenges around, OK, actually, we needed to work with the business to change the operating model. That sometimes was around changing the fact that IT we're no longer going to do transactional business activities or moving activities between business teams and that helps with both ERP and HCM users.
Then we are still left with a residual set of SoD challenges. And then for those we built custom reports for a limited number of occasions and developed some mitigating controls and documented those and made sure actually operating effectively. I will talk later about some of this in a bit more detail.
Emma - So, let's have a look at Rules Management to start off with.
Adil - Yeah, so just kind of connecting the dots from the previous slide to this is, as you can see, SoD is not about just pumping out a report out of a system. It's about those steps that we'll go through in the next few slides. So, as part of those steps, the first step is, obviously, you´ve got to start with good policies. And I'll ask Matt to add to that. But we started with our, as a software provider, we have a standard template. Now, we do recommend customers not to just use the template. Because, guess what? The guidance from the regulators and the auditors is to really take a risk-based approach, and really think about your controls, your business, your business model and how risk gets rated in your organization and treated as well. So that's defining the policies. And so, we have the tools and the capability to define the policies. Like I said, we have some templates to get started with. But this is where we leveraged our relationship with Matt's organization and kind of reviewed that with what we had to start with and what the customer really needed. That requires in-depth conversations about dataflow, and the process mapping and so forth. And so that's kind of a first step.
But from a technology perspective, we can import the rules, and we can start with the templates, we can help you create rules. So the tool enables you to define policies as we call them rules in SafePaaS. You can customize them, which I'd like Matt to say how did we customize some of the rules? Some of the rules had duplicates. It's an art. I mean. And I admire how Matt was able to use the rules as a strategic tool to really figure out, what rules will really produce the best outcomes for the customer in terms of risk mitigation. But also, reduce the burden on remediation.
Then updating those policies. So, Matt, do you want to just kind of dig into those points a little bit more?
Matt - Yeah. And it was interesting to explore why some of the rules for that, and, actually, some would, based on organizational requirements, but some are coming from the external auditor. And I had some fun challenging some of those ones, particularly. Because, yeah, I didn't think they were necessary and that they weren't in line with what other organizations would implement. And being able to challenge that and provide a rationale, why?
And provide a rationale of how that risk is actually being covered, or why it's not relevant within Oracle Cloud, allowed them to be able to chop out whole rules which was awesome, because at that point, if you de scope to a particular role for legitimate reason, and that's been agreed by the auditor that means thousands of violations that are going to go there and then. Parts of it were around, “OK, the rule might exist, but the privileges within there, let's tweak those.” So, quite often, it was, “yes, this could be high risk.” However, you need a combination of this privilege, plus this privilege to make the second privilege high risk. So, at that point, there wasn't really much point in keeping all of those privileges, because if they are high risk on their own, then would kind of be back in the false positive pocket again.
And then a third one was around “OK, even if it is high risk. Sometimes they were either they're just in there in the wrong classification. So quite a lot being triggered when something has been called our configuration, but it's really actually a transactional privilege, and vice versa. And at that point, that was triggering the whole heap of violations both for business unit users and IT uses that, really were relatively easy to tidy up. But I mean, the key running theme are approvals and change management. So nothing was changed in any rule set. And SafePaaS has got internal controls within the tool itself to make sure that I can't just go tweak and remove the privilege from a rule because I don't like it. It has to go through an approval.
Emma - The next step. Remediate Role and user conflicts.
Adil - Go ahead, Matt.
Matt - Yeah. So, I mean, one of the key things was, after we got the rules correct, it is about understanding within any one role we need to make sure it's clean. And when I say clean it, I mean, it has no inherent segregation of duties issues. Because if any one role has got both sides of a conflict then anybody receiving that is going to have a conflict. And other than a single service account, there are no users. When I say service I mean no integration, use it. There are no other users that are using any roles that are not segregated by design. Because once you've got a clean set of roles, it becomes a lot easier to know, “OK, if I only give it that one role, then that I'm not going to create any other SoD issues.” So, that's a kind of an ongoing maintenance benefit, as well. Now, in terms of how we went about doing it, typically, we would create a custom role. And It could be one of two ways we went about doing it. So it could either start from the ground up, if it was a small role, that we just building for a specific activity, such as auditing configuration. We split out from every other role, took it away, and then created a custom role just for auditing configuration. Or it could be that I'm gonna start with an existing role and then chop out individual privileges,that are triggering segregation of duties violations.
Now, that led to, probably the vast majority of conflicts disappearing, particularly for those that came from HR users.
Adil - So, from a SafePaaS perspective, Matt, just to kind of, add to what you said, is, we provide you these types of reports. This is just one example, but reports have drill down, so you can see at the role level, what is the role made up of. And without getting into too many details, just kind of referring back to that graphic Matt had you can see the top level role, inherited roles, duty roles. We provide you all that functionality in the tool so that folks like your partners like Matt, then your internal auditors, external auditors can review that, and then make those kinds of judgment calls on that Matt just referred towhat's the best way to remediate the role and hopefully make that process a little easier for you
Matt - On this particular screen, it´s very clear, I mean, I know you´ve drawn a box around it to make it even clearer, but a single privilege that's causing a problem, OK. Let's have a conversation about that. And then, in realistic terms, this organization. And that privilege would have been agreed to be chopped down.
Adil - Absolutely.
Emma - The next step?
Matt - So after the roles themselves are clean, because it's about making sure that, “OK, how do we then take away the out-of-box roles or previous versions of roles, and replace them with the new ones?” But we're not going to give them back in the example that we just had on screen. The user had both payments and capacity to create payable invoices. We're not going to give one role that allows them to do AP invoices and then one role that allows them to do payments. Unless there's a really good reason, and for the vast majority of occasions, there was no really good reason for why any one user needed two conflicting privileges across different roles. So because we created separate configuration roles and kept them, they are clean. They had no transaction on the master data access. Then, that allowed us to separate those out, and the nature of their organization is that they have an IT team that deal with configuration. The end users in the business don't deal with configuration so that allowed us to be clean.
Adil - Can move on.
Emma - User accounts.
Matt - So, I think I mentioned for the implementation team, we know that unless there was no rationale for maintaining the account. So, we disabled it and for a limited number of users, we made their account read-only. And often, that was for them when they were an external third-party support team, who needed the ability to see what was going on in production, and to see configuration, to see transactions because they were providing support, but they didn't need to be able to update. So, that might have made it to be able to see both a supply master data and the invoices, the AP invoices coming through. But, they didn't need to do both of them, make changes to both of them. So, we made their accounts read-only. In practice, that was a short-term fix. Nowadays, I mean, they're clean. Other read-omnly bits of access have been chopped in production. But because SafePaaS has got filters built-in around read-only uses, it was a very quick and easy way to be able to demonstrate to auditors, we had already tidied an awful lot of stuff.
Emma - Operating model changes.
Matt - So this was one of the most interesting ones, because other than changes to segregation duties rules this was the other area that required a lot of influencing skills. So whereas changes to segregation of duties rules, internal teams are broadly happy with any changes being suggested.
After all, we were brought in as subject matter, experts in the area but, the external auditors needed a bit more convincing. These ones, when we're moving activities from one team to another, then people pay attention to that normally. Actually, from an IT point of view, they were fine with giving up their transactional activities. It makes their life easier to be able to say, “I'm afraid I can't create a journal for you anymore, because I don't have the access.” That clearly brought them benefits from a capacity point of view, as well as a controls point to you at that point. The moving activities between Business Teams, I mean, that was definitely a joint effort between ourselves, plus, also the actual local business teams. Because that was them thinking “OK, based on this particular user, or this particular team having access to A plus B, how can we do this differently?” Where could we move one of those activities, to? Because we built segregated roles, then we and they knew that if they took away one of the business activities, they could then take away one of the roles, they would be clean. Now, wasn't completely 100% successful, Not far off, but no. There are few limited areas where their team is just, they can't separate some activities out.
Emma - And the last one, the mitigating or compensating controls.
Matt - So for the organization we're talking about they were down to two different buckets. There was about 3000 violation lines related to a single service account where we know about it. And therefore, we made sure that there were a whole heap of mitigating controls that prevent people from logging in directly as the user that monitors when they, if somebody ever did manage to find a way to get in, around passowrd controls for the user, around audit logging, changes that are being performed by this user. And then we documented them. And then we made sure they were tested and operating effectively. And they crossed over with a number of other different IT general controls that were being covered anyway. So that was beautiful from our point of view.
The other half for the business activities. Because we knew which segregation duties rules were going to be conflicts have one or more conflicts against them. Then, it was about making sure, for those individual rules, how do we mitigate those specific risks? So, if we're talking about AP invoices, and payment, if we´re talking about actually opening and closing periods, plus entering a journal, for that particular one, we know that they're operating model is that the close team do do both. We agreed that they shouldn't be opening a prior period and entering a journal in that prior period. So, we built a custom control that pulls in the data, says, “OK, show me where somebody has opened it in a prior period, and then to the journal.” We made sure we tested it, in non-production environments, and proving that it worked and now it can operate. And sits there with data in production. So, it's really about making sure that there are mitigating controls that are designed, operating, designed effectively and operating effectively. People should be actually checking in, not just assuming that everything is all good.
Adil - Absolutely.
Emma - Well, that brings us to the end of this session. And either of you want to add anything before we move on to Q&A.
Adil - Just want to add, kind of summarize where we are with this client. I think Matt covered all the accomplishments so far, and depends where our listeners are in their journey. Because every company is unique. So, if you are in a similar situation, this is a great place to start, with that chart where Matt showed, starting with the rules and going step by step in a very logical manner. If you already achieved that, in other words, you have a good steady state, one of the things that I think about is how do we keep the systems clean? All this investment that our clients make and getting to an effective stage with their SoD. How do you keep it effective? And one of the things that we're exploring is, we have a couple of more products that customers not using, and we didn't mention those. So I thought I might just mention them here. So we have this tool that integrates with your provisioning process. So let's say, if you're doing provisioning in SailPoint or Azure, or something like that, we can take that information. And basically what we call it, preventive controls. Being able to assess, simulate if a request will create a problem down the line, and then alert the right approvers to review that and prevent that from happening. In other words, do not grant that access because that's a worry of many of our clients, including this one is that even though we're cleaning up all this environment it's possible through, a provisioning system somebody is requesting that access back, and right now, we have some good manual controls on it. But, that's something to consider. Same thing with, Oracle shifts new roles or new privileges as the patches get applied every quarter. So, having someone like Matt and some tools - SafePaaS has a roles manager, review those on a periodic basis, would be great, I think an ongoing need that can be addressed. So, just because you've gone to a steady state, it's difficult to maintain that unless you have some of these basic services and tools in place. Otherwise, you have to repeat this exercise at the end of the year or the next big audit committee meeting, when things get bubbled up to the Audit Committee about your financial statement risks and segregation of duty shows up on the list. So, to prevent all that, you gotta think preventive. And I think that's where I see ongoing success with this customer, and many of the other customers that might be today, in a happy state with SoD. But things are not going to stay the same way because business doesn't stop.
Matt - And I think, linked to what you just said Adil, quarterly releases will always mean that there's different additional privileges from the work we've been doing. What we've found is that there's roughly1 to 2 privileges a quarter, that we think should be added into the segregation of duties rules. And therefore, the rules are not static anymore. In E-Business Suite I might have created the roles and then tried to forget about it, but that can't be the case in Oracle Cloud.
Adil - That's right. So some good tips for those of you that want to take on this journey and reach out to Matt.