A subprocessor evidence checklist asks whether an AI vendor discloses the organizations that process customer data on its behalf, where that disclosure applies, and how updates are communicated. It is a document-review workflow, not a blanket privacy verdict. The useful result identifies the exact list and the questions a procurement or privacy reviewer still needs answered.
Primary sources checked on 8 October 2026. Worked examples and sample records below are illustrative; they do not represent product tests or real customer findings.
Define the product and customer relationship
Start with the product, plan, contracting entity, and processing route. A consumer assistant, enterprise workspace, and API service may have different terms and disclosures. A vendor’s cloud partner can also introduce another contractual layer. Write down which relationship your team intends to use before looking for a list.
Separate subprocessors from affiliates, integrations chosen by the customer, and model providers accessed through another platform. These labels have different meanings in documentation. Do not combine every company mentioned on a website into one presumed subprocessor list. Preserve the vendor’s classifications and ask the responsible reviewer to resolve uncertain relationships.
Locate the primary disclosure route
Search the vendor’s official privacy, legal, or trust center and follow its links. Anthropic’s commercial data-location article points readers to a subprocessor list in its Trust Center. That establishes a primary disclosure route, although the list itself may have access or rendering conditions. Record both the referring page and the destination.
If the destination cannot be inspected, mark the list access-limited rather than inventing its contents. A provider’s statement that a list exists is not the same as your verification of the current entries. Do not populate names from an old third-party article and label them current. Retain the access limitation and the route for an authorized reviewer.
Capture fields that support review
For an accessible list, record each disclosed organization, service purpose, location information, applicable product, and effective or observation date. Preserve the source terminology. A country where a service operates may not be the same as the storage location for your data. If the list uses broad regional language, do not turn it into a precise country guarantee.
Add columns for source URL, list version if available, notification mechanism, and unresolved questions. Keep the list separate from the vendor’s retention, training-use, and security claims. Those documents may be relevant to procurement, but the existence of a subprocessor list does not resolve them. The checklist should make the relationships visible without implying a completed privacy assessment.
Examine update and notification practices
Look for an official method to learn when the list changes, such as a trust-center feed or a contractual notification clause. Record how someone subscribes and which account role should receive notices. A public list that changes silently creates a different operational review need from a list accompanied by proactive notifications.
Do not infer notification rights from a generic marketing email subscription. Read the relevant documentation and agreement. Where a contractual process applies, have the responsible reviewer confirm the actual terms for your organization. The checklist can collect the evidence and identify the clause, but should not substitute an AI-generated interpretation for the organization’s approved contractual position.
Create a bounded evidence checklist
Use states such as official list located, entries inspected, product scope confirmed, update route identified, and review questions open. Assign evidence to each state. A single yes/no box labeled compliant hides too many distinct checks. A list can be public but stale, detailed but applicable to another product, or current but not accessible to the researcher.
In an illustrative review, the team locates an official trust-center route but cannot inspect all entries without access. The correct next action is an authorized access request or review by the account owner. It is not to conclude that the vendor refuses disclosure, and it is not to pretend the entries were verified. Keep the finding proportionate to the evidence.
Hand over questions to the right reviewer
Summarize the inspected documents, current list status, relevant product, and open questions about processing purposes or locations. Include short references to primary records and the check date. Ask the procurement or privacy owner to determine whether the disclosures meet the organization’s requirements. The research artifact should reduce their search work without making an unsupported legal conclusion.
Revisit the checklist when the plan, processing route, or vendor notification changes. Store the previously inspected list or manifest with the review history. When entries change, identify additions and removals explicitly rather than replacing the old file without context. A maintained evidence checklist makes supplier review repeatable and helps the organization respond to material changes.
Review and preserve the finished subprocessor evidence checklist
Before handing over the result, perform a review that starts from the evidence rather than the generated prose. Pick a clearly supported item, a disputed item, and an item with missing information. Write the expected treatment of each before reading the proposed conclusions. Then open the cited originals and compare the result with those expectations. Check the surrounding text, headings, dates, and qualifications, because a citation can point to the correct document while supporting a narrower statement.
Ask a colleague to use the finished deliverable without your explanation. They should be able to locate the original records, identify unresolved questions, and understand which statements are direct evidence and which are your interpretation. Revise any place where they must guess. Keep the reviewed output, source manifest, prompt, and correction history together. Record the review date and the event that should trigger another check. When a source changes, preserve the earlier assessment and explain which conclusions were affected rather than silently replacing the evidence.
Do not equate an empty result with the absence of a problem. Check that all intended inputs were included and readable. Explain exclusions and merged records. A useful handover makes incompleteness visible and assigns a next action to the person who can resolve it.
Frequently asked questions
Does a public list establish privacy compliance?
No. It is one evidence source within a broader product-specific and contractual assessment.
Are affiliates always subprocessors?
Use the vendor’s documented classifications and have uncertain relationships reviewed; do not merge labels automatically.
What if the list requires access?
Record the official route and access limitation, then use an authorized reviewer or access request.
Can I reuse a third-party list?
Use it as a lead, but verify current entries against the primary disclosure before labeling them current.
What should the checklist include?
Product scope, official list route, inspected entries, dates, notification process, and unresolved questions for the responsible reviewer.
