What a vendor's DPA should actually cover — and what a click-through TOS doesn't

A vendor’s click-through terms of service are not a data processing agreement, even when they include a section called “Privacy.” Under both Israeli and EU law, using a processor without an adequate data processing agreement (DPA) in place is itself a gap — independent of whether the vendor has actually mishandled anything. GDPR’s Article 28(3) is specific about what has to be in that agreement, and most standard SaaS terms cover almost none of it.

Why “we take privacy seriously” in the TOS isn’t a DPA

A privacy-friendly paragraph in a terms-of-service document tells you the vendor’s general posture. It doesn’t specify what happens to your data, in your account, under your instructions — which is what a DPA has to do. The distinction matters legally, not just practically: a controller’s obligation is to have a processor agreement with specific content, not merely to use a vendor that talks about privacy in good faith.

What a DPA actually has to cover

At minimum: the subject matter, duration, nature and purpose of the processing; the categories of personal data and data subjects involved; the processor’s obligation to act only on the controller’s documented instructions; confidentiality commitments covering anyone who processes the data; the security measures in place; the rules for engaging sub-processors; assistance with data subject rights requests; what happens to the data at the end of the relationship (deletion or return); and cooperation in the event of an audit. A one-paragraph privacy mention in a TOS covers, at best, one or two of these.

Sub-processors: the clause most terms skip entirely

An AI vendor rarely runs its entire stack itself — cloud hosting, model providers, analytics, support tooling are frequently sub-processors one layer down. A proper DPA requires either specific consent to named sub-processors or, at minimum, a mechanism to be notified of changes and object. Standard terms of service almost never mention this at all, which means a vendor can add or swap a sub-processor with access to your customers’ data and there’s no contractual trigger requiring them to tell you.

AI vendors specifically: training and retention terms

This is where AI vendors need scrutiny a generic SaaS DPA template doesn’t cover: does the agreement specify whether inputs are used for model training, how long inputs and outputs are retained, whether that retention differs between raw inputs, embeddings in a retrieval index, and any fine-tuned model artifacts (see the three ways AI touches your data), and what the actual deletion mechanism is if you need it exercised. A generic DPA that never mentions training or retention settings hasn’t actually addressed the risk that matters most with this category of vendor.

A short checklist before you sign

Is there a signed DPA, not just terms of service — a “yes” that’s actually been checked, not assumed. Does it name sub-processors or commit to notifying you of changes. Does it specifically address AI training and retention, not just generic data handling. Does it specify a deletion mechanism you could actually invoke. And does what it says match what the vendor’s account settings are actually configured to do — the gap between the two is exactly what an assessment is built to find.