ACCT6007 Chap.5 Internal Control and IT Controls
Internal Control and IT Controls
This chapter treats internal control as an interconnected system and distinguishes design, implementation and operating effectiveness. It maps control environment, risk assessment, information, control activities and monitoring to financial-report risks.
The IT section separates general controls over access, change and operations from application controls over transaction input, processing and output, then links both to audit reliance. Design asks whether a control could address the risk, implementation asks whether it has been placed into use, and operating effectiveness asks whether it functioned consistently with appropriate follow-up.
Enquiry is combined with observation, inspection or reperformance. A walkthrough connects the documented process to actual transaction flow. General IT controls support reliable applications by restricting access, governing changes and maintaining operations. Application controls validate inputs, processing and outputs, but their reliability can be undermined when administrators can alter logic or source data without review.
Control limitations include human error, collusion, override and changing conditions. If a strategy relies on a control, the auditor tests operation. Failure leads to investigation, revised control risk and changed substantive work, not an automatic conclusion that the financial report is misstated. Entity-level controls shape the environment but do not substitute for a precise transaction control when reliance is planned.
A walkthrough can reveal interfaces, override points, exception queues and manual steps hidden by a process diagram. Input validation, sequence checks and reconciliations address different failure modes. Exception reports matter only when someone reviews and resolves them. A compensating control must address the same risk with enough precision and timeliness.
The response explains what was tested, which deviations appeared and how the substantive approach changes.
What this chapter covers
- 01
Control components
- 02
Design and implementation
- 03
Operating effectiveness
- 04
General IT controls
- 05
Application controls
- 06
Control testing and exceptions
Worked example · free
Test supplier access segregation
- 1Identify fictitious suppliers and unauthorised payments as the risk.
- 1Separate supplier maintenance, approval and payment release.
- 1Inspect role permissions and sample master-data changes for approval.
- 1Evaluate incompatible access and exception follow-up.
Key terms
- Control environment
- The governance, integrity and accountability context supporting internal control.
- Control activity
- A policy or procedure designed to address a risk.
- Walkthrough
- Tracing a transaction through a process to understand controls and implementation.
- General IT control
- A control over access, change or operations supporting applications.
- Application control
- An automated or manual control within transaction processing.
- Operating effectiveness
- Whether a control functioned consistently as designed during the period.
Internal Control and IT Controls FAQ
How does design differ from operating effectiveness?
Design asks whether a control could prevent, detect or correct the intended error. Implementation asks whether it was placed into use. Operating effectiveness asks whether it functioned consistently, by appropriate people, with exceptions followed up during the period.
Are automated controls always reliable?
No. Reliability depends on correct application logic, source data and the general IT controls protecting access, changes and operations. An automated report can be wrong if parameters, data or code are unreliable, even when its format looks authoritative.
What happens when a tested control fails?
The auditor investigates the cause and representativeness of the deviation, reassesses control risk and planned reliance, and changes substantive procedures when needed. A control deviation does not by itself prove a monetary misstatement, but it changes the evidence strategy.
Exam move
For each control, write its objective, activity, evidence of operation and exception response. Sort IT examples into access, change, operations, input, processing or output. Practise explaining why a general-control weakness can undermine application reliance, and why enquiry alone is insufficient evidence of consistent operation.
Take a transaction such as supplier payment and trace initiation, master-data maintenance, approval, processing, exception reporting and posting. At each stage, identify one possible misstatement and a preventive or detective control. Separate a control's design from evidence that it operated. Inspect configuration, logs and resolved exceptions rather than relying on a policy description.
Build pairs of general and application controls to show dependency, such as change management supporting an automated three-way match. For every failed test, explain whether a compensating control addresses the same risk with enough precision and timeliness. Then state how nature, timing or extent of substantive work changes. Review answers for vague claims that technology makes processing reliable by itself.
The examination move is always risk, objective, control, test and consequence. Add one scenario where the automated control works but general access is weak, and explain why reliance remains questionable. Add another where a precise manual review compensates for a failed automated check, then specify the evidence needed to support that conclusion. Keep prevention, detection and correction distinct throughout the explanation.
Verify who reviewed each exception, when, and what corrective action followed.
Working through Internal Control and IT Controls in ACCT6007? Sia is AskSia’s AI Accounting tutor — ask any ACCT6007 Internal Control and IT Controls question and get a clear, step-by-step explanation grounded in how ACCT6007 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
