SOX IT General Controls

IT General Controls (ITGCs) are the IT controls that support the reliability of financially significant applications and data. Business process controls almost always depend on technology: the ERP enforces the three-way match, the billing system calculates revenue, the close checklist lives in a workflow tool, and every reconciliation starts from a system-generated report. ITGCs are what let you — and your auditor — trust that those systems do what they're configured to do, all year.

The dependency is the whole point, and it works in reverse too: when ITGCs fail, everything built on them wobbles. If change management over the ERP is ineffective, the auditor can no longer assume the automated three-way match worked in March just because it works in December ("benchmarking" reliance breaks). If access controls fail, segregation of duties conclusions fail. If report logic isn't under change control, every management review control consuming those reports inherits an IPE problem. This cascade is why an ITGC deficiency that looks technical routinely gets evaluated as a significant deficiency — and why ITGCs are tested every single year with little sympathy for "nothing changed."

Scoping: Which Systems and Which Layers

ITGC scope derives from the financial scoping in your 404 risk assessment: for each significant account, which applications initiate, process, record, or report the data? The usual suspects: the ERP/general ledger, revenue and billing systems, payroll and stock compensation platforms, treasury systems, consolidation and close tools, and any warehouse or reporting layer producing IPE used by key controls.

For each in-scope application, controls apply across the technology stack, not just the app:

Spreadsheets deserve a word: complex, financially significant spreadsheets (models for impairment, tax provisions, allowance calculations) are treated as end-user computing — needing access restriction, version control, and input/logic validation. Auditors increasingly push these calculations into governed systems precisely because spreadsheet ITGCs are painful.

Domain 1: Access Management

Access controls ensure only authorized individuals have access to financially significant systems and data — and only the access their role requires. The controls auditors test:

• Provisioning: new access requests documented and approved by an appropriate owner before granting; role-based where possible.
• Deprovisioning: access removed timely upon termination or transfer. Auditors compare the HR termination list against system access logs and measure the gap in days; anything beyond your stated SLA (commonly 1–3 business days) is an exception, and terminated users who logged in after termination are a serious one.
• Periodic user access reviews (UARs): typically quarterly for financially significant systems — a designated reviewer examines each user's access, confirms appropriateness, and removals identified are actually executed and evidenced. UARs fail testing when reviewers rubber-stamp, when the user population is incomplete, or when flagged removals never happen.
• Privileged access: administrator, superuser, and direct database access restricted to a small, justified population; activity of privileged users monitored or logged; generic/shared accounts eliminated or vaulted with check-out logging.
• Segregation of duties (SoD): no single user able to both create and approve within a critical flow (create vendor and pay vendor; post and approve journals; change payroll and run payroll). Where SoD conflicts are unavoidable in small teams, a documented mitigating control (e.g., independent review of the conflicting activity) must exist and be tested.
• Authentication: password policy, MFA, and — in SSO environments — controls over the identity provider itself, since IdP admin rights confer access to everything downstream.

Domain 2: Change Management

Change controls ensure that changes to applications, interfaces, reports, and infrastructure supporting financial reporting are authorized, tested, approved, and deployed by someone other than the developer. The tested elements:

• Authorization and tracking: every change tied to a ticket with documented approval.
• Testing before production: evidence of testing appropriate to the change's risk, in a non-production environment.
• Approval to deploy: a documented go-decision by someone with authority.
• Segregation of environments and duties: developers do not have unmonitored ability to push their own code to production. This is the single most contested ITGC in modern engineering organizations — more below.
• Emergency changes: a defined fast path with retrospective approval and review, used rarely; a high emergency-change ratio is itself a red flag.
• Completeness of the change population: auditors don't just sample your tickets — they pull the system-generated deployment or change log and reconcile it against tickets. Changes in production with no ticket are automatic exceptions. If you cannot produce a reliable change population, the domain can fail wholesale.

DevOps and CI/CD are compatible with SOX — but the controls move into the pipeline: enforced peer review on pull requests (with the branch protection settings themselves under change control), automated test gates, deployment restricted to the pipeline identity rather than humans, and immutable logs of who approved and what deployed. What auditors will not accept is engineers with standing direct-to-production write access and no independent review. If a small team truly cannot separate duties, the mitigating control is typically a periodic (weekly/monthly) independent review of production changes against approvals — documented and performed with rigor.

Configuration changes count too: changes to ERP workflow rules, approval limits, chart of accounts, and report logic are "changes" even when no code ships.

Domain 3: IT Operations

Operations controls ensure systems process data completely and accurately day to day, and that data survives incidents:

• Job scheduling and monitoring: financially relevant batch jobs (interfaces posting sub-ledger data to the GL, billing runs, payroll processing) are monitored; failures generate alerts, and there is evidence failures were resolved — the finding is rarely "a job failed," it's "the job failed and no one noticed for two weeks."
• Interface monitoring: completeness and accuracy checks (record counts, control totals) on data moving between systems feeding the ledger.
• Backup and recovery: financial data backed up on a defined schedule, failures monitored, and restoration tested periodically — an untested backup is an assumption, not a control.
• Incident and problem management: incidents affecting financial systems logged, resolved, and escalated where financial data integrity is implicated.
• Batch/job change control: schedule changes and new jobs follow change management.

Domain 4: Program Development (SDLC)

Where operations covers routine changes, program development covers new systems and major implementations: an ERP migration, a new billing platform, a consolidation tool rollout. Controls include a defined methodology, documented requirements and design, testing including user acceptance by finance, data conversion validation (reconciling converted balances and open items between old and new systems — the highest-risk step of any migration), formal go-live approval, and post-implementation review.

A mid-year ERP migration is simultaneously a program-development testing event and a material change in ICFR disclosable under Section 302 — and it typically forces dual testing of old-system and new-system controls for their respective portions of the year. Plan migrations with the SOX calendar in mind; a Q4 ERP cutover is asking for a painful audit.

Cloud and Third-Party Considerations

For SaaS and cloud infrastructure hosting financial data, responsibility splits:

• The provider's side — physical security, infrastructure operations, their own change management — is covered by obtaining and reviewing the provider's SOC 1 Type II report. Your obligations: verify the report covers your services and period, review exceptions and their relevance, bridge any gap between report end and your year-end (via a bridge letter), and — critically — implement and test the complementary user entity controls (CUECs) the report assumes customers perform. Unreviewed CUECs are a routine first-year finding.
• Your side never disappears: user access administration in the SaaS app, configuration changes you make, integrations you build, and admin access to your cloud accounts (IAM, root/break-glass accounts, infrastructure-as-code pipelines) remain your ITGCs to design and evidence.

ITGC Checklist

• In-scope application inventory derived from 404 scoping, covering all stack layers per system
• Access provisioning requires documented pre-approval; roles defined for financial systems
• Terminations feed automatically (or same-day) from HR to access removal, with SLA measured
• Quarterly user access reviews executed with complete populations and evidenced remediation
• Privileged and direct-database access minimized, justified, and logged; no shared admin accounts
• SoD conflicts analyzed; unavoidable conflicts covered by tested mitigating controls
• All production changes tied to approved tickets; deployment log reconciled to tickets for completeness
• Developer direct-to-production access removed, or pipeline controls plus independent review in place
• Emergency change procedure defined, rare, and retrospectively approved
• Financial batch jobs and interfaces monitored with evidenced failure resolution
• Backups scheduled, monitored, and restoration-tested with documentation
• SOC 1 Type II reports collected for all relevant providers; exceptions assessed; CUECs mapped and tested
• System implementations follow SDLC controls with data conversion reconciliation and go-live approval
• Key financial spreadsheets inventoried with access, version, and validation controls

Frequently Asked Questions

Which frameworks do ITGCs map to — COBIT, COSO, something else?

ITGCs sit inside your COSO-based ICFR assessment (COSO Principle 11 covers general controls over technology). Many organizations borrow structure from COBIT or ISO 27001 for design, but the audit is not against those frameworks — it is against whether these controls support reliable financial reporting. If you already run SOC 2 or ISO 27001, much of the control fabric overlaps; the SOX difference is scope (financial systems only) and evidence rigor (population completeness, precise SLAs).

Are ITGC deficiencies automatically material weaknesses?

No — an ITGC deficiency on its own usually cannot cause a misstatement directly; its severity depends on what it exposes. The evaluation asks: which application controls and IPE relied on the failed ITGC, and could the resulting misstatement be material? A UAR gap on a peripheral system may stay a control deficiency; broken change management over the ERP frequently aggregates into a significant deficiency or, combined with other issues, a material weakness. Pervasive ITGC failure across domains is one of the most common material weakness fact patterns in real disclosures.

Our engineers deploy to production twenty times a day. Are we doomed?

Not at all — continuous deployment with enforced PR review, automated test gates, pipeline-only deploy credentials, and immutable audit logs is stronger evidence than a monthly change advisory board, because the control is systematic rather than human. The work is making the pipeline itself auditable: branch protection settings under control, review requirements that can't be bypassed, and the ability to produce a complete deployment population on demand.

What population and sample sizes should we expect for ITGC testing?

Auditors first establish completeness of each population (all hires, all terminations, all changes) from system-generated sources, then sample: commonly around 25 items for high-frequency populations like changes and provisioning, all items or large portions for small populations like terminations and admin access, and each occurrence for quarterly controls like UARs. The population-completeness step is where unprepared teams stumble — know how you'd prove "this is every change that hit production this year."

Do we need ITGCs over our identity provider and HR system?

Almost certainly yes, as security-impacting systems: the IdP gates access to every financial application behind SSO, and the HR system is the trigger and source-of-truth for provisioning and termination controls. They are typically scoped for the ITGC domains relevant to the reliance placed on them, even though neither posts a journal entry.

How do ITGCs differ from application controls?

Application controls live inside a business process and address specific assertions — the system blocks a duplicate invoice, calculates depreciation, enforces an approval limit. ITGCs are the environment controls that keep those application controls trustworthy over time. Auditors test an automated application control lightly (often a single instance) precisely because ITGCs give them confidence it operated consistently — which is the reliance that evaporates when ITGCs fail.

In the next lesson, we will cover SOX audit preparation.

Most ITGC evidence — access reviews, change logs, termination tie-outs — can be automated instead of screenshotted. AuditXYZ helps you compare compliance automation platforms and auditors to find tools that handle SOX ITGC evidence collection.