How to Get AI Vendor Risk Assessment: A Step-by-Step Guide

You get an AI vendor risk assessment by inventorying every AI tool your team actually uses, scoring each one against data handling, model training, and compliance criteria, then documenting the findings before you sign a contract or renew one. Done properly, it takes two to four weeks for a mid-sized SaaS company with a moderate AI footprint, longer if procurement has been informal and nobody has a full list of what is actually in use.

That last part is the real problem. Most Canadian tech companies do not have an AI vendor risk problem because they lack a process. They have one because a developer added an AI code assistant on a Tuesday, marketing signed up for an AI writing tool on a Friday, and neither purchase ever touched security review. By the time a customer's due diligence team or a SOC 2 auditor asks "which AI tools have access to your data," the honest answer is often "we are not entirely sure." This guide walks through the assessment process that fixes that, step by step, with the timelines you should actually expect.

Step 1: Build a Complete AI Tool Inventory (Week 1)

You cannot assess what you have not found. Start with a discovery pass across three sources:

• Finance and procurement records: expense reports and SaaS subscription tools will surface anything paid for with a corporate card.
• SSO and identity provider logs: any AI tool your team logs into with Google or Microsoft SSO shows up here, including free-tier tools nobody expensed.
• A short employee survey: ask directly which AI tools people use for coding, writing, customer support, or data analysis. This catches shadow IT the other two methods miss, especially browser extensions and personal-account usage.

Expect this step to surface more tools than you expect. It is common for a 40-person company to find 15 to 25 distinct AI tools in active use once you look past the obvious ones like ChatGPT or GitHub Copilot.

Step 2: Classify Vendors by Data Exposure and Business Criticality

Not every AI tool deserves the same scrutiny. A grammar checker with no access to customer data is a different risk category than an AI tool that ingests your codebase or customer support tickets to generate responses. Sort your inventory into tiers:

• Tier 1, high risk: tools with access to customer PII, source code, financial data, or protected health information.
• Tier 2, moderate risk: tools with access to internal but non-sensitive business data.
• Tier 3, low risk: tools with no meaningful data access, used for isolated tasks.

Tier 1 vendors get the full assessment described below. Tier 2 gets a lighter version. Tier 3 gets a one-time check and periodic re-review. This triage is what keeps the process from taking six months on a company with dozens of tools.

Step 3: Request and Review the Vendor's Security and AI Governance Documentation (Weeks 1 to 2)

For each Tier 1 vendor, request:

• Their SOC 2 Type II report or equivalent, and its exceptions
• A written data processing agreement or AI addendum
• Their model training policy, specifically whether your inputs are used to train their underlying models
• Sub-processor list, since most AI vendors are themselves built on top of another provider's foundation model
• Data residency and retention terms

This is the step where response time becomes your bottleneck rather than your own effort. Enterprise AI vendors with a mature trust program can turn documents around in days. Smaller or newer AI startups, which describes a large share of the tools your team is probably experimenting with, sometimes do not have this documentation written down at all. Build in a buffer for follow-up and, in some cases, a decision to not use a vendor because they cannot answer the model training question.

Step 4: Score Against a Consistent Risk Framework

Use the same scoring criteria across every vendor so the results are comparable and defensible to an auditor or a customer's security team later. A workable framework scores each vendor on:

• Data handling practices and encryption in transit and at rest
• Whether customer data trains the vendor's models by default, and whether opt-out is available
• Sub-processor transparency and their own security posture
• Compliance certifications held (SOC 2, ISO 27001, ISO 42001)
• Incident history and breach notification terms in the contract
• Data residency, which matters directly for PIPEDA and, for any vendor touching Quebec residents' data, Quebec's Law 25

The output should be a simple risk rating per vendor, not a fifty-page report nobody reads. If your company is working toward SOC 2, this scoring becomes part of your vendor management control and needs to be repeatable on a schedule, not a one-time exercise.

Step 5: Decide, Document, and Set Contract Terms

For each vendor, the assessment ends in one of three outcomes: approve, approve with conditions, or reject. "Approve with conditions" is common, for example requiring the vendor's enterprise plan (which usually disables model training on your data) rather than their free or team tier. Document the decision and the reasoning. This record is exactly what a SOC 2 auditor or an enterprise customer's procurement team will ask to see, and having it ready is far better than reconstructing it under deadline pressure during due diligence.

Step 6: Set a Re-Assessment Cadence

AI vendors change their terms, their sub-processors, and their model training defaults more often than traditional SaaS vendors do. A tool that did not train on your data last year may quietly change that default in a terms update. Tier 1 vendors should be re-reviewed at least annually, and any vendor with a material change to its terms or a public incident should trigger an immediate re-check rather than waiting for the annual cycle.

Realistic Timelines

For a company with 15 to 25 AI tools in scope, expect roughly:

• Discovery and tiering: 1 week
• Documentation collection for Tier 1 vendors: 1 to 3 weeks, dependent on vendor response time
• Scoring and decisions: 3 to 5 days
• Total for a first pass: 3 to 5 weeks

Subsequent annual re-assessments run faster, typically 1 to 2 weeks, since the inventory and documentation baseline already exists.

Where a Partner Helps

The mechanics above are not complicated, but they are time-consuming and easy to deprioritize once week two hits and half the vendors have not replied yet. That is usually where the process stalls inside companies without a dedicated security function, which describes most Canadian tech companies under 200 people. traztech runs AI vendor risk assessments as a fixed-scope engagement: we do the discovery, chase down vendor documentation, apply a consistent scoring framework, and hand you a decision record you can put in front of an auditor or a customer's security questionnaire. We work with companies in Toronto, Waterloo, Ottawa, Vancouver, Calgary, and Montreal, and the assessment accounts for PIPEDA and, where relevant, Quebec's Law 25 from the start rather than as an afterthought.

If your company is scaling into the US and expects SOC 2 due diligence to ask about AI tool usage, this is worth doing before that conversation happens, not during it. It also pairs naturally with broader compliance program work if AI governance is one gap among several.

Get in touch with traztech at /contact to scope an AI vendor risk assessment for your tool inventory.

What the Vendor's Answer Actually Means

The single question that decides most AI vendor assessments is whether your inputs are used to improve the vendor's models. The trouble is that vendors answer it in language that sounds reassuring and means very little. Three phrases come up constantly and each one needs a follow-up.

"We do not train on customer data." Ask which plan that applies to. Many vendors disable training only on business, enterprise, or API tiers, and leave it enabled by default on free and personal tiers. If half your engineers signed up with a work email on the free tier, the enterprise commitment in the contract does not cover them. Ask for the statement to be tied to the account, not the product.

"Your data is not retained." Retention and training are separate questions and vendors often conflate them. A vendor can retain prompts for thirty days for abuse monitoring while not training on them, and that thirty-day window still puts your customer data on their infrastructure and inside their breach blast radius. Ask for the retention period in days, where the data sits, who inside the vendor can read it, and whether a zero-retention option exists on your tier.

"We use a leading foundation model provider." That is a sub-processor disclosure wearing a marketing jacket. Ask which one, under what contract terms, in which region, and whether the vendor has passed its own no-training commitment upstream. A vendor that promises not to train on your data but sends it to an upstream API under default consumer terms has made a promise it cannot keep. This is the most common broken link we find in AI vendor chains, and it is usually not deception. The vendor's own founders often have not read the upstream terms since they signed up.

The Contract Clauses That Do the Work

An assessment that ends in "approve with conditions" is only worth the paper it is written on if the conditions land in the agreement. Five clauses carry most of the weight, and they are worth naming specifically to whoever handles your contracts.

A data processing agreement or AI addendum that names your data categories rather than referring vaguely to "customer content". A no-training commitment expressed as a contractual obligation, not a link to a support article the vendor can edit unilaterally. A sub-processor list with a change notification period, thirty days is the workable norm, and a right to object. Breach notification with a stated deadline in hours, because the default in many AI startup terms is "without undue delay", which auditors and enterprise customers both push back on. And deletion on termination, covering derived artefacts such as embeddings and fine-tuning checkpoints, not only the raw uploads.

That last one matters more than people expect. If the vendor builds an index over your documents, deleting the source files does not necessarily remove them from retrieval. Ask what happens to the index.

How an Auditor Actually Tests This Control

Companies preparing for SOC 2 often assume the auditor wants to see the assessment reports. What the auditor tests is the control, and the control is usually worded as something like "management performs a risk assessment of third parties with access to customer data prior to engagement and at least annually thereafter". Testing that means the auditor picks a sample.

They will ask for the full vendor population, choose five to ten names from it, and ask for the assessment record and the approval date for each. Two failure modes show up repeatedly. The first is that the sampled vendor was onboarded three months before the assessment was performed, so the record exists but the timing breaks the control. The second is that the population list is incomplete, which the auditor discovers by cross-checking against your expense report or your identity provider. If a tool appears in the SSO logs but not in the vendor list, the control is not operating, regardless of how good the assessments themselves are.

This is why discovery is not a one-off exercise. Whatever you build for the first pass needs a repeatable way to catch new tools, whether that is a procurement gate, a monthly review of new SSO applications, or an approval step in the tool your team already uses to request software. A messy but repeated process tests better than an elegant one performed once. You can keep the register, the evidence and the review dates in the free traztech Workspace if you do not already have somewhere sensible for them to live.

The Categories People Miss

Discovery based on expense reports and SSO catches the obvious subscriptions. Four categories tend to slip through and each of them has bitten a company we have worked with.

Browser extensions. An AI extension with page-read permission sees whatever the employee sees, including your admin console, your support tool, and your customers' records. Nothing about it appears in procurement. Managed browser policy is the practical control here.

Features inside tools you already bought. Your help desk, your CRM, and your code host have all shipped AI features in the past two years, often enabled by default and governed by an updated terms page rather than a new contract. The vendor was assessed. The feature was not.

Agents and connectors with write access. An assistant that reads a document is a confidentiality question. An assistant with a connector that can create tickets, push commits, send email as a user, or move money is an integrity question, and it needs a different review. Ask what the agent can do, not only what it can see.

Model providers reached directly from your own code. If your engineers call a model API inside your product, that provider is a sub-processor of yours and belongs on your customer-facing sub-processor list. Plenty of companies assess the AI tools their staff use and forget the API key sitting in their own production environment.

When the Vendor Will Not Answer

You will hit vendors, usually small ones, that have no SOC 2 report, no DPA template, and no clear answer on training. That is not automatically a rejection. It is a decision about compensating controls, and there are a few that hold up.

Restrict the data that reaches the tool, so the tool is approved only for non-sensitive internal use and that restriction is written into the record. Require a specific plan tier with the terms you need. Put the tool behind SSO so you can revoke access in one place. Or accept the risk explicitly, at a named approver, with a review date. An auditor is comfortable with a documented accepted risk. What fails is a gap with no owner and no date.

If the vendor is central to your product and cannot answer basic questions about retention and sub-processors, treat that as commercial information as much as security information. A vendor without a trust programme in 2026 is a vendor that will slow down every enterprise deal you take them into.

What Drives the Cost

If you are buying this as an engagement rather than running it yourself, the price moves on four things. The number of Tier 1 vendors, since Tier 2 and Tier 3 reviews are quick and Tier 1 is where the document chasing happens. Whether a usable inventory already exists or has to be built from scratch across finance, identity and interviews. Whether the output has to map to a named framework, because a scoring model that has to line up with SOC 2 vendor management, ISO 27001 Annex A supplier controls, and your customers' questionnaires takes longer to design than a generic rating. And how much of the vendor chasing you want done for you, which is the part that consumes calendar time rather than skill.

Vendor response time is the variable nobody controls. Budget for it rather than promising your board a date that depends on a support inbox at a twenty-person startup.

When You Should Not Hire Us for This

If you have fewer than five AI tools and one of them is a code assistant on an enterprise plan, run this yourself in an afternoon. Pull the SSO application list, read the two contracts that matter, write a page per Tier 1 vendor, and put a calendar reminder eleven months out. Paying anyone for that is paying for typing.

If you already have a security or GRC hire, the honest answer is that this work should be theirs. It is a good early project for someone new in the role because it forces them to meet every team and see how software actually gets bought. Outsourcing it removes the one exercise that would have taught them the company.

And if AI vendor risk is the only gap between you and an audit, buying a standalone assessment is probably the wrong shape of purchase. It usually turns out to be one finding inside a broader readiness position, and it is cheaper to handle it inside compliance work you were doing anyway than as its own engagement. Where it genuinely earns outside help is the opposite case: a large, untracked tool estate, a customer due diligence deadline, and nobody internally whose job it is to chase forty vendors for documents. If that is your situation, tell us the vendor count and the deadline and we will tell you whether it is worth a fixed scope or a slot on an ongoing retainer.