This article provides a practical checklist and decision record. The checklist and decision record are editorial syntheses requiring local adaptation.
| Fact to establish | Evidence to request | Why it matters | Owner | Escalation trigger |
|---|---|---|---|---|
| Intended service and use | Service description, use-case documentation | Defines the scope of the assessment | Procurement | Use changes after onboarding |
| Data flow | Data flow diagram, input/output specification | Identifies what data is exposed | Security, privacy | New data categories introduced |
| Model and provider chain | Model documentation, provider list | Identifies dependencies and change risk | Technical owner | Model or provider change |
| Security architecture | Security documentation, penetration test summary | Assesses technical controls | Security lead | Security incident, architecture change |
| Access controls | Access management documentation | Assesses who can access what | Security lead | Access model change |
| Retention and deletion | Data retention policy, deletion procedure | Assesses data lifecycle | Privacy lead | Retention policy change |
| Training use | Training data policy, opt-out mechanism | Assesses whether your data trains models | Privacy lead | Training policy change |
| Subprocessors | Subprocessor list, flow-down terms | Identifies downstream risk | Procurement, legal | New subprocessor added |
| Incidents | Incident response plan, notification terms | Assesses response capability | Security, incident lead | Incident occurs |
| Changes | Change management process, notification terms | Assesses continuity of controls | Technical owner | Material change without notice |
| Assurance evidence | Certifications, audit reports, test results | Adds evidence with a defined scope and date | Procurement, security | Assurance expires, changes or is withdrawn |
| Contract terms | Contract, DPA, SLA, exit terms | Defines legal obligations | Legal, procurement | Contract renegotiation |
What is an AI vendor risk assessment?
A vendor risk assessment is the diligence an organisation performs before approving a supplier, service or contract. It covers:
- The supplier's identity and the specific service being considered.
- The data flows: what enters, what is processed, what is stored, what is returned.
- The security architecture and access controls.
- The model's provenance, evaluation and change management.
- Subprocessors and supply-chain dependencies.
- Incident response, continuity and exit.
- Legal, regulatory and contract evidence.
- Unresolved gaps, compensating controls and conditions.
The ICO contracts and third parties AI toolkit supports clarifying controller and processor roles, pre-procurement diligence, purpose and data documentation, subprocessors, security controls, incident responsibilities and assistance with data-protection assessments. It is data-protection-focused, not a complete commercial or AI-safety review. The ICO says the toolkit is under review following the Data (Use and Access) Act 2025.
Vendor assessment versus AI use-case assessment
These are two separate assessments:
| Aspect | Vendor risk assessment | AI use-case risk assessment |
|---|---|---|
| Question | Do the supplier and service risks fit the proposed relationship? | May this defined use proceed, and under what conditions? |
| Scope | Supplier, service, data flows, contract | Use case, affected people, data, controls |
| Owner | Procurement, security, legal | Use-case owner, risk owner |
| Output | Supplier-and-service decision, conditions, contract terms | Use-case decision, conditions, monitoring |
| Reassessment | Provider change, contract change, periodic | Use change, incident, periodic |
A satisfactory vendor review does not approve every proposed use case. Keep the two decisions separate whenever both a supplier and a use are in scope.
To assess the organisation's proposed AI use separately, see the AI risk assessment template.
Define the service, use and data flow before sending questions
Before requesting evidence, define:
- The specific service or product being considered.
- The intended use in your organisation.
- The data that will flow to and from the service.
- The users and affected people.
- The integrations and dependencies.
- The contract terms you require.
This prevents a generic questionnaire from being sent to a specific service. The questions should be tailored to the actual use.
Scope the review to the product edition, tenant configuration and features you intend to buy. Evidence for a provider's consumer product may not answer questions about its enterprise service, and a group-wide policy may not describe the system that handles your information. Put a date and owner on the scope record so later changes can be compared with the decision you actually made.
Draw the data flow before debating controls. Show who submits information, which supplier or subprocessor receives it, where an output returns, what is retained and how administrators or support staff may access it. Mark any point the team has not verified. An honest gap is more useful than a neat diagram built on assumption.
AI vendor risk assessment checklist
The following checklist is an editorial synthesis. It is not a universal standard or a pass/fail score. Each item should be answered with evidence, and gaps should be recorded.
Supplier and service identity
- Full legal name and registration details.
- The specific service or product being assessed.
- The service's intended purpose and limitations.
- The service's target market and typical use cases.
Intended use and prohibited uses
- What is the service designed to do?
- What is it not designed to do?
- What uses are prohibited by the provider?
- Does your intended use fall within the provider's stated scope?
Data inputs, outputs and purpose
- What data enters the service?
- What is the purpose of processing that data?
- What data is returned or stored?
- What is the data flow (input, processing, output, storage, deletion)?
- Which optional features, integrations or support routes create another data path?
Storage, retention, deletion and training use
- Where is data stored (location, jurisdiction)?
- How long is data retained?
- How is data deleted on request or at contract end?
- Is your data used to train models? If so, can you opt out?
- What are the subprocessor data handling terms?
Security architecture and access
- What security architecture is used?
- What access controls are in place?
- What testing has been performed (penetration test, code review)?
- What is the security incident response process?
- What is the fallback plan for mission-critical systems?
- Which administrative events are logged, who can inspect them and for how long?
Published in November 2023, the NCSC secure AI development guidance supports lifecycle supply-chain assessment, documented components, security standards, fallback planning, asset versioning and documentation of limitations and failure modes. It covers a cybersecurity lane, not a complete governance, privacy or procurement framework.
Model provenance, evaluation and change management
- What model is used (name, version, provider)?
- What evaluation has been performed?
- What are the known limitations and failure modes?
- How are model changes managed and communicated?
- What is the change notification process?
Subprocessors and supply chain
- Who are the subprocessors?
- What are the flow-down terms?
- How are subprocessor changes communicated?
- What is the supply-chain risk?
Incidents, continuity and exit
- What is the incident notification process and timeline?
- What is the business continuity plan?
- What is the exit process (data return, deletion, transition)?
- What are the service level agreements?
- Can the organisation export the records it needs to change supplier or stop the service?
Legal, regulatory and contract evidence
- What is the role allocation (controller, processor, joint controller)?
- What data protection terms apply?
- What are the contractual commitments?
- What assurance evidence is available (certifications, audit reports)?
- What are the liability and indemnity terms?
The NIST AI RMF Core supports documented requirements, risk tolerance, defined roles and third-party risk work. Vendor assessment is one way to address third-party risk, but it does not by itself prove compliance or effectiveness.
Evidence quality: answer, document, test and independent assurance
This evidence model is an editorial synthesis for local procurement, legal and security teams to adapt.
Evidence does not sit in one universal ladder. Its value depends on relevance, independence, recency and scope:
- An answer can clarify the service quickly, but the owner, date and supporting material still matter.
- A policy or technical document can show the intended design; check that it covers the service and configuration under review.
- A test can demonstrate behaviour under stated conditions; read its method, date, exclusions and result.
- Independent assurance can reduce reliance on self-attestation, but only for the systems, period and controls inside its scope.
- A contractual commitment records what the parties agreed, but it does not show that a control has operated.
Match each claim to the evidence that would actually support it. If a vendor says customer content is not used for model training, for example, establish which products, account settings and data types the statement covers, then check the relevant terms or technical evidence. Record exceptions instead of smoothing them into a yes/no answer.
No questionnaire, document, test or certification proves suitability, safety or compliance by itself. A narrowly relevant test may answer one question better than a broad certification. The assessment should preserve what each item shows, what it does not show and when it needs to be refreshed.
Record gaps, compensating controls and conditions
For each gap identified:
- Record the gap and its risk.
- Identify any compensating controls.
- Define any conditions for approval.
- Assign an owner and a review date.
- Record the decision and its reasoning.
A gap does not automatically mean the vendor is unsuitable. It may be accepted by the named authority with a compensating control, a contract condition, a restricted use or a deadline for evidence. Record the gap owner, due date and consequence if it remains open. A blank answer and an accepted uncertainty are not the same thing.
Make and document the vendor decision
Copy-and-adapt vendor decision record
The following record is an editorial synthesis requiring local procurement, legal and security adaptation.
- Supplier, service, edition and configuration: [...]
- Supplier/service scope evaluated and information classes considered: [...]
- Supplier/service decision: [accept for the evaluated scope / accept with conditions / decline]
- Explicit exclusions: [...]
- Open evidence gaps: [...]
- Conditions and preconditions: [...]
- Owners and due dates: [...]
- Evidence retained and location: [...]
- Reassessment triggers: [...]
- Decision maker and date: [...]
The vendor decision should record:
- The decision: approve, approve with conditions, or decline.
- The decision maker and date.
- The conditions (if any) and their owners.
- The gaps and compensating controls.
- The reassessment triggers.
- The contract terms that reflect the assessment.
State precisely what the supplier-and-service decision covers: the named supplier, service, edition, configuration, intended relationship and information classes considered. This decision does not authorise the proposed AI use; that remains a separate decision for the organisation's use-case approval authority. Also state what has not been accepted. If a condition must be met before contracting or onboarding, retain the evidence of closure rather than treating the decision label as proof that it happened.
Map important promises to their contractual or testable home. A sales answer may prompt a contract clause; a contract clause may require a configuration check; a configuration check may produce an access record. These artefacts answer different questions and should not be collapsed into one “passed” field.
To connect supplier diligence to the governance framework, see the AI governance framework guide.
To set user rules for an approved service, see the AI acceptable use policy template.
Monitor material changes after onboarding
A vendor assessment is not a one-time event. After onboarding, monitor:
- Material changes in the service, model or provider.
- Security incidents or breaches.
- Changes in subprocessors.
- Changes in data handling or retention.
- Changes in the regulatory environment.
- Periodic reassessment at a locally defined interval.
Decide how those signals will reach the assessment owner. Contract notices, status reports, updated subprocessor lists, assurance expiry dates, incidents and internal user reports may all matter. Record who reviews a change, whether existing conditions still hold and whether the use-case assessment also needs to reopen.
The European Commission AI Act overview records phased application of the EU AI Act. Dates and amendments are time-sensitive. Do not say every obligation applies now or every AI use is high-risk.
Where a document checkpoint fits
A document checkpoint is one control within an approved workflow. It is not a substitute for vendor assessment. The vendor assessment covers the supplier, service, data flows, security, model, incidents and contract. A document checkpoint covers a specific document version before it enters the AI workflow.
.mdSiren is a document security workspace for AI, coming soon. Its Standard Scan will check the exact document version before AI use, route that version to Approved, Needs review or Quarantine, and keep Approved versions in a private Library for dependable reuse. That document decision remains limited to the reported checks and scan policy in force; it does not assess the supplier, provide complete due-diligence evidence, determine contractual suitability, prevent leakage or establish compliance.
To review .mdSiren's current security scope, see the security page.
To understand the planned document-check workflow, see the how it works page.
Frequently asked questions
What should an AI vendor risk assessment include?
A practical assessment will usually include supplier and service identity, intended and prohibited uses, data inputs and outputs, storage and retention, security architecture, model provenance and change management, subprocessors, incidents and continuity, legal and contract evidence, and unresolved gaps. The specific content depends on your organisation's context and the service being assessed.
Is it the same as a security questionnaire?
No. A security questionnaire is one input to a vendor risk assessment. The assessment is broader: it covers data flows, model controls, incidents, continuity, contract terms and unresolved gaps. A questionnaire may be a starting point, but it is not the complete assessment.
Who should assess an AI vendor?
Common contributors include procurement, security, privacy, legal and technical owners. The right group depends on your organisation's structure and the proposed service. Include the people who understand the intended use and those accountable for the relevant risks.
What evidence should a vendor provide?
Evidence relevant to each risk area may include current documentation, scoped test results, independent assurance reports and contractual commitments. Check the service, configuration, period and exclusions each item covers. The buyer should request evidence proportionate to the proposed use and record any gap rather than relying on a single hierarchy or certificate.
How often should an AI vendor be reassessed?
There is no universal interval. Reassessment should be triggered by: material change in the service or provider, security incident, regulatory change, or periodic review at a locally defined interval. The specific triggers are defined in your governance policy.
