Every ICFR audit comes down to one question: does the evidence support the conclusion? That sounds simple, but PCAOB inspection findings have identified recurring deficiencies in selecting controls that address assessed risks, testing management review controls, and testing controls over system-generated data and reports.
In this article, I will break down what auditors actually need to test, how to test it, and what documentation needs to look like to support the audit conclusion and review.
What Is an ICFR Audit?
An ICFR audit is an independent audit of the effectiveness of a company's internal control over financial reporting. Under PCAOB AS 2201, the ICFR audit is integrated with the financial statement audit, although the two audits have different objectives. The auditor evaluates whether selected controls are suitably designed and operating effectively, using sufficient appropriate evidence to support the overall ICFR opinion.
What Do Auditors Need to Test in an ICFR Audit?
At a high level, every control test should address several core elements. Missing one can create a documentation gap that a reviewer may need to resolve.
Element | What It Establishes |
Financial reporting risk | The specific way a misstatement could occur |
Relevant assertion | Completeness, accuracy, existence, valuation, or presentation |
Control design | Whether the control could prevent or detect the risk if it operated as intended |
Operating effectiveness | Whether the control actually functioned throughout the period |
Control performer | Who executed the control and whether they had appropriate authority |
Evidence | What supports the conclusion that the control operated |
Exceptions | Any deviations identified and how they were resolved |
PCAOB AS 2201 directs auditors to use a top-down, risk-based approach when identifying significant accounts, relevant assertions, and controls to test. The auditor's testing should focus on controls important to the conclusion rather than every control in the RCM.
1. Financial Reporting Risks and Relevant Assertions
Every control test starts with a chain: risk → account/disclosure → assertion → control. If you cannot trace a control back to a specific risk and assertion, you may be testing it simply because it appears in the risk control matrix (RCM), not because it matters to your conclusion.
For example, if the risk is that revenue is recorded before delivery, the relevant assertion may be cutoff, depending on the specific risk and the financial reporting framework. The control needs to directly address that risk, not just relate to revenue in general.
Auditor Tip: Use a Risk-to-Control Traceability Check
Before testing, write one sentence: "This control is important because it addresses [risk] for [assertion] and is necessary to support our ICFR conclusion." If you cannot complete that sentence clearly, reconsider whether the control belongs in your testing plan.
2. Key Controls Selected for Testing
You do not need to test every control in the RCM. AS 2201 does not require testing all controls related to an assertion, and redundant controls generally do not need separate testing unless the redundancy itself serves a control objective. Auditors should select controls that are important to the conclusion about whether the assessed risks are sufficiently addressed.
How Auditors Identify Key Controls
Evaluate each control against these factors:
Risk coverage: Does it sufficiently address the assessed risk?
Precision: Is the control designed at a level appropriate to the risk it addresses?
Frequency: How often does it operate?
Dependencies: Does it rely on other controls or information?
Manual vs. automated: Does the nature of the control affect the testing approach?
Entity-level vs. process-level: Could entity-level controls affect the nature, timing, or extent of testing of other controls?
A Simple Key-Control Selection Test
Ask whether excluding the control from testing would leave a gap in your ability to conclude on the relevant assertion. If the answer is no, it may be a supporting or redundant control rather than a control that needs separate testing.
3. Control Design Effectiveness
Design effectiveness testing asks whether the control, if operated as designed, could prevent or detect a misstatement that could result in a material misstatement. This assessment comes before determining the extent of operating-effectiveness testing.
What Auditors Should Examine
Control objective
Risk addressed
Frequency of operation
Control owner and their authority
Precision of the control
Criteria used during review
Escalation procedures for exceptions
Evidence the control generates
Auditor Tip: Test Design Before Sampling
Testing the operation of a control that is not suitably designed will not address the underlying design deficiency. Confirm that the control is capable of addressing the identified risk before proceeding with operating-effectiveness testing.
4. Control Operating Effectiveness
Operating-effectiveness testing establishes whether the selected control operated as designed and whether the person performing the control possessed the necessary authority and competence. The nature, timing, and extent of testing should reflect the risk associated with the control.
Four Common ICFR Control Testing Methods
Inquiry: Asking the control owner how the control operates
Observation: Watching the control being performed
Inspection: Reviewing documentation related to the control
Reperformance: Independently executing the control procedure
Important Distinction
"The control exists" does not mean "the control operated effectively." Inquiry alone is not sufficient evidence to support a conclusion about the effectiveness of a control. The appropriate combination of procedures depends on the nature and risk of the control.
5. Management Review Controls
Management review controls (MRCs) require particular attention because the auditor needs to understand not only whether the review occurred but also the nature and precision of the review.
What Auditors Should Test in a Management Review Control
What was reviewed
What criteria the reviewer used
The precision of the review
What threshold triggered further investigation
What exceptions were identified
How exceptions were resolved
What evidence shows the review actually occurred
Auditor Tip: Don't Just Test the Signature
A signed-off report shows evidence of approval, but the auditor also needs to evaluate how the reviewer performed the review and whether the review was sufficiently precise to address the relevant risk. Ask the control owner to walk through exactly how they determine that something requires investigation before requesting sample evidence.
6. Information Produced by the Entity (IPE)
IPE refers to information produced by the company, such as system-generated reports, spreadsheets, data extracts, or calculations, that a control relies on. If the information is inaccurate or incomplete, the auditor may not be able to rely on it as evidence for evaluating the control.
When IPE Testing Is Necessary
IPE considerations apply whenever a control uses:
System-generated reports
Exception reports
Spreadsheets
Reconciliations
Data extracts
Dashboards
Automated calculations
What Auditors Should Validate
Work through this sequence: accuracy → completeness → source → parameters → period → population. Confirm where the information comes from, what population it includes, what parameters generated it, and whether the information is sufficiently precise and detailed for the audit purpose. Auditors can test the information directly or test controls over its accuracy and completeness.
Auditor Tip: Add an IPE Checkpoint to Every Control Test
Add a simple flag to every control workpaper: does this control use company-produced information? If yes, determine how its accuracy and completeness will be evaluated before relying on the control evidence.
7. IT General Controls and Automated Controls
Manual Controls vs. Automated Controls
Manual controls depend on activities performed by people, while automated controls execute according to programmed logic. Automated controls may depend on relevant IT general controls, including controls over program changes and access, remaining effective.
Benchmarking Automated Controls
Where relevant IT general controls remain effective and the automated control has not changed since the established baseline, auditors may be able to conclude that the automated application control continues to operate effectively without repeating the prior year's specific operating test. The auditor should consider changes to the application, related files, tables, data, and parameters on which the control depends.
8. Sampling and Testing Extent
Sample size decisions should consider the objective of the control test, the expected rate of deviations, the maximum deviation rate the auditor can accept, the allowable risk of assessing control risk too low, and the characteristics of the population. Sample sizes should not simply be copied from the prior year because the population, control, and risk factors can change.
Sampling does not apply to every control. It generally may not apply to tests that depend primarily on segregation of duties or controls that do not provide documentary evidence of performance. Before building a sample, confirm that the audit objective actually involves estimating a deviation rate.
9. What Auditors Need to Document in an ICFR Audit
PCAOB AS 1215 requires documentation to clearly support the purpose, procedures performed, evidence obtained, and conclusions reached. It also requires enough information for an experienced auditor with no previous connection to the engagement to understand the nature, timing, extent, and results of the work performed.
At minimum, document:
Purpose and objective of the test
Risk and relevant assertion addressed
Control description
Nature, timing, and extent of testing performed
Evidence obtained
Testing results
Deviations or exceptions identified
Conclusion reached
Performer and reviewer information
10. What a Strong ICFR Control Testing Workpaper Looks Like
A strong workpaper follows a consistent structure: risk → assertion → control → population → procedure → evidence → exception → conclusion.
For example:
Risk: Revenue recorded before delivery
Assertion: Cutoff
Control: Controller reviews period-end revenue transactions against defined revenue-recognition criteria
Population: Period-end revenue review instances
Procedure: Inspected evidence of the review and reperformed selected review procedures
Evidence: Review documentation and underlying transaction detail
Exception: None identified / [description of exception]
Conclusion: Control operated effectively for the period tested
A reviewer-ready workpaper does not require reconstructing the audit from screenshots, email chains, or unexplained tick marks. The documentation should make the procedures performed, evidence obtained, results, and conclusion understandable to an experienced auditor.
How Auditors Can Reduce ICFR Testing Rework
Start With Evidence Sufficiency
Before assigning samples, check whether the evidence shows who performed the control, when it was performed, what population was reviewed, what exceptions were found, and how they were resolved. Classify evidence as ready, incomplete, ambiguous, or incorrect before testing begins.
Use Risk-to-Control Traceability
Map each relevant assertion to its key controls and the evidence expected. This keeps testing focused on controls that matter to the conclusion, rather than every control listed in the RCM.
Flag IPE Dependencies Early
Identify which controls depend on system-generated data before fieldwork starts. Evaluate the accuracy and completeness of the information, or the controls over it, and consider whether it is sufficiently precise and detailed for the audit purpose.
Standardize Workpaper Structure
Apply a consistent objective → risk → population → sample → procedure → evidence → exception → conclusion format across control tests. A consistent structure makes it easier for reviewers to understand the work performed, evidence obtained, and conclusions reached.
How Roz Supports ICFR Control Testing
Roz is an AI-native audit fieldwork and control-testing platform built for auditors and audit teams. It does not replace auditor judgment. It accelerates the repetitive first pass of control testing so auditors can focus on review and conclusions.
Client-specific evidence workspace: Organize controls, evidence, and engagement documentation in an isolated client workspace.
AI-assisted control testing: Run defined or AI-suggested attribute checks against relevant evidence and sample sets.
Evidence-to-control mapping: Connect supporting evidence to the relevant controls and testing criteria.
Potential exception identification: Surface potential exceptions or insufficient evidence for auditor investigation and review.
Traceable workpapers: Export completed control activities as formatted workpapers with supporting evidence, annotations, and audit trails.
Human review and auditor judgment: Auditors verify results, investigate exceptions, and can rerun or override tests where appropriate.
Conclusion
ICFR testing is not a one-time checklist exercise. It requires a consistent discipline: trace controls back to specific risks and assertions, separate design testing from operating effectiveness testing, evaluate the data controls depend on, and document conclusions so a reviewer can follow the work without reconstruction. Auditors who build these habits into their process can reduce rework and produce documentation that supports inspection readiness.
Frequently Asked Questions
Do auditors need to test every ICFR control?
No. AS 2201 does not require testing every control related to an assertion, and redundant controls generally do not need separate testing unless the redundancy itself serves a distinct control objective. Auditors should focus testing on the controls necessary to support their conclusion.
How are management review controls tested?
Auditors need to test more than whether a review took place. Effective testing establishes what was reviewed, what criteria the reviewer applied, what triggered investigation, what exceptions were found, and how those exceptions were resolved, supported by evidence of the review.
What is IPE in an ICFR audit?
IPE, or information produced by the entity, refers to system-generated reports, spreadsheets, data extracts, or calculations that a control relies on. Auditors need to evaluate its accuracy and completeness, or the controls over that information, before relying on it.
