Practical guide
How to evaluate internal controls with AI
Evaluating a control requires two different judgments. First, is the control designed to address the stated risk? Second, did it operate as described during the period tested? AI can organize evidence and flag inconsistencies, but it should not collapse those judgments into one confidence score. The output should be a control assessment with a traceable risk, design conclusion,.
Evaluating a control requires two different judgments. First, is the control designed to address the stated risk? Second, did it operate as described during the period tested? AI can organize evidence and flag inconsistencies, but it should not collapse those judgments into one confidence score. The output should be a control assessment with a traceable risk, design conclusion, operating-evidence conclusion, exceptions, and follow-up action.
Map the control to one risk and objective
Write the objective, risk, control activity, owner, frequency, and retained evidence in separate fields. For example:
| Element | Synthetic example | | --- | --- | | Objective | Vendor bank-detail changes are authorized before payment | | Risk | An unauthorized change redirects funds | | Control | A finance manager verifies changes through an approved callback and records approval | | Frequency | Every change | | Evidence | Request, callback record, approval, system audit event |
Ask AI to identify missing links: Does the control address the risk before the payment can occur? Does the owner have suitable authority? Would the retained evidence show who performed the check and when? These are prompts for investigation, not automatic conclusions.
The U.S. Government Accountability Office’s Green Book describes internal control through five components and related principles for the U.S. federal context. It can provide a conceptual reference, but it is not a universal rulebook for every company, jurisdiction, or audit engagement.
The Institute of Internal Auditors’ current standards are a separate professional reference for internal-audit work. They organize requirements, implementation considerations, and examples of evidence of conformance. An organization still needs to identify which framework and engagement requirements apply before using either source.
Assess design without using test results
A design assessment asks whether the documented control, if performed as intended, could reduce the specified risk to the organization’s accepted level. Walk through one transaction from initiation to completion. Look for gaps in timing, authority, segregation, information quality, and exception handling.
In the example, a callback after payment would be poorly timed even if staff performed it consistently. A callback to the phone number supplied in the change request may not provide independent verification. Those are design issues. More samples do not repair them.
Record the design conclusion and rationale before testing operation. This prevents a clean sample from disguising an ineffective design.
Test operation with explicit evidence
Define the population, period, selection method, sample, expected attributes, and exception rule. AI can reconcile lists, extract dates, and compare records, but the tester verifies source completeness and reviews every exception.
For a synthetic population of 64 bank-detail changes, suppose 12 are selected across the quarter. Eleven contain a request, independent callback record, manager approval, and audit event. One has approval dated after the first payment using the new details. The exception is not “missing paperwork”; it shows the control did not operate before the risk event for that item.
Do not ask AI to label the control effective based on an exception rate. The conclusion depends on the control’s importance, the sampling approach, the nature and cause of the exception, compensating controls, and the applicable assurance standard.
Keep four evidence layers
Maintain the process description, design walkthrough, operating test, and conclusion as linked but separate artifacts. For each AI-assisted extraction, retain the original source location and reviewer disposition. Generated summaries cannot replace invoices, approvals, logs, or interview records.
A useful exception log contains the sample ID, expected attribute, observed evidence, risk implication, owner response, follow-up evidence, and final disposition. Similar-looking exceptions may have different causes, so group them only after review.
Verification checklist
Before closing the assessment, confirm that:
The most important discipline is not the volume of testing. It is preserving the chain from risk to design, from sample to evidence, and from exception to conclusion.
- the objective and risk are specific enough to test;
- the control description states who does what, when, using which information;
- design evidence and operating evidence have separate conclusions;
- the population and period are complete and defined;
- the selection method and test attributes are reproducible;
- every exception is traced to source evidence and its risk implication;
- AI-extracted fields were checked against originals;
- the final conclusion follows the organization’s applicable framework and review process.
Sources and claim map
The worked population and all transaction details are synthetic. This educational resource is not an audit opinion, legal conclusion, or substitute for an organization’s applicable professional standards.
- U.S. Government Accountability Office, Standards for Internal Control in the Federal Government: supports the description of the Green Book’s federal scope and its five-component internal-control framework.
- The Institute of Internal Auditors, Global Internal Audit Standards: supports the description of the current professional internal-audit standards and their evidence-of-conformance structure.
Sources: [1] [2]
Sources
- 1.Standards for Internal Control in the Federal Government · U.S. Government Accountability Office
- 2.Global Internal Audit Standards · www.theiia.org