ITGC: what the financial auditor actually tests, and how to not fail it

Practitioner reference for CIOs, controllers, internal audit, and finance-adjacent CISOs · 2026-05-24 · Written from twelve years of being the IT person the statutory auditor asks for evidence from, and the consultant the controller calls when those evidence requests don't go well

Why ITGC is the audit nobody briefs you on

If you are reading this you have probably been pulled into a meeting where the financial auditor wants “the IT controls.” Not the SOC 2 audit, not the ISO audit, not the ISMS programme. Something narrower, more specific, and somehow simultaneously vague. You ask what exactly they need, and what comes back is a checklist that reads like it was written for a 1998 mainframe environment translated through three layers of partner-level English.

That checklist is the IT General Controls — ITGC — assessment. It is the part of the statutory financial audit that examines whether the IT systems supporting financial reporting can be relied on. Get this right and the financial auditor relies on system-generated reports as evidence; the audit moves faster, with less manual sampling. Get it wrong and they fall back to substantive testing of every transaction, the audit takes three times as long, you get findings in the management letter, and somebody on the finance side gets very unhappy with you.

I want to lay out what ITGC actually is, what the auditor will test, what I have seen go wrong, and how to prepare so that the financial audit team treats your IT environment as a reliable control environment rather than a black box to be worked around. This is also the guide I wish I had when I first inherited a programme where the statutory audit and the SOC 2 audit and the internal IT audit were all running in parallel and nobody had thought to align them.

What ITGC actually is

ITGC is the set of IT controls that govern the systems supporting financial reporting. It is not the broader IT audit. It is not the cybersecurity audit. It is a specific, financial-reporting-oriented subset of IT controls, examined by the financial auditor (or by an internal IT auditor whose work the financial auditor relies on), to determine whether system-generated financial information can be trusted.

The framework that originally defined ITGC for statutory audit purposes is the COBIT family, but in practice modern ITGC audits are driven by:

• AICPA Auditing Standards (specifically AU-C 315 and AU-C 330) for US engagements
• SA 315 and SA 330 (Indian standards equivalent) for India
• ISA 315 and ISA 330 internationally

These standards require the financial auditor to understand IT controls relevant to financial reporting and to test them where reliance is intended. The auditor decides scope; you respond to it. But the structure they will apply is consistent across engagements.

ITGC is conventionally organised into four domains. I have heard them called slightly different names in different firms, but the substance is the same:

All four matter; access and change management are where most findings happen.

There is also a fifth conversation that increasingly comes up — end-user computing (EUC) controls around spreadsheets and analyst-built tools that feed into financial reporting. EUC is technically not part of classical ITGC, but every financial auditor I have worked with in the last five years asks about it, and every controller eventually gets a finding about it. We will get to it.

What “in scope” actually means

The single most important question to settle at the start of an ITGC engagement is: which systems are in scope?

The financial auditor’s working logic is: any system that generates, transmits, stores, or processes data that ends up in the financial statements is in scope. Period. This is broader than people initially think. The standard list:

• General ledger / ERP (SAP, Oracle Financials, Tally, Zoho Books, Sage, NetSuite, etc.) — always in scope
• Sub-ledgers — AR, AP, fixed assets, payroll, inventory management
• Banking and treasury systems that handle cash flows
• Billing and revenue recognition platforms
• Procurement and purchase order systems
• Expense management systems if they auto-post to GL
• HR / payroll systems if they feed compensation data to GL
• Anything that auto-posts journals to the GL — this catches a lot of integration points

Not in scope by default:

• CRM (unless it triggers revenue recognition)
• Marketing automation
• Support ticketing
• Internal communication tools
• HR onboarding (unless it provisions financial system access)

The most missed in-scope items I see:

1. The shadow GL. Many growing companies have a “real” ERP and a parallel set of spreadsheets where finance does the actual close. The spreadsheets are in scope as EUC, but the underlying source systems feeding the spreadsheets are also in scope. People forget the source systems because the controller works in the spreadsheet.

2. The integration layer. APIs, middleware, ETL pipelines that move data between systems. If a payment processor’s API feeds the AR sub-ledger, the integration is in scope, not just the two endpoints. This is where modern ITGC scoping is hardest because the integration layer is often the product engineering team’s problem and the finance auditor doesn’t know to ask about it.

3. Cloud-hosted financial systems. Yes, the SaaS vendor handles a lot of the IT general controls, but the customer’s responsibility for access management does not disappear. Who provisions users in your SaaS ERP? Who reviews access? Who removes access when people leave? If the answer is “the SaaS vendor handles it” you have a finding waiting to happen.

Scope settling should happen in the first scoping meeting. Get it in writing. Don’t let the auditor expand scope mid-audit because something they discovered “looked relevant.” That happens, but it costs you time and creates surprise findings.

Access to Programs and Data — what the auditor actually tests

This is the domain where most findings live. I have never seen a clean ITGC audit on access controls in the first year of a new financial system. Never. Not once. The auditor will find something.

What they test:

1. New user access is properly approved before provisioning. Sample size: typically 25 new users from the audit period.
2. Terminated users have their access removed in a timely manner. Sample size: typically 25 terminations.
3. Periodic access reviews are performed by appropriate reviewers at appropriate intervals. Sample size: at least one cycle of access reviews, and they will spot-check 25 user-system combinations to verify the review was meaningful.
4. Privileged access to financial systems is limited, justified, monitored, and reviewed separately. Sample size: full population of privileged users typically (it should be small).
5. Segregation of duties (SoD) — no single user can both initiate and approve a financial transaction. Sample size: a defined matrix of SoD conflicts, tested against the actual access configuration.
6. Authentication controls — password policy, MFA, account lockout, session timeout. Sample size: configuration review plus test cases.

What the evidence looks like that satisfies them:

• For new users: a signed access request (paper or workflow ticket), the business justification, the approver’s identity, the date of provisioning. The dates should make sense; access should not predate the approval.
• For terminations: an HR-generated termination report and a corresponding access-removal log. Time-to-deprovision should be measurable; the standard is 24 hours, but I have seen auditors accept 48 hours if documented as policy.
• For access reviews: the review file with reviewer signatures (or workflow approvals), evidence that the review actually questioned things (some accesses got removed during the review), and a re-test sample showing that the review’s conclusions were acted on.
• For privileged access: an inventory of privileged users, their justifications, evidence of monitoring (session recording, log review), and evidence of periodic re-justification.
• For SoD: an SoD matrix that defines conflicts, a tool or process that detects conflicts, and evidence that conflicts are either remediated or compensated by mitigating controls.

What goes wrong:

I see the same five patterns:

1. Generic access requests. “Please give John access to SAP” with no role specified. The auditor cannot tell whether John has the access he was approved for or has accumulated more. Fix: require access requests to specify the role or permissions, and provision exactly that.

2. Terminated users still active. Not in the primary system, where HR-system integration usually handles it, but in secondary systems — the database, the reporting tool, the SFTP that pushes data to the bank. The leaver process touches the GL but not the supporting infrastructure. Fix: maintain a single source of truth on identity that fans out to every in-scope system, including infrastructure.

3. Access reviews that approve everything. The reviewer ticks every box. The auditor asks how many access changes resulted from the review. The answer is zero. This is a “review-in-form-not-substance” finding. Fix: require the review to surface and remediate at least some access; require the reviewer to log time spent.

4. Privileged access via shared accounts. “DBA” account used by three people, no individual accountability. This is a finding in any modern engagement. Fix: every individual gets their own privileged credentials; shared accounts are eliminated or, where unavoidable (legacy systems), wrapped in PAM session recording.

5. SoD theoretical, not actual. The SoD matrix lives in a policy document; nobody runs it against the actual access configuration. Fix: monthly automated SoD report; documented disposition of every conflict.

Change Management — what the auditor tests

Change management for financial systems is the second-most-found domain. The auditor wants to know: can untested or unauthorised changes hit production?

What they test:

1. Change requests are documented with business justification and risk classification.
2. Approval is from an appropriate person (not the developer; not the developer’s friend).
3. Testing is performed before production deployment, with evidence.
4. Segregation of duties between development, testing, and production deployment — the same person should not write the code and push it to production.
5. Emergency changes have a defined process that catches up the documentation after the fact.
6. Direct changes to production data (DML statements against the financial database) are controlled, justified, approved, and logged.

Sample size: typically 25 changes from the audit period, drawn across the four major financial systems.

Evidence that satisfies them:

• A change ticket (Jira, ServiceNow, equivalent) with: requester, business need, technical change description, risk classification, approval chain, testing evidence, deployment record, post-deployment verification.
• For emergency changes: post-incident change documentation with the same fields, plus an explanation of why the emergency path was used.
• For data fixes: a documented request, approval, the exact SQL or transaction run, the operator’s identity, the rollback path if needed, and a verification that the fix achieved its purpose.

What goes wrong:

1. Developer-deployed changes. “We don’t really have a deployment team; the developer who wrote it deploys it.” This kills SoD instantly. Fix: introduce a deployment role, even if it is a peer on the same team, and require approval evidence in the deployment pipeline.

2. Emergency change abuse. Half the changes go through the emergency path because the normal path is “too slow.” This is a finding. Fix: track emergency vs normal change ratios. If emergency exceeds 10-15% of total changes, the normal process is broken; fix that first.

3. Production data fixes. Someone runs a SQL UPDATE against the GL because there was an integration bug. No ticket. No approval. No log. This is the highest-severity ITGC finding I see. Fix: every direct-to-production data change requires a documented and approved process; the database should log all such statements; auditors will sample them.

4. Test evidence absent. Changes deployed without test evidence saved. The developer says “I tested it.” Fix: require test results to be attached to the change ticket; require sign-off on test outcomes.

5. Vendor-deployed changes invisible. Your SaaS ERP vendor pushes a release. You don’t have visibility into what changed. The auditor asks for change evidence. You point at the vendor. The auditor wants to know how you assured the changes did not break controls. Fix: subscribe to vendor release notes, do regression testing on critical reports, document the test as your control over vendor changes.

Computer Operations — the often-skipped domain

Operations controls cover the boring infrastructure stuff — backups, batch processing, monitoring, disaster recovery. Most ITGC audits go light here unless the auditor specifically discovers a problem.

What they test:

1. Backups are performed on the agreed schedule, are validated for integrity, and can actually be restored.
2. Job scheduling and batch processing is monitored for failures; failed jobs are detected, investigated, and remediated.
3. System monitoring detects significant operational events and alerts appropriate staff.
4. Disaster recovery is planned, tested, and effective.

Sample size: typically a sample of dates from the audit period to verify backup completion, plus the most recent DR test evidence.

What goes wrong:

1. Backup tests are never done. Backups run nightly; the last actual restore test was 19 months ago. Fix: scheduled restore tests at least quarterly for financial systems; document the test, the restore time, and any issues.

2. DR test was a desktop walkthrough. The plan was reviewed in a meeting; no actual failover occurred. Some auditors accept tabletop tests for non-critical systems but for GL-supporting infrastructure they want at least a partial failover. Fix: annual partial failover test; document RTO/RPO actually achieved.

3. Batch failures not investigated. Nightly batches fail; nobody notices until finance can’t close the month. Fix: monitoring with alerting and a documented runbook; daily morning check of batch status with sign-off.

This domain is where I tell teams to put their proportional effort: enough to pass the audit, not so much that it becomes a programme of its own.

End-user computing (EUC) and spreadsheets

This is the domain that did not exist in classical ITGC frameworks but now eats half the audit conversation at many engagements.

The reality: every finance team I have ever worked with relies on spreadsheets. Some are operational tools used once a month. Some are critical models that feed the close. The auditor will ask for an inventory of spreadsheets used in financial reporting and will test the high-risk ones.

What “high-risk” means:

• Used to calculate financial reporting numbers (depreciation schedules, revenue recognition models, accrual calculations, FX revaluation)
• Used to combine data from multiple systems into a reported number
• Not subject to version control or change management

What the auditor tests:

1. Whether an inventory exists
2. Whether high-risk spreadsheets have basic controls — access restriction, change tracking, periodic review, formula audit
3. Whether the spreadsheets reconcile to source systems
4. Whether the spreadsheets have version history

What goes wrong:

Every finance team has the same problem: the master tax model spreadsheet that has 14 tabs, 3,400 formulas, has been incrementally edited for nine years, is on a shared drive, has no change history, and is so important that two people have permissions and nobody else dares touch it. The auditor will find this and write it up.

The honest fix is to migrate the calculation into the ERP or a purpose-built tool. The realistic fix is to apply lightweight controls — version control via SharePoint or Google Drive history, locked formula cells, named ranges, a tab that lists who changed what and when, and a quarterly reconciliation to source.

If you are starting from zero on EUC controls, just doing the inventory and ranking the top 20 spreadsheets by criticality is enough to move from “no controls” to “controls in design.” The auditor will give you credit for that and the finding becomes “deficiency” rather than “significant deficiency.”

SOC 1, SOC 2, and the ITGC relationship

This is where confusion happens, and where I find myself drawing the same diagram in three different client meetings every quarter.

SOC 1 is a report on controls at a service organisation that are relevant to the user organisation’s financial reporting. It is an ITGC report, written from the perspective of the customer’s financial auditor. When your SaaS ERP vendor produces a SOC 1, your financial auditor can use it to gain assurance over the vendor’s controls. SOC 1 reports come in Type 1 (point-in-time control design) and Type 2 (operating effectiveness over a period).

SOC 2 is a report on controls at a service organisation against the AICPA Trust Services Criteria — Security, Availability, Processing Integrity, Confidentiality, Privacy. It is broader than financial reporting and is the report you produce for your own customers’ security and risk teams.

The relationship:

• If you are a service provider whose customers’ financial auditors will rely on you, you need SOC 1.
• If you are a service provider whose customers’ security teams want assurance over your controls, you need SOC 2.
• Many companies need both.
• A SOC 2 does not satisfy a financial auditor looking for SOC 1 coverage. They overlap but are not interchangeable.

For your own financial audit:

• If you use SaaS systems that are in your ITGC scope, you should obtain and review their SOC 1 reports.
• If they only have SOC 2, the financial auditor may still rely on it for some control coverage, but may also do additional testing.
• If they have neither, you need to perform your own substantive testing of the vendor’s controls or accept that the controls will be tested manually.

The two-line summary: SOC 1 is for the financial auditor, SOC 2 is for the security team. Get the right report from the right vendor; pass the right report to the right auditor.

The relationship between ITGC and the broader IT audit

I have been asked this question more times than any other in this domain: how does ITGC relate to ISO 27001 audits, SOC 2 audits, RBI CSF audits, the internal IT audit, and the cybersecurity audit?

The short answer is they overlap substantially but are not the same.

ITGC is a focused subset of IT controls relevant to financial reporting. It is examined by the financial auditor.

ISO 27001 is a broad ISMS standard. Its Annex A controls overlap heavily with ITGC — access management (A.5.15-A.5.18), change management (A.8.32), backup (A.8.13), capacity management (A.8.6). But ISO 27001 also covers many controls that have no financial-reporting relevance — physical security of offices, cryptography for non-financial data, mobile device policy. ISO 27001 certification does not satisfy ITGC and ITGC does not satisfy ISO 27001.

SOC 2 covers the Trust Services Criteria. It overlaps with ITGC on access and change management for in-scope systems, but it is wider on security overall and narrower on financial reporting depth.

Internal IT audit as practiced by an internal audit function typically covers ITGC plus broader IT topics — cybersecurity posture, IT governance, IT risk management, IT compliance. Many internal IT audit functions effectively act as a pre-audit for the external statutory audit’s ITGC work.

RBI CSF audit (for banks and NBFCs in India) overlaps with ITGC at access, change, and operations level, but adds extensive cybersecurity-specific testing.

The good news: if you have a mature ISMS or are SOC 2 certified, you have already done 70% of the ITGC work. You just need to map the existing controls to the ITGC framework and present the evidence in the way the financial auditor wants to see it. The mapping is not hard. The presentation is where time gets spent.

The actionable advice: when scoping internal audits and certifications, deliberately align them with ITGC scope. Run one set of access reviews that satisfies ISO 27001, SOC 2, and ITGC. Run one change management process. The duplication is what burns out teams; the alignment is what makes the audit conversation tractable.

Common findings — the recurring pattern

If I had to summarise the seven findings that show up in eight out of ten ITGC audits I have seen:

1. Stale access in non-primary systems. People who left months ago still have access in a secondary system that didn’t connect to the HR feed.

2. Privileged access via shared accounts. “Admin” or “sa” accounts used by multiple humans with no individual accountability.

3. Access reviews that approve everything. Tick-box reviews where nothing changed.

4. Direct production data changes without trail. A DBA fixed something. There’s no ticket. It worked.

5. Emergency changes account for too high a percentage of total changes. The normal change process is broken.

6. Backups not actually restored. Last restore test was 18 months ago.

7. Spreadsheets running critical calculations with no controls. The master tax model. The revenue recognition workbook. The depreciation schedule that lives on someone’s laptop.

Fix the bottom five first; they create the most material findings. The top two are best fixed once but require sustained discipline.

What I would do if I were preparing for an ITGC audit in 90 days

Working backwards from the audit:

Day -90 to -60. Confirm scope. Get the system list locked. Identify in-scope user populations. Identify in-scope change populations. Identify in-scope spreadsheet population.

Day -60 to -45. Run an internal access review. Force it to surface and remediate at least some access. Document everything.

Day -45 to -30. Pull a sample of changes for the audit period. Verify every one has a ticket, approval, test evidence, and deployment record. Where any element is missing, document a remediation.

Day -30 to -15. Verify backups can be restored. Run a real test. Document the test. Verify the DR plan is current and the last test is reasonably recent.

Day -15 to -5. Pre-stage the evidence library. Every control, every artefact, every period it covers. Verify dates. Verify completeness.

Day -5 to 0. Walkthrough rehearsal with the IT team. Anticipate the questions. Decide who is in the room. Decide who is not in the room.

This is the same workflow I run when a client engages me for pre-audit preparation, scaled down for ITGC specifically.

What this guide does not cover

Three areas I left out deliberately:

1. Specific tool implementations. I have not recommended a specific access governance tool, a specific change management platform, or a specific spreadsheet control framework. The right tool depends on size, budget, system mix, and existing investment. I would rather you internalise the control logic than pick up a tool recommendation that may be wrong for your context.

2. Industry-specific ITGC nuances. Banks have additional ITGC requirements driven by RBI; insurance has IRDAI; healthcare in the US has HIPAA. These layer on top of the framework I have described but do not replace it.

3. Public company specifics. SOX (US) and Indian equivalents under SEBI LODR have their own internal control over financial reporting requirements that intersect with ITGC. The COSO framework, key controls, walkthroughs, deficiency evaluation — that is a separate guide.

This is a practitioner reference, not audit guidance. It reflects how ITGC engagements typically work as of May 2026 in India, the US, and internationally, and is not affiliated with any specific audit firm or standard. Compliance teams should validate specific obligations against the engaging audit firm’s methodology, applicable auditing standards, and counsel review.

ControlForge maps ITGC controls across ISO 27001, SOC 2, RBI ITGRCA, and SEBI CSCRF through cross-framework synthesis clusters covering access, change, operations, and program development domains.