The first thing I want to understand about a vendor is its place in the workflow. What information will it receive, what will it be allowed to do, and how difficult would it be to continue operating without it? Those answers give the review a shape. They help us ask for evidence that matters to the proposed use and make the remaining decision visible to the people who own the risk.
Source
The vendor is part of the operating boundary
Verizon’s 2026 DBIR release highlights increased third-party involvement in its breach dataset. That supports closer examination of dependencies, while leaving the individual procurement decision to evidence about the actual use.
I would organize the review around the ways this vendor could affect the firm: information held, authority granted, and work interrupted. The solution is a proportionate review with a continuing owner, rather than a questionnaire whose answers are detached from the deployment.
Proposal
Draw the proposed data path
Before sending a questionnaire, describe the use case. List the information the service receives, how it receives it, where results go, and the integrations or permissions required. Distinguish a limited manual upload from continuous access to a source system.
The same vendor can introduce very different exposure under different configurations. A trial using public documents and an integration reading an internal repository should have different review scopes.
Describe this figure
The same vendor under two configurations, side by side, each drawn as the four things the piece asks a review to list first. On the left, a trial using public documents: it receives public documents through a limited manual upload; its integrations or permissions and where its results go are left for the reader to ask; its review is scoped to the trial, an approval that covers this narrow use only. On the right, an integration reading an internal repository: it receives an internal repository through continuous access to a source system, highlighted as the configuration that changes the review; it works through an integration, and the reader asks whether it requests any tenant-wide or administrative consent; where its results go is left for the reader to ask; it needs a different review scope, because it brings broader access and a new data category.
Identify the business dependency as well. If the service becomes unavailable, can work continue elsewhere? Can the firm export its information in a form it can use? How difficult would replacing the workflow be?
NIST’s supply-chain guidance supports assessing supplier criticality and establishing requirements. The review brief should turn those ideas into questions about the actual purchase.
Match evidence to the questions
Assurance reports, technical documentation, contracts, and product tests each cover different ground. Record the scope and period of any assurance material. Check whether the relevant product, service, or operating arrangement falls within it. A document’s existence does not resolve every implementation question.
Ask how accounts are created and removed, how permissions are enforced, how important events can be investigated, and how the vendor handles incidents that affect customer information. Where processing involves other providers, understand the relevant subprocessors and the path for material changes.
For an AI-enabled service, examine the treatment of inputs, outputs, retained copies, and any use for model improvement. Use the specific contractual and product terms that apply to the proposed configuration; marketing language is an incomplete basis for a decision.
Test the part the firm will operate
The firm still owns its configuration and use. A capable product can be deployed with excessive access, unclear ownership, or an export path nobody has tried.
Use a bounded test with suitable data. Verify an ordinary user’s access, an administrator’s visibility, and the removal of access. Try the export that the exit plan depends on. Record limitations instead of translating every concern into a yes-or-no answer.
A hypothetical vendor might provide a good export of records while omitting attached files or relationship history. That limitation could be acceptable for one use and disqualifying for another. The decision should describe the consequence.
Record the operating decision
Finish with a named owner, the approved use and data scope, unresolved conditions, and the person accepting the decision. Include review triggers such as broader access, a new data category, a significant product change, or a material incident.
Assign responsibility for renewals, user changes, and exit. If the service becomes embedded in a critical workflow, its review should evolve with that dependency.
The aim is a decision another person can understand later: what the firm intended to do, what evidence it examined, which limitations it accepted, and when it will reconsider.
Proposal
What I would test next
For the most consequential new vendor, I would test access removal and export during the pilot. If either behaves differently from the review assumptions, make that a condition of acceptance and identify who can resolve it.