The IT environment and IT general controls

Almost every transaction at Tamarack is initiated, recorded, processed and reported by software. Sales orders arrive through electronic data interchange from grocery chains, prices come from a master file, invoices are generated automatically, cash receipts are matched by an algorithm, and journal entries flow from subledgers to the general ledger without anyone typing them. Auditors who ignore this environment end up testing printouts produced by systems they do not understand. This lesson covers how the auditor understands the IT environment, identifies risks arising from the use of IT, and evaluates the general IT controls on which automated controls and reliable data depend. Lesson 5 extends the topic to service organizations, and lesson 6 to integrated audits of internal control.

Why IT matters to the financial statement audit

The revised risk assessment standard, CAS 315 (Revised 2019), made IT a required part of the auditor's understanding of internal control. The auditor must understand the entity's IT environment, identify the IT applications and other aspects of the environment that are subject to risks arising from the use of IT, identify those risks, and identify the general IT controls that address them. The requirement applies even when the auditor does not plan to rely on controls, because IT affects the reliability of the information the auditor uses as evidence and the risks of material misstatement themselves.

Benefits of IT for internal control include consistent processing of large volumes, timely and accurate calculations, and automated controls that cannot be skipped by a busy clerk. The risks are different in kind. An error in a program repeats on every transaction. Unauthorized access can let someone create a vendor and pay it, or change prices, without leaving the paper trail that manual fraud usually leaves. Changes to programs or master data can alter processing silently. And because systems are shared, a weakness in one place, such as excessive administrator access to the database, can undermine every application that relies on it.

Understanding the IT environment

The understanding starts with the flow of transactions and information through the entity's systems, and identifies where automated controls, reports and interfaces are relevant to the audit. For Tamarack, the team documents the following.

The auditor then identifies which applications and other aspects of IT are relevant. An application is relevant when it processes data the auditor relies on, maintains automated controls the auditor intends to rely on, or produces information used as audit evidence. For Tamarack, the cloud ERP, the Mexican ERP, the consolidation application, the trade promotion system and the payroll provider are relevant. The company's marketing website, which takes no orders, is not.

General IT controls

General IT controls, or ITGCs, are controls over the IT processes that support the continued proper operation of the IT environment, including the continued effective functioning of automated controls and the integrity of information. They are usually grouped into four areas.

The link between ITGCs and the audit is a chain. If the automated three-way match is to be relied on, the auditor must have evidence that the match was configured correctly, which can come from a test of one transaction or an inspection of the configuration, and that the configuration did not change during the period without authorization and that only authorized users could override it, which comes from ITGCs over program changes and access. Without effective ITGCs, a single test of an automated control at one point in time says little about the rest of the year.

Risks arising from the use of IT

The auditor identifies the specific risks that could affect the relevant applications, and the ITGCs that address them. Typical risks include: unauthorized access to data, causing destruction or improper changes; inappropriate access privileges that break down segregation of duties; unauthorized changes to master files, such as prices or bank account details; unauthorized changes to systems or programs; failure to make necessary changes; inappropriate manual intervention; and potential loss of data or inability to access data. Not every risk is relevant to every application. For a SaaS ERP, risks over program changes to the core software sit mainly with the vendor, which is why the vendor's service organization report matters, while risks over configuration and access remain largely with Tamarack.

Testing access: a user access review

Access controls are the ITGCs most often found deficient. The program below performs the kind of analysis an IT audit specialist runs on extracts from the ERP and the human resources system: it compares active accounts with terminations, looks for combinations of permissions that break segregation of duties, and flags generic accounts. The data are synthetic.

# User access review for the group's ERP (synthetic data generated with a fixed seed).
import random, datetime as dt
random.seed(4311)
start = dt.date(2026, 1, 1)
roles = ["AP clerk", "AR clerk", "Buyer", "GL accountant", "Warehouse", "Sales", "IT support"]
users = []
for i in range(1, 181):
    users.append({"id": f"U{i:03d}", "role": random.choice(roles), "active": True,
                  "perms": set(), "last_login": start + dt.timedelta(days=random.randint(200, 364))})
for u in users:
    if u["role"] == "AP clerk": u["perms"] |= {"enter_invoice"}
    if u["role"] == "Buyer": u["perms"] |= {"create_vendor", "raise_po"}
    if u["role"] == "GL accountant": u["perms"] |= {"post_journal"}
    if u["role"] == "IT support": u["perms"] |= {"admin"}
# Seeded problems of the kind access reviews find:
for uid in ("U017", "U088"): next(u for u in users if u["id"] == uid)["perms"] |= {"create_vendor", "approve_payment"}
next(u for u in users if u["id"] == "U140")["perms"] |= {"post_journal", "approve_journal"}
users.append({"id": "TEMP01", "role": "Generic", "active": True, "perms": {"post_journal"},
              "last_login": dt.date(2026, 11, 2)})
hr_terminations = {"U023": dt.date(2026, 3, 31), "U064": dt.date(2026, 7, 15),
                   "U101": dt.date(2026, 9, 30), "U155": dt.date(2026, 12, 12)}
for uid in ("U023", "U101"):          # disabled on time
    next(u for u in users if u["id"] == uid)["active"] = False
next(u for u in users if u["id"] == "U064")["last_login"] = dt.date(2026, 8, 4)

exceptions = []
for u in users:
    if u["id"] in hr_terminations and u["active"]:
        late = u["last_login"] > hr_terminations[u["id"]]
        exceptions.append((u["id"], "terminated but still active" + (", logged in after leaving" if late else "")))
    if {"create_vendor", "approve_payment"} <= u["perms"]:
        exceptions.append((u["id"], "can create vendors and approve payments"))
    if {"post_journal", "approve_journal"} <= u["perms"]:
        exceptions.append((u["id"], "can post and approve own journal entries"))
    if u["role"] == "Generic":
        exceptions.append((u["id"], "generic account with posting rights"))
print(f"Accounts reviewed: {len(users)}   terminations in the year: {len(hr_terminations)}")
for uid, issue in exceptions:
    print(f"  {uid:<7} {issue}")
print(f"Exceptions: {len(exceptions)}")

Accounts reviewed: 181   terminations in the year: 4
  U017    can create vendors and approve payments
  U064    terminated but still active, logged in after leaving
  U088    can create vendors and approve payments
  U140    can post and approve own journal entries
  U155    terminated but still active
  TEMP01  generic account with posting rights
Exceptions: 6

Six exceptions arise among 181 accounts. Two users can both create vendors and approve payments, a classic segregation of duties conflict that could allow a fictitious vendor to be set up and paid. One user can post and approve journal entries. A generic temporary account has posting rights, so entries made through it cannot be traced to a person. Two former employees remain active; one of them, U064, logged in three weeks after leaving. Each exception needs follow-up: whether the access was used, what was done with it, and whether other controls would have caught a misstatement. For U064, the team obtains the activity log and finds that the login was a failed attempt to view a pay statement; no transactions were posted. The deficiency in the removal process remains, and the team evaluates its severity in lesson 6.

Testing program changes

For program change controls, the auditor typically obtains a system-generated list of changes moved to production during the period, tests its completeness, and matches each change, or a sample, to an approved, tested ticket. Testing whether developers can move their own changes to production, and whether emergency changes are approved afterwards, addresses the risk that unauthorized changes reach production.

# Change management test: match changes migrated to production with approved tickets (synthetic).
import random
random.seed(4312)
devs = ["dlee", "mortiz", "kchen", "abrar"]
migrators = ["ops1", "ops2"]
changes, tickets = [], {}
for n in range(1, 65):
    cid = f"CHG{n:03d}"
    dev = random.choice(devs)
    changes.append({"id": cid, "dev": dev, "migrated_by": random.choice(migrators), "emergency": False})
    tickets[cid] = {"approved": True, "tested": True}
# Problems seeded for the illustration
tickets["CHG012"]["approved"] = False
tickets["CHG047"]["tested"] = False
del tickets["CHG033"]                                   # change with no ticket at all
changes[20]["migrated_by"] = changes[20]["dev"]         # developer moved own change (CHG021)
for c in (changes[5], changes[58]): c["emergency"] = True
post_approved = {"CHG006"}                              # CHG059 never approved after the fact

issues = []
for c in changes:
    t = tickets.get(c["id"])
    if t is None: issues.append((c["id"], "no change ticket"))
    else:
        if c["emergency"]:
            if c["id"] not in post_approved: issues.append((c["id"], "emergency change not approved afterwards"))
        elif not t["approved"]: issues.append((c["id"], "migrated without approval"))
        if not t["tested"]: issues.append((c["id"], "no evidence of user testing"))
    if c["migrated_by"] == c["dev"]: issues.append((c["id"], "developer migrated own change"))
print(f"Production changes in the year: {len(changes)}  (emergency: {sum(c['emergency'] for c in changes)})")
for cid, why in issues: print(f"  {cid}  {why}")
print(f"Changes with exceptions: {len({i[0] for i in issues})} of {len(changes)}")

Production changes in the year: 64  (emergency: 2)
  CHG012  migrated without approval
  CHG021  developer migrated own change
  CHG033  no change ticket
  CHG047  no evidence of user testing
  CHG059  emergency change not approved afterwards
Changes with exceptions: 5 of 64

Five of the 64 changes have exceptions. CHG021 is the most serious in principle: a developer moved his own change into production, which defeats the separation intended to prevent unauthorized changes. The team inspects what CHG021 changed, a report layout for the promotion accrual report, and compares the report's output before and after. Because the promotion accrual report is used in the audit of trade promotion liabilities, the team performs additional procedures on the report's logic and data for the whole year rather than relying on it unchecked.

Information produced by the entity

Auditors use reports from the client's systems as evidence: aged receivables to test allowances, inventory aging to test provisions, journal entry listings to select entries for testing. The standards require the auditor to evaluate whether such information is sufficiently reliable for the purpose, which usually means testing its accuracy and completeness. Effective ITGCs support the reliability of system reports; where they are deficient, the auditor tests the specific report directly, for example by reconciling the aged receivables total to the general ledger, recalculating aging for a sample of invoices, and checking that the report's parameters capture all customers.

Data analytics, introduced in ACCT-341, depend on the same foundation. A journal entry test that runs on an incomplete extract can miss exactly the entries that matter. Before running analytics on Tamarack's full year of journal entries, the team reconciles the extract's totals to the trial balance by account and confirms that the extract parameters cover all companies, periods and entry sources.

Cloud services and the role of IT specialists

Cloud computing shifts some IT processes to vendors, but not the entity's responsibility for its financial reporting or the auditor's need for evidence. For a SaaS application, the vendor manages the infrastructure, the database and changes to the core software; the customer configures the application and manages its own users. The auditor therefore needs evidence about controls at the vendor, usually from a service organization report covered in lesson 5, and about controls at the entity over configuration, access and interfaces.

The engagement team decides whether IT specialists are needed, and the firm's system of quality management, discussed in lesson 1, should set expectations for their involvement. Under CAS 315 (Revised 2019), the auditor must have the appropriate skills to understand the IT environment. For Tamarack, an IT audit specialist performs the access and change analyses, reviews the configuration of automated controls and evaluates the vendor's service organization report; the audit team remains responsible for integrating the results into the risk assessment and responses.

Cybersecurity incidents are a growing source of financial reporting risk. A ransomware attack can disrupt processing, destroy data or cause losses that need to be recognized or disclosed. The auditor considers cybersecurity risks when they could affect the financial statements, for example through the IT environment, through possible fraud such as business email compromise redirecting payments, or through disclosures, but is not engaged to provide assurance on cybersecurity itself; that is a separate engagement, discussed in lesson 11.