The Sarbanes-Oxley Act (SOX) is the US law that makes executives personally accountable for the accuracy of financial reports – and, through internal control over financial reporting (ICFR), makes your technology estate part of that accountability. Section 302 has the CEO and CFO certify each filing; Section 404 requires management to assess ICFR annually, with the external auditor independently attesting for accelerated filers. Because every material financial figure now flows through software, auditors test the systems beneath the numbers – and that is where IT general controls (ITGCs) come in, along with the engineering teams who suddenly find themselves in audit scope.
Why the IT controls existLink to this section
The logic is simple: the finance team's controls assume the systems tell the truth. An automated three-way match, a calculated depreciation figure, a revenue report – all are only as reliable as the platform they run on. If unauthorised people can change data, if developers can push unreviewed code into the ERP, if a failed interface job goes unnoticed, then every downstream financial control silently degrades. ITGCs are the controls that keep the systems trustworthy, and audit firms group them into four domains: access to programs and data, program changes, program development, and computer operations – exactly how the table below is organised.
Who ends up in scope (including in Australia)Link to this section
SOX binds companies listed on US exchanges – including foreign private issuers, which is how Australian companies with a NYSE or Nasdaq listing (or ADR programme) inherit it, subsidiaries included. But its reach is wider through two side doors. First, if your company hopes to IPO in the US, SOX readiness is part of the run-up, and retrofitting controls in the S-1 year is miserable – build earlier. Second, if you're a SaaS or service provider whose product touches customers' financial data (billing, payroll, payments, ERP add-ons), your customers' SOX auditors will ask what happens inside your platform – and the answer they accept is a SOC 1 report, which is ITGC discipline audited in your own house. Many of our engagements start exactly there.
What fieldwork actually looks likeLink to this section
SOX testing is refreshingly concrete. The auditor takes your control matrix, samples real instances, and asks for evidence: these 25 access grants – show me the approvals. These 25 production changes – show me review, testing, and who deployed. This quarterly access review – show me it happened, and that flagged access was actually removed. Three lessons follow. Evidence must be generated by the process, not reconstructed after it – controls that rely on someone remembering to screenshot fail within a quarter. Precision matters – a control described as "management reviews access periodically" is untestable; "system owners recertify all access quarterly, revocations within five business days" passes. And one person's convenience is the classic deficiency – the developer with production admin rights, the finance manager who can create and approve vendors. Deficiencies aggregate upward toward material weakness, which is publicly disclosed and board-visibly painful.
Engineering-friendly SOX is possibleLink to this section
The bad version of SOX bolts a manual bureaucracy onto a modern engineering organisation – change advisory boards, wet-ink approvals, quarterly screenshot hunts. The good version notices that your existing toolchain already produces better evidence than paper ever did: branch protection enforces segregation of duties, PR approvals are timestamped and immutable, CI records testing, deployment logs identify who shipped what. We design ITGCs that are your pipeline, with the gaps closed – which auditors increasingly prefer, because the evidence is complete and tamper-resistant by construction.
How SOX relates to other frameworksLink to this section
The ITGC domains are a subset of what ISO 27001 and SOC 2 already demand – access control, change management, operations – scoped to financially relevant systems and tested with more sampling rigour. If you run those programmes, SOX reuses their controls; if you're building from scratch, SOX-grade discipline gives you a strong core for both. For service providers, SOC 1 is the report that answers your customers' SOX questions, and we prepare you for it with the same control set.
How we helpLink to this section
We sit deliberately between the auditors and the engineers, fluent in both dialects:
- Scoping and control design. We identify the systems that genuinely affect financial reporting, right-size the control matrix, and write controls precisely enough to test – and loosely enough to live with.
- Pipeline-native implementation. Access workflows, change control, and operations monitoring built into your identity provider, Git platform, and CI/CD – evidence as a by-product, not a project.
- Readiness and remediation. Pre-audit walkthroughs and sample testing so deficiencies surface with time to fix, plus remediation of the findings your auditor has already raised.
- Control-owner training, evidenced. Owners and reviewers trained on what their controls require and what their sign-off asserts – on our platform, with tamper-evident completion records that slot straight into the audit file.
- SOC 1 for providers. If your customers are the ones under SOX, we build and evidence the ITGC set their auditors need to see, through to your Type II report.
The table below sets out a typical ITGC control matrix and how we help with each control.
IT general controls (a typical SOX control matrix)
Access to programs and data
| Ref | Control | How we help |
|---|---|---|
| AC-01 | User access provisioning and deprovisioning | We wire joiner/mover/leaver workflows into your identity provider and ticketing so every grant has an approval and every departure has a removal date – the two samples auditors always pull first. |
| AC-02 | Privileged and administrative access | We minimise who holds admin rights over financially relevant systems, separate day-to-day from privileged accounts, and log privileged activity so it can be reviewed, not just trusted. |
| AC-03 | Periodic user access reviews | We stand up quarterly access recertification with system owners, tracked to completion, with revocations actioned and evidenced – a review without records is a finding. |
| AC-04 | Authentication and segregation of duties | We enforce MFA and password policy on in-scope systems and build the SoD matrix that keeps any one person from both creating and approving a payment, a vendor, or a journal entry. |
Program changes
| Ref | Control | How we help |
|---|---|---|
| CM-01 | Change authorisation, testing, and approval | We fit SOX-grade change control into your existing engineering workflow – PR-based approvals, test evidence, and deployment records – so compliance rides your pipeline instead of fighting it. |
| CM-02 | Segregation of development and deployment | We ensure developers can't push their own changes to production unreviewed, using branch protection and deploy gates rather than slow manual handoffs. |
| CM-03 | Emergency changes | We define the break-glass path – act fast, then document, review, and approve retrospectively – so incidents don't become audit findings a quarter later. |
Program development
| Ref | Control | How we help |
|---|---|---|
| DV-01 | System development and acquisition life cycle | We apply proportionate SDLC controls to projects that touch financial reporting – requirements, testing, approval to go live – sized for agile delivery, not waterfall theatre. |
| DV-02 | Data conversion and migration | We control and evidence data migrations into financial systems – reconciliations, validation, and sign-off – so opening balances survive auditor scrutiny. |
Computer operations
| Ref | Control | How we help |
|---|---|---|
| OP-01 | Job scheduling and batch processing | We monitor the scheduled jobs that feed the ledger – interfaces, postings, reconciliations – with failure alerting and documented follow-up on every miss. |
| OP-02 | Backup and recovery | We implement backup for financially relevant systems and test restoration on a schedule, because "the backup ran" and "the data comes back" are different assertions. |
| OP-03 | Incident and problem management | We build incident procedures that capture financial-reporting impact, with root-cause analysis and remediation tracking your auditors can walk through. |
Entity and process level
| Ref | Control | How we help |
|---|---|---|
| EL-01 | Information produced by the entity (IPE) and key reports | We inventory the reports and queries your controls rely on, and lock down their logic and parameters – because a control fed by an unvalidated report fails with it. |
| EL-02 | End-user computing and spreadsheets | We find the spreadsheets that secretly run your close, then protect, version, and review the ones that must stay – and migrate the ones that shouldn't. |
| EL-03 | Vendor and service organisation reliance | We map your outsourced systems (payroll, billing, ERP hosting) to their SOC 1 reports, review them properly, and test the complementary user controls those reports quietly assign to you. |
| EL-04 | Control-owner competence and training | We train control owners and reviewers on what their sign-off means and what evidence it requires – delivered on our platform with tamper-evident completion records for the audit file. |