Enterprise
The GDPR Data Processing Agreement, explained
Processing scope, sub-processors, transfer mechanisms and execution — what the DPA covers and the exact path your privacy team follows to get it signed.
Ciao's GDPR Data Processing Agreement is the contract that governs how Ciao processes personal data on your behalf: the scope of processing, the sub-processors involved — including model providers operating under zero-retention contracts — and the applicable transfer mechanisms. Unlike vendors that treat the DPA as an afterthought, Ciao routes it through a defined procurement path so your legal team reviews and executes real documents, not summaries.
Published 2026-07-03 · Last updated 2026-07-03
Why the DPA is where AI platforms get stuck
For a European privacy team — or any team serving European users — the DPA is not paperwork, it is the control. It defines what the processor may do with personal data, which sub-processors touch it, and on what legal basis data crosses borders. An AI development platform adds a layer that older DPA templates never anticipated: model providers, sitting in the processing chain, with their own retention behavior.
This is where many AI tool evaluations stall. The product demo goes well, then the privacy office asks for the sub-processor list and the model provider's retention terms, and the vendor's answer is a support-ticket thread. Weeks pass. Deals — and internal projects — die in that gap, not because the answer was bad but because nobody had written it down.
Ciao's approach is to make the DPA a first-class procurement artifact. The agreement covers the processing Ciao performs to operate the platform, names the categories of sub-processors involved, and sits alongside the commitments your reviewers will want to see next to it: customer code is not used to train models, inference runs under zero-retention model contracts, and SOC 2 Type II reports are available under NDA.
What the DPA covers
- Processing scope and roles — What Ciao processes on your behalf to operate the platform, in what role, and for what purpose — the controller-processor foundation your privacy assessment is built on.
- Sub-processors — The categories of sub-processors behind the platform — cloud infrastructure and model providers among them — with the current list maintained as part of the DPA document set your team reviews before signing.
- Model providers inside the frame — The model layer is treated as part of the processing chain, not an exception to it: inference runs under zero-retention model contracts, and customer code is not used to train models.
- Transfer mechanisms — The legal mechanisms applicable to any cross-border transfers are documented in the agreement, so your DPO assesses actual language rather than assurances.
- Deployment postures that shrink the question — Deploying to your own AWS, Azure or GCP account, a private VPC, or on-prem under separate terms keeps application data inside infrastructure you control, simplifying the residency analysis. See the data residency page for that dimension.
- Security measures with evidence behind them — The technical and organizational measures referenced by the DPA connect to verifiable artifacts: SOC 2 Type II reports under NDA and the security pack on request.
How to execute the DPA
1. Request the document set
Contact the enterprise team via the contact page and ask for the DPA alongside the security pack — they are designed to be reviewed together.
2. Review scope and sub-processors
Your privacy team maps the processing description and the sub-processor list against your records of processing and your risk framework.
3. Assess the model layer
Review the zero-retention and no-training commitments as part of the same exercise; if you bring your own model keys or endpoints, your existing provider terms slot into the analysis.
4. Resolve questions with a counterpart
DPA questions route to the enterprise team as part of procurement — a named process, not a community forum.
5. Execute and file
The signed DPA becomes part of your vendor file together with the SOC 2 Type II report reviewed under NDA, giving your auditors one coherent evidence set.
Verification and commercial notes
A page like this cannot substitute for the agreement itself, and does not try to: the DPA, the sub-processor list and the data-handling terms are documents your legal team reads in full during procurement. What this page commits to is the path — request via the contact page, review with a named enterprise counterpart, execute as part of the engagement. DPA execution is included in enterprise procurement rather than sold separately; serious production programs start at USD 10,000 per year. Nothing here is legal advice — it is a description of the workflow and the documents, for the people whose job is to assess them.
One practical tip from teams that have run this review quickly: parallelize. Send the DPA to privacy, the SOC 2 Type II report to security and the commercial terms to procurement in the same week — the document set is designed so the three reviews do not block one another, and the enterprise team can field all three threads at once.
The DPA reviewer's checklist, mapped
| Reviewer question | Where the answer lives |
|---|---|
| What processing does the vendor perform? | Processing scope in the DPA |
| Who are the sub-processors? | Sub-processor list in the DPA document set |
| Do model providers retain or train on our data? | Zero-retention model contracts; no training on customer code — contractual terms |
| What transfer mechanisms apply? | Transfer provisions in the DPA |
| What security measures back this up? | SOC 2 Type II report under NDA; security pack on request |
| Where does application data physically run? | Deployment posture: Ciao cloud, your cloud account, private VPC, or on-prem under separate terms |
Frequently asked questions
How do we get the DPA?
Request it via the contact page as part of an enterprise conversation. It arrives with the security pack and the data-handling terms so your privacy and security reviews can run in parallel rather than in sequence.
Are model providers listed as sub-processors?
The model layer is documented as part of the processing chain in the DPA document set, together with the commitments that matter most: inference runs under zero-retention model contracts, and customer code is not used to train models.
How are sub-processor changes communicated?
The notification mechanism is defined in the DPA itself — your team reviews the exact terms during procurement rather than relying on a paraphrase here. The current sub-processor list is part of the document set you receive.
Does deploying in our own cloud change the DPA analysis?
It narrows it. When the application runs in your own AWS, Azure or GCP account, a private VPC, or on-prem under separate terms, application data stays inside infrastructure you control, which simplifies the residency and transfer questions your DPO has to answer.
Can our outside counsel review before we commit commercially?
Yes. The DPA and security pack are shared during procurement precisely so legal review happens before signature, alongside the SOC 2 Type II report under NDA. Bring counsel in as early as you like — the documents are ready for them.