AI vendor assessment under ISO 42001: due diligence on the AI you buy

Ask any organization about its AI systems and the answer quickly turns to in-house models or a pilot with a language model. But in almost every AI inventory we perform, the majority of AI turns out to be purchased: SaaS tools with built-in AI features, a chatbot from an external party, HR software with candidate screening, or a vendor that quietly added AI to an existing product. That shifts the center of gravity of AI governance. The question is not only how you control your own models, but above all how you keep a grip on AI that is built, trained and changed by others. ISO 42001 sets explicit requirements for this. In this article we explain what the standard expects and how to set up a workable AI vendor assessment.

## Why AI vendors are a category of their own

Vendor assessment is nothing new for most organizations. Anyone with ISO 27001, or in scope of NIS2 or DORA, already assesses vendors on information security. Yet AI is a fundamentally different category, for three reasons.

First, the product changes under your hands. A vendor that retrains its model or replaces it with a new version effectively delivers a different system, with potentially different behavior, different error patterns and different risks. With classic software you manage this through change management and release notes; with AI it often happens without notice.

Second, the chain is longer and more opaque. Behind the SaaS vendor there is often a model provider, and behind that, training data whose origin cannot always be traced. Meanwhile, your organization remains responsible for the outcomes towards customers, employees and regulators.

Third, AI risks touch different domains than classic security risks: bias in outcomes, incorrect or fabricated output, unwanted reuse of your data for training, and legal questions around intellectual property. A standard security questionnaire does not cover this.

## What ISO 42001 requires

ISO 42001 addresses vendors and third parties in several places. The core: if AI systems or components are supplied by third parties, your organization must have processes to assess those parties, allocate responsibilities in the chain, and manage the risks of supplied AI. Annex A of the standard contains specific controls for the relationship with suppliers and customers in the AI value chain, including documenting responsibilities between parties and assessing services that contain AI components.

Then there is the EU AI Act. The regulation assigns obligations to different roles in the chain: providers, deployers, importers and distributors. Anyone deploying a vendor's AI system is usually a deployer and must, among other things, be able to demonstrate that the system is used according to the instructions and that appropriate oversight is in place. That is only possible if your vendor gives you the right information. Vendor assessment is therefore not just a standard requirement, but also where you collect the information you need for your own compliance.

## Step 1: know which vendors supply AI

Due diligence starts with the inventory. Take your existing vendor register and contract overview as a starting point and ask for each vendor: is there AI in what this party delivers? Watch out for silent additions. Vendors add AI features through regular product updates, without procurement or security being aware. An annual survey among contract owners and a clause obliging vendors to report new AI functionality prevent your register from becoming outdated.

## Step 2: classify by risk, not by contract value

Not every AI vendor deserves the same assessment regime. A spell checker with machine learning is different from a system that co-decides on credit applications or job candidates. Classify vendors by the impact of the AI system: does it touch personal data, does it influence decisions about people, is the output customer-facing, and what happens if the system is wrong? That classification determines the depth of the assessment. Note that contract value is a poor indicator here. A cheap tool with access to sensitive data can pose a bigger risk than an expensive license for a low-risk application.

## Step 3: ask the right questions

The core of the due diligence is a targeted set of questions. Questions that make the difference in practice:

About the model and the data: which data was used for training and how was bias assessed? Is our data used to train models, and is that contractually excluded? Where are our prompts and outputs stored and for how long?

About changes: how does the vendor inform us about model changes or new versions? Can we freeze a version or test it before an update goes live?

About the chain: which subcontractors and model providers sit behind the service? Do our agreements also apply to them?

About demonstrability: does the vendor hold certifications such as ISO 42001 or ISO 27001, or a SOC 2 or ISAE 3402 report? What logging is available so we can monitor usage and outcomes?

About exit: what happens to our data upon termination, and is there a realistic alternative if the service disappears?

## Step 4: capture agreements contractually

A questionnaire is a snapshot; the contract governs the rest of the term. Make sure the answers that weigh heavily in your assessment also land as obligations in the contract or its annexes. Think of a prohibition on training with your data, a duty to notify substantial model changes and incidents, audit rights or the right to periodic assurance reports, and agreements on liability for damage caused by incorrect output. Where personal data is processed, this should come together with the data processing agreement, but do not confuse the two: a data processing agreement covers privacy, not AI-specific risks.

## Step 5: reassess continuously

AI vendor assessment is not a one-time gate but a cycle. Schedule reassessments based on the risk classification, for example annually for high-risk vendors, and reassess in between when triggered: a reported model change, an incident, an acquisition of the vendor, or new regulation. Record the outcomes in your AIMS, so that during a certification audit or customer inquiry you can immediately show which vendors were assessed, when, and with what conclusion.

## Common mistakes

We regularly see three patterns go wrong. Organizations send a generic security questionnaire and consider AI covered, while the AI-specific risks remain unexamined. They only assess new vendors, while the biggest AI risk often sits with existing vendors that have added functionality. And they collect answers without attaching consequences: an assessment without an acceptance decision, mitigating measures or contractual follow-up is administration, not risk management.

Secure Audit supports organizations in setting up AI governance under ISO 42001, including vendor assessment, AI inventory and preparation for certification. The certification audit itself is performed by an accredited certification body. Get in touch for a no-obligation conversation.