If you sell software with an AI feature to enterprise buyers, you have probably heard both acronyms in the same breath: SOC 2 and ISO 42001. Procurement teams throw them around interchangeably, which is a problem, because they are not interchangeable. They answer different questions, they get asked for by different people at different stages of a deal, and confusing one for the other can stall a sale you thought was already won.
This is a common point of confusion for Canadian SaaS companies moving upmarket into the US, so let's separate the two clearly, then talk about why most companies selling AI products end up needing both.
What SOC 2 actually proves
SOC 2 is an attestation report, not a certification. An independent CPA firm audits your security controls against the AICPA's Trust Services Criteria (security, availability, confidentiality, processing integrity, and privacy) and issues an opinion on whether those controls are designed properly (Type I) or operating effectively over a period of time, typically three to twelve months (Type II). Buyers ask for SOC 2 to answer one question: can we trust you with our data and our uptime? It covers access controls, change management, incident response, vendor risk, encryption, and the general operational hygiene of a SaaS business. Security teams and procurement at almost any US enterprise will ask for a SOC 2 report before they sign, regardless of whether your product touches AI at all.
What ISO 42001 actually proves
ISO 42001 is a certification, not an attestation. It is the first international standard for an AI management system (AIMS), and it is issued by an accredited certification body after an audit against the ISO 42001 standard itself. It does not ask "is your infrastructure secure." It asks "do you have a governed, documented, repeatable process for how you build, deploy, monitor, and improve AI systems." That means things like: how you evaluate models before shipping them, how you handle bias and fairness testing, how you log and monitor AI outputs in production, how you handle human oversight of automated decisions, and how you manage the lifecycle of the data feeding your models. If your product makes or influences decisions using machine learning, especially in regulated sectors like finance, healthcare, insurance, or HR tech, this is the standard that speaks directly to AI-specific risk. We cover the full scope of what an audit actually checks on our ISO 42001 readiness page.
Who asks for which, and when
In practice, the request usually maps to the role asking:
- Security and IT teams ask for SOC 2 almost universally, early in the deal cycle, often as a gate before a demo even gets scheduled with legal or procurement.
- Legal, risk, and compliance teams ask for ISO 42001 (or an equivalent AI governance framework) later, usually once the buyer's own AI governance policy requires vendor-level proof that your model development and monitoring practices are sound.
- Regulated-industry buyers (banks, insurers, healthcare payers) increasingly ask for both up front, because their own regulators are starting to expect documented AI risk management from every vendor in the chain.
The pattern we see with clients: SOC 2 gets you in the room. ISO 42001 gets you through the room when the product itself is the thing under scrutiny, not just the infrastructure it runs on.
Why "either-or" is the wrong frame
SOC 2 and ISO 42001 overlap in places (both touch access control, incident response, and vendor management) but they are not substitutes for each other. SOC 2 says nothing about model bias, explainability, or human oversight of automated decisions. ISO 42001 says nothing about whether your database backups are encrypted or your on-call rotation actually works. A buyer's security team reading your SOC 2 report cannot use it to answer their AI governance committee's questions, and a buyer's AI risk committee reading your ISO 42001 certificate cannot use it to answer their infosec team's questions. If you only have one, you have answered half the diligence and left the other half open, which is exactly where deals get delayed while a new document request goes back and forth. For companies with an AI feature that matters to the sale, the realistic target state is both: SOC 2 as the baseline every enterprise buyer expects, and ISO 42001 as the specific answer to "how do you govern the AI part." Where you start depends on what's actually blocking your current pipeline. If the objections you're hearing are about uptime, data handling, and general security posture, start with SOC 2 (or the broader security programme our security work covers). If the objections are specifically about model risk, bias, or automated decision-making, ISO 42001 readiness is the more direct fix.
Sequencing them without duplicating work
Because the two frameworks overlap on core controls like access management, logging, and vendor risk, doing them in sequence rather than from scratch each time saves real audit hours. Most companies build SOC 2 first since it is the more commonly requested baseline, then layer ISO 42001 on top, reusing policies, risk registers, and evidence collection processes rather than duplicating the groundwork. The AI-specific pieces, model documentation, bias testing, human oversight controls, get built as additions to an already-functioning governance programme rather than as a parallel system.
This is also where a lot of teams underestimate scope. ISO 42001 readiness is not a checklist you complete in a sprint. It requires defining the boundaries of your AI management system, documenting your model lifecycle end to end, and building monitoring that a third-party auditor can actually verify, not just describe in a policy document.
The bottom line
If you are fielding both acronyms from the same buyer, that is a signal, not a redundancy. It usually means the deal has moved from "is this vendor secure" to "is this vendor's AI trustworthy," and those are genuinely separate diligence tracks. Treat them as complementary pieces of the same trust story rather than picking one and hoping it covers the other.
Not sure which one your current pipeline actually needs first? Get in touch and we'll walk through what your buyers are actually asking for and build the right sequence for your team.