Modify procedures for IT environments, computer-assisted techniques, sampling, and use of others.
IT, sampling, and use of others are not side topics. They change the work plan when systems generate records, populations are too large for item-by-item testing, expertise is specialized, or findings show that the original procedure no longer answers the risk.
The practical task is to identify the evidence dependency, explain the risk created by that dependency, and modify procedures specifically enough that the revised work can support the conclusion.
This lesson focuses on how to:
The IT environment affects assurance work when records, controls, reports, or the audit trail depend on automated processing. A procedure that would be persuasive in a manual system may be weak if the underlying report can be changed, filtered, or produced from incomplete data.
| IT condition | Assurance risk | Procedure response |
|---|---|---|
| Automated processing of transactions | Errors may repeat consistently across a large population. | Test relevant automated controls and perform data-based exception searches across the full population where feasible. |
| User access and segregation-of-duties weaknesses | Unauthorized changes may occur without visible manual approval. | Inspect access listings, test privileged-user activity, and consider whether reliance on related controls is reduced. |
| System-generated reports | The report may be incomplete, inaccurate, or filtered in a way that affects testing. | Test report logic, parameters, source data, and reconciliation to the general ledger or subledger. |
| New system, data conversion, or major upgrade | Opening data, mapping, and interfaces may not transfer correctly. | Test conversion reconciliations, interface controls, exception logs, and post-implementation adjustments. |
| Outsourced processing or hosted application | Evidence may sit with a service provider rather than the entity. | Obtain and evaluate service auditor reports where relevant, and bridge any period or control gaps with direct procedures. |
| Cybersecurity incident or unusual system activity | Integrity of records may be impaired. | Increase procedures over affected accounts, inspect incident logs, and evaluate whether management’s remediation is sufficient. |
The key is to connect the system fact to evidence reliability. If the practitioner relies on a report, the report must be complete and accurate for the purpose. If a control is automated, the supporting IT general controls matter.
Computer-assisted techniques are useful when the risk sits in patterns, exceptions, recalculations, or large data sets. The case response should identify the data source, completeness check, test logic, and exception follow-up.
| Use case | Why it helps | Caution |
|---|---|---|
| Full-population transaction scan | Finds unusual items that a small sample may miss. | Data completeness and field definitions must be tested first. |
| Duplicate or exception search | Targets fraud, error, duplicate payments, duplicate invoices, or override indicators. | Exception criteria must match the risk; broad searches can produce false positives. |
| Recalculation | Tests mathematical accuracy of interest, depreciation, commissions, tax, or inventory costing. | The formula must reflect the applicable policy or criterion, not an assumed textbook rule. |
| Stratification | Directs attention to high-value or high-risk items while still addressing the rest of the population. | High-value testing does not automatically cover low-value systematic errors. |
| Trend or outlier analysis | Identifies unexpected relationships, spikes, gaps, or unusual timing. | Analytical findings require follow-up evidence before they support a conclusion. |
| Log review | Helps detect privileged access, overrides, failed logins, or unusual processing times. | Logs may be incomplete or overwritten if retention controls are weak. |
Data analysis is not a conclusion by itself. Exceptions must be investigated, and clean results are meaningful only if the population and report logic were reliable.
Sampling is a design choice, not a default. The sample must match the objective. A sample designed to test control operation does not automatically support a substantive conclusion, and a sample from the wrong population may be useless even if the arithmetic is correct.
| Decision | What to consider |
|---|---|
| Population definition | The population must include the items relevant to the assertion or criterion and exclude unrelated items. |
| Sampling unit | The unit may be an invoice, transaction, customer, control occurrence, day, batch, or dollar unit. |
| Objective | The procedure may test control operation, existence, accuracy, completeness, valuation, compliance, or another criterion. |
| Risk and tolerable exception | Higher risk or lower tolerable exception usually requires more persuasive work. |
| Selection method | Random, systematic, haphazard, targeted, and dollar-unit methods serve different objectives. |
| Sample size and extent | Extent should respond to risk, expected exceptions, population characteristics, and assurance level. |
| Evaluating exceptions | Determine whether exceptions are isolated, systematic, projected, corrected, or indicative of fraud or control failure. |
The most common sampling error is defining the population incorrectly. For completeness testing, the population should often start outside the accounting records. For occurrence testing, the population may start with recorded items.
Using others can improve evidence, but it does not remove the engagement team’s responsibility for the conclusion. The practitioner must evaluate whether the work is relevant, reliable, and sufficient for the objective.
| Other party | Before relying | How to use the work |
|---|---|---|
| Specialist | Assess competence, capabilities, objectivity, scope, assumptions, and methods. | Use the specialist’s work for the specialized estimate or measurement, while evaluating whether assumptions fit the engagement criteria. |
| Internal audit | Assess objectivity, competence, systematic approach, and whether the work addresses the risk. | Use selected work only when appropriate, and still perform enough engagement-team review and testing. |
| External auditor of a related entity | Understand scope, materiality, timing, and reporting limitations. | Use the work only for the component, investee, or related entity area it actually covers. |
| Service-provider auditor | Read the report type, period covered, tested controls, exceptions, and complementary user-entity controls. | Bridge period gaps and test user-entity controls before relying on the service-provider control environment. |
Reliance should be scoped. If a specialist’s work supports an impairment valuation, it does not automatically support revenue recognition. If a service-provider report covers only nine months, the remaining period still needs attention.
The exam often gives a planned procedure and then adds a fact that makes the procedure inadequate. The response should name the trigger and provide the revised work.
| Trigger | Modification |
|---|---|
| Ineffective controls | Reduce reliance, increase substantive procedures, and consider reporting control deficiencies. |
| High exception rate | Expand testing, investigate cause, project or evaluate misstatement, and reconsider risk assessment. |
| Fraud indicators | Preserve evidence, involve appropriate senior team members, extend unpredictable procedures, and evaluate communication obligations. |
| System change | Test conversion, interface, access, and report reliability before relying on system outputs. |
| Unreliable report | Reconcile report totals, test query logic, inspect source records, or obtain evidence from an independent source. |
| Specialist limitation | Obtain additional specialist work, perform alternative procedures, or evaluate whether scope limitation affects the conclusion. |
Avoid writing “perform more testing” as a conclusion. Identify what changes: control reliance, sample extent, procedure nature, timing, specialist involvement, or communication to management and governance.
| Step | Question | Output |
|---|---|---|
| 1. Dependency | What does the work rely on? | System, report, population, sample, specialist, internal audit, related entity, or service provider. |
| 2. Risk | Why might that dependency weaken evidence? | Reliability, scope, access, competence, objectivity, population, or exception issue. |
| 3. Procedure change | What specific work should change? | Revised nature, timing, extent, or evidence source. |
| 4. Evaluation | What would the results mean? | Effect on reliance, exception evaluation, or conclusion. |
| 5. Communication | Who needs to know if the issue is significant? | Management, governance, user, or report implication. |
Use this framework when a case provides an IT note, report extract, sampling issue, service organization fact, specialist limitation, internal audit work paper, or unexpected exception.
| Pitfall | Correction |
|---|---|
| Using a system-generated report without testing report reliability. | Test completeness, accuracy, parameters, and reconciliation before relying on the output. |
| Sampling from the wrong population. | Define the population from the assertion or criterion before choosing the sample. |
| Treating internal audit work as a substitute for engagement-team judgment. | Assess objectivity, competence, scope, and the need for direct review or reperformance. |
| Ignoring exceptions because they are small individually. | Evaluate whether exceptions are systematic, projected, fraud-related, or relevant to control reliance. |
| Accepting specialist conclusions without understanding assumptions. | Evaluate the specialist’s assumptions, methods, source data, and fit with the engagement criteria. |