SOX § 404 IT controls

Sarbanes-Oxley § 404 requires an issuer's management to assess its internal control over financial reporting (ICFR) and, for larger filers, requires the issuer's auditor to attest to that assessment. When AI systems influence the numbers that flow into financial statements, those systems can fall within the scope of that assessment.

Section 404 duties belong to the issuer's management and its auditor. Verdifax has no Section 404 obligation of its own, no tool is certified under Section 404, and Verdifax does not currently hold a SOC 1 or SOC 2 report. Verdifax records can serve as evidence for IT general controls that management assesses and the auditor tests (customer-assessed).

Maturity note. Several pipeline values, including the zero-knowledge transcript and its state-prover binding, are still scaffold values rather than real cryptographic proofs. Hardware attestation depends on the deployment: runs on the hosted service carry the hardware-attestation scaffold flag, because the hosted service runs without an attestation agent; deployments with an AMD SEV-SNP attestation agent bind a verified SEV-SNP quote into each run's execution record (demonstrated 2026-10-03). Every audit bundle flags scaffold values with a scaffold field; the open-source verifier surfaces them in its report. See /concepts/scaffold-gaps/ for the full disclosure list and what activates each. References on this page to hardware attestation are flagged inline.

What's actually required

Auditors of ICFR work under PCAOB AS 2201 (formerly Auditing Standard No. 5). In practice they test IT general controls (ITGCs) for systems that affect financial reporting, commonly grouped as:

Change management, every modification to a system in scope must be authorized, tested, and traceable
Logical access, only authorized personnel can modify production
Operations, failures and unusual events are detected, investigated, resolved
Computer operations, backups, scheduling, recovery

The change-management requirement is the one where AI systems most often fail audit. A model gets retrained, the new weights ship to production, and there's no auditable evidence chain connecting "the recommendation that affected this 10-Q line item" to "the specific model version that produced it."

Verdifax as change-evidence

Each Verdifax manifest hash binds an inference to:

The program_id you declare for the run (your identifier for which model, which version)
The registry_record_hash you declare for the run, binding the inference to your own change-approval record; on deployments that enforce the program registry, an unregistered program is refused before transport
The hardware attestation, an AMD SEV-SNP report bound inside the execution record on deployments with a hardware agent configured; runs without one disclose a per-run scaffold, as the hosted service does today (see scaffold-gaps)
The transcript and execution-plan fields, with the transcript currently a disclosed scaffold value (see scaffold-gaps)

If the model changes (new weights, new code path, new approval record), you declare a new program_id and registry_record_hash, and inferences after the change are sealed against the new values. The hash itself is the change-evidence.

Mapping

ITGC requirement	Verdifax contribution
Change management, all production changes traceable	Every inference is anchored to the program and registry record hash declared for it; with registry enforcement on, unregistered programs are refused before transport
Change management, unauthorized changes detected	On records sealed from run 239 on, changing any section, the approval chain included, no longer matches the complete-record entry on the public log. Run 238 also carries that entry, but deleting it only lowers the verdict to partial coverage. On leaf v5 records sealed before run 238, changing any of the run's anchored values, including the program id and registry record hash, no longer matches the public-log entry, while descriptive sections such as the approval chain are sealed only by hashes inside the bundle
Operations, unusual event review	`status: "stage_error"` runs are persisted for forensic review
Operations, financial-relevant computations reproducible	Pinned-clock replay reproduces the manifest hash (`POST /execute/verify-determinism`); production records verify by recomputation from their recorded fields. Separate production calls each seal their own clock, nonce and public-log entry, so their hashes differ
Logical access, privileged operations logged	Verdifax admin endpoints (`/admin/keys`) require a privileged key; revocations are auditable

Sample SOX-relevant attestation

receipt = verdifax.attest(
    payload=canonical_invoice_classification_input,
    program_id=PROD_INVOICE_AI_PROGRAM_ID,        # registered, approved for prod
    route_id="invoice-class-q4-2026",
    registry_record_hash=PROD_REGISTRY_RECORD,    # ties to change-control ticket
)

journal_entry = JournalEntry(
    debit=...,
    credit=...,
    classification=model_output,
    ai_attestation=receipt.manifest_hash,         # ← evidence chain ends here
)

The journal entry now carries cryptographic evidence of which AI program was declared for the classification. The auditor traces from the entry → manifest hash → declared registry record hash → your change-control ticket. End-to-end change-evidence in one chain. On deployments that enforce the program registry, the run was also refused before transport unless the program was registered.

What this is not