Analytics and improving the SOX compliance process
Using the right technology in the right way can do a lot to help reduce the costs and efforts involved in SOX compliance. One of the quickest wins can come from using data analytics to test the effectiveness of internal controls. This is not normally done by directly testing the individual control, but by testing all the transactions that are meant to be subject to that control. If all the transactions appear to have complied with the control objectives, then the control is assumed to be working as intended.
One of the great advantages of using analytics to test controls in this way is that you go beyond the traditional approach of, say, simply checking that a certain control setting in an ERP system is turned on. You can find out whether, despite the setting being on, there is evidence that a problem transaction has still occurred—meaning that the control is not 100% effective after all. You can also determine if there have been deliberate attempts to circumvent the control. So, to take a simple example, you can test to see that all journal entries were approved by an appropriate individual and within their authorization limits. You can then also test to see if attempts were made to circumvent the control by, say, splitting a large journal entry into multiple smaller ones, just under an authorization limit.
Should analytics become part of the control process itself?
There is an interesting issue that arises when considering transaction monitoring as part of a SOX compliance process. Is there a point at which transaction monitoring actually becomes the control? And, if so, is this a problem?
I was asked this question during a recent webinar. The implication was that if transaction monitoring is the control then there is a problem. I think it is a good topic to discuss for a number of reasons—one being that it can open up a good conversation about roles and responsibilities among the three different lines of defense. Personally, I don’t think establishing transaction monitoring as part of a control mechanism is a bad thing (the reverse, in fact), but it does all depend on who has responsibility for performing and responding to the monitoring.
Whose job should it be to monitor transactions?
If someone in internal audit is responsible for transaction monitoring, no one is likely to see that as an issue in terms of roles—auditors have been using data analytics for SOX control testing as part of the audit process for years. But what if the monitoring is an ongoing process—performed on a daily or weekly “continuous” basis? Is it really the auditors’ job to deal with all the issues that may arise from “red flag” transactions that may or may not indicate actual fraud and errors? Perhaps it is reasonable that someone in the second line of defense takes on responsibility for transaction monitoring—as a bit of a mid-point in terms of roles. But why not make transaction monitoring the responsibility of front-line management—the first line of defense? They are the ones directly responsible for maintaining effective controls—so why not have them use the power of data analytics to enhance the control systems that need to be in place? It doesn’t have to replace traditional control systems—even though it may make sense to do so in some circumstances—just supplement them.
I would argue that having the first line of defense perform transaction testing/monitoring is a very good way of enhancing control and of supporting SOX compliance processes. What do you think?
eBook: The Essential Guide to
Seriously Reducing the Burden of ICFR/SOX/A-123 Compliance
In this 26-page eBook, you'll learn how to: