AUD control-framework coverage for COSO, entity-level controls, IT controls, walkthroughs, and control limitations.
This chapter builds the internal-control framework that supports audit planning and later control testing. It is one of the most important routing chapters in AUD because many later decisions depend on whether the control system is understood correctly.
Internal-control questions should separate design, implementation, and operating effectiveness. Understanding a control is not the same as relying on it, and strong control language does not eliminate management override or inherent limitations.
| Control area | First question | Common AUD trap |
|---|---|---|
| COSO framework | Which component or principle explains the control issue? | Memorizing COSO terms without applying them to risk. |
| Entity-level controls | Does governance or tone affect multiple processes and accounts? | Treating entity-level controls as less important because they are broad. |
| ITGCs and application controls | Which technology control supports the application or report output? | Assuming application controls are reliable when ITGCs are weak. |
| Walkthroughs and documentation | Has the auditor understood design and implementation with enough evidence? | Treating inquiry alone as a walkthrough. |
| Limitations and override | What could still fail because of judgment, collusion, override, or cost-benefit limits? | Assuming a designed control eliminates misstatement risk. |
| Step | What to do | Why it matters on AUD |
|---|---|---|
| 1. Identify the risk and control objective | Determine which assertion, process, or reporting risk the control is meant to address. | A control is only meaningful when tied to a specific risk. |
| 2. Place the control in the framework | Classify the issue under COSO, entity-level controls, ITGCs, application controls, or process controls. | Control layers support each other and cannot be evaluated in isolation. |
| 3. Test design and implementation understanding | Use walkthroughs, observation, inspection, and reperformance as appropriate. | Understanding implementation requires more than inquiry. |
| 4. Decide whether reliance is possible | Consider whether design, implementation, and related ITGCs support planned reliance. | The auditor may understand a control without relying on it. |
| 5. Account for limitations and override | Evaluate management override, collusion, judgment, and cost-benefit limitations. | Internal control reduces risk but does not eliminate audit risk. |
| Checkpoint | Exam use | What to avoid |
|---|---|---|
| Control objective | Link the control to a specific assertion, process, account, or reporting risk. | Evaluating control wording without knowing what risk it addresses. |
| Control layer | Classify the control as COSO component, entity-level, ITGC, application, or process-level. | Treating all controls as if they operate at the same level. |
| Design versus implementation | Determine whether the control is suitably designed and whether it has been placed in operation. | Treating inquiry alone as proof that a control works. |
| Reliance decision | Decide whether planned reliance is supported by design, implementation, and related IT controls. | Assuming the auditor relies on a control simply because it is understood. |
| Limitation or override | Consider management override, collusion, judgment, and cost-benefit constraints. | Concluding that a strong control system eliminates audit risk. |