Emma - What are some of the current challenges that Oracle E-Business Suite customers are facing?

Navinder - Oracle E-Business Suite and Oracle ERP Cloud are complex systems. They're really the heartbeat of the back office, especially finance, procurement processes, and your HR processes. If you’re SOX compliant you know these are key systems to get SOX certified. Some of the challenges E-Business Suite customers face include:

Their number one challenge is generally around segregation of duties, a specific ITGC control that stipulates no single user should have access that allows him or her to either commit financial fraud or to misstate accounting information going back to the legacy of Enron.

Segregation of duties is challenging. An EBS system has 10s of 1000s of forms. An organisation needs to define a segregation of duties matrix around the principles they have and then translate that into Oracle Forms and make sure people aren’t given access to forms that conflict. This is difficult to do manually, which is where automated solutions like SafePaaS help - detective segregation duties.

Customers also face challenges around preventative segregation of duties. How do you make sure that over a period of time, your internal controls environment doesn't deteriorate? Having good controls around the user provisioning process when you assign access which isn’t as straightforward as it seems. Starters, movers and leavers, seems quite simple but when you look at it from a segregation of duties perspective it really isn’t.

Periodic review of access. Some organizations have really complicated Excel files, which go from the central control, the SOX team via email to hundreds of people who have to validate, and then somebody has to correlate all of that. Periodic recertification of access - what other roles that users have appropriate. If this is done manually, it’s a time-consuming, error-prone, painful exercise. Tracking sensitive access, tracking, privileged access that users have are also challenges.

These are challenges EBS customers are still facing today given the complexity of these systems.

Stephanie - In addition to some of the, at the access level, for users, also, when it comes to change management of some of those responsibilities, or if your EBS environment, and the way that you're using it, the modules continue to evolve over time, and you need certain responsibilities to assign to users that may be at the time of go live, maybe those responsibilities were clean or free of SoD conflict but as changes are needed, or new responsibilities are built that's something that over time can change and without a GRC tool to monitor that it can be quite a blind spot on the access side. In terms of configuration monitoring, a lot of times such a big advantage of using EBS and other ERP applications is that there are potentially automated controls that are built into the environment, such as maybe Workflow Approvals. Many organisations rely on these configurable controls as part of their control environment. But at times, maybe not maliciously some of these configurations are changed inadvertently. That's something else that GRC tools can help with, monitoring some of those key configurations that support the control environment and provide that visibility so that teams don't have to do that manually as well.

Ian - Anything around IT general controls in an IT environment is going to be challenging. I took Millicom through a SOX implementation programme. ITGC was our single most complex, most time-consuming area that also had the highest risk attached to it. From a risk perspective, when I'm looking at an ERP, anything that goes wrong in terms of IT general controls around an ERP system has a real pervasive impact across the organisation because it calls into question every control that relies on reports coming out of that system. It was really the number one risk area, IT general controls, access, privileged access, change management, segregation of duties, all those control topics in the context of the ERP. These were some of the topics that concerned me most and took up probably the most time, internally, getting ourselves prepared in terms of how we effectively design an approach, and then implement and roll that out across the organisation. Also get the interested stakeholders comfortable with that approach. Whether that's internal stakeholders in IT, end users, process owners, external auditors, there's a lot of work that goes on getting all those viewpoints and interests aligned, in terms of getting an effective internal control framework - one that everybody can be comfortable from a reliance perspective.

Emma - Customers that are planning to stay on EBS, how can these complex challenges that they're facing that you've just talked about be addressed with solutions such as SafePaaS?

Stephanie - I think, from my perspective, such a big value add of implementing a tool such as SafePaaS is that for customers who are planning to stay on EBS can get that framework in place. Establishing what those key configurations are within EBS that you want to monitor. What are those segregation of duties risks that you want to monitor? What does your organisation consider sensitive access? Getting all that framework in place to support the current EBS environment. Then as the company and the application landscape evolves in the future, those additional applications can be brought onto the SafePaaS application. There's not necessarily a need to wait in terms of when new applications are being implemented, because SafePaaS is able to integrate with other, whether it be cloud applications or maybe just other applications that are supporting the business.

I think that that's one big benefit of SafePaaS. The other thing is that SafePaaS started out as an EBS tool. There's a lot of robust functionality as it relates to EBS and if companies are planning to stay with EBS, SafePaaS can continue to support them. If there's a change in something new, a new business object, for example, that is a key configuration for them that they want to be monitored, that maybe wasn't available at a certain time that's something that Nav’s team help work with to continue that support for customers who plan to remain on EBS for the foreseeable future.

Emma - What about those planning on migrating to ERP cloud, for example?

Stephanie - I think if EBS for a lot of companies that are planning to go over to ERP cloud, it's not always clean cut, there's maybe a phased rollout.  So it makes sense to implement a risk management tool ahead of time - the sooner the better when we were talking earlier about when's the right time to implement GRC tools, as early as possible because, as part of the organisation potentially remains on EBS you continue to have that visibility as some of other organisation even if it's a big bang approach starts to migrate to ERP cloud, you have that framework in place so you can start to monitor all of those things in your future state environment.

Another thing to keep in mind is just the pure act of a new system being implemented. Undergoing that transformation internally introduces some other risks that are a little bit different than some of the operational risks we've been talking about.  Some of those classic CITC is, as you're going through that implementation, you have service providers who are going to have access to your data, to your systems. Having a tool such as SafePaaS not only helps to have that visibility into not only the people who work within the organisation who are potentially part that have that access, but also who are the service providers. As people come on to the team, and leave the team, making sure that their access is appropriate and not excessive, also helping to monitor some of those service accounts that may be get set up during the implementation. And also, just helping for example, as the service providers doing configurations, migrating code, whatever it may be, into Oracle Cloud in one prod, or environment, to check to have that quality assurance that it's matching some of the other environments as well. It helps both from a risk perspective, as well as an efficiencies perspective, to try to get GRC tools involved in the process earlier rather than later. I think we've seen a lot of clients who are quite overwhelmed by their migration to Oracle Cloud, and so that their thought is, hey, let's get that set up and then let's come back to the risk management piece. That tends to create a lot of additional risk, and potentially blind spots that then it's effort and money to clean that up later on.

Navinder - I think the most important point, from my perspective is, when you're doing a major ERP upgrade, whether that's from Oracle EBS to ERP cloud, or maybe from SAP to Oracle ERP cloud, or whatever it might be, just don't forget about controls. What tends to happen on these projects, and I've actually led some ERP projects so I have a pretty good understanding, is that the focus is generally from an IT perspective on delivering the new system, by a certain time in a certain budget, which is absolutely perfect. But if you forget about controls in that process, and don't have somebody looking after looking at certain specific business control areas, and access control areas, that tend to be problematic, right through the implementation, then you have a very expensive piece of work coming up at some point post go live. Expert organisations, somebody like Deloitte, who actually has this skill set, working with you through that process makes it much, much easier.

The other point I have around this is Oracle ERP Cloud comes with certain nuances, which are quite different to other versions, you've got various concepts, and I'm not going to bore folks with technical concepts, but you've got certain types of roles, which are seeded, and then you've got to create custom roles. Sometimes if you just copy what comes out of the box, you get inherited, you inherit a lot of roles and privileges, which you don't even know what access you end up giving to people. Just make sure you really design the security model appropriately so that you can avoid future issues. So those are the two points I just wanted to add to think about.

Stephanie - We had a recent example where a client was migrating from their old system, so PeopleSoft and a few other applications and going to Oracle ERP Cloud, and their approach like Nav said is ‘let’s get these modules live by this date.’ Throughout the implementation there are certain custom roles that were developed to support the business processes. Then some people took over the security administration, which was quite new for them, because it's a new system for them, maybe a little bit of a different skill set. Going through the project, they had made a series of changes to those application security roles. The organisation didn't have visibility to see over the course of the last six months, and the tail end of the implementation, a whole bunch of excessive access has been introduced to users. So then as part of the implementation, there's typically other vendors in there, and other stakeholders, whether it be internal audit groups, or potentially external auditors doing pre- implementation reviews. When those third parties came in and did a review, it raised lots of red flags. Really, when really short time window right before go live. The organization was then struggling, and then another vendor to try to do more clean up on those roles and then have to pay those external auditors more money to come in re-review, since the first audit raised a lot of red flags. If you have a GRC tool that's in place, and you have the right people monitoring the tool, and using its functionality, it can just help provide that real-time feedback. Maybe someone requested additional access, there was a reason to give them that access, but that triggered this SoD conflict, was that approved? Or how do we go about tracking all of that rather than having to do so much rework on the background which really incurs a lot of cost for organisations?

Emma - What about those that run more than one ERP system? Organisations often run multiple ERP systems and hundreds of applications, on premise in the cloud - how do they address risk in terms of having multiple systems and applications?

Stephanie - I think I touched on this a little bit more, we talked about maybe clients that are on EBS, and then planning to go to Oracle Cloud ERP, and maybe they're running in parallel as part of the cutover. I think organisations that we work with are not necessarily 100% Oracle ecosystem. There's typically, there might be other HR systems in play, or maybe other systems that are helping with invoicing or master data. Something that's been a hot spot for auditors as of late, I would say, is looking at segregation of duties risks, not just inherent within one application, but does a user have the ability to do certain transactions or certain configurations in multiple systems? So, I think that's one benefit SafePaaS or other GRC tools, is that it provides you the ability to have one place where you're looking at segregation of duties risk, within your ERP, if Oracle may be Oracle Cloud, maybe Oracle EBS, but also SafePaaS has the ability to integrate with those other applications as well. So rather than trying to either, maybe manually monitor some of that access, or have separate kind of siloed GRC tools, I think something that it helps with efficiencies, and obviously costs to have a one stop shop, where the different stakeholders have that ability to view into cross applications.

In terms of other capabilities to have it, if you want to talk on that, but I think what we see a lot in the marketplace now is a desire to have more capabilities within a single tool instead of having to run the case at a different GRC tool for different applications. And also, maybe, as it comes to some identity and access management capabilities, making sure although a lot of organisations have certain tools in place to help with identity. Sometimes those tools don't have the ability to do the fine-grained SoD at the most granular level. I think figuring out in terms of what's the application landscape looks like for all of these types of support tools, whether it be identity tools, and GRC tools, in figuring out what are the sweet spots for each of those applications. That way, they're complementing one another. What are the pain points the organisation has, is what capabilities they should be focusing on.

Navinder - To add to that, I think earlier to the point that Ian was making around IT general controls being the most complicated area for SOX implementations or, indeed Risk and Compliance programmes, having multiple systems just, this extends that out multi fold, because you sometimes have to consider access controls across systems, access certification across systems, so who has access to what roles in which ERP system and I think having the GRC too which can look across would be to be really useful.

Ian - I think I'd echo all those points from a client perspective, the more that you can use one GRC tool to identify, monitor, manage, your internal control, risk the better.

I think it should be the ultimate objective. It's not easy, but I think if you can look to tools where you can bundle capabilities together and deal with multiple systems, multiple platforms, because as Stephanie said, ERP is a core of any financial system, but many organisations may have different ERP environments, HR, billing systems, maybe other add ons around procurement or supply chain, or whatever, and risks around access, change management risk around segregation of duty, cut across all those platforms. The more that you can link those platforms together from a risk management perspective, the more you can use one tool to do that, the easier and the and the more effective your controls in your in your risk management programme is going to is going to be.

Emma - Why is staying on outdated GRC software a risk for organisations?

Navinder - I'll suggest a couple of thoughts around this. There are certain software vendors who, as they move to a newer version of their system, they have naturally stopped developing the older versions. If you're using a GRC software that is one such software that isn't being developed, bugs aren't being fixed on priority. The vendor is basically saying that we are going to stop supporting it in a in a few years. They put a timetable on that, it's a big risk, because what that means is the tool’s no longer dynamic is no longer keeping with market trends you might miss out on certain key controls, key developments around controls, whereby the output that you get out of the two, you might have more manual activity to do, which is exactly why you don't exactly what you don't want when you invest in a GRC software. So, I think having

GRC software that is that is that is up to date, in terms of vendors actually focusing on developing and constantly improving is a big advantage. I think I just like to make a point that two different types of GRC software is a broad term, you've got the GRC software applications, like the Archers and the MetricStreams of the world, which are generic GRC solutions where you can run a SOX programme, you can document all of your risks, and you can document all of your controls and all of your evidence, which is a very different thing to GRC software, which is specialised like SafePaaS, which is purely focused on alleviating specific IT general controls risk around ERP systems like Oracle. This is very specialised, but the comments I've made around the risks are not in the GRC software apply to both camps. There are large vendors who have ERP specific GRC software, who are not supporting that software anymore, which makes it makes it a large risk for organizations.

Stephanie - Now, I would just say, as I've said generally, the way that you use your ERP application is going to continue to be dynamic and change over time. So, the way that it is implemented on day one, you still have an Operations and Support team that are potentially developing new functionality as your business continues to evolve. So, if your GRC tool is stagnant and supports that, it becomes less and less useful for the organisation, because as maybe there's new functionality that the business has started to use, and potentially you want to track some of those configurations. But for example, those objects are not available. Your vendor is no longer developing those objects for you to use. Now, you need to develop a manual process. So now you're trying to have people who are using the GRC tool to try to gain efficiencies, but then also have to do things outside of the system. It makes it less useful over time. If you have an issue where, for example, it's an on prem and it's connected, your GRC tool’s connected to your on prem environment and there's something that's wrong with the connection between the two and maybe the data isn't interfacing over completely accurately, now you're in a position where your tool is completely useless until you're able to troubleshoot that. And that was something I had seen, in the past just some issues with data coming over, at some point due to there being too much data or whatever it may be. But obviously, with any tool that your organization's using, its technology, and there's a risk for it to break, or there could be bugs. You really need your vendor to continue to support you through that, to make sure that your tool that you're continuing to pay for as an organisation is really meeting your needs.

Case Studies

Ian - I've spent probably the last five or six years grappling with the challenge of implementing a SOX compliant internal control framework in a multinational organisation. I think, up front there we identified that IT general controls or ITGC around EBS, that was going to be one, if not THE major challenge, in particular, as sort of alluded to before segregation of duties, user provisioning, user recertification. Things like how we keep track and monitor significant configuration changes, sensitive changes in the system, so a whole array of, of control topics around EBS that we identified as complex problems that we needed to solve. I suppose maybe I'd highlight five or six kind of key learnings from my perspective, and I'm talking here as the project sponsor for the whole of the piece of work around the internal control framework, in preparation for the listing, and maybe it's worth saying that whilst a lot of my work was focused on the requirements needed to comply  with US SOX, I think the learnings are applicable to any organisation that is going through an internal control transformation programme, not just applicable to US SOX, and that there are many other territories in the world that are looking at corporate governance in this area. In the UK, some people may be aware of proposals around a UK SOX type regime coming up. So, I think, everything we're talking about today is equally applicable. I think for me a couple of key learnings, one is around stakeholder management. There's a large number of stakeholders involved in any kind of internal control programme, the IT team themselves, end users, process owners, information security, internal audit, external audit. Don't underestimate the time and effort that that's required in terms of collaborating and working with those individuals because the more that you can get alignment of your work, the more you can deliver a programme that can hit, not meet the needs of users, the needs of the internal control community, the needs of information security professionals, with cyber professionals, the more you can work collaboratively and get one framework that hits all of those requirements, the better, but it does take time, and it does take effort  to get that alignment.

Secondly, on a similar theme, I would mention the external auditors here. So, a lot of your work, particularly around ERPs are going to be, your work is going to be used an external auditor, if they wish to rely on internal controls. That is one of the big paybacks of investment in a programme around internal control. But  in my experience, don't assume that the external auditor will know everything around about a GRC tool, don't assume that an external auditor will know your ERP in depth as a subject matter expert, in that you also need to spend time with them walking them through what you're doing, from a risk perspective, what you're doing from a controls perspective, educate them about how you're doing it, and talk to them about some of the choices that you might be making, particularly around how you define your segregation of duties, what roles you're identifying as particularly sensitive or privileged, what things you are monitoring,  through alliance, or through alert, because, you know, they will have some views on what they consider is important. So, spend the time with them up through going through your decision-making process, and that will maximise their ability to leverage your work, their ability to rely, and ultimately, that is part of the payback for the investment in terms of time and effort.

Thirdly give yourself plenty of time for this work, if you've got hard deadlines, such as a listing, such as a year end coming up or whatever, give yourself time because to do it properly, to design, test, do lots of dry runs, do lots of pilot testing, there is there is quite a lead time here, particularly as I mentioned, when you're working with lots of other stakeholders in this environment, so, build a realistic timeline around your programme. And as I said, give a lot give yourself lots of time to to pilot test before you absolutely need to rely on the outputs of the GRC.

A very positive one, I would say and from my experience was that we actually had an unexpected cost savings coming out of the programme that we implemented and how we used SafePaaS. So, it's some cost savings that weren’t part of the business case. But when we went through the process, and we looked at using SafePaaS for automating the user process, automating the setup of new users, we found some cost savings that we didn't originally expect in terms of not needing the time and effort from an external help desk as much as we had previously done. And those cost savings ended up being quite significant. And, as I said and a real added bonus for us, quite compelling, a positive outcome.

My final learning as well is, don't forget around about controls around the GRC and the GRC platform itself. If you're using a tool such as SafePaaS that also needs controls around it around access, around change management. And again, you want to rely on the output of this, you want your external auditors to rely on the work you're doing, they will look at the controls around the GRC itself. And it can be really easily overlooked in the excitement of working through the core design and implementation. But don't forget about those. Otherwise, you might be tripped up at the end.

Stephanie - I think Ian has a lot of perspective on the value add from his side being a client. I would just say, like, from my case, study perspective, and just most important success factors that we've seen are making sure the right people are engaged, like Ian said, and just keeping in mind that a GRC tool is still another tool. So, making sure you allocate time to train the users, test it, identify how it can best help the organisation. I've seen some cases where clients have been interested in GRC tools and they've figured we can just use this tool ourselves. Or we can just have somebody come in for two weeks and quickly configure the tool for us. And then we'll figure out how to use it. I think a lot of us who have been through large scale transformations, either on the audit side or as the implementer. Know that the number one thing for success is the change management. So just think it is important to understand who the stakeholders are on bringing them along for the ride, and then making sure that you're not just configuring a tool, and then you have no idea how you're going to use it. And making sure like Ian said, it's, it's still another application that you do need to manage. So, the testing piece, after the configurations have been set up are so important to show, if you are going to rely on using some of the outputs of the tool, how can you be sure of the completeness and accuracy. Making sure you have all the evidence for that that's something that I'm being on the external audit side of some GRC tools is something that we've said, Hey, if you like in my past life as an auditor, just if you're planning on using this, how do we know that all the information that's within the tool is accurate? So, you do want to make sure that you have all that documentation, and you've allocated enough time to get all that testing, so that both internal and external stakeholders are comfortable with how the tools being used.

Emma - Where do you all see risk management solutions heading in heading in the future?

Stephanie - I think we've touched on it a lot before. But I think the main thing that I'm seeing from a lot of our clients is easy integration with multiple applications, to get that cost savings and the efficiencies so there are not multiple GRC tools in play or blind spots. So, I think cross application is a really big one. Making sure that out of the box, that it's easy for these companies to feel comfortable that they're able to connect to this SaaS product. I think the other thing is just making sure that there's efficiencies for companies to leverage tools that they may be already have in place that they don't necessarily want to replace, to complement those tools. So, for example, I've seen a lot of clients that use ServiceNow as a ticketing tool, for example. And they want to as part of, just maybe in the past they've had that ticketing tool and it manually gets routed to somebody who approves it and then takes it and then gets that access updated in the system.  Integrations between types of tools, ticketing tools, or Jira, or all those different tools to make it seamless behind the scenes, just to remove manual intervention wherever possible kind of like the use case, Ian was describing where not needing the reliance on all those extra manual steps that maybe the company is accustomed to. So, I think cross application is the big one and seamless integration with existing tools.

Navinder - I think cross application is really quite a big one. The other one is, Steph mentioned about tools like ServiceNow, which are for ticketing, but we see a large number of clients also using tools like SailPoint, which are your identity management solutions where, whereby single stop shop for assigning access and removing access. So, integrating with those tools, because, from an Oracle perspective, specifically, an ERP perspective, there are certain controls, which does IDM solutions can't really look at because they are generic tools, and, for example, preventative segregation of duties. So, in how does a platform that is specialised integrate with those tools becomes quite important from a customer perspective, it becomes quite important to consider that, that how you will have complementary products like that working well, for example, a product like SafePaaS and SailPoint, ServiceNow and so on and so forth. I think that's an area which you see a lot of dynamic built in. I mean, the question is quite generic headed in the future, I can't think of any use cases for artificial intelligence of blockchains. But I'm sure in the years ahead, there will be some really interesting use cases or really good ideas around using advanced technology, but at the moment, these are the kind of areas cross application, integrating with IDM and IAM solutions.

Ian - I mean, I think integration as a theme definitely when we talk about GRC, it's a very broad generic term, SafePaaS GRC in terms of looking at specific risk management and controls around ERP and other solutions themselves, but then there are also the wider GRC systems that look at sort of broader risk management, internal control, documentation, testing, etc. I think one thing about one thing for me around integration will be getting those types of systems talking together, so that you can kind of pull all your different control risk management activities together. I think looking at thinking, looking at auditor capabilities, making sure the systems are user friendly from an audit perspective, and can help facilitate internal external auditors, getting the information that they need out of it. I think that's important and, and a big thing and  a potential cost saver. You know, and it's a changing world. I mean what is important today, from a controls and risk management perspective, that is going to change over time, and platforms that are flexible, scalable with the most minimal time and effort, obviously I think  those are going to be the solutions that do well, in the future, and also ones that have a great end user experience as well, recognising them, a lot of people that use these tools will be knowledgeable in their areas, maybe they’re finance professionals, shared service professionals, process owners, that'd be knowledgeable in their area, not necessarily knowledgeable around maybe from a more technical perspective in the ERP. I think the more that vendors can make their solutions accessible, readable, understandable for kind of educated end users. I think that will be a defining point in terms of the solutions that are successful in the market going forward.

Q&A

What about if we're already live on ERP cloud? How can a solution like SafePaaS help us?

Navinder - Shall I take a shot at that? We've actually been implementing SafePaaS at clients that already implemented ERP cloud. In terms of how it can help, so the use case that most gets presented and is really a great starting point is separation of duties because it's a complex area. If you've already got Oracle Cloud, you've got this new system with new concepts, privileges and duty roles, job roles and data access sets. SafePaaS Enterprise Access Monitor is really quite good at making it really easy for extracting information out of Oracle Cloud, and then analysing it from an SoD perspective and presenting out. So, from a detective SoD perspective, if you've already gone live with Oracle Cloud, that's what I’d highly recommend. We can do a demo and show you how that how that might work. The other product that the other area that I could recommend looking at is the access certification. So, periodic access reviews of privileged access. So, if you if you've defined out of your 200 roles, 50 are considered privileged or security wise, more important. And the enterprise access certification tool can actually help you with automating the certification that we also have fusion specific Oracle Fusion specific functionality, looking at business units, etc. And it's quite flexible. So, I guess, those are the two areas that I would consider. There's also of course, the user provisioning aspect. So, you can have preventative SoD from user provisioning perspective we've got a tool that can look at that. And also, one which monitors configuration changes. But generally, the use cases tend to begin with separation of duties, and then go on to recertification, user provisioning, and then the more complex configuration change tracking.

How difficult was it to have effective segregation of duties controls without GRC tools?

I mean it's possible.  You can build specific control objectives around key segregation of duties risks, but how you control and how you monitor those segregation of duty controls becomes quite difficult, it becomes quite manual. It often becomes detective rather than preventative. So, you are looking at correcting problems after the fact. And therefore, when you do identify an issue, you are then also going back and trying to work out, what if anything actually went wrong during the period that your segregation of duties ineffective. So, don't answer the question like everything you could, you can always come up with some way of maybe not necessarily managing it, but at least mitigating the control risk, but I think you'll find that it will be more time consuming, more onerous in terms of the manual activity that's required to do it. And, and ultimately less effective in not having, you know, a level of an automated tool that that can help you address those SoD control objectives.

Stephanie - Yeah, I think we, I've seen working for a service provider, we do have a number of clients that will pay the weight or other companies that have developed internal proprietary tools to do periodic SoD scans for them, and then provide them with results from that, and then they'll take those results. As Ian said, if there have been some conflicts identified, then you have to go back and do an analysis to say during the time this person had this SoD conflict. Did they actually act on it? Did they remove the access that they've had so far? There are number of organisations that actually are outsourcing that to companies that have the ability to do those SoD runs for them, and that's a recurring cost for them, and not just a financial cost then they still have to have maybe their DBAs, get those extracts and send it to the company, and then the look back analysis and all of that. So, it is quite cumbersome. And sometimes we'll see if companies don't want to implement at the time of go live from that perspective that they'll want us to develop a matrix for them to say, hey, these two responsibilities are not compatible with one another. But that still leaves you a blind spot on what if one of those responsibilities changes, and then it introduces a risk there. And so, there's so many use cases we've seen where more recently, a company, unlike Ian was talking about was part of the company was going to be going public at the end of the year. And they had hundreds of known SoD conflicts. They weren't necessarily they weren't SOX compliant, they didn't need to be based on their business so those conflicts were just kind of sitting there as known conflicts. Then they had a really short window where they wanted to identify the high conflicts, get those remediated, also implemented GRC tool to help them track at the time of go live. And so, all of that got really condensed into a few months window, versus if they would have had the visibility from earlier on it's likely that hundreds of conflicts wouldn't have been introduced into the environment. So, there are a lot of companies that have gotten into a situation where it feels almost unmanageable, and it's getting pushed on the backburner until there are some hard requirements and then there's a rush to try to fix it.

How long does it take to implement SafePaaS?

Navinder - I guess it does depend on the client environment, but I can give a generic idea. If you're implementing the SoD solution here is to let's say, for an Oracle release 12 environment or Fusion environment, a couple of examples, we implemented at an Oracle Fusion customer in six to eight weeks. That included requirements design, and implementation end to end. So, it really doesn't have to take very long, it's not like an ERP programme, you're only looking at second aspect in great detail. You are working with your key control leads, key financial committees. If client resources are available, and decisions can be made quickly, it can really be very quick. The other tools as well, they shouldn't I think most of them should take between six to 12 weeks. But there are certain cases where the requirements are quite complex. Of course, that can take longer. So, it does depend, but it's nothing like implementing any ERP system or any complex system. The costs aren't in any way comparable either. So, really, in terms of the previous question that Ian and Stephanie answered. I mean, it does help quite a lot in terms of providing visibility to auditors once implemented, and they're not really that difficult.

How does SafePaaS differ from tools such as Archer that's been around for a long time?

Navinder - Archer and other tools like that are excellent tools for managing the SOX programme. Millicom used a tool which was similar where you kind of have only all your hundreds of controls for the SOX programme by country, by division documented in a GRC system, and then you track based on who's responsible for what control evidencing, etc. So, it's very much a risk management solution. Archer’s a risk management solution, which provides visibility to management around how many controls when evidence and how the auditor is seeing etc. But while a tool like SafePaaS is very specialised, specifically around ERP controls, specifically around IT general controls. So, this is like, focusing on a very painful area in great detail and providing evidence for auditors to really hit the box and say everything's okay. While the other tools like Archer are very high level, across the organisation and more around managing controls and risks. There's quite a significant difference there.