Tips for Compliance and Data Analytics

The other day I had the great fortune to moderate a webinar on data analytics in compliance programs with Kirsten Liston, founder and CEO of Rethink Compliance. We had a great time and Liston certainly knows her stuff on data analytics, so I took lots of notes. Let’s review the major themes that arose from the discussion.

We can start with compliance officers’ access to data, since that’s a point the Justice Department has emphasized repeatedly in recent years. Right in the department’s guidelines for effective compliance programs is the question: “Do compliance and control personnel have sufficient direct or indirect access to relevant sources of data to allow for timely and effective monitoring or testing of policies, controls, and transactions?”

I suspect that at many companies the answer is still no. The next question is why you don’t have such access. 

You might have a technology problem. Remember that internal auditors worry about access to data too, and they talk all the time about the enterprise needing a “single source of truth” from which different teams can pull whatever data they need for the analytics they’re preparing. You, the compliance officer, would be one of those teams. 

Plenty of GRC systems proclaim that they are that single source of truth. Larger ERP systems such as Oracle or SAP promise that too. So maybe the obstacle to you having access to data is a poorly configured ERP software system or a GRC tech platform that doesn’t meet your needs. You can’t access the data because the data doesn’t exist.

Then again, you might have a corporate culture problem instead. That is, if your company has sophisticated data analytics for marketing, finance, HR, and other parts of the enterprise, but not for compliance, then the problem isn’t the company’s technology or its supply of data. The problem is a corporate culture that keeps the compliance function marginalized. 

The Justice Department appreciates the distinction here, by the way. In numerous public appearances, officials have stressed that they want to see a data analytics program that’s reasonably designed given the company’s overall operations. So if your enterprise has only rudimentary data analytics capabilities across the board, prosecutors won’t expect the compliance team to have a stellar, stand-out program. On the other hand, if your company has been using whiz-bang analytics in all departments except corporate compliance, that’s going to look really bad — and it should. 

So if you’re still struggling with access to all the data you need, begin by asking what the obstacle truly is: deficient technology, or deficient culture? Those are radically different reasons, and you’ll need radically different arguments to persuade senior management to change its mind. 

Analytics-Friendly Processes

There is another possible scenario, too. Senior management might fully support your mission for more data analytics, and the company might have ERP or GRC software sufficient to help — but your business processes might not be generating the data you need. 

I call this having “analytics-friendly” business processes, designed to generate the data you need to collect. 

Some business processes are inherently analytics-friendly. For example, if you’re sending an online survey to employees, the responses you get will be neatly structured and ready for whatever analytics program you have. Ditto for most processes in the accounting department, where you could sort transactions by date, amount, payment recipient, and more. All those fields must exist for any accounting system to function, so just about any accounting process is analytics-friendly.

What about, say, exit interviews that HR conducts with employees? How are they collecting data during those interviews? If they ask questions in person and record answers manually, that’s decidedly not analytics-friendly; to pull out useful data at scale, you’d need lots of transcription or sophisticated text analytics. You’d be layering an analytics process on top of the data collection process. That can get complicated and messy.

Or look to your own Code of Conduct for an example closer to home. If the code only exists as a PDF or a web page posted to some internal website, you can’t easily extract data about how employees actually use it. Hence it’s all the rage these days to talk about a “digitally transformed” Code of Conduct, which can generate all sorts of structured data you can then analyze. 

Compliance officers have a few points to consider in all this. Foremost, how do you identify business processes that either are analytics-friendly, or could easily be made so? I would flag two factors:

• The process happens at scale, such as payments to third parties, calls to the hotline, visits to training courses, and so forth. It needs to happen frequently enough, and in a uniform manner, that if you could capture data, you’d have enough data to make the effort worth your time.
• The process has quantitative dimensions to it, which are far more easily captured than qualitative data. Go back to that example of HR exit interviews. Maybe you’re a large company where exit interviews happen at scale, but if the exit interviews are open-ended questions with extensive written answers, that’s qualitative data — great to consider, hard to analyze. 

When the process happens at scale, and has quantitative dimensions to it, that’s a process ripe for data analytics. Even if you need to redesign the process so it’s more digital in nature, that will be far easier to do than transforming a process that primarily handles qualitative data. 

How to Determine Meaning

Sometimes you might want to focus more on the analysis behind a piece of data more than the data itself. 

For example, let’s say your company tracks internal reporting metrics, and you have 0.6 reports per 100 employees. That is less than half of what Navex estimates as the average for all companies, which stood at 1.47 reports per 100 employees in its 2023 Global Incident Management Benchmark Report. 

That 0.6 number doesn’t necessarily mean that your data capture is wrong. Instead, you need to sit back and ask, what circumstances at my organization must be true for this number to be accurate? 

It could be that your company is great and nobody has any complaints. Well, what other evidence would support that thesis? 

• Extremely low employee turnover
• High satisfaction on employee sentiment surveys
• Lots of employee referrals for new hires
• Lots of internal promotions
• High scores on discussion board websites such as Glassdoor.com
• An abundance of clean internal audits 

Or maybe that 0.6 number exists because you have a terrible reporting process. How could you test that thesis? Maybe most employees bring their concerns directly to managers. Do managers understand how to handle an internal report? Does a formal policy exist requiring them to pass along complaints to the compliance team, and have they been trained on that? 

My point is that compliance teams will inevitably encounter an outlier result. The next question is how to deduce whether that outlier is accurate. Start by asking why that number might be true, and then look for evidence to prove or disprove those possible reasons.