IT & Consulting

ITGC Audit Checklist: IT General Controls, Evidence and How to Prepare

By ITCM Team · Updated October 2026

An ITGC audit is the part of an external financial statement audit where the auditor tests the IT general controls behind your financial systems: who can access programs and data, how changes reach production, how new systems are implemented, and whether computer operations such as backups and scheduled jobs run reliably. To pass it you need controls that actually operated throughout the year and evidence you can hand over quickly, which is what the checklist below is built around. This guide explains why auditors test ITGCs, lists the prepared-by-client (PBC) evidence per domain, shows how deficiencies are rated, covers cloud and SaaS providers, and gives a month-by-month preparation timeline.

What IT general controls are and why financial auditors test them

IT general controls (ITGCs) are the policies and procedures that keep your IT environment reliable as a whole, as opposed to application controls that sit inside a single process, such as a three-way match or a credit limit check. They cover the systems that feed the financial statements: the ERP or accounting system, its database and operating system, the payroll and banking interfaces, and the identity platform that controls logins.

External auditors care because almost every figure in the accounts comes out of a system. If anyone could change the code that calculates depreciation, or a former employee could still post journals, the auditor cannot trust a system report or an automated control without testing it in detail. Effective ITGCs are what allow the auditor to rely on the system, which usually means less substantive testing for you and fewer surprises in the management letter.

Under the International Standards on Auditing, ISA 315 (Revised 2019) requires the auditor to understand the IT environment, identify risks arising from the use of IT and the general IT controls that address them. It applies to audits of periods beginning on or after 15 December 2021, and in Saudi Arabia SOCPA requires the ISAs for statutory audits. For US-listed companies, Section 404 of the Sarbanes-Oxley Act requires management to assess internal control over financial reporting (ICFR), and larger filers also need an auditor opinion on it under PCAOB AS 2201, where ITGCs are a standard part of the testing.

ITGC audit vs ERP audit vs IT governance review

These three are often confused. An ITGC audit is scoped by financial reporting risk and carried out by, or for, the external auditor. It looks across every in-scope system, including infrastructure and identity, and asks whether the controls operated all year. An ERP audit goes deeper into a single business system: role design, segregation of duties inside modules, master data and workflows. If that is what you need, use our separate ERP audit checklist.

An IT governance or ISO/IEC 27001 review is broader again, covering strategy, risk management, security and policies beyond financial reporting. The good news is that the evidence overlaps heavily, so a well-run access review or change process serves all three.

The four ITGC domains auditors test

Audit firms word them slightly differently, but the classic structure has four domains. Many firms merge program development into program changes for smaller companies that rarely implement new systems, and some treat computer operations narrowly as backups and job scheduling.

PBC checklist: access to programs and data

Access is where most ITGC findings arise, so prepare this domain first. Auditors typically sample new joiners, leavers and role changes across the year and compare them with system listings, so the dates must line up. Prepare evidence for each in-scope layer: application, database, operating system and network or directory where it gives access to financial data.

• Complete user listings for each in-scope system, extracted by the auditor or with a screenshot of the query, showing user, role, status, creation date and last login.
• HR starter and leaver reports for the period, so the auditor can match leavers to deactivation dates.
• Joiner evidence: an access request with manager approval before or on the account creation date.
• Mover evidence: approval for new access and removal of old roles when someone changes job.
• Leaver evidence: tickets or logs showing access disabled on or soon after the last working day, including VPN and remote access.
• Periodic user access reviews (often quarterly or semi-annual) signed off by business owners, with evidence that requested removals were actioned.
• A list of privileged and administrator accounts, with justification and a review of their activity or approvals.
• Generic, shared and service accounts: who owns them, whether interactive login is blocked, and how passwords are controlled.
• Password policy and MFA configuration screenshots from the system itself, not only the written policy.
• Your access control policy, approved and dated.

PBC checklist: program changes and change management

For change management the auditor wants a complete population of changes made to in-scope systems during the period, then picks a sample and traces each back to approval and testing. The hardest part is usually proving completeness, so a system-generated list from your ticketing tool, version control or the application’s own change log is far more convincing than a spreadsheet maintained by hand.

• A complete list of changes moved to production in the period, with ticket number, description, dates and who deployed it.
• For each sampled change: the request, business or system owner approval, evidence of testing (test results or UAT sign-off) and approval to deploy.
• Evidence of segregation between developers and production: who can deploy, and confirmation that developers cannot change production directly, or a monitored exception if they must.
• Emergency change procedure and evidence that emergency changes were reviewed and approved after the event.
• Configuration changes to financially relevant settings (tax codes, posting rules, approval limits) and how they are approved.
• Patching records for the operating system and database, if in scope.
• Vendor-delivered updates for SaaS or packaged software and how you assess and test them before or after release.

PBC checklist: program development and acquisition

This domain only matters in years when you implement a new financial system, migrate data or carry out a major upgrade. If that happened, auditors usually ask early, because a weak migration can affect opening balances.

• Project approval and business case, with a named sponsor.
• Requirements and design documents for financially relevant functions.
• Test plans and UAT sign-off from business owners.
• Data migration plan, reconciliations of balances and record counts between old and new systems, and sign-off by finance.
• Go-live approval and a list of known issues accepted at go-live.
• Post-implementation review and access set up for the new system following your normal joiner process.

PBC checklist: computer operations, backups, job scheduling and incidents

Operations evidence shows that data is protected and that automated processing completed correctly. Auditors want to see logs and results, not just a backup tool configured once.

• Backup policy and schedule for in-scope databases and file stores, including retention and off-site or immutable copies.
• Backup job logs for the period, with evidence that failures were investigated and rerun.
• At least one documented restore test in the year, with date, what was restored, result and who checked it.
• List of scheduled batch jobs and interfaces that affect financial data (bank imports, payroll postings, depreciation runs, integrations).
• Job monitoring evidence: alerts, failure logs and tickets showing failed jobs were resolved.
• Access to the job scheduler and who can change job definitions.
• Incident and problem management records for incidents affecting financial systems, including root cause where relevant.
• Disaster recovery or continuity plan for financial systems, if the auditor requests it.

Cloud and SaaS: SOC reports and complementary user entity controls

Moving to the cloud does not remove ITGCs; it splits them. The provider runs the data centre, infrastructure and often the change process for the software, while you remain responsible for who has access, how you configure the system and how you check the data. Auditors normally ask for the provider’s SOC report instead of testing the provider directly.

A SOC 1 report covers controls at a service organisation that are relevant to its customers’ internal control over financial reporting, so it is the report financial auditors usually want. A SOC 2 report covers security and, depending on scope, availability, processing integrity, confidentiality and privacy. A Type 2 report tests operating effectiveness over a period, while a Type 1 only describes design at a point in time, so ask for Type 2 where it exists.

When you receive the report, check that the period overlaps your financial year, read the exceptions and the auditor’s opinion, confirm which subservice providers are carved out, and work through the list of complementary user entity controls (CUECs). These are controls the provider expects you to operate, such as reviewing your own users and protecting admin credentials. If the report ends months before your year-end, request a bridge letter covering the gap.

Common ITGC deficiencies and how auditors rate them

Under US PCAOB standards there are three levels. A control deficiency exists when a control’s design or operation does not allow staff to prevent or detect misstatements on time. A significant deficiency is less severe than a material weakness but important enough to merit the attention of those overseeing financial reporting. A material weakness is a deficiency, or combination, with a reasonable possibility that a material misstatement will not be prevented or detected on time, and if one exists ICFR cannot be considered effective.

Under the ISAs used in Saudi Arabia and many other countries, ISA 265 uses two levels: deficiency in internal control and significant deficiency, and the auditor must communicate significant deficiencies in writing to those charged with governance and to management. An ITGC finding on its own is often rated as a deficiency, but the auditor will consider whether compensating controls exist and whether it undermines reliance on reports and automated controls. Several related findings in one system can be aggregated into a more serious rating.

How to prepare in the months before the year-end audit

Start by agreeing scope with your auditor: which systems, databases and interfaces are in scope and which controls they plan to test. Then run a self-assessment against the checklist above, fixing gaps early so that each control shows a period of operation before testing. A control redesigned in December rarely helps a 31 December year-end, because the auditor needs evidence across the period.

Collect evidence as you go rather than at the end. Save access reviews, restore tests and change samples into a shared folder named by control, and keep system-generated lists with the date and query used. Assign a single owner on the IT side who knows the evidence and can answer follow-up questions quickly.

Building a remediation plan after findings

When the management letter arrives, treat each finding as a small project. Record the root cause, the fix, the owner, the target date and the evidence that will prove the control now works. Prioritise anything the auditor rated significant, then access findings, because these are the most visible to audit committees.

Check whether the issue already caused harm, for example by reviewing what a leaver account did after the person left. Then fix the process, not just the instance, and let the control run for a few cycles before reporting it as remediated. If you need outside help to design controls or run the evidence process, our IT consulting service starts from $100, with the price agreed first and payment after you review the work. For the wider policy and framework side, see our guide on IT governance and compliance.

• Root cause: process, tooling, ownership or awareness?
• Immediate containment: remove access, review activity, confirm backups.
• Permanent fix: workflow change, automation or a new review step.
• Evidence: what the auditor will test next year and where it will be stored.
• Follow-up: management review of status until the finding is closed.

Frequently asked questions

What are the main IT general controls?

The main ITGCs fall into four domains: access to programs and data, program changes, program development or acquisition, and computer operations such as backups, job scheduling and incident management. Within those, the controls auditors test most are user provisioning and removal, access reviews, privileged access, change approval and testing, and backup monitoring.

What evidence do auditors ask for in an ITGC audit?

Typical requests include system user listings, HR joiner and leaver reports, access request and removal tickets, signed user access reviews, a complete list of production changes with approvals and test evidence, backup logs, a restore test record, batch job failure logs and SOC reports for cloud providers.

Is an ITGC deficiency a material weakness?

Not usually on its own. Auditors consider how severe the gap is, whether compensating controls exist and whether it affects reliance on reports and automated controls. Several related ITGC failures can, however, be combined and rated as a significant deficiency, or under US PCAOB standards as a material weakness.

How often should user access reviews be done?

There is no single mandated frequency. Many companies review access to financial systems quarterly and privileged access more often, while smaller companies with stable teams may review semi-annually. Agree a frequency that matches your risk and then perform every review on time with evidence.

Do ITGCs apply to SaaS and cloud systems?

Yes. The provider operates some controls, which are normally covered by its SOC 1 or SOC 2 report, but you still own user access, configuration, interfaces and the complementary user entity controls listed in that report.

Is ITGC testing only for SOX companies?

No. Auditors following the International Standards on Auditing also need to understand IT and general IT controls under ISA 315 (Revised 2019). The depth of testing depends on whether they plan to rely on controls, but any company with a statutory audit can expect ITGC questions.

Related reading & services

• IT governance and compliance guide
• ERP audit checklist
• ISO 27001 for small business
• IT consulting services
• IT policy development
• Server management

← All articles