5.3 IT General Controls (ITGC) & Automated Application Controls

5.3 IT General Controls & Automated Application Controls

Financial systems can initiate, process, record and report transactions with little visible manual intervention. The audit therefore identifies the technologies relevant to financial reporting, understands the related IT processes and determines how controls and data depend on them.

IT general controls

IT general controls support the continued operation of applications, data and automated controls. A common audit structure covers four connected domains:

Access to programs and data

Access controls include authorised provisioning and removal, role design, authentication, privileged-access management, periodic review, logging and monitoring. The auditor tests whether rights match job responsibilities and whether elevated users can bypass normal application controls.

Privileged access is not assessed through a slogan that developers may “never” enter production. Routine development and deployment powers should be separated from production operation. Where emergency or exceptional access is permitted, it should have a documented purpose, prior or prompt approval as policy allows, time limitation, logging and independent review.

Program changes

Change management covers request, risk assessment, approval, development, testing, migration and post-implementation review. The auditor identifies who can change code or configuration, whether development and production are appropriately separated, and whether emergency changes follow a controlled path. The governing policy sets time limits; there is no universal 24- or 48-hour rule for every system.

Program development

Development controls govern new systems and major releases: requirements, security and control design, testing, data conversion, acceptance, cutover and post-implementation review. For a migration, reconciliation should address record counts, control totals, mapping, rejected items and opening balances. “100% of rows loaded” is not enough if fields were mapped incorrectly or the source population was incomplete.

Computer operations

Operations controls include job scheduling, interfaces, incident and problem management, backups, restoration testing, availability, monitoring and disaster recovery. A successful backup job is not evidence that restoration will work; auditors examine restore tests and whether recovery objectives match business needs.

Application controls

Application controls operate within a business process:

• input controls validate required fields, formats, ranges, authorised master data and duplicates;
• processing controls perform calculations, three-way matches, sequence checks and workflow approvals;
• interface controls reconcile records and totals transferred between systems; and
• output controls restrict and review reports, exception lists and reconciliations.

The auditor maps each control to an assertion. A three-way match can support occurrence, accuracy and authorisation of a payment, but it does not prove that master data, purchase orders or receipts were genuine. An automated range check proves only that configured values met the programmed rule.

Testing controls and dependencies

Start by evaluating design and implementation: could the control address the risk, and is it in use? If reliance is planned, test operating effectiveness over the relevant period. Evidence may include configuration inspection, controlled reperformance, change logs, exception handling and the ITGCs that keep the configuration stable.

For a fully automated control with unchanged code and configuration, testing one or a small number of executions may sometimes be combined with evidence over relevant ITGCs. This is a methodology decision, not a universal “sample of one” rule. Changes, multiple configurations, manual intervention or unreliable logs require different work.

Responding to deficiencies

When an ITGC fails, identify the affected applications, controls, reports, interfaces, users and periods. Evaluate compensating controls and whether alternative evidence exists. Without support, do not rely on the affected automated controls; revise the nature, timing and extent of other procedures. Unaffected controls remain available if their independence is demonstrated.

Constructed scenario

Assume developers held unreviewed production administrator rights during year-end and several financial-rule changes lacked approval and testing. The auditor would identify which automated validations and reports could have changed, inspect logs and configuration histories, test compensating review, extend transaction or data procedures where necessary and communicate the deficiency at the level required by ISA 265. The response depends on impact and evidence; it is not automatically a full-population manual retest.

Document scope precisely: application version, configuration, interfaces, infrastructure, relevant reports and period. A control that worked in one environment or business unit may not support another. When service organisations or cloud providers operate part of the stack, evaluate the applicable assurance report, complementary user controls, subservice arrangements and exceptions rather than assuming outsourced technology is outside the audit. Retain evidence of every dependency conclusion.