Regulatory & Privacy · Sarbanes-Oxley ICFR
SOX ITGC testing that ties your systems back to the numbers.
We test the IT general controls behind your financial systems, document them the way your external auditor and the PCAOB expect, and connect each one to the application controls and accounts it supports.
SOX ITGC testing evaluates the IT general controls behind the systems that produce your financial statements: access to programs and data, program changes, program development, and computer operations. FinAudit CPA scopes the systems in play, tests each control domain, and documents the results so your external auditor can rely on them for internal control over financial reporting.
Reviewed by Debraj Hazra, CPA (USA), ACA (ICAEW, ICAI)
Last updated July 2026
What is SOX ITGC testing, really?
ITGC stands for IT general controls: the controls over the technology environment that supports your financial reporting. Think of the systems that calculate revenue, post journal entries, run payroll, or age your receivables. Those systems only produce reliable numbers if the environment around them is well governed. Who can log in and change a record? Who moves code into production? How does a new system get built and validated before it touches the general ledger? ITGC answer exactly those questions.
Sarbanes-Oxley, the 2002 law passed after a run of accounting scandals, requires public companies to maintain and assess internal control over financial reporting, usually shortened to ICFR. Section 404 puts management on the hook to test those controls and the external auditor on the hook to opine on them. IT general controls sit underneath that whole structure. When your auditor wants to rely on an automated control — a system that blocks a duplicate payment, say, or enforces a three-way match — they first have to trust the system running it. ITGC testing is how that trust gets established and documented.
So SOX ITGC testing is the disciplined work of identifying the systems in scope for financial reporting, defining the controls over those systems, gathering evidence, and testing whether each control was designed well and operated all year. Done right, it gives your external auditor a foundation they can rely on and gives your audit committee confidence that the numbers rest on something solid.
Application controls are only as trustworthy as the environment they run in. IT general controls are that environment. Test them poorly and every automated control above them becomes a manual control your auditor has to check by hand.
The four ITGC domains, and why each one matters
Auditors and the PCAOB group IT general controls into four domains. Each protects a different way the numbers could go wrong.
Access to programs and data. This is the largest domain and the one that fails most often. It covers who can get into your financial systems and what they can do once inside: user provisioning and deprovisioning, periodic access reviews, privileged and administrator accounts, password and authentication rules, and segregation of duties. The risk is simple. If the wrong person can post a journal entry or change a customer's credit limit without oversight, the financial data is exposed. We test that access is granted deliberately, reviewed regularly, and removed when people leave or change roles.
Program changes. Financial systems change constantly — new features, patches, configuration tweaks. Change management controls make sure every change is requested, tested, approved, and moved to production by someone other than the developer who wrote it. The risk here is a change that quietly breaks a calculation or opens a backdoor. We test that your change process was followed for real changes across the year, not just described in a policy document nobody uses.
Program development. When you build or buy a new financial system, or run a major upgrade, development controls make sure it was designed, tested, and validated before it went live and started producing numbers. The risk is a fresh system that posts wrong figures from day one. We review the projects that touched financial reporting during the period and test that data was migrated accurately and the system was signed off before go-live.
Computer operations. This domain covers the day-to-day running of the environment: job scheduling and monitoring, backups and recovery, and incident management. The risk is an unnoticed failed batch job that leaves the ledger incomplete, or a data loss with no clean recovery. We test that automated jobs are monitored, failures get resolved, and backups actually restore.
ITGC vs application controls: how they work together
People mix these up constantly. Application controls live inside a specific system and act on transactions. IT general controls sit underneath and govern the systems themselves. Your auditor can only rely on an application control if the ITGC beneath it are effective.
| IT general controls (ITGC) | Application controls | |
|---|---|---|
| What they govern | The IT environment and systems as a whole | A specific transaction or calculation inside one system |
| Example | Only approved developers can move code to production | The system blocks an invoice without a matching purchase order |
| Scope | Access, change, development, operations across systems | One control point in one application |
| What breaks if they fail | Every automated control above them loses reliability | One control gap the auditor can test around directly |
| Auditor reliance | The precondition for relying on any automated control | Relied on only when the ITGC beneath are effective |
How our SOX ITGC testing runs
You always know which systems are in scope, what evidence we need, and where a control stands. No surprises before the external auditor arrives.
-
01
Scoping the systems
We start from the financial statements and work backward to the systems that feed each material account, then agree which applications, databases, and operating systems are in scope. Scope drives everything, so we get it right first.
-
02
Risk and control mapping
For each in-scope system we define the ITGC across all four domains and map them to the application controls and accounts they support, so nothing is tested in isolation.
-
03
Design assessment
We evaluate whether each control, as designed, would actually prevent or detect the risk it targets. A control that looks fine on paper but cannot work gets flagged now, not in fieldwork.
-
04
Operating effectiveness testing
We pull samples across the period and test that each control operated all year, using your existing tickets, logs, and system records wherever we can to limit disruption.
-
05
Deficiency evaluation
When a control falls short, we assess severity — deficiency, significant deficiency, or material weakness — and describe the financial reporting impact in plain terms your audit committee can act on.
-
06
Documentation and handoff
We deliver test documentation structured the way your external auditor expects, so they can review and rely on it with minimal rework.
What you get, and how long it takes
You receive a full ITGC testing file: a scoping memo that ties systems to financial statement accounts, a control matrix across all four domains, design and operating effectiveness conclusions for every control, a deficiency log with severity assessments, and documentation formatted for your external auditor to review. If you are pre-IPO, you also get a candid readiness view of where your control environment stands against what a first SOX year demands.
Timing depends on your maturity and the number of in-scope systems. A focused environment with a handful of financial systems and clean evidence can move through design and testing in a few weeks. A larger estate with many applications, or a first-time program where controls are still being built, runs longer because remediation has to happen before there is a full year of operation to test. Public companies typically run this every year around their reporting cycle. Pre-IPO companies should start 12 to 24 months ahead, because SOX 404 needs controls that have operated over a period, and you cannot manufacture that history the week before you file.
What actually drives the cost
We scope every engagement and quote a fixed fee, so you will not face a surprise hourly bill. The number reflects real factors, not guesswork:
Number of in-scope systems
Each financial application, plus the databases and operating systems beneath it, adds controls to test. A single ERP is far lighter than a dozen integrated platforms.
Control maturity
If your access reviews and change process already run cleanly with good evidence, testing moves fast. If controls are informal or undocumented, remediation is where the effort goes.
Cloud and outsourcing
Heavy use of cloud platforms and third-party providers means reviewing their SOC 1 reports and mapping which controls you still own versus what you can rely on from them.
First year versus recurring
A first SOX program involves building and documenting controls from scratch. A recurring engagement reuses last year structure, so it costs less to run.
Why run your ITGC testing with FinAudit CPA
Most firms that test IT general controls come at it from pure IT. They know access reviews and change tickets, but they cannot tell you which controls actually matter to the revenue number or where a weak control creates real financial statement risk. That gap shows up in over-scoped testing that wastes your team time, and in deficiency write-ups that read like IT tickets instead of financial reporting judgments.
FinAudit CPA is a licensed US CPA firm. We read the IT environment and the financial statements, and we connect the two. When we scope, we start from the accounts and work down to the systems, so we test the controls that protect material numbers and skip the ones that do not. When we find a deficiency, we assess it the way an auditor evaluating ICFR does — by its effect on the financial statements — which is exactly the language your external auditor and audit committee use. You get senior attention, fixed scope you can budget around, and documentation built to be relied on the first time it is reviewed.
Pair your ITGC testing with
- SOC 1, when a third-party provider runs systems inside your financial reporting scope and you need to rely on their controls
- Statutory audit and review, when you need financial statement assurance alongside your controls work
- US GAAP and IFRS advisory, when accounting judgments and controls need to move together, especially pre-IPO
- SOC 2, when the same systems also need to prove security to your customers
SOX ITGC Testing · questions buyers ask
IT general controls, or ITGC, are the controls over the technology environment that supports financial reporting. They fall into four domains: access to programs and data, program changes, program development, and computer operations. They are not controls over a single transaction. Instead, they govern the systems themselves, which is what lets your external auditor trust the automated controls those systems run.
Application controls act on transactions inside one system, like blocking an invoice without a matching purchase order. ITGC govern the systems those application controls live in. An auditor can only rely on an automated application control if the ITGC beneath it, especially access and change management, are effective. Weak ITGC turn every automated control into a manual one the auditor must test by hand.
The PCAOB expects controls to be identified from the financial reporting risks they address, tested for both design and operating effectiveness across the period, and evidenced clearly. Auditors are expected to understand how systems produce the numbers, not just tick a checklist. We document testing to that standard so your external auditor can review and rely on it without extensive rework.
Public companies filing with the SEC must assess internal control over financial reporting under Sarbanes-Oxley Section 404, and ITGC sit underneath that assessment. Pre-IPO companies take it on ahead of going public. Audit committees oversee the work because they are responsible for the integrity of financial reporting. If your financial systems are automated, ITGC testing is part of your SOX obligation.
Start 12 to 24 months before you expect to file. SOX 404 requires controls that have operated over a period, so you need a full run of history to test, and that history cannot be created retroactively. Beginning early gives you time to build controls, generate evidence, remediate gaps, and reach your first reporting deadline with a control environment that is ready rather than rushed.
Section 302 requires your CEO and CFO to certify, each quarter, that the financial reports are accurate and that they maintain disclosure controls. Section 404 goes deeper: management must assess and document the effectiveness of internal control over financial reporting annually, and the external auditor opines on it. ITGC testing supports 404, because that is where controls are formally tested and evidenced.
We evaluate the failure by severity — a deficiency, a significant deficiency, or a material weakness — based on how it could affect the financial statements. A single access gap may be a minor deficiency, while a broad change management failure could undermine reliance on every system it touches. We describe the financial impact plainly so your team can remediate and your audit committee can judge the risk.
ITGC exist to support financial reporting, so testing them well means understanding the numbers, not just the systems. A licensed CPA firm scopes from material accounts down to the systems that feed them and evaluates deficiencies by financial statement impact, in the same language your external auditor uses. FinAudit CPA reads both the IT environment and the financials, which keeps testing focused and useful.
Pair it with
Audit once, comply many.
SOC 1 Audit
The report your customers’ auditors need when your service touches their books.
Statutory Audit & Review
Independent financial statement audits and reviews signed by a licensed US CPA firm.
US GAAP & IFRS Advisory
Technical accounting answers you can defend to your auditor — under both US GAAP and IFRS.