AI and SaaS Vendor Due Diligence: A CISO Playbook for Third-Party Cyber Risk

Executive summary

AI vendor risk management should approve a defined use case, not grant permanent trust to a supplier’s brand. Before signing or renewing, establish what the service can access, what its AI features can do, which downstream providers receive data, and how the business would operate without it.

The practical sequence is to tier suppliers by business consequence, test assurance evidence against the actual service, negotiate usable obligations, and document the decision. Then monitor the conditions that could invalidate that approval. A new model provider, expanded connector or changed training policy deserves attention even when the commercial contract remains unchanged.

This playbook focuses on those purchasing and renewal decisions, rather than enterprise-wide AI governance or the actions taken after a third-party breach.

Define what you are approving

The first question is not whether the vendor completed a questionnaire. It is whether the proposed service is acceptable for a specific business purpose under specific conditions.

Record the product, subscribed edition, enabled features, business owner, permitted data and integration permissions. Distinguish an assistant that drafts text from one that can change records, send messages or initiate transactions. A supplier-level assessment cannot substitute for understanding the deployment.

NIST CSF 2.0 explicitly addresses supplier criticality, contractual requirements, due diligence before formal relationships, ongoing monitoring and activities after an agreement ends. These are outcomes, not a prescribed purchasing workflow.[1] NIST’s C-SCRM program also treats supply-chain risk across the technology lifecycle.[4]

Use that guidance to shape your process, not to claim universal legal compliance. NIST and CISA guidance is not a universal legal requirement. Particular federal, sector, contractual or jurisdictional obligations may apply, and must be assessed separately.[4] [5]

Assign responsibilities before procurement starts negotiating. CISA’s program basics recommend a cross-functional team, understanding upstream suppliers and verifying third-party assurance.[5] The business owner explains the dependency and owns operational consequences. Security evaluates technical exposure, privacy assesses data processing, legal reviews obligations, and procurement manages commercial leverage and deadlines. Define who can accept residual risk under delegated authority. The CISO’s assessment should not become silent acceptance on everybody else’s behalf.

Tier suppliers by consequence, not contract value

A low-cost connector with broad mailbox access may deserve more scrutiny than an expensive service using public information. Score criticality using the sensitivity of data, privilege, operational dependency, consequences of incorrect outputs and practical replaceability. NIST calls for suppliers to be known and prioritized by criticality; its acquisition guidance connects criticality to requirements and acceptable risk.[1] [3]

The following is a proposed operating model, not a NIST classification or a regulatory category.

Apply an override when a single factor creates intolerable exposure. Do not average privileged access into a reassuring score. Record the reasoning, not just the label, and reassess when the use case changes.

Also examine concentration. Several apparently independent SaaS products may depend on the same model endpoint, cloud region or identity service. NIST’s acquisition guidance includes considering market concentration and supply-chain interdependencies during due diligence.[3]

Review AI features and downstream providers explicitly

Ask the supplier to map the path from your users and connectors to the application, model provider, storage and support systems. Request subprocessors, processing locations, purposes, retention periods and access arrangements. Do not assume every upstream dependency is legally a subprocessor; privacy and legal teams should establish the relevant roles.

For generative AI, separate inference from training and service improvement. Ask whether prompts, uploaded files, retrieved content, outputs, embeddings and feedback are retained or reused. Establish whether restrictions apply to the contracted edition, support access, abuse monitoring and downstream providers. An answer about the base application does not necessarily answer what happens in the AI feature.

NIST AI 600-1 identifies risks from third-party components and recommends extending procurement assessments to embedded generative AI, privacy, security, intellectual property and ongoing monitoring.[2]

Consider a hypothetical support platform adding AI ticket summaries. Approval for storing customer tickets does not automatically cover sending them to another provider. If the feature later gains permission to issue refunds, the assessment changes again. Data handling and execution authority are separate approval questions.

For action-capable features, ask whose identity executes each action, which permissions constrain it, what requires human approval and how execution can be stopped. Use a controlled pilot with synthetic or appropriately sanitized data to test access boundaries, logging and unintended actions. Agree pass criteria before the demonstration. Vendor benchmarks cannot establish fitness for your deployment; NIST notes that predeployment tests may not reflect real-world contexts.[2]

Treat a changed model provider, new subprocessor, expanded connector, new processing location or altered data-use terms as a material-change review trigger. Route the notice to a named owner and record the decision. A notice sitting unread in a procurement mailbox is not a control.

Read assurance evidence for scope and limitations

Questionnaires, SOC 2 reports and certifications are evidence inputs, not proof that a service is safe for your use case. NIST cautions against treating initial supply-chain due diligence as exhaustive and identifies attestation reports among tools that can support third-party transparency.[3] [2]

Start with the boundary. Does the evidence cover the legal entity, product, region and AI feature you intend to use? Read the reporting period, qualifications, exceptions, customer responsibilities and treatment of downstream providers. Ask what changed after the assessment. Do not let an attractive certificate distract from an excluded component that processes your sensitive data.

For a critical supplier, seek evidence that resolves concrete concerns. Examples include a recent independent penetration-test summary with remediation status, tenant-isolation testing, administrative access controls, vulnerability handling, recovery exercises and audit-log availability. Request enough detail to assess the concern without demanding unrestricted access to another organization’s sensitive findings.

Review your side too. Single sign-on, multifactor authentication, role configuration, connector scopes, token rotation and log export may depend on your edition or implementation. Ask the supplier to demonstrate the relevant configuration in a test tenant. Record customer-controlled settings as implementation prerequisites, not as assumed vendor capabilities.

Match claims to artifacts. If the supplier says customer data is excluded from training, reconcile that statement with the contract, feature settings and downstream arrangements. If deletion is promised, ask which copies are covered, which retention exceptions remain and how completion is evidenced.

When evidence is unavailable, record uncertainty explicitly. A controlled trial with no sensitive data may be acceptable where production use is not. Conditional approval should name the missing evidence, permitted scope, accountable owner and deadline. Repeating a questionnaire answer in the risk register does not resolve the gap.

Negotiate obligations the business can use

This section is a security negotiation checklist, not legal advice. Counsel should adapt terms to the service, applicable obligations and negotiating position. NIST recommends integrating supply-chain requirements into agreements, while its generative AI profile addresses contracts, usage rights, security requirements and third-party evaluation.[1] [2]

Translate important assumptions into obligations. Specify permitted processing and data use, including training restrictions where needed. Address subprocessor transparency, material-change notice, security evidence, vulnerability handling and cooperation. Agree notification triggers, timing, contacts and update expectations appropriate to your obligations. Avoid language that makes useful information contingent on a completed investigation.

For AI-enabled products, clarify ownership and permitted use of inputs and outputs, relevant licensing terms, and responsibility for changes to upstream models. Negotiate a practical review period for material changes and the ability to disable the feature, restrict processing or leave when the changed service exceeds approved risk. Obtain legal assessment of what is enforceable and commercially realistic.

FINRA’s 2025 third-party risk discussion includes initial and ongoing due diligence, fourth-party considerations, data protection in contracts, and asking whether vendors incorporate generative AI.[6] This is sector-specific precedent for FINRA member firms, not a rule imposed on every organization.[6]

Document unresolved clauses in business terms. If the supplier will not commit to an acceptable data-use restriction, options include excluding sensitive data, disabling AI or choosing another product. Where applicable requirements cannot be met, executive acceptance is not a substitute for compliance.

Make AI vendor risk management approvals conditional

Record one of four decisions: approve within scope, approve with conditions, defer pending evidence, or reject. Include the version or configuration reviewed, evidence dates, unresolved risks, controls, acceptance authority and next review trigger. Require proof that launch conditions are met before production access is enabled.

Build continuous monitoring around decisions, not dashboard volume. Track material feature and subprocessor notices, changes to terms, assurance expiry, relevant vulnerabilities, service disruptions and overdue remediation. Compare your tenant’s actual permissions and enabled AI features with the approved baseline. NIST recommends monitoring supplier risks throughout relationships and specifically extending assessment and alerting to third-party generative AI.[1] [2]

External security ratings and public signals may help prioritize questions, but should not be treated as direct measurements of your tenant or undisclosed AI processing. Investigate a signal against the affected service before changing its risk status.

Set escalation rules that someone can execute. A new sensitive-data destination should prompt privacy and security review before use. Expanded write access should reopen authorization testing. Repeated missed remediation commitments should trigger a renewal decision, not another automatic extension.

Maintain a renewal calendar that includes the cancellation notice deadline and realistic migration lead time. Start reassessment while alternatives remain viable. Renewal should confirm continued suitability against current use, not merely recycle the original approval.

Validate exit before dependency becomes expensive

Exit planning belongs in selection. CSF 2.0 includes provisions for activities after a partnership ends, and the generative AI profile recommends identifying third-party overreliance and fallbacks.[1] [2]

Ask how records, attachments, configurations and relevant logs can be exported, in which formats and at what cost. Test whether another system can actually use the export. For important AI workflows, identify how retrieval indexes, prompts, evaluations and integration logic can be rebuilt or transferred where applicable. A data download is not necessarily an operational replacement.

Agree the transition support, access-revocation steps and deletion evidence you will need. Clarify backup retention and exceptions rather than accepting an unqualified promise of immediate deletion. Obtain legal advice on contractual and applicable retention obligations.

Validate a fallback for critical workflows, including the option to disable AI while retaining the underlying service. Name the migration owner and record realistic staffing, cost and disruption estimates. If replacement is not practical, report that constraint as residual dependency risk before approval.

Give executives a decision pack, not a document archive

Most supplier approvals should remain within delegated authority. Escalate material exceptions, concentration and dependencies that exceed approved risk appetite. The board needs the business consequence and the choice, not every questionnaire response.

Prepare a short pack covering the intended benefit, criticality, data and execution authority, evidence confidence, unresolved gaps, alternatives, exit feasibility and recommended decision. Separate verified controls from supplier assertions and unknowns. Include the cost of delay or replacement using internal estimates with stated assumptions, not invented precision.

State the requested decision plainly: approve a constrained deployment, fund an alternative, or accept a defined residual exposure under valid authority. Attach an owner, expiry date and reconsideration trigger. For portfolio reporting, show critical suppliers with overdue conditions, material changes awaiting review and unvalidated exits. These measures support choices more directly than counting completed questionnaires.

A decision-oriented 90-day plan

Days 1 to 30: establish the approval boundary

Procurement and security should reconcile suppliers against business owners, integrations and upcoming renewals. Identify embedded AI features and tier the highest-consequence dependencies first. Agree delegated approval limits and material-change triggers with risk, privacy and legal. At day 30, decide which deployments can proceed within existing controls and which must remain constrained or deferred pending evidence.

Days 31 to 60: resolve the consequential gaps

Review critical suppliers using service-specific evidence and controlled configuration tests. Reconcile data-use claims with contracts and downstream arrangements. Assign remediation owners and deadlines. Procurement should prioritize negotiation before renewal leverage disappears. At day 60, choose mitigation, a restricted use case or an alternative for each material gap. Do not substitute an unexplained risk score for that choice.

Days 61 to 90: prove the process can hold

Test an export and fallback for a critical dependency. Verify that material-change notices reach decision owners and that expired conditions escalate. Check a sample of approved deployments against their actual permissions and enabled features. At day 90, give executives the unresolved decisions, funding needs and dependency constraints. Commit to review triggers that fit the supplier’s criticality, rather than imposing one cadence on every service.

Frequently asked questions

Is a SOC 2 report enough to approve an AI vendor?

No. Treat it as scoped evidence alongside the actual service, data flow, AI features and customer-controlled settings. Resolve relevant exclusions and exceptions. Missing feature-specific evidence may justify a constrained pilot, but should not be described as production assurance.

Must every SaaS AI update trigger a full reassessment?

No. Reopen the affected decisions when data destinations, processing purposes, permissions or business consequences change. A cosmetic interface update differs from a new model provider or autonomous action. Document why the change does or does not alter the approved risk.

Who accepts the remaining supplier risk?

The executive or business owner authorized by the organization’s risk policy should accept it, with specialist advice. Record the scope, rationale, conditions and expiry. Security provides an assessment; approval authority must be explicit. Applicable legal requirements cannot be waived through internal risk acceptance.

Conclusion

Good AI vendor risk management makes the approval boundary visible and keeps it current. Know the dependency, demand relevant evidence, negotiate usable obligations and prove that the business can leave. The standard is not a perfectly completed supplier file. It is a decision that names what is allowed, what remains uncertain, who owns the consequences and what change will force reconsideration.

Related resources

For the wider accountability model around these supplier decisions, use the AI Governance Hub. Record unresolved exposure, treatment and approval in the Cyber Risk Register Template, then translate material exceptions into the executive choices supported by the CISO Board Report Template. If a separate board briefing or advisory discussion is appropriate, the Executive Enquiry page provides the relevant contact route.

References

1. The NIST Cybersecurity Framework CSF 2.0
2. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1
3. Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, NIST SP 800-161 Rev. 1 Update 1
4. NIST Cybersecurity Supply Chain Risk Management Program
5. CISA Information and Communications Technology Supply Chain Risk Management
6. Third-Party Risk Landscape, 2025 FINRA Annual Regulatory Oversight Report