At a Glance
ISO 42001 and SOC 2 are different assurances. ISO/IEC 42001 is a certifiable standard for an AI management system: how you govern the AI you build or use. SOC 2 is a CPA firm’s attestation report on whether your service controls are designed and operating well. A customer asking about AI governance usually wants the first; one asking about your service security wants the second.
- Scope: 42001 covers AI risk, impact and lifecycle; SOC 2 covers security, availability, processing integrity, confidentiality and privacy.
- Output: 42001 ends in a certificate from a certification body; SOC 2 ends in a report with a CPA opinion.
- Overlap: access control, logging, change management and vendor oversight evidence serve both.
- AI in SOC 2: no AI-specific Trust Services Criteria have been reported; auditors apply the existing ones to AI systems.
The confusion is understandable, because both now show up on the same security questionnaire. ISO/IEC 42001, published in December 2023, “specifies requirements for establishing, implementing, maintaining, and continually improving an Artificial Intelligence Management System.” SOC 2, under the AICPA’s SOC suite, reports on controls relevant to “Security, Availability, Processing Integrity, Confidentiality, or Privacy.” One is about managing a technology; the other is about whether a service can be trusted.
What changed in 2026 is that auditors started asking about AI inside SOC 2 anyway. A Cloud Security Alliance research note published 30 August 2026 reports that the AICPA “has not published AI-specific Trust Services Criteria,” and that the criteria were last substantively revised in 2017, with a points-of-focus refresh in 2022. Then on 11 September 2026, the AICPA released technical Q&A section 9561 on how a service organization’s use of AI affects SOC 1 and SOC 2 examinations, which Schneider Downs summarizes as confirming that AI does not create a separate examination model.
So a buyer who asks “are you SOC 2 for AI?” is asking for something that does not exist as a separate product, and a vendor who answers with an ISO 42001 roadmap may be answering a different question.
How Do ISO 42001 and SOC 2 Actually Differ?
| Question | ISO/IEC 42001 | SOC 2 |
|---|---|---|
| What is it? | An international management system standard for AI | An attestation engagement under AICPA standards |
| What does it cover? | Policy, roles, AI risk and impact assessment, lifecycle controls, data management, third parties, internal audit, management review | Controls relevant to the five trust services categories for the system in scope |
| Who performs it? | An accredited certification body; ISO itself certifies no one | A licensed CPA firm acting as service auditor |
| What do you get? | A certificate of conformity, kept alive by surveillance audits | A report with the auditor’s opinion, system description and, for Type 2, test results over a period |
| Who usually asks for it? | Customers and procurement teams assessing how you govern AI you build or embed | Customers assessing the security of a service that holds their data |
| Where does AI fit? | It is the whole subject | Inside existing criteria, wherever AI affects the system in scope |
The certification point matters for honesty in sales. ISO states that it “does not perform certification or issue certificates.” Accredited certification bodies do. A SOC 2 report, by contrast, is not a certificate at all; it is an opinion, and the useful part for a customer is often the exceptions section, not the cover page.
For clarity on our own position: Analytics AIML does not hold ISO 42001 certification or a SOC 2 report, and is neither a certification body nor a CPA firm. We build the data controls and evidence that both kinds of auditor examine.
When Does a Customer Need Which?
Read the request, not the acronym. Three patterns cover most mid-market situations.
A customer is about to put its data in your service. That is a SOC 2 question. They want to know your access controls, change management and incident response work, and they want a Type 2 report covering a period, not a point in time. If your service uses AI to process their data, expect follow-up questions about it under the same report.
A customer is buying an AI capability from you, or embedding your model in their product. That is increasingly an ISO 42001 question, or at least a request for a roadmap to it. They want to see an AI policy, impact assessments, a model inventory and evidence that someone reviews the system over its life.
An enterprise procurement team sends a 300-line questionnaire. It is probably both. Answer each section against the assurance it is really asking about, and do not offer a 42001 roadmap where a SOC 2 exception needs explaining.
What Do SOC 2 Auditors Now Ask About AI?
Because the criteria did not change, the examination did. According to Aprio, auditors now map AI evidence onto the existing common criteria: governance and competence, risk assessment and monitoring, logical access including shadow AI detection, system operations and model monitoring, change management for model updates, and vendor oversight. Schneider Downs adds that third-party AI providers are handled as subservice organizations, with the usual inclusive or carve-out choice, and that processing integrity is where AI output accuracy becomes a control concern.
Notice how close that list sits to the ISO 42001 Annex A areas. That is the overlap worth engineering once.
What Evidence Can One Lakehouse Produce for Both?
Most of the overlap is data. If your AI systems and the data they read run on a governed lakehouse, the same tables answer both auditors.
| Evidence | Lakehouse source | SOC 2 use | ISO 42001 use |
|---|---|---|---|
| Who can read what | Unity Catalog grants, row filters and column masks | Logical access controls | System use and data management controls |
| Who did read what | Audit log system table copied to a retained Delta table | Monitoring and incident investigation | Operational records for AI systems |
| Where model inputs came from | Column-level lineage from source to feature table to model | Processing integrity of AI-assisted outputs | Data provenance across the AI lifecycle |
| What changed and when | Model versions, pipeline deployments, approval records | Change management | Lifecycle and verification controls |
| Which AI systems exist | An inventory table with owner, purpose, risk class and status | System description accuracy | Scope and Statement of Applicability |
| Which vendors touch data | Approved external model endpoints and usage logs | Vendor and subservice oversight | Third-party relationship controls |
Two platform facts hold that table up. Unity Catalog captures lineage automatically to the column level for queries run on Databricks, though not through UDFs or path-referenced tables. The audit log system table is in Public Preview with a 365-day default retention, which is shorter than a three-year certificate cycle or most audit look-backs, so schedule the copy job. Our data security posture management guide covers finding the sensitive data those controls should protect in the first place.
Why Do Teams Get This Wrong?
The usual failure is sequencing. A sales team hears “AI governance” from a prospect, the company buys a compliance tool, and two parallel programmes start: one collecting SOC 2 screenshots and one writing 42001 policies. Neither reads from the systems that actually run the AI. Six months later there are two evidence folders, two inventories that disagree, and a model in production that appears in neither because a product team shipped it from a notebook. I see the same root cause in both programmes, and it is a process defect before it is a compliance one: nobody mapped how AI systems get built, approved and changed before writing controls to describe it. Fix the workflow first, put the evidence where the systems write it, and let both audits read the same tables. Our AI governance framework lays out that control set in the order we build it.
What Should You Ask Before Signing an Auditor or Building Controls?
- Which assurance is the customer actually asking for? Get the questionnaire section or contract clause in writing before you scope anything.
- Is the AI in scope of our existing SOC 2 system description? If a model processes customer data and the description does not mention it, that gap will surface at the next examination.
- Are our AI vendors subservice organizations, and are we carving them out? Ask your service auditor how they will treat each one.
- Can we produce an AI inventory from a query, today? If not, that is the first build, for either path.
- Is the certification body accredited, and for 42001 specifically? ISO recommends checking accreditation before you hire one.
- How long do we keep access and decision logs? Match retention to the longest audit period you face, not to a platform default.
If you want those answers built into the platform rather than a folder, our AI governance and compliance work starts with the inventory and the shared evidence tables. This is general information, not legal or audit advice; your service auditor and an accredited certification body make the assurance calls.
Frequently Asked Questions (FAQs)
Is ISO 42001 a replacement for SOC 2?
No. ISO 42001 certifies an AI management system; SOC 2 is an attestation report on service controls. Many companies selling AI-enabled services will be asked for both.
Is there a SOC 2 for AI?
Not as a separate framework. The Cloud Security Alliance reports the AICPA has published no AI-specific Trust Services Criteria, and the AICPA’s September 2026 Q&A applies existing criteria to AI use.
Which should a mid-market company get first?
Usually SOC 2, if customers trust you with their data, because that is the assurance a customer handing you its data is usually asking for. Add ISO 42001 when customers start asking specifically how you govern AI you build or embed.
Who issues ISO 42001 certificates?
Accredited certification bodies. ISO states it does not perform certification or issue certificates itself.
Does SOC 2 Type 2 cover AI models?
It covers them where AI affects the system in scope. Auditors apply access, change management, monitoring and vendor criteria to models and AI vendors, and processing integrity to AI outputs.
Can one set of controls serve both audits?
Much of it. Access policies, audit logs, lineage, change records and an AI inventory on one lakehouse answer both; ISO 42001 adds impact assessments and management review on top.