Information: facts provided or learned about something or someone.

Analytics are the building blocks of risk assessments. 

Simply put, an analytic is a piece of information. And like any other piece of information, the way in which you use it is as important as the information itself. 

In audit, each analytic should provide a fact about a data point or set of data with respect to a risk. It is from these analytics, these pieces of information, that auditors and financial managers can build a larger understanding of risk on the data set, process, system, or organization. Thus, analytics comprise the most essential material of risk assessment. 

While each analytic may answer a simple question, identifying, creating, and compiling analytics is not a simple process.  Building on years of experience, we have refined a process for developing analytics that makes a difference for ThirdLine users. We'd like to share that with you -- how to build an effective analytic and integrate them in a way to build knowledge about your organization and ultimately an effective risk assessment tool.

‍

Good analytics have contextual attributes. 

A good analytic anticipates future questions.

The purpose of an analytic is to identify some characteristic of risk within the system and provide the auditor or management with insight into how to deal with that risk. Therefore, each analytic needs what we at ThirdLine call contextual attributes. Contextual attributes are the who, when, where and what type of risk that each analytic needs for future insights.

Who: Which employee performed the action that triggered the analytic?

When: When was the transaction made or reviewed?

Where: Which business process and department are associated with the transaction?

Risk-type: What kind of risk is associated with the transaction: fraud, ESG, control, training risk, or all of the above?

In many cases, the contextual attributes of the analytic are found in the same tables or schemas as the information used to inform the analytic. However, some information may need to be joined in. For example, you may know the employee associated with the transaction, but their department information may come from an organization chart. Take the time to compile these tables, so when your Chief Auditor asks you, “Which department is riskiest?” you have the answer. 

It is the contextual attributes that enable the risk assessment tool we are aiming to build in the future.

‍

Good analytics identify a risk. 

Just because you can make an analytic, doesn’t mean you should. Before building any analytics you need a plan for your risk assessment tool. First, identify the process to evaluate. Then hold conversations with subject matter experts on those processes. In these conversations, identify each step of the process, and then identify risk associated with each step. These can include risks that a transaction itself is inappropriate or the risk that the controls put in place by management are failing.  

For example, if the goal is to assess risk within the purchase card program, begin with understanding how transactions are completed and reviewed. From conversations with the purchasing manager and from reviewing policies and procedures, you identify four risks.

Risk 1: The cardholder circumvents their spending limit

Risk 2: The cardholder buys an inappropriate item

Risk 3: The cardholder buys something for personal use 

Risk 4: Someone other than the cardholder uses the purchase card. 

‍

Good analytics ask simple yes or no questions. 

From here, separate the risks you can identify with the available data. This is an iterative process of considering the data sets you have access to and how to operationalize the risk into a simple analytic that answers a yes or no question. Operationalize is a fancy word for finding a way to measure a thing. For example, in health care the doctor may measure your health through blood pressure and heart rate.

In this example, we don’t have a data source to know if someone else was using the employee’s card, but we have spending limit data, spending amounts, date stamps, and information about the vendor based on the merchant category code. This process comes up with the following analytics:

‍

While these analytics are imperfect measures for identifying circumvention of spending limits, inappropriate purchase, or personal use purchases, they provide some potential indicators of risk. Much like measuring health with blood pressure, when we operationalize a risk into an analytic, it can be an imperfect measure. The benefit of using these analytics is it focuses the auditor’s valuable time on a risky subset of transactions, rather than relying on random selection. 

The last area we wish to build an analytic for is related to the controls in place to mitigate the other risks. In this case, the review process. The organization requires the cardholder’s supervisor to review transactions within 30 days of submission which we can operationalize using the audit history of the transaction. 

Analytic 4. Did the reviewer complete their review within 30 days?

This last analytic is a more precise measure than the others.

Generally speaking, analytics that test controls are more precise because controls are often rule-based and set up to be yes or no questions. 

After each analytic is defined, auditors can prioritize the analytics in order of importance to the organization or the audit department. This is your risk road map.  In this example, the auditors are most concerned about controls, therefore the road map places the split transaction and review process analytic at the front of the road map, and then auditors will tackle building the analytics related to merchant category code and weekend purchases later. 

The most important thing to remember is the analytic should answer a single question about the transaction in question. For example, was the transaction performed during business hours? Or, was the transaction reviewed within 30 days? For those of you who have conducted attribute testing for an audit, the importance of a simple “yes” or “no” question is familiar. As my graduate school advisor used to say, “Clarity begets clarity, and mush begets mush.” This is true for your analytics, too. 

‍

Good analytics tell a story.

Ultimately, each analytic should tell a story that matters to the owners or users of the business process you are analyzing. As you interview subject matter experts and isolate the rules and controls from policies and procedures, consider the stories that need to be told by the users. 

For example, a story related to purchase card misuse may be, “As a manager, I need to know when purchase cards are used over the weekend.” Another story may be, “As an auditor, I need to know if compensating controls for weekend transactions are working.” 

User stories such as these supply those involved in creating the analytics with a simple thread to tie multiple risks together and link the analytic back to the data set, process, system, or organization that you are focused on.

They can also help focus and prioritize which analytics to build out. Finally the user story provides a plain-language descriptor of the work for non-technical partners and users. 

‍

Looking to the future

With the guidelines outlined here, your analytics will 1) be based on risk and placed in a Risk Road Map, 2) ask and answer simple questions, 3) include contextual attributes needed for the broader risk assessment, and 4) tell a user story that matters to the key players within the business process you are analyzing. 

You will have the right information to take simple, risk-based questions and identify which employee, which department, and which time period have the greatest risk, AND which type of risk your organization needs to focus on. 

Final risks and analytics with contextual attributes.

‍

‍

This blogs is the the second of a 5-part series. Check out the others below:

1. Top 10 Reasons ERP Analytic Initiatives Fail

2. Analytics = Information (This One!)

3. Risk Assessment = Knowledge

4. Analytics-powered workflow = Experience

5. Your Judgement + AI/ML = Wisdom

‍

‍

‍

‍