Security

Real offensive depth

Testing and defence led by a published security researcher with six CVEs, including a CVSS 9.1 Mirai botnet kill-switch.

All security →
Compliance

Audit-ready, fixed scope

SOC 2, ISO, CPCSC, and the Canadian privacy stack, run end to end with an independent auditor.

All frameworks →
Resources

Learn the space

Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.

Read the blog →
Compliance

What Is AI Vendor Risk Assessment? A Plain-Language Guide

AI vendor risk assessment is the process of evaluating a third-party AI tool, model, or platform before your company adopts it, so you catch data-handling, security, and compliance problems while they're still the vendor's problem, not yours. It covers what data the tool touches, where that data lives, whether the vendor trains on your inputs, and whether the tool can meet the obligations you've already promised your own customers.

Why "just another SaaS tool" doesn't cover AI

Most companies already run a vendor security review for new software. AI tools break that playbook. A standard SaaS questionnaire asks about encryption, access controls, and breach notification. It rarely asks whether your customer data is being used to fine-tune a model, whether outputs can leak training data back to other users, or whether the vendor's subprocessor list changes every time they swap model providers.

That gap is why AI vendor risk assessment has become its own discipline rather than a checkbox on an existing intake form. Teams in Toronto and Waterloo building on top of OpenAI, Anthropic, or open-weight models are discovering this the hard way when a customer's security team or an auditor asks a question their existing vendor review never anticipated.

Who actually needs this

You need a formal process if any of the following is true:

  • Employees are using AI copilots, chatbots, or coding assistants that touch customer data, source code, or internal documents.
  • Your product embeds a third-party AI API (an LLM, an OCR model, a fraud-scoring model) and you resell the output to customers.
  • You're pursuing SOC 2, ISO 27001, or ISO 42001 and an auditor is going to ask for evidence of vendor due diligence.
  • You operate under PIPEDA or Quebec's Law 25 and need to show you assessed a processor's data handling before sending it personal information.
  • A customer's procurement or security team sent you a questionnaire asking which AI vendors touch their data.

Startups often assume this only applies once they're large enough to have a dedicated security hire. In practice, the exposure shows up the moment an employee pastes a client contract into a free-tier chatbot, which is usually long before anyone owns vendor risk formally.

What an assessment actually involves

A proper assessment isn't a vague gut check. It follows a repeatable sequence:

1. Data mapping

What data type flows into the tool (PII, financial records, source code, health data), and what flows out. This determines everything else, including whether Quebec Law 25 or PIPEDA obligations apply.

2. Vendor documentation review

SOC 2 reports, subprocessor lists, data retention and training policies, and model cards where available. Many AI vendors are newer companies without a SOC 2 yet, which changes the questions you need to ask directly rather than take on faith.

3. Model behaviour and output risk

Does the model hallucinate in ways that create liability for your use case (legal, medical, financial advice)? Can a user extract another customer's data through prompt injection? Is there a documented process for the vendor to patch model-level vulnerabilities?

4. Contractual and compliance fit

Does the vendor's data processing agreement actually match what you told your own customers you'd do with their data? This is where a lot of assessments stall, because marketing claims and the fine print in the DPA frequently disagree.

5. Risk rating and decision

Every vendor gets scored (low, medium, high risk) with a documented rationale, an approval or rejection, and, if approved, any compensating controls (usage restrictions, data masking, no-training opt-outs).

traztech's AI vendor risk assessment service runs this exact sequence and hands clients a documented risk register they can show an auditor, a customer's security team, or their own board, instead of a one-line email saying the tool "looks fine."

How long it takes

For a single tool with a clear use case (a coding assistant, a support chatbot), a focused assessment typically runs one to two weeks: document collection, vendor follow-up on gaps, and a written risk report. For a full AI vendor inventory across a mid-sized company, expect three to six weeks, since most organizations discover they're using more AI tools than the initial list suggested once you ask around the sales and support teams. Ongoing monitoring, re-assessing vendors annually or whenever they change subprocessors, is lighter and can often be folded into an existing vendor management cadence.

Common misconceptions

"The vendor's SOC 2 report covers this"

A SOC 2 report tells you about the vendor's general security controls. It rarely says anything specific about how your prompts and outputs are used, retained, or shared with model providers further up the chain. You still need to read the AI-specific terms separately.

"We signed the DPA, so we're covered"

A data processing agreement is a legal commitment, not a technical control. It doesn't verify that the vendor's infrastructure actually does what the DPA says. Assessment is how you confirm the paper matches the practice.

"This only matters for regulated industries"

Fintech and healthcare feel the pressure first, but any company handling customer PII, source code, or contracts has exposure. A leaked customer list from an unvetted AI tool is a breach regardless of your industry.

"One assessment and we're done"

AI vendors change their models, subprocessors, and training practices more frequently than typical SaaS vendors. An assessment is a point-in-time snapshot, which is why it needs a renewal cadence, not a one-time sign-off.

Where this fits into a broader compliance program

AI vendor risk assessment isn't a standalone exercise for most companies. It slots into the vendor management section of a SOC 2 audit, feeds directly into ISO 42001 readiness work if you're building an AI management system, and matters to Canadian companies specifically because of how PIPEDA and Quebec's Law 25 treat cross-border data transfers to AI providers headquartered outside Canada. Companies in Ottawa, Vancouver, Calgary, and Montreal working toward the Canadian Program for Cyber Security Certification (CPCSC) are increasingly finding AI vendor governance called out explicitly as part of that assessment, not left as an afterthought.

Getting a second set of eyes on your AI vendors

Most companies don't need a permanent AI governance department. They need someone who's done this assessment before to go through the tools already in use, flag the two or three that actually carry risk, and document the rest so the question doesn't reopen every time a customer or auditor asks. That's the boutique-firm advantage over a generic platform subscription: a person who reads the vendor's actual terms, not a form that assumes every AI tool works the same way.

If your team is using AI tools faster than anyone is reviewing them, contact traztech to scope an assessment before an auditor or a customer's security team forces the timeline.

Not ready for a call? Same.

Get the playbook, not a sales pitch

If this was useful, Jacob sends a few short, practical notes on locking down your startup without a big security team. No fluff, unsubscribe in one click. Just reply if you want to talk; it reaches him directly.

From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.

Need help with any of this?

We help startups build secure, scalable infrastructure. Book a free strategy call and let's talk about your stack.

Book a free consultation