Why SOX Reaches Your Vendors
SOX compliance in IT vendor management follows a simple chain of logic: Section 404 requires management to attest to the effectiveness of internal controls over financial reporting, those controls depend on IT general controls (ITGCs), and increasingly the systems that touch financial data are operated by third parties. When your ERP, payroll, billing, or close-management software runs in a vendor's cloud, that vendor's controls become part of your control environment — and your auditor will say so.
The risk is no longer hypothetical. 97% of organisations experienced at least one supply-chain breach in 2025, up from 81% in 2024. A control failure at a vendor that processes financial transactions is a material weakness waiting to be reported. That is why SOX vendor management belongs in the same governance operating model as licence compliance, described in the compliance and governance guide, with clear ownership across IT, procurement, and internal audit.
The IT General Controls That Matter
SOX ITGCs concentrate on the controls that keep financial data accurate and protected. Two domains carry most of the weight in a vendor context. The first is program change controls: modifications to financial-reporting systems must be authorised, tested, and documented, so that an unreviewed change cannot silently corrupt reported figures. The second is logical access controls: who can reach financial systems and data, governed through user provisioning, periodic access reviews, privileged-account management, and segregation of duties.
Where a vendor hosts the system, you must satisfy yourself that these controls operate inside their environment as rigorously as they would inside yours. This is also where SOX and security overlap with licensing — the same access reviews that satisfy an auditor also surface the dormant and over-provisioned accounts that drive both security risk and licence waste, a point developed in our usage monitoring guide. SAP and Oracle ERP estates concentrate this exposure; the SAP vendor hub covers where the control and licensing questions intersect.
An auditor will treat a control failure at a vendor that touches financial reporting exactly as they would treat one inside your own walls. The contract is where you make sure that does not happen by surprise.
Relying on SOC 1 and SOC 2 Reports
You cannot audit every vendor directly, so SOX relies on independent attestation. For vendors whose systems affect financial reporting, the relevant report is a SOC 1 Type II, which covers controls over financial reporting across a period of operation; broader security, availability, and confidentiality concerns are covered by SOC 2 Type II. Critical vendors should be contractually required to provide one annually — not merely at onboarding.
Two cautions apply. First, reliance is never total: SOC reports carry complementary user entity controls (CUECs) — the controls you must operate on your side for the vendor's controls to be effective. Identifying and operating your CUECs is your responsibility, and auditors test it. Second, review the reports annually and read the exceptions, because a clean cover page can sit above qualified findings. Companies that heavily use cloud services should review third-party SOC 1 and SOC 2 reports every year to confirm vendor standards still align with their own. This discipline sits naturally alongside structured vendor due diligence.
Building SOX Controls Into the Contract
The contract is where SOX vendor management becomes enforceable. Require an annual SOC 1 Type II (and SOC 2 Type II where relevant) delivered within a defined window; a right to audit if the SOC report is qualified or unavailable; notification of control changes and material incidents; and flow-down of these obligations to sub-contractors that touch financial data. Embed the obligations in your contract compliance monitoring so the annual report actually arrives and is reviewed, and align them with the broader third-party risk management framework. The CIO Contract Governance white paper consolidates these into a single control set. To map your SOX exposure across the vendor estate before the next 404 cycle, request a confidential briefing.
Segregation of Duties and Access Recertification
Two control practices carry disproportionate weight in a SOX vendor review, and both depend on disciplined operation rather than documentation alone. The first is segregation of duties (SoD): the principle that no single individual should control a complete financial transaction from initiation to recording. In cloud ERP estates — SAP and Oracle in particular — SoD conflicts proliferate because role design is complex and access accumulates as people change jobs without their old entitlements being revoked. An auditor who finds a user able to both create a vendor and pay it has found a reportable control weakness, regardless of whether the access was ever misused.
The second is periodic access recertification: a formal review, typically quarterly, in which control owners confirm that every user's access to financial systems remains appropriate. Quarterly cadence is the practical standard because the gap between annual reviews is long enough for material drift to accumulate. Where the system is vendor-hosted, the contract must give you the visibility and reporting to run these reviews — access logs, role definitions, and change records — and the vendor's own SOC 1 report should evidence that its administrators are subject to the same discipline.
Done well, recertification serves double duty: the same review that satisfies SOX also reclaims dormant accounts that inflate both security risk and licence cost, linking financial-controls hygiene directly to the savings agenda. There is a third dimension auditors increasingly probe — privileged access. Administrator and service accounts that can alter financial data or bypass application controls must be inventoried, justified, and monitored, and where a vendor holds privileged access to your hosted financial systems, the contract should constrain who at the vendor can use it, log every use, and notify you of changes. A control environment that is rigorous about ordinary users but blind to privileged access has left the largest door unwatched.