IUC & IPE Audit Procedures: What is Required for a SOC Examination?

This blog is being written to address a topic that has been around for a number of years in the SOX world, but is now becoming more relevant in the SOC world of testing. Why, you might ask, is it becoming more relevant in the SOC world? The reason is simple: because when an entity’s SOX control environment has relevant controls that are maintained by a subservice provider, those maintained controls are included in the SOC report that the subservice provider delivers.

It is reasonable to assume that the SOC report testing should be conducted at a level of scrutiny that is comparable to that of required testing in the SOX world, as those relevant controls support the SOX control environment. With this in mind, it is important to understand whether your SOC practitioner is taking the necessary steps to gain comfort with the completeness and accuracy of the IPE and IUC collected.

 

 
Note that IPE and IUC have many titles, and they are at times referred to as the following:

• Electronic Audit Evidence [EAE]
• Key Reports
• Key Spreadsheets
• Information used by the Entity [IUE]

 

What are IPE and IUC?

In order to understand if the SOC reports are addressing IPE and IUC, let’s start with what these terms mean:

• Information “Produced or Provided” by the Entity (IPE) is evidence for the audit that is generated by the entity and used by the auditors to test a control.
• Information Used by the “Company or Entity” (IUC) is evidence that is used by the Company/Entity, in order to perform or execute their internal controls.

There is a subtle difference between the two terms, but it is important to understand the difference. For IUC, the entity should have checks or controls in place to be confident that the information is complete and accurate. While for IPE, the practitioner (auditor) should have checks in place to be confident that the information is complete and accurate.

The guidance around the testing of IPE/IUC has been drafted and superseded by the PCAOB and the AICPA multiple times over the past decades.  The guidance has become more relevant with the increased usage of information technology systems, and these information technology systems are used for generating populations for control testing, and for other supporting control evidence for testing, as well as executing controls.

PCAOB Standards for IPE/IUC Documentation

The PCAOB Audit Standard (AS) 15.10 states that:

“When using information produced by the entity as audit evidence, the auditor should evaluate whether the information is sufficient and appropriate for purpose of the audit by performing procedures to:

• test the accuracy and completeness of the information, or test the controls over the accuracy and completeness of the information; 
• Evaluate whether the information is sufficiently precise and detailed for purposes of the audit.”

 

AICPA Standards for IPE/IUC Documentation

The AICPA Attestation Standards (official standards noted below – applicable to SOC 1 and SOC 2 examinations) states that IPE and IUC procedures are a matter of professional skepticism and professional judgment on behalf of the practitioner performing the audit:

“Professional Skepticism and Professional Judgment  

.A66 Professional skepticism includes being alert to matters such as the following:  

• Evidence that contradicts other evidence obtained
• Information that brings into question the reliability of documents and responses to inquiries to be used as evidence
• Circumstances that may indicate fraud
• Circumstances that suggest the need for procedures in addition to those required by relevant AT-C sections

.A67 Professional skepticism is necessary to the critical assessment of evidence. This includes questioning contradictory evidence and the reliability of documents and responses to inquiries and other information obtained from the appropriate party. It also includes consideration of the sufficiency and appropriateness of evidence obtained in light of the circumstances.   

.A68 The practitioner neither assumes that the appropriate party is dishonest nor assumes unquestioned honesty. The practitioner cannot be expected to disregard past experience of the honesty and integrity of those who provide evidence. Nevertheless, a belief that those who provide evidence are honest and have integrity does not relieve the practitioner of the need to maintain professional skepticism or allow the practitioner to be satisfied with less than sufficient appropriate evidence for the service being provided.  

Professional Judgment (Ref: par. .45) 

.A69 Professional judgment is essential to the proper conduct of an attestation engagement. This is because interpretation of relevant ethical requirements and relevant AT-C sections and the informed decisions required throughout the engagement cannot be made without the application of relevant knowledge and experience to the facts and circumstances.  

.A70 For examination and review engagements, professional judgment is necessary regarding decisions about the following matters:  

• Materiality and attestation risk
• The nature, timing, and extent of procedures used to meet the requirements of relevant AT-C sections and gather evidence
• Evaluating whether sufficient appropriate evidence for the service being provided has been obtained and whether more needs to be done to achieve the objectives of this section, section 205, or section 210, and any relevant subject-matter-specific AT-C”

With the differences in requirements between the PCAOB and the AICPA, it becomes evident that there is room for interpretation regarding how far the practitioner’s detailed test procedures need to go in order to test the IPE and IUC.

Information produced by the entity and information used in controls often comes in the form of a report. The reports might be system-generated, manually prepared, or a combination of both (download of system accumulated data entered manually into an excel spreadsheet). An entity could spend a lot of time and money if they attempted to address the completeness and accuracy of all their IPE and IUC in their control environments. To avoid spending too much time or money on this area, an entity will typically focus most on the relevant controls that support their requirements for SOX and SOC compliance.

 

What are Relevant Controls?

Relevant controls are the necessary controls to meet the examination objectives and requirements. Some practitioners refer to relevant controls as “key” controls. An entity may have hundreds of controls. Each control is important in its own way with the risk it was created to mitigate, and each is important for the operations and financial activities of the business.

However, when determining relevant controls, consideration regarding which controls may be parsed down for focus upon will need to be considered. An entity should start its IPE and IUC analysis by focusing on the controls that the entity determined were to be tested by regulatory agencies or compliance practitioners for the purpose of meeting the examination requirements. These controls may be deemed the relevant controls for the audits, as well as the IPE and IUC initial considerations.

An entity is able to begin to identify their IUC populations by identifying their relevant controls, and listing out exactly what the documents are that are used to execute or perform those controls.  This information includes any supporting documents that the control is dependent upon. Note that the supporting documentation that could change the outcome of the control operation is necessary to be tested for IPE/IUC considerations, as this is information that the control is dependent upon.  This supporting document mapping by relevant control will ultimately turn into the entity’s initial list of IUC.

 

First Steps to Test Completeness and Accuracy of IPE / IUC

When the initial list of an entity’s IUC is considered relatively complete, then the next step includes sitting down with the control owners who execute/perform the controls to gather additional information.  Obtaining this understanding will assist the practitioner to determine what steps are taken by the control performer to ascertain that the documents their controls are dependent upon are complete and accurate.

The entity should consider documenting those steps to be memorialized into the IUC population document. The information is then provided to the examination practitioners, if and when questions arise. When the practitioner tests the relevant controls, the entity will likely be asked to provide the steps taken to document the completeness and accuracy of the documents the controls are dependent upon (IUC).

The practitioner will also obtain IPE in order to test an entity’s internal controls.  IPE is the responsibility of the practitioner (with assistance from the entity) to test and determine appropriate procedures to obtain comfort over the accuracy and completeness of the IPE, as IPE is information that is used to support control testing, not control performers.

Examples of IPE include (note this listing is not all-inclusive):

• Listing of Newly Hired employees and contractors over a specified period of time
• Listing of all employees
• Listing of terminated employees and contractors over a specified period of time
• Listing of all changes to the relevant systems (operating system, database, application, network devices)
• Listing of administrative users in relevant systems (operation systems, database, application)
• Listing of users who can implement changes into production
• Listing of systems inventories
• Authentication configuration evidence for relevant systems

To create procedures to test the accuracy and completeness of IPE and IUC a practitioner needs to understand the IPE in detail. A practitioner would need to understand what the IPE/IUC is, how the IPE/IUC was generated, and how it is used to support the control dependent upon it, or of the related audit test. For example, a practitioner would need to understand if the IPE/IUC was system generated and if so, what the source data was and where the source data comes from (what database or system), the report logic used to generate the report, and the parameters used to pull the IPE/IUC.

 

IPE / IUC Controls – Source Data, Report Logic, and Parameters

IPE that is system generated is reliant on the accuracy and completeness of the source data, the report logic (how the report logic was initially created and what happens when modifications are made to that report logic), and parameters (when the data has set parameters that only display certain relevant pieces).

• Source data: The source data is the underlying information that the IPE/IUC is created from, usually would include data from an IT system (for example: a list of widget sales in the past 6 months, the source data is the database of all widget sales).
• Report logic: The report logic is the computer code, algorithms, or formulas for transforming, extracting, or loading relevant source data and creating reports.  Report logic may include standardized report programs, user-operated tools (query tools and report writers), or excel spreadsheets.
• Parameters: Parameters allow users to look at only the information that is of interest to them.  Common uses of report parameters include defining the report structure, specifying or filtering data in a report, or connecting related reports (data or output) together.

IPE/IUC that is not system generated will also still require testing for completeness and accuracy, and appropriate procedures and focus areas will need to be determined by the client and the practitioner in each individual case.

 

What is an IUC / IPE Audit?

There is not an IUC/IPE-specific audit; rather there are procedures performed when testing relevant controls that include test steps developed to understand that the IUC and/or IPE are complete and accurate.

It is important that IUC and IPE are complete and accurate when a control is dependent upon them.  This is important because otherwise, it can result in a number of inaccuracies related to the control execution.

Some of the possible IUC/IPE considerations that testing should be designed to include are:

• All data is captured.
• Report logic is correct.
• The report logic and/or source data can not be changed inappropriately or without authorization.
• The parameters are correctly applied.

The next few paragraphs help to provide some examples of test procedures that may be performed as IPE/IUC testing steps and considerations while conducting a compliance audit.

IPE Control Testing Example

Example Entity Control: Changes made to “Application XYZ” are approved via a change management ticket prior to being released into the production environment.

Consideration of IPE: In order to test that changes to the production Application XYZ environment were approved prior to being implemented, a practitioner will need to obtain the full population of Application XYZ changes. This XYZ change population to be obtained is the “Information Produced by the Entity” (IPE) that will support the practitioner to test the control. When the entity provides the practitioner with the listing (population) of Application XYZ changes, the practitioner will need to perform procedures over the listing to ascertain that it is reasonable to believe that that population provided is complete and accurate.

The practitioner will strive to understand the following:

• The change population listing is complete.
  • It includes all relevant changes made to Application XYZ during the time frame requested.
• The change population listing is accurate.
  • The listed changes included in the report are the accurate details relevant to the changes performed (who, what, when, where, why).

The Practitioner will strive to address whether the IPE is sufficiently precise and detailed for their testing purpose. For example, imagine if the Entity’s control owner provided the IPE change population in a word document format and it had 3 manually added Application XYZ changes during the requested time frame and no other supporting detail.  The practitioner would need to consider whether that format of evidence is sufficient.

A few reasons that a practitioner who is exercising professional skepticism and professional judgment regarding this evidence described may not consider it sufficient to test the control are as follows:

• The change population was not systematically generated from the Application XYZ.
• The change population may not include all changes, as the list was manually prepared and changes may have been missed.
• The changes do not include any other supporting details.

The practitioner may require management to modify the IPE provided, or to identify an alternative source or format for the information to be provided. An example of this could include a program change population directly obtained from the source code library or output from a code management tool or system.

 

IUC Control Testing Example

Example Control: Annually, user access reviews are performed over users and their roles that maintain access to Application XYZ.

Considerations of IUC: In order for the entity’s control owner to execute the control, and for them to feel confident signing off on the appropriateness of the users and the roles they are assigned in Application XYZ, IUC will be required. The control owner should strive to create a system-generated listing from Application XYZ that includes each user and the roles assigned to each user, as the starting point for their review. This user listing should be considered IUC supporting this control, as the control is dependent upon that listing being complete and accurate for the control owner to execute the access review.

The entity’s control owner will need to demonstrate that they considered and took the necessary steps to ascertain that the user access report they utilized to execute the control was complete and accurate. The entity’s control owner should consider documenting the steps they took to ascertain that the report completely included every user with access in the application, and it accurately and completely listed all the roles assigned to each of those users.

Some examples of how the entity’s control owner could validate the IUC includes:

1. Completeness: Developing an expectation of known users with access to Application XYZ and inspecting the listing to see that the known users were included/displayed in the report.
2. Accuracy: Tie out the roles assigned to a user in the report directly back to the source system to make sure the report generated properly.
3. Completeness & Accuracy: Develop their understanding of how the report was generated, and if any parameters were utilized.
4. Completeness & Accuracy: Develop their understanding of how the report logic is updated, and whether its updates follow the SDLC or change management processes.

 

Evidence of Completeness and Accuracy in Compliance Reports

To fully understand and test relevant controls during a compliance report examination, it is important that practitioners don’t get caught in a slippery slope of over-scoping and over-testing the IUC and IPE. It is also important that the practitioners take the steps necessary to understand the controls that are relevant to their procedures, and whether those controls are dependent upon IPE or IUC. After that determination is made is when an auditor will be able to effectively conclude on the design appropriateness and operating effectiveness of the control with each of the important considerations necessary to do so.

A SOC practitioner must use their professional skepticism and professional judgment to address IUC and IPE considerations over the entire examination, and for each piece of evidence, they inspect and utilize to support their control procedures. With these control steps in place and in mind, a SOX audit with SOC report relevance is appropriately addressed, as expected, by the users of the SOC report.

If you have IPE or IUC consideration questions or are interested in how IPE / IUC is being considered for your upcoming SOC reports or any other needed audit services, reach out to Rhonda Willert and the team at Linford & Co for a riveting discussion on the matter!!