ITGC testing for SOX covers four areas over the applications that feed your financial statements: access to programs and data, program changes, program development, and computer operations. For each in-scope application you design a test of each relevant control, pull a complete population, select a sample sized to the control's frequency and risk, and keep evidence that another tester could reperform. The domains are the easy part. Tests get rejected because the population was incomplete, the report behind the control was never validated, or the reviewer's evidence shows a signature and not the review.
This guide is written from the side of the table that decides whether testing holds up. It is general information, not audit or legal advice. Your external auditor's methodology governs what they accept, so confirm specifics with them and with a qualified professional.
Why ITGCs carry so much weight
ITGCs do not prevent a misstatement directly. They protect the environment where the controls that do prevent misstatements run. An automated three-way match, a system-enforced approval limit, or the report a controller reviews each month can only be trusted if nobody could change the logic unnoticed and nobody had access they should not have.
Auditors scope top down. Auditors think top down. They start at the financial statements, move through entity-level controls, then to significant accounts, disclosures and their assertions, and only then to the applications and ITGCs underneath. This is the order of their reasoning, not always the order in which they do the work. Under PCAOB guidance, IT risk is part of that top-down approach, not a separate exercise. In practice, an application is in scope because a significant account depends on it, not because it is important to the business.
Risk is also assessed domain by domain. One application can be high risk for change management because it is custom code deployed weekly, and low risk for access because three people use it. Scoping that treats every application the same tests too much in some places and too little in others.
The four domains, and what a passing test looks like
Access to programs and data
This is where most findings start, and where we look first.
Provisioning. The test asks whether access was approved by the right person before it was granted, and whether the access granted matches the access approved. Evidence is the request, the approval with a timestamp earlier than the grant, and the system's own record of the grant. A ticket marked "done" with no system-side proof is weak.
Terminations. Take the HR termination list for the period, match it to the application and network user lists, and check when access was removed against the separation date. The test fails quietly when the HR list is incomplete, for example when contractors are left out or when the user list came from a report nobody validated. If someone kept access after leaving, the next question is whether they used it. Log evidence of no activity after the separation date often turns an exception into a deficiency that can be evaluated rather than an open question.
Privileged access. List every account with administrative rights at the application, database and operating system layers, including service accounts and generic or shared IDs. Confirm each one is justified and that privileged activity is monitored where the access cannot be removed. Developers with production access are a classic finding. They are not automatically a deficiency if a monitoring control exists and works.
User access reviews. The reviewer certifies that each user's access is appropriate. Auditors reject these when the list given to the reviewer was not shown to be complete, when the reviewer approved hundreds of lines in minutes with no notes, or when the removals requested never happened. Evidence should show what the reviewer looked at, what they challenged, and that every change they requested was made.
Program change management, including emergency changes
The core test: every change to an in-scope application, database or configuration that reached production was authorized, tested and approved before deployment, by someone other than the developer where the system allows it.
The most common mistake is sampling from the ticketing system. The population has to come from the system side: the deployment log, the version history, the database change log. Then match it back to the tickets. A change with no ticket is the finding a ticket-based sample can never surface.
Where change control runs through pull requests and deployment pipelines, test it there. Look at branch protection settings, required reviewers, who can override them, and whether anyone can deploy directly around the pipeline.
Emergency changes need their own path: a defined emergency, deployment by an authorized person, and approval after the fact within a set period, with evidence. An emergency process used for a third of all changes is a design problem, not an operating one.
Program development and the SDLC
This domain covers new systems and major upgrades. Tests look for approved requirements, testing evidence, user acceptance sign-off, go-live approval, and controls over data conversion. If no significant implementation happened during the period, this domain may have nothing to test. Document that conclusion, not just its absence.
ERP implementations deserve attention before go-live, not after. Conversion reconciliations, access granted for the cutover, and segregation of duties in the new system are all easier to evidence while the project team is still in place.
Computer operations and job scheduling
This covers scheduled jobs that move or process financial data: interfaces, batch postings, nightly calculations. Tests check that changes to the job schedule are controlled, that failures are detected, and that failed jobs are investigated and resolved with evidence. Backup and recovery controls belong here when they bear on the integrity of financial data. Many auditors now scope them narrowly, because ITGCs for financial reporting are about data integrity more than availability.
Sample sizes: the logic, not a table
PCAOB standards do not set sample sizes by control frequency. Sample size for a test of controls depends on the tolerable deviation rate, the expected deviation rate, and the acceptable risk of assessing control risk too low, applied with judgment. PCAOB standards leave the tolerable deviation rate to the auditor's judgment. Practice guides and firm methodologies generally use lower tolerable rates, such as around 5 percent, when the auditor wants high assurance from the sample, and higher rates when other tests provide some of the assurance.
The frequency tables in circulation come from audit firm methodologies. Commonly cited firm ranges are one for an annual control, two for quarterly, two to five for monthly, five to fifteen for weekly, twenty to forty for daily, and twenty-five to sixty for controls that run many times a day. These are firm conventions, not regulatory requirements. Treat these as a starting point. Ask your auditor which ranges they use and test to theirs, because a management sample smaller than the auditor's own is a sample they cannot rely on.
A few practical points:
- Event-driven ITGCs such as new users, terminations and changes are sampled from the population of events, not from calendar dates. The population's completeness is part of the test.
Automated controls and configurations are often tested once, by inspecting the setting and running one transaction through it, provided the ITGCs around the application are effective. This is common auditor practice rather than a fixed rule. Auditors can benchmark an unchanged automated control from a prior year only when change, access and operations ITGCs are effective and still tested, and the baseline must be re-established periodically.
- One deviation in a sample usually means the tester either expands the sample to show the deviation was isolated, or concludes the control did not operate. Firm methodologies differ on which, and on how many additional items are needed. Expanding the sample is not a way to dilute an exception. If the cause is systemic, more items just find more of it.
IPE: the reports behind the controls
Information produced by the entity (IPE) is any report, query, extract or spreadsheet a control relies on. The user list in an access review, the change log, the aging report a controller reviews. When an auditor uses company-produced information, they must test its accuracy and completeness, or test the controls over it, and judge whether it is precise and detailed enough. PCAOB inspections have repeatedly cited audits for not doing this well enough.
What good IPE evidence looks like depends on the type of report:
- Standard system reports that have not been modified: evidence that the report is standard and unmodified, the parameters used (date range, entity, filters) captured at the time it was run, and a reconciliation of totals to a source such as the general ledger.
- Custom reports and queries: the logic itself, reviewed by someone who can read it, plus a test that ties records in the report back to the source and records in the source forward to the report. Both directions matter. One proves accuracy, the other completeness.
- Spreadsheets: the inputs traced to their source, formulas checked, and access and version controls over the file. A spreadsheet that feeds a key control is itself in scope.
Screenshots should show the parameters, the run date and the user, not just the output. Re-test custom report logic when it changes, and confirm each period that it has not. Change management ITGCs over the reporting tool are what let you rely on last year's logic test.
Cloud, SaaS and service organizations
Moving an application to a SaaS provider moves some ITGCs to the provider. It does not move all of them.
SOC 1 Type 2 reports are the evidence for the provider's side. A Type 1 report has no operating effectiveness tests, so it cannot reduce your testing much. A SOC 2 is generally not designed for financial reporting reliance, and a SOC 3 omits the test detail entirely. Read each SOC 1 for the opinion, the scope, the period, the exceptions and what they mean for you.
Complementary user entity controls (CUECs) are the controls the provider assumes you run, such as approving your own users, reviewing access, and controlling the configurations you can change. The service organization's description of its system in the SOC 1 report should list them. Map each one to a control of yours and test it. Getting the report does not end your work.
Carved-out subservice organizations, typically the cloud hosting provider underneath a SaaS application, are excluded from the vendor's report. You need that provider's own report, or another basis for comfort.
Bridge letters cover the gap between the SOC 1 period end and your fiscal year end. A bridge letter is a statement by the provider's management, not tested assurance. A short gap with a clean letter is usually workable. A long one can call for more procedures, so ask your auditor where their threshold is.
ITGCs are not your security program
A security framework assessment and ITGC testing overlap but answer different questions. ITGCs for SOX care about whether financial data and the logic processing it can be changed without authorization. Confidentiality, vulnerability management, endpoint protection and incident response matter to the business, but most sit outside SOX scope unless they bear on financial data integrity. Security frameworks such as ISO 27001 are not designed to provide assurance over financial reporting and generally cannot replace a SOC 1 report or ITGC testing, though auditors occasionally consider them as supporting evidence.
The practical risk runs both ways. Folding the whole security program into SOX inflates the control count and the testing bill. Assuming a security certification covers SOX leaves the change and access controls over the general ledger untested. Keep a clear map of which controls serve which purpose, and test once where one control serves both.
What auditors reject in management's testing
From the inspection side, these are the patterns that stop an auditor from relying on management's work:
- Population not shown complete. The sample came from a list nobody validated.
- Ticket-side change populations with no reconciliation to what reached production.
- Review evidence that shows only a sign-off. No indication of what was examined, what was questioned or what was resolved.
- IPE assumed, not tested. The report behind the control was never checked for completeness and accuracy.
- Sample sizes below the auditor's methodology, or samples taken only from part of the period.
- Exceptions explained away. A deviation noted as "isolated" without the analysis to support it.
- Interim testing with no roll-forward to year end.
- Tester objectivity. The person testing the control reports to the person who performs it.
Rejection is rarely about effort. It is about evidence a reviewer cannot reperform.
How the external auditor relies on management's testing
Your auditor decides how much of your work to use, and evaluates how far that work can reduce their own. The factors are competence and objectivity. Objectivity is lower when the testers report to the person responsible for the control they test, or lack access to the audit committee. Higher-risk areas generally get less reliance on others regardless.
To make reliance possible:
- Agree the methodology with the auditor before testing starts: sample sizes, IPE approach, documentation standard, timing.
- Use testers who are independent of the control and its owner, with the IT audit competence the domain needs.
- Write workpapers another tester could reperform: the attribute tested, the population source and its validation, the items selected, what was inspected, and the conclusion.
- Time interim testing so a roll-forward is practical, and plan that roll-forward in advance.
Expect the auditor to reperform some of your work. Findings in that reperformance, missing evidence, or changes to the control after you tested it are the usual triggers for broader reperformance or loss of reliance.
Deficiencies, remediation and retest
When an ITGC fails, start with impact analysis. Identify which applications and which dependent controls relied on it: automated controls, key reports and IT-dependent manual controls. Then decide whether direct testing of those controls, or a compensating control, covers the risk for the period. The failed control usually cannot be fixed retroactively. The question is what else provides comfort for the months it did not work.
Remediation then has three parts: fix the design or the execution, let the fixed control run long enough to produce evidence, and retest it. How long is long enough depends on frequency. A daily control can usually show effectiveness over a shorter period than a quarterly one, and a year-end control can only be shown at year end. How long is enough is a matter of auditor judgment. SEC guidance allows management to conclude ICFR is effective at year end if material weaknesses are remediated, and the fixed controls have operated long enough to be tested, by then. Management should still consider disclosure. Work back from the calendar. A quarterly control fixed in November may not run enough times to be tested.
Where we come in
We document and test ITGCs and the business process controls that depend on them, to the standard an external auditor applies to its own work, so the auditor can use them. How much they rely on is their call, and the opinion stays theirs. We are an advisory firm, not a CPA firm. The ITGC and business process testing service usually runs four to eight weeks and delivers a control matrix, narratives, a walkthrough and test workpaper per control, an evidence index, and an exceptions summary with a recommendation for each. Key report and SOC 1 reviews run two to four weeks, alongside that work or on their own.
The standard comes from years of defending audit work through annual PCAOB inspections; the experience page has the detail. If an auditor, examiner or regulator writes up a deficiency on a control we documented and tested, we remediate it at no charge. The full terms are on the home page.
Start with a free two hour scoping call. Send the date of your audit planning meeting and a line on what has changed in your systems this year.
Frequently asked questions
How many ITGCs should we have?
Enough to cover the access, change and operations risks for each in-scope application, and no more. SEC guidance does not require management to identify every control in a process, only those addressing the risk of material misstatement. Many programs carry duplicates that test the same risk twice.
Can we use the same sample sizes every year?
You can use the same method. Auditors are expected to vary the nature, timing and extent of their own testing from year to year to keep it unpredictable., so expect their selections to change even if yours do not.
Does a SaaS vendor's SOC 2 cover our SOX ITGCs?
Usually not. SOX reliance generally rests on a SOC 1 Type 2, plus your own testing of the complementary user entity controls. If a vendor offers only a SOC 2, ask your auditor early what additional evidence they will need.
Will our auditor accept testing done by a consultant?
They may, if the work is competent, objective and documented to their standard, and they decide how much to rely on it. Agreeing the approach with them before testing starts is the single best predictor that the work gets used.
Do we have to test ITGCs before an IPO?
Management's first ICFR assessment is generally due with the second annual report after the offering. Material weaknesses found before then can still be disclosed in the registration statement, so testing early leaves time to fix what you find.