.webp)
ITGC covers a lot of ground on paper. In practice, access controls, who has access to systems that touch financial data, and whether anyone can prove it, are consistently one of the categories that carry the most weight in a SOX 404 audit.
Ask five IT managers what SOX ITGC covers and you'll get five different answers: change management, patch cycles, backup schedules, physical security, access controls. All technically correct. All in scope on paper.
Access controls are consistently one of the categories auditors flag most. User provisioning and deprovisioning, segregation of duties, and access reviews show up again and again in lists of the most common ITGC deficiencies, right alongside change management gaps. It's not the only category worth getting right, but it's reliably one of the two or three that carry the most weight in a SOX 404 assessment, and it's the one most directly tied to a single root cause: someone who left the company six months ago still has login credentials to the ERP, a developer has standing admin rights to production financial data with no documented business reason, or a service account nobody can identify still has write access to the general ledger integration.
If your organization is building or maintaining a SOX ITGC program, the access control piece is where most of your time, and most of your risk, actually lives: what SOX ITGC requires around access, what auditors test, and how to build evidence that survives scrutiny instead of falling apart under it.
What SOX ITGC Actually Requires, Narrowed to Access
ITGC (IT General Controls) exist to support ICFR (internal control over financial reporting) by making sure the systems that process financial data are reliable. Of the control categories that make up ITGC, access controls are the ones auditors weight most heavily, for a simple reason: every other control assumes access is already governed correctly.
Change management assumes only authorized people can push changes. Data integrity assumes only authorized people can touch the data. If access itself isn't controlled, every downstream control inherits that weakness.
The access-specific requirements under SOX ITGC break down into four areas:
Provisioning. New access to financial systems (ERP, general ledger, AP/AR, payroll, and the databases and infrastructure underneath them) must be authorized before it's granted, with documented approval tied to a specific business need.
Deprovisioning. When someone leaves the company or changes roles, access to financial systems must be removed or adjusted within a defined window, not whenever IT gets around to it.
Periodic review (SOX user access review). On a regular cadence, someone independent of the user must confirm their access is still appropriate. This is the control that gets tested most heavily, and the one manual processes struggle with most.
Segregation of duties (SoD). No single person should be able to both initiate and approve a financial transaction, or both create and reconcile records, without a compensating control.
Patch management and generic disaster recovery get bundled into "ITGC" conversations constantly, and they matter for IT risk generally, but they're not identity-driven controls, and they're not where a SOX 404 access exposure actually sits. Access, provisioning, deprovisioning, reviews, and SoD, is consistently one of the two or three ITGC categories that carry the most weight in a SOX 404 assessment, which makes it the highest-leverage place to focus if you're building or tightening a program.
Access is the core of it. But "access" in SOX ITGC extends further than the four items above once you follow it through the rest of the control environment.
Where Access Governance Extends Into the Rest of ITGC
Access controls don't sit in isolation from the other ITGC categories auditors test. Once identity is governed properly, it naturally extends into three more areas:
Network and systems security controls. Enforcing least privilege (giving people access only to what their role requires), catching shadow IT before it becomes an unmonitored path into financial data, and building in time-bound access that expires automatically instead of lingering indefinitely, these are all extensions of the same access governance discipline, not a separate control category.
Physical security controls. This category usually means data center access, but for most SaaS companies the more relevant version is device-level: when someone leaves, can you remotely lock or wipe the devices that had access to financial systems, immediately, not whenever IT gets to the ticket. Tying device management to the same offboarding trigger that revokes application access closes a gap that's easy to miss when access and device controls live in separate tools.
Incident management controls. When something goes wrong, auditors want a record: who had access, what changed, and when. Maintaining audit logs on access changes, unauthorized app usage, and resource deletions as a byproduct of the access governance process, rather than a separate logging project, is what turns "we think we'd notice" into "here's the log."
Data processing controls (encrypting personal data, controlling how it moves between systems) sit slightly further from pure access governance, but they follow the same logic: access to sensitive data should be provably restricted, not just assumed. The common thread across all four extensions is that they're identity-centric, not infrastructure-centric. That's a meaningfully different scope than a general IT risk program covering patch cycles and backup schedules, and it's why an access-first approach to ITGC ends up covering more ground than "just access reviews" implies.
Why Manual Access Controls Fail SOX ITGC Testing
The failure pattern is consistent across companies of very different sizes.
An IT team runs quarterly access reviews using exported spreadsheets. A manager gets a list of their team's access, replies "approved" over email, and the spreadsheet gets filed. When the auditor asks for evidence, that's what gets handed over.
The problem isn't that the review didn't happen. It's that the evidence can't answer the questions auditors actually ask:
Was this the complete list of users with access to financial systems on the day of the review, or just the users someone remembered to export?
Can you show who made each decision, and when?
If access was flagged for removal, can you prove it was actually removed, not just that a ticket was created?
Spreadsheets and email threads don't hold up against that level of scrutiny. Auditors sample individual users and trace them through the entire process: were they in scope, were they reviewed by an appropriate independent reviewer, was the decision documented with a timestamp, and if remediation was required, is there before-and-after proof it happened. Manual processes usually fail somewhere in that chain, most often at the "proof remediation happened" step, since IT tickets sit in a backlog and nobody circles back to confirm closure.
What SOX ITGC Auditors Test, Specifically
Three things come up in nearly every SOX ITGC access control test:
Completeness of scope. Auditors don't just check whether you reviewed your ERP users. They ask how you determined that was the complete list of systems touching financial data, including databases with direct access, cloud infrastructure, and service accounts. Missing a category here is one of the most common findings.
Independence of the reviewer. The person approving access changes generally shouldn't be the same person who requested or granted that access. Auditors check whether the reviewer had the authority and the context to make an informed decision, not just a rubber stamp.
Operating effectiveness over time. A control that exists on paper but wasn't consistently followed for the whole audit period is treated as ineffective. Auditors want to see the control operating across multiple review cycles, not reconstructed after the fact.
Building ITGC Access Control Evidence That Holds Up
The pattern that works, and the one Zluri is built around, comes down to closing three gaps that manual processes leave open.
Discovery before governance. You can't review access to systems you don't know exist. Before a review cycle starts, you need a complete and current inventory of everything touching financial data, not just the applications IT remembers to include.
Independent, contextual reviews, scoped to how the audit actually needs them. Reviewers need to see enough context (last login, role, department, employment status) to make a real decision, not just approve a name on a list. Routing reviews to the right independent reviewer automatically, rather than relying on someone to remember who owns what, removes a common source of audit findings. This is also where review structure matters: a single rigid review format doesn't fit every ITGC scope. Sometimes an auditor wants to see every user with access to one financial application reviewed together. Sometimes the more useful cut is one access group reviewed across every app it touches. Sometimes it's a single high-risk user's entire access footprint reviewed end to end. Zluri supports all three: application-based, group-based, and user-based reviews, so the review structure can match whatever the audit sample actually asks for instead of forcing every review into the same shape.
Closed-loop remediation with proof. When access needs to be revoked, the system should execute that change and capture before-and-after evidence automatically, rather than generating a ticket that may or may not get closed. This is the single biggest gap between companies that pass ITGC testing cleanly and companies that get flagged.
Zluri's access review capability is built around these three steps specifically for this reason: SOX ITGC testing is fundamentally a test of whether your access governance process is real, repeatable, and provable, not whether it exists on paper.
Frequently Asked Questions
What's the difference between ITGC and ITAC in SOX compliance?
ITGC (IT General Controls) governs the environment around financial systems, including who has access, how changes are managed, and how the systems are administered. ITAC (IT Application Controls) governs specific transactions within an application, such as automated three-way matching or validation rules. ITGC has the broader scope; ITAC restricts what a user can do within a single application.
Which access controls fall under SOX ITGC?
Provisioning of new access to financial systems, deprovisioning when employment or roles change, periodic access reviews, and segregation of duties between conflicting responsibilities. These four areas make up the access-specific portion of ITGC that auditors test most directly.
How often do SOX ITGC access reviews need to happen?
SOX doesn't state a specific frequency in the statute, but because public companies report financials quarterly, auditors expect access review frequency to match: quarterly, at minimum, for systems in SOX scope.
What happens if service accounts are missing from ITGC access reviews?
Auditors specifically test for this gap. Service accounts often carry elevated privileges, don't get deprovisioned when their creator leaves, and rarely appear in standard reviews built around human employee accounts. A missing service account inventory is one of the more common findings in ITGC testing.
Can spreadsheets satisfy SOX ITGC evidence requirements?
Generally not for public companies under Big 4 scrutiny. Auditors expect system-generated logs with timestamped decisions tied to specific reviewer identities, and before-and-after proof that remediation actually occurred. Manually compiled spreadsheets and email approvals typically can't produce that level of evidence at scale.
Does SOX ITGC require controls over physical devices, not just application access?
Yes, at least the identity-relevant slice of it. When an employee leaves, the standard is to be able to immediately lock or wipe the devices that had access to financial systems, not just revoke their application logins. Tying device management to the same offboarding trigger as access revocation is what closes this gap in practice.
.svg)
