ITGC audit checklist

Before you test anything: scope and populations

More ITGC findings come from scoping and populations than from the controls themselves. Settle these first or the testing will be reworked:

• In-scope applications, databases, operating systems and the layers beneath each financially significant system — ITGCs are tested per layer, not per application.
• The service organisations in scope, and whether you are relying on a SOC 1 report for any of them — including the complementary user entity controls that report assumes you operate.
• Completeness and accuracy of every population. If the user listing or change log you sample from cannot be shown to be complete, the sample proves nothing. This is the single most common reason ITGC testing fails late in the cycle.
• Who produced each report used as evidence, and how you demonstrate it was not filtered or edited.

1. Access to programs and data

• New access is requested, approved by the right business owner and provisioned to match what was approved — with the approval retrievable, not just asserted.
• Terminated users are removed promptly, and you can evidence the timing against the HR leaver date rather than the ticket close date.
• Transfers have access removed, not just added. Movers who accumulate permissions across roles are the finding auditors probe hardest.
• Privileged and administrative access is restricted, owned and reviewed — including database and OS-level accounts, not only the application.
• Periodic user access reviews are performed with evidence of what reviewers saw, what they decided, and that removals actually happened.
• Segregation of duties conflicts are defined, monitored and resolved, with compensating controls documented where a conflict is accepted.
• Generic, shared and service accounts have named owners and controlled credentials.
• Authentication settings match policy — password parameters and MFA coverage on every path in, including VPN and admin consoles.

2. Program changes

• Changes are requested, tested, approved and migrated by someone other than the developer who wrote them.
• Developers cannot migrate to production, and cannot make direct changes there. Where they can in an emergency, that access is monitored and reviewed.
• Emergency changes follow a defined path with after-the-fact approval — and the population of emergency changes is complete.
• Test evidence and approvals are retained for the sample, not recreated at audit time.
• Configuration and master-data changes are covered, not just code. This gap is common in ERP environments.

3. Program development

• New systems and major implementations follow a documented lifecycle with approvals at defined gates.
• Data conversion is reconciled and signed off — the control auditors most often find missing on a go-live in the period.
• Pre-implementation testing and user acceptance are evidenced before the cutover, not after.

4. Computer operations

• Batch jobs and interfaces are scheduled, monitored, and failures are detected, escalated and resolved with evidence.
• Backups run to policy and — the part that gets skipped — restoration is tested and the result recorded against your stated recovery objective.
• Incidents and problems are logged, prioritised and closed.
• Physical and environmental controls where systems are hosted, or the equivalent assurance from your provider.

The deficiencies that recur every year

• Access reviews that cannot be evidenced. A review happened; nobody can show what was reviewed or what changed as a result.
• Leaver removal timing measured from the wrong date, so the control looks compliant and is not.
• Incomplete populations — a change log that excludes emergency changes, or a user listing pulled after a clean-up.
• Developers with standing production access, unmonitored.
• Backups never restored. Success logs are not a recovery control.
• Report-based evidence with no completeness support, which invalidates the testing built on it.

Where this connects

ITGCs underpin more than the financial statement audit. The access domain is largely the same evidence as identity and access management, SOC 2 CC6 and PCI DSS Requirements 7 and 8 — see SOC 2 services — and the operations domain overlaps with business continuity. Testing once and reusing the evidence is usually the difference between one controls programme and four.