SOX IT general controls: a technical checklist for engineering teams

SOX IT general controls are the access, change, development and operations controls on systems that produce financial reporting. Engineers implement them by limiting who can reach financial systems and data, requiring approved and tested changes, controlling releases and jobs, and keeping dated records. Scope them to what matters for financial reporting risk.

Where the four areas come from

Section 404 of the Sarbanes-Oxley Act has public companies assess internal control over financial reporting each year, with an independent auditor attestation where required. The SEC's 2007 interpretive guidance for management says the evaluation should consider IT general controls relevant to the applications providing IT functionality. It lists program development, program changes, computer operations, and access to programs and data as areas to consider, and says management only needs to evaluate those IT general controls necessary for the proper and consistent operation of other controls that address financial reporting risks. The SEC also pointed to the COSO framework as a suitable basis for the assessment.

That scoping sentence is your friend. You do not need to control every system, only those whose failure could cause a material misstatement through automated controls, reports or data.

Step zero: find the in-scope systems

Ask finance which applications support significant accounts: ERP, general ledger, consolidation, billing, revenue recognition, payroll, treasury, expense tools and the databases, operating systems and cloud accounts beneath them. Include interfaces that move data between them and any spreadsheets or scripts that feed reported numbers. Record the list with business owner and technical owner.

Checklist: access to programs and data

• Central identity provider with MFA for in-scope applications, databases and cloud consoles.
• Documented joiner, mover and leaver process, with leaver access removed within a window you define and can evidence.
• Role-based access with approval by the business owner; no shared accounts.
• Privileged access limited, logged and reviewed. Direct database write access in production is exceptional and approved.
• Periodic access reviews by business owners, with the list used, reviewer, decisions and removals recorded.
• Segregation of duties rules for conflicts, such as creating and approving a payment, with a check or compensating control.
• Service accounts and API keys inventoried, owned and rotated.

Checklist: program changes

• Every change to in-scope code, configuration and infrastructure has a ticket, a reviewed pull request, test evidence and an approver who is not the author.
• Branch protection and deployment pipelines enforce the above, so bypasses are technically restricted.
• Separate development, test and production environments with access differences.
• Emergency changes follow a defined path with after-the-fact approval within a stated time.
• Release records tie deployed versions to approved changes, and detection exists for changes made outside the pipeline.

Checklist: program development and implementation

• A documented lifecycle for new systems and major upgrades: requirements, design review, testing, business sign-off and go-live approval.
• Data conversion and migration controls with reconciliations.
• Training and user acceptance records for finance users.

Checklist: computer operations

• Job scheduling controlled by authorised people, with alerts on failures and a record of fixes.
• Backups scheduled, monitored and restores tested.
• Incident and problem management with tickets and resolution evidence.
• Monitoring of availability and security events for in-scope systems.

Evidence: populations and samples

Auditors test by sampling. For each control, be ready to produce a complete population for the period: all changes deployed, all new users, all leavers, all privileged access grants. Then show the evidence for any item they pick. Build exports now, not during testing.

Pitfalls

Treating tool configuration as proof without showing it operated all year. Access reviews approved by someone who cannot judge the access. Developers with production admin rights. Changes that bypass the pipeline during an incident with no follow-up. Controls that exist at year end but not before.

What to do

1. Get the in-scope system list from finance and confirm technical owners.
2. Draw a control matrix: control, system, owner, frequency, evidence source.
3. Configure enforcement in tools first, then document it.
4. Produce an export for every population from the first month.
5. Schedule access reviews and change reviews on the calendar.
6. Keep a deficiency log with remediation dates.
7. Ask your internal audit or auditor to walk through the matrix before testing.

Quick check

How Safeguard helps automate this

Change management evidence is the most repeated ITGC request, so it benefits most from automation. 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, which saves time for other work. Technical evidence comes from your real code and dependencies: scans, SBOMs and reachability. Autonomous remediation can open tested fix pull requests, which arrive as reviewable changes; it is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. Your external auditor forms the opinion; Safeguard does not replace them. Book a call.

Sources

• SEC Commission Guidance Regarding Management's Report on Internal Control Over Financial Reporting (Release 33-8810, 2007): role of IT general controls.
• PCAOB AS 2201 blocked our fetch; auditor expectations here are described generally.

Last reviewed: 18 October 2026.