Every year, management has to assert that IT general controls over financial reporting actually worked — and produce the testing to back it. If your Australian entity sits in a US parent’s SOX scope, that testing usually lands on a small IT team with no independent tester and no time. We run it: control walkthroughs, sampling, workpapers your external auditor can rely on, and deficiencies found while there is still time to fix them.
IT general controls are the controls over the systems that produce the numbers — not the financial controls themselves, but the ones that make you able to trust the systems underneath. Section 404(a) of the Sarbanes-Oxley Act requires management to assess and formally report on the effectiveness of internal control over financial reporting each year, and that assessment is worthless without evidence. So ITGCs get tested twice over: once by management to support the assertion, and again by the external auditor under 404(b) to attest to it. The distinction that matters operationally is between design and operating effectiveness. A control can be perfectly designed and still fail because someone skipped it in March. Testing has to prove both — that the control would catch the problem, and that it actually ran, every time, across the whole period.
There are three distinct roles in a SOX programme and confusing them is expensive. Management owns the 404(a) assertion and must have the controls tested; in larger groups internal audit performs that testing, and where there is no internal audit function it is either done by the control owners themselves — which fails independence — or outsourced. The external auditor is a PCAOB-registered public accounting firm performing the 404(b) attestation; they test independently and cannot rely on work they helped design. Aegentra operates in the first role: we test on management’s behalf, either as an independent tester or co-sourced alongside your internal audit function, and produce workpapers written to survive the external auditor’s review. We are not a PCAOB-registered firm and do not perform the 404(b) attestation. That separation is the point — if we did both, neither would be worth anything.
Testing follows the four domains external auditors organise their own ITGC work around, scoped to the systems that actually feed the financial statements — typically your ERP, the Microsoft 365 identity layer in front of it, and whatever sits between them. Access to programs and data covers provisioning, periodic user access reviews, privileged and emergency access, segregation of duties conflicts, and terminations processed in time. Program change covers whether changes were authorised, tested and approved before production, and whether developers can move their own code. Program development covers implementations and migrations that hit financial systems during the period. Computer operations covers job scheduling and failure handling, backup and restoration, and incident management. Two things generate most findings in practice: user access reviews performed but not evidenced, and information produced by the entity — the reports and extracts used as testing evidence — with no proof the report itself is complete and accurate.
Most engagements start as one of these and grow into another. Independent ITGC testing is the core: we test the control population for the period, document each test in a workpaper, and hand over a package your external auditor can pick up and rely on. Co-sourced internal audit is the same work, run as an extension of your internal audit function against their methodology and reporting lines — common where a group IA team is stretched across regions and needs the Australian entity covered. A mock ITGC audit is a dress rehearsal, run the way the external auditor will run it, timed early enough that a failed control can still be remediated and re-performed within the period. And where testing has already found a deficiency, we rebuild the control and re-evidence it — though never the same control we then test, which would defeat the purpose.
SOX testing is usually split: interim testing partway through the year, then a roll-forward at year-end covering the remaining period. That structure exists precisely so deficiencies surface while remediation is still possible — a control that fails in interim testing can be redesigned, operated for a few months, and re-tested before the assertion is due. A control that fails at year-end cannot. Deficiencies are classified by severity: a control deficiency is a shortfall, a significant deficiency is serious enough to warrant attention from those responsible for financial reporting, and a material weakness carries a reasonable possibility that a material misstatement would not be prevented or detected — which is disclosable and reaches the parent’s filings. Most material weaknesses in ITGCs are not exotic. They are a user access review that nobody evidenced, or a developer who could still push straight to production in month seven.
| What this service is | Independent SOX ITGC testing supporting management’s Section 404(a) assessment |
|---|---|
| What it is not | The Section 404(b) external audit attestation — that requires a PCAOB-registered firm |
| Framework | Sarbanes-Oxley Act Sections 302 and 404; ITGCs over financial reporting systems |
| Who it is for | Australian subsidiaries of US-listed parents, pre-IPO groups, and SEC registrants |
| Domains tested | Access to programs and data, program change, program development, computer operations |
| Engagement models | Independent testing, co-sourced internal audit, mock ITGC audit, deficiency remediation |
| Testing approach | Design and operating effectiveness, sampled across the full period |
| Deliverables | Test plan, workpapers, findings register with deficiency ratings, remediation plan |
| Timing | Interim testing plus year-end roll-forward |
| Fee | Fixed fee agreed after a scoping call |
| Delivery | Remote-first, Australia-wide; onsite available |
Need the controls built before they can be tested? See SOX ITGC readiness. For how SOX reaches Australian entities in the first place — and how it differs from ISO 27001 and SOC 2 — read SOX compliance in Australia.