Navigating SOX Compliance withing Dynamics F&O: Insights from Industry Experts

In today’s dynamic business environment, achieving and maintaining SOX (Sarbanes-Oxley Act) compliance has become more critical than ever. Companies are continuously navigating complex regulatory requirements and seeking solutions that not only meet compliance standards but also support operational efficiency. One of the most pressing challenges in this realm is ensuring that ERP systems, such as Microsoft Dynamics Finance and Operations, align with SOX compliance requirements. 

In this article, we delve into a thought-provoking discussion between Bartosz Szpiech, VP of Product Development at Executive Automats by XPLUS, a SOX compliance expert, and Monray Williams, IT Governance & Risk Management Consultant, an auditor for SOX compliance. Monray Williams has been working in the industry for 30 years, with the last 17 years focused mostly on the IT sector and compliance. 

Their conversation highlights the nuances of achieving SOX compliance within ERP systems, specifically focusing on the Dynamics Finance and Operations platform. They explore the common pitfalls and strategic recommendations for companies preparing for an ERP implementation, offering valuable insights into ensuring that controls are effectively integrated from the outset. 

Bartosz Szpiech:

Let’s start with the basics. For someone new to this, could you explain what SOX compliance is? We’ve discussed it in different projects, and it’s clear that it’s not just about the ERP system—it involves much more across an organization.  

Monray Williams:

Absolutely. It’s important to understand where SOX came from. The Sarbanes-Oxley Act (SOX), as it’s called in the USA, was introduced after cases of global corporate corruption, especially following scandals like Enron and Lehman Brothers. These incidents revealed major failures in internal controls, and the U.S. Securities and Exchange Commission (SEC) decided to set up a set of regulations for the companies listed on the New York Stock Exchange to ensure that good governance and internal controls are in place for organizations. 

Bartosz Szpiech: There’s a lot to consider, and although SOX compliance is well-known in the U.S. with SEC regulations, it also applies to other stock markets like the London Stock Exchange (LSE) and the Johannesburg Stock Exchange. 
 
Each country has its own set of regulations. While these standards are formalized and widely recognized in the United States, they are not exclusive to the U.S. Other stock markets around the world also have their own specific requirements and guidelines. 

Monray Williams: Exactly. Many other markets followed the U.S. lead. We’ve seen J-SOX in Japan, a European version, and even a French version. In South Africa, the Johannesburg Stock Exchange (JSE) introduced similar measures. While they may not be as strict as the U.S., they still require companies to ensure financial reporting controls are in place. 

Bartosz Szpiech: Besides, it highlights the growing trend in the market where businesses must adapt. ERP systems need to be ready to enable users to implement automated controls and mitigation measures. These systems need to incorporate a wide range of functionalities to ensure the efficiency and security required by stock market regulations.  

When we worked together on one of the largest D365 F&O implementation in the Southern Hemisphere, we identified several necessary system functionalities, where the Segregation of Duties (SoD) was just the “tip of the iceberg”.  

Can you name some other critical controls needed in an ERP system to ensure SOX compliance? 

Monray Williams: Certainly. There are a few basics.  

First, access control and appropriate limitations — ensuring people only have the appropriate “rights” to the system.  

Second, change control — ensuring only authorized and tested changes are made to the system.  

On the access control side, segregation of duty plays a crucial role in supporting processes by ensuring that individuals cannot perform conflicting transactions or have overlapping responsibilities within the business.  

On the change control side, key elements include managing privileged access, which may be necessary to make certain system changes, as well as establishing controls around emergency changes. These processes vary between different ERP systems. 

Historically, SAP has been a leader in this area, along with the GRC (Governance, Risk, and Compliance) platform, providing robust support for SOX compliance. However, there is growing pressure on other ERP systems to implement similar controls.  

We've also seen an industry emerge to fill the gaps in ERP systems that lack built-in functionality to enforce, measure, and monitor control compliance. As a result, various companies have developed solutions that assist with data tracking, segregation of duties, and monitoring access to critical transactions. These products supplement many large ERP systems that might not offer the full range of functionalities needed to enforce all control measures required for SOX compliance. 

Bartosz Szpiech: In your experience, when implementing a system, how long does it typically take to become SOX compliant? Is compliance something that happens during the implementation, or does it come later? 

Monray Williams: That’s an excellent question!  
 
Companies often have a general assumption about when they need to be compliant. 

Typically, during implementation, customers believe they can go live, then go through what we call the 'intensive care period,' and only afterward focus on compliance. But it's the opposite. The moment you go live, you are required to be compliant. What we commonly see in implementations is that companies go live without immediately implementing the necessary controls. Then, halfway through the year, auditors come in and raise concerns. Auditors review the entire year, and if the controls weren’t functioning for the full duration, they’ll say, 'We can’t rely on your system because the controls were only activated halfway through, or worse, weren’t enforced at all. Therefore, we can't rely on your application.' 

Bartosz Szpiech: That’s a real risk. I’ve seen how implementing security controls can change business processes. Sometimes, companies need to adjust their workflows to remain transparent from a financial perspective. Besides, it was very interesting for me to see how important it is to make the right decision before the implementation. But what are the penalties for non-compliance? 

Monray Williams: Essentially, if you're not compliant, the severity of the noncompliance dictates the consequences, which are reported to the SOX team and ultimately to the SEC. This can lead to a range of penalties, depending on the situation. 

However, the most significant impact might not come from the SEC directly but from how your shareholders react when they learn that your controls aren't in place. Recently, the SEC has expanded its requirements, mandating the reporting of privacy and security breaches as well, which can further influence how shareholders relate to your stock.  

In the industry, there’s a common belief that the presence or absence of effective controls can influence stock prices by up to 20%. While I can't definitively confirm that figure, many experts suggest that good governance and strong controls can positively impact a company's share price. On the other hand, if management fails to comply, the bigger concern might be the indirect repercussions from the market, not just the penalties imposed by the SEC. Ultimately, market perception is what should concern management the most. 

Bartosz Szpiech: Losing 20% of your stock price has a huge impact, especially for large organizations. 

Monray Williams: Exactly. If you look at recent events, the impact on share prices when controls fail is significant. And I’m not just referring to controls related to financial reporting. Take the recent CrowdStrike incident, for example. I believe the impact on their share price was around 11%, though we can debate the specifics of what went wrong. In my opinion, it was essentially a control failure that led to the release of an update, which is estimated to have caused around $5 billion in damage to the market. 

Bartosz Szpiech: It was significant.  

Monray Williams: Absolutely! While the goal of this discussion isn’t to analyze the incident in detail, we have looked into it, and I firmly believe that a breakdown in some internal controls is what allowed this update to reach the market. 

Bartosz Szpiech: That's an interesting point! The impact was widespread, affecting everything from airports and the military to aviation and medicine. So, that really encapsulates what needs to be considered during implementation.  

What are the key risks to be aware of, and what remediation steps should be taken? What would your recommendations be for a company that is preparing to go live or planning to implement a system soon? Should they collaborate with auditors? Should they engage in internal planning? What advice would you offer to a company gearing up for an ERP system implementation? 

Monray Williams: I think there are three or four key components to consider. 

First, as part of your system design and business processes, it's critical to integrate your controls and control points right from the start. You don’t want to retrofit controls after the fact. Many companies overlook this, and then, when auditors raise the issue, they find themselves having to reconsider and sometimes even re-implement parts of their processes, which can be very costly. Therefore, ensure that controls are an integral part of your system development lifecycle, with appropriate controls built into your business processes. 

Second, make sure to test those processes thoroughly before going live, and that includes testing the controls. From the moment the system goes live, your controls must be functioning properly. There's no opportunity for you to wait to establish controls after the system is live. 

The third point is related to working with auditors. While auditors can't provide a formal opinion on your controls until they are operational, you can look at the opening balances, make sure that everything that comes into the system is independently verified, and then the auditors can give an opinion on the design of the controls before they are operational. You can also leverage your internal audit department to review the design of the controls, even if they aren’t completely independent. There are many proactive steps you can take to avoid being non-compliant or lacking sufficient controls. 

Finally, when selecting your ERP system, be sure to ask detailed questions about its capabilities. I’ve seen situations where companies move from a system with strong control capabilities to one with fewer built-in controls, which then forces them to rely on additional tools or systems to maintain their compliance. So, understanding the capabilities of your chosen ERP system is key to avoiding extra effort and maintaining the necessary control environment.  

Bartosz Szpiech: That's a great point, and I think it’s worth diving into the case of Dynamics Finance and Operations. It came as quite a surprise to many stakeholders on the project that the standard version of Finance & Operations, at the time of implementation, lacked key control measurements. For example, the segregation of duties wasn’t functioning as expected. We can probably agree that the way SOD was handled in F&O was a bit misleading because it wasn’t tied to the smallest security objects in the system, which caused confusion. Even though it might have seemed like the right choice, that oversight created challenges. As a result, companies now need to not only purchase F&O but also look for ISV products and include an auditing team to ensure they can achieve SOX compliance. What’s your take on Finance & Operations and making it compliant from this angle?  

Monray Williams: I think you’ve brought up two important points.  

First, it’s crucial to assess segregation of duties at the correct level. If you’re not doing that, you’ll end up with false positives, thinking you're compliant when in fact, you’re not assessing SOD correctly. 

The second point is that businesses need to have a defined set of rules in place. These rules should be used either within the application itself or through supporting tools to assess which transactions are incompatible and shouldn’t be assigned to the same user. Many companies lack this "rule set," and without it, there’s no clear way to test whether the access rights you’re giving to users might create a conflict.  

So, for me, the solution is twofold: first, the business must establish clear rules about what is and isn’t allowed; and second, the ERP system or supporting technologies need the functionality to check compliance against those rules.  

Bartosz Szpiech: To put it simply, you can make Finance & Operations SOX compliant, but you need to make certain decisions about which tools to incorporate. You need a solid foundation to properly design role access rights, ensure SOD measurement controls are in place, and create a rule set. Things like emergency access rights and other processes come into play as well, but that’s a longer discussion.  

The point is, F&O is stepping into the enterprise-level market, and every system integrator wants to work with it. And with the right experts, we’re able to take F&O to the next level and ensure that the necessary controls are in place so that organizations can maintain compliance.