Foundation-model providers belong on your sub-processor register

Most AI SaaS companies have thought carefully about how they store and protect data at rest. Fewer have thought equally carefully about what happens during inference. When a customer's document, prompt or query travels across an API call to a foundation model provider, that provider is processing personal data or confidential business information on your behalf. In data-protection terms they are a sub-processor. In ISO 27001 terms they are a supplier with access to information assets in scope of your ISMS.

Both frameworks require you to document the relationship, assess the risk and have a contractual agreement in place. Enterprise buyers increasingly audit this, and the gap they find most often is not that the vendor chose a bad LLM provider - it is that the vendor has not formally mapped the relationship at all.

What makes an LLM API provider a sub-processor

A sub-processor is any third party that processes personal data on behalf of a data controller, under instruction from a data processor. If your product passes customer inputs - text, files, metadata - to an external model API, and those inputs could contain personal data, the API provider is processing that data on your behalf. The channel is HTTPS and the dwell time may be milliseconds, but the legal and compliance logic is the same as for any other cloud service that handles customer data.

The same logic applies to confidential business information that is not personal data. A law firm's client matter, a financial services firm's transaction narrative, a healthcare provider's clinical notes - these are assets the customer has placed in your custody. When you forward them to a third-party API, you are extending the trust boundary. ISO 27001 Annex A 5.19 requires you to assess information security risks in supplier relationships before the relationship starts, not after a buyer's questionnaire surfaces it.

What the register entry should contain

A sub-processor register is not a marketing-page list of the tools you use. It is a documented record that enables you and your customers to understand the data flows and the assurance in place. For each LLM API provider, the entry should capture:

The provider and the specific service. Not just "OpenAI" but which API endpoint category - completions, fine-tuning, embeddings. Different APIs may have different data retention terms.

The categories of data processed. What customer data could plausibly reach this API? If your product allows free-form input, the answer is probably "any data the customer chooses to submit, which may include personal data."

The purpose and legal basis. Why does this data reach the provider, and under what contractual basis are you sending it?

The data processing agreement. The DPA or equivalent terms that govern the provider's obligations. Most major providers publish these. You need a record that you have accepted them and that the version on record matches the one in force.

The assurance documentation. What security certifications or independent assessments does the provider hold? ISO 27001, SOC 2 Type II, and CSA STAR are common. You should record which were reviewed and when.

Data retention terms. What does the provider's contract say about how long it retains API inputs? Some providers retain prompts for abuse monitoring; others process in memory only. This varies by provider, by plan tier, and by whether you have signed a zero-retention data processing addendum.

Subprocessor notification mechanism. Most DPAs require data processors to notify customers before adding a new sub-processor. If your LLM provider changes - model upgrade, infrastructure change, regional routing - does your customer notification obligation trigger?

The assurance gap buyers find most often

An illustrative scenario: a procurement team at an enterprise financial services firm runs a security questionnaire against an AI analytics vendor. The questionnaire asks which sub-processors have access to customer data and what assurance documentation exists for each. The vendor lists the main cloud provider and the database service, both with current SOC 2 reports. The LLM API provider is not listed.

The buyer's security team follows up. The vendor confirms they use an LLM API for the core summarisation feature. When asked for the DPA, the vendor sends a link to the provider's general terms of service. The buyer asks for the zero-retention addendum. There is none - the vendor is on a standard API plan with standard data retention defaults.

This does not necessarily kill the deal. But it introduces a delay, requires remediation, and in some regulated sector deals it is a blocker until the vendor can produce a signed DPA with data retention terms the buyer's legal team accepts. The fix is not complicated - most major providers offer enterprise DPA terms - but discovering the requirement through a buyer's questionnaire is the most expensive way to learn it.

Keeping the register current

The sub-processor register is not a one-time exercise. Several things should trigger a review:

• A change in which LLM provider or model is used in production.
• A new product feature that sends a new category of data to the API.
• A provider's DPA or terms of service update.
• A customer's annual vendor review or contract renewal questionnaire.
• A change in the regulatory environment - national AI legislation, updated GDPR guidance on AI processors - that affects the legal basis for the processing.

Connecting the register review to your ISMS management review cycle is the most practical approach. Monthly or quarterly sub-processor spot-checks are appropriate if your product is actively evolving its AI infrastructure.

What auditors want to see

Under ISO 27001, supplier relationships fall primarily under Annex A controls 5.19 to 5.22. An auditor reviewing your supplier management will ask:

• Is the supplier relationship documented before processing starts?
• Is there a contractual requirement for the supplier to maintain appropriate security?
• Is the supplier's security performance monitored and reviewed?
• Are there records of the assessment?

A sub-processor register that includes LLM API providers, with current DPAs and dated assurance reviews, answers all four questions. A verbal confirmation that "we use OpenAI and they are obviously secure" does not.

Where Kellwick fits

Kellwick helps AI SaaS companies build sub-processor registers that hold up to enterprise buyer scrutiny - including the LLM API layer that gets missed most often. If you are preparing for ISO 27001 certification or working through a buyer's security questionnaire, see how we work with AI SaaS companies.