Classical vendor diligence asks a question about a company. AI diligence asked that way returns an answer that is true of the company and false of your deployment, because the same product on a different plan tier can carry different training-data, retention and residency terms — and because the thing you assessed changes underneath you between annual cycles more often than any other supplier you hold a file on.
The shift in one sentence. The unit of diligence is the plan and the configuration, not the company — so a file that records “vendor approved” without recording the tier, the models available, the retention setting as configured and the date each was verified is a file that cannot answer the question it was opened to answer.
Plain-English explainer · Vendor tiers, terms and sub-processors change — verify current documentation · Last reviewed September 2026
Most AI vendor files answer a question nobody asked. They record that a company holds a SOC 2 and an ISO certificate, that a DPA was executed, and that the review is due next January. What they do not record is the plan tier the organisation is actually on, the models its users can actually select, the retention and training-data position as actually configured on the tenant, and the date somebody last looked. Those four facts are where the risk lives, and all four can change without the vendor changing at all. This page is about closing that gap. It covers why the plan tier is the unit of analysis, what each artefact you can obtain genuinely proves and what it cannot, the model providers and sub-processors sitting behind the supplier whose name is on your order form, the contract terms that only matter once AI is involved, the evidence a licensed CPA firm requests when it tests the control, and the trigger list that keeps the file current between annual cycles.
Key Takeaways
- The unit of diligence is the plan and the configuration, not the company. The same product on a free tier, a team plan and an enterprise agreement can carry different positions on training-data use, retention, processing region, sub-processor notice and audit logging — and a tier change can remove a commitment with no visible event in the product.
- Every artefact answers a narrower question than it appears to. A SOC 2 covers the system described in section 3, which frequently predates the AI feature you are buying. A certificate covers a scope you have to read separately. A model card is self-published and written for the model rather than for your deployment.
- The supplier on your order form is rarely the one processing the inference. Ask which entity performs it, whether that changes by model, and whether a change is a notifiable sub-processor event — because on most self-serve tiers it is not.
- The contract terms that matter for AI are not the ones in a standard SaaS DPA: training-data use, retention of derived artefacts such as embeddings and indexes, model change and deprecation notice, human review of content for abuse monitoring, and what happens to anything built from your data on exit.
- AI supplier files go stale faster than any other kind, and the drift is usually configuration rather than contract. Eleven triggers should reopen a file, and only one of them is the calendar.
- Depth should follow consequence rather than spend. A bounded internal tool with no customer data does not need the file that an autonomous, customer-affecting deployment needs, and treating every supplier identically produces thin files everywhere rather than thorough ones where they matter.
Same product, different plan, different answer
A vendor-level assessment produces a vendor-level answer, and for classical software that is usually close enough: the security of the platform does not change much between the plan that costs twenty dollars and the one that costs two hundred. For AI products the opposite is true. The dimensions below are exactly the ones your customers ask you about, and every one of them can differ between tiers of the same product.
| What can differ by tier | How it varies | How to verify it | Where it bites |
|---|---|---|---|
| Whether your inputs and outputs train the model | The most consequential single term, and the one that most often differs between a free tier, an individual subscription, a team plan and an enterprise agreement on the same product. Some vendors default consumer tiers to training on inputs with an opt-out buried in settings, hold business tiers out by default, and commit contractually only on the enterprise agreement. Others take a uniform position. You cannot infer which kind of vendor you are dealing with from the brand. | The clause in the agreement that actually binds you, not the marketing page and not the help-centre article. Ask for the paragraph, in the agreement you are signing, with the tier named in it. Where the answer lives in a setting rather than a term, capture the setting, who can change it, and whether a tenant administrator or the vendor can change it back. | The question your largest customer asks in writing, and the one their counsel asks a second time. A commitment you made on the strength of a marketing page is a commitment you cannot evidence when it is tested. |
| Retention period and what deletion actually removes | Abuse-monitoring retention, conversation history, embeddings and indexes built from your content, and provider-side logging each have their own answer, and those answers frequently differ by tier. Zero-retention or no-logging processing is commonly an enterprise-only or application-only option, sometimes requiring an explicit request rather than arriving as a default. | Ask four separate questions rather than one: how long is the prompt and completion retained, how long is any derived artefact retained, what a deletion request removes and on what timescale, and whether abuse-monitoring copies sit outside that. A single number in a datasheet usually answers only the first. | Deletion commitments in your own customer contracts, a data principal or data subject erasure request that reaches an index you did not know existed, and the scoping of any incident that touches the supplier. |
| Processing region and residency | Residency options are frequently tier-gated and often partial: the primary inference may run in your chosen region while safety classification, abuse monitoring, evaluation sampling or a fallback route does not. Regional availability also differs by model within the same product, so the residency answer can change when a user picks a different model from a drop-down. | Which specific processing operations are pinned to the region, which are not, and what happens on failover. Ask whether the residency guarantee survives a model change, and get the answer for the specific models your people will actually select. | Transfer mechanisms under GDPR, sector residency expectations in regulated industries, and the answer you give a customer whose contract names permitted processing locations. |
| Tenancy and isolation of derived artefacts | Whether your content is used to build a shared index, whether caching is tenant-scoped, and whether fine-tuned weights or retrieval indexes are isolated to your tenant vary by product surface as well as by tier. Connectors and retrieval features often have a different isolation story from the base chat surface in the same product. | Name the feature, not the product. The answer for the chat surface and the answer for the connector-backed retrieval feature in the same suite are separate answers, and the second is usually the one that matters. | Confidentiality commitments and the multi-tenant question that appears in every serious enterprise security review. |
| Sub-processors and who may be added | Enterprise agreements typically carry a published sub-processor list, a notice period before additions, and some form of objection right. Consumer and self-serve tiers usually carry none of the three, which means a model provider can change beneath you with no notice you are entitled to. | The list itself, the notification mechanism and how you subscribe to it, the notice period in days, and what the objection right actually permits — objection with termination for convenience is a real right, objection with no remedy is a courtesy. | Your own sub-processor disclosures to your customers, and your ability to answer the flow-down question without a gap in the chain. |
| Administrative control, logging and export | Admin consoles, audit log APIs, retention of those logs, SSO and SCIM, and the ability to export or delete on behalf of a user are near-universally tier-gated, and the log retention window is frequently much shorter than the one your incident process assumes. | Whether the log exists, what fields it carries, how far back it reaches, whether it can be exported programmatically, and whether it survives seat deprovisioning. A ninety-day window against a twelve-month observation period is a finding waiting to happen. | Access-review evidence, incident scoping, and the logging criteria in a SOC 2 examination. This is also the row that most often turns a cheap tier into an expensive one at audit time. |
| Security commitments you can actually point at | Enterprise agreements carry security addenda, breach-notification timelines, audit or assessment rights, and in some cases liability terms scaled to the engagement. Self-serve terms carry a link to a trust page and a disclaimer. | Whether a breach-notification obligation exists at all, what triggers it, and how many hours or days it allows. Then read it against your own downstream notification obligations, because a supplier obligation that is slower than yours leaves you exposed for the difference. | Every downstream notification clock you carry, and the vendor-risk criterion your auditor tests. |
Why this is not a criticism of vendors
Tier differentiation is how these products are priced, and there is nothing improper about a vendor offering contractual commitments on a negotiated agreement that it cannot offer on a self-serve plan with no signature on it. The failure is on the buying side, and it is a failure of unit rather than of effort: a diligence process built for companies, applied to a product category where the company is not the thing that varies. Teams that do extremely careful work still produce files that say “vendor assessed” and cannot say which plan was assessed.
The version that catches sophisticated buyers is one level down. Your supplier is frequently an application built over somebody else’s model, and is itself on a plan tier of that provider — a tier governing retention, training and residency for the layer where your data is actually processed, which you did not negotiate and cannot read. The mitigation is not to obtain the upstream agreement. It is to make any change to it a notifiable event under your own contract.
A supplier file that records the company and not the plan answers the question “who did we buy from?”. Nobody has ever asked that question in a security review.
The criterion this lands on is CC9.2, which asks the entity to assess and manage risks associated with vendors and business partners. Nothing in it is AI-specific and nothing needs to be. What AI changes is the rate at which the assessed thing moves, and the number of layers between the entity you contracted with and the entity performing the processing. Where the deployment is governed under an AI management system, the supplier and responsibility-allocation controls in Annex A.10 of ISO/IEC 42001 ask the same question from the management-system side, and the two evidence sets overlap heavily. Keep the separation between approving a supplier and approving a use, though — they are different decisions with different owners, which is the subject of use-case approval versus vendor approval.
What each one proves, and what it does not
Collecting artefacts is the easy half and the half most files contain. Reading them for what they actually assert is the half that changes decisions. Every row below has a narrower scope than its name suggests, and the third column is where diligence either happens or does not.
| Artefact | What it genuinely tells you | What it does not | What to ask for |
|---|---|---|---|
| SOC 2 Type 2 report | That a licensed CPA firm examined a described system over a stated period and expressed an opinion on whether controls operated effectively to meet the criteria in scope. Read properly it gives you the system boundary, the subservice organisations and the method used for them, the complementary user entity controls you must perform, the tests the auditor ran, and any exceptions with management responses. | It does not tell you the AI feature is in scope. Vendors ship AI capabilities faster than they extend a system boundary, and a report whose description predates the feature covers the platform the feature runs on rather than the feature. It also says nothing about model behaviour, evaluation quality, training-data provenance or output reliability, because the common criteria ask about none of them, and the elective Processing Integrity criteria address the completeness, validity, accuracy and timeliness of system processing rather than the behaviour of a model. | The current report plus the previous one, the bridge letter if the period ended more than three months ago, and a direct written answer to a single question: is the AI capability we are buying inside the system described in section 3. |
| ISO/IEC 27001 certificate | That an accredited certification body found an information security management system conforming to the standard, within a defined scope, at a point in time, with surveillance audits between recertifications. | A certificate without its scope statement and its Statement of Applicability is close to unreadable for diligence purposes. The scope may name a legal entity, a location or a service line that does not include the product you are buying. Certification is not a controls-operated-effectively opinion over a period and should not be read as one. | The certificate with the scope statement, the accreditation body and certificate number so you can verify it against the certification body register, the issue and expiry dates, and the Statement of Applicability or at minimum the list of excluded controls with justifications. |
| ISO/IEC 42001 certificate | That an AI management system conforming to ISO/IEC 42001:2023 was assessed by a certification body — policy, roles, an inventory of AI systems, impact assessment processes, operational controls and continual improvement. For an AI supplier it is the most relevant management-system signal available, because it is the only one whose subject matter is the AI itself. | It is a management-system conformity assessment, not a product assessment, and it makes no statement about how any particular model performs. Check the scope for the same reason as ISO 27001, and check whether the certification body is accredited for 42001 specifically — accreditation for this scheme is younger and thinner than for 27001, and an unaccredited certificate is a different artefact wearing similar clothes. | Certificate, scope statement, certification body and its accreditation for the 42001 scheme, and the date of the most recent surveillance audit. |
| Model card or system card | The vendor’s own account of intended use, out-of-scope uses, training-data characterisation at a high level, evaluation results on named benchmarks, known limitations and identified risks. Its most useful section for diligence is usually the limitations one, because a vendor that names failure modes precisely is a vendor that has looked for them. | It is self-published, unaudited, written for the model rather than for your deployment, and frequently silent on exactly the population or language your use case depends on. A benchmark score is not a performance commitment and cannot be relied upon as one. | The card for the specific model version you will be served, not the family. Then ask the question the card cannot answer: what evaluation was run on data resembling ours, and if none was, what would it take to run one. |
| Data processing agreement | The instrument that makes the supplier a processor acting on your documented instructions, with the subject matter, duration, nature and purpose, data categories, security measures, sub-processor terms, assistance obligations, return-or-delete-on-termination and audit provisions. Under GDPR Article 28 a written contract of this kind is a condition of the processor relationship, and section 8(2) of the DPDP Act 2023 requires a Data Fiduciary to engage a Data Processor only under a valid contract. | A generic DPA drafted for a SaaS product routinely fails to address the AI-specific questions: training use of inputs, retention of derived artefacts such as embeddings and indexes, human review of prompts for abuse monitoring, and whether outputs are processed further. A DPA is necessary and it is not sufficient. | The DPA, the transfer mechanism and its supporting documentation, and an explicit AI addendum or an amended clause that answers the four questions above in the body of the agreement rather than by reference to a web page the vendor can edit. |
| Sub-processor list | Who else touches the data, which for an AI product usually reveals the layer that matters most — the inference provider, the cloud region, the moderation or safety service, the observability platform and any human-review vendor. | Lists are frequently incomplete for AI stacks specifically, because a vendor may treat an inference provider as infrastructure rather than as a sub-processor, or may list a cloud provider without naming the model provider running on it. Absence from the list is not evidence of absence from the stack. | The list, the subscription mechanism for changes, the notice period, and one direct question the list itself rarely answers: which entity performs the inference, and does that change by model. |
| Evaluation and red-team results | Whether the vendor tests its own system adversarially and what it found. For a product with tool access, the useful content is prompt-injection resistance, tool-invocation containment and what the system does when it is handed hostile content from a document, a web page or an email. | Almost never produced in a form you can rely on. Summaries are marketing artefacts, full results are rarely shared, and methodology is usually undisclosed, which makes the results uncomparable between vendors. A vendor that declines to share detail is not necessarily weak, but a vendor that cannot describe its methodology at all usually is. | The methodology and the cadence even where the results are withheld — what is tested, by whom, how often, and what happens when something is found. Then ask whether any finding has changed the product, which is the question that separates a programme from an exercise. |
| Penetration test summary | That an independent tester examined the application surface within a stated scope, and how the vendor handles findings. The letter is worth less than the scope statement attached to it. | Application penetration testing methodology does not generally address model-layer behaviour, and a clean report says nothing about prompt injection, tool misuse or excessive agency. Treat the two as separate assurance questions rather than assuming one covers the other. | Scope, date, tester, whether the AI surface and any tool or connector integrations were in scope, and the remediation status of anything rated high or critical. |
| Trust centre page and questionnaire responses | A fast first filter and a useful signal about maturity. A trust centre carrying a current report, a real sub-processor list with a subscription link, and a documented notice period is a vendor with a functioning compliance operation. | It is unbound marketing content the vendor can change without telling you, and it is the single most common source of a diligence answer that turns out to be untrue for your tier. Nothing on a trust page survives contact with a contractual dispute. | Use it to shape the questions. Record the answers from the agreement, the report or a written response from a named person — and capture the date you read it, because the page will not carry one. |
Two structural points run through the table. The first is that none of these artefacts says anything about how the model behaves. A SOC 2 opinion addresses controls against the trust services criteria. A certificate addresses conformity of a management system. A penetration test addresses an application surface. Output quality, hallucination rate, bias on a population that matters to you, and resistance to a document that contains instructions aimed at the model are all outside every one of them. If your use case depends on output reliability, the assurance for that has to come from your own evaluation, and it is the part of the file teams most often expect a vendor artefact to cover.
The second is that an artefact has a date and a scope, and both travel with it into your file. A certificate without an expiry recorded is a review that will never fire. A report without its period end recorded is a bridge letter you will not know to ask for. This is unglamorous and it is the difference between a register that manages itself and one that is only as current as the last person who remembered to look. How those artefacts are read in a buyer relationship generally is covered in vendor SOC 2 requirements and how to read a SOC 2 report.
Seven things to check in an AI supplier’s SOC 2
A general reading of a SOC 2 checks the opinion, the period and the exceptions. Reading one for an AI supplier adds a specific worry that the general reading does not surface: whether the report reaches the thing you are buying at all.
| The system boundary in section 3 | Read the description of the system and find the product surface you are buying, by name. If the description talks about a platform and your purchase is a feature shipped onto that platform eleven months after the description was written, you are reading a report about the floor rather than about the thing standing on it. |
| The period, against your own | A Type 2 covers a stated period. If it ended more than three months ago you want a bridge letter, and a bridge letter is a management representation rather than an auditor opinion — it asserts no material change, it does not test anything. If the AI feature launched after the period ended, no amount of bridging reaches it. |
| Subservice organisations and the method used | This is the row that matters most for an AI supplier, and the one most reviewers skim. Under the carve-out method the subservice organisation’s controls are excluded from the description and from the opinion, and you have to obtain assurance about them yourself. If the model provider or the hosting cloud is carved out, the report you are holding says nothing about the layer where your data is actually processed. |
| Complementary user entity controls | The controls the report assumes you will perform. For AI products these frequently include configuring retention, enabling or disabling training-data use, managing administrative access and controlling what content users may submit. A CUEC you have not implemented is a gap in your control environment, not in theirs, and your own auditor will ask. |
| The criteria categories in scope | Security is always present. Confidentiality, Availability, Processing Integrity and Privacy are elective. If you are relying on the report for a confidentiality commitment and only Security is in scope, the report does not support the reliance you are placing on it. |
| The opinion paragraph and any exceptions | A qualified opinion is not automatically disqualifying and a clean one is not automatically reassuring. Read the exceptions, the management responses and whether the response changed a cause or restated a policy. An exception disclosed with a dated remediation reads better than a scope narrow enough to avoid the question. |
| Whether the AI feature has its own controls at all | Search the control listing for anything addressing model access, prompt or output handling, training-data use, or evaluation before release. Where none exists, the honest reading is that the AI capability inherits the general control environment and has no controls specific to it — which may be acceptable, but it is a finding you record rather than an absence you do not notice. |
The third row deserves expansion, because it is the one that most often turns a comfortable file into an uncomfortable one. The carve-out method excludes a subservice organisation’s controls from both the description and the opinion. For a classical SaaS vendor the carved-out party is usually a hyperscaler with its own well-known report, and the residual risk is small and well understood. For an AI application vendor the carved-out party may be the inference provider — which is to say, the layer at which your prompts are actually processed. A clean opinion on a description that carves out the model provider is a clean opinion about the wrapper. That is not a criticism of the report. It is what the method means, and subservice organisations are treated the same way everywhere. It just has a different weight here.
The fourth row is the one your own auditor will test rather than the supplier’s. Complementary user entity controls are the controls the report assumes you perform, and for AI products they are unusually consequential: configure retention, set the training-data option, restrict administrative access, control what may be submitted, review what connectors are enabled. A vendor report obtained, filed and never opened at the CUEC section is among the most common vendor-management gaps, and it is entirely avoidable. The same logic applies to the shared-responsibility split with cloud providers, which is the version of this problem most teams already know.
On timing, the second row above gives the rule and the bridge letter its own treatment. The AI-specific consequence is the one worth repeating: where the capability launched after the period closed, no bridging reaches it, and the honest entry in your file is that this capability is not covered by the current report, with a date for when it will be. On exceptions, read the management response rather than counting the exceptions: what an exception actually means is usually less alarming and more informative than its presence suggests.
The stack you contracted with is one layer of five
Classical supply-chain diligence worries about the sub-processor list because a sub-processor might store data. AI stacks add a layer that processes it, and that layer is frequently a different company from the one whose logo is on the login page. Read the fourth column: it is the map of what your file cannot say.
| Layer | Who is actually there | What you can reach | What you cannot see |
|---|---|---|---|
| The application you contracted with | The vendor whose name is on the order form and whose product your people open. | Full contractual reach. This is where your DPA, your security addendum, your notice periods and your termination rights live, and the only layer at which you can negotiate anything. | Almost nothing, provided you asked. This layer is the easy one, which is why diligence that stops here feels complete and is not. |
| The model or inference provider | The frontier lab or hosted-inference platform actually running the model. Frequently a different company from the one you contracted with, occasionally several depending on which model a user selects or which route a fallback takes. | Contractual reach only through your vendor’s agreement with them, which you cannot read. Your leverage is the flow-down clause and the sub-processor notice period, and both are worth exactly what your agreement says they are. | Whether the model provider’s own terms permit training on data passed through, what their retention is, which region the inference runs in, and what happens when your vendor switches provider for cost or capacity reasons. This is the layer where the plan-tier problem repeats one level down: your vendor may be on a tier of the model provider that carries different terms from the one you assumed. |
| Cloud and hosting | The hyperscaler or platform the whole thing runs on, sometimes the same company as the model provider and sometimes not. | Usually well documented, usually carve-out in the vendor’s SOC 2, and usually the layer with the strongest independent assurance available. The shared-responsibility split is published and stable. | Region and failover behaviour for the specific service, and whether the residency commitment you were given survives a capacity event. Rarely the weakest layer, and rarely worth the share of review time it receives. |
| Safety, moderation and human review | Classification services, abuse-monitoring pipelines and — the one most reviewers miss entirely — human reviewers who may read flagged content, sometimes at an outsourced provider. | Minimal, and frequently undisclosed. Human review for abuse monitoring is often carved out of the retention and confidentiality story by a clause allowing processing for safety purposes. | Whether a human can read your prompt, under what trigger, where that person sits, how long the flagged copy is retained, and whether it is excluded from your deletion request. Ask this one directly, because it almost never appears in an artefact. |
| Observability, telemetry and evaluation sampling | Logging platforms, tracing tools and internal evaluation pipelines that may sample production traffic to measure quality. | Almost none, and rarely named in a sub-processor list because vendors classify these as internal tooling. | Whether production prompts are sampled into an evaluation set, who can see that set, and whether it is covered by the retention terms you were quoted. A vendor that answers this question precisely has thought about it. A vendor that has never been asked will need a week. |
Three questions that reach further than a sub-processor list
The fourth column above is a map of what your file cannot say. Three of those blind spots close if you ask directly rather than waiting for an artefact to volunteer them, and none of the three is normally covered by anything a vendor sends you unprompted.
- Which entity performs the inference, and does it change by model? The highest-yield question in AI diligence, and the one the sub-processor list only looks like it has answered. What you want is a mapping from each model your users can select to the entity that serves it.
- Can a human read our content, and under what trigger? Abuse monitoring is legitimate and widespread, and a flagged copy held for a safety purpose may sit outside both the retention window you were quoted and the deletion request you submit.
- Is production traffic sampled for evaluation? Measuring a language product means looking at what it was asked and what it said. Ask who can see the sample, how long it is kept, and whether your retention terms reach it.
Every one of those three is answered by a person, in writing, or not at all. That is the tell: a layer nobody can be asked about is a layer nobody has been asked about.
Thirteen fields that make a file answerable
The test of a supplier record is not whether it is complete but whether somebody can answer a customer’s written question from it without opening a contract or calling the vendor. These thirteen fields are what that takes. Half of them are configuration rather than contract, which is the point. Read the last column before the second: it is the shape each field takes when it has been populated badly, which is how these records usually fail rather than by being absent.
| Field | What a good entry holds | Why the field exists | What a bad entry looks like at fieldwork |
|---|---|---|---|
| Supplier legal entity and contracting entity | The entity named as counterparty on the executed agreement, with its jurisdiction, recorded alongside the brand the product is sold under where the two differ — which is usual. | It is the entity your DPA binds, the entity your notification clause runs against, and the entity that has to still exist for either to mean anything. Brands are marketing. Counterparties are served. | The brand name in the entity field. At fieldwork the register names a party that appears nowhere in the agreement, so the control cannot be tied to the contract it depends on. |
| Product surface and plan tier | "Business Standard, as named on the order form dated 14 January 2026, and confirmed against the tenant billing page 12 March 2026." The surface named separately from the suite, because the suite is not the surface. | Everything on the divergence table hangs off the tier. A file that records the vendor but not the tier has not recorded the thing that actually varies. | The word "Enterprise" typed into a free-text field from a sales email. It is not a plan name, it cannot be checked against an order form, and no question on the divergence table can be answered from it. |
| Models available to users on this tenant | The list as it appears in the tenant admin console on a stated date, which of them is the default, whether users may select others, and the date the list was last exported. | A residency or retention answer that holds for the default model and not for a selectable alternative is not an answer. Model choice is a user action with contractual consequences. | A single model family named at onboarding. When a user selects something else the register describes a deployment that no longer exists, and nobody generated an event. |
| Training-data position, with source | "Inputs and outputs not used to train or improve any model — clause 7.4 of the MSA dated 14 January 2026. Verified 12 March 2026 by the legal operations owner. Carve-out: abuse monitoring, clause 7.6." | It is the first question your own customers ask in writing, and the answer has to survive being asked for a second time by their counsel. | The words "no training on inputs" with no clause reference and a verification date of "onboarding". At fieldwork it reads as an assertion nobody can test, on the single term the file exists to record. |
| Retention settings as configured | Four numbers rather than one — prompt, completion, derived artefacts such as embeddings and indexes, and abuse-monitoring copies — each stated as configured on your tenant, with whether the setting required a request and which surfaces it covers. | The tier default is not the tenant setting, and a deletion commitment you made downstream is measured against what is actually configured. | The tier default copied from a datasheet. The register says thirty days. The tenant is on the default ninety, and the difference is discovered by the customer who asked. |
| Processing region as configured | The region setting, the specific operations it covers, the operations the vendor confirmed are excluded, and the documented failover position — the exclusions captured in writing, because they are the part that gets contested. | Transfer mechanisms and customer contracts naming permitted locations are both tested against the exclusions rather than against the headline. | "EU" in a one-word field. Safety classification and abuse monitoring run elsewhere, nobody asked, and the commitment in your own customer agreement was made against the one-word version. |
| Connectors, integrations and data sources enabled | Every source the product can reach, each with the identity used to reach it and the scope that identity holds, exported from the platform on a stated date rather than described from memory. | This field determines the blast radius of the deployment, and it changes more often than any other field on the record without anything being purchased. | A connector list written at onboarding against a product that has shipped twice since. The export and the register disagree, and the register is the document you handed the auditor. |
| Tool, action and write capability | Whether the product can take an action rather than only produce text, which actions, under whose credentials, whether a human approves before the action takes effect, and the date the capability was last confirmed against the live tenant. | The line between an assistant and an agent is crossed by configuration, not by purchase. Nothing in a vendor-shaped process observes the crossing. | The field absent entirely, which is the usual state. A write path enabled in twenty minutes by an administrator is invisible to a register that never had somewhere to record it. |
| Administrative access and identity integration | Who holds tenant administration by name, whether SSO and SCIM are enabled, and evidence that deprovisioning through the identity provider actually removes access to this product rather than merely to the login page. | Access-review evidence depends on it, and the joiner-mover-leaver control is tested against the product rather than against the directory. | SSO recorded as enabled with no test behind it. A leaver retains a local password on the product, and the access-review population never included this supplier. |
| Audit log availability and retention window | Whether a log exists, the fields it carries, the window in days, whether it can be exported programmatically, whether it survives seat deprovisioning, and the window written next to your own observation period so the comparison is on the page. | Incident scoping and the logging criteria in an examination both run against the window, not against the existence of a log. | A ninety-day window recorded with no comparison drawn, then produced against a twelve-month observation period. The evidence covers a quarter of the period and the gap is found by the person testing it. |
| Artefacts held and their dates | SOC 2 with its period end, certificates with issuing body and expiry, DPA version and execution date, sub-processor list with the snapshot date you captured it — dates in date fields rather than inside a filename. | Dates are the field that makes the register self-policing. An expiry you recorded is a review that fires without anyone remembering. | Artefacts filed in a folder with no dates extracted. A certificate lapsed in March, the review was due in January, and nothing in the system could have raised either. |
| Tier, and the basis for it | The tier, the two or three attributes that set it, the date it was derived and by whom — "Tier 2: customer contract text in scope, no action capability, human between output and effect. Derived 14 January 2026." Re-derived, not renewed, when a triggering attribute changes. | A tier with a rationale can be argued with, re-derived and defended in an interview. A tier without one is a label, and two reviewers in the same organisation will assign it differently. | A tier column populated and a rationale column empty across the whole register — which is the specific tell that tiering is nominally in place and not operating. |
| Owner, review date and next review | A named business owner who is not the person who bought it, a named deputy, the date of the last substantive review, what that review actually examined, and the date of the next. | Ownership is what makes every other field maintainable, and it is the first thing an assessor tests by asking the named person a question. | An owner who left in November, or a review column carrying one identical date across every supplier — which evidences a bulk update rather than a review, and is tested as such. |
Three of these do most of the work and are the three usually missing. Plan tier as it appears on the order form, because everything on the divergence table hangs off it. The date verified against each position, because a position without one is an assumption with good posture. And connector and tool capability, because it changes most often, changes without a purchase, and sets what the deployment can reach.
That last field is where the supplier question quietly becomes a different one. A product that produces text carries the risk profile of a document. A product that can call a tool or write to a system carries that of a system with credentials, and should be assessed as one — a transition covered in when a tool becomes an AI agent. Excessive Agency sits at LLM03 in the 2026 edition of the OWASP Top 10 for LLM Applications, published 4 August 2026, up from LLM06 in the 2025 edition — the largest upward move on that list, and it moved because of incidents in production agentic systems rather than because of theory. Where the product ingests content it did not author — a document, a web page, an email, a ticket — Prompt Injection is LLM01 in the same edition, and the relevant supplier question becomes what the product does with instructions that arrive inside content. That interaction is the subject of prompt injection and tool calls.
The register this record lives in should be the same one that holds every AI system in use, not a separate procurement artefact — a point made at length in the AI system inventory and registry. Two registers describing the same deployments diverge within a quarter, and the one nobody uses is always the one the auditor asks for.
What one supplier looks like filled in
Field definitions are easy to agree and hard to apply. Below is the supplier from the worked example further down this page, as the record reads after the remediation that closes that story. All thirteen fields, populated. It is illustrative, not a client. Read it for the shape of an answer rather than the content: every position carries the date it was verified and the clause or export it came from.
| Supplier legal entity and contracting entity | SUP-0117. Counterparty on the MSA is the supplier’s Irish operating entity. The product sells under a brand that does not match it, recorded as an alias rather than in the entity field. Both taken from the executed agreement of 14 January 2026, not the website footer. |
| Product surface and plan tier | Document-intelligence suite, contract-summarisation surface only. Business Standard, as named on the order form dated 14 January 2026, and re-confirmed against tenant billing 28 July 2026. The suite’s meeting-notes surface is not licensed here, recorded so a later "we already have them" argument cannot smuggle it in. |
| Models available to users on this tenant | Four selectable, exported from the admin console 28 July 2026 — two from the original provider, two from the provider added on 3 March. Default is the original provider’s general model. Selection is unrestricted, logged as an open item because the residency answer below differs between the two. |
| Training-data position, with source | Not used to train, fine-tune or improve any model — clause 7.4 of the MSA dated 14 January 2026. Verified 12 March and again 28 July 2026 by the legal operations owner. One carve-out recorded in full rather than summarised: content flagged by abuse monitoring may be retained and reviewed under clause 7.6. Flow-down of 7.4 to the second model provider confirmed in writing 16 July 2026. |
| Retention settings as configured | Four numbers, because one would have hidden three of them. Prompts and completions: 30 days, reduced from the plan default of 90 on request. Derived artefacts — the retrieval index over uploaded contracts: life of tenant, deletion on request within 30 days, confirmed 16 July 2026. Abuse-monitoring copies: 90 days, outside the deletion request, clause 7.6. The index line had been assumed to fall inside the 30-day figure and did not. |
| Processing region as configured | Inference pinned to the EU region. Two exclusions captured in writing on 16 July 2026 because they get contested later: safety classification runs outside the pinned region, and capacity failover may route inference outside it with notice after the fact. The second provider’s regional coverage differs from the first — hence the open item above. |
| Connectors, integrations and data sources enabled | Two, exported 28 July 2026 rather than described. Contract repository: read and write, under a service credential held by legal operations, write path added 28 April 2026. Identity provider: SSO only, no directory read. The previous version of this field was a sentence written at onboarding, and was wrong by April. |
| Tool, action and write capability | Write, added 28 April 2026, re-reviewed at Tier 1 on 24 June. The product files generated summaries into the contract repository over an API token. Since 31 July the write is held for release by a named reviewer, with the source clauses shown alongside so the reviewer checks something rather than approving a summary of itself. Before that it wrote unattended, and no field said so. |
| Administrative access and identity integration | Tenant administration held by two named people in legal operations, neither the requester. SSO enabled. SCIM unavailable on this plan, recorded as a gap with its compensating control — monthly manual reconciliation of the product’s user list against the leaver report, tested 30 July 2026 rather than assumed. |
| Audit log availability and retention window | Administrative and document-access events, 90 days on this plan, exportable through the console but not by API. Written on the same row: the observation period is twelve months. The comparison sits on the record deliberately — extended retention is an Enterprise-tier feature, so this is a plan-tier decision with an evidence consequence. Position taken: monthly export to our own store, first run 31 July 2026. |
| Artefacts held and their dates | SOC 2 Type 2 for the period ended 30 September 2025, bridge letter covering 1 October 2025 to 14 January 2026. ISO/IEC 27001 certificate expiring 11 November 2027, scope statement obtained and the product surface confirmed inside it. DPA executed 14 January 2026, and AI addendum v2 executed 24 June 2026. Sub-processor list captured 28 July 2026, superseding a January snapshot that did not contain the second model provider. |
| Tier, and the basis for it | Tier 1, re-derived 24 June 2026. Basis, stated so it can be argued with: customer contract text in scope, the product can act in a system of record, and — until 31 July — no human between output and effect. Previously Tier 2, derived 14 January 2026, which was correct that day and stopped being correct on 28 April when an attribute changed and nothing re-derived it. |
| Owner, review date and next review | Owner: Head of Legal Operations. Deputy: Contracts Manager. Both named 24 June 2026. The original entry had the requester as owner, and the requester had changed roles. Last substantive review 31 July 2026, and what it examined is recorded — the scope export, the four retention figures re-confirmed in writing, the sub-processor list against the January snapshot. Next review 31 January 2027, with a quarterly reconciliation between. |
One habit runs through every field in that record and it is the only thing worth copying from it: each value was exported or cited, then dated. That is what lets the retention row carry four numbers instead of one, the connector list show a write path nobody announced, the log window sit next to the observation period it has to cover, and the tier say that Tier 2 was correct in January and stopped being correct in April — a statement a bare label cannot make.
Ten terms that only matter once AI is involved
A standard SaaS data processing agreement handles storage, access, security measures and deletion competently, because those are the questions it was drafted for. It does not reliably handle any of the ten below, and a supplier file that relies on a generic DPA for an AI product has a gap in exactly the places the product is different.
| Term | What to ask for | The version that will not hold | Why it matters |
|---|---|---|---|
| Training-data use | An affirmative statement that customer inputs and outputs are not used to train, fine-tune or improve any model, for the tier you are on, with any exception stated in the clause rather than in a policy the vendor can revise. | A cross-reference to an online policy, a commitment qualified by "unless you opt in" where opt-in is a setting an end user can toggle, or silence combined with reassurance on a call. | It is the first question your own customers ask, and a commitment sourced from a web page cannot be evidenced when a regulator or a counterparty asks you to produce it. |
| Retention and deletion of derived artefacts | Retention stated separately for prompts, completions, embeddings, indexes, fine-tuned weights and abuse-monitoring copies, with a deletion commitment that names a timescale and says what it reaches. | A single retention number covering "your data", with derived artefacts unmentioned. The embedding index built from your documents is not obviously covered by a clause about conversation history, and reasonable people read that clause both ways. | Erasure obligations, your own deletion commitments, and the honest answer to what is left behind after termination. |
| Sub-processor notice and objection | A published list, notification by a mechanism you can subscribe to, a defined notice period before a new sub-processor begins processing, and an objection right with a real remedy attached. | Notice by website update, no period, and an objection right whose only remedy is to stop using a service you have already built into a workflow. | Model providers change. Without this clause the layer where your data is processed can change beneath you, and you will find out from a changelog. |
| Processing location | The regions in which processing occurs, which operations are covered, what happens on failover, and a change-notification obligation. Where a residency option is tier-gated, confirm it is enabled on your tenant and capture the evidence. | A residency claim in a datasheet with no contractual counterpart, or a regional commitment that quietly excludes safety classification and abuse monitoring. | Transfer mechanisms, sector residency expectations, and the contracts you have already signed naming permitted locations. |
| Model change and deprecation | Notice before a default model changes, a pinning option for a named version, a deprecation window long enough to re-test, and notification when a version is retired. | Silence — which is the norm on self-serve tiers, and which means the system underneath your validated workflow can be replaced without any event you would observe. | Everything you evaluated was evaluated against a version. Without notice and pinning, your evaluation evidence has an expiry date you cannot see. |
| Security incident notification | A notification obligation triggered by a security incident affecting your data, with a stated maximum period, a minimum content standard, and a named contact route that is not a support ticket queue. | Notification "without undue delay" with no outer limit, or an obligation that runs from the vendor’s conclusion of its investigation rather than from its awareness. | Your own clocks run from your awareness, and if your supplier controls when you become aware, your downstream obligations are hostage to their triage speed. |
| Audit, assessment and evidence rights | A commitment to provide the current SOC 2 or equivalent annually, to respond to reasonable security questionnaires, and to notify on a material change in certification status — including a lapse. | An audit right in principle with no artefact obligation, so each annual review restarts as a negotiation with a sales team. | This clause is what makes ongoing review possible at all. Without it, re-review depends on the supplier’s goodwill at exactly the moment their goodwill is least available. |
| Output ownership and indemnity | A clear statement on ownership of outputs and whatever intellectual-property indemnity the vendor offers on your tier, with its conditions and exclusions read rather than assumed. | An indemnity headline whose conditions require you to use a filter you have disabled, or which excludes exactly the use you bought the product for. | It determines whether generated material can enter your codebase or a customer deliverable, and your engineering and legal positions are written against the answer. |
| Human review of content | Disclosure of whether humans may read submitted content, under what triggers, where those reviewers are located, whether they are employed or outsourced, and how long flagged copies are retained. | A safety-purposes carve-out broad enough to swallow the retention and confidentiality terms sitting above it. | It is the disclosure most likely to surprise a customer after the fact, and the one least likely to appear in any artefact unless you ask for it by name. |
| Exit, export and transition | Export in a usable format, a defined deletion-on-termination commitment with confirmation, and a transition period. Where fine-tuned weights or an index were built from your data, the clause should say what happens to them. | Deletion on termination "in accordance with our standard practices", with no confirmation and nothing said about derived artefacts. | Concentration on a single AI supplier is now a real availability and commercial risk, and the exit clause is the only part of the file that addresses it. |
Two of these are worth fighting for even when the rest are conceded, because they are the only two that protect you against changes you would not otherwise observe. Sub-processor notice with a real period and a real remedy is what makes the model-provider layer visible at all. Without it your supply chain changes by website update. And model change notice with a pinning option is what stops your evaluation evidence from silently expiring. Everything else on the table can be compensated with a process on your side. These two cannot, because both address events that produce no signal in your environment.
Drafting the four that carry the most weight
A principle is not a clause, and the gap between them is where most AI addenda fail. Below is drafting input for the four terms that do the most work: operative language for the primary ask, the fallback still worth signing when it is refused, and the point below which the term should be treated as absent rather than weak. It is input for your own counsel rather than legal advice, and it assumes its defined terms are actually defined — the retention clause does not bite unless Derived Artefacts reaches embeddings, indexes and fine-tuned weights.
| Term | The primary ask, drafted | The fallback still worth having | The red line, and what it costs you |
|---|---|---|---|
| Training-data use | "Supplier shall not use Customer Data, nor any Derived Artefacts, to train, fine-tune, adapt, evaluate or otherwise improve any model, classifier or service, whether for Customer, for Supplier or for any third party. Supplier shall procure the observance of this restriction by each Sub-processor. Any exception is stated in this clause and nowhere else. No policy, documentation page or product setting varies it." Define Customer Data to cover inputs and outputs both — a clause reaching prompts but not completions leaves the generated material available. | Where the supplier will not bind every Sub-processor, take the commitment for itself plus an obligation to pass it down and to tell you if it cannot. Where an abuse-monitoring carve-out is immovable, bound it rather than fight it: name the trigger, cap the retention, restrict who may read the content, and exclude that material from training use even though it survives deletion. | A commitment living in a policy the supplier can revise, or one qualified by "unless you opt in" where opt-in is an end-user setting. Record the term as absent and cap the use at Tier 3. |
| Retention and deletion of Derived Artefacts | "Derived Artefacts means any embedding, vector, retrieval index, cache, fine-tuned weight, adapter, evaluation set or other representation generated from Customer Data, whether or not Customer Data can be reconstructed from it. Supplier shall retain Customer Data and Derived Artefacts no longer than the periods in Schedule X, which states separate periods for prompts, completions, Derived Artefacts and any abuse-monitoring copy. On written request, and in any event within thirty days of termination, Supplier shall delete both from live and backup systems and certify deletion in writing." The definition is the clause: without it the term reaches conversation history and leaves the index built from your documents outside it. | A longer deletion window, or backup-cycle expiry rather than immediate deletion from backups, still leaves a defined end state. Hold the definition and the separate periods — four numbers rather than one — because those are what let you answer an erasure request without guessing. | Deletion "in accordance with Supplier’s standard practices", Derived Artefacts unmentioned, no confirmation. You cannot make a deletion commitment to your own customers on top of it, so do not make one. |
| Sub-processor notice and objection | "Supplier shall maintain a current list of Sub-processors, including each entity performing inference or model hosting, at a location Customer can subscribe to for notifications, and shall notify Customer at least thirty days before a new Sub-processor begins processing Customer Data. Customer may object on reasonable data-protection grounds within that period. Failing agreement on a remedy, Customer may terminate the affected service without penalty and receive a pro-rata refund." Name the inference layer explicitly — a generic clause is routinely read as not reaching a model provider the supplier classes as infrastructure. | A shorter period, or notice with no termination remedy. Notice without a remedy is still worth having: it turns a silent change into a dated event you can record, reassess and disclose downstream. What you lose is leverage, not visibility. | Notice by website update, no period, no subscription. This is the term the worked example turns on: the supply chain then changes by publication and you hear about it from a customer. |
| Model change and deprecation | "Supplier shall notify Customer at least sixty days before changing the default model serving the Service, deprecating a model version in use by Customer, or changing the entity performing inference. At Customer’s request Supplier shall keep a named model version available for not less than one hundred and eighty days from notice of deprecation. Supplier shall notify Customer of any change that materially alters output characteristics, whether or not the version identifier changes." That last sentence is the one that matters: routing and system-prompt changes move behaviour without moving the version string. | Pinning on request rather than by right, or a shorter deprecation window, works if you size your re-evaluation cycle to fit it. Notice without pinning is the weakest version still worth signing — you cannot stop the change, but you know when to re-run the evaluation. | Silence, the norm on self-serve tiers. Every evaluation you hold then has an invisible expiry date. Keep validated workflows off this supplier, and do not cite the evaluation at audit without saying the version is unpinned. |
The red-line column is the one to read as policy rather than as drafting. Each of those positions is a statement that the term cannot be obtained on this supplier at this tier, and that the use has to be capped to match — which is a decision somebody takes and records, not a gap that sits in the file unremarked. That is what the exception record further down this page is for, and it is the difference between an accepted risk and an unnoticed one.
A note on leverage, because advice of this kind is often written as though every buyer were a large one. On a self-serve tier you will negotiate nothing, and the correct response is not to pretend otherwise but to record the position accurately, tier the use accordingly and keep consequential work off that supplier. Leverage arrives at three moments: at first purchase, at renewal, and when you are expanding. The organisations that get these clauses are usually the ones that asked at the second or third of those rather than the first, and asked for two clauses instead of ten. A negotiation that wins the notice period and the model-change clause has done more than one that sought a redline on everything and ran out of time.
Where personal data is in scope, the processor relationship itself is the baseline rather than an enhancement: GDPR Article 28 conditions processing on a written contract with defined content, and section 8(2) of the DPDP Act 2023 requires a Data Fiduciary to engage a Data Processor only under a valid contract. Neither is satisfied by acceptance of online terms in a signup flow that nobody in your organisation can produce a copy of. Which of your own obligations attach, and in which role, is covered in what is a data fiduciary and, for the AI-specific roles, in the AI roles an organisation can occupy.
Questions that discriminate, and questions that do not
A two-hundred-question security questionnaire issued to an AI vendor usually produces two hundred compliant answers and no decision. The test of a question is whether two genuinely different suppliers would answer it differently. Most questions fail that test, and the seven below fail it in instructive ways.
| The question that returns nothing | Why it fails | What to ask instead |
|---|---|---|
| "Do you take security seriously?" — and its longer relatives. | Every question with one obviously correct answer returns that answer. Questions of this shape occupy most of the length of most questionnaires and contribute nothing to a decision, while training the respondent to answer the whole document on autopilot. | Ask for an artefact or a specific fact: the current report and its period, the certificate and its scope, the named contact for security incidents. A question answerable only by producing something is a question that discriminates. |
| "Do you use customer data to train your models?" | Ambiguous on three axes at once — which tier, which surface, and whether fine-tuning, evaluation, safety classification and abuse monitoring count as training. A truthful "no" is available to almost any vendor under some reading. | Ask it four ways. Are inputs or outputs on our plan used to train or fine-tune any model. Are they used to evaluate or improve any model or safety system. Are they retained in any form beyond the stated retention window. And which contractual clause states this, on the agreement we are signing. |
| "Are you SOC 2 compliant?" | There is no such status. It invites a yes from a vendor holding a two-year-old Type 1 covering a system that does not include the product you are buying, and it gives you no purchase when that turns out to be the case. | Ask for the report. Then ask the only question that actually matters for an AI purchase: is the AI capability we are buying inside the system described in section 3, and if not, when will it be. Written answer, from a named person. |
| "Where is our data stored?" | Storage is rarely the interesting question for an inference product, where the material processing is transient and the residency answer differs between inference, logging, safety classification and evaluation. | Ask where inference is performed, where prompts are logged, where safety classification runs, where abuse-monitoring copies are held, and what changes on failover. Then ask which of those five answers is contractual. |
| "Do you have an AI policy?" | Yes is available to any vendor with a document, and the document is not the control. It also asks about the vendor’s internal use of AI rather than about the product you are buying, which is a different subject. | Ask what governs the product: how models are selected and approved for release, what evaluation is run before a model change reaches customers, who can change a default model, and whether you are notified. If they hold ISO/IEC 42001 certification, ask for the scope statement. |
| "Do you notify us of changes?" | Everyone says yes, meaning a changelog. A changelog is a publication, not a notification, and nobody on your side is subscribed to it. | Ask which change classes trigger a proactive notification to a named contact — sub-processor addition, default model change, region change, retention change, certification lapse — with the notice period in days for each, and where that obligation sits in the contract. |
| "Have you had a breach?" | A question that invites a defensive one-word answer and tells you nothing about the capability you actually care about, which is how they would handle the next one. | Ask what triggers notification to customers, what the maximum period is, what the notification will contain, who the named contact is, and whether the clock runs from awareness or from the conclusion of their investigation. The last one is the one that matters. |
One drafting rule sits underneath all seven: a question whose answer you cannot file is a question you have not really asked. “Yes, we take security seriously” goes nowhere in a register. “Not used for training under clause 7.4 of the agreement dated 14 January 2026, verified 12 March 2026” goes into a field and answers a customer’s question two years later without anyone re-opening the contract. So design the questionnaire backwards from the register rather than forwards from a template. How this reads from the other direction — when you are the one receiving it — is covered in SOC 2 and security questionnaires.
The set, written backwards from the register
That rule produces a table rather than a document. Every question exists because a field needs populating, and the third column names which. Three are asked of every supplier, thirteen more from Tier 2, and five more at Tier 1 — where the questions stop being about the supplier’s posture and start being about your deployment. The fourth column does the real work: the form of answer you will accept, which is what stops a clause question being closed with a paragraph of reassurance.
| The question, as issued | Asked from | Field it populates | Acceptable form of answer |
|---|---|---|---|
| Which legal entity is the counterparty on the agreement we are signing, and is the product brand a different name? | Tier 3 | Supplier legal entity | The executed agreement. |
| What is the plan name exactly as it appears on our order form, and which product surfaces does it license? | Tier 3 | Product surface and plan tier | Order form, plus a screenshot of the tenant billing page. |
| Are inputs or outputs on our plan used to train or fine-tune any model? | Tier 3 | Training-data position | Clause reference in the agreement we are signing, with the tier named in it. |
| Are they used to evaluate, improve or tune any model, classifier or safety system — separately from training? | Tier 2 | Training-data position | Clause reference, or a written answer from a named person where the clause is silent. |
| Which clause states this, and does it also bind your sub-processors? | Tier 2 | Training-data position | Clause reference. A policy link is not an answer to this question. |
| What is retained, for how long, stated separately for prompts, completions, derived artefacts such as embeddings and indexes, and abuse-monitoring copies? | Tier 2 | Retention settings | Four figures in writing. One figure is a sign the question was not understood. |
| What does a deletion request actually remove, on what timescale, and what does it not reach? | Tier 2 | Retention settings | Written answer from a named person, plus the clause if one exists. |
| Which of those retention figures are tenant settings we control, and which are fixed by the plan? | Tier 2 | Retention settings | Screenshot from our own tenant admin console, dated. |
| Which entity performs the inference, and does that change by model or on failover? | Tier 2 | Models available · supplier stack | A mapping from each selectable model to the serving entity. Written, from a named person. |
| Which models can our users select, which is the default, and can we restrict the list? | Tier 2 | Models available | Export or screenshot from the tenant admin console, dated. |
| Which specific processing operations are pinned to our chosen region, and which are excluded? | Tier 2 | Processing region | Written answer naming the exclusions. "EU" on its own is not an answer. |
| What is the audit-log retention window in days, what fields does it carry, and can it be exported? | Tier 2 | Audit log window | Written figure, verified against the console. Compare it to your observation period before filing it. |
| Can a human read our content, under what trigger, where are those reviewers, and how long is the flagged copy kept? | Tier 1 | Retention settings · contract terms | Written answer from a named person. This one almost never exists in an artefact. |
| Is production traffic sampled into an evaluation set, who can see it, and is it covered by the retention terms we were quoted? | Tier 1 | Retention settings | Written answer from a named person. |
| What evaluation has been run on data resembling ours, and if none, what would it take to run one? | Tier 1 | Tier basis · approval record | Methodology and cadence, even where results are withheld. A benchmark score does not answer it. |
| Is the AI capability we are buying inside the system described in section 3 of your SOC 2 — and if not, when will it be? | Tier 2 | Artefacts held | Written answer from a named person, with a date. |
| Which sub-processors are on the current list, how do we subscribe to changes, and what is the notice period in days? | Tier 2 | Artefacts held · contract terms | The list with a capture date, the subscription link, and the clause. |
| What notifies us of a default model change or a deprecation, with how much notice, and can we pin a version? | Tier 1 | Contract terms · models available | Clause reference. Silence here is itself the recorded answer. |
| What triggers security incident notification to us, what is the maximum period, and does the clock run from your awareness or from the conclusion of your investigation? | Tier 2 | Contract terms | Clause reference. The last part of the question is the part that matters. |
| What can the product do beyond producing text — which actions, under whose credentials, and does a human approve? | Tier 2 | Tool, action and write capability | Scope export from the platform, plus a demonstration of the approval step at Tier 1. |
| On termination, what is exported, in what format, what is deleted, and what happens to anything built from our data? | Tier 1 | Contract terms · artefacts held | Clause reference, and a deletion-certification commitment in writing. |
Twenty-one is shorter than almost any questionnaire in circulation and costlier than it looks, because several cannot be answered without the respondent going and finding something. That is the intended cost. A question a vendor answers from memory tells you what they believe, while one that requires a clause reference or a console export tells you what is true.
Depth follows consequence, not spend
A process that applies the same depth to every AI supplier produces thin files everywhere rather than thorough ones where it matters, and it collapses under volume within two quarters because the people running it stop believing in it. Tier by what happens when the deployment is wrong, not by what it costs — the most consequential AI supplier in many organisations is also one of the cheapest.
First, the rubric the tier comes out of
A tier assigned by judgement is one two reviewers will assign differently, neither able to show their working. Seven attributes move the answer. Assess each against evidence rather than the requesting team’s description, then apply the combination rule: any single Tier 1 attribute sets Tier 1, and two Tier 2 attributes escalate to it. The tier belongs to the deployment, so it is re-derived — not renewed — when a capability ships, when the use materially changes, or when your plan tier moves.
| Attribute | What each value implies for the tier | What evidence fixes the value |
|---|---|---|
| Data class reaching the product | Public or already-published material: Tier 3. Internal material: Tier 3, or Tier 2 where volume makes aggregation meaningful. Customer data, personal data, or anything under a customer NDA: Tier 2. Special-category personal data, or customer data under a contract naming permitted processing locations: Tier 1. | The connector inventory and the tenant configuration, not the requester’s description of what people will paste. A product with a read connector into a customer system carries that system’s data class regardless of intent. |
| Can it take an action, or only produce text? | Produces text for a person to read: no escalation from this attribute. Can call a tool, write to a system, send a message or move a record: Tier 2 minimum. Can take an action that is irreversible in practice — an external send, a payment, a deployment, a deletion: Tier 1. | The scope export from the platform, read for write and send permissions. This is the attribute most often answered wrongly, because the answer changes when an administrator enables a feature and nothing re-asks the question. |
| Is a human between the output and the effect? | A named person releases each output: holds the tier where the other attributes put it. Unattended, or a human approval that is a single click with nothing shown to check against: escalates one tier, and combined with action capability sets Tier 1. | A demonstration, not a policy. Watch the approval step and ask what the reviewer is shown. An approval screen that displays the output and not its basis is a rubber stamp with a log entry. |
| Does it affect an individual’s access to something? | Employment, credit, education, housing, insurance, healthcare or access to a service you provide: Tier 1, on this attribute alone. Assists a person who decides, with the decision and its reasons recorded by them: Tier 2. No bearing on individuals: no escalation. | The business process description, tested against what happens to the output. "It only ranks candidates, a recruiter decides" is a Tier 1 answer wearing Tier 2 clothes if nobody ever promotes a candidate the ranking placed last. |
| Is the process regulated? | Financial reporting, clinical, safety-critical, or subject to a sector regulator’s expectations on outsourcing or automated processing: Tier 1, and the scoping question is answered explicitly rather than assumed away. Regulated organisation, unregulated internal process: no escalation from this attribute alone. | Legal or compliance answers this one, not the requesting team. It is the attribute business owners most reliably get wrong in both directions. |
| Would failure be visible to your customers? | Output reaches a customer, or a customer-facing system, without a person re-deriving it: Tier 2 minimum, Tier 1 where it reaches them unattended. Visible only internally: no escalation. | Trace the output forward one more step than feels necessary. The board pack that has quoted a generated figure since December is a downstream dependency nobody recorded. |
| Do outputs feed a system of record? | Written into a repository, CRM, ledger or case system that others later rely on as fact: Tier 2 minimum, and Tier 1 where the write is unattended. Read and discarded: no escalation. | The write scope on the connector, plus one question: who later reads this field and do they know it was generated? Provenance that is not recorded at the write is not recoverable afterwards. |
Record the outcome as the attributes plus a date rather than as a label, in the tier field of the record above. That is what makes the assignment arguable, re-derivable and defensible in an interview — and it is what stops the rationale column being empty, which is the specific failure the next two paragraphs describe.
| Tier | What it looks like | Depth of the file | Who decides |
|---|---|---|---|
| Tier 3 — bounded, low consequence | No customer or personal data, no system access, no autonomy. A transcription tool on internal meetings, a drafting assistant on public material, an image tool for marketing. | Register entry, terms reviewed, training-data and retention position recorded with its source, named owner, annual confirmation. No report required, no questionnaire issued. | The requesting team, recorded centrally. Security is notified, not consulted. |
| Tier 2 — production data or meaningful reach | Touches customer data, personal data or internal systems, but does not act autonomously and does not make decisions about people. Most enterprise assistants and most connector-backed retrieval deployments land here. | Full artefact set: current SOC 2 read against the system boundary, certificates with scope, DPA with an AI addendum, sub-processor list with subscription, the full configuration record, and a differentiated questionnaire. Re-review annually and on any trigger. | Security with the business owner, against a published turnaround. Privacy joins where personal data is in scope. |
| Tier 1 — consequential, autonomous or regulated | Acts on systems without a human in the loop, moves money, affects an individual’s access to employment, credit, education or a service, sits in a regulated process, or would be visible to your customers if it failed. | Everything at Tier 2, plus evaluation evidence for your own use case rather than the vendor’s benchmark, the oversight design tested rather than described, the exit plan written before signature, and an impact assessment. Where the deployment falls inside a high-risk classification, the obligations attaching to that classification are scoped explicitly rather than assumed away. | An AI governance forum with legal and privacy present. Residual risk accepted by the accountable executive by name, not by the forum. |
Two failure modes account for most of what goes wrong here, and they are opposites. The first is everything at Tier 3, which is what happens when tiering is nominally in place but nobody wants the argument about assigning a higher tier to a tool a senior person already likes. The tell is a register where the rationale column is empty. The second is everything at Tier 1, which looks rigorous for a quarter and then quietly stops operating, because a process that demands an impact assessment for a transcription tool teaches people to route around it. The tell is a backlog of pending assessments and a parallel population of tools nobody submitted.
Because the tier belongs to the deployment, the same supplier can legitimately sit at Tier 3 for one use and Tier 1 for another, and a register that cannot express that will force a wrong answer in one direction or the other. Where the deployment affects individuals, the assessment question separates into two instruments rather than one — the organisation-facing risk assessment and the people-facing impact assessment — a distinction set out in AI risk versus AI impact assessment.
At Tier 1 one more thing is worth doing before signature rather than after it: write the exit. What you would export, in what format, how long a transition would take, what alternative exists, and what happens to anything built from your data. It takes an afternoon at the point when you have maximum leverage and nobody is under pressure, and it is the part of the file that turns out to matter on the day a supplier changes its pricing model, its terms or its ownership.
Twelve steps, four sets of hands
Most supplier processes fail at the handover rather than at the assessment. The work is genuinely split — the business owner knows the process, security owns consistency across the portfolio, legal owns the words that bind, and somebody has to prepare the evidence — and every step where two parties each believe the other has it is a step that silently does not happen. One row per step, one column per set of hands.
| Step | Requesting business owner | Security | Legal and privacy | TCSA |
|---|---|---|---|---|
| Raise the request | Owns. Names the business process, the data classes that would reach the product, and what it is meant to do that cannot be done today. | — | — | Supplies the intake form, shaped so the tier can be derived from the answers without a second conversation. |
| Assign the tier | Proposes, and supplies the attributes. | Owns the decision. The tier drives every requirement downstream, so it is made once and recorded with its basis. | Confirms whether the process is regulated and whether individuals are affected — two of the attributes the business owner most often gets wrong. | Designs the rubric and calibrates the boundaries against the estate, so Tier 1 stays rare enough to mean something. |
| Obtain and read the artefacts | Introduces the vendor contact and chases. Does not assess. | Owns. Reads the report against the system boundary rather than filing it, and records which CUECs apply to you. | — | Runs the read against the seven checks on this page and drafts the file note, including what the artefacts do not reach. |
| Negotiate or record the terms | Supplies the commercial leverage and the renewal date. | States which terms are required at this tier and which are preferences. | Owns the drafting and the negotiation, working from the clause language rather than from principles. | Supplies the drafting input, the fallback positions, and the red lines at which the use should be tiered down instead. |
| Capture the configuration record | Provides tenant access and confirms what is actually switched on. | Owns. Exports rather than describes — scopes, model list, retention settings, connector inventory. | Records the clause references and dates against the contractual fields. | Defines the thirteen fields and the evidence standard for each, so a later export can be compared mechanically. |
| Approve or refuse | Accepts the residual risk at Tier 3, in their own name. | Approves at Tier 2. Refusal is a decision with a written reason, not a silence. | Joins at Tier 2 where personal data is in scope, and present at Tier 1 without exception. | Prepares the paper the decision is taken on. Does not take it. |
| Subscribe to the change feeds | — | Owns. Points every subscription at a role-owned queue and records the subscription state as a field, so its absence is visible. | Confirms which notifications are contractual obligations rather than courtesies. | Sets the routing so a notification becomes a ticket rather than an unread message. |
| Run the quarterly reconciliation | Answers questions about configuration changes their team made. | Owns. Produces the dated record with the four inputs, the differences found and where each went. | — | Designs the runbook and the record format, because the record is what the auditor samples. |
| Act on a fired trigger | Owns the decision to continue, change or stop the use. | Owns the reassessment and re-derives the tier where a triggering attribute moved. | Assesses whether your own downstream disclosure or notification obligations have started. | Runs the reassessment to the same standard as the original, so the file does not thin out over time. |
| Accept an exception | Requests it, and supplies the business consequence of refusing. | Owns the compensating control and the tier cap the gap imposes. | Confirms whether the gap is one you are permitted to accept given commitments you have already made downstream. | Drafts the exception record, including the expiry date and the second-review rule. |
| Deprovision and confirm deletion | Requests removal, or the review finds the deployment disused. | Owns. Confirms the credential was revoked at the source and the deletion certificate was received — not merely that the register entry was closed. | Checks the exit clause was performed, including on Derived Artefacts. | Writes the step into the offboarding and review routines so it is not a one-off act of diligence. |
| Produce evidence at audit | Answers interview questions about their own supplier and its use. | Owns the population and the reconciliation that makes it defensible. | Produces the executed agreements and the clause references the register points at. | Prepares the evidence and coordinates with the examining firm. Does not test, and does not opine. |
Turnaround, silence and who accepts the risk
A matrix without a service level is a diagram. Publish three numbers and hold to them. Tier 3 confirmed within two working days, fast enough that nobody is tempted to skip it. Tier 2 decided within ten working days of a complete request, the clock starting when the artefacts arrive rather than when the request is raised, so chasing a vendor does not burn your own service level. And Tier 1 taken at the next governance forum, its date published a quarter ahead so a request can be timed against it.
Then say what happens on silence, because the argument running through this page is that changes nobody observes get treated as permission. An unanswered Tier 3 request is approved by default and logged as such: the risk is small, and a process that stalls on low-consequence requests trains people to stop using it. An unanswered Tier 2 or Tier 1 request is not approved, and escalates to the named deputy after the window and to the forum after twice it. Default-approve where being wrong is cheap, default-escalate where it is not, and never leave a category in which silence and approval look identical from outside.
Residual risk is accepted by a person rather than a body, at a level matching the tier: the business owner at Tier 3, security at Tier 2 with legal joining where personal data is in scope, and at Tier 1 the accountable executive for the affected process, by name and explicitly not the forum collectively — a forum can advise, minute and challenge, but a decision owned by everyone present is one nobody can be asked about afterwards. Three things escalate a decision one level regardless of tier: a requested exception to a red-line term, a security-versus-business disagreement that survives one conversation, and any reassessment that would move the tier upward.
The first ninety days, in order
For an organisation with none of this, the sequence matters more than the tooling, and it is not negotiable in one respect: the rule comes before the list. The last column is the one that repays the most attention — each of those is a way of doing the right steps in an order that wastes them.
| Days | Step | Who owns it | Deliverable that must exist at the end | Where teams get it wrong |
|---|---|---|---|---|
| Days 1–5 | Publish the tiering rubric | Security, signed off by whoever accepts risk at Tier 1 | The seven attributes, the combination rule, and the depth each tier requires — written before any supplier list exists. | Writing it after the list. A rule reverse-engineered to fit the tools you already have is the first thing an assessor unpicks, and it cannot be defended in an interview. |
| Days 1–5 | Freeze the record schema | Security, with legal on the contractual fields | The thirteen field definitions with allowed values and an evidence standard for each, in a system that keeps version history. | Adding fields that would be interesting. Every field nobody maintains reduces confidence in the fields somebody does. |
| Days 6–15 | Build the population from four independent sources | Finance supplies the ledger and expense data, IAM supplies the grants, and security runs the feature review | A candidate list with a source column on every row, so a later completeness argument has something to stand on. | Starting with the suppliers you already know about. That inversion is what kills the exercise — the whole value is in the ones no register holds, and a list seeded from the register can only confirm itself. |
| Days 16–30 | Tier the population | Security, with the business owner supplying attributes and legal answering the regulated-process question | A tier and a basis on every candidate, with most of the population at Tier 3 and that fact treated as a correct result. | Escalating everything to look rigorous. A process that demands an impact assessment for a transcription tool teaches people to route around it, and it stops operating inside a quarter. |
| Days 31–60 | Build files for Tier 1 and Tier 2 only | Security owns the read, legal owns the terms, and the business owner chases the vendor | Artefacts obtained and read first, configuration captured second, for the tiers that warrant it. Tier 3 gets a register entry and nothing more. | Collecting artefacts for everything. Volume at this step is what makes the whole programme collapse under its own weight before it reaches the suppliers that matter. |
| Days 61–75 | Wire the triggers so they can fire | Security, with the subscriptions pointed at a role-owned queue | Change-feed subscriptions recorded as a field, and every date field populated — certificate expiry, report period end, renewal date, trial expiry, next review. | Subscribing an individual. The notifications go to someone who leaves, and the absence is invisible because subscription state was never a field. |
| Days 76–90 | Run the first reconciliation | Security, reviewed with each business owner | A dated reconciliation record whose output is treated as the baseline rather than as a set of findings to be argued about. | Treating the first run’s differences as failures of the people involved. The first reconciliation always finds drift. Punishing it is how you guarantee the second one is less honest. |
One inversion kills this more reliably than any other: starting with the suppliers you already know about. A population seeded from the register can only confirm the register, and the suppliers worth finding are by definition the ones no register holds — the tool bought on a card, the connector a user authorised against their corporate account, and the AI feature that arrived inside a product you have owned for three years. Build the population from sources the register owner does not control, and accept that the count coming out of days 6 to 15 will be larger than the count going in. That is the exercise working.
A good file, and the two changes it missed
An illustrative composite, not a client. The point of the example is that the onboarding file was genuinely good — better than most — and still could not answer the question it was asked five months later, because both changes happened outside the thing the file was about.
| Onboarding | 14 Jan 2026 | A 400-person B2B software company approves a document-intelligence supplier for contract summarisation. The file is complete and good: current SOC 2 Type 2 for the period ended 30 September 2025 with a bridge letter covering the gap to signature, ISO 27001 certificate in scope, DPA executed with an AI addendum stating no training on inputs, sub-processor list with the cloud provider and one model provider named. Tier 2. Named owner in legal operations. Next review 14 January 2027. |
| The silent change | 3 Mar 2026 | The supplier adds a second model provider for capacity and updates the sub-processor page. Notice was by website update, because the notice-period clause had been struck during negotiation as boilerplate. Nobody is subscribed to the page. Inside the buyer’s environment nothing changes: same interface, same outputs, same invoice. |
| The tier change | 28 Apr 2026 | The supplier ships a workflow feature that files summaries directly into the buyer’s contract repository over an API token. An administrator enables it in twenty minutes because it is obviously useful. The product has crossed from assistive to acting, and nothing in the buyer’s process observed the crossing, because the vendor did not change and the file is about the vendor. |
| Detection | 11 Jun 2026 | A customer security review asks the buyer to list every sub-processor with access to their contracts. Reconciling the answer against the supplier’s current page surfaces the March addition. The buyer’s own disclosure to that customer has been incomplete for more than three months, and the buyer learns it from the customer’s questionnaire rather than from any control of their own. |
| Scoping | 11–19 Jun 2026 | Three questions, answered in this order. Which customers’ material was processed after 3 March. What the second model provider’s terms say about retention and training for the tier the supplier is on — a question the buyer can only ask through the supplier. And whether the buyer’s own sub-processor disclosure obligations were triggered, which they were, by the flow-down clause in two of their enterprise agreements. |
| Remediation | 24 Jun – 31 Jul 2026 | The notice clause is reinstated by amendment with a thirty-day period and a termination remedy. The configuration record gains three fields it did not have: tool and write capability, connector inventory, and the subscription state for the supplier’s change feed. A quarterly reconciliation is added between the supplier register and each supplier’s published sub-processor page. The workflow feature is re-reviewed at Tier 1 and the write path is put behind an approval. The buyer also writes to the two customers whose flow-down clauses had been running since March — naming the date, the entity, the exposure and the two new controls, before either customer asks a second question. |
| First reconciliation | 2 Sep 2026 | The new control runs for the first time, across nine AI-touching suppliers, and takes about an hour. Four inputs captured and dated: the register export (9 records), each supplier’s sub-processor page, the terms applicable to each plan tier, and each tenant’s own configuration. Three differences. Two are recorded changes — a notified sub-processor addition already assessed in August, and a retention setting the buyer itself had changed. The third is an unrecorded change on a different supplier: a web-access feature enabled by default in a July release, reaching a data source nobody had assessed. It is raised as trigger four, the tier is re-derived, and the feature is switched off pending review. The record names the reviewer, the date, the scope, the three differences, their classification and where each went. |
| At fieldwork | 18 Sep 2026 | The CPA firm tests the vendor-risk control across the period. The population is 34 suppliers, 9 of them AI-touching. The March change is disclosed, along with the gap from 3 March to 11 June and the control that now exists to close it. The auditor spends more time on that one supplier than on the other 33 combined — a change detected, scoped and remediated inside the period is the most informative artefact in the file. |
Read the two changes against each other, because they fail in different ways. The March change was contractual and invisible. A notice clause struck as boilerplate during negotiation is the reason it arrived by website update, and the reason nobody was subscribed is that there was nothing to subscribe to. This is the failure a clause prevents, and it is why the sub-processor term is one of the two worth fighting for.
The April change was configuration and entirely inside the buyer. No supplier changed, no contract changed, nothing was purchased. An administrator enabled a feature that moved the deployment from producing summaries for a person to writing into a system of record over a token, which is a different risk class assessed under a different tier. Nothing in a vendor-shaped process observes that, which is the structural argument for putting connector and tool capability in the register as a field with its own review, rather than treating it as a detail of the product.
Two things about the detection are worth naming. It came from a customer rather than from a control, which is the most expensive way to find anything — and it was found by a reconciliation the buyer could have been running all along. And the buyer’s own disclosure obligation to two of its customers had been live the whole time, which converts a supplier-management lapse into a contractual breach of the buyer’s own. Once your contracts pass the obligation through, the gap between a supplier changing and you knowing is no longer the supplier’s problem.
The file was about a company. Both of the things that changed were about a plan and a configuration, and neither produced an event anybody in the organisation would have seen.
Eleven triggers, only one of which is the calendar
Annual review is a reasonable floor and a poor ceiling. AI suppliers change materially between cycles — models, sub-processors, capabilities, tiers — and almost none of those changes produce an event inside your organisation. Read the second column first: it is the honest account of how you would actually find out. Then read the last one, which is what each miss looks like on paper twelve months later — because a trigger that never fired is not an absence in the file, it is a specific artefact with two dates on it that do not reconcile.
| Trigger | How you would learn about it | What you reassess | The clock | What the miss looks like at fieldwork |
|---|---|---|---|---|
| A new sub-processor or model provider is added | The vendor’s change feed, if you subscribed. A contractual notice, if you kept the clause. Otherwise a quarterly reconciliation between your register and their published list, which is the control that catches it when the first two fail. | The new entity’s terms on retention and training, the processing region, whether your own downstream disclosure obligations are triggered, and whether any customer agreement gives you an objection right you should exercise. | Your notice period if you have one. Your own flow-down disclosure obligations may run from the change taking effect rather than from your awareness of it, which is why the reconciliation cadence matters. | A register entry whose sub-processor snapshot is dated at onboarding, with no successor snapshot, sitting beside a vendor page that lists an entity the register has never held. The auditor does not have to find the change. They compare two dates. |
| The default model changes, or a version is deprecated | A release note, a changelog entry, or — most often — a user reporting that outputs feel different. This is the trigger with the worst detection story in the whole list. | Every evaluation result you hold, because each was produced against a version. Prompt behaviour, output format stability, anything downstream that parses the output, and the residency and retention answers if the new model routes differently. | The deprecation window, which is frequently shorter than a re-evaluation cycle. Pinning a version is what buys you the time, and it is a contract term rather than a setting on most tiers. | An evaluation record produced against a model version, and a register with no version field and no notice clause — so nothing in the file can say whether the evaluated system is the one that ran during the period. |
| Your plan tier changes, in either direction | Procurement, at renewal — or silently, when a trial converts, a seat count crosses a threshold, or a vendor consolidates tiers. | Everything on the divergence table. A downgrade can remove a contractual training-data commitment, shorten log retention below your evidence requirement, or withdraw a residency option, and none of those produce a visible event in the product. | Before the change takes effect, which means the register has to know the renewal date. This is the single cheapest trigger to automate and the one most often missed. | A renewal date in the contract and no renewal date in the register, on a supplier whose plan changed mid-period. The tier commitment in the file describes a plan that stopped applying in March. |
| A new capability ships, or is auto-enabled | The product changelog and your own administrative console. Features that arrive enabled by default are the dangerous ones, and web-access, connector and agentic features have all shipped that way. | The configuration record, the data the feature can reach, and whether the deployment has crossed from producing text to taking action. If it has, it is a different risk tier and needs re-approval rather than a note. | Immediate. A capability that reaches new data sources changes your exposure the day it is enabled, not at your next annual review. | A connector inventory written at onboarding, and a platform export taken at fieldwork that lists a source the inventory does not. The gap between the two dates is the period over which the control did not operate. |
| The processing region or residency configuration changes | A contractual notice, a settings change, or a capacity event that moved processing without a notification anybody read. | Transfer mechanisms, customer commitments naming permitted locations, and any sector residency expectation you are subject to. | Immediate where a customer contract names locations, because the breach is of your agreement and not of theirs. | A residency commitment recorded once, with no verification date, on a tenant whose configuration the auditor can read directly. Where the two disagree, the register is the document you asserted was accurate. |
| A certification lapses, or a report period ends | The expiry and period-end dates in your own register, which is the point of recording them. Suppliers rarely announce a lapse. | Whether the gap is a delay or a withdrawal, whether a bridge letter covers it and what a bridge letter actually asserts, and whether a certification body changed or a scope narrowed at renewal. A scope that quietly shrank is more common than a certificate that lapsed. | Within the review cycle for a delay. Immediately for a withdrawal or a narrowed scope, because both change what your own file is relying on. | A certificate in the file with an expiry inside the period and no review record after it, or a scope statement from two renewals ago attached to a current certificate number. |
| The supplier is acquired, or changes contracting entity | Press coverage, a notice of assignment, or a new entity name on an invoice. The invoice is frequently the first signal that reaches anybody. | Whether the DPA and security addendum survive assignment, whether the sub-processor list changes as stacks consolidate, whether residency options change, and whether your own customers must be told. Assurance artefacts are often re-issued under the acquirer over the following year, which resets scope questions you had already settled. | At notice of assignment where the contract gives you a right. Otherwise at the next review, with a specific check on entity names in the agreement. | Agreements in the name of an entity that no longer exists, a register unchanged, and invoices from the acquirer for the second half of the period. |
| A security incident at the supplier | Their notification, if the clause exists and they honour it. Otherwise public reporting, which means you learn it at the same time as your customers. | Whether your data was in scope, what their notification actually said and what it omitted, whether your own notification clocks have started, and whether the incident reveals a control weakness that changes the tier. | Your own statutory and contractual notification clocks, which run from your awareness. Under GDPR the supervisory authority clock is 72 hours from becoming aware of a personal data breach, and under the DPDP Act 2023 a Data Fiduciary must intimate the Data Protection Board and each affected Data Principal in the prescribed form and manner. | A supplier incident in public reporting during the period, with no entry in your own incident log and no reassessment record — which converts a design question into an operating one. |
| An incident or near-miss in your own use of the product | Your incident process, a user report, or a monitoring alert — provided the deployment is monitored at all. | Whether the cause sits in the supplier, the configuration or the use. The third is the most common and the one least likely to be attributed correctly, because a supplier is a satisfying place to put a cause. | Inside the incident, not after it. A supplier-attributable cause changes the vendor file and belongs in it while the detail is still available. | An incident record attributing a cause to the supplier, with no corresponding update to the supplier file, so the organisation learned something and the control did not. |
| A material change in how you use it | Your own use-case register, if the product gained a new purpose, a wider data class, a larger audience or a new connector. | The tier first. A supplier approved for internal drafting and now summarising customer contracts has not changed, but your exposure has, and the diligence depth should follow the use rather than the vendor. | Before the new use goes live, which is the only point at which the answer can still change the design. | An approval record for internal drafting, and a use that by the period end reaches customer contracts. The tier in the register was never re-derived, and the rationale column shows the original attributes. |
| Nothing at all — the calendar | The review date in the register. | The artefact set for currency, the configuration record against the live tenant, and the sub-processor list against your last snapshot. Most annual reviews find one drift of consequence, and the configuration drift is more common than the contractual one. | Annual for Tier 2 and Tier 1, with Tier 1 also carrying a mid-year configuration check. Tier 3 is a confirmation rather than a review. | A review column carrying one identical date across every supplier, or a cadence with quarters missing. Both read as a bulk update rather than a review, and the sample will land on one. |
Three mechanisms that make the triggers fire
A trigger list is a wish until something causes it to operate, and there are only three mechanisms that reliably do. Dates in the register handle the calendar triggers and the artefact ones: certificate expiry, report period end, renewal date, trial expiry, next review. Each of those is a field that can raise a task without a human remembering, and recording them is the cheapest control on this page.
Contractual notice plus subscription handles the vendor-initiated ones, and it has two halves that are usually done badly in combination: the clause is negotiated and nobody subscribes to the feed, or somebody subscribes and the notifications go to an individual who leaves. Point the subscription at a shared mailbox or a ticket queue owned by a role, and record the subscription state as a field so the absence is visible.
A periodic reconciliation handles everything the first two miss, which on self-serve tiers is most of it. It runs quarterly for every AI supplier above Tier 3, it is about an hour for a portfolio of a dozen, and because it produces a dated record with a reviewer and an outcome it is the artefact that evidences the whole ongoing-review control. It is specified below rather than described, because a control this load-bearing should not depend on whoever wrote it being the one who runs it.
The reconciliation, as a runbook rather than an instruction
“Compare the register against their published position” is a sentence, not a procedure, and the difference shows up the first time somebody other than its author runs it. Four inputs, each obtained the same way every quarter so the comparison is mechanical rather than interpretive.
| Input | Where it is obtained | The comparison performed |
|---|---|---|
| Your register export | A system-generated export filtered to AI suppliers above Tier 3, carrying the query used, the source system, the run date and the record count. Export it first, so the rest of the exercise is compared against a fixed baseline rather than against a register that moves while you work. | Nothing yet — this is the baseline. Its completeness is a separate question answered by the four discovery sources, not by this reconciliation. |
| The supplier’s published sub-processor list | The vendor’s live page, captured with the date you captured it and stored rather than linked. A link records where the answer was. A capture records what it said. | Entity by entity against your last snapshot. Additions, removals and renames all count — a rename is frequently a consolidation, and a removal can mean a function moved in-house or moved somewhere undisclosed. |
| The supplier’s current terms and trust pages | The terms applicable to your plan tier, not the default set, plus any AI-specific or product-specific terms that sit outside the master agreement. | Against the clause references recorded in your register. You are checking whether the position your file cites still says what your file says it says, which is a different question from whether the vendor announced a change. |
| Your own tenant configuration | The admin console: the model list, the enabled features and connectors with their scopes, the retention settings, the residency setting, and the audit-log window. Exported, not described. | Against the configuration fields in the register. This is the input that finds the April-style change — the one nobody purchased, nobody announced, and an administrator enabled in twenty minutes. |
Every difference the comparison surfaces falls into one of four classes, and the class decides what happens next. Classifying is the step that stops a reconciliation becoming a list of observations nobody acts on.
| No change | Every compared value matches the register. | Record the date and the reviewer against the supplier. A reconciliation that finds nothing is still evidence the control operated, but only if it left a record. |
| Recorded change | A value moved and your file already knew — a notice was received, assessed and the register updated. | Confirm the register reflects it and that the assessment record exists. Close. These are the ones that demonstrate the notice-and-subscription mechanism working. |
| Unrecorded change | A value moved and nothing in your file knows. The March addition in the worked example is this class. | Raise the corresponding trigger, run the reassessment, and answer the second question immediately: whether your own downstream disclosure or notification obligations have been running since the change took effect. Record the detection date and route, because the interval between the change and the detection is the thing that gets tested. |
| Unrecordable | You cannot determine the current value — the vendor publishes nothing, the console does not expose it, and no clause entitles you to ask. | This is an exception, not a finding, and it goes to the exception record below with a named accepter, a compensating control and an expiry. What fails is leaving the field blank, because a blank field reads at fieldwork as a control that did not operate rather than as a risk somebody consciously accepted. |
Then record the run itself, because the reconciliation record is the artefact your auditor samples — not the register it was run against. Seven fields: reviewer, run date, suppliers in scope and how that scope was derived, the four inputs with their capture dates, the differences and their classification, where each one went, and a sign-off. A quarter with no differences is recorded as exactly that, which is a result. A quarter with no record is indistinguishable from one in which nothing happened.
Exceptions, which are the normal case rather than the edge
Read this page’s own admissions together and the conclusion is unavoidable. On a self-serve tier you negotiate nothing. Evaluation results are rarely produced in a form you can rely on. Two of the five layers are contractually out of reach. Most real files therefore carry a gap somebody consciously accepted, and a process with no structure for that produces either dishonest files or stalled ones. Give the exception its own record.
| Supplier and deployment | The register ID and the specific deployment, because the same supplier can carry an exception on one use and not on another. |
| The artefact or term that is absent | Named precisely — "no breach-notification obligation", not "limited contractual coverage". An exception you cannot state in one sentence is one nobody will be able to review. |
| Why it is unobtainable | The supplier declined, the tier does not offer it, or no mechanism exists. The three have different prospects at renewal, which is why the distinction is recorded rather than flattened. |
| Compensating control, if any | What you do instead, and honestly nothing where there is nothing. A compensating control that exists only in the exception record is worse than an admitted gap. |
| The tier cap the gap imposes | The ceiling this exception sets on use. A supplier with no breach-notification obligation does not carry Tier 1 work, and a supplier with no training-data clause does not receive customer data. The cap is the control. |
| Named accepter | A person, at the level that tier requires — the business owner at Tier 3, security at Tier 2, the accountable executive by name at Tier 1. Not a forum, and not a role with nobody in it. |
| Expiry date | Every exception expires. An exception with no expiry is a policy change made by one person without anybody agreeing to it. |
| Review outcome and renewal count | What happened at each review, and how many times it has been renewed. The count is the field that makes the second-review rule operable. |
One rule keeps the register from filling up with permanent exceptions wearing temporary clothes. An exception renewed unchanged twice is a decision to live with the gap permanently, and it should be re-accepted one level higher than it was first accepted rather than rolled forward by whoever is running the review. That is not bureaucracy for its own sake: the second renewal is the point at which a temporary accommodation has become the organisation’s actual position, and the person who would have to defend that position should be the one who chose it. The alternative is a register in which nothing is ever refused and nothing is ever fixed.
One trigger deserves separate treatment because its consequences are the widest. A model change invalidates evaluation evidence, and on most tiers you will find out from a changelog or from a user saying outputs feel different. What to reassess, how to decide whether a change is material, and how to run regression testing at a scale that is actually sustainable is the subject of when a model changes, what do you reassess. The related discipline on your own side — keeping a record of what the system actually did — is covered in AI agent monitoring and audit logs.
What the CPA firm actually requests
Teams expect to be asked for their vendor assessments. What they are asked for first is a population, because a sample drawn from an incomplete list proves nothing about the list it came from. For AI suppliers the completeness question is unusually hard, since a meaningful share of them were never purchased through procurement at all.
| The request | What satisfies it | What gets rejected |
|---|---|---|
| Define the population of AI suppliers | A system-generated export of the vendor register with a run date and a record count, reconciled to sources the register owner does not control: the accounts-payable ledger, the identity provider application and OAuth grant list, and the expense system. The reconciliation is the evidence. The register alone is an assertion. | A hand-maintained spreadsheet offered as the population. A register that omits a supplier visible in the expense records — which is the reconciliation the auditor will actually run, and the one that finds the tool bought on a card. |
| Evidence diligence was performed before use began | For sampled suppliers, the completed assessment with a date preceding first use, the artefacts held at that date, the reviewer, and the approval with a decider who is not the requester. | An assessment dated after the first invoice. Requester and approver as the same account. An assessment referencing a report the organisation cannot produce. |
| Evidence the tier and depth were applied as designed | The tiering criteria as documented, the tier assigned to each sampled supplier with its rationale, and evidence that the deeper requirements were actually performed where Tier 1 was assigned. | Every supplier at the lowest tier. A tier assigned with no recorded rationale. A Tier 1 supplier with a Tier 3 file, which is the most common finding on this control. |
| Evidence the ongoing review operated at the stated cadence | The review record for each occurrence in the period, with the reviewer, the date, what was checked, what changed and what was concluded — including at least one review that found something and did something about it. | A review column populated with a single date for every supplier, which indicates a bulk update rather than a review. A cadence with months missing. A review that has never found anything. |
| Evidence a trigger-based re-review actually fired | A recorded instance — a sub-processor addition, a model change, a certification lapse — with the detection date and route, the reassessment performed, and the decision taken. One real instance evidences the control better than a documented procedure with no instances. | The procedure alone. A change that the organisation demonstrably knew about, with no corresponding record, which converts a design observation into an operating one. |
| Evidence complementary user entity controls were implemented | For each sampled supplier whose report lists CUECs, an identification of the applicable CUECs and evidence of the corresponding control operating in your environment. | A report obtained and filed with no evidence that anyone read the CUEC section. This is the most frequently skipped step in vendor review and the one auditors most reliably test. |
| Evidence the configuration position is current | The configuration record with a verification date inside the period, and for at least one supplier a screenshot or export from the live tenant matching what the record claims. | A record whose retention and training entries were populated at onboarding and never re-verified, on a product that has shipped materially since. |
Two pieces of vocabulary make this easier to follow. What the auditor is establishing about any list you export is its completeness and accuracy, and the artefact class has a name: information produced by the entity, usually shortened to IPE. That is why the query, the source system, the run date and the record count have to travel with the register export rather than being reconstructed afterwards. Sample sizes then behave as they do everywhere else in a SOC 2 examination: a small population is usually tested in full, so a register of nine AI suppliers is nine tests and a single missing approval is a deviation rate of more than a tenth with no sampling risk to absorb it.
Where this maps in the frameworks you already run
None of this is a new control set. It is the vendor control you already have, carrying the fields the AI case makes necessary. Read the third column as the answer to “why does the register need that field” — the question asked every time somebody proposes trimming the schema.
| Requirement | Reference | Fields that serve it | What satisfies it |
|---|---|---|---|
| Assessing and managing risks associated with vendors and business partners | SOC 2 trust services criteria, CC9.2 | Tier and its basis · artefacts held · owner and review date | The assessment for each sampled supplier, dated before first use, with the approval by someone other than the requester and the tier recorded with its attributes. |
| Risk mitigation activities for risks arising from business disruption, including supplier failure | SOC 2 trust services criteria, CC9.1 | Contract terms — exit and transition · models available | The written exit position for Tier 1 suppliers, and the concentration query showing which suppliers resolve to the same model provider. |
| Operational planning and control of the AI management system | ISO/IEC 42001:2023, clause 8.1 | Tier and its basis · tool, action and write capability | The tiering rubric as published, plus evidence the deeper requirements were actually performed where Tier 1 was assigned. |
| Allocating responsibilities across the AI value chain | ISO/IEC 42001:2023, Annex A.10.2 | Supplier legal entity · tool, action and write capability · administrative access | The responsibility matrix, plus the record of which complementary user entity controls from the supplier’s report you identified as yours and where each operates. |
| Suppliers — ensuring responsible AI expectations reach the supply chain | ISO/IEC 42001:2023, Annex A.10.3 | Training-data position · retention settings · processing region · artefacts held | The executed AI addendum with clause references, and the sub-processor list with its subscription mechanism and capture date. |
| Customers — what you commit downstream about AI in your own service | ISO/IEC 42001:2023, Annex A.10.4 | Training-data position · processing region · supplier legal entity | Your own sub-processor disclosure, reconciled to the register, with the date of the last reconciliation. |
| Responsible use of AI systems within the organisation | ISO/IEC 42001:2023, Annex A.9.2 and A.9.4 | Tier and its basis · connectors enabled · owner | The use-case approval separate from the supplier approval, naming the intended use and the uses declared out of scope. |
| Policies and procedures addressing AI risks from third-party entities | NIST AI RMF 1.0, GOVERN 6.1 | Tier and its basis · artefacts held · contract terms | The documented diligence procedure with its tiering rule, and completed assessments demonstrating it was applied as written. |
| Contingency processes for failures or incidents in third-party AI systems | NIST AI RMF 1.0, GOVERN 6.2 | Contract terms — incident notification and exit · owner and deputy | The incident notification clause with its outer limit, and at least one recorded instance of a trigger firing and being acted on. |
| Responsibilities along the AI value chain | Regulation (EU) 2024/1689, Article 25 | Supplier legal entity · tier and its basis · tool, action and write capability | The role determination for the deployment — provider or deployer — with the reasoning, since modifying or rebranding a system can move you along that spectrum. |
| Obligations of deployers of high-risk AI systems | Regulation (EU) 2024/1689, Article 26 and Article 14 on human oversight | Tier and its basis · audit log window · tool, action and write capability | Where the deployment is in scope: the oversight design tested rather than described, and the log retention shown to cover the period you are required to keep. |
| Engaging a sub-processor only with authorisation, and on equivalent terms | Regulation (EU) 2016/679, Article 28(2) and 28(4) | Artefacts held — sub-processor list · contract terms — notice and objection | The authorisation mechanism in the DPA, the notice period, and the flow-down obligation binding each sub-processor to equivalent terms. |
| Engaging a Data Processor only under a valid contract | Digital Personal Data Protection Act, 2023, section 8(2) | Supplier legal entity · artefacts held — DPA version and date | The executed contract, producible on request. Acceptance of online terms in a signup flow that nobody can produce a copy of does not satisfy it. |
Two rows are most often missed. The EU AI Act rows apply only where a deployment is in scope, and the first question is the role determination rather than the control — Article 25 exists because modifying, rebranding or putting your own name on a supplied system can move you from deployer toward provider, which is a question about what you did to the product rather than what you bought. And GDPR Article 28 is usually cited at the level of the article, but the sub-processor chain lives in 28(2) and 28(4), the pairing that creates the flow-down obligation rather than merely the written-contract one.
Completeness is where most of the difficulty sits, and the four discovery sources in the ninety-day sequence above are what an auditor will reconcile your population against. Note which one carries the category the others cannot reach: a review of your existing suppliers’ feature releases, which finds the AI capability that appeared inside a product you already own, at no additional cost, under an agreement signed before the feature existed. That one has no financial footprint and no OAuth grant, so no export will ever surface it.
An ISO/IEC 42001 certification audit asks a different set of questions about the same subject matter. The certification body examines a management system — the AI policy and who approved it, the roles assigned, the inventory of AI systems and how it is kept current, how impacts are assessed, how third parties and suppliers are managed under Annex A.10 — while the CPA firm expresses an opinion on control effectiveness over a period. Much of the underlying evidence overlaps, but the framing and the deliverable do not. Certificates are issued by accredited certification bodies, SOC reports by licensed CPA firms, and integrating the two management systems is a separate exercise from mapping their evidence. TCSA does the readiness, control design, evidence preparation and coordination on both sides of that line. TCSA does not certify, attest, audit or sign — those belong to the certification body and the CPA firm respectively, and the separation is what makes their output worth something. More on the mechanics in the evidence collection guide.
The cases that produce genuine disagreement
The design above covers the common cases. These are the situations where reasonable people inside the same organisation reach different answers, and where settling the position in advance is worth several days later.
The supplier who will not share the report
Some vendors, particularly the largest, decline to provide a SOC 2 outside a customer relationship or behind a portal with terms you would rather not accept. Three workable moves. Ask what they will provide — many will share a scope statement, a certificate, a bridge letter or a completed questionnaire even when they will not release the full report. Ask whether provision is available post-signature and write the obligation into the agreement, so the next annual review is not a negotiation. And where genuinely nothing is available, take it to the exception record above rather than leaving the field blank. What fails is quietly treating a refusal as a pass.
The supplier who is themselves a reseller of a model
A great many AI products are thin applications over a frontier model, and the diligence question is which layer carries which obligation. The application vendor owes you the DPA, the notice periods and the security commitments, and they are the only party you can negotiate with. But the retention, training and residency answers are frequently the model provider’s answers restated, and restated from the tier the application vendor holds rather than from the one you assume. Ask the application vendor to state which model provider tier they are on and what it permits, and to commit that any change to that arrangement is a notifiable sub-processor change. A vendor who cannot answer that question has not read their own upstream agreement, which is itself the finding.
The model provider is also your cloud provider
Where inference runs inside a hyperscaler’s own AI service, the assurance picture improves in one respect and gets murkier in another. The hosting layer is well documented and the shared-responsibility split is published, which is genuinely helpful. But the service-specific terms — whether prompts are logged, whether abuse monitoring applies, whether the region commitment covers safety classification — vary by service and by region within the same cloud, and the umbrella agreement you already signed may not be where those terms live. Read the service-specific terms, not the master agreement, and record the service name rather than the cloud’s name in your register.
Open-weights models run on your own infrastructure
Self-hosting removes the processor relationship and with it most of this page — no DPA to negotiate, no sub-processor list, no retention term, because the data never leaves. It does not remove supplier diligence. It relocates it. The questions become licensing terms and whether your intended use is permitted by them, the provenance and integrity of the weights and where you obtained them, the security of the serving stack, and the fact that you have now taken on the evaluation, monitoring and change-management obligations the vendor was performing invisibly. In management-system terms you have moved along the role spectrum from deployer toward provider, which changes which obligations attach to you rather than reducing their number.
The free tool that arrived inside a product you already bought
The most common unreviewed AI supplier in any organisation is not a new vendor at all. It is an assistant that appeared inside an existing SaaS product at no additional cost, enabled by default, under an agreement signed three years before the feature existed. There is no purchase order, no procurement event and no security review, because nothing was bought. The reconciliation that catches this is not financial — it is a periodic review of the AI features of your existing major suppliers, asking for each whether an AI capability now exists, whether it is on, what it reaches and whether the original agreement addresses it. Organisations that run this review for the first time are routinely surprised by the result.
Concentration on a single model provider
Diligence is usually written as a per-supplier exercise, which makes the portfolio question invisible. If nine of your AI suppliers resolve to the same model provider two layers down, then a capacity event, a price change, a policy change or an outage at that provider is a correlated event across nine files that each look independently well managed. Record the model provider as a field in the register rather than only as a line in a sub-processor list, so the concentration is a query rather than a discovery. This is also the practical argument for the exit clause: concentration is only a risk you can act on if you have somewhere to go.
The proof-of-concept that became production
A trial signed under click-through terms, with no DPA, no negotiated notice period and a consumer or self-serve tier, becomes the production system because it worked and nobody was watching the transition. The diligence file, if one exists, describes a pilot with synthetic data. Two guardrails work: put an expiry on every trial approval so it has to be positively renewed rather than allowed to persist, and make the transition from trial to production a named event in the process that requires the full assessment. The second matters more, because the transition is the moment the data class changes and it is almost never marked.
The auditor asks about a supplier you cannot reach
Where a sub-processor two layers down materially processes your customers’ data and you can obtain nothing about them, describe the position accurately rather than implying coverage you do not have. Your control is the contractual flow-down and the notice mechanism at the layer you contracted with. The deeper layer is covered by that vendor’s own diligence, which you rely on and have not tested. A narrower control described precisely tests clean. A vendor-management control described as covering the full supply chain, in an organisation that cannot name the inference provider, produces an exception on your own words.
The fifth of those — the AI feature that arrived inside a product you already bought — is also the bridge to the other half of this problem. Where an approved path is missing or thin, people use whatever is available under their own accounts, and the supplier register then describes a different organisation from the one that exists. That gap is the subject of shadow AI governance. Where you need someone owning this whose job is not also to be the person buying the tools, that is what a fractional CISO or DPO engagement is for.
When you are the AI supplier being diligenced
Everything on this page arrives back at you, usually in writing, usually from a buyer whose own counsel has read something similar. These seven are the ones a buyer working from a page like this one will put to you. The difference between a good answer and a defensive one is specificity, and in three of them a willingness to describe a limit rather than imply coverage you do not have.
"Which AI sub-processors have access to our data?"
Answer with a list, not a category. Name the application vendors, and for each of them name the model or inference provider behind it, because a buyer who has read this page will ask the second question immediately and a hesitation there undoes the first answer. State how you learn about changes — the contractual notice period, the subscription, and the reconciliation cadence that catches what the first two miss. If a layer is one you cannot see into, say so plainly and say what you rely on instead. The answer that damages the relationship is not an incomplete supply chain. It is a confident list that turns out to have been missing an entry the buyer found themselves.
"Is our data used to train AI models?"
The defensible answer names the tier, the clause and the date verified: on our agreement with each AI supplier, inputs and outputs are not used to train or improve models, and here is the clause. Two refinements make it stronger. Say what the commitment excludes — abuse monitoring and safety classification are common carve-outs and a buyer who discovers one later reads the whole answer as evasive. And say when you last verified it, because a verified position carries a date and an assumption does not.
"Your supplier changed their model provider. Why were we not told?"
This is the question the worked example on this page exists for, and there are only two honest answers. Either your contract carried a flow-down obligation and you met it, in which case point at the notification. Or it did not reach that far, in which case say so, say what you have changed, and say when. The recoverable version is specific: we learned it on this date through this route, we assessed the exposure in these terms, our disclosure to you was incomplete for this period, and here are the two controls that now exist. The unrecoverable version is a general assurance that supply-chain changes are managed.
"How do you know your AI vendors have not changed their terms?"
Describe the mechanism rather than asserting the outcome. Contractual notice obligations where you negotiated them and their periods. Subscription to change feeds where they exist. A scheduled reconciliation between your register and each supplier’s published position. And the register fields — certificate expiry, report period end, renewal date — that make a review fire on a date rather than on someone remembering. Then be honest about the residual: self-serve tiers change by website update, and the reconciliation is what covers them. A buyer can tell the difference between a mechanism and a reassurance in about one sentence.
"Do you hold ISO 42001, and do your AI vendors?"
Answer for yourself with the scope statement and the certification body, or say plainly where you are in the programme and what the timeline is. For vendors, the honest position is that 42001 certification is still uneven across the AI supply chain and its absence is not yet a disqualifier — so say what you do instead, which is the artefact set and the configuration record on this page. A buyer asking this question is usually testing whether you treat AI suppliers differently from other suppliers at all. Showing them the difference answers the question better than a certificate would.
"What happens if your AI supplier goes away?"
Availability and concentration, asked as a compliance question. The answer has three parts: whether the capability is essential to the service you provide them or an internal convenience, what the exit terms actually provide — export format, deletion confirmation, transition period, what happens to derived artefacts — and whether an alternative exists that you have assessed rather than assumed. Naming the model provider concentration yourself, before they find it, converts a weakness into evidence that you look at your portfolio rather than only at your files.
"Can you pass our AI requirements down to your vendors?"
Read the requirement before agreeing to it, because flow-down clauses drafted for classical processors frequently cannot be satisfied through an AI stack — a requirement to name and obtain consent for every sub-processor at every layer is not satisfiable against a supplier whose own upstream terms you cannot see. The productive response is to say which parts you can flow down today, which parts you can commit to on renewal, and which parts nobody in the market can currently meet. A supplier who negotiates that clause precisely is more credible than one who accepts it whole and cannot perform it.
A structural note on all seven. The answers that land are the ones that name a mechanism and a date rather than asserting an outcome, and that volunteer the limit before the buyer finds it. A supplier who says “we cannot see into that layer, and here is what we rely on instead” is more credible than one who implies visibility they do not have — and considerably more credible on the day the buyer checks.
Frequently Asked Questions
What is AI supplier due diligence?
Why does the plan tier matter so much for AI vendors?
What artefacts should we obtain from an AI vendor?
Does a SOC 2 report cover a vendor’s AI features?
Is an ISO 42001 certificate enough to approve an AI vendor?
How do we find out which model provider is behind our vendor?
What contract terms are specific to AI suppliers?
How often should AI vendor reviews be repeated?
Does the EU AI Act change what we have to do about AI suppliers?
What if a vendor refuses to share their SOC 2 report?
Does self-hosting an open-weights model remove the need for due diligence?
Who should own AI supplier due diligence?
Sources for this page
- ISO — ISO/IEC 42001:2023, artificial intelligence management system. The supplier and responsibility-allocation controls sit in Annex A.10, and the use controls sit under A.9.
- ISO — ISO/IEC 27001:2022, information security management system, for the certificate, scope statement and Statement of Applicability referred to above
- AICPA — SOC 2 and the trust services criteria, including the vendor and business partner risk criteria (CC9.2) and the treatment of subservice organisations
- NIST — AI Risk Management Framework (AI RMF 1.0), including GOVERN 6.1 and GOVERN 6.2 on third-party risk and on contingency for failures in third-party AI systems
- OWASP GenAI Security Project — Top 10 for LLM Applications, 2026 edition, published 4 August 2026 (Prompt Injection at LLM01 and Excessive Agency at LLM03, up from LLM06 in the 2025 edition)
- European Commission — regulatory framework for AI, covering Regulation (EU) 2024/1689 and the amendments made by the Digital Omnibus on AI, Regulation (EU) 2026/1744
- EUR-Lex — Regulation (EU) 2024/1689 (the AI Act), including Article 14 on human oversight for high-risk systems
- EUR-Lex — Regulation (EU) 2016/679 (GDPR), Article 28 on processors and the written contract requirement
- Ministry of Electronics and Information Technology — Digital Personal Data Protection Act, 2023, including section 8(2) on engaging a Data Processor under a valid contract
References checked September 2026. Two of these move faster than the rest of the page: the OWASP list renumbers between editions, and the EU AI Act’s applicability timetable has already been amended once. Cite the edition and the date, and confirm the current text before relying on anything quoted here. Vendor plan tiers, retention defaults, residency options and sub-processor lists change on their own schedule and without notice on self-serve tiers — verify those in the supplier’s current documentation and in your own tenant rather than against any example above.
Related Reading
When a Model Changes, What Do You Reassess?
The material-change test, the detection problem, and regression testing at scale.
Read moreMonitoring Agents That Work Unattended
Tool-call history is the load-bearing record. What must be captured for an action to be investigable.
Read moreGoverning Hundreds of Agents
Risk classes and inheritance instead of hundreds of individual assessments.
Read moreThe Ten Questions That Govern Any AI Agent
Scope, ownership, data, capability, identity, oversight, failure detection, evidence, reassessment and how to stop it.
Read moreISO 42001 Knowledge Hub
AIMS controls, EU AI Act mapping, risk assessment and guides.
Read moreISO 42001 (AI Management)
The world's first AI management system standard, for AI builders.
Read more