Nearly every Canadian SaaS company we talk to has shipped an AI feature in the last eighteen months: summarization in the ticket queue, a copilot in the dashboard, a retrieval assistant over the customer's documents. Then an enterprise buyer asks for the SOC 2 report, opens the system description, and starts asking questions the report does not answer. That gap shows up as a stalled deal, a questionnaire with forty AI-specific rows, and a readiness project re-scoped because nobody counted the model provider as part of the system.
SOC 2 has no AI-specific criteria, and that is the whole problem
There is no AI-specific Trust Services Criterion. SOC 2 rests on the common criteria CC1 through CC9 plus the availability, confidentiality, processing integrity and privacy categories. There is no "CC10 for artificial intelligence", and no separate AI attestation a licensed CPA firm can issue in place of a SOC 2. If a document says your AI system must meet an AI trust services criterion, ask for the citation.
Every AI question therefore arrives through one of two doors. Door one is the existing criteria: the model provider relationship is vendor management, prompt changes are change management, who can reach the training corpus is logical access, whether you notice anomalous output volume is monitoring. Door two is the system description, Section 3 of the report, which management writes and the auditor opines on as fairly presented or not. If your product sends customer data to a third-party inference endpoint and the description does not say so, it is not fairly presented. That is an audit problem, not a marketing problem.
What changes, and why it moves the boundary
Four things change. A new data flow leaves your infrastructure, so the data flow diagram an auditor asks for first is wrong. A new category of data appears in prompts and completions, which hold whatever a user typed. A new upstream dependency appears, and if availability is in scope, so is that provider. A new class of change appears in model versions, system prompts, retrieval configuration and guardrail rules, which most teams ship outside code review.
Is your model provider a subservice organization or a vendor
A subservice organization performs part of the service that is relevant to user entities' internal control over the services in scope. A vendor is a supplier whose controls you do not rely on to meet your commitments. The distinction matters because a subservice organization is carved out of or included in the report, and a carve-out means identifying complementary subservice organization controls, monitoring that provider, and saying so in the system description.
The reflex answer is that a model provider is "just an API vendor". Sometimes that holds: the model never touches customer data, inference runs on weights you host. More often it does not. If customer data flows to the provider, if their retention and deletion behaviour is part of what you commit to your customers, if their access controls are the reason that data stays confidential, they are performing part of the service in scope.
Auditors ask which providers are in the boundary and for which features; what evidence you hold of the provider's control environment and whether you read it; which complementary subservice organization controls you identified; and how you monitor the provider between reports. Monitoring is where companies fail. Downloading a provider's report is not vendor management. Reading it, recording the exceptions, checking that the complementary user entity controls apply to you, and repeating on a schedule, is.
Where the AI questions land in the Trust Services Criteria
The mapping we use when scoping AI-enabled products:
CC9 and CC3, risk mitigation and risk assessment. Provider management. Is the model provider on the vendor register with a risk rating. Was a risk assessment done before the feature shipped. Do the terms permit your use case and your data. Is there a data processing agreement, and an alternative if the provider goes away.
CC8, change management. Model, prompt and configuration changes. Who approves a model version change. Is a system prompt change reviewed the way code is. Do you have a record of which model version served which customer on a given date. Is there regression testing before a change reaches production, and can you roll back. Strong engineering teams have the weakest evidence here, because prompts feel like content.
CC6, logical access. Training data and model endpoints. Who can reach the training or fine-tuning datasets. Who holds the inference API keys, how are they rotated, are they distinct per environment. Did somebody tune on a production export. Who can reach the vector store, and does it inherit the access controls of the documents it was built from. That last one catches retrieval products built on an embedding index with no per-document permissions.
CC7, system operations and monitoring. Output logging. Are prompts and completions logged, where, and for how long. Who can read them. Are they in the data classification scheme. Is there monitoring for anomalous usage or abuse, and an incident response path for an AI-specific failure such as a model returning one customer's content to another.
CC2 and CC5, communication and control activities. Is there an AI acceptable use policy. Do customers know the feature exists and what it does with their data. If confidentiality is in scope, that commitment now has to hold across the provider boundary; if privacy is in scope, notice, choice and consent apply to the AI processing too.
None of this needs a new criterion. It means re-answering criteria you already answered, for a part of the system that is new.
The questionnaire questions that arrive before the auditor does
The security reviewer arrives before the auditor. Have a written answer to each of these first:
- Is customer data used to train or fine-tune your models, or a third party's
- Is customer data retained by the model provider, and for how long
- Can a customer opt out of AI processing, and what happens to the feature then
- Where is inference hosted, in which country, can it be restricted to a region
- What happens to prompts and completions, who reads them, what is the retention
- Is the model provider in your sub-processor register
- Do you have human review for consequential decisions, and how is it evidenced
- What testing have you done against prompt injection and data leakage
- Do you have an AI governance policy and a model inventory
- Will you notify us before adding or changing a model provider
The last one surprises people. Buyers now want change notification rights over the model supply chain, and if your contract does not allow for that, legal should see it before sales promises it.
Training data provenance, and why "we do not train on customer data" is not an answer
Every AI company writes that sentence. It is necessary and not sufficient, because the reviewer has three follow-ups.
What did you train on, then. For anyone who fine-tunes, provenance is a diligence item: where the corpus came from, whether you hold the rights, whether there is personal information in it. A scraped corpus with no licence record is an exposure a reviewer will flag even though it is not a security control.
Does your provider train on it. Your commitment does not bind them, and the answer can differ between a provider's consumer and enterprise offerings. The evidence is the contract clause, not the marketing page.
What about everything that is not training. Retention for abuse monitoring, human review of flagged content and caching all persist customer data at a provider without anyone training on it. An honest answer names all three.
Prompt and output logging is the control nobody scopes in time
A team turns on request logging to debug the feature. Full prompts and completions go to the standard log sink, which is retained for a year, readable by the whole engineering team, shipped to a third-party observability platform, and outside the data classification scheme because it predates the AI feature. The company now holds an unclassified, broadly readable, year-long store of the most sensitive text its customers have entered, possibly outside the SOC 2 boundary and in another country.
The fix is not complicated. Classify these logs at the level of the underlying customer data, set and enforce a retention period, restrict read access and log the reads, redact before logging where you can, and decide whether the observability platform is in scope. Then write that into the system description. What takes time is finding every place it happens: application logs, error tracking, evaluation datasets, support tooling, analytics events and the provider's dashboard.
The governance layer buyers now expect
Three artifacts come up in nearly every AI security review, and SOC 2 names none of them.
An AI acceptable use policy. Internal, covering which external AI tools are approved and what staff may put into them. Cheapest to write, most commonly missing.
A model inventory. Every model in use, its owner, what data it touches, which provider serves it, what version is in production and when it last changed. It is the AI equivalent of an asset register, and it makes CC8 evidence possible. Without it you cannot answer "which version served this customer in March".
Human review for consequential decisions. Where output affects a person's care, credit, employment or access to a service, buyers want a human in the loop and want it evidenced. "A clinician reviews it" is a claim. A record of who reviewed it and what changed is a control. All three reach a SOC 2 through CC1, CC2, CC5 and the system description.
How ISO 42001 and the NIST AI RMF sit beside SOC 2
ISO/IEC 42001 is a management system standard for artificial intelligence, published in 2023, certifiable by an accredited certification body the way ISO 27001 is. It gives structure to AI governance: policy, roles, impact assessment, lifecycle management, supplier controls. It does not replace SOC 2, because a certificate is not an attestation over controls at a service organization. The two overlap at the governance layer, since the same inventory and impact assessment work feeds both. TrazTech offers ISO 42001 readiness on the same two-phase model as the rest of our work.
The NIST AI Risk Management Framework is voluntary, with no certification and no body issuing certificates against it. Its value is vocabulary and structure for your risk assessment, and an answer when a buyer asks what methodology it follows. Use it to organize the work, not as a deliverable.
Sequence the whole thing as SOC 2 first, because that unblocks deals, governance artifacts alongside it, ISO 42001 when a buyer asks for it.
What to do with the OWASP LLM Top 10 in a readiness context
The OWASP Top 10 for LLM Applications is a community list of common weakness classes in LLM-backed software. Prompt injection, sensitive information disclosure, supply chain weaknesses, data and model poisoning, improper output handling and excessive agency come up most in our work.
It is not a control framework and no auditor tests against it. Treat it the way you treat the web application Top 10 during a SOC 2 readiness: the checklist that sets your testing scope, not criteria. It connects at CC4 and CC7. If your risk assessment names prompt injection and your testing program covers it, you have evidence. If the risk register has no AI entries, the risk assessment is incomplete, and an auditor can say so without mentioning OWASP.
Two items deserve a note for anyone building agents. Excessive agency is the model calling tools beyond what the use case requires, a CC6 access question as much as an AI one: the model's effective permissions are those of the credentials you gave it. Improper output handling is model output reaching a browser, a shell or a query without treatment. Our LLM red teaming and AI security assessment work covers this testing, and the report is evidence in a readiness file.
The Canadian angle
Canada has no federal AI statute in force governing private sector AI systems; the AI provisions in the previous privacy bill did not become law. What applies is the existing privacy regime: PIPEDA federally, Quebec's Law 25, Alberta PIPA, and PHIPA in Ontario for health information. Law 25 is the sharpest for AI, because it requires informing an individual when a decision is based exclusively on automated processing and allowing them to submit observations. That is a live obligation for any product making automated decisions about Quebec residents.
Data residency is the other Canadian point. "Where is inference hosted" is harder to answer here, because much managed inference capacity is not in Canadian regions. If you told a customer their data stays in Canada and the inference call leaves, that is a broken commitment before it is an audit finding.
A worked example: an Ontario AI clinical assistant
We ran a SOC 2 Type I for a VC-backed Ontario medtech company putting an AI clinical assistant in front of practitioners. The write-up is published, with the gap analysis and the 84-item evidence request: SOC 2 Type I for an AI Clinical Assistant.
Ordinary SaaS security controls were the bulk of the work. The AI-specific questions clustered around where inference happened and what was retained of the clinical text that passed through prompts. AI does not make a SOC 2 a different kind of project. It adds a few scoping decisions at the start, and punishes you for making them late.
What to do next
Three things pay for themselves before you talk to an auditor. Draw the data flow honestly, including every hop to a third party, and decide for each whether it is a subservice organization or a vendor; that drives the system description, the vendor program and the carve-out language. Build the model inventory. Find every place a prompt or completion is stored, and give each a classification and a retention period.
Then do the gap assessment. TrazTech works in two phases: Phase 1 sets scope and produces a findings register, Phase 2 is remediation scoped and priced from those findings. We do not price remediation first, because nobody knows the gaps yet, and for an AI-enabled product the boundary question alone can move the size of the project. TrazTech is the readiness partner; the attestation is issued by an independent licensed CPA firm and ISO certification by an accredited certification body. SOC 2 and ISO 27001 readiness starts from $3,000, penetration testing from $1,000, fractional CISO from $3,000 a month.
Worth asking any firm you consider: have they completed AI-involved engagements in Canada they can show you; who signs the audit and can they be referenced; is remediation priced before or after the gap assessment; which entity signs the contract and under which province's law; and where does your engagement data live.
To have the AI side tested rather than only documented, start with an AI security assessment or LLM red teaming, and bring the report into the readiness file.