Transcript

What have learned learnt from US SOX, and what's the likely impact of UK SOX on internal controls reporting requirements?

Nigel - Many people were finding themselves responsible under this new legislation (Sarbanes Oxley) for the signing off of internal controls. I think the reaction of many CEOs and CFOs back in the day was, "what is an internal control?" There really wasn't a controls consciousness that was very broad at that point in time. When it all sort of got started, I would say that I was honoured that a lot of companies looked to their technology provider and asked, "what do we do?" "How should we react to this?" I was fortunate enough to be an accountant by first profession, I'm an internal auditor and have a few other auditing qualifications as well. So, I felt that I had at least some knowledge of what was going to happen in this space after having read through the legislation. It looked as if it was going to impact the financial reporting pieces. We really thought that was where it was going to start. But it's kind of interesting that the centre of gravity of what was happening with internal controls reporting over that period, sort of shifted that around for a while, and kind of started off in the financial reporting spaces. Pretty quickly, it spread to the document management area. People were very focused on documenting their controls, and to develop sort of procedures manuals. That seemed to be where everyone sort of rushed to. A lot of dominant companies at that phase tended to come from more of a document management background. Then it kind of shifted more sort of formally from a document, to maybe more formally seeing what was happening in a workflow. So, to be able to certify that things were being done within a workflow. And some of the workflow tools started to become dominant in a second wave in those early days. Then it shifted from the human aspects of procedures manuals, and maybe workflow management, to get kind of focused in on the IT controls. And so that became sort of dominant, I think, for a long time clearly, because once you can take advantage of the controls that are already, baked into the ERP system, they tend to be much more predictable, and much more reliable, harder to circumvent to some large degree and certainly easily certified. But it's very broad. I mean, that space is actually very, very broad. So, I think where it kind of finally came to rest was people taking more of a risk-based approach, but they had to actually find out where their risks were and sort of drill down from a risk- based approach into the internal controls area. So that's the sort of journey that I saw. I was very fortunate that I had been thinking that something was likely to happen in that space in terms of automating the audit process. And so, we did get a little bit of a head start at Oracle in sort of bringing out some of the some of the first tools in that space. And my enduring thanks to the SafePaaS gang in making sure that all my early customers there were well looked after.

Adil - That's an excellent point, I'll just add a couple of more observations to what you said that might be helpful to folks that are listening to us in the U.K. So absolutely, you know, it was seen as a documentation problem, and frankly, put a lot of burden on management and companies to go out and spend, you know, I just say a ton of money you know, audit firms or internal audit firms. You know, one of the by-products of the Enron blow up that resulted in Sarbanes Oxley in the US was, and a few others, was also that, you know, Anderson Consulting, and Arthur Andersen, which was one of the top audit firms exploded that evolved into this new organisation called Protiviti. A number of other organisations that basically specialised and building businesses around SOX. Some people called them SOX-in-a-box, where you could go to these organisations, and they'll come in, and basically, they will pull out their Word and Excel documents and, you know, take what was known at the time as a bottom approach. They would go around talking to, various process owners and control owners and documenting the design of the control and then testing against that design and getting certification. It was a huge amount of effort put in and the burden was on businesses recognised by the governing bodies in the US, which is led by the SEC under the Congress guidelines for Sarbanes Oxley. And so, they actually came out with a clarification of that standard and as you said, correctly, take a more of a risk-based approach as opposed to what at the time was more of, initially a bottom up approach. So, as you move forward in the U.K I think the lessons that your audit firms have learned from the US market will be applicable. And hopefully, I know that there's not a prescribed framework like we had in the US with the COSO framework being the standard for audit standard two, and then audit standard five and onwards. But audit standard two was really not clear enough. So even the governing bodies to the PCAOB, were not clear on how to do that, and that created a lot of chaos for us here. And obviously cost and not much, I would say some value but not enough value. Where we saw the value is when five comes out in 2006, 2005. I don't know the exact time but we saw a big shift in the US. People started to rationalise those controls to key controls, and started looking at their financial statement risks that are tied to the to the actual impact of those risks on the balance sheet and income statement. And while we did have a clarity on how to do that analysis, but the analysis itself was important to take a look at the risk that's impacting your liabilities and assets, etc. And then look at that risk. And so, I think that the rationalisation period is where we see a shift to what is now known as governance risk and compliance because, you know, we needed automation, we needed software, away from the Word documents and Visio charts and those risk control matrices that were developed manually, you know, so going from that manual certification of your controls effectiveness, what we call SOX 302, on a quarterly basis, an annual assessment of sorts known as SOX 404. That shift we see happening, as the lessons were learned in the US market, not only by the auditors and the auditees, but also the governing bodies in the US. And I think that's where you start seeing some value come up, where you know, you're starting to have control owners and process owners and really understand what they need to do. And we'll talk a little bit about how we get to the automated stage from there. But yeah, so those are a couple of things that I just wanted to highlight that will help hopefully, folks that are starting this journey in the U.K.

Matt - Yeah, I think so. I spent my formative years at Big Four accounting firms. So, having sat as both an implementer of SOX programmes, but also as an auditor of organisations that are subject to US SOX, I think there are a couple of things that I noticed. One was around the evidence required to demonstrate that controls are operating effectively. So, I mean, there's always been a requirement that larger organisations will take a controls-based approach for their external audit. This is supplemental, so this is about not just relying on the external auditors to do their work at year end, plus any internal audit work that may or may not happen around financial systems and their processes. This is a requirement of management to perform at least quarterly testing, to demonstrate that controls are still effective, and then they are actually both designed effectively and operating effectively. That kind of sat in two different buckets, one on management, also one on the external auditors, to make sure that it has happened and that the testing was appropriate. Now, that kind of latter bucket at the moment is a little bit unclear whether or not in the U.K, that will definitely be required from external auditors. It's quite impactful in terms of effort and value costs to audit fees at a point. But that's to be confirmed. That's one of the discussion topics.

How are these internal controls reporting requirements likely to impact on your ERP? 

Adil - So I think that's a good segway from the previous discussion of this journey we're talking about and how it might help folks listening in the U.K. So, as we get to this, you know, back to the point that Matt you just made about the certification, which may or may not be the same in the U.K, the key thing is the design and the effectiveness of the controls that are operating and tying that back to what Nigel was saying about workflow. So initially, what we thought we could do is workflow our processes or processes that were not workflow, workflow those two, and we'll talk about a case study in a little bit later that Nigel and I jointly worked on with some customers. So, one of the things we did was we said, "okay, now that we have these processes documented, so procure to pay process, you know, how do you create a supplier? How do you pay a supplier and everything in between?" So those activities, we built out these key controls around it, and in around those key controls, then we said, "okay, now how do we test these controls?" Well, we realised very quickly, that these controls are actually happening in our ERP system for most of the, you know, the organisations that we worked with at the time, which is typically a company with, you know, 500 million to up from there, that were listed on a US stock exchange. And there were a few smaller ones, too, you know, we had the opportunity to work with some of the great start-ups like Facebook, and so forth. So, we are seeing this, that the need for automating the controls was important for management to really continuously monitor these controls. So even though the requirement is a quarterly certification in the US, you know, you don't want to wait till the end of the quarter and then fail to control the key control. And if you don't have a good backup control, then you know, you've got essentially a finding, and that finding had categories or has categories, everything from a significant deficiency to a material weakness, and if you report a material weakness, it impacts your market cap, essentially, because the reliance on your financial statement goes down. So, it's a big risk, not just to the process itself, but also to the company overall, to stakeholders, for misstating, financial statements, significant risk, right, and there's liabilities on the executives, and so forth, which we won't have time to get in that detail. But I think what I'm trying to say is that the key thing on this slide I wanted to pick up from the last slide is that now that we have documented our controls in the US, we're learning to monitor them, and the best place to monitor them is where you're executing the process, which is in your enterprise resource planning system. I had the opportunity to work at Oracle as well. And so one of the things we did with Oracle customers was kind of examine how Oracle processes were set up. And it's true for SAP and others too. So, it's not limited just to, Oracle's just an example. So, let's say using an Oracle ERP system like E-Business Suite, right, which is a popular system here in the US that many of our SOX customers use, you have a way to, you know, create a workflow on suppliers, has supplier bank account changed, or if the tax IDs missing, you know, prevent that from being secured and saved inside the system because it leads downstream to a control failure. So, we would look at the control matrix that was documented in the early days and then you could match that control to the process that's executed in your ERP system. And that was kind of a breakthrough moment for us, in the US because now the customer and most importantly, the control owners, people that operate the control, such as the head of procurement could go in and say, okay, you know, do I have a, you know, some liability transaction in my sub ledger? let's say purchase orders that are sitting  in the sub ledger, and they're not reported all the way up to the financial statement through the sub ledger accounting process, and the posting process. So, you know, reconciliation becomes really important now. And so now you're starting to see these capabilities of Account Reconciliation, automated task management under the financial close process. And all that is integrated into your ERP systems. The ERP system became the centre of gravity to use Nigel's term as the gravity shifted from just documenting the controls to measuring the operating effectiveness of those controls. And auditors got very interested in a lot of things. One of the things that really bubbled up that we realised was segregation of duties. You know, in the early days of ERP systems, we were trying to the mantra was, hey, how can we make the whole organisation work together in an integrated fashion, and that was the big value prop from ERP, but now it's like, okay, it's integrated but that doesn't mean that somebody can put up you know, an entry in the sub ledger and your liability and reverse that if they have access to General Ledger as well. So, you got to segregate those items. So, I think, segregation of duties, transaction controls, configuration management, all those things became important and I'd like a little bit later in the presentation format to drill into these items. But these are some of the things that we started to see naturally develop. The auditor has started using some tools that were coming to the market. Acquisitions happened. Many GRC players came to the market. The market got really hot in about 2008/9 when Gartner and Forrester and all the major IT research firms jumped on this bandwagon and started defining the terms of what GRC really means and we saw a lot of activity. For example, in the software category, because there was a big demand from the auditors and management to automate these controls and monitor these controls, that are actually being operated within the ERP system and some things outside the ERP system too like reconciliation tools, and so forth, to just put more visibility into your close process. So that's kind of where the ERP was a big part of this, the solution ultimately, and I think, again, with the theme today, you know, if you are thinking about documenting your controls and the design of those controls, and then check testing that the best place, in many cases, not all cases, many cases is that ERP system where the transactions are being processed, within your process. So, I'll pause there and see if you guys want to add anything to that Nigel and Matt, or we can just move on.

Matt - Well, this a sundial picture that I put together. So, I tried to write for Sarbanes Oxley, some of the key areas of focus for ERP. So, there's a whole load, I mean, Sarbanes Oxley requires you to do a lot of other stuff that has nothing to do with the ERP in terms of entity controls, in terms of cyber security, etc. Yes, if I'm running, say Oracle, ERP, cloud, or any other Workday, your financials, etc., then I probably do need to worry about cyber risk, but it's still not going to be my number one risk. So, because at this point in time, UK SOX, they have not specified a framework  in their kind of proposal papers, and hence, there's, I think, there's probably going be an assumption that it will default, similar to the US one, which is around COSO, which in turn doesn't really have an IT bit to it. So that will then default to COBIT. Now, that entirely makes sense, because all the big accounting firms all rely on COBIT for their IT audit approaches for external audits, etc. So, really, this is saying, Okay, well, these are some of the areas you might want to think about. If you are thinking around, what could we be doing now? So, there's a bit around User Access Management. So, who's got access to the system? So, who has got what access? And how do they get it? There's a bit around IT operations. Now, that's probably slightly less relevant for some ERPs but that will include things like monitoring of batch jobs There's a bit around change management, that will absolutely be relevant. And that may cover IT controls, it may cover automated business process controls, so if I'm changing things like approval hierarchies, well, that’s really a business process control, but actually should be covered as part of the IT general controls change management process, it should go through a formal change management process. The bit around programme development now really, for ERPs, this is the least in scope area of the key areas of COBIT because you can try all you like but Oracle, is not going to go and develop a programme just because you wanted to have a particular feature. So yes, whilst ERP Cloud, HCM Cloud, you can try and influence that and in fact, one of my own personal ideas is about to go live in the next release of HCM Cloud, which I'm pretty proud of but there's no guarantees, and you're not the one that's doing the development. So,  however, when you've moved out of IT General controls, you then move into IT application controls and manual business process controls. So, some of the key areas that you have to think about there are configurable controls and that is your matching options, your matching tolerances in payables. It could be whether or not your journals are allowed to automatically post It could be whether or not you're either a force and a journal approval. That to me is kind of one of the key areas of focus now, because that's moving a lot of manual activities away from having to put a monitoring activity, which is that kind of bottom right box of the manual Business Process Control monitoring, up to relying on stuff that you're already paying for within the system. And then you've got probably one of the most complex on the whole set of it is segregation of duties and sensitive access. So instead of both finding the policy to check that okay, well, what am I going to allow is entered journals plus post shows accept acceptable historically, no. Most people running E-Business Suite are not going to allow that. However, if I’m running ERP cloud, actually, my policy probably changes now, because I can force all journals that are manual to go through an approval process, I can't avoid it and therefore, that's probably an acceptable separation of duties violation that I can just document.

Nigel - So one thing that that sort of just leapt at me here was that these are really good for like making sure that you've got controls in place, but from a preventive control perspective, but of course, there's the whole issue of when a controller may have failed to have something that is more of a detective control and the area of sort of transaction monitoring, it would be another just another area that that would be useful in this area, as well, just to confirm has a risk emerged.

Matt – Agree. Each of these will have both preventative and protective parts to them. How do I know that I've given the access expected to the right people? How am I going to pick it up if somebody has received unexpected access? And I think that's one of the differences in SOX testing, for example, where, because you're going to know often pick your own samples on a periodic basis to demonstrate it was in line with a policy that I've documented, and is in line with business requirements, and was approved by the right person, then you're more likely to pick up those exceptions. But if you do pick up those exceptions, you can't just extend your sample. I mean, that becomes a control violation at that point that you then need to remediate.

What activities could you be performing now to confirm whether your ERP, and its supporting processes are ready for UK SOX? 

Adil - I can certainly start and I'd love to hear from, I was curious what Matt mentioned, he had a ERP client that just going live so hopefully, you can shed some light. We're working with, obviously, some U.K customers right now so what we're seeing what our customers are doing, especially in Cloud ERP, today, fast forwarding that to U.K for a second is that, you know, they're spending a lot of time designing good controls with us, and our partners. For example, if you're thinking about rolling out a cloud platform, because, you know, with the COVID pandemic, all this stuff, people are starting to move to this work anywhere model. And there's also other benefits, cost savings and so forth. One of the things that we're seeing our customers do today is that they're spending more time in designing the control correctly before they roll out an ERP system. And what we're specifically seeing is that the roles design, right, so let's say you're going to have folks in your finance department with a dozen roles or something so they can inquire through the sub ledgers on your AR and AP side, they can check inventory levels, they can and then of course, you know, their main job is to put in journal entries, some will possibly approve those journal entries, and there may be some exceptions to that. So that's where we're seeing customers bring in SafePaaS, and our partners to really use the tools and capabilities based on the lessons learned and best practices we have deployed, embedded into our platform. Lessons learned in the US over the last whatever, a couple of decades, I guess now is to embed those controls into their framework when they configure any ERP system. Similarly, we're working with customers that want to monitor you know, what we call continuous monitoring, or continuous auditing. So being able to configure when you configure any ERP control and standard control, let's say a three-way match or a tolerance level the flexibility in access enables you to change it, right. So, it's you know, 6pm on a Friday night and I've got to close the books and one of the transactions is not posting and I can force it, you know, change a configuration or force that through it seems like maybe a naive thing to do but I've seen customers and their auditors spend weeks looking at those transactions and costing the company a lot of money in at least one company I've seen where it turned into a material weakness and impacted the financial statements. So, I think these configurations that seem, maybe not as toxic in the beginning, come back and bite you. Same thing with transactions that slipped through your controls, you know so we have, as we implement new products, new implementations our customers are doing, they buy a new product from an ERP system that are like rolling out a new system to get beef up their controls and get stronger controls, what they find is that certain settings that were set up in their assurance system, like user acceptance testing are not really moved correctly to the prod. So being able to compare that change management process. And so those are some of the things that our customers are doing today. And we recommend that there's some good lessons learned for us just in the last 12 months that other folks in the U.K can share, through our best practices and through our partners that are helping implement SafePaaS for our customers. So, I would love to hear from you Matt about the story without obviously giving out confidential details as you won’t but just give us a little bit of background on you know, what are you seeing that it's really important to us?

Matt – I think there's a couple of different things. One is around understanding where we are now. And one is around understanding what do we want there to be? So, for example, defining policies and reviewing existing policies and making sure that they are defined appropriately. And then it could be as simple as, what is our matching tolerance? Because you're going to be expected to at least think about that and document that. And this is stuff that we can be doing now, we don't need to wait a couple of years for any formal decisions. I can think of one client where they have six different Ledger's, and six different settings for payable tolerances. Now, the root cause of that is that they kind of combined lots of different bits into a single ERP. but they haven't actually made any decisions around well, what is good practice to them. What is in line with their own aspirations and goals? But it's also about understanding, then Okay, what if we understand the policies to do an assessment of the configuration? And that could be if the system is already live, and that is somewhat easier because you're just looking at, okay, this is what the system says, this is our policy. As long as our policy is designed effectively, and the controls are designed effectively over in our policy, then we can then quite easily go over whenever they have exactly the same, or different could explain, can we document any gaps between those two? And if the answer is no, then it's all work that can be done now. And that could be that around access controls. So, for example, I have defined my separation of duties policy now, I don't need to wait for anything to be defined at a later point in time in terms of compliance and regulation. Because there will be something around separation of duties. It's definitely already there and expected as part of good practice, external audits anyway, it's just going to be required in a more formal way in the future. Yeah, and then I guess, one of the other bits is if you have a better understanding of what your key controls are, that you're really relying on, can then get a better idea of where are there opportunities to automate. And that could be by using the ERP itself better or it could be because actually, we've got a gap. So, I'll come on to in a minute. But around things like access controls, I mean, that it's perfectly possible to manually do a recertification of all users and their privileges on both E-Business Suite and on ERP cloud. It is painful, because if you've got X 1000 users with however many assignments against those, then to manually run the exercise is a big challenge. But it's probably going to be a control as expected, because as part of COBIT allows me to demonstrate that the access is still in line with business requirements. But if you don't look at some kind of tool, then you might as well commit somebody as a full-time job to be doing it.

Nigel - I think to reiterate on that the other IT controls level that, you know, we have, you know, we always have COBIT as the North Star there that the likely set of control objectives for IT controls, but as you as you sort of move into the outside of the IT controls and you've moved into general controls, just to be thinking about what in the within the COSO model, we're really aiming at, What is the business aiming to do in general? Like, what is the business strategy that with these controls are actually lining up for? So actually, trying to work out what that mapping is, to sort of read to reiterate what Matt was saying, like, really, what is the business strategy? And how do the controls help you meet them or ensure that you don't fall short of them? I think that that is work that can be done now, useful work to be done irrespective of really, of UK SOX, but likely to be required under the frameworks that are there.

Matt - I'm not going to talk through every single one of these because I've talked through the bit, the four areas that I pulled up around IT general controls, previously. But I think the reason why I've included is I like to think about what can I do by default within the application? What can I do if I rely on additional tools to help me typically from a third party, but Oracle themselves have some tools that could help versus what's not covered by any of that? And therefore, I'm going to need to still build some manual monitoring activity. And I guess, around User Access Management if I look at ERP Cloud, for example, the ability to report out who has access to a single function, that is stuff that did not exist in E-Business Suite. Oracle, have clearly taken the feedback and reflected it. Is it really good enough for me to be able to say that I can do segregation of duties enforcement? Or not really no. Because for me to be able to demonstrate that, for example, I know exactly who's got access to say, amend a supplier master file detail, create a new supplier, amend an existing one, change a bank account, whatever, I would need to know each of the individual entitlements within your ERP Cloud that relates to that, and then look at each one of those individually. So that will end up being quite painful. Whereas if you supplement it with tools, then you can do this. And there are a number of tools out there that will allow you to do this. Whereas something like monitoring security configuration, you can, in E-business Suite are actually quite easy to do, you'd have to go build your own custom monitoring control. And then can you build your custom auditing and then go switch on and then go build your own monitoring control It's still a lot easier if there's some tools that actually put it all in a centralised place. And I think that that will be end up being the kind of change that people will see where Part One might be What can we do within ERP relatively easily? versus Okay, well, we've done that now, how do we then optimise that in a bit of a better way, so that we're not spending many year’s worth of effort just to monitor a change that probably hasn't changed in the first place, and then document any changes that have changed. I'll probably skip through the next ones. So, given this section was around, some other things you might want to think about. I mean, there will be ERP embedded tools such as audit trails, with E-Business Suite or manage audit policies in ERP Cloud. I mean, they require some people that know what they're doing. Partly because the ERP vendors, documentation around it is not entirely complete. And they're not always designed with controls in mind. So, there's often poor reporting, or one of the key bits around SOX is that you need to demonstrate evidence that a control has not been amended. It's been operating effectively over a period of time. Well in the ERP cloud, for example, I can't prove the auditing that's enabled within the application having changed. That's one of its gaps at this point in time. Whereas there are if you're going to think about third party tools and service, there are some questions that I'd suggest that people ask the potential vendors, so does it support their particular specific requirements? So, the example I've given there is FBDI a one-time payment for those that come from ERP cloud or are implementing it, this allows me to do a one-time payment process. It requires me to have about four different privileges, to be able to do it. You need to make sure that your ERP vendor can support that and use your third-party tool and service vendor can support that. Equally, the tools themselves will become part of scope for SOX. If you're relying on the tool to be operating a key control for you be it segregation of duties monitoring, be it monitoring changes to key configuration, then you need to make sure that it itself has a SOC1 part II report, independent third party assurance. Equally the content, with the third-party tools and services need to make sure there is completeness of the content of the ERP that you’re talking about. The chances are there’s probably going to be a need by the organization to redefine content. And then the processes themselves. The tools themselves need their own processes around change control. For example, a shared client with SafePaaS. We needed to make sure was we put in a set of processes around, how do we make sure that we update content on an on-going basis in terms of the rules themselves? How do we make sure that the tool itself gets updated on an on-going basis? It has its own change control back to ITGC themselves again. And the last section is around the project. Quite a lot of GRC vendors are relatively new or are starting to see systems for the first time. There are not that many ERP Cloud instances in the UK that have existed for such a long time that they’re thinking about putting tools and third-party services over the top of it. Therefore, the content isn’t necessarily complete but you also need to make sure that there’s enough testing time to be able to include it. And go-lives get impacted because you need to best it on the reporting timetable, the controls timetable. If you’re already supposed to be already operating under a SOX environment, then you want to avoid quarterly updates, sorry want to avoid the updates on the quarterly reporting timetable. If you use Oracle ERP Cloud, the Oracle SaaS product you’ll get quarterly updates from Oracle itself with ERP Cloud so you need to consider that at the same time.

Nigel – I think one of the risks as everything moves to cloud we have to understand is there is a lot of integration risk that is inherent in moving things to cloud services. That is a risk just being able to provision those reports and ensure all the systems that need to work together but when you have things in a none cloud environment you have access to more to make sure things were actually well-integrated whereas now you’re limited to the integration points that are available from those cloud service providers. That’s one key thing.

Matt – One thing for me that as ERPs move to cloud, it’s not a static product. So, with EBS organizations did an upgrade once in a never. They’d keep the same version for 5,6,7 years whereas with Oracle ERP Cloud you’re getting an update every quarter. You’ve not stopped that, you get new functionality as part of that and unfortunately for me, I think of functionality as being new potential risks. For example, a new way to amend chartered accounts information appeared in the latest release. That means that I have to make sure that A my internal processes but also any content that I may have needs to reflect that change.

Nigel – I really think that the whole notion of what’s underneath the ERP umbrella changes over time. So that notion of what is this thing we call ERP. Sometimes it includes the manufacturing systems, sometimes it includes the HR systems. It seems it’s an ever-evolving beast and some bits move out and some bits move in. We are certainly in a situation where risks may be emerging in systems that are not currently under the ERP umbrella. It’s definitely going to impact the ERP system, and maybe emerging in systems that are on the ERP periphery or maybe even not in ERP what we call today.

Can you share some case studies of how US organizations used GRC technology to comply with Sarbanes Oxley in the early days?

Adil – I can think of a couple. I’m based in Dallas for those of you that know me. I started working on some local accounts and Nigel and I worked together, Nigel from a product perspective and us from services perspective. Nigel, an account in Fort Worth comes to mind where, at the time we were in the documentation phase of getting all the controls documented and then we used some of the workflow capabilities available in Oracle to help them implement those controls. We talked about that at the beginning of the session, about migration from documentation to testing the operating effectiveness of those controls. That’s going way back in history to 2004/5 but Nigel one of the things I’d love to hear from your perspective, as a technologist, what are some of the things from your perspective that are some of the things that customers in the U.K can do to streamline that controls monitoring? You spent a lot of time talking about the financial close process and that’s probably the heart of this whole exercise. Maybe you can share your perspective here Nigel.

Nigel – I think the account you’re alluding to is Texas Industries. And certainly, in our read of what the legislation was requiring it to do was to require that controls had been signed off, very much an auditing view of taking responsibility for those controls and to confirm they are designed well and working effectively. It was interesting to have clients turn round to us and say, “we’re kind of interested if they’re signed off but more so if they’re done,” which was where those controls were actually human activities, but yes, there’s some element you’ve got to say they are effective but more centrally you needed to say that the activities had been completed. I think with workflow tools that allowed us to at least confirm that someone had said that something had been completed such that subsequent activities would then become eligible, certainly in the close process you have to be careful about timing to make sure that things are happening in the correct sequence. That was one of the important controls that we had. Even though the activity was a manual one that the eligibility for it was actually something you needed manual input for. I think at the end of the day that was a 2005 view and I think moving more of the activities into automated activities just allow us the controls to work more effectively, they are more reliable, harder to circumvent, easier to certify. More of them are actually automated controls. That’s where I would push people these days to look at the inventory of configuration capabilities you have within the systems you are using to ensure where you can automate and take the human decision out, but implement a policy, you know, that actual behaviour within the system is just a much more reliable way to enforce that control.

Adil - Yeah, just to kind of fast forward from there to now just to give you an idea where we are today. So that was sort of where we started with these workflow capabilities. And our more recent customers are doing, Nigel, as you stated, automating that. So for example, in the recent months and years, we're seeing customers adopt the financial close process where it's integrated into the ERP system, so as you're closing Sub Ledgers as part of your checklist, so typically, a customer comes to us, they have some sort of what we call here, a three ring binder, they have a checklist, you know, I'm going to close my AP, close my AR, and so on and so forth. And I will do this from this interface. And I will, you know, if I found the name of the global company, most of us are then so let's say Singapore is where your clothes process starts, it moves to London, and then to New York with the time zone differences. And you have some special entries to make. Let's say you're a bank, investment bank, and you have year-end bonuses to release. And those are topside entries before it goes for finals review. So, the monitoring of this process, the close process becomes really important for the executives to ensure that as you know, as we have more aggressive timelines, to disclose results faster, and close books accurately and timely. You know, we have the added pressure of monitoring that checklist. And so having that spreadsheet folded around multiple regions and business units, errors happen in spreadsheets, and that's where customers get in trouble. So, what we're seeing from our customers today is that work for the close workflow itself has to be automated. Some of those pieces are happening in your ERP systems. But a big chunk of that is still manual, you know, your work paper, your reconciliation. So customers that feel that pressure of accurately timely, you know, reporting accurate results to the market can leverage some of the technologies available in the market today, like we have, where they can dip into your  deep integration dip into your ERP system sense out you know, what's what tasks are completed any ERP, blend them with the manual tasks that are happening or automate those and tools like SafePaaS, and then speed up that close process to make sure the executives have enough time to review the accuracy and, you know, sanity check the numbers and the variants on balance sheet statements etc.…, and provide the necessary guidance with the financial report filing requirements that are here in the US. So, I think it's just come a long way since 2005, to 21. And, some of the advantages U.K customers have today is they can leverage these best practices that are built into the technology available today to reap the benefits from the lessons learned here.

Questions:

Could you not enforce third party vendors to adopt your policies and standards and hence controls by embedding them into the contract?

Matt - I guess I'll start doing I think that you would struggle to for somebody like Oracle to change their controls for their cloud computing centre. Unfortunately, it's a service that they provide. So, I think it's about understanding what are your key controls and where can you get a level of assurance through things like the SOC1, part II reports. If it's a smaller vendor, then maybe you have a bit more influence.

Nigel - Yeah, probably not long for this world. If you forced a cloud vendor to conform to exactly your requirement, they're probably not going to be in business long. Because if they if they do that for five clients, they're now out of business.

With regard to segregation of duties, is there a specific area or use case for UK SOX where probabilistic analysis or machine learning could be used to add value?

Nigel - I mean, with regard to segregation of duties, you've got to find out where you've actually got risks materialising so there might be a risk that someone would actually put through a transaction that is a nefarious transaction, that turns out to be fraudulent. If you're going to have a learning system, it's got to know when it has to know when risks have actually materialised, such that it can it can learn from it. In terms of a segregation of duties area, if you're looking at areas that are you know, can do unsupervised learning. If you've got someone that's got, like 1000s of privileges, then the average number of privileges that you've got is like 10 per user, then you can find outliers very easily without it being a supervised learning problem.

Is there a major difference in how key configurable controls in P2P and GL are implemented in Oracle Fusion versus Oracle R12? Any examples would be good to know.

Matt - There are a large number of controls, ERP cloud, basically when Oracle was creating it, they tried to take the best bits of E-Business Suite, from JD Edwards, etc. and the finance bit is pretty much a lift and shift from EBS. So, a lot of controls that you would expect in EBS exist in ERP cloud as well. However, there are some that are brand new, and there are some that have disappeared. So, for example, controls that allow me to have unbalanced journals they've kind of gone away to a certain extent now. I don't need to worry about that in ERP Cloud. However, there are other ones around approvals that are completely different.

How can we assess the risk in our ERP system to ensure we are proactive for UK SOX?

Adil - Yeah, that's the question that we get a lot at SafePaaS as part of our risk assessment service. We work with partners in the U.K, such as Matt and Nigel that can help you kind of put a big picture together and then from a quantitative analysis perspective, you know, there's capabilities in our tools, other tools that can dig into the ERP systems and extract a snapshot of, let's say, your configuration, the security model, apply the rules that we or our partners provide, and spit out a report. So that gives you sort of the starting point of how much work may be involved. So, as you're setting up your SOX, controls projects, one of the things you want to know is size up the project and get it budgeted and have the right amount of resources to be successful. So, starting with an assessment a risk assessment is a good idea. The audit firms can do that for you as well. So, there's many different ways to get that. But generally, it's a great question to start to think about how to scope this project to get compliant with the UK SOX.

Matt - Yeah, I think that an assessment will end up creating a business case for you. So, get certainly, that there's quite a lot more work that we do consistent with services around ERP Cloud, HCM Cloud, EBS, where it's really about understanding what is potentially good, and how do you get there. But how much effort that's likely to be and what benefits you're going to get from it.

To help you understand the context of the white paper, you can view our "UK SOX, what to do now. How to ensure success!" discussion.