SOC 1 for AI Tools in the SOX Workflow. The Next Procurement Gate.

TL;DR

The moment a public company uses an AI tool to prepare workpapers the external auditor will rely on, that AI tool is a service organization under AICPA SSAE 18. The external auditor's reliance assessment under PCAOB AS 2601 requires a SOC 1 Type 2 report. SOC 2 covers security and is necessary, but it is not sufficient for SOX. Without a SOC 1, the audit team performs additional procedures or declines reliance.

The first procurement gate that will stop AI tools from entering the SOX workflow at scale is not security review. It is service organization reliance.

The moment a public company uses an AI tool to prepare workpapers the external auditor will rely on, that AI tool is a service organization. Under SSAE 18 and AS 2601, the external auditor has to assess whether the tool's controls are sufficient to rely on the work produced through it. The standard mechanism for that assessment is a SOC 1 Type 2 report. If the tool does not have one, reliance is not automatic. The audit team either performs additional procedures over the tool's controls or declines reliance entirely.

This piece is for SOX 404(a) teams and internal audit leaders selecting AI tools, and for external audit firms evaluating client tooling. The standards anchor on the issuer side to SOX Section 404(a), 33-8810, and SSAE 18 for the SOC reports themselves. On the external auditor side, the relevant guidance is AS 2601 on service organizations and AS 2201 on the audit of ICFR.

Dark glass tower with sharp vertical lines — The procurement gate auditors walk into first.

When does an AI tool become a service organization

A service organization, under SSAE 18, is an entity that provides services to a user entity that are likely to be relevant to that user entity's internal control over financial reporting.

For an AI tool used in SOX testing, the test is straightforward. If the tool processes or produces information that is used in management's ICFR assessment, and a failure in the tool could affect the reliability of that assessment, the tool meets the service organization definition. A few examples that clearly meet the bar.

An AI agent that pulls populations from upstream systems and produces the workpaper used to test a SOX control.
An AI tool that classifies journal entries as risky or non-risky as part of a management review control.
An AI system that performs user access reviews and produces the evidence management uses to conclude on the access review control.

Tools that probably do not meet the bar.

A general-purpose chatbot a SOX analyst uses for research without that output entering a workpaper.
A document summarization tool used to draft narratives that will be re-written by humans before any control activity.

The line is whether the tool's output materially affects the work product the external auditor will rely on. When in doubt, assume the tool is a service organization. The external auditor will.

SOC 1 vs SOC 2. The most expensive confusion in SOX procurement

The common procurement mistake is treating a SOC 2 report as sufficient for a SOX-relevant tool. It is not. The two reports cover different things and serve different audiences.

SOC 1 vs SOC 2 for SOX-bound AI tools — Only SOC 1 clears the SOX procurement gate. SOC 2 clears security review.

Dimension	SOC 1	SOC 2
Standard	SSAE 18, focused on internal control over financial reporting	SSAE 18, focused on the trust services criteria
Subject matter	Controls relevant to a user entity's financial statements	Security, availability, processing integrity, confidentiality, privacy
Primary audience	External auditors performing ICFR audits	Security and procurement teams at customer organizations
Used for SOX reliance	Yes	No
Used for security review	Sometimes	Yes

A SOC 2 report is necessary for any modern SaaS procurement. It is not sufficient for a tool that produces SOX workpapers. The external auditor cannot rely on a SOC 2 to obtain comfort over financial reporting controls because that is not what the report covers.

This is not a technicality. The SEC and PCAOB have been clear that the audit of ICFR depends on evidence about controls relevant to financial reporting. SOC 2 trust services criteria do not address ICFR-relevant controls directly. SOC 1 does. The audit-evidence framework in AS 1105 and the ICFR audit construction in AS 2201 both anchor on financial-reporting-relevant controls, which is the SOC 1 subject matter.

Practical consequence. A vendor that has SOC 2 Type 2 but no SOC 1 has cleared security review. They have not cleared the SOX procurement gate.

Open notebook on a wood desk with afternoon light — A SOC 1 Type 2 is the substrate of reliance. SOC 2 cannot do this work.

What a SOC 1 Type 2 actually contains

The Type 1 vs Type 2 distinction matters because the external auditor's reliance is almost always on the Type 2.

SOC 1 Type 1 is a point-in-time report. It describes the service organization's system and the suitability of the design of controls as of a specific date. It does not test operating effectiveness over time.
SOC 1 Type 2 covers a period (usually six to twelve months) and tests both the design and the operating effectiveness of the controls during that period.

A Type 1 is useful as a step on the path to a Type 2, especially for newer vendors. It is not what an external auditor relies on for ICFR audit conclusions.

Inside a SOC 1 Type 2, five sections matter to a SOX buyer.

Independent service auditor's report. The opinion. Did the controls operate effectively over the period.
Management's assertion. What the service organization is asserting about its controls.
System description. What the system does, what data it processes, what controls are in place. This is where buyers should look closely. A vague system description hides scope problems.
Control objectives, controls, and tests. The control matrix. Each control objective tied to specific controls, tested against specific procedures, with results.
Complementary user entity controls. The CUECs. What the service organization expects the customer to do for the service organization's controls to be effective. Read alongside the AICPA SOC for Service Organizations overview for the underlying framework.

A buyer who reads only the auditor's opinion and skips the system description and CUECs has not done a SOC 1 review. They have read the cover.

The CUEC trap

Complementary user entity controls are the most commonly missed element of SOC 1 reliance. The pattern repeats. A customer signs the contract, deploys the tool, gets the SOC 1 report, and never reads the CUECs. A year later the external auditor asks how each CUEC has been implemented. The answer is silence.

For an AI tool used in SOX testing, common CUECs the customer needs to plan for include the following.

User access management at the customer. Provisioning, periodic access review, and timely deprovisioning of customer-side users of the AI tool.
Evidence source approval. Customer review and approval of which source systems and queries the AI tool is permitted to use.
Reviewer training. The customer's preparers and reviewers are trained to use the tool and to evaluate its outputs critically.
Rule and configuration oversight. Customer-side approval and review of changes to control rules, exception thresholds, and prompt templates.
Workpaper review. A documented process for reviewing AI-generated workpapers before they are submitted as part of management's testing.

If management does not implement these, the SOC 1 reliance does not hold. The external auditor will perform additional procedures or decline reliance, and the cost of automation rises rather than falls. The same Information and Communication component of COSO 2013 that governs management's evidence quality applies to the customer side of the SOC 1 boundary.

Procurement timeline reality

A SOC 1 Type 2 cannot be produced on demand. The timeline matters for buyers and vendors both.

The typical sequence for a vendor going from no SOC report to a usable SOC 1 Type 2 looks like this.

Readiness assessment. Two to three months. Identify gaps against the relevant control objectives and remediate.
SOC 1 Type 1. Two to three months. Independent service auditor reviews the design of controls as of a point in time and issues the report.
Observation period for SOC 1 Type 2. Six to twelve months. Controls operate during the period and are tested at the end.
SOC 1 Type 2 issuance. One to two months after the observation period closes.

End to end, a vendor that starts with nothing is twelve to eighteen months from a usable Type 2. This is why a buyer cannot wait until an external auditor asks about the SOC report. The buyer should have asked at procurement.

For SOX programs that have already deployed an AI tool without a SOC 1, the path forward is one of three.

The vendor commits publicly to a SOC 1 Type 2 timeline, and management documents the gap and the mitigation in the meantime.
The external auditor performs additional procedures over the tool's controls during the audit, at the customer's cost.
Management restricts use of the tool to non-SOX work until the SOC 1 is in place.

None of these are great outcomes. All of them are better than discovering the gap mid-audit.

Server racks lit blue in a data center — The reliance question is concrete. The procurement workflow has to make it answerable.

What buyers should ask

The procurement questions for a SOX-bound AI tool break into three groups.

Standing of the SOC 1 itself.

Do you have a SOC 1 Type 2 report. If yes, what period does it cover.
If you have only a Type 1, when does the Type 2 observation period start, and what is the expected issuance date.
If you have neither, when do you commit to having both, and what mitigations do you offer customers in the interim.

Substance of the SOC 1 report.

Provide the SOC 1 system description. Confirm it covers the functionality our SOX program will use.
Walk through the control objectives in scope. Identify any that we should have expected and are not present.
Were any control exceptions noted in the most recent Type 2. If so, what was the cause and what has been remediated.

CUECs and customer obligations.

List the CUECs in your SOC 1. We will document our implementation of each.
Provide guidance on what changes in our program would invalidate SOC 1 reliance.
Describe how you communicate changes in your controls or system to customers between report issuances.

A vendor that handles these crisply has built for the SOX procurement gate. A vendor that deflects has not.

What vendors in this category should be doing now

If you are building an AI tool for the SOX workflow and do not yet have a SOC 1 Type 2, the runway to procurement readiness is shorter than most teams realize.

Three priorities, in order.

Define the system scope as if for the system description. This forces clarity on what the tool actually does in the SOX workflow, which will surface scope ambiguities before the auditor does.
Write the control objectives. What does management need to be able to rely on. What does the external auditor need to evaluate. The control objectives are the architecture.
Pick a service auditor and start the readiness assessment. The earlier this happens, the shorter the gap to a usable Type 2.

The tools that win this category in 2026 and 2027 will be the ones whose SOC 1 Type 2 is already in customers' hands when the conversation about external audit reliance starts. The tools that figure this out late will lose enterprise deals to whichever competitor figured it out earlier.

See Arden run this in production

Arden is built for issuer-side SOX 404(a) programs that need testing and workpaper output structured for external auditor reliance. Customers can review our service-organization scope, control objectives, and CUEC roadmap during procurement.

Book a 30-minute walkthrough

Traceable AI Workpapers in SOX 404(a). The three things external auditors examine in AI-generated workpapers, including SOC 1 reliance and CUECs.
The Management Review Control Problem in Agentic SOX Testing. Why 33-8810 reserves judgment for the human reviewer, and what that means for AI tool design.

FAQ

Is a SOC 2 Type 2 enough for a SOX-bound AI tool. No. SOC 2 covers the trust services criteria (security, availability, processing integrity, confidentiality, privacy). SOX reliance requires controls over information used in financial reporting, which is the SOC 1 subject matter. SOC 2 is necessary for security and procurement review. It is not sufficient for the SOX procurement gate.

Does an AI tool need its own SOC 1 if it sits on top of a cloud provider that has one. Yes. The cloud provider's SOC 1 covers the cloud provider's controls. The AI tool's controls are a separate matter. An external auditor relying on a SOX workpaper produced by the AI tool needs assurance over the AI tool's controls, not just the underlying infrastructure.

What if the AI tool is used only for non-SOX work. Then a SOC 1 is not required for SOX procurement. The tool may still need a SOC 2 for security review, and other reports may apply depending on use. The SOC 1 question is specific to ICFR-relevant work.

Can an issuer rely on a SOC 1 from a sub-service organization. Sometimes. A SOC 1 report identifies whether the service auditor used the inclusive method (sub-service organization controls included) or the carve-out method (sub-service organization controls excluded, with the user entity expected to obtain separate assurance). Read the system description carefully to confirm.

How often does a SOC 1 Type 2 need to be refreshed. Annually. Most service organizations issue a Type 2 covering a twelve-month period. Gap periods between reports are an issue for external auditor reliance and should be covered by bridge letters from the service organization.

Does the external auditor's own SOC 1 review process replace the issuer's procurement diligence. No. The external auditor evaluates the SOC 1 to support their reliance. The issuer needs the same assurance for management's own ICFR assessment under 33-8810. Both parties read the report. They read it for different purposes.