First year SOX IT general control failures cluster in access, change management and operations: scope drawn too loosely, access reviews that skip privileged accounts, changes that bypass approval, populations that cannot be reproduced, and hosted systems nobody owns. Each is cheap to fix before the auditor tests it.
Why do these mistakes matter?
The auditor's standard, PCAOB AS 2201, treats general controls over program changes, access to programs and computer operations as the basis for relying on automated controls. If those fail, the audit may need more manual testing of financial processes. (I read the standard via an archived copy because the PCAOB site blocked automated access. Ask your auditor about their specific test approach.)
Mistake 1: scope by guesswork
Teams either list every system or only the general ledger. Neither works. Start from the financial reporting processes, trace to the applications that run key controls, and add the databases, operating systems, cloud accounts and interfaces beneath them. Write down why anything is left out.
Mistake 2: access reviews that stop at the application
A review that approves a list of application users but ignores the database, the operating system and the cloud console misses where real power sits. Include privileged and service accounts, and record who reviewed, when, what they changed and how removals were confirmed. Reviewers need to understand the roles, so give them role descriptions.
Mistake 3: leaver access that lingers
Compare HR termination dates with account disable dates, for every in scope system. A gap of days is a finding. Automate the comparison and keep the output.
Mistake 4: developers who can ship to production alone
Segregation of duties is a classic test. If the same person can write, approve and deploy a change, you need a compensating control, such as mandatory pull request review enforced by branch protection plus alerts on direct pushes. Keep the setting export as evidence.
Mistake 5: emergency changes that never get reviewed
Outages happen and fast fixes are normal. The mistake is skipping the after the fact approval. Make the emergency path explicit, require a ticket within a set time, and review all emergency changes at a regular meeting. Count them. A rising number tells you something.
Mistake 6: evidence you cannot reproduce
The auditor will ask for a complete list of the population, then pick samples. If you built the list by hand, you may not be able to rebuild it. Save the query or report definition, its run date and the system it came from. Check that the list is complete, for example by comparing totals with another source.
Mistake 7: overlooking operations controls
Teams focus on access and change and forget job monitoring, backups and incident handling. For financial interfaces and batch jobs, show that failures are detected, investigated and fixed. For backups, show restore tests, not only a successful job log.
Mistake 8: treating SaaS providers as out of scope
If a hosted application supports a key control, you must still get assurance. That usually means obtaining the provider's independent report, reading its exceptions and confirming that you perform the user controls it expects. Put a named owner and a yearly date on this.
Mistake 9: control owners who do not know they are owners
A control matrix nobody has read fails in the first sample. Hold a short kickoff with each owner, show them the evidence expected and calendar the due dates.
What to do
- Redraw scope from financial processes down to infrastructure.
- Add databases, operating systems and cloud accounts to access reviews.
- Compare HR leavers to disable dates monthly.
- Enforce pull request review and keep the settings export.
- Define and review emergency changes.
- Save the queries behind each population.
- Test restores, and review job failures.
- Collect and read provider assurance reports.
- Brief every control owner.
Quick check
What is a population in an ITGC test?
The complete set of items a control applies to in the period, such as all leavers or all production changes. The auditor samples from it, so it must be complete and reproducible.
Do emergency changes need approval?
They need an explicit path and a documented review, even if approval happens after the change. Confirm the design with your auditor.
How Safeguard helps automate this
Most of these mistakes are about records that exist only in someone's head or inbox. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between audits. Technical evidence comes from your real code and dependencies, using scans, SBOMs and reachability, which supports the change and vulnerability handling story. Safeguard's agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically. Safeguard helps prepare and keep evidence ready. The auditor decides what passes. Book a call to discuss.
Sources
Last reviewed: 18 October 2026.
