SOC 2 vs ISO 42001: Which AI Governance Proof Do Buyers Want?

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.

The paperwork is different, and buyers handle it differently

Beyond what each framework proves, the two produce artefacts that behave differently inside a buyer's vendor risk process, and that shapes how you use them in a deal.

A SOC 2 report runs forty to eighty pages: the auditor's opinion, management's system description, and the table of controls with the tests performed and the results. It is confidential. You will hand it over under NDA, one buyer at a time, and their analyst will read the exceptions and the complementary user entity controls before anything else. Because it covers a defined period, it expires in a practical sense: once your report period ended more than a few months ago, the analyst wants a bridge letter from your management confirming nothing material changed, or they want the next report.

An ISO 42001 certificate is a single page. It names the certification body, the accreditation, the certificate number, the validity dates, and a scope statement. Nobody signs an NDA to see it, and it goes on your trust page. The detail lives in your Statement of Applicability and management system documentation, disclosed selectively. The cycle is three years with surveillance audits in between rather than an annual report, so the renewal rhythm is different and the gap problem does not arise the same way.

The practical consequence: the certificate is the thing that gets you past an automated procurement filter, and the report is the thing that survives a human reading it closely. If your buyer's process is a portal with a checkbox for AI governance certification, a beautifully run but uncertified AI management system scores zero. If your buyer's process is an analyst on a call, the running programme with evidence beats a certificate with a thin scope statement. Which of those you are facing is worth asking before you spend anything.

Read the scope statement, including on your own certificate

The scope statement is where ISO certifications get hollowed out, and experienced diligence teams know it. A certificate scoped to "the development and operation of the recommendation service" tells a buyer that the copilot handling their customer data sits outside the management system entirely. A narrow scope bought to save money can end up worse than no certificate, because you have handed the buyer a document that records an exclusion.

Apply the same reading to vendors you assess. When an AI vendor sends you their ISO 42001 certificate, check whether the scope covers the product you are buying, whether the certification body is accredited, and whether the validity dates are current. The equivalent check on a SOC 2 report is the period covered, the criteria in scope, whether the opinion is unqualified, what the exceptions say, and which subservice organisations were carved out. Both documents can be technically genuine and substantively irrelevant to the thing you are worried about.

Where the work genuinely overlaps, and where the overlap claim is oversold

Both frameworks want access control, change management, vendor and supplier management, incident handling, human resources security, and a risk assessment process that produces records rather than opinions. If you have those operating for SOC 2, they carry across, and that is real saving.

What does not carry across in either direction is larger than the mapping tables suggest. ISO 42001 requires internal audit, management review, a documented scope boundary for the management system, competence records, and a corrective action process, none of which SOC 2 demands as such. SOC 2 requires a system description written to a specific standard, a control matrix mapped to trust criteria, and evidence sampled across a period, none of which the ISO management system produces natively. Then the AI-specific half of Annex A, impact assessment, data provenance for training, model life cycle documentation, human oversight, and information provided to interested parties, has no SOC 2 counterpart at all.

Be sceptical of any tool or consultancy quoting a crisp overlap percentage. The honest answer is that the number is not computable in a meaningful way, because evidence artefacts have free-text titles that differ by framework, by auditor, and by company. A screenshot proving quarterly access review satisfies both, but only if someone maps that specific artefact to both control references deliberately. Left alone, the same review gets filed twice under two names and nobody notices. The saving is real and it comes from disciplined evidence management, not from the frameworks being secretly the same. Keeping one register with each artefact mapped to every control it serves is what converts theoretical overlap into fewer hours, and it is why we give clients a free Workspace to hold that register rather than letting it live in a shared drive.

Timelines and what actually drives the cost of each

SOC 2 timing is dominated by the observation period. Readiness work, then controls operating, then a Type II window of three to twelve months, then fieldwork, then the report. A first Type II inside six months of starting is achievable if the readiness work is disciplined; a Type I can land much sooner and buys you a credible interim answer. Our fixed-scope track is published as SOC 2 in 75 Days, from $3,000 for the gap analysis, and the audit fee sits on top of that with an independent CPA firm.

ISO 42001 timing is dominated by how much management system you already have and how many AI systems land in scope. With a live ISO 27001 management system you are extending something that already runs internal audit and management review. Without one you are building the whole Annex SL apparatus before the AI-specific controls start. Then certification adds a Stage 1 documentation review and a Stage 2 audit, and accredited certification bodies for this standard are still scarce enough that booking is a scheduling constraint in its own right.

Cost drivers for SOC 2: criteria in scope, number of systems and entities, how many subservice organisations, and how organised your evidence is when the auditor opens the package. Cost drivers for ISO 42001: number of AI systems, whether you train or fine-tune anything, whether personal data feeds a model, and whether you already run an ISO management system. Different levers, which is why "which is cheaper" is the wrong question.

Who owns each one internally

SOC 2 has an obvious owner in most companies: whoever runs security and infrastructure, with engineering supplying evidence. ISO 42001 does not, and that ambiguity is the most reliable predictor of a stalled project we see. The AI management system touches product decisions about what a model is allowed to do, legal questions about training data rights, engineering practice on evaluation and monitoring, and support processes for handling complaints about automated output. Nobody in a fifty-person company owns all of that.

The arrangement that works is a named owner with authority over the product roadmap, not a compliance coordinator collecting documents. Someone who can say a feature does not ship until its impact assessment is done, and be believed. In smaller companies that is often a founder for the first year, then a security or risk lead, which is a common reason teams bring in a fractional CISO to hold both this and the security programme rather than hiring twice. If nobody can be given that authority, delay the project rather than staffing it with someone who will be overruled.

The third answer: sometimes neither is what the buyer needs

A meaningful share of AI governance requests are satisfiable without either credential, and it is worth testing that before committing budget. Ask the buyer what decision the document supports. Often the honest answer is that their AI governance policy requires them to record something about each vendor, and what they need is a completed questionnaire, your AI system inventory, your data handling commitments in the contract, and a named contact for AI incidents.

Alignment with the NIST AI Risk Management Framework is a lighter option that many US buyers accept, particularly when the alternative is waiting a year for a certificate. It is voluntary, there is no certificate, and a self-assessed alignment statement is worth exactly as much as the evidence behind it, but for a buyer who mainly wants to see that you have thought about this seriously, it can close the question. We compared the two approaches in ISO 42001 vs NIST AI RMF. The failure mode to avoid is producing an alignment statement with nothing underneath it, because a buyer who probes and finds nothing will trust the rest of your answers less.

When you should not buy either of these from us

The honest version, since this is the part most comparison articles leave out.

When the AI feature is not material to the deal. If your product has an LLM writing draft email subject lines and the customer's data never touches it, ISO 42001 is not what is blocking your pipeline. Write it down, disclose it, move on.

When one deal is driving everything. A single enterprise prospect asking for AI governance evidence is not a reason to build a certified management system. It is a reason to answer their questionnaire well and ask what specifically would satisfy them. Sometimes the answer is a contract clause. Building a management system for one logo, then losing the deal on price, is an outcome we have watched happen.

When your security fundamentals are not in place. If you do not have MFA everywhere, an offboarding process that works, backups you have restored from, and logging you actually read, both frameworks will surface that and you will pay consultants to discover what you already suspect. Fix the fundamentals first. That is cheaper and it is a better use of the quarter.

When you have the people to run it. Companies with an existing ISO 27001 management system and a competent internal auditor frequently do not need an implementation partner. They need someone to review their gap analysis and challenge their scope statement, which is a couple of days of work, not a programme. We will quote it that way, and if you would rather have it as a standing arrangement than a project, that is what a retainer is for.

When the real requirement is regulatory. If you are placing a high-risk AI system on the EU market, your obligation comes from the regulation, and no certificate discharges it. Read the regulation against your product, work out which role you hold, then decide what a management system adds on top. Buying the certificate first and reading the law later gets the order backwards.

What to say when a buyer asks today and you have neither

You will get the question before you have the documents, so have an answer that does not sound like stalling. What works: here is the inventory of AI systems in our product and what each does. Here is our written position on customer data and model training, and here is where it appears in the contract. Here is who reviews output before it reaches a customer in the workflows where that matters. Here is our current security attestation status and the date of the next report. Here is our AI governance roadmap with dates, and here is the person who owns it.

That answer, delivered with the artefacts attached, gets more deals through diligence than most people expect, because it demonstrates the thing the certificate is supposed to demonstrate. What does not work is a promise with no dates, or a claim of alignment nobody can evidence. If you find yourself unable to assemble the paragraph above, that gap is the actual project, and it is smaller than either certification.