IT General Controls (ITGC) Review Checklist Template

The first task’s answers show the SOC 1 and go-live tasks and name the approver. Tasks 3 to 6 run in the annual review only, not in quarterly updates.

• Open the review and answer the scope questions — period, annual review or quarterly update, service organisations, go-lives or data migrations, and the ITGC owner or CFO who signs off
• Confirm the in-scope applications against the SOX scoping — every system that runs an automated control, calculates a reported figure or produces a key report
• Map each application to its database, operating system and network — a direct database update or a domain admin account bypasses every control in the application above it
• Rate the ITGC risk of each system — customisation, change volume, who can reach production and how many key controls depend on it
• Update the ITGC control matrix — each control with its domain, system, layer, owner, frequency and the application controls it supports
• Agree the test plan with the external auditor — sampling approach, which tests they will use, and the interim and roll-forward dates

Take each population from the system itself and record how you proved it complete before sampling.

• Test that new and changed access was approved before it was granted — compare the approval date on the request with the date the account or role was created
• Test leaver removal against the HR termination list — access removed within your policy deadline, and no sign-in after the leaving date
• Review privileged access at every layer — application administrators, DBAs, root and domain admins, each named, justified and kept to a minimum
• Check service, generic and emergency accounts — an owner, a purpose, credentials rotated, and every break-glass use logged and reviewed
• Take evidence that periodic access reviews ran — the completed recertification for each in-scope system, tested here rather than re-performed
• Check authentication settings against policy — password rules, MFA and remote access at the application, database and identity provider

The last two tasks appear only when a system went live, was upgraded or had data migrated in the period.

• Build the change population from the system, not the ticket queue — deployment logs, transport logs or object change dates, matched to tickets so unticketed changes surface
• Test sampled changes for approval, testing and authorised deployment — request, test evidence and business sign-off, all dated before the move to production
• Test emergency changes as a separate population — retrospective approval within your policy window, with the same test evidence after the fact
• Check who can deploy to production — developers should not move their own code; where they can, a reviewed deployment log has to compensate
• Test that direct data fixes and configuration changes follow the process — a changed tolerance or rate table alters results as much as code
• Test the implementation of any new or upgraded system — user acceptance testing, go-live approval and a post-implementation review before key controls rely on it
• Reconcile migrated data to the source system — record counts, control totals and key fields, signed off by the data owner

Key reports are tested once here, so the business-process testers can rely on them.

• Test monitoring of scheduled jobs and interfaces — failed or incomplete runs detected, investigated and rerun, with evidence for a sample of failures
• Test changes to the job schedule — new or altered jobs approved, and write access to the scheduler restricted
• Test backups and at least one restore — backups of in-scope data completed as scheduled, and a restore proven to work in the period
• Test incident handling for in-scope systems — incidents that could affect financial data logged, resolved and reviewed for root cause
• List the key reports and spreadsheets that controls rely on — the information produced by the entity (IPE) behind reviews, reconciliations and estimates
• Test the completeness and accuracy of each key report — source data, report logic or query, parameters and any manual handling, or the ITGCs that protect them

The four SOC 1 tasks appear only when a service organisation supports an in-scope system. The last task’s answer decides whether Phase 6 appears.

• Obtain a SOC 1 Type 2 report for each service organisation — check that its period, services and control objectives cover what you actually use
• Read the opinion, the exceptions and the subservice organisations — a qualified opinion or a carved-out data centre leaves a gap your own controls must fill
• Map and test the complementary user entity controls — each CUEC the report lists, matched to a control you operate and test
• Obtain a bridge letter for any gap to your year end — the provider’s statement that nothing material changed, backed by your own inquiry
• Conclude on design and operating effectiveness for every ITGC — effective, or exceptions found and passed to evaluation

Shown only when Phase 5 records at least one exception.

• Log each exception with its root cause — the control, system, layer, what failed and how long the gap lasted
• List the application controls and reports that relied on it — every automated control, interface and key report on the affected system
• Assess whether the gap was exploited — for example, review every change deployed or every action taken by the unauthorised account during the gap
• Rate the deficiency with the SOX team — deficiency, significant deficiency or material weakness, by likelihood and magnitude, allowing for compensating controls
• Remediate and retest before the as-of date — the fixed control has to operate long enough to be sampled

The sign-off is an approval assigned to the ITGC owner or CFO named in Phase 1.

• Summarise results by system and domain — controls tested, exceptions, deficiencies and remediation status
• Hand the conclusion to the SOX programme — which systems’ ITGCs are effective, so their automated controls and key reports can be relied on
• Report significant matters to the CFO and audit committee — significant deficiencies and material weaknesses, with remediation dates
• ITGC owner or CFO approves the review — reads the summary and evidence, then records Approved or Not approved
• Schedule the next update and set re-run triggers — a new ERP module, migration or service organisation brings the review forward