Mitigating controls are a great way to reduce SOD conflict risks. But if you’re not careful, you can mitigate yourself out of compliance. SAP SOX compliance in your company may be such a routine activity that you’ve lost track of why you’re doing it, beyond being told to. And, you may not realize that there could be ways to do it better. It’s not enough to assign a compensating control to a risk and call it a day. Advances in Governance Risk Management and Compliance (GRC) solutions offer new methods for handling SOX aspects in the SAP audit, especially concerning Segregation of duties (SoD).
First, What Is SOX Again?
SOX is short for “The Sarbanes-Oxley Act,” a federal securities law affecting publicly-traded companies. Sarbanes and Oxley were both Senators who sponsored the legislation in 2002. The law arose from a realization that public companies needed to do a better job creating accurate financial statements. Such a need became glaringly apparent in the wake of massive frauds at Enron, WorldCom and Global Crossing.
If you haven’t heard of those three companies, that’s sort of the point here. These were among the biggest and most famous businesses in the world, and they all went under after they were caught cooking the books. Investors lost billions. Thousands lost their jobs and retirement plans. The “Big Five” accounting firm of Arthur Andersen collapsed under indictment, which was another consequence of this malfeasance. Now, it’s the Big Four… It was a bad time. Equity markets needed reassurance that a company’s financial reporting was correct – hence the law.
The SOX law is lengthy and complicated. Two of its sections are relevant to the IT department and SAP administrators. SOX Section 302 covers a company’s financial reporting. The CEO and CFO must personally certify that all the company’s records are complete and accurate. These two executives must confirm that they accept personal responsibility for all internal controls and have reviewed these controls in the past 90 days. The law even calls for criminal penalties for willful violations of SOX. This has not actually occurred in 17 years, but the idea of the top people going to jail over the configuration of your SAP landscape is pretty intense.
SOX 302 definitions of internal controls include IT infrastructure affecting accounting and financial reporting. For example, SAP. Section 404 lays out addition requirements for monitoring and maintaining internal controls related to a company’s accounting and financials. SOX 404 requires an annual audit of these controls, and it need to be performed by an outside firm.
Translation: the SAP audit is part of SOX compliance. A federal law mandates your CEO and CFO to put their signatures on your work product. Further translation: You better know what you’re doing if you value your job.
SAP SOX Compliance and Internal Controls
SOX is big on internal controls, with good reason. Internal controls are processes that ensure the accuracy of financial statements. Say you have an internal control specifying that two separate people handle the processes of invoicing and making bank deposits, respectively. This is known as Segregation of Duties (SoD).
This control prevents a single person from being able to easily commit fraud. An example could be sending an invoice, stealing the payment and then deleting the invoice. The risk here is that the company’s cash flow would not equal its reported sales revenue. Accounting audits are supposed to catch such tricks, but as the Arthur Andersen example shows, auditors can be misled. Alternatively, the SoD control prevents a single person from sending a fake invoice, which overstates the company’s revenues and earnings, ultimately enabling executives to collect unearned bonuses. This fraud is perpetrated by insiders, and is similar to what happened at Enron and the others.
Given that SAP is typically the main financial and accounting system at a business, the SOX audit often focuses on internal controls configured into the SAP landscape. The SoD controls described above, and many more, are set up and governed inside SAP. The SAP audit verifies that they’re effective.
How to Reduce SoD Conflicts in SAP SOX Compliance
When two SAP system users have access privileges that allow them to violate an SoD control, that is known as an SoD conflict. To pass an SAP audit that fulfills the needs of SOX, you have to identify and get rid of SoD conflicts.
The SAP audit process will ask you to answer two basic questions about your controls.
- Are they valid?
- Do they actually work?
For your controls to be valid, they need to mitigate the entire risk, not just a piece of it. You need to prove your success to the auditor.
Common Pitfalls with Mitigating Controls
Setting up new vendors is an activity that can lead to fraud if a single SAP user can set up a new vendor, submit invoices from this new vendor and then approve those invoices for payment. Unfortunately, real life experience has shown the potential for costly and embarrassing frauds using this exact technique. So let’s say you want to reduce SoD risks in vendor management. One way to overcome an SoD risk like this is creating what’s known as a “mitigating control.”
Mitigating controls might state that you review all Vendor Master Changes on a weekly basis for appropriateness. As you might imagine, this is a potentially faulty practice. It’s an adequate control to have someone skim the changes and search for potential SoD problems. In our experience, excessive reliance on mitigating controls is risky.
It won’t matter to the auditor if you’ve said you are going to execute a potential process. You have to make the actual mitigating control work. Instead, you should have a process in place to define what you’re looking for and how to address suspicious activity. A procedure should document the workflow so it’s reviewed and signed off by the appropriate party each week. You would also have to reaffirm the control. This way you can ensure it actually addresses all the SoD risks it’s supposed to cover.
Manual Processes Are Impractical for Reducing SoD Conflict
You have to automate your internal controls, especially SoD. It’s just too difficult to use mitigating controls successfully without automation. The process is time-consuming and complicated. Using manual review results in a patchwork of poorly-maintained controls, and won’t reduce SoD conflicts or other obstacles to SAP SOX compliance. Even if the manual process leads to controls that work, it is usually hard to maintain the review process. Compliance staff wastes time getting signatures and documentation.
Automated processes enable you to continuously monitor your controls. GRC software like our ControlPanelGRC can provide this functionality. It can spot issues instantly and then drill down to reduce SoD conflict. This saves everyone on the audit team and SAP admin teams a lot of time.
Finding the Right SAP Access Control Solution
Symmetry’s ControlPanelGRC tool augments SAP’s native capabilities to enable streamlined SOX audits. It defines and analyzes risks in the SAP software, and ControlPanelGRC also provides rulebooks that help with SoD management. It works on a highly granular level and facilitates risk modeling and “what if” scenarios.
ControlPanelGRC Access Control provides continuous control monitoring in a single solution. It automatically executes compensating control reporting. A self-documenting workflow follows, allowing for review and signoff. These capabilities let you reduce SoD conflict and cut down on uncertainty in your SAP SOX compliance efforts.
Learn how Symmetry can support your SAP SOX compliance processes. If you would like to receive a free SAP GRC Risk Assessment, please contact us.