MODULE 2

Internal control, information systems and IT

Understand internal control components, financial information systems, IT risks, general controls and evaluation of control design and implementation.

12 sections11 min readFree to read
In this topic 12 sections
  1. 47Controls support objectives, with unavoidable limitations
  2. 48Five components work together
  3. 49Follow information into the financial statements
  4. 50Smaller entities require a proportionate understanding
  5. 51Blockchain changes the trail, not the reporting objective
  6. 52References: Internal control and information systems
  7. 53Automation changes the pattern of risk
  8. 54Distinguish the supporting environment from transaction controls
  9. 55Control the whole processing journey
  10. 56Cloud computing relocates responsibilities
  11. 57Design, implementation and operation answer different questions
  12. 58Sources and further reading

Controls support objectives, with unavoidable limitations

Management and those charged with governance establish and maintain internal control. Controls support reliable reporting, effective operations and compliance. The auditor studies the system to assess misstatement risks and design audit work; a financial statement audit does not automatically provide a separate opinion on the effectiveness of every control.

Controls provide reasonable assurance because people can make mistakes, misunderstand instructions, collude or override procedures. A control may also become unsuitable after changes to staff, systems or transactions. A sound policy on paper is therefore only the beginning of the evaluation.

Five components work together

ComponentWhat it contributesWhat the auditor examines
Control environmentExpectations about honesty, competence, responsibility and accountability.Management behaviour, governance oversight, authority, staffing and the resources devoted to IT.
Entity's risk assessment processRecognition and response to threats to reporting objectives.How management identifies risks, assesses their importance and likelihood, and responds; why a relevant risk may have been missed.
MonitoringFeedback on whether controls remain suitable and operate as intended.Ongoing reviews, separate evaluations, correction of deficiencies and the reliability of monitoring information.
Information system and communicationCapture and movement of information needed for reporting.Transaction flows, records, adjustments, disclosures and communication of responsibilities or significant matters.
Control activitiesSpecific actions that address identified risks.Approvals, reconciliations, verification, access restrictions, asset protection and segregation of duties.

Concept sources: ASA 315, paragraphs 21–26 and Appendix 3 — five-component reference; the contribution-and-enquiry comparison is an original teaching arrangement.

The control environment influences the rest of the system. An approval requirement is less credible when management rewards staff for bypassing it. Governance oversight should challenge reporting choices and incentives; job descriptions, recruitment, training and clear delegated authority should support competent performance. IT governance also needs resources and oversight appropriate to the business's dependence on technology.

Management's risk assessment is distinct from the auditor's assessment. The auditor understands and evaluates management's process but reaches an independent conclusion. Likewise, monitoring is not the same as executing a transaction control: approving a payment is a control activity; periodically reviewing whether payment approvals are occurring is monitoring.

Follow information into the financial statements

An information system includes people, procedures, records and technology. Follow significant transactions from initiation through recording, processing and correction to the general ledger and final report. Include the period-end process and information about conditions that are not ordinary transactions, such as litigation or an impairment indicator. Disclosures may depend on information outside the ledger.

A decision path
  1. Business event occurs
  2. Evidence and accounting data are captured
  3. Processing and exceptions are controlled
  4. Ledger and supporting records are reconciled
  5. Adjustments and disclosures are prepared
  6. Reporting responsibilities and issues are communicated

Concept sources: ASA 315, paragraph 25 — original information-flow model.

A usable audit trail links the final amount back to its origin and permits completeness checks in the other direction. Electronic logs, transaction identifiers and controlled interfaces can perform the role once played by paper documents. Data downloads can help reveal actual processing paths, but the auditor still needs to understand the completeness and meaning of the data.

Control activities can prevent a problem or detect and correct it. Separation of authorisation, recording and custody reduces opportunities to initiate and conceal an error or fraud. Physical protection addresses access to assets; access permissions address systems and records. A review must be sufficiently detailed, timely and followed up to address its intended risk.

Smaller entities require a proportionate understanding

Small and medium-sized entities may have informal records, few staff, limited accounting expertise and concentrated ownership. A hands-on owner can exercise effective oversight, yet the same concentration can make override easier. Neither size nor informality establishes that controls are ineffective.

Evaluate what the owner actually does, which risk the action addresses, whether incompatible responsibilities remain, and what evidence demonstrates performance. A director's knowledge of every customer is useful context; it does not establish that revenue is completely recorded. Pay attention to unrecorded transactions, related parties, unusual year-end entries, unsupported balances and access to assets or records.

Weak records can limit the evidence available for the audit. Consider these difficulties during acceptance and planning, and revisit the approach when they emerge. A substantive strategy still requires the prescribed understanding of the control system. Conversely, if sufficient appropriate evidence cannot be obtained, extra substantive work may not resolve the problem.

Blockchain changes the trail, not the reporting objective

Distributed ledgers and smart contracts may improve traceability and automate recording. Describe these ledgers as tamper-evident and tamper-resistant rather than absolutely tamperproof. A durable record still leaves questions about the original input, authorisation, ownership, valuation and omitted transactions. NIST's 2018 Blockchain Technology Overview supports the technical distinction; its audit implications follow from applying the control objectives above.

References: Internal control and information systems

  • ASA 315 — components, scalability and limitations of internal control.
  • NIST IR 8202 — technical background to distributed ledgers, with no claim that blockchain removes audit risk.

Automation changes the pattern of risk

IT can process large volumes consistently, reduce transcription errors and produce detailed records. It can also repeat a defective calculation across an entire population. Integration spreads the consequences of a bad data item, while automatic initiation of transactions may reduce visible human checks.

Other concerns include concentrated expertise, incompatible access rights, unauthorised changes, disappearing logs and dependence on a few systems or service providers. The auditor considers these issues through their effect on financial reporting and audit evidence, rather than treating every technology weakness as a material misstatement.

Distinguish the supporting environment from transaction controls

General IT controls (GITCs) support dependable operation of applications and the integrity of information. Application controls address the processing of particular transactions or data, such as checking a valid product code or rejecting a duplicate invoice. The revised standard uses the broader term information processing controls, which can be manual or automated.

General-control areaPurpose and illustrative controls
Responsibilities and accessSeparate incompatible development, administration and operating duties; approve access; remove departed users; restrict and review privileged activity.
Development and changesAuthorise proposed changes, test them with users, approve release, control migration and retain documentation.
Computer operationsSchedule authorised processing, review failures and logs, control operator activity and investigate exceptions.
System software and dataRestrict changes to operating systems, databases, configurations, programs and documentation; preserve records of significant changes.
Continuity and physical protectionMaintain usable backups, test restoration, protect equipment and plan recovery from disruption.

Concept sources: ASA 315, Appendices 5–6 — reference for IT understanding and general controls; original grouping of the guide's control areas.

A good application check can be undermined if an administrator can alter it without detection. Equally, a GITC deficiency should be evaluated in relation to the affected systems, data and controls: it is not an automatic conclusion that every application is unreliable. Compensating controls or alternative evidence may matter.

The work is selective and risk-based. Identify relevant controls, determine the applications and other IT elements exposed to IT risks, then identify the GITCs addressing those risks. The auditor is not required to test every GITC. The AUASB's June 2022 GITC bulletin explains this boundary.

Control the whole processing journey

StageControl objectiveExamples to recognise
InputCapture authorised, complete and accurate transactions once.Approved source documents; required fields; valid codes; sequential numbering; transaction counts and batch totals.
ProcessingApply the intended logic to the correct data without loss, duplication or unauthorised alteration.Run-to-run reconciliations, transaction-code checks, rounding checks, controlled master-file updates and before-and-after reports.
OutputProduce reliable results and deliver them only to appropriate users.Reconcile output totals, investigate unusual items, check expected reports arrived and protect confidential reports.
Exception handlingResolve rejected items without losing or duplicating them.Assigned responsibility, exception logs, independent approval of corrections and controlled resubmission.

Concept sources: ASA 315, Appendix 3, information processing controls — control-objective reference; original input-to-resolution teaching table based on the supplied guide.

Understand what individual checks establish. A field test checks data format; a validity test checks membership in an approved set; a completeness test requires necessary information. A limit test applies one boundary, a range test applies two, and a reasonableness test examines whether related values make sense. A sequence test reveals missing or repeated identifiers.

Control totals serve different purposes. Record counts compare the number of items. Financial batch totals compare amounts. Hash totals add identifiers solely as a control check; the resulting total has no accounting meaning. A check digit is calculated from an identifier to help detect entry errors. None of these alone proves the commercial validity of the transaction.

Standard forms, training, coding instructions and a clear chart of accounts reduce input mistakes. A turnaround document reuses verified output as later input. Processing safeguards should identify the intended file, update cycle and retention requirements. The guide's older references to header/trailer records and physical media illustrate enduring objectives: process the correct complete dataset and avoid unintended loss or mixing of files.

A decision path
  1. Accept validated input
  2. Process against authorised rules
  3. Reconcile totals and inspect exceptions
  4. Correct with approval and resubmit
  5. Reconcile final output and restrict distribution

Concept sources: ASA 315, paragraph 25 and Appendix 3 — original teaching sequence for integrity of information flows.

Cloud computing relocates responsibilities

Public, private, community and hybrid clouds describe deployment arrangements. Infrastructure, platform and software services describe how much of the technology stack the provider operates. The allocation of controls varies with the arrangement; the client retains responsibility for its reporting and its own controls.

Map financial and operational systems, interfaces, providers and client responsibilities. Evaluate availability and recovery; confidentiality and access by outsiders, other customers and provider staff; integrity of data and reports; and incident support, logs and notification. Consider backups, restoration, data ownership and portability, encryption and key management, segregation between customers and physical security. These are assessment prompts, not an assumption that cloud systems are inherently weaker.

Concept sources: Australian Signals Directorate, Cloud Computing Security Considerations, October 2021 — historical security reference matching the guide's period.

Design, implementation and operation answer different questions

Design asks whether a control could address the risk. Implementation asks whether it exists and is used. Operating effectiveness asks whether it worked consistently over the relevant period. Enquiry alone does not establish implementation or operating effectiveness; inspection, observation or reperformance may be needed.

For example, inspect who can change a configuration, examine approval evidence and observe the system's behaviour. A single walkthrough can inform design and implementation but generally does not prove a manual control operated throughout the year. Tests supporting reliance must cover the intended period and relevant dependencies.

Under revised ASA 315, controls identified for evaluation include those addressing significant risks, journal entries, planned reliance, risks where substantive procedures alone are insufficient, and other controls selected using judgement. A predominantly substantive strategy does not erase these risk-assessment requirements. For each deficiency, explain the misstatement that could follow and the consequence for planned audit evidence.

Sources and further reading