A New Era in Segregation of Duties
In this week’s blog post, we’re sharing insights on our latest interview with Pat Wadland on Segregation of Duties (SoD). Pat is the Senior Director of Risk and Compliance Solutions at Fastpath, and has worked with numerous fortune 500 companies, US government agencies and other organizations in the field of implementing assessment and design and security to mitigate risk and improve business processes. He focuses on ensuring his clients achieve maximum value from their XP enterprise systems and acquire a deep understanding of their full capabilities, but also presents the trends on Oracle leading practices and solutions.
Understanding of Proper SoD
In a general sense, SoD is a set of internal preventive controls in order to alleviate potential risk of human error and fraud by requiring more than one person to complete a specific task, mainly in a financial, transaction-based sense. Consequently, monitoring potential SoD conflicts in businesses’ applications and cross application security is a critical component for companies’ risk and compliance programs. As digital transformation allows you to move your entire business operations to hybrid and cloud platforms, this has become even more essential in comparison to SoD we’d have been talking about in the last decade. In particular because nowadays each company’s essential business processes can flow through multiple applications based on the best solutions they provide, rather than using only one platform to control everything. For example, a company might be using Oracle Business Suite to run most of their major functions, but transition some functions into the Oracle cloud or fusion ERP and HCM applications with Salesforce for your CRM functions. It’s a very common use case for companies whether they are small or huge.
One of the biggest misconceptions when it comes to SoD comes from the fact that companies seem to think that they don’t need to start from the granular level. Generally, they’ll be separating the duties across the roles, and then they’ll be in good shape but in most cases that is not the case. The major reason behind this is what drives a SoD conflict. At the end of the day, it’s not the name of the role that’s going to provide the access. Depending on your ERP dynamics, you’re talking about the underlying menu item displays, menu, item actions, Oracle EBS, extra functions, privileges and so on. What should be driving SoD is going to be what you should be assigning to those configurations based on the underlying security objects, rather than the role title.
Risk Management and SoD
As SoD is an internal control, an organisation should be viewing it within the framework of risk management activities. This means that the organisation should thoroughly analyse the business processes and make good choices on potential conflicts, and put compensating controls in case there are remaining conflicts. This is why SoD requires the company and everyone involved in the SoD control process including the risk managers to have a clear understanding of the individuals, their roles and key business processes. If you haven’t already done so, as a risk manager, you should be prioritizing a simple risk assessment from a SoD standpoint as well by firstly identifying the key areas for your organisation and individuals involved. Afterwards go in depth with your business cycle areas to find out what might cause or prevent users from potential conflicts of interest. At the end of the day, the compliance risk associated with SoD violations can lead to big monetary losses or penalties, as well as audit findings.
A good example on this matter would be “Procure to pay”. Most companies consider vendor master data a high risk area. So that’s probably a pretty straightforward one, as well as setting up maybe the key configurations in your accounts payable system whether that’s SAP dynamics, Oracle and so on. If you go deeper into these, you’ll see most of the business processes are done with workflows and scoping assessments and going through these and identifying the key areas within those aspects. This way you can start with the highest risk areas and go through the rest. This will not only help you build your SoD controls, but also a solid foundation for your application and ID dependant or manual SOX controls as they are absolutely fundamental for any sound security environment. On that note, a risk manager should definitely talk about improving security and making it a top priority in their work load. This once again brings the “preventive” part of SoD controls. To avoid creating SoD violations or conflicts each time a new access privilege is implemented, you should also be implementing preventive controls to check for such conflicts. Keep in mind that, especially in small companies, it is crucial to implement and properly document certain exceptions as there might be occasions where users legitimately need to breach these rules to cover for their colleagues’ absence or where a team or an employee might be taking a broader range of responsibilities.
More than likely, your auditor will seek evidence of how your company manages SoD and what preventative measures have been taken to ensure SoD policies are not violated. To satisfy your auditor, you’ll need to provide evidence that you’ve properly tested the controls and they are thorough enough to catch suspicious activity. Proper implementation of and documentation of exceptions will also work as providing sound evidence that can show the auditor you’ve been paying good attention to your SoD. Nevertheless, be aware that this might be an extremely complex and time consuming process to implement within your processes. Using specialized tools such as Fastpath’s will help you with reducing risks, and provide the evidence you need in an efficient manner.
Predictions on the Evolution of SoD Monitoring
The next evolution going on and to pivot off the transaction monitoring. To give a little bit of context here, we need to go back to 10–15 years ago, when the companies would go for internal controls audit or the ICFR audit, rather than financial statement audit. Most of the time, your external auditor would come in and sample or take a subset of your transactions, rather than taking your entire population of transactions and focus on sample based modelling to ensure all is in order. In the recent years, some firms have gone to developing systems where they’re not just taking samples as they’re able to take the whole population transactions and journal entries and audit those. On that note, it’s possible to see that, from an audit standpoint alone, companies no longer need to go to audit with samples alone but for the whole population and that’s itself a big shift we can expect. From the change management side, that means, the audit will be able to ask about all the changes that were made, for example in SAP dynamics environment, within the past fiscal year and companies will be required to show the relevant documentation.
This means that we’re already at an advanced stage of cross application access and segregation of duty monitoring. According to Pat, the next step on the evolution is going to be the cross application transaction monitoring. As we’re already able to monitor the entire transaction environment within separate applications, and getting close to developing full-stack solutions that allow us to track connections between various applications, create topology maps or reports in a secure and controlled manner.
Takeaway Points
First takeaway, would be to make sure to swap to efficient tools to maintain your processes and documentations rather than doing the whole thing manually. Automation is very important regardless of the process so look into tools to help you automate these processes wherever possible. External audits will also be going for an automation process, and developing new tools, and on that note it will be beneficial for your company to be in alignment with them. At the end of the day, they’ll be most likely asking what kind of methods you are using to collect your data and assess whether it is a sound process. Especially considering you’re using various programs and different processes, it will allow you to save time and easily show things such as who has access to the payroll side, or employee master data and so on. Any tools to help automate and assist your external and internal auditors with gaining that insight into who can do that information are very helpful.
Secondly, do not put your processes in their own bubbles. you’re not looking at just your one major ERP, but you’re taking the whole approach of your ecosystem of what ERP is, are systems or available and making sure you’re really thinking through. SoD conflicts won’t be limited to just one system and might affect every other system as well.
Closing Words
For now, this sums up the key points of our interview. As the Global Risk Community team, we once again thank Pat Wadland for his insight on Segregation of Duties and cross-application monitoring. More information about this topic is available in our original interview, which is accessible here.
#risk #SoD #segregation #audit #cross-application #monitoring #management
