AI Vendor Due Diligence for ISO 27001 & ISO 42001
Integrating AI governance, ISO/IEC 27001, ISO/IEC 42001, and cybersecurity supply-chain controls
In this Article
- June 12, 2026
- CyberZoni
1. Why AI changes vendor due diligence
AI changes vendor risk because it introduces probabilistic system behavior, new data flows, new dependency chains, and faster product change. A vendor may not market itself as an AI company, but it may still use AI for customer support, analytics, document processing, fraud detection, security operations, software development, workflow automation, or generative content creation.
Traditional due diligence asks whether data is protected, access is controlled, vulnerabilities are managed, and incidents are handled. AI-aware due diligence asks additional questions: whether customer data is used for model training, which model providers are involved, whether outputs affect people or business decisions, whether humans can override outputs, and how the vendor prevents prompt injection, sensitive information disclosure, model poisoning, excessive agency, and other AI application weaknesses identified in technical security guidance such as the OWASP Top 10 for LLM and Generative AI Applications.
2. Standards and framework landscape
There is no single framework that fully solves AI-aware vendor onboarding. A practical program combines information-security management, AI management, AI risk management, cybersecurity supply-chain risk, cloud assurance, privacy, and emerging AI regulation. The standards below are particularly useful for building questionnaire content, evidence requirements, risk-tiering, and approval criteria.
Reference | Vendor onboarding relevance | Typical evidence or questions |
Information-security management system requirements; useful baseline for vendor security governance, risk management, supplier controls, incident response, access control, and resilience. | Certificate scope, Statement of Applicability summary, risk treatment summary, supplier controls, incident response procedure, access-control evidence. | |
Artificial Intelligence Management System requirements; useful for assessing whether the vendor governs AI responsibly across the AI lifecycle. | AI policy, AI risk assessment, AI inventory, roles and accountability, lifecycle controls, AI governance meeting records, internal audit results. | |
Guidance on managing risk related to AI for organizations that develop, deploy, produce, or use AI-enabled products, systems, and services. | AI risk methodology, risk register, mitigation plan, residual risk acceptance, monitoring and review process. | |
AI system impact assessment guidance; relevant where vendor AI may affect individuals, groups, society, fairness, safety, or human-centred outcomes. | AI impact assessment, stakeholder analysis, documented impacts, mitigation actions, lifecycle reassessment evidence. | |
Voluntary framework for incorporating trustworthiness considerations into AI design, development, use, and evaluation. | Govern/Map/Measure/Manage evidence, AI RMF crosswalk, AI risk metrics, red-team or evaluation results. | |
Cybersecurity supply-chain risk management guidance for identifying, assessing, and mitigating supply-chain cybersecurity risk. | Supplier-risk program, subcontractor inventory, acquisition controls, supply-chain risk assessment, software/security assurance evidence. | |
Useful cybersecurity control references for governance, identity, logging, incident response, system acquisition, privacy, and supply-chain controls. | Control mappings, security architecture, vulnerability management, logging/monitoring, contingency planning, secure SDLC evidence. | |
Technical security reference for generative AI and LLM applications, including prompt injection, sensitive information disclosure, supply chain, data/model poisoning, excessive agency, and vector weaknesses. | Threat model, prompt-injection mitigations, output validation, tool/agent permission design, vector-store security, abuse monitoring. | |
Risk-based AI regulatory framework for developers and deployers in the EU; includes obligations for high-risk AI systems and general-purpose AI models. | AI Act applicability assessment, role mapping, high-risk classification, technical documentation, human oversight, incident reporting, transparency materials. | |
SOC 2 and CSA CCM/CAIQ | Useful assurance references for outsourced service providers and cloud/SaaS vendors. SOC reports help assess outsourcing risk; CSA CCM/CAIQ supports cloud control assessment. | SOC 2 Type II report, bridge letter, CSA CAIQ responses, shared-responsibility model, cloud control evidence. |
3. AI-aware vendor due diligence lifecycle
AI-aware due diligence should follow a lifecycle model. The goal is to identify the vendor risk profile before contracting or integration, then maintain visibility as vendor services, AI features, model providers, subprocessors, and data practices change.
Lifecycle step | Practical action |
1. Pre-screen | Determine service purpose, business owner, criticality, data types, user population, integration points, geography, and whether the vendor uses or provides AI. |
2. AI exposure classification | Classify AI as none, internal vendor use, embedded AI feature, customer-facing AI, high-impact AI, or autonomous/agentic AI. |
3. Security and privacy review | Review ISO 27001/SOC 2 evidence, privacy documentation, access controls, encryption, logging, incident response, vulnerability management, cloud controls, and subcontractors. |
4. AI governance review | Request AI policy, AI inventory, model/provider list, data-use description, AI risk assessment, AI impact assessment, human oversight controls, output monitoring, and AI incident process. |
5. Evidence validation | Evaluate whether evidence is current, relevant to the service in scope, independently assured where required, and consistent with questionnaire answers. |
6. Risk scoring and approval | Score inherent risk, residual control risk, evidence quality, open remediation, AI exposure, and contractual safeguards. Apply approval gates based on risk tier. |
7. Contracting and onboarding | Include security, privacy, AI-use, subcontractor, audit, incident, change-notification, and exit clauses before production access or data transfer. |
8. Monitoring and exit | Monitor AI feature changes, incidents, new subprocessors, regulatory changes, assurance reports, remediation status, and data deletion/return at offboarding. |
4. Core due diligence domains, questions, and evidence
The following domains can be used to extend a traditional vendor security questionnaire. Not every vendor needs every question. Apply the full set to vendors that process sensitive data, support critical operations, provide AI functionality, use customer-facing AI, or rely on third-party AI providers.
Domain | Core due diligence question | Expected evidence |
AI use and inventory | Does the vendor use AI in the service or supporting operations? Which AI systems, models, providers, agents, or plug-ins are in scope? | AI inventory, model/provider register, system architecture, product feature description. |
Data use and training | Is customer data, prompts, files, telemetry, or support data used for training, fine-tuning, model improvement, evaluation, or analytics? | Data-flow map, data processing addendum, opt-out terms, retention schedule, training-data policy. |
Security baseline | Are access controls, encryption, logging, vulnerability management, secure development, and incident response implemented for the service? | ISO 27001, SOC 2, penetration test summary, vulnerability process, access control screenshots, logging samples. |
AI governance | Is there assigned accountability for AI risk? Are AI use cases approved and periodically reviewed? | AI policy, governance charter, AI risk committee records, roles and responsibilities, internal audit results. |
Model risk and output controls | How are AI outputs evaluated, monitored, constrained, and escalated when inaccurate, harmful, biased, or unsafe? | Evaluation results, monitoring metrics, human oversight procedure, escalation process, output testing evidence. |
LLM and generative AI security | How does the vendor prevent prompt injection, sensitive information disclosure, excessive agency, improper output handling, model/data poisoning, and vector-store exposure? | LLM threat model, red-team results, prompt security controls, output validation, agent/tool permission design. |
Subprocessors and AI supply chain | Which subprocessors, cloud services, foundation model providers, data processors, data labelers, and AI APIs support the service? | Subprocessor list, data-flow map, contracts, third-party assurance, change notification process. |
Privacy and legal | Does the vendor process personal data, regulated data, biometric data, employment data, or data subject to sector obligations? | DPA, DPIA or privacy assessment, transfer mechanism, retention/deletion procedures, regulatory mapping. |
Regulatory and impact assessment | Could the AI use case be high-impact, high-risk, safety-related, employment-related, financial, biometric, education-related, or otherwise regulated? | AI Act applicability assessment, AI impact assessment, legal review, human oversight and transparency materials. |
Operational resilience | Can the vendor maintain service availability, recover from incidents, and continue operations if the AI provider or model service fails? | BCP/DR plans, RTO/RPO, incident tests, dependency mapping, fallback procedures. |
Change management | Will the vendor notify customers before material changes to AI functionality, model providers, data usage, subprocessors, or security posture? | Change policy, release notes, contract notification clause, governance records. |
Exit and data deletion | Can data, prompts, embeddings, logs, model-derived artifacts, and backups be returned or deleted when the relationship ends? | Deletion certificate, data-return procedure, backup deletion schedule, offboarding evidence. |
5. Risk scoring and approval model
AI-aware scoring should not replace existing vendor risk scoring. Instead, it should add AI exposure, model/data risk, evidence quality, and AI governance maturity to the standard inherent and residual risk model. The scoring model should also recognize that positive questionnaire answers are not enough if the evidence is weak, stale, incomplete, or outside the scope of the actual service being onboarded.
Scoring dimensions
Dimension | What to evaluate |
Inherent business risk | Criticality of the service, business dependency, availability requirements, user population, and financial/operational impact. |
Data risk | Sensitivity, volume, purpose, jurisdiction, regulatory classification, personal data, confidential data, and retention. |
AI exposure | Whether the vendor uses AI internally, embeds AI features, exposes AI to users, makes recommendations, automates actions, or supports high-impact decisions. |
Security control maturity | Security governance, IAM, encryption, logging, secure SDLC, vulnerability management, incident response, resilience, and cloud controls. |
AI governance maturity | AI policy, AI risk assessment, impact assessment, model/provider inventory, human oversight, transparency, output monitoring, and accountability. |
Supply-chain dependency | Subprocessors, foundation model providers, cloud dependencies, external data sources, software components, plug-ins, and service concentration risk. |
Evidence quality | Whether the vendor provides independent, current, service-specific, and verifiable evidence rather than unsupported self-attestation. |
Contractual safeguards | Data-use restrictions, AI training limitations, audit rights, notification obligations, incident requirements, deletion obligations, and exit rights. |
Risk tier | Approval treatment |
Low | Routine business owner approval. Baseline contractual security and privacy terms. Review at renewal or every 24-36 months. |
Medium | Security or privacy review required. Evidence requested for key controls. Remediation tracked. Review every 12-24 months. |
High | Security, privacy, legal, and business owner approval. Enhanced AI/data clauses. Open high-risk issues require treatment plan. Review every 6-12 months. |
Critical | Senior risk owner or risk committee approval. Formal risk acceptance for exceptions. Contractual restrictions, enhanced monitoring, exit planning, and recurring assurance required. |
6. Key challenges caused by the surge of AI
- Shadow AI and embedded features: AI can appear inside ordinary tools without a separate procurement event. Vendors may activate AI assistants, summarization, analytics, or support automations after the initial onboarding review.
- Opaque data usage: Customers may not understand whether prompts, attachments, logs, telemetry, tickets, or support transcripts are used for training, evaluation, fine-tuning, or product improvement.
- AI supply-chain opacity: A primary vendor may rely on cloud AI services, external foundation models, plug-ins, vector databases, data labeling providers, or outsourced support operations.
- Model and output uncertainty: AI outputs can be inaccurate, biased, misleading, inconsistent, or manipulated. For decision-support systems, this creates governance, legal, and operational exposure.
- LLM application security risks: Prompt injection, sensitive information disclosure, excessive agency, improper output handling, data/model poisoning, vector weaknesses, and AI supply-chain vulnerabilities need explicit review.
- Rapid feature change: AI product features and model providers can change faster than annual vendor review cycles. Contracts should require notice for material AI or data-use changes.
- Evidence maturity gap: Many vendors can describe responsible AI principles but cannot yet provide robust evidence such as AI risk assessments, model/provider inventories, impact assessments, red-team results, or operational monitoring records.
- Regulatory uncertainty and jurisdiction: AI obligations vary by use case, geography, sector, and role. The EU AI Act uses a risk-based approach and imposes strict obligations for high-risk AI systems.
7. Cybersecurity considerations for vendor onboarding
The cybersecurity review for AI-enabled vendors should cover both classic security controls and AI-specific technical controls. NIST SP 800-53 provides a broad catalog of security and privacy controls, including risk assessment, incident response, system and services acquisition, privacy, and supply-chain risk management families. NIST SP 800-161 is especially relevant for technology vendors because it focuses on supply-chain cybersecurity risk across products and services.
Control area | Vendor onboarding focus |
Identity and access | Least privilege, MFA, privileged access management, service-account controls, API token controls, access reviews, customer tenant isolation. |
Secure development | Secure SDLC, code review, dependency scanning, secrets detection, AI-assisted coding controls, vulnerability remediation SLAs. |
AI application security | Prompt-injection defenses, input/output validation, retrieval restrictions, agent permission limits, safe tool invocation, rate limiting, abuse monitoring. |
Data protection | Encryption, DLP, prompt/log retention limits, data minimization, tenant segregation, secure deletion, backup controls, vector-store protection. |
Logging and traceability | Audit logs for administrative actions, data access, prompt activity where appropriate, model changes, output overrides, and incident investigation. |
Model and AI provider security | Provider inventory, model versioning, change control, evaluation records, red-team testing, provider assurance, outage/fallback plan. |
Incident response | Incident notification, AI-specific incident classification, containment for data leakage or unsafe output, forensic log availability, customer communications. |
Supply chain | Subprocessor transparency, model provider due diligence, software component management, cloud dependencies, subcontractor flow-down clauses. |
Operational resilience | BCP/DR, dependency outage handling, recovery testing, RTO/RPO, fallback to non-AI processes for critical workflows. |
8. Contracting and operating controls
Due diligence findings should flow directly into contract requirements and operational controls. AI-specific obligations should be included before production access is granted or sensitive data is shared. This is especially important for high-risk vendors, SaaS platforms, AI-enabled processors, and vendors using third-party model providers.
Contract or operating control | Example requirement |
AI usage disclosure | Vendor must disclose AI functionality, AI providers, model types, subprocessors, and material changes to AI features or data usage. |
Training restriction | Customer data, prompts, files, telemetry, and outputs may not be used to train, fine-tune, or improve AI models unless explicitly authorized in writing. |
Data protection | Data must be processed only for agreed purposes; retention, deletion, access, encryption, transfer, and localization requirements must be defined. |
Human oversight | Where AI outputs affect decisions, vendor must define human oversight, override, escalation, review, and accountability controls. |
Security controls | Vendor must maintain security controls, vulnerability management, incident response, logging, and secure development practices appropriate to the risk tier. |
Subprocessor control | Vendor must provide a subprocessor list, flow down security/AI/privacy obligations, and provide notice or approval rights for material changes. |
AI incident notification | Vendor must notify customers of security incidents, data leakage, model compromise, unsafe AI behavior, unauthorized AI training, or material AI failures. |
Audit and evidence rights | Customer may request reasonable evidence such as assurance reports, certifications, AI risk assessments, technical documentation, and remediation status. |
Exit and deletion | Vendor must support data return/deletion, access revocation, deletion of prompts/logs/embeddings where applicable, and confirmation of completion. |
9. Procurement Supplier Risk Assessment Template
The Procurement Supplier Risk Assessment Template can be used as the practical operating layer for the AI-aware vendor due diligence model described in this document. The product is an Excel-based vendor selection tool with questionnaire assessment, vendor management, and ISO 27001 alignment.
Product page: Procurement Supplier Risk Assessment Template on CyberZoni.com
For organizations updating supplier onboarding for AI, the template should not only collect vendor answers. It should also help structure intake, classify vendor risk, request evidence, calculate scoring, document remediation, and route the supplier to the right approval path. This makes the template useful for procurement teams, security teams, privacy/legal reviewers, and business owners who need a common view of vendor risk.
Related Templates & Documents
Procurement Supplier Risk Assessment Template
- Full questionnaire: detailed Excel workbook for complete vendor risk assessment.
- Condensed questionnaire: quick Excel tool for fast vendor risk