SOX 404 Compliance Checklist for AI-Assisted Controls (2026)

If your team uses AI for transaction monitoring, journal entry testing, anomaly detection, or control evidence documentation, your SOX 404 program has a problem that no existing checklist solves. The governing standards, PCAOB AS 2201, SEC Release 33-8810, and the 2013 COSO Internal Control Framework, all predate generative and agentic AI. No regulator has issued AI-specific guidance as of the June 2026 revision of the SEC's Financial Reporting Manual.

This checklist fills that gap. It maps AI deployment scenarios to specific COSO principles and AS 2201 requirements, identifies where AI creates new risks, and specifies what documentation auditors will expect. Hand it to your team today.

Key takeaway: "While external auditors and regulators have not given blanket approval for AI-driven SOX compliance, companies can design an approach that is practical, trustworthy and ready for scrutiny.", Grant Thornton Advisory, 2025

Why AI Changes the SOX 404 Calculus (Without Changing the Legal Standard)

AI does not change what SOX 404 requires. It changes how you satisfy those requirements, and where you can fail.

Section 404(a) still requires management to assess and report on ICFR effectiveness annually. Section 404(b) still requires external auditor attestation under AS 2201 for accelerated and large accelerated filers. The COSO 2013 framework still governs the assessment. What changes is that AI introduces new categories of control risk, new evidence requirements, and new testing obligations that traditional SOX programs are not built to handle.

As KPMG's December 2025 ICFR Handbook notes: "Companies continue to implement increasingly complex systems as well as AI and automation to support financial reporting and operating performance. Effective ICFR is needed to manage these risks."

The PCAOB's new QC 1000 quality control standard, effective December 15, 2025, requires audit firms to address technology risk at the firm level. The first full audit cycles under QC 1000 are calendar year 2026 audits. Expect auditors to scrutinize AI-assisted controls more rigorously than they did in 2025.

For the foundational SOX 404 framework, including filer thresholds, 404(a) vs. 404(b) differences, and the top-down risk-based methodology, see Finrep's SOX Section 404 Compliance: 2026 Updates, Key Differences, and Best Practices. This checklist picks up where that guide leaves off.

Step 1: Classify Your AI Controls Before You Test Anything

The single most consequential decision in an AI-assisted SOX program is how you classify each AI tool. Classification drives testing scope, frequency, and documentation requirements.

The KPMG ICFR Handbook identifies three categories. Get this wrong and your entire testing approach is miscalibrated.

Classification	Description	Testing Burden	Key Risk
Fully automated control	AI makes the control decision without human intervention (e.g., auto-blocks a transaction)	Highest: robust ITGCs required; test the AI model itself	Model failure with no human backstop
Semi-automated control	AI flags exceptions; human reviews and disposes each flag	Moderate: test AI detection layer AND human review layer separately	Alert fatigue; reviewer rubber-stamping
AI-assisted management review	AI provides analysis to support human judgment (e.g., variance analysis dashboard)	Similar to traditional MRC, plus data quality requirements	Input data unreliability undermining the analysis

Checklist: AI Control Classification

Inventory every AI tool used in financial reporting processes (see Step 2)
For each tool, document whether a human must approve before the control conclusion is recorded
Assign each tool to one of the three categories above
Document the classification rationale in the risk-and-control matrix (RACM)
Re-classify any tool that changes behavior due to a vendor model update (see Step 6)

Step 2: Build the AI Model Inventory (Pre-Assessment Readiness)

Before scoping controls, management must know what AI is in the environment. Most companies discover mid-assessment that AI is embedded in ERP modules, RPA platforms, and analytics tools they did not explicitly deploy as controls.

Grant Thornton specifies that governance by design requires model inventories, risk assessments, and approval gates before production use. This is the minimum auditors will expect.

Checklist: AI Model Inventory

Identify all AI tools touching financial reporting processes: ERP-embedded AI, standalone analytics platforms, RPA with ML components, generative AI used for documentation
For each tool, document: vendor name, model version, deployment date, last update date, and the specific control objective it supports
Classify each tool by risk tier: high (key control), medium (supporting control), low (efficiency tool not relied upon for ICFR)
Document whether each vendor provides a SOC 1 Type II report covering the AI model specifically (many do not yet; see Step 5)
Align the inventory to the NIST AI Risk Management Framework GOVERN function as a baseline governance artifact
Present the inventory to the audit committee; boards are increasingly asking AI governance questions that management must be able to answer in a SOX context

Step 3: The Core SOX 404 Checklist, Mapped to COSO Components

The 2013 COSO framework contains 17 principles across five components. All 17 must be evaluated for AI-specific risks. The three COSO principles most directly affected by AI are called out explicitly below.

Control Environment (COSO Component 1)

Document that the board and senior management have established accountability for AI-assisted controls, not just for the financial outputs they produce
Confirm that roles and responsibilities for AI control ownership are assigned to named individuals, not to the AI system itself
Verify that personnel operating AI-assisted controls have sufficient competence to evaluate AI outputs, not just accept them. Grant Thornton identifies skills gaps as the primary barrier to AI adoption in SOX programs
Document the human oversight layer: who reviews AI outputs, what authority they have to override, and how overrides are logged

Risk Assessment (COSO Component 2)

Update the fraud risk assessment to include AI-specific fraud vectors: adversarial inputs designed to manipulate anomaly detection, model poisoning, and unauthorized model access
Assess model drift risk: the risk that an AI model's accuracy degrades over time as the underlying data distribution changes, causing it to miss exceptions it would previously have caught
Assess hallucination risk for any generative AI used in documentation or analysis: the risk that the model produces plausible but incorrect outputs that are accepted without verification
Assess training data bias risk: if the model was trained on historical data that reflects past errors or fraud, it may systematically fail to detect similar future patterns
Document how each AI-specific risk maps to a financial statement assertion and a potential misstatement

Control Activities (COSO Component 3, including Principle 11)

COSO Principle 11 (Select and Develop General Control Activities Over Technology) is the most directly applicable principle for AI. It must be extended to cover model development, training data governance, version control, and model monitoring.

ITGCs for AI systems (required under AS 2201 for automated controls):

Program development and change controls: document the approval process for deploying a new AI model or updating an existing one
Access controls: restrict access to the AI model, its training data, and its configuration parameters to authorized personnel only
Computer operations controls: confirm the model runs as intended on each execution; document how failures are detected and escalated
Change management: establish a formal process for evaluating vendor model updates (see Step 6)

Segregation of duties in AI workflows:

Confirm the AI system cannot both initiate and approve a transaction or control conclusion. Grant Thornton is explicit: SOD must be enforced across AI-assisted workflows to avoid conflicts
For multi-agent systems, apply SOD analysis at the agent level: document which agent performs which step and confirm no single agent can complete a full transaction cycle
Document the human approval gate that prevents AI auto-clearance of exceptions above a defined materiality threshold

Precision threshold calibration:

Document how the anomaly detection threshold was set and validated. A threshold that generates excessive false positives creates alert fatigue; reviewers begin dismissing genuine exceptions. Grant Thornton identifies precision thresholds that flag true anomalies as a critical design requirement
Re-validate thresholds when the underlying data distribution changes (e.g., after an acquisition, system migration, or significant business model change)
Document that the threshold is set at a level sufficient to detect material misstatements, not merely operational anomalies

Information and Communication (COSO Component 4, including Principle 13)

COSO Principle 13 (Use Relevant, Quality Information) is critical for AI: models are only as reliable as their inputs. The KPMG ICFR Handbook addresses "information used in controls" as a hot topic specifically because of AI.

Document the data quality controls that ensure AI inputs are complete, accurate, and timely before each model execution
Confirm that input data lineage is traceable: auditors will ask where the data came from and how it was validated
For continuous monitoring outputs, document the process for disposing of AI-generated alerts at scale. Thousands of flagged exceptions require a documented triage and sign-off workflow, not just a spreadsheet
Confirm that AI-generated outputs are explainable: the system must produce a human-readable rationale for each exception, not just a pass/fail flag. Grant Thornton specifies that leading organizations maintain "explainable exceptions and auditable remediation"

Monitoring (COSO Component 5, including Principle 16)

COSO Principle 16 (Conduct Ongoing and/or Separate Evaluations) aligns directly with AI-enabled continuous monitoring. But it creates a meta-monitoring requirement that no existing guidance addresses: management must also monitor the AI monitor itself.

Document how the AI monitoring system is evaluated for reliability on an ongoing basis (not just at year-end)
Establish drift detection: monitor model accuracy metrics (precision, recall, false positive rate) on a defined schedule and document results
Document the escalation path when drift metrics deteriorate beyond a defined threshold
Confirm that AI-generated monitoring outputs are used as evidence for Principle 16, with documentation of how the AI system's own reliability was validated

Step 4: What AS 2201 Requires When AI Is a Key Control

Under PCAOB AS 2201, auditors must obtain sufficient evidence about the design and operating effectiveness of controls. AI-generated outputs must meet this evidentiary standard, and auditors will test the ITGCs that support any automated control.

For AI-assisted controls, AS 2201's automated control testing framework applies directly. The auditor must test:

The AI model's program development and change controls
Access controls to the model and its training data
Computer operations controls ensuring the model runs as intended
The completeness and accuracy of the data inputs to the model

Additionally, PCAOB AS 2110 (Identifying and Assessing Risks of Material Misstatement) requires auditors to consider the risk that automated controls may not operate as intended. Model drift, adversarial inputs, and training data bias are new risk categories that must be assessed under AS 2110's existing framework.

When internal audit uses AI tools to perform SOX testing, PCAOB AS 2605 (Consideration of the Internal Audit Function) applies. The external auditor must evaluate the quality of AI-assisted internal audit work product, including whether the AI testing procedures are reliable. AI-generated work is subject to the same AS 2605 scrutiny as manual work.

For complex AI environments, auditors may engage AI/ML specialists under PCAOB AS 1210 (Using the Work of an Auditor-Engaged Specialist). Expect this in 2026 audits of companies with fully automated AI controls.

Key takeaway: Management cannot simply accept AI outputs as its own 404(a) assessment. SEC Release 33-8810 requires management to base its assessment on its own evaluation. When AI tools are used in the assessment process, management must independently validate the AI's conclusions.

Step 5: Service Organization Controls for Third-Party AI Tools

If your AI tool is provided by a third party, you have a SOC 1 problem. PCAOB AS 2601 (Consideration of an Entity's Use of a Service Organization) requires the auditor to obtain evidence about the service organization's controls. For AI tools embedded in ERP systems or standalone analytics platforms, the company must obtain a SOC 1 Type II report covering the AI system's relevant controls.

The gap: many AI vendors do not yet provide SOC 1 Type II reports that specifically cover their AI models. A SOC 1 covering the underlying cloud infrastructure does not satisfy AS 2601 if the AI model itself is the key control.

Checklist: Third-Party AI Tool Scoping

For each third-party AI tool classified as supporting a key control, request the vendor's SOC 1 Type II report
Confirm the SOC 1 scope covers the AI model's development, change management, and operational controls, not just infrastructure
If no SOC 1 is available, document the alternative procedures performed to obtain equivalent assurance (e.g., vendor questionnaire, on-site assessment, contractual representations)
Review the SOC 1 for complementary user entity controls (CUECs) that your organization must implement
Escalate to external auditors early if a key AI vendor cannot provide adequate SOC 1 coverage; this is an audit scope issue, not just a vendor management issue
The KPMG ICFR Handbook identifies "controls at service organizations" as a hot topic specifically because of AI tool proliferation

Step 6: Mid-Year Model Changes and the Change-in-Control Question

When an AI vendor updates the underlying model mid-year, does that trigger a change-in-control event requiring re-testing? No regulator has answered this question directly. Here is the practical framework.

A vendor model update is a change to the automated control. Under AS 2201's ITGC framework, program changes require testing to confirm the control continues to operate as intended after the change. The key question is materiality: does the update change the model's behavior in a way that affects its ability to prevent or detect material misstatements?

Checklist: Mid-Year Model Change Response

Establish a contractual right to receive advance notice of model updates from AI vendors
Upon receiving notice of an update, assess whether the update changes the model's detection logic, training data, or threshold behavior
If the update is material to control behavior: re-perform design effectiveness testing; document the change in the RACM; notify external auditors
If the update is non-material (e.g., performance optimization with no behavioral change): document the assessment rationale and obtain vendor confirmation in writing
Log all vendor model changes in the AI model inventory with dates, version numbers, and materiality assessments
Consider whether a mid-year model change that degrades control effectiveness constitutes a control deficiency requiring escalation (see Step 7)

Step 7: Deficiency Classification for AI-Specific Control Failures

Not all AI failures are material weaknesses. But some are, and the classification analysis is different from traditional control failures.

Under PCAOB AS 1305 (Communications About Control Deficiencies), if an AI model fails, management must assess whether the failure constitutes a significant deficiency or material weakness and communicate accordingly. The analysis depends on the nature of the failure and the adequacy of compensating controls.

AI Failure Type	Likely Classification	Key Factors
Model drift (gradual accuracy degradation)	Design deficiency if undetected; significant deficiency or material weakness if exceptions were missed	Was drift monitoring in place? Were missed exceptions material?
Hallucination in documentation	Depends on human review layer	Did a human independently verify the AI output before relying on it?
Training data bias	Potentially significant deficiency or material weakness	Does the bias cause systematic failure to detect a category of misstatement?
Vendor model change without re-testing	Change management deficiency; escalates if exceptions were missed	Was the change assessed? Was re-testing performed?
SOD violation in AI workflow	Significant deficiency at minimum; material weakness if fraud risk is elevated	Can the AI both initiate and approve? Is there a manual compensating control?
No SOC 1 for key AI vendor	Scope limitation; auditor may be unable to opine	Were alternative procedures performed?

For material weakness disclosure requirements and the full deficiency classification framework, see Finrep's Material Weakness Disclosure Requirements: 2026 SEC Compliance Guide.

Step 8: Documentation and Evidence Matrix for AI-Assisted Controls

The most common audit finding in AI-assisted SOX programs is not that the AI failed. It is that management cannot produce the evidence trail auditors need to evaluate whether the AI worked.

Grant Thornton specifies that leading organizations maintain "traceable monitoring, explainable exceptions and auditable remediation." Here is what that looks like in practice.

Evidence Artifact	What It Documents	AS 2201 Relevance
Model card / model specification	Model purpose, training data, version, known limitations, approved use cases	Design effectiveness; ITGC program development
Training data documentation	Data sources, quality controls, bias assessment, refresh schedule	COSO Principle 13; input data reliability
Threshold calibration record	How detection thresholds were set, validated, and approved; re-validation dates	Control precision; design effectiveness
Exception disposition log	Each AI-generated alert, reviewer identity, disposition decision, timestamp	Operating effectiveness; human oversight layer
Human review sign-off	Named individual confirming review and approval of AI output for each control period	AS 2201 evidence sufficiency; SOD
Drift monitoring report	Periodic accuracy metrics (precision, recall, false positive rate) with trend analysis	COSO Principle 16; meta-monitoring
Vendor change notification log	All vendor model updates with materiality assessments and re-testing decisions	ITGC change management
SOC 1 Type II report (or alternative)	Service organization controls over the AI system	AS 2601 service organization requirements

2026 Regulatory Watch-List: Open Questions Practitioners Must Monitor

No primary regulator has issued AI-specific SOX 404 guidance as of mid-2026. The SEC's Financial Reporting Manual, updated June 29, 2026, contains no AI-specific ICFR guidance. The PCAOB's 40-plus active auditing standards contain no AI-specific provisions. COSO has not issued an AI supplement to the 2013 framework.

These are the open questions to track:

PCAOB AI guidance: The PCAOB's inspection focus on technology-assisted audit procedures (TAAPs) signals that AI-specific auditing standards are under consideration. Watch for concept releases or proposed standards in late 2026.
COSO AI supplement: COSO has signaled awareness of AI's impact on the 2013 framework. A formal supplement or update would provide the authoritative bridge practitioners currently lack.
SEC AI disclosure rules: Whether AI use in internal controls must be disclosed in the 404(a) management report or in 10-K risk factors remains an open question. The SEC's cybersecurity disclosure rules (2023) may be relevant if an AI control failure affects financial reporting systems.
SOC 1 coverage for AI vendors: The AICPA's evolving guidance on SOC reports for AI systems will determine whether vendors can provide adequate coverage under AS 2601. Watch for AICPA updates to the Trust Services Criteria.
EU AI Act intersection: For companies with EU operations, the EU AI Act's requirements for high-risk AI systems may overlap with SOX governance requirements. Grant Thornton recommends anticipating EU AI Act alignment needs now.
EGC AI governance debt: Companies using AI-assisted controls during their EGC period (exempt from 404(b) for up to five years post-IPO under the JOBS Act) may accumulate governance debt that creates material weakness risk at first 404(b) audit. See Finrep's SOX and AI Controls: The 2026 Governance Framework for CFOs and Controllers for the governance architecture to build during the EGC window.

FAQ: SOX 404 and AI-Assisted Controls

Does using AI for transaction monitoring satisfy SOX 404 control requirements? Yes, but only if the AI control is properly designed, tested, and documented. Testing 100% of transactions with AI does not by itself satisfy SOX 404. AS 2201 requires evidence that the control is adequately designed and operating effectively, not just that transactions were reviewed. The AI system itself must be subject to ITGC testing.

How do we classify an AI tool: automated application control, ITGC, or something new? Use the three-category framework in Step 1. Fully automated AI controls (no human intervention) are treated as automated application controls and require robust ITGC support. The AI model's own development, change management, and access controls are ITGCs. There is no formally recognized new category under AS 2201 as of mid-2026.

What happens to segregation of duties when AI auto-clears exceptions? Auto-clearance without human approval is a SOD risk if the AI system can both detect and resolve an exception without independent review. Design the workflow so that exceptions above a materiality threshold always route to a named human reviewer. Document the threshold and the reviewer's sign-off.

Does model drift constitute a significant deficiency or material weakness? It depends on whether drift caused the control to miss exceptions that were, or could have been, material. Undetected drift with no compensating control is at minimum a design deficiency. If material exceptions were missed, escalate to significant deficiency or material weakness analysis under AS 1305.

What must management's 404(a) assessment say about AI-assisted controls? Management must be able to assert that it understands and has independently validated the AI's conclusions. Under SEC Release 33-8810, management cannot simply accept AI outputs as its own assessment. The assessment should reference the AI control classification, the testing performed, and the evidence obtained, including the human oversight layer.

How do we handle a mid-year model change by an AI vendor? Treat it as a program change under the ITGC change management framework. Assess whether the change is material to control behavior. If material, re-perform design effectiveness testing and notify external auditors. Document the assessment regardless of the conclusion.