Steve Biskie, Co-Founder and Managing Director, High Water Advisors, joins SAPinsider Studio at the SAPinsider GRC 2016 event to discuss audit controls in the age of enterprise digitization.
This is an edited transcript of the discussion:
Ken Murphy, SAPinsider: Hi, this is Ken Murphy with SAPinsider. I am at the SAPinsider GRC event here in Las Vegas. Joining me today is Steve Biskie, who is the Co-Founder and Managing Director of High Water Advisors. Steve is also a long-time speaker here at the GRC event, I believe one of the first is that’s correct?
Steve Biskie, High Water Advisors: Before they were even called GRC events, back in the early Sarbanes-Oxley for SAP Customers.
Ken: Thank you for joining us again.
Steve: Thanks Ken, good to be here.
Ken: GRC was a big topic at this morning’s keynote, and one of the things that struck me was one of the presenters saying that there’s sort of an unofficial re-branding of SAP GRC as SAP GRC and security. What does that mean for the GRC space? How significant a change is that?
Steve: I think there are a couple of things. Security has always been important in the GRC side in that security is a huge control enabler that helps us ensure that people that are doing work and performing functions in their environment are the people that are authorized by management to be able to do that. Certainly one of the new things we hear a lot in security these days gets into the cybersecurity side, and I think that’s one of the bigger shifts; historically we’ve paid more attention to users and access roles in SAP, and now we’re having more recognition that it goes beyond that when we talk about security. So at the end of the day we need security to help protect us, but part of that protection is not just the external threat it’s also the internal and just making sure the right people are doing what they’re supposed to be doing. So I don’t know it dramatically changes from an audit and compliance perspective what we focus on, but it certainly adds a layer that perhaps we hadn’t put as high of a risk as we do today.
Ken: We keep hearing about the digital transformation and companies going digital and the need to become data-driven. How does that impact governance?
Steve: Historically, auditors at some point we need to go back to paper and now one of the challenges is we don’t have paper anymore, it’s all electronic. But I think it’s a huge opportunity for us as well, because as we start to get more digital data the opportunity to be able to mine through that data and verify that things are working the way we intended, to some extent a large part of the audit history where we take samples of things was driven by the fact that you just didn’t have accessibility to everything so you’d take a small sample because at some point you had to go back to an electronic document, maybe a contract with a signature. But the opportunity here is as we move more into this digital age, we can now mine through 100% of what we’re doing and really focus in on where the potential problems might be as opposed to guessing a little bit or relying on samples to get there. So I think for me and my profession it’s a huge opportunity for us.
Ken: So how does that digitization of the enterprise change the way a company has to look at the way it does its internal controls.
Steve: The biggest thing is I think it affords an opportunity to look at different things, so take an example a configurable control in SAP. We may look at tolerance levels, and tolerances do a couple things for us. They recognize that there’s a cost benefit relationship between controls in SAP, so if a customer pays me a little bit less or maybe slightly more than they owed, or if we pay a vendor slightly different than contract terms historically you’d go back and you’d correct those. But if it’s a very small difference we find that we may spend more time correcting than actually the value of that difference there. So SAP provides these tolerances, but the difference is before the digitization and all this information electronically historically we’d test that as a configuration control. We’d look to see how is it set in SAP, and we can still do that. But now that we’ve got the data electronically we can now start to mine for the outcome of that and ask if the benefit we hope to achieve from that control actually being met? As we start to look at that data we’re going to see things that we might not have caught during the configuration test. So as an example we might see that while that three-way match process is met and only things that were within those tolerances were being paid, we start to see some examples of transactions falling outside and wonder what happened. Well now we’ve got someone assigned the ability to manually release these payments and removing those blocks and therefore effectively bypassing that control, and that’s not the type of thing we’d have been able to see easily without the ability to look at all the data.
Ken: But can you see all of them? Are there any hidden control issues in an SAP system?
Steve: I’m doing a talk this week on that topic, and part of it again goes back to changing the mindset of how we test controls. A very typical audit-related test of controls is going to focus heavily on configuration and then some assessment to make sure that that configuration hasn’t changed over time. But as you really start to dig into that outcome side and whether that outcome is being achieved, we need to look at other things. So sticking with that three-way match process, a typical three-way match is I’ve got a purchase order, eventually I’ve got a receipt against that purchase order and I’ve got a payment. And traditionally we’d look at that and ask if all of those are within the tolerances we’ve defined? And we’re good. But when we start to think about the outcomes and different ways of looking at this and how these can be circumvented, one of the most common ways to circumvent the three-way match control is someone waits to create the purchase order until after the goods receipt or after the invoice comes in. Which means that it’s still going to go through that matching process, but because the purchase order is created after the fact it’s almost guaranteed it’s going to match those items. But now we can mine through those transactions and we can identify situations like that and have a conversation with management as to whether this is in line with what their expectations are. And I think that’s the key for me is that the more data we have, the more ability for us to mine through –we’re not necessarily saying this is a good thing or a bad thing, but we’re able to actually quantify that conversation with data and have a very productive conversation with management about what their expectations are around those controls.
Ken: As more and more data comes in though does that become more difficult, does it present more risk either internally or externally to the organization?
Steve: It’s a good question and on one hand you hear the argument that as we start to find out more particularly with some of the new compliance regulations we may be obligated to report on those issues. Others would argue that wouldn’t it be better to know and make intelligent decisions around that. It certainly does add a little bit of time at the front-end. But if we’re smart about the way we’re doing this, it will absolutely take us longer to mine through the data that first time and figure out what’s working and what’s not working. We may have some false positives when we look at it because we understand that business process. But if we’re smart about the way we’re doing it then next time we do it what we’ve done should be highly reusable. So over time we should really be able to streamline our audit practices and compliance processes to leverage this data and get to proof. But to your point it also involves a change even on the external side. So there’s historically on the external audit side when we’re dealing with a compliance issue we might test a control and if there are one or two errors in that control eventually we say that it’s significant and we need to report it. But if we’re looking at everything there’s never an expectation that a control needs to be perfect, so it very well could be that we have hundreds of deviations from that control but it’s still acceptable. But that’s a mind-shift that we need to move from the way we used to do it with these samples into how do we work now that we’re looking at everything that’s happening, and how do we help quantify it? And more importantly as management, how do we communicate what that acceptable level of tolerance is for that control, recognizing that we don’t always expect it to be perfect there are going to be some deviations. What’s that threshold above which we say that maybe it’s not acceptable and we want to dig more?
Ken: Are there any other ways to identify and assess internal control outcomes?
Steve: I think there are a couple. So SAP on the Process Control side, that’s really the tool that’s been designed to do that. And one of the nice things about Process Control is that you can build each of those layers into it. So on one hand you can monitor the configuration itself and whether it’s monitoring it against a standard to say it either matches or doesn’t match the standard I expect, or even getting into more of a real-time automation around that to say that I’ve now triggered a workflow that if this control changes, if this setting changes in SAP, I want to be notified about it. So we’ve got that and that’s part of process control. But then within the rules engine of process control we also have the ability to mine through the data and support that controls setting with the outcomes that we’re seeing and maybe flag transactions that fall outside of the boundaries that we’ve set. So from a technology perspective, SAP has given us the tools. As organizations move more and more to tools like HANA as well as the back-end for process control it only expands what we’re able to do and the speed that we’re able to do it. So it’s a pretty exciting time.
Ken: One other thing we heard in the keynote today was more from the business side – again with the theme of digitization – is that the business is sort of leading or driving IT for internal changes. Do you see that same dynamic manifesting itself in the GRC space?
Steve: For sure. And again going to some newer technologies that SAP has introduced, when I think of something like Process Control. We’ve talked about the benefit of that and Process Control has a brother now called Fraud Management. So whereas Process Control is going to mine for indicators that our controls are working as we expect within that, Fraud Management is a tool that we can begin to use to ask if there’s things from that controls standpoint that do fall a little bit under the radar that when we look at the big picture of the enterprise any one of those activities might not pop up as being important, but now when I look at them in combination, it raises a flag. So companies dealing with anti-bribery type regulations these days as an example. It would be common as a company that we have an even-dollar transaction that occurs. It would be common that we have periodic cash transactions that occur; we’re always going to be doing business in high-risk countries over there. Once in a while we’re going to do business with a new agent, but now we’ve got an even-dollar cash transaction in a high-risk country to a new agent in there and that becomes a slightly different picture. The combination of those two tools I think again gives us the opportunity to see things that we might not have seen before and I think Fraud Management is a great example of one of those that would probably never be driven by IT, it’s driven by this business realization that if I can identify and catch behavior not even fraud related, it could be just errors or mistakes that people are making, but if I can identify and correct that near the point of occurrence, I prevent the snowball effect that at some point in time would later result in a large clean-up effort.
Ken: Steve, thank you for joining us today.
Steve: Excellent. Ken, I appreciate it. Thanks for having me.