5 Steps to Overcome Your Fear of Data Analytics in Audit

5 Steps to Overcome Your Fear of Data Analytics in Audit

Many people get overwhelmed when we talk about data analytics. They believe in a false narrative that analytics and data mining is an IT task, and not something that a business or risk and audit resource can handle. The phrase “data analytics” might conjure images of IT experts using super complex software and typing code to analyze millions of rows of data. But that’s simply not true. In reality, most data analytic efforts — even with large data sets — can be easy to implement, do not require specialized technology, and can be very beneficial to implementing efficiency into your audit program. 

Among the many benefits of integrating analytics into an audit or control testing program, one of the most significant is that the ability to analyze data from an entire population using a consistent analysis methodology over time provides the best insight. This analytic insight can identify areas of unknown risk, instances of over or under testing, and thematic trends across an enterprise that aren’t necessarily visible when using siloed or incomplete data sets. 

Data analytics doesn’t need to be intimidating — there are many intuitive data analytics tools available in internal audit software. In the end, data analytics is nothing more than a systematic review of information to draw a conclusion, which is similar to performing a test and recording the outcome. The goal with audit analytics is to improve our testing by systematically analyzing data to draw conclusions and use that information to guide our audit programs year over year, and most publications on this topic point to a simple 5 step process.

Step 1. Define Your Objective

Before you even start looking at the data, understand the potential areas of risk or control failures associated with the underlying business process that are related to the data, and figure out what you think the data could tell you. Then, imagine what the results could be. 

For example, suppose you are going to look at a listing of transactions from a payment system. In that case, you might develop objectives like looking for transactions that are not supported by purchase orders or looking at the days of the week the transactions are posted. The result could show that not all transactions were supported, or we may find transactions posted on the weekend when no one should be working. This is the step when you should ask big questions, think thematically, and use experience and insight to consider trends that you’d like to investigate.

Step 2. Find the Data

Depending on data availability and the questions you’re trying to answer from Step 1, you may need to combine sets of data from multiple sources. If you’re already using an integrated audit platform, much of the data may already be present in one system, but oftentimes you may need to consider and combine data from ERP systems, IT management systems, or payment systems. The type of testing you can perform and analytics you can derive will be dictated by the information that is available to you. 

Let’s say you are planning to look for transactions posted on the weekend when no one is supposed to be working. At a minimum, analyzing data for this test will include a date/time stamp on each transaction, but you will probably also want to know who processed the transaction, the dollar amount, and a supervisor’s approval. Your next action will be to actually get the data. If you have the required access and sufficient training on the systems involved, you may be able to get the information on your own. If you do not currently have this information, work with your IT team to get read-only access to critical internal systems and have the end-user administrator provide training to the internal audit department. Ideally, this data could be integrated directly into your audit software in a recurring feed so you can utilize this analytic over time to see trends in testing and overall control performance. Understanding how the data is used in practice can help you overcome the fear of data in a spreadsheet.

Step 3. Prepare the Data

Much of the fear of data analytics stems from large data sets and disorganized, unstructured information. Data preparation includes many different aspects, so we will focus on two of the broadest, most encompassing points: preparing the data and normalizing the data. Preparing data addresses the quality of the information, while normalization (in general) eliminates redundancies. 

Preparing the data is especially necessary when the information is coming from multiple sources as the structure and format of the data will most likely not be the same. For example, you may have a column of text in a spreadsheet, but some cells also have numbers or spaces in front of the letters or symbols in the data. Another example is one system may have a date format of mm/dd/yyyy and another may be dd/mm/yyyy. Preparing the data will remove all of the unrecognizable information from the cells.

Normalizing looks for different versions of the same data records. For example, a company name could show up in multiple tables in multiple ways: AuditBoard, Audit Board, Audit_Board, Auditboard. These are all the same company input into systems in different ways, but are actually the same piece of data. Normalizing attempts to resolve data variations across multiple sources to avoid extraneous data that could skew your testing and analytic results. 

If you don’t prepare and normalize the data, the output will either produce an error or the results will be unreliable. This process sounds challenging, and is oftentimes what people fear when dealing with large data sets. However, there are specific tools that can help with this process that are present in most organizations. They are not difficult to use and often suggest fixes to the data you are trying to combine, which means that you don’t have to identify issues, simply resolve the problems. Reach out to your IT department for assistance if you need help locating and using such tools.

Step 4. Analyze the Data

At this point, you will have come up with the objective, pulled the data, and spent some time preparing and normalizing the information — now it’s time to analyze the data. Once you run the tests, you may or may not understand the results. Your best resource to understand the results will likely be the people you are auditing. If it is appropriate, you can take the results back to the data owners for help understanding the output. That this may not always be appropriate, especially if this is for a fraud examination.

Also keep in mind that it may take more time and more data to determine an outcome, especially if you’re testing for trends over an entire fiscal year or longer. Don’t get discouraged if at first you’re not seeing the expected analytic answer. 

Step 5. Report Results

One of the most critical factors in reporting results is knowing your target audience. Reporting to the board versus a process owner will be very different. Your reporting should help achieve the desired actions that need to be taken — you can provide more detailed reporting to a control or process owner that could drive action plans, while reporting a more succinct analysis to senior management to raise positive or negative trends across the enterprise. In addition, be careful not to overwhelm management with excess information. Always present summary information and provide any details as an appendix to the summary. 


Applying the five steps above will go a long way in overcoming a fear of data. No matter where you are in your data analytics journey, consider how introducing an analytics process can impact your audit team’s testing. Adding analytics to your audit program improves testing effectiveness by testing entire populations instead of random or judgmental sampling, which provides greater assurance.


Joe Traietta, CISSP, CRISC, was a Managing Director of GRC Alliances at AuditBoard. Prior to joining AuditBoard, Joe spent 20+ years in industry and consulting with companies such as BNY Mellon, EY, and PwC specializing in IT Risk, Vendor Risk, Operational Risk, IT Control Testing, and GRC Technology Enablement across the financial services, insurance, and retail.