Risk and Control Issues Commonly Overlooked by Internal Audit - 8: Data Warehouses and Business Intelligence/Analytics

Norman Marks, CRMA, CPA, is a vice president for SAP and has been a chief audit executive and chief risk officer at major global corporations for more than 20 years.


This post includes a sneak preview from the soon-to-be-released update of my SOX book for management. It will be an IIA Research Foundation publication and I will share details later.

One of the sections in the book covers the risks (and therefore the need for controls over those risks) when reliance is being placed on a key report that uses a data warehouse or business intelligence software. While the book, and therefore this extract, is focused on key controls for SOX, the principles apply whatever the nature of risk being addressed.

When an otherwise manual control includes using a report, that report is often called a ‘key report’ and the control is called a "hybrid control." Why "hybrid"? Because it is part automated (the report) and part manual (the use of the report).

Special attention should be paid when hybrid key controls use reports from a data warehouse, (also referred to sometimes as a data store, repository, or similar). The term “business intelligence” refers to the entire process of extracting data from enterprise applications, storing that data in data warehouses, and analyzing the data and delivering information to the user in the form of reports or on the screen. In addition, such reports may be used in business processes (for example, as a basis for a journal entry to update a reserve account).

Where reliance is being placed, as a form of critical IT functionality, on information from a data warehouse, additional risks may be introduced that require attention from appropriate key controls. Note that the following risks would only be relevant to the extent that they relate to key controls or critical IT functionality (also noting that the latter is not limited to activities of the IT department).

  • Data from the enterprise applications may not be completely downloaded.

  • Errors may be introduced in the downloads, especially when potentially inconsistent data is downloaded from multiple applications and combined in the data warehouse.

  • Downloads may not be current.

  • Access to the data warehouse may not be secure, with a risk that the data is inappropriately changed.

  • Inappropriate changes may be made by individuals with approved access to the data.

  • The data may be defined, such as through the use of data universes, incorrectly. Without getting into technical details, data in the warehouses is described in a universe. Programs that analyze the data use these universes to extract the appropriate data, so if the universe is incorrect, the extract and analysis will be wrong.

  • The programs used to generate the report (or information on screen) may not function as intended (just as enterprise application code may not function as intended) due to deficiencies in the development, maintenance, or security of the programs.

  • Parameters used to run the analysis may be out of date or otherwise incorrect.

In many cases, business intelligence is not owned and operated by IT in the same way as enterprise applications such as general ledger or accounts payable. The analytical routines (programs) are frequently written and maintained by users who may also maintain the data universes and even have the data warehouse on their own servers, outside the direct control of IT. When reviewing the risks and identifying controls related to data warehouses, consideration should be given to:

  • Who owns and operates the data extract? Is it IT (which is more reliable) or the user (generally less reliable)?

  • Who owns and is responsible for the data warehouse? Is it IT?

  • Who developed and maintains the data universe and the programs used for the analysis? Again, is it IT?

  • Are there business process key controls over the integrity of the data used in the analysis? Are they sufficient to identify any error that could lead to a failure of a key hybrid control or result in a material misstatement (such as the posting of an incorrect journal entry for a reserve account)?

  • Are there ITGC that can be relied upon to address risks related to data warehouses?

As a general rule, there is a lower level of risk when IT is responsible for business intelligence. From a design point of view, management should consider putting all aspects of business intelligence (such as maintenance of the data warehouse and reports) that represent a potential risk to financial reporting under IT control.


  1. Is this an area of risk for your organization?
  2. Have you identified the appropriate controls over data warehouses and the creation/maintenance of reports, including business intelligence and analytics?
  3. How involved is IT in securing data warehouses, providing change control over key reports, etc? How much is left to users and is this wise?
  4. Has enough advantage been taken of this technology to replace spreadsheets?


Posted on Feb 18, 2012 by Norman Marks

Share This Article:    

  1. Interesting article.

    Speaking from an SAP standpoint specifically there are a number of ITGC risks unique to the SAP BW environment. We often find that both internal and external audit will exclude the BW system from their scope due to it's 'display only' nature. When they do include it, the focus tends to be on ITGC risks common to the core SAP application (ECC) rather than looking at what's important in BW (e.g. ability to modify extractors, infoprovidors, process chains, transformation rules, etc).

    As this article rightly highlights, when key business decisions and key controls rely on data in the BW environment this changes the importance of BW. Personally I think that warrants a workplan that adequately tests the risks that matter in a BW environment. 

Leave a Reply