Subprocessor notification requirements in an AI vendor contract work on two levels: the law sets the minimum, and the contract sets the deadlines. GDPR Article 28(2) requires a processor working under general written authorisation to tell you about any intended addition or replacement of a sub-processor, and to give you the chance to object. The Regulation sets no notice period and says nothing about what happens after an objection, so the contract has to supply both. LLM vendors add a second gap. A standard SaaS agreement gives the customer no contractual way to learn that the model behind the product has changed. A clause worth signing therefore covers six things: who gets disclosed, what each notice contains, how long you have, what you can do if you refuse, where the live list sits, and model changes as a trigger in their own right.

Subprocessor notification requirements: what the law fixes

Article 28(2) bars a processor from engaging another processor without the controller’s prior specific or general written authorisation. Under general authorisation the processor has to inform the controller of intended changes, which gives the controller the opportunity to object. The UK ICO adds procedure: the processor sends proposed changes in writing with the date by which objections must be raised, and the controller replies in writing with its reasons. Whatever happens further down the chain, the initial processor stays fully liable to the controller for a sub-processor’s data protection failures.

EDPB Opinion 22/2024, adopted on 7 October 2024, raises the bar for what counts as a meaningful notice: enough detail and enough time for an informed objection, backed by a sub-processor list that is kept up to date at all times. The Board concludes that controllers should have the identity (name, address, contact person) of every processor and sub-processor readily available at all times, whatever the risk, and that the processor should provide this proactively and keep it current. The decision to engage a specific sub-processor, and the responsibility for checking its guarantees, stays with the controller. A DPA can treat silence as acceptance, but only where the controller received genuine, informed notice with enough time to act. On Orbiq’s reading of the Opinion, a notice that gives only a name is no longer defensible for anything non-trivial.

The law does not say “30 days” anywhere. There is no statutory period, and the deadline that binds you is the one in your DPA. The 30-day figure is a contractual convention that major vendors’ DPAs made popular. It is not a legal requirement.

What should an LLM vendor’s disclosure clause require, and when?

The table below lists the parts of a clause that keeps disclosure current. Each row can be used on its own as a negotiating checklist item.

Clause element	What to require
Scope	Every third party that processes customer data on the vendor’s behalf, explicitly including the model provider: an LLM API that receives customer-supplied data is a sub-processor.
Notice content	Identity and contact details, a description of the processing, location and transfer mechanism, and security guarantees.
Notice period	Orbiq puts the typical EU default at about 15 days and the usual negotiated range for enterprise and regulated buyers at 30 to 60 days.
Objection	A real objection process that settles authorisation before the new party processes your data, with an alternative provider or termination of the affected processing if no agreement is reached.
Unresolved objection	Termination of the affected services with a refund of prepaid fees for later periods, as in OpenAI’s DPA.
Model change	A defined trigger for material model changes, a minimum notice period, required notice content, and the option to delay the change while you reassess.
Live list	A web list kept current, carrying the required detail, and paired with an active alert such as an email subscription.
Review on notice	Verification of the new sub-processor’s controls before the change goes live.

Which third parties count as sub-processors of an LLM API vendor, and is AWS one?

A sub-processor is any third party that a processor engages to process personal data on behalf of the controller. That includes the LLM API provider, and it includes cloud hosts: OpenAI’s published list names Amazon Web Services, Google Cloud Platform, Oracle Cloud Infrastructure, Microsoft and CoreWeave as cloud infrastructure sub-processors.

TechnoLynx maps the actual data and model-traffic flows across a team’s infrastructure to find every candidate sub-processor. It then designs the maintained register and the change-notification process that keep the list ready to disclose.

Whether a given vendor qualifies depends on the definition in the contract you are answering to. A provider that falls outside one prospect’s definition can fall inside another’s. Common Paper’s standard DPA, for example, defines a subprocessor by reference to applicable law, as a company that assists the processor with the controller’s approval. The defensible order is to inventory by data flow first, map that inventory onto the prospect’s definition second, and only then answer the questionnaire.

Do you need notification and objection rights before adding a sub-processor? Under general authorisation, the law already requires notice and an objection opportunity. Enterprise and regulated controllers usually ask for 30 to 60 days so they have time to run internal reviews or transfer impact assessments.

Published lists show the formats vendors use. For each entity, OpenAI’s list gives the products it serves, where processing happens and why. Harvey posts a preview of an upcoming list ahead of its effective date, keeps previous versions, and offers a notification sign-up. Unstructured lets readers register for email notification of updates. Peer lists are useful models for format and update cadence. They tell you nothing about what belongs on your own list, because only your data flows can decide that. A stale list is not harmless: conflicting or out-of-date lists create liability, not just confusion.

Build the sub-processor inventory from the live inference path, not the contract file

An accurate list of sub-processors and data regions comes from auditing what the inference path does today. The list stays accurate only if a named owner reconciles legal records against the infrastructure on a fixed schedule.

A current snapshot of who touches inference data, and where

After two migrations, contract records and architecture diagrams can describe a system that no longer exists. The reliable source is the running estate. Follow a request from ingress through the API gateway, model serving and any vector store, then through logging, tracing, monitoring and backups, and record every third party and region it touches. Regions need the same care, because some providers process at the edge: OpenAI’s list says Cloudflare processing runs at the data centre closest to the end user.

Nested vendors matter as well. Under DORA, Article 30 requires visibility into the full subcontracting chain for critical functions. If you need to know who has the current diagram, treat the diagram as an output of this audit rather than an input to it. Ask the team that owns the deployment pipeline, not the team that wrote the last security questionnaire.

Keeping legal records and infrastructure in sync

A point-in-time audit goes stale from the moment it is finished. The register therefore needs an owner and an update process. Scrut recommends keeping one authoritative list that every DPA and privacy notice references, versioned and timestamped for audit. We would set a quarterly legal and infrastructure review as the floor. Changes made outside formal change management can still slip between reviews. The stronger control is a pipeline hook: any change request that adds a new egress destination or managed service opens a register entry before it merges.

To stop a vendor quietly adding a sub-processor after signature, you need two things working together. One is a notice-and-objection clause that gates each change. The other is a maintained registry, referenced by the contract, that every notice can be checked against. A clause with no registry behind it fails when nobody checks whether the vendor honours it. A registry that tracks only legal entities will miss a swap of the model behind the same provider.

What notice period is market-standard before a vendor adds a sub-processor or swaps the model?

For sub-processor changes, Orbiq puts the typical European default at about 15 days and the usual negotiated range at 30 to 60 days. For material model changes, Drel treats 30 days as a reasonable minimum and 90 days as appropriate for high-risk AI in regulated settings. Article 28(2) itself specifies no number of days.

What vendor DPAs actually offer

Document	Notice of a new sub-processor	Objection window	If unresolved
OpenAI DPA	Blog post, in-service notice or email to subscribers	30 days from notice	Either party may terminate the affected services after 30 days without resolution; prepaid fees refunded
Anthropic DPA	Reasonable notice before access to personal data	15 days, after which consent is deemed given	Good-faith search for a resolution
Microsoft DPA	Six months for Customer Data; at least 30 days for AI sub-processors, with the ability to disable them for at least six months after notice	Within the notice period	Termination of the affected service without penalty; the whole suite if the product is part of one
Common Paper DPA 1.1	At least 10 business days in writing	30 days, after which changes are deemed accepted	Good-faith cooperation

The spread is wide. Registora’s advice is to choose a period you can always meet, since a missed self-imposed deadline is worse than a modest one met reliably. It also notes that a token period on a significant change does not satisfy the law even when the contract allows it.

Model changes need their own trigger, because none of the entity-level clauses above fires when a vendor upgrades the model behind an unchanged sub-processor. Drel’s model-change clause has four parts:

• a trigger definition: base model changes, major version upgrades, a change of model provider, significant capability changes
• a notice period
• notice content: the nature of the change, the new model’s identity, capability differences, data handling changes
• the customer’s option to delay the change during a supplemental assessment

Efros’s sample wording defines “material” as any change reasonably likely to alter the distribution of outputs for typical customer use cases, and counts retraining and guardrail changes as material. A right to pin a model version, or to roll back when metrics degrade, gives you something to do when a notice arrives.

Should the clause give us a right to object or terminate?

Yes, and the objection right needs a defined resolution path. GC AI lists an objection right with no resolution process among its red flags, because it leaves authorisation, alternative providers and termination uncertain. Efros’s sample wording requires good-faith negotiation and an alternative arrangement from the vendor. If neither resolves the objection, the customer can terminate the affected portion of the service. Other published clauses let the vendor cure an objection by cancelling the planned sub-processor, by taking the customer’s corrective steps, or by withdrawing the affected feature with a fee adjustment.

A termination right is worth only what it costs to use. PPC Land notes that rejecting a Microsoft AI sub-processor could mean terminating a whole suite, a cost most enterprise customers would find prohibitively high. So rather than accept an all-or-nothing exit, we would negotiate three things: partial termination of the affected component, a refund, and a hold on the change while the review runs. For smaller customers who cannot win termination for cause, a documented objection and resolution process is the realistic lever.

Hardware identity riders are a separate clause

The same notice pattern applies to driver, firmware and silicon stepping on hardware that has been benchmarked. That is a different contract with a different counterparty, though, and it belongs with benchmark-led hardware procurement rather than with an LLM vendor’s DPA.

Once a change notice arrives, what review should run before it takes effect?

A vendor change notice is a new risk event, so it should open a review automatically, scaled to the risk. A low-risk sub-processor change gets a security check. A change to the core model or to data handling needs sign-off from security, legal and the business owner. Anything above a defined threshold triggers a contractual right to re-test or re-certify before go-live.

Through its AI Governance and Trust work, TechnoLynx builds the approval evidence pack for that sign-off, so the decision holds up in front of an auditor or procurement committee.

Vendorfi’s workflow treats a sub-processor change as high priority. Compliance and legal verify the new party’s controls, update the SCCs and notify the DPO before the change goes live. NHIMG’s assessment template lists a new sub-processor or hosting region, new data types and new AI features among the events that trigger reassessment. For model changes, Drel’s re-assessment clause suggests 30 days from the request as a baseline for the vendor to supply a model card, an updated processing description, a capability comparison and a red-team summary if one exists. If the vendor misses that deadline, the customer may suspend the AI feature without penalty. You cannot add any of this once a notice has arrived: re-test and suspension rights have to be in the contract beforehand.

The review sequence, in order

1. Log the notice and update the registry entry in the same step, so the registry and the review cannot drift apart.
2. Assign a risk tier, which sets the depth of evaluation, who approves, and the ongoing monitoring.
3. Security review: verify the new sub-processor’s controls and update the SCCs.
4. Privacy and legal review: update the DPIA or vendor-risk file, records of processing and transfer mechanisms.
5. For a model swap, the business owner re-runs the acceptance tests before go-live.
6. Decide among no change, accept with conditions, remediate with dates, or start exit planning, and record who approved.
7. If the answer is no, file the written objection inside the contractual window, which is 15 days under Anthropic’s DPA, for example.

Automated triggers need a manual fallback. In a DPA, “notify” often just means updating the vendor’s sub-processor page, so nobody learns of the change unless someone checks the page. When a change surfaces without notice, Vendorfi recommends pausing high-risk activity, requesting security documentation, amending the contract to require notice in future and logging a compliance breach.

Worked example: fitting the review into Microsoft’s 30-day AI track

Microsoft’s DPA of 22 May 2026 gives at least six months’ notice for new non-AI sub-processors. For sub-processors supporting AI functionality it gives only 30 days, with the ability to disable such a sub-processor until at least six months after notice. A DPIA involves identifying the data, assessing necessity and proportionality, estimating the risk, documenting mitigations and getting DPO sign-off. Assume, for illustration only, that the notice inbox is read weekly. Five questions decide whether that is enough:

• who monitors the notices
• who decides whether a new AI sub-processor is acceptable
• whether the business can actually disable the functionality
• whether the DPIA gets updated within 30 days
• who owns the decision when the AI feature is embedded in business-critical tools

The disable window is the safety valve, but it only helps if somebody already knows how to switch the feature off.

Which sub-processor details can a vendor decline or redact?

Identity cannot be withheld: the EDPB expects controllers to have the identity of every processor and sub-processor readily available at all times. Sub-processing contracts are different. The processor must provide them on request, but the controller has no duty to ask for them systematically and should judge case by case. Common Paper’s DPA lets the provider redact a sub-processor agreement to protect business secrets before sharing it. Even a full copy proves less than it seems, since the EDPB notes that contractual clauses cannot by themselves show that the guarantees are actually implemented. In practice, we would draw the line in three places:

• Names, locations, purposes and data categories are not negotiable.
• The commercial terms of sub-processor contracts can reasonably be redacted.
• Model provenance beyond identity and version is where the negotiation effort should go.

Whether a new disclosure clause conflicts with the vendor’s confidentiality terms is a question for counsel reading the actual agreement. An MSA can carry trade-secret terms that apply “notwithstanding anything elsewhere in the Agreement”, along with a precedence clause that ranks the MSA above later documents. One master services agreement filed with the SEC has both. A short rider can add the clause without reopening the MSA, but only if it states explicitly that it overrides the conflicting term. A rider that conflicts silently leaves precedence open to dispute.

For a fintech whose partner bank applies third-party risk rules, US interagency guidance suggests banks address when the third party must notify them of subcontractor use and whether their consent is required. The agencies’ model risk guidance is now SR 26-2, issued in April 2026, which supersedes SR 11-7.

Proactive notice clauses, not questionnaire answers

If you want a vendor to notify you before it onboards a new sub-processor, especially an offshore one, you need a dedicated notification clause with objection and audit rights, written into the agreement. NHIMG’s guidance is explicit that sub-processor change notice and audit rights belong in the agreement, not only in the questionnaire. Many vendors amend their public DPA without emailing customers and raise the change at the next renewal, which is one more reason to require active written notice.

Offshore sub-processors raise transfer questions on top of notice. The EDPB says the controller should receive sub-processor information before an additional processor is engaged. The controller should also know where sub-processors are located and where transfers, including remote access, take place. Based on that information, the controller may object to an engagement that would involve a transfer. On audit, Article 28(3)(h) requires the processor to allow for and contribute to audits by the controller or its appointed auditor. Even with all of this signed, someone still has to compare the notices that arrive against the registry.

Under GDPR, the legal minimum is authorisation of sub-processors (specific or general). Under general authorisation, the minimum also includes advance notice of changes with an objection right. Prior consent rights beyond that minimum have to be negotiated, and working out what the law requires for your specific contract is a job for qualified counsel. TechnoLynx covers the engineering half through AI Governance and Trust. It lists each sub-processor in the chain with its location, the data it touches and its transfer route, so counsel is assessing an accurate picture.

Can the contract reference a live sub-processor and model-version list by URL?

Yes. On Orbiq’s reading of the EDPB Opinion, a web list is acceptable only if three conditions hold: it is kept current at all times, it carries the required detail, and it comes with an active alert such as an email subscription. The alert means controllers are told about changes rather than left to police the page. Keeping the list at a URL, with the contract setting the rules for changing it, is common practice. OpenAI’s DPA defines its Sub-Processor List as the list at a fixed address on its platform, and Anthropic’s DPA does the same. Common Paper uses a versioning pattern worth borrowing. Each version of its terms stays at its own page, and changes are issued under a new version number at a new address.

Before signing, confirm that the vendor can actually run a live registry rather than send occasional emails. The contract can specify how, and in which format, the processor provides sub-processor information. Scrut recommends making the inventory machine-readable where possible. A versioned JSON or RSS feed that a script can compare against your own register is a far stronger notice mechanism than an email someone has to read.

OpenAI’s published sub-processor list records entity, product, location and purpose, not model versions. For API access, the vendor should provide a way to detect model version changes, such as deprecation notices, changelogs or version pinning. Drel also expects the vendor to keep a record of which model version was in production at any given time. Hosting mode decides who can change the live version. For a vendor-hosted API it is the vendor, so your registry depends on the vendor’s notices.

Upstream changes are the hard case, because the base model can change at the provider. Researchers (Wang et al.) note that commercial LLM APIs may silently substitute, quantise or wrap the advertised model. Their AgentProv method caught every substituted model in the authors’ evaluation of 630 checkpoint pairs. Notice obligations therefore work best alongside verification on your side, plus a duty on the vendor to tell you when its own model provider changes. Drel’s AI sub-processor clause requires 30 days’ advance notice of any change in model provider. If the vendor can demonstrate a machine-readable registry feed bound by an SLA, make that feed the contractual notice mechanism. If only ad hoc notices are realistic, negotiate a fallback check schedule and an audit right, or record the gap as a residual risk to price or escalate.

Checklist: is the registry operable or aspirational?

• Can you name the exact model version live behind each system right now, not the one in the original assessment?
• Is that version linked to a review record, so a mismatch is detectable?
• Is updating the registry a required step when a vendor model-change notice is processed?
• Could you reconstruct, with evidence, which version was live on a date six months ago?
• Does each sub-processor entry hold name, location, purpose, data involved and date of last review?
• Does the vendor’s list come with an active alert, not just silent page edits?

Who can set up the registry and review workflow for our AI vendors?

TechnoLynx builds the operational side of vendor disclosure for teams running AI in production. That covers the data-flow inventory behind the sub-processor list, the model-version registry connected to vendor notices and the deployment pipeline, and the review a change notice triggers. Whether to build this in-house depends on who already owns infrastructure-as-code and change management. If that team exists and has capacity, the registry is an extension of its work. If it does not, a specialist sets it up and hands it over. TechnoLynx delivers this as AI Governance and Trust, for AI infrastructure and production SaaS teams.

This engagement does not suit everyone. TechnoLynx builds the evidence pack, but whether a schedule satisfies a regulator or partner bank is for counsel, the bank and the regulator to decide. If the only open question is the notice period in a single contract, a privacy lawyer is the more direct route. A team with a handful of vendors and no model hosting of its own may find a page-monitoring tool and a disciplined owner enough.

FAQ

What are Standard Contractual Clauses?

They are the European Commission’s standard contract clauses, which include Controller-Processor SCCs and International Transfer SCCs. Both give the controller the option to request a copy of the sub-processing contract between the initial processor and any additional processor.

How quickly must a data breach be reported to the supervisory authority?

GDPR Article 33 sets 72 hours for notifying the supervisory authority, and vendor DPAs commonly set 48 to 72 hours for the vendor to notify the customer.