Thesis
IPE work is not a contest to create the thickest workpaper. The auditor needs enough evidence to show that the report or population is complete, accurate enough, precise enough, and tied to the audit objective. Extra manual handling can make the evidence trail worse if it introduces undocumented edits, missing rows, changed filters, or broken custody.
For CIA candidates, the best answer balances reliability and efficiency. Preserve the source-system output, document how it was generated, reconcile key control attributes, and avoid unnecessary transformation unless the transformation itself is controlled and reviewed.
Why IPE Matters in ITGC Sampling
Information produced by the entity includes reports, listings, extracts, schedules, and query outputs generated from the organization's systems. In ITGC testing, common examples include:
- active user listings,
- privileged-access reports,
- terminated-user populations,
- change-ticket listings,
- batch-job failure reports,
- security-role mapping exports,
- application configuration reports.
If the auditor uses the listing to select samples, the listing must support the sample population. If the listing is incomplete or altered after extraction, the sample may not represent the real population. That weakens the test even if every selected item is tested perfectly.
Worked Example: VerdanTek Medical Systems
VerdanTek Medical Systems is testing quarterly user-access reviews for its ERP. IT runs a source-system report showing all users with purchasing and payment roles. The report will be used by the audit team to select a sample of users for access review testing.
The evidence package should answer five questions:
- Source: Which system, report, table, or query produced the listing?
- Scope: Which environment, company codes, roles, date range, and filters were used?
- Completeness: How does the row count or control total agree to the delivered file?
- Integrity: Was the file preserved without manual editing after extraction?
- Precision: Does the listing include the fields needed for the audit procedure?
If someone pastes the entire listing into a separate template, the auditor now has a second file that may not equal the source output. Rows can be skipped, hidden, sorted incorrectly, truncated, duplicated, or changed. The better design is usually to preserve the raw export, capture extraction support, and document any needed formatting or transformation separately.
IPE Evidence Is Use-Case Specific
The evidence needed depends on how the information is used.
If the report is only the population for sample selection, the auditor cares about source, scope, completeness, and preservation of the population. The evidence may include the report name, query parameters, extraction timestamp, row count, and read-only source file.
If the report is used by a control owner to perform a review, the control design should include how the control owner validates the report before relying on it. For example, a manager reviewing open purchase-order exceptions may need evidence that the exception report includes all relevant sites and excludes only approved statuses.
If the report is transformed before testing, the transformation becomes part of the audit trail. The auditor should document filters, joins, formulas, deduplication, excluded records, and reviewer signoff.
Controls for Reliable IPE
| Risk | Control response | Evidence to retain |
|---|---|---|
| Wrong report or query used | Approved report name or query reference | Report title, query ID, system owner confirmation |
| Population excludes relevant records | Document scope, filters, and parameters | Filter screenshot, parameter list, date range |
| File changed after extraction | Preserve original export and restrict edits | Read-only file, hash or version history where available |
| Row count mismatch | Reconcile source count to delivered file | Source count, export count, reconciliation note |
| Key field missing | Check precision and detail against audit procedure | Field list, procedure-to-field mapping |
| Manual template creates errors | Avoid unnecessary rekeying or document transformation | Transformation log, reviewer signoff |
| ITGCs do not support reliance | Evaluate access, change, and job controls over the source system | ITGC test results, exception analysis |
Why More Handling Can Reduce Reliability
Manual movement of data may feel like stronger documentation because it creates another workpaper. It can also create a new evidence problem. The auditor must now ask whether the copied file still agrees to the source report.
Common failure modes include:
- hidden rows not copied,
- spreadsheet row limits truncating data,
- formulas converting IDs or dates,
- filters left on during transfer,
- manual deletions to "clean up" the file,
- loss of extraction timestamp or query context,
- no audit trail for who changed the file.
The control objective is not "put everything into the template." The control objective is "make the population reliable for the audit procedure."
Exam Framing
When a CIA question gives you an IPE scenario, ask:
- What is the report used for?
- Which assertion or control objective depends on it?
- What proves the source population is complete and accurate enough?
- Has the data been changed after extraction?
- Are ITGCs and application controls relevant to reliance?
- Is the report precise and detailed enough for the planned test?
The best answer usually preserves the direct source export, documents report-generation evidence, validates completeness and accuracy proportionately, and controls any transformation. The weak answer adds manual handling without explaining how the new file remains tied to the source.