g2-tracking

Information Produced by the Entity (IPE) in Compliance

IPE audit evidence for compliance

IPE, or Information Produced/Provided by the Entity, is a term used in compliance and auditing that regards the actual information used by the auditor in order to assess, test, and draw conclusions about controls, and ultimately, the audit opinion.

There is no clear-cut, oxford-dictionary definition of what constitutes IPE, or IPE audit evidence, and so it becomes a rather subjective item. The simplest way to think about it, is to view it as a type of report that is used to (1) show a listing, (2) show a system configuration, or (3) give insight into a system or process. IPE can either be prepared manually or it can be a system generated report.

Example

Manually generated IPE: A user takes a screenshot within a tool showing the list of users that have access to system X. This screenshot is then manually generated and provided as evidence.

Automatically/systematically generated IPE: Taking the same example as above, if you were to run a SQL query on the same database of users as above, and provide the exported list of users as evidence, this would be a system generated IPE. Important to note here is that there are specific considerations with a system generated query, which we will address and discuss below.

Whether IPE is produced manually, or systematically, there are several considerations that need to be factored in:

  • How can I verify that the listing I am looking at is really from system A?
  • How can I verify that the listing is COMPLETE?
  • How can I verify that the listing is ACCURATE?
  • How can I verify that there are no exclusions in the listing (which may be directly related to C&A above)?

The importance of completeness and accuracy of IPE

Completeness: This ensures that all transactions are included i.e. if the report extract has 10 entries, we need to be able to prove and verify that there were exactly 10 transactions in the report, as it was on the system. No more, no less. This verifies that from a total record perspective, there were no exclusions.

Accuracy: This ensures the correct amount, value, and totals are disclosed in the information. This is not limited to numerical values only, and could include hash values of a text file for example. In a practical example, let’s assume that a report has 10 entries with a value of 2 for each entry. Accuracy would be to verify that the total value of these entries is 20 (10×2).

With the advancement of technology (and how it is able to make our lives faster and better), there are many tools that enable us to generate systematic IPE files that an auditor can have 100% reliance on. 

GET COMPLIANT 90% FASTER WITH AUTOMATION

Three main components of an IPE report

There are three main components of an IPE report that we need to be able to determine and prove:

  1. Source data: When considering this factor, we need to ask “Where did the data come from, originally?” A report that is extracted, but has passed through three other tools or systems before being extracted will not provide the same assurance as a list that comes directly from the source system, to an extract.
  2. Logic of the report itself: This refers to the formula or code used to transform and extract the source code into meaningful information. Report logic can be a standardized tool or query.
  3. Parameters/filters: Imagine we may want to see all users that were added in a certain date range. This would be a specific parameter applied to the data before extraction. It is important to distinguish between filters for relevance and those to conceal certain data elements. If we need to show users are valid in a certain period, and then extract the data, this could be perfect. However, we apply a filter to cover up terminated employees that are still active in a system because we don’t want auditors to see a deviation. This can be a very big problem, and such actions are why it is so important to prove C&A for all IPE.

In summary, whenever any piece of information is needed as audit evidence, both manually provided, and system-generated, it is critical that we can show where the information is coming from, when it was extracted (to prove it is relevant to the audit), what was applied to the data before extraction (filters/manipulation), and we can verify it comes from the source system itself.