The short answer. SOX itself does not name specific IT controls. What happens in practice is that auditors test IT general controls under PCAOB standard AS 2201 across four domains: access to programs and data, program changes, program development, and computer operations. Data work sits mainly in program development, where the expectations are that cleansing and validation rules were applied and evidenced, and that migrated data reconciles. The evidence standard is system-generated, complete, dated and attributable.

If your systems carry financially significant data, an auditor will eventually ask you to prove things about how that data is handled. Knowing in advance what they test, and what counts as evidence, turns audit preparation from a scramble into a by-product. Here is the practical picture.

Where the requirement comes from

SOX Section 404 requires management to assess internal control over financial reporting, and for many filers an external auditor provides an opinion on it. The auditor tests IT general controls under PCAOB standard AS 2201 in order to rely on the systems and reports that financial controls depend on. An important nuance: SOX does not itself specify IT controls. The control expectations come from audit practice and professional standards, which is why published checklists converge on a similar set rather than quoting legislation.

The four domains auditors test

Domain	What it covers
Access to programs and data	Provisioning with approval, timely removal, periodic review, privileged access, segregation of duties
Program changes	Changes authorised, tested and approved before production, with development separated from production
Program development	New systems and, notably, data conversion and migration
Computer operations	Job scheduling and monitoring, batch and interface completeness, backup and restore

The data controls specifically

Two expectations come up repeatedly, and both are things a data platform either produces or does not.

Within program development, published control checklists are consistent about data conversion and migration. The first expectation is that data cleansing and validation rules are applied and evidenced, with validation reports, exception handling records and approval of the go-live data as the evidence. The second is that data migration is validated, tested by checking that record counts and balances match after migration, with reconciliation results attached. Both are familiar as good practice. The shift for most teams is treating them as evidence obligations rather than internal quality steps.

The evidence standard catches people out

Audit guidance is consistent that an auditor is not satisfied that a control exists; they sample it and expect complete, dated, attributable evidence for each item sampled. Manually compiled spreadsheets and email approvals typically cannot meet that standard at scale, because the auditor traces individual items: what was checked, when, by whom, what the result was, and what changed as a result. A frequently cited failure pattern is changes made directly in a database that never enter the change register, discovered when the auditor compares database logs to approved changes. The lesson is that evidence has to be generated by the system doing the work.

Preparing without a scramble

Drive validation from defined rules so a report is produced naturally rather than assembled later.
Reconcile every load and retain the results, not just the final one.
Log exceptions and their resolution, because auditors are as interested in failures and follow-up as in passes.
Capture approvals as dated records tied to a named approver.
Self-test ahead of the audit. Pull a sample yourself and try to produce what an auditor would accept.

The failures auditors find most often

Published guidance is fairly consistent about where ITGC testing goes wrong, and the patterns are mundane rather than exotic. Leavers retaining active accounts. Access reviews approved wholesale with no evidence of anything being removed. Changes made directly in a database that never entered the change register, found when the auditor compares database logs against approved changes. Testing performed but not evidenced. None of these means the organisation was careless about its data; they mean the evidence trail did not match the practice. That distinction matters, because the remediation is usually about how work is recorded rather than how it is done.

Run the sample on yourself

The most useful preparation is also the simplest: pick a sample yourself and try to produce what an auditor would accept. Take a handful of changes or data loads from the period, and for each one locate the approval, the test evidence, the validation result and the reconciliation. If you can assemble all of it quickly, you are in good shape. If you find yourself reconstructing, negotiating or explaining, you have found your gap months before the external auditor does, at a point where fixing the process is straightforward rather than becoming a reportable deficiency.

The same evidence serves more than SOX

Organisations subject to SOX are often subject to other frameworks too, and the underlying control expectations overlap heavily. Access governance, change control, and evidence of validation appear in some form across most regimes. That means a control designed once and evidenced properly can frequently support testing under several frameworks, rather than each one driving a separate collection exercise. Designing the data controls for reuse from the start, with system-generated evidence that can be exported, is a meaningful efficiency for teams who would otherwise assemble similar packs repeatedly through the year.

Migrations attract attention

A migration is a period of elevated audit interest, for understandable reasons: financial data is moving, controls are in flux, and temporary access is often granted to people who do not normally have it. Expect the migration period to be looked at specifically rather than sampled like any other quarter. That makes it worth being deliberate about the control basics during the programme: who had elevated access and for how long, how data fixes were approved and logged, and what evidence exists for each load. Teams that handle those three well during the migration generally find the subsequent audit uneventful.

How deKorvai helps

deKorvai is built to produce these artefacts from the work rather than alongside it. Validation runs against configurable business and technical rules, which generates the validation evidence the data conversion control expects. Reconciliation compares loaded data against the source, which is the test auditors apply to data migration. Full audit trails on every operation, with execution tracking and change logs, give the system-generated, attributable record the evidence standard requires, and its compliance and regulatory reporting is intended for exactly this handover. None of that removes the need for your own control design, but it does mean the evidence exists when asked for.

Key takeaways

SOX does not name IT controls; auditors test ITGC under PCAOB AS 2201.
Four domains: access, program changes, program development, computer operations.
Data sits in program development: validation evidenced, migration reconciled.
Evidence must be system-generated, dated and attributable.

Frequently asked questions

Does SOX specify IT controls for data?

No. SOX Section 404 requires management to assess internal control over financial reporting, and auditors test IT general controls under PCAOB standard AS 2201 to rely on the systems producing financial data. The specific control expectations come from audit practice, not the legislation.

What are the four SOX ITGC domains?

Access to programs and data, program changes, program development, and computer operations. Data conversion and migration sits within program development, which is why migration work falls into audit scope for financially significant systems.

What data controls do auditors test?

Two in particular: that data cleansing and validation rules were applied and evidenced, with validation reports, exception handling and approval of go-live data; and that data migration was validated by checking record counts and balances match, with reconciliation results attached.

Why are spreadsheets not enough as evidence?

Because auditors sample individual items and trace them: what was checked, when, by whom, and what changed as a result. Guidance consistently expects system-generated evidence that is complete, dated and attributable, which manually compiled records struggle to provide at scale.

SOX Data Controls: What Auditors Actually Check