SOX ITGC readiness for Australian entities

A US parent's filing obligation lands on your IT team as a control matrix nobody here wrote. We build the IT general controls behind it — access, change, development and operations — inside your own systems, and evidence them across the whole period so the auditor's testing has something to land on.

SOX is not Australian law. It still reaches you.

The Sarbanes-Oxley Act is United States federal law, and it arrives in Australia through ownership rather than jurisdiction. Your Australian entity is in scope when it is a subsidiary of a US-listed parent or SEC registrant and is material to the group’s consolidated financial statements, when you are preparing for a Nasdaq or NYSE listing, or when you are a foreign private issuer with US-listed ADRs. In each case the group’s obligation becomes your control matrix, usually with a deadline attached, and the external auditor tests the Australian systems as part of the group audit.

• Australian subsidiary of a US-listed parent, material to the consolidated numbers.
• Pre-IPO groups preparing for a Nasdaq or NYSE listing.
• Foreign private issuers with US-listed ADRs.
• Entities carrying ITGC findings the parent wants closed before the next cycle.

Sections 302 and 404 — what each one actually requires

Section 302 is a per-filing certification: the CEO and CFO personally certify, in every quarterly (Form 10-Q) and annual (Form 10-K) filing, that the financial statements are accurate and that they have designed and evaluated the disclosure controls behind them. Section 404 is an annual assessment of the control system itself. Section 404(a) requires management to assess and formally report on the effectiveness of internal control over financial reporting; Section 404(b) requires the company’s external auditor to independently attest to that assessment. Aegentra delivers readiness supporting the 404(a) assessment. Aegentra is not a PCAOB-registered firm and does not perform the 404(b) attestation.

• Section 302 — CEO and CFO certification in every quarterly and annual filing.
• Section 404(a) — management’s annual assessment of ICFR effectiveness.
• Section 404(b) — the external auditor’s independent attestation.
• Design effectiveness and operating effectiveness are tested separately.
• Controls must operate, and be evidenced, across the whole period — not at a point in time.

The four ITGC domains we build

IT general controls sit underneath every automated control and every calculation inside a financially-significant application. If they fail, the auditor cannot rely on anything above them, and testing escalates from a sample to substantive work across the population. Four domains carry the weight. Access to programs and data covers provisioning and deprovisioning, periodic user access reviews, privileged and emergency access, and segregation of duties — it generates more findings than the other three combined. Program change covers whether changes to financial systems were requested, tested and approved before production, and whether a developer could deploy their own code. Program development covers implementations and migrations that touched a financial system during the period. Computer operations covers job scheduling and failure handling, backup and restoration, and incident management.

• Access to programs and data — joiner/mover/leaver, user access reviews, privileged access, segregation of duties.
• Program change — request and approval trail, testing evidence, separation of development from production.
• Program development — project sign-off, data migration validation, user acceptance testing, go-live authorisation.
• Computer operations — job scheduling and failure handling, backup and restore testing, incident and problem management.
• Third-party platforms are covered through their SOC 1 Type II report and its complementary user-entity controls.

How a readiness engagement runs

Four phases, fixed scope and fixed price agreed after a scoping call. We start from the group SOX program office’s control matrix and materiality thresholds rather than a generic template, and produce an agreed list of in-scope systems and the controls each one carries. Gap assessment tests every in-scope control the way the external auditor will — design first, then whether it actually operated — and returns a gap register rated by how likely each gap is to become a deficiency. Remediation configures the controls inside your own Microsoft 365 tenant and financial systems. Then evidence: a control that works today is worthless if you cannot show it worked in March, so we set up capture through Aeges before the auditor asks for a sample.

• Scope with the parent — work from the group control matrix and materiality thresholds.
• Gap assessment — every in-scope control tested for design and operating effectiveness.
• Build and remediate — controls configured in your own tenant and financial systems.
• Evidence the period — evidence capture set up so the population exists before testing.
• Deficiency severity runs control deficiency → significant deficiency → material weakness; a material weakness is disclosable and reaches the parent’s filings.

SOX vs ISO 27001 vs SOC 2

These three are routinely confused, and scoping one as though it were another is the most expensive mistake in this area. The control work overlaps on access, change and operations, so mature ISO 27001 or SOC 2 evidence gives you a genuine head start — but SOX scopes tightly to the systems that touch the numbers and tests to financial-audit standards, which is a higher evidentiary bar than most ISMS internal audits apply.

What drives it	SOX: US securities law · ISO 27001: voluntary certification · SOC 2: customer due diligence
Who tests it	SOX: PCAOB-registered audit firm · ISO 27001: JAS-ANZ-accredited body · SOC 2: licensed CPA firm
Scope	SOX: systems touching the financials · ISO 27001: the whole ISMS you define · SOC 2: one service and its criteria
Cadence	SOX: annual with interim testing · ISO 27001: three-year cycle plus surveillance · SOC 2: annual Type II period
You end up with	SOX: a management assertion · ISO 27001: a certificate · SOC 2: an attestation report

Already built the controls and need someone independent to test them? That is SOX ITGC testing, a separate engagement — we never test controls we built. We also deliver ISO 27001 implementation and SOC 2 readiness separately, and map the control overlap so shared evidence is built once rather than three times. For background on how SOX reaches Australian subsidiaries, read SOX compliance in Australia.