SOX: when AI lands inside a financial-reporting control
Nobody sets out to put a language model inside a control that auditors test. It happens when an agent extracts contract terms, a copilot summarises ledger exceptions, or a model output informs a journal entry. At that point the AI path is part of the IT general controls population.
- The instrument
- Sarbanes-Oxley Act 2002, sections 302, 404 and 906, with ICFR expectations over supporting IT systems
- Status
- In force for US-listed issuers
- Who it applies to
- Issuers and their subsidiaries where AI is used in, or feeds, a process affecting financial reporting.
Where AI-FW fits
AI-FW does not produce financial figures and cannot attest to the accuracy of any number. What it provides is the ITGC evidence for the AI component: who changed enforcement, who could reach the model, what changed and when, and whether the control ran as intended throughout the period.
What stays with you
Read this list first. It is the boundary of what a product can do for you, and it is where the remaining work sits.
- Deciding whether a use case is inside ICFR scope: that judgement belongs to management and its auditors
- The change-management process itself, meaning tickets, authorisation and testing evidence. The product records the technical change, not the approval
- ITGC walkthroughs and the narratives that accompany them
- Segregation-of-duties analysis across administrative roles, and compensating controls where roles overlap
- Management's assessment and certification, and liaison with the external auditor
What the framework asks, and what the product does
The obligations that touch the AI path, paired with the capability that answers each one. Everything else in this framework is organisational work, listed above.
Least privilege for systems that affect internal control over financial reporting
Role policies, per-agent identity and owner-scoped views, with every access change recorded against an actor
The person who changes enforcement should not also be the only reviewer
Separate administrative and read-only roles, an approval queue for sensitive actions, and a record showing who did what
Changes are documented, approved and traceable
An audit event for every rule and setting change, whether created, edited, enabled or disabled, with the actor and timestamp and the control set version per release
Systems run as intended, are monitored, and are reviewed
Activity, error and access views, assessment history over time, and drift findings raised when a control is disabled
Keep the audit trail for the period under audit
Log and evidence retention are settings, so they can be aligned to a seven-year policy where your retention schedule says so
Know which systems touch financial data flows
A model inventory attributing every endpoint and provider, with a guard rule that blocks anything outside it
Protect the integrity of data flowing through the control
Outbound rules that block or observe malformed and leaky output, and a parameter policy that prevents silent model substitution
Management must be able to demonstrate that controls operated
A per-period evidence pack covering control status, live rule state including disabled rules, retention values, approvals and the change log
A rule pack to start from
The enforcement that makes the controls real. Severity runs 1 to 5, and a rule that is switched off reports as a gap, so these are meant to be live from day one.
An instruction override inside a reporting process is a control failure, not a curiosity
The inventory is only real if something enforces it
Reduces what a careless or compromised workflow can carry out
Structure leaks are as damaging as data leaks in a reporting context
What the evidence pack contains
Per period, and without prompt or response content, which is what makes it safe to hand over.
- Change log for the periodEvery rule and setting change with actor and timestamp, unbroken
- Role configurationAdministrative and read-only separation, with no shared credentials
- Rule stateIncluding rules currently disabled, since an unreviewed disable is a control failure
- Approval activitySensitive actions routed to a person, and recorded
- Retention valuesAligned to the audit period and your retention schedule
Customer responsibilities and sources
- Determine whether the AI use case falls within ICFR scope, and document the reasoning. If it does not, record that and stop.
- Run change management: tickets, approvals and testing evidence, since the product records the technical change rather than the authorisation.
- Provide ITGC walkthroughs and testing narratives alongside the evidence pack.
- Analyse segregation of duties across administrative roles, and document compensating controls where they overlap.
- Own the management assessment, the certification, and the relationship with the external auditor.
Common questions
No. It enters scope when AI is used in, or feeds, a process that affects financial reporting: an extraction agent, a summarisation copilot over ledger exceptions, a model invoked from a reconciliation tool. The first useful step is the scope question, and it belongs to management and its auditors rather than to a vendor.
Four things, in ITGC language: who could change enforcement and who could reach the model; what changed, who approved it and when; whether it ran as intended and was monitored; and whether the AI capability was tested before use. The product answers the first three continuously, and gives you a place to hold the fourth.
Because a control that exists but is switched off fails the period, and it fails silently. The assessment reports it as a gap and raises a drift finding, which is the earliest signal you get before an auditor samples the same period.
Validate it yourself with our Technical Plan
Ask us to run this framework against your own environment: the rules that would be created, what the assessment reports, and what the evidence pack contains for a real period.
This page maps product capabilities to published expectations. It is not legal, audit or certification advice, and it creates no compliance representation. Applicability and sufficiency are judgements for your counsel and, where relevant, your auditor, assessor or certification body. Framework details are current as reviewed; check the primary sources above, and the page itself, before relying on a date or a threshold.