IT general controls and application controls

When an ERP calculates a three-way match or blocks an order over a credit limit, management and auditors want to rely on that automated control. They can only do so if they are confident the control works as designed and has kept working all year. That confidence comes from two layers of controls. Application controls are built into specific business applications and transactions: input edits, matching rules, calculations, approval workflows. IT general controls (ITGCs) are the broader controls over the IT environment that keep application controls working: who can access the system, how changes are made, how the system is operated and how data is backed up and recovered. If the general controls are weak, an automated control that worked in January may have been changed or bypassed by June, and nobody would know.

This lesson explains both layers, how they connect, and the basic logic auditors use to test them. The aim is not to make you an IT auditor (ACCT-331 and the CISSP courses go further), but to make you able to discuss controls with IT staff, read a control matrix, understand an auditor's findings and design sensible controls in your own processes.

IT general controls

ITGCs are usually grouped into four domains. Access to programs and data covers user provisioning and removal, authentication, role design, privileged access and periodic access reviews. Program change management covers how changes to software and configuration are requested, approved, tested, migrated to production and reviewed, including emergency changes. Program development or acquisition covers how new systems are selected, built, tested, converted and approved before going live. Computer operations covers job scheduling, monitoring, incident handling, backup and recovery. The domains map closely to COBIT's Build, Acquire and Implement and Deliver, Service and Support domains from lesson 8, and to ITIL practices such as change enablement and incident management (ITIL-140).

Access controls deserve special attention because they are where ERP risks concentrate. Every user should have a unique account, so that actions can be traced; shared logins destroy accountability. Access should be granted by role, on the principle of least privilege, with approval from the business owner of the data. When people change jobs their old access should be removed, not just added to, a problem known as access creep. Privileged accounts, such as system administrators and ERP superusers who can do anything, should be few, monitored and used only when needed, ideally through a check-out process that logs each use. A quarterly access review, in which managers confirm that each person's access is still appropriate, catches what the other controls miss.

Change management protects the integrity of the programs and configuration. In a cloud ERP, the vendor controls much of the software code, so the customer's change management focuses on configuration: tax codes, approval limits, matching tolerances, posting rules and workflows. A change to the three-way match tolerance from 2 per cent to 20 per cent is a change to a key financial control and should go through the same request, approval, testing and logging process as a software change. Separating the people who make changes from the people who approve and move them into production prevents a single person from introducing an unauthorized change.

Application controls

Application controls operate within a specific process and are usually classified as input, processing and output controls. Input controls make sure that data entered is authorized, complete and accurate. Processing controls make sure that data is processed completely and correctly, without loss, duplication or unauthorized change. Output controls make sure that reports and files are complete, accurate and go only to the people entitled to them. Many application controls are automated, and well-designed ERPs include them as configuration options; others are manual reviews of system output.

Batch controls are an old idea that remains useful whenever data moves between systems, such as an upload of bank transactions or a nightly interface from the online store. Before processing, the sender computes a record count, a financial total (such as the sum of amounts) and sometimes a hash total, which is a meaningless sum of a non-financial field such as account numbers, used only to detect changes. After processing, the receiver computes the same totals. If any total differs, records were lost, duplicated or altered. The code below shows both batch totals and the Luhn check digit, which detects most single-digit keying errors and transpositions of adjacent digits.

# Batch totals for an interface, and Luhn check digits (illustrative)
sent = [("1043", 6200.00), ("1077", 2900.00), ("1102", 1500.00), ("1188", 950.25)]
received = [("1043", 6200.00), ("1077", 2900.00), ("1120", 1500.00), ("1188", 950.25)]   # one id altered

def totals(batch):
    return len(batch), round(sum(a for _, a in batch), 2), sum(int(c) for c, _ in batch)
for label, b in (("sent", sent), ("received", received)):
    n, amount, hash_total = totals(b)
    print(f"{label:9s} count {n}  amount {amount:,.2f}  hash total {hash_total}")
print("Batch agrees" if totals(sent) == totals(received) else "Batch DIFFERS - investigate before posting")

def luhn_digit(number):
    total = 0
    for i, ch in enumerate(reversed(number)):
        d = int(ch)
        if i % 2 == 0:          # double every second digit starting from the right of the payload
            d = d * 2 - 9 if d > 4 else d * 2
        total += d
    return str((10 - total % 10) % 10)
def luhn_valid(full):
    return luhn_digit(full[:-1]) == full[-1]

base = "104377"
full = base + luhn_digit(base)
print(f"Customer id with check digit: {full}")
for keyed in (full, "1043787", "1034777"):
    print(f"  keyed {keyed}: {'valid' if luhn_valid(keyed) else 'rejected'}")

sent      count 4  amount 11,550.25  hash total 4410
received  count 4  amount 11,550.25  hash total 4428
Batch DIFFERS - investigate before posting
Customer id with check digit: 1043777
  keyed 1043777: valid
  keyed 1043787: rejected
  keyed 1034777: rejected

The record count and amount total agree, but the hash total exposes the altered customer number, which would otherwise have posted $1,500 to the wrong account. In the Luhn example, a single wrong digit and a transposition of adjacent digits are both rejected at entry. Check digits are built into payment card numbers, many bank account and identification numbers, and they can be added to an organization's own customer and supplier numbers at little cost.

Testing controls

Auditors and internal reviewers test controls in two ways. A test of design asks whether the control, if it operates as described, would prevent or detect the risk: is the credit check applied to every order channel, does the duplicate check include normalized invoice numbers? A test of operating effectiveness asks whether it actually operated throughout the period. For manual controls this usually means selecting a sample of instances and inspecting evidence, such as signed reconciliations. For automated controls, the logic is different: a computer applies the same rule every time unless it is changed, so testing one instance of each scenario (for example, an order under the limit, an order over the limit and an order exactly at the limit) can be enough, provided the ITGCs show the program and configuration were not changed without control during the period. This is why weak ITGCs are so costly: they force auditors to test far more transactions.

Completeness and accuracy of the data used in controls is the other recurring issue. A manager who reviews an exception report is performing an IT-dependent manual control, and the review is only effective if the report includes every exception and calculates them correctly. Auditors call such data information produced by the entity (IPE), and they test it, for example by reconciling the report's population to the ledger or re-running its logic, as lesson 4 did for the aging report.

Organizations that outsource processing, such as payroll to a service provider or their ERP to a cloud vendor, still own the controls. They rely on the provider's controls report, in Canada usually a CSAE 3416 report (the Canadian equivalent of a SOC 1 report), to understand and evaluate the controls operated by the provider, and they must operate the complementary user entity controls the report lists, such as reviewing payroll registers and managing their own users' access.