AI Vendor Risk Assessment (2026): Framework, Scorecard & GDPR/EU AI Act Guide

Written and reviewed by Irfan Ullah, Founder of TrusteraAI and creator of the TrusteraAI AI Risk Assessment Framework™. Last updated: August 2026 · Regulatory review: August 2026.

Sources & Methodology: Regulatory requirements are based on the applicable EU legal text (EUR-Lex) and official guidance. Framework references are mapped to NIST and ISO publications. Statistics are attributed to their original publishers, linked below.

Most vendor risk reviews were built for software, not for AI. A standard security questionnaire asks whether a vendor encrypts data at rest — it doesn’t ask whether your prompts become training data, whether the model’s outputs can be traced back to a specific version, or what happens to your data when the vendor’s next model update quietly changes how the tool behaves. An AI vendor is a different risk category, and treating it like an ordinary SaaS subscription is how organizations end up with unreviewed AI tools processing customer data.

Quick Answer: An AI vendor risk assessment is a structured evaluation of a third-party AI tool or model provider across security, compliance, data handling, model provenance, and operational resilience — producing a documented, severity-weighted score and a set of hard disqualifying criteria (gates) that determine whether the vendor is approved.

Gartner’s survey of 302 cybersecurity leaders found that 69% of organizations suspect or have direct evidence of employees using unsanctioned generative AI tools. Separately, IBM’s 2025 Cost of a Data Breach Report found that breaches involving a high level of shadow AI cost organizations $670,000 more on average than standard breaches. A structured, repeatable vendor assessment — applied before a contract is signed, not after an incident — is how you keep AI tools from entering your stack unreviewed in the first place.

---

🎯 Start Here

• Need the scorecard now? Jump to The TrusteraAI AI Vendor Risk Assessment Framework™
• Reviewing a vendor’s GDPR posture specifically? Jump to Data Handling & GDPR
• Already have a vendor flagged as risky? See Connecting Vendor Assessment to Your Governance Chain

---

---

What Is an AI Vendor Risk Assessment?

Quick Answer: An AI vendor risk assessment is a structured, repeatable evaluation of a third-party AI tool or model provider — covering security, compliance, data handling, model provenance, and operational resilience — that produces a documented score and a clear approve/reject decision, applied before signing and re-run at renewal.

This is distinct from a general vendor security review in one important way: AI vendors introduce risk categories that don’t exist for ordinary SaaS tools. Your data isn’t just processed — it may become training data. The tool’s behavior isn’t fixed at the version you tested — it can shift silently with a model update. And the underlying model itself carries provenance questions (what data trained it, how it was evaluated, what its known failure modes are) that a typical security questionnaire never asks.

Why a Generic Vendor Questionnaire Isn’t Enough

A standard SaaS security review typically checks: SOC 2 status, encryption in transit and at rest, SSO/MFA support, and an SLA. All of that still matters for AI vendors — but it stops well short of the risks that are specific to AI:

Standard SaaS Review Covers	AI Vendor Risk Assessment Also Needs
Encryption, access control, SOC 2	All of the above, plus AI-specific security controls
Data residency and retention	Whether data is used for model training, and whether that’s opt-out or opt-in
Uptime SLA	Model change management — notice period before a model update changes behavior
General compliance certificates	AI-specific certification (ISO/IEC 42001) and EU AI Act role/documentation
Vendor financial stability	Model provenance — training data composition, evaluation results, known limitations
—	Capability deprecation policy — what happens when the vendor retires the feature you built on

Certificates like SOC 2 and ISO 27001 are a floor, not a ceiling — they confirm the vendor has a security program, not that the program accounts for AI-specific failure modes. Treat them as one gate among several, not the whole assessment.

The TrusteraAI AI Vendor Risk Assessment Framework™

Quick Answer: The TrusteraAI AI Vendor Risk Assessment Framework™ scores AI vendors across five domains — security posture, compliance, data handling, model provenance, and operational resilience — using severity-weighted points and a set of hard go/no-go gates that disqualify a vendor regardless of total score.

Domain	Focus	Primary Owner
1. Security Posture	Authentication, encryption, secrets, audit logging, incident response	Security Engineering
2. Compliance & Certifications	SOC 2, ISO 27001, ISO 42001, sector/regional regimes	Compliance / Legal
3. Data Handling & GDPR	Training data use, retention, deletion, cross-border transfer, DPA, subprocessor chain	Privacy Officer / DPO
4. Model Provenance	Training data composition, evaluation results, model cards, known limitations	AI Governance Lead
5. Operational Resilience	SLA, change management, deprecation policy, financial stability	Procurement

This structure is deliberately consistent with the domains in our AI Risk Assessment Checklist and Enterprise AI Security Checklist — a vendor scored here plugs directly into the risk-scoring methodology you’re already using elsewhere in your governance program, rather than requiring a second, disconnected scoring system.

Domain 1: Security Posture

Control	What to Verify	Evidence to Request
Authentication & identity	SSO (SAML/OIDC), mandatory MFA on admin accounts, SCIM provisioning	Identity provider integration docs
Encryption	TLS 1.2+ in transit, AES-256 at rest, customer-managed keys for regulated workloads	Encryption architecture summary
Secrets management	Production secrets in a managed vault, documented rotation cadence	Secrets management policy
Audit logging	Authentication, config-change, and data-access logs, exportable in a standard format (JSON, CEF, syslog)	Sample log export
Incident response	Documented plan, tested via tabletop, named security contact, customer notification commitment	IR plan summary or attestation

The export test: many vendors offer audit logs inside their own console with no export path — useful to their support team, not to your security operations. If logs can’t be exported to your own SIEM in a standard format, treat that as a real gap, not a minor one.

Domain 2: Compliance & Certifications

Certification	What “Strong” Looks Like	What “Weak” Looks Like
SOC 2 Type II	Current report (within 12 months), Security + other relevant Trust Services Criteria in scope, shareable under NDA	Type I only, or report older than 12 months
ISO/IEC 27001	Current certification, cloud (27017) and PII (27018) extensions where relevant	Lapsed or pending certification
ISO/IEC 42001	Certified, with the AI product explicitly in scope	No AI-specific certification despite AI being the core product
Sector/regional regimes	Documented regime mapping — GDPR, and sector rules (HIPAA, PCI-DSS) if relevant	No documented regional or sector mapping
Sub-processor register	Public list, change notification within a defined window, customer right to object	Sub-processors undisclosed or changed without notice

ISO/IEC 42001 — the AI management system standard — is the certification most worth weighting heavily here. It’s the first widely recognized certification addressing AI-specific governance (training-data management, model lifecycle, AI incident response) rather than treating AI as generic IT infrastructure. A vendor holding ISO 42001 within their AI product’s scope is signaling that AI governance is a distinct discipline for them, not an afterthought.

Domain 3: Data Handling & GDPR

This is the domain where AI vendor risk diverges most sharply from ordinary SaaS vendor risk, and where a Spain- or EU-facing SaaS company needs the most rigor.

Control	What to Verify
Training data use	Never assume customer inputs are excluded from model training or improvement. Verify the vendor’s contractual terms and product-specific data-use policy for prompts, files, outputs, feedback, and fine-tuning data — enumerated per category, not a single blanket statement
Data Processing Agreement	A GDPR Article 28 DPA is in place, naming the processing purpose, data categories, and sub-processors
Retention policy	Named retention period per data category (prompts, outputs, logs, fine-tuning data), with a documented deletion process
Deletion verifiability	Deletion completed within a defined SLA, verifiable via signed attestation — not just a stated policy. This provides evidence the organization can use to operationalize applicable Article 17 erasure obligations when vendor-processed data is subject to erasure — it supports, but doesn’t by itself satisfy, that obligation
Cross-border transfer	Documented transfer mechanism (SCCs, adequacy decision) for any processing outside the EEA
Cross-tenant isolation	Your prompts and outputs cannot surface to other customers — isolation model documented and tested
Subprocessor → model provider chain	Identify who actually processes your prompts: is the AI SaaS vendor passing data to an underlying model provider (OpenAI, Anthropic, Google, etc.)? Is that provider disclosed as a subprocessor? Can the vendor change the underlying model provider without notice, and can you object?

Why this control matters: default data-use terms vary widely across vendors, and assuming exclusion without verification is a common, avoidable gap. This is one of the most consequential AI vendor contract terms to verify, and one of the hardest to renegotiate after signing.

A vendor scoring poorly on this domain — particularly one processing personal data of your Spain- or EU-based customers with no clear lawful basis or deletion process — should feed directly into a DPIA screening using the same Article 35 threshold logic from our Risk Assessment Checklist. For the regulatory foundation this domain sits within, see our Spain GDPR Checklist for SaaS and AEPD Inspection Guide.

Domain 4: Model Provenance

What to ask depends on where the vendor sits in the AI supply chain:

If the vendor is a foundation/model provider (e.g., you’re buying API access to a model directly): ask for training-data provenance, licensing status, model card, evaluation methodology, and safety evaluations — the full table below.

If the vendor is an AI-powered SaaS application built on someone else’s model: ask which underlying model and provider they use, whether your data reaches that underlying provider, their fine-tuning practices, how they notify you of model changes, and what documentation they can pass through from their own model provider. Full training-data disclosure usually isn’t available to them either — don’t penalize a SaaS vendor for not having information their own provider hasn’t given them.

Signal	What to Ask For
Training data composition	A public or under-NDA summary of training data sources, licensing status, and cutoff date
Evaluation results	Published benchmark results and methodology, including safety-relevant evals, not just capability benchmarks
Model card	A current model card per release, naming intended use, known limitations, and documented failure modes
Fine-tuning isolation	Confirmation that any fine-tuning on your data is isolated from the base model and from other customers
Version change notice	Advance notice before a model version change that could alter output behavior

The model card test: ask for the model card of the exact version you’ll be deployed against. A current, detailed card that names real limitations is one of the strongest signals of a mature AI vendor. A vendor who can’t produce one, or produces a card with no limitations listed, is telling you something important about how seriously they treat model governance.

Domain 5: Operational Resilience

Control	What “Strong” Looks Like
Service SLA	Named uptime commitment, real service-credit formula (not a token 5%), exclusions clearly stated
Incident response SLA	Defined acknowledgment and resolution targets, public status page with retained history
Change management	Advance notice (30+ days) before material changes; versioned APIs where applicable
Deprecation policy	Written commitment — minimum notice period, migration support — before a capability you depend on is retired
Financial stability	Funding/runway transparency where relevant; no single customer representing an outsized share of revenue

Deprecation policy is the most overlooked control in this domain. Unlike traditional SaaS, an AI vendor may retire a specific capability mid-contract because the underlying model was deprecated or the vendor’s roadmap shifted — while your contract, and your integration, keep running. A written deprecation policy with a real notice period is the protection that matters most once you’re already dependent on the tool.

Scoring, Severity Weighting & Go/No-Go Gates

Quick Answer: Score each control on a 1-5 scale, weight by severity tier, and apply hard disqualifying gates independently of the total score — a single Critical-tier failure disqualifies a vendor regardless of how well it scores elsewhere.

Severity Tier	Example Controls	Weight
Critical	Authentication, encryption, cross-tenant isolation, training data use	4 points each
High	Audit logging, incident response, ISO 42001, deletion verifiability, deprecation policy	2.5 points each
Medium	Secrets management, sub-processor register, change-management notice	1.5 points each
Informational	Model provenance disclosures, evaluation transparency, financial-stability signals	0.7 points each

The formula:
Weighted control score = (control score ÷ 5) × severity weight
Overall score (out of 100) = sum of weighted control scores ÷ maximum possible weighted score × 100

Calculate the maximum possible weighted score using only the controls actually applicable to that vendor — for example, if Domain 4’s training-data-composition control is marked N/A for a SaaS vendor built on a third-party model (per the vendor-type distinction above), exclude it from both the vendor’s score and the maximum possible score for that assessment. Comparing a foundation-model provider and a SaaS application against the same denominator would understate the SaaS vendor’s score for information it was never in a position to provide.

These weighting coefficients (4 / 2.5 / 1.5 / 0.7) are TrusteraAI’s recommended methodology — neither NIST, ISO/IEC 42001, nor GDPR prescribes specific numerical weights. Adjust them to reflect your organization’s own risk priorities if needed; what matters is applying them consistently across every vendor you assess.

Go/No-Go Gates — apply these independently of the weighted total:

• Any Critical-tier control scoring at the floor (1/5) is an automatic disqualifier
• No enumerated, verified position on training data use is an automatic disqualifier for any vendor touching customer or employee personal data
• No documented deletion process is an automatic disqualifier for any vendor processing EU/Spain personal data

As with the numerical weights above, these gates are TrusteraAI’s recommended policy thresholds — not GDPR, NIST, or ISO/IEC 42001 requirements. Adopt, adjust, or add to them based on your own organization’s risk tolerance; the discipline that matters is applying whatever gates you choose consistently and independently of the total score.

Set your shortlist threshold (a common baseline is 75% of the weighted total) before scoring begins — deciding the bar after seeing the results turns the assessment into a rationalization exercise rather than a decision tool. Re-run the full assessment annually, and immediately after any vendor acquisition, model version change, or reported security incident.

How This Assessment Supports GDPR, EU AI Act & ISO 42001

Framework	What This Assessment Supports
GDPR Article 28	Confirms a compliant Data Processing Agreement is in place before the vendor processes personal data as a processor
GDPR Article 17	Domain 3’s deletion-verifiability check supports your ability to operationalize customer erasure requests involving vendor-processed data
EU AI Act — Annex IV / Article 73	Domain 2 and 4 checks (technical documentation, model cards) provide supporting evidence toward documentation obligations that may apply to certain providers and deployers — they don’t themselves determine or satisfy your organization’s EU AI Act obligations, which depend on your specific role and the system’s classification. See our AI Incident Response Plan for how vendor-caused incidents connect to Article 73 reporting once applicable
ISO/IEC 42001	Domain 2’s certification check and Domain 4’s provenance checks support the supplier-control requirements under an AI management system

This assessment is a documented input toward these frameworks — it doesn’t itself constitute regulatory compliance. Confirm your organization’s specific obligations with qualified counsel.

Connecting Vendor Assessment to Your Governance Chain

A vendor assessment shouldn’t be a standalone exercise. It’s one link in a chain:

AI Inventory (does this vendor’s tool already exist in our stack?) → Vendor Risk Assessment (is it safe to approve?) → AI Risk Assessment (what’s the ongoing risk once approved?) → AI Incident Response Plan (what happens if this vendor has an incident?)

Before assessing a new vendor, check whether it’s already logged in your AI Inventory — shadow AI often means a vendor is already in use without ever going through this process. Once approved, a vendor scoring Medium risk or above should get a full entry in your AI Risk Assessment Checklist, and the vendor-compromise category in your AI Incident Response Plan already covers what to do if this specific vendor is compromised — the two are designed to work together, not be built separately.

The AI Vendor Risk Assessment Template

Vendor Name:
Assessment Date:
Assessed By:
Vendor Type: [Foundation/Model Provider / AI-Powered SaaS Application]
Contract Status: [Prospective / Existing - Renewal / Existing - Expansion]

DOMAIN 1 — SECURITY POSTURE
Authentication (SSO/MFA):            Score: __ / 5
Encryption:                           Score: __ / 5
Secrets Management:                   Score: __ / 5
Audit Logging (exportable):           Score: __ / 5
Incident Response Program:            Score: __ / 5

DOMAIN 2 — COMPLIANCE & CERTIFICATIONS
SOC 2 Type II:                        Score: __ / 5
ISO/IEC 27001:                        Score: __ / 5
ISO/IEC 42001:                        Score: __ / 5
Sub-processor Register:               Score: __ / 5

DOMAIN 3 — DATA HANDLING & GDPR
Training Data Use (verified):         Score: __ / 5   [GATE]
DPA in Place (GDPR Art. 28):          Score: __ / 5
Deletion Verifiable (GDPR Art. 17):   Score: __ / 5   [GATE]
Cross-Border Transfer Mechanism:      Score: __ / 5
Cross-Tenant Isolation:               Score: __ / 5   [GATE]
Subprocessor → Model Provider Chain:  Score: __ / 5

DOMAIN 4 — MODEL PROVENANCE
Training Data Disclosure (if applicable, mark N/A if not): Score: __ / 5
Model Card / Documentation Provided:  Score: __ / 5
Evaluation Results Published:         Score: __ / 5

DOMAIN 5 — OPERATIONAL RESILIENCE
Service SLA:                          Score: __ / 5
Deprecation Policy:                   Score: __ / 5
Financial Stability:                  Score: __ / 5

Weighted Total Score: ___ / 100 (calculated against applicable controls only)
Gates Failed (Y/N):
Decision: [Approve / Reject / Conditional - Remediation Required]
Next Review Date:

Want this as a fillable spreadsheet with automatic severity weighting? Explore our AI Governance Resource Library.

Enterprise Scenario: Assessing an AI Support Tool Vendor

Scenario: A US-based SaaS company, serving customers across Spain and the broader EU, evaluates an AI-powered customer support tool that would process customer names, emails, and support ticket content.

Domain	Finding	Score	Gate Status
Security Posture	SSO/MFA supported, exportable audit logs	4/5	Pass
Compliance	SOC 2 Type II current, no ISO 42001	3/5	Pass
Data Handling & GDPR	No verified, enumerated position on training data use in the standard contract	2/5	Fail — Gate triggered
Model Provenance	Underlying model and provider disclosed, documentation passed through	4/5	Pass
Operational Resilience	99.9% SLA, no written deprecation policy	3/5	Pass

Outcome: Despite a reasonable overall weighted score, the unverified training data position triggered an automatic disqualifying gate. The company returned to the vendor requesting an enumerated data-use addendum before proceeding — the vendor agreed, the clause was added to the DPA, and the assessment was re-run and passed. Without the gate, this vendor would have been approved on total score alone despite a real, consequential gap.

Framework Mapping

Standard	Domain(s) It Aligns With
NIST AI Risk Management Framework	Vendor assessment supports the Map function — identifying third-party AI components and their context, as an input to Measure and Manage
NIST Cybersecurity Framework	Domain 1 (Security Posture) aligns with Identify and Protect functions
ISO/IEC 42001	Domains 2 and 4 support supplier-control requirements within an AI management system
GDPR	Domain 3 supports Article 28 (processor agreements) and Article 17 (erasure) obligations

Common Mistakes to Avoid

• Treating an AI vendor like a standard SaaS vendor and skipping model-specific questions entirely
• Assuming customer data is excluded from training without verifying the vendor’s actual contractual terms
• Scoring on total weighted score alone without hard gates — a strong overall score can still hide a disqualifying gap
• Comparing a foundation-model provider and a SaaS application against the same denominator without excluding non-applicable controls
• Demanding full training-data provenance from a SaaS vendor built on a third-party model, when that information isn’t available to them either
• Never re-running the assessment after a vendor’s model version changes or after an acquisition
• Approving a vendor without checking whether it’s already logged in your AI inventory as shadow AI
• No written deprecation policy on file before a capability the business depends on is retired without warning

Best Practices

• Set your scoring threshold and gate list before you start scoring, not after
• Distinguish what to ask a foundation model provider versus an AI-powered SaaS application built on one
• Calculate the maximum possible score using only the controls applicable to that specific vendor
• Request the model card or equivalent documentation for the exact version you’ll be deployed against
• Treat deletion verifiability, not just a stated retention policy, as the practical control that supports GDPR Article 17 obligations
• Trace the subprocessor chain to the actual underlying model provider, not just the vendor you’re contracting with
• Re-run the full assessment annually, and immediately after a vendor acquisition, model change, or reported incident
• Feed every assessed vendor into your AI inventory and risk register, closing the governance loop

Key Takeaways

✅ AI vendors carry risk categories a standard SaaS security review doesn’t cover — training data use, model provenance, and deprecation risk chief among them.

✅ A severity-weighted score alone isn’t enough — hard go/no-go gates catch disqualifying gaps that a strong total score can mask, and both the weights and the gates are TrusteraAI policy recommendations, not regulatory mandates.

✅ Never assume customer data is excluded from model training — verify the vendor’s actual terms, and trace the subprocessor chain to the real underlying model provider.

✅ This assessment connects directly to your AI Inventory, AI Risk Assessment Checklist, and AI Incident Response Plan — it isn’t a standalone exercise.

Frequently Asked Questions