A Data Processing Agreement is the shortest path to knowing whether a chatbot vendor is deployable in Europe, and almost nobody reads one. Vendors publish either nothing at all or a template that has never been opened, and buyers accept both because the document looks like a legal project.
It is not. GDPR Article 28 lists what the contract must contain, so reviewing one is a checklist against a fixed list. Ten minutes, eight clauses.
A few terms first, because the rest of this depends on them. GDPR is the General Data Protection Regulation, the EU law governing personal data. A controller decides why and how personal data is processed, which is your organization; a processor acts only on the controller's instructions, which is the chatbot vendor. A DPA, or Data Processing Agreement, is the contract Article 28 requires between the two, and a subprocessor is anyone the processor hands the data on to.
Two more. SCCs are Standard Contractual Clauses, the template terms the European Commission publishes to make transfers of personal data outside the EU lawful. A DSAR, or data subject access request, is a person exercising rights over their own data, such as asking for a copy or asking for deletion.
iShort answer
Article 28(3) fixes what a DPA must contain, which turns the review into a checklist: scope, documented instructions, confidentiality, security, subprocessors, assistance with data subject rights, breach and impact assessment support, deletion or return, and audit information. For a chatbot specifically, the clause that fails most often is scope, because a vendor's DPA can cover account data while leaving visitor conversations outside it. On SiteGPT, the DPA binds only when signed by both parties and is executed for Enterprise customers at onboarding, baseline processing terms for every plan sit in the Terms and Conditions, the subprocessor list is public with a 10 day notice period before a new subprocessor processes data, and transfers rely on Standard Contractual Clauses. There is no EU data residency.
Eight clauses, in the order they appear in Article 28(3). Work down the document and mark each one present, weak, or missing.
Scope of processing
Subject matter, duration, nature, and purpose. For a chatbot this has to name end-user conversations, not only your account and billing data.
Categories of data
The types of personal data and the categories of data subjects. Website visitors are a different category from your employees, and both need naming.
Subprocessor consent
Article 28(2). Specific or general authorisation, a notice period before a new subprocessor starts, an objection route, and flow-down of the same obligations.
Transfer mechanism
Chapter V. The named safeguard for data leaving the EEA, and for SCCs the module in use. Module Two is controller-to-processor.
Security measures
Article 32. The controls have to be in the contract, not only on a marketing page, and the document should say how changes to them are handled.
Assistance with requests
Article 28(3)(e). The mechanism and turnaround when a DSAR names a person rather than a conversation ID. Ask how the search actually runs.
Breach notice
Article 33(2). Without undue delay is the legal floor. A usable clause converts it into hours and commits to what the notice contains.
Deletion on termination
Article 28(3)(g). Delete or return at your choice, including existing copies, unless EU or member state law requires retention. Check which is the default.
Key takeaways
| The question | The short answer |
|---|---|
| Is a DPA optional? | No. Article 28 requires a contract with any processor, and a chatbot vendor is a processor. |
| What has to be in it? | Six scope items plus eight processor obligations, all set out in Article 28(3). |
| Which clause fails most often? | Scope. A DPA that covers account data but not visitor conversations is the common trap. |
| Do you get to approve subprocessors? | Under general authorisation you get notice and an opportunity to object, not a veto per vendor. |
| Are SCCs enough on their own? | They are the mechanism. Schrems II adds a transfer impact assessment on top, and that one is yours. |
| How does SiteGPT execute a DPA? | Signed by both parties, at Enterprise onboarding. Other plans contact support. |
What a DPA is, and why no EU institution can sign without one
When your chatbot answers a visitor's question, two organizations touch that person's data. You decided to put the widget on the site and why, which makes you the controller. The vendor runs the processing on your instructions, which makes it a processor.
Article 28(3) says that processing by a processor "shall be governed by a contract". Not documented, not covered by a policy: governed by a contract that binds the processor to the controller and sets out a specific list of terms.
This is why procurement at a university or a hospital stops dead without one. The buyer cannot lawfully instruct a processor that has no contract, so the DPA is a gate rather than a nice-to-have, and no amount of security certification substitutes for it.
The broader question of what else gates an EU deployment, including the lawful basis you rely on, is covered separately in GDPR and your website chatbot. This page stays inside the contract.
The Article 28 checklist, what has to be in the document
Article 28(3) opens with six things the contract must set out, then lists eight obligations it must impose on the processor. Read them in that order, because the scope items decide whether the obligations apply to anything you care about.
The six scope items: subject matter of the processing, duration, nature and purpose, type of personal data, categories of data subjects, and the obligations and rights of the controller.
For a chatbot, two of those six do the real work. "Categories of data subjects" should name the visitors to your website, not only your own employees. "Type of personal data" should reach conversation content, because a visitor can type anything into a chat box regardless of what your form fields collect.
| Article 28(3) obligation | What good looks like in a chatbot DPA | What weak looks like |
|---|---|---|
| (a) Process only on documented instructions | Instructions are defined, and the vendor commits to informing you if an instruction appears to infringe GDPR | A carve-out letting the vendor process for its own product improvement or model training |
| (b) Confidentiality of authorised personnel | Named commitment covering anyone who can read conversation content, including support staff | Silence on who internally can open a transcript |
| (c) Security measures under Article 32 | Measures are attached as an annex that forms part of the contract | A link to a marketing page the vendor can edit at will |
| (d) Conditions for engaging another processor | Public list, notice period, objection route, obligations flow down under Article 28(4) | "We may use subprocessors" with no list and no notice |
| (e) Assistance with data subject rights | A described mechanism and turnaround for finding a person's conversations | "Reasonable assistance" with no process and no timeline |
| (f) Assistance with Articles 32 to 36 | Breach support, plus inputs for your data protection impact assessment | Assistance offered at additional cost, or at the vendor's discretion |
| (g) Deletion or return at the end | Your choice, on a stated timeline, covering existing copies | Deletion "in line with our retention policy", which is the vendor's choice, not yours |
| (h) Information for audits | Evidence you can put in a file, plus a defined route for inspections | An audit right that exists on paper but is capped at a summary letter |
Two of these are worth pausing on. Obligation (a) is the clause that a vendor's own AI ambitions tend to break, because "we may use aggregated data to improve our services" is a purpose you did not instruct. And obligation (g) matters more than it looks, since the default in most templates is the option that suits the vendor.
Subprocessors, the clause people skip and then regret
Article 28(2) sets out the rule: a processor cannot engage another processor without prior specific or general written authorisation from the controller. Under general authorisation, the processor must inform you of intended additions or replacements and give you an opportunity to object.
Article 28(4) then does the part that protects you. The same data protection obligations must flow down to the subprocessor, and the original processor remains fully liable to you for the subprocessor's performance. You do not have to chase a vector database you have never heard of; you chase your vendor.
For an AI chatbot this clause carries more weight than it does for ordinary software, because the subprocessor list is where the model providers appear. A new AI subprocessor is a new recipient of conversation content and usually a new transfer, which is exactly the change that should reach you before it happens rather than after.
Judge the clause on four practical points:
| What to check | Why it decides the answer |
|---|---|
| Public list or available on request | A public page is one the vendor has to keep accurate, and one you can verify without a sales conversation |
| Notice period before processing starts | Notice after the fact is not an opportunity to object. The period is what makes the right real |
| How notice reaches you | A page you have to remember to check is weaker than an email you receive |
| What each subprocessor does and where | Function and country together answer the transfer question factually, before anyone characterises it |
How SiteGPT's works. The subprocessor list is public, last updated July 2026, and names each company, its function, and its country. The page commits to updating it at least 10 days before a new subprocessor processes personal data, offers an email subscription for change notifications, and states that customers with an executed DPA additionally receive direct email notice.
It also documents the awkward case honestly, which templates usually skip. Where a replacement is urgently required for security or service continuity, the replacement may be engaged immediately for data not protected by the Standard Contractual Clauses; for SCC-protected data it does not process until the notice period has run or the affected customer approves earlier engagement.
Transfers, the section to read before anything else
If a single clause decides whether an EU deployment is lawful, it is this one. Chapter V governs transfers to countries outside the EEA, and where no adequacy decision covers the recipient, the controller needs appropriate safeguards under Article 46.
The DPA should name the mechanism rather than gesture at it. For SCCs, that means identifying the module: Module Two covers controller-to-processor, which is the usual shape for a chatbot vendor, and Module Three covers processor-to-processor, which is what the vendor needs with its own subprocessors.
Then check the date. The EU-U.S. Privacy Shield was invalidated in 2020, so a document still relying on it has not been reviewed in six years, and that tells you something about everything else in it.
Schrems II
Relying on Standard Contractual Clauses is not a filing exercise. A controller must also assess whether the destination country's law undermines the protection the clauses promise, and apply supplementary measures where it does. That assessment is your document to produce, not the vendor's, but the vendor supplies the inputs: encryption in transit and at rest, access controls, and its policy on government access requests. Ask for those during procurement rather than after signature.
Source: CJEU Case C-311/18SiteGPT's position, stated plainly. There is no EU data residency and no regional hosting option. The privacy policy states that service providers are primarily located in the United States, and that transfers of EU, EEA, and UK resident data rely on the European Commission's Standard Contractual Clauses and, where the provider is certified, the EU-U.S. Data Privacy Framework. The Data Privacy Framework part is per provider, so treat it as covering specific certified recipients rather than the arrangement as a whole.
Competitors that host in the EU have a genuine advantage on this specific point, and if EU-only storage is a hard procurement requirement then that is the honest answer. What is checkable here instead is the mechanism and the Article 27 representatives: Prighter EU Rep GmbH in Vienna for the EU, and Prighter Ltd in London for the UK. Article 27 is mandatory for non-EU organizations offering services into the EU and is skipped often enough that it is worth confirming for every vendor on a shortlist.
Audit rights, breach notice, and deletion on termination
These three sit at the back of the document, get read last, and are the ones you actually use.
Audit rights, Article 28(3)(h). The processor must make available all information necessary to demonstrate compliance and allow for and contribute to audits. In practice almost no buyer runs an on-site inspection of a SaaS vendor, so what matters is whether the evidence route produces something you can file: a SOC 2 Type II report, penetration test summaries, the subprocessor list, and answers to a security questionnaire. An audit right capped at a one page summary letter is not evidence.
Breach notice, Article 33(2). The processor must notify the controller without undue delay after becoming aware of a personal data breach. That obligation exists because the 72 hour deadline in Article 33(1) is yours, not the vendor's, and it is unusable if the vendor takes a week. Convert "without undue delay" into a number of hours in the contract, and specify what the notice must contain, so you are not gathering basic facts while your own clock runs.
Deletion or return, Article 28(3)(g). At the end of the relationship the processor deletes or returns the data at the controller's choice, and deletes existing copies unless EU or member state law requires storage. Two things to verify: which option the template makes the default, and whether backups are addressed, because "deleted from production within 30 days" and "deleted everywhere" are different commitments.
How the SiteGPT DPA gets executed, and what to do if you are not on Enterprise
The DPA page provides a generator that produces a customized template from your company details. Read the note on that page before treating the output as an agreement: it becomes binding only when signed by both parties.
Execution is gated. SiteGPT executes DPAs for customers on Enterprise plans as part of enterprise onboarding, which is the same shape as the Enterprise-only BAA on the HIPAA side. Baseline data processing terms for every plan are set out in the Terms and Conditions, and the page directs everyone else to contact support to discuss requirements.
The generator's stated contents line up with the checklist above: processing terms and obligations, security measures and technical safeguards, subprocessor information, data subject rights procedures, breach notification protocols, and international data transfer mechanisms.
The gap worth naming. On the HIPAA side, SiteGPT publishes its standard BAA in full, so counsel can read the actual text before a sales conversation. The DPA text is not published the same way, so an EU buyer cannot do the equivalent pre-read from a generator form. If a pre-read matters to your review process, ask for the text at the start of procurement rather than at signature.
Pros
- Subprocessor list is public and specific, naming each company, its function, and its country
- Commits to updating that list at least 10 days before a new subprocessor processes personal data
- Email subscription for subprocessor changes, plus direct notice for customers with an executed DPA
- Transfer mechanism is stated publicly: Standard Contractual Clauses, plus the EU-U.S. Data Privacy Framework where the specific provider is certified
- Article 27 representatives appointed in both the EU (Prighter EU Rep GmbH, Vienna) and the UK (Prighter Ltd, London)
- Privacy policy states the controller and processor split explicitly, including that the website owner controls visitor conversations
Cons
- The DPA is executed for Enterprise customers at onboarding; other plans rely on the Terms and Conditions and contact support
- The DPA text is not published for pre-review, unlike the standard BAA on the HIPAA side
- No EU data residency and no regional hosting option; the subprocessor list names zero EU-based subprocessors
- The generator produces a template, and a template read as an executed agreement is a common procurement error
- No canonical GDPR program page yet, so the answers sit across the privacy policy, the DPA page, and the subprocessor list
Red flags in a chatbot vendor DPA
Inverting the checklist is faster than working through it. If any of the following appears, the document has a problem that no amount of security certification offsets.
| Scenario | Best pick | Why |
|---|---|---|
| The DPA scopes account data, not conversations | Stop the purchase | The most common failure and the hardest to spot, because the document is genuine. If website visitors are not named as a category of data subjects, the contract does not govern the processing you are buying. |
| A carve-out for product improvement or model training | Stop the purchase | Article 28(3)(a) permits processing only on documented instructions. A right to use conversation content for the vendor's own purposes contradicts the clause directly, and for an AI vendor it is a live risk rather than boilerplate. |
| No named transfer mechanism, or one naming Privacy Shield | Stop the purchase | Chapter V requires a safeguard for data leaving the EEA. Privacy Shield was invalidated in 2020, so relying on it means the document has not been reviewed in six years. |
| Subprocessor list available on request only | Push back | Article 28(2) gives you an opportunity to object, which requires knowing who is on the list and when it changes. A private list with no notice period makes the right unusable. |
| Security measures linked rather than annexed | Push back | A link to a page the vendor controls can change after signature. Article 32 measures should be attached to the contract so changes are contractual rather than editorial. |
| Deletion on the vendor's retention policy | Push back | Article 28(3)(g) puts the choice between deletion and return with the controller. A clause deferring to the vendor's own policy quietly reverses that, and usually says nothing about backups. |
| The vendor can amend the DPA by updating a page | Push back | Unilateral amendment converts a negotiated contract into a notice board. Ask for changes to be agreed, or at minimum for notice with a right to terminate. |
| Breach notice stated only as "without undue delay" | Negotiate | It is the legal floor, and your own 72 hour deadline under Article 33(1) runs regardless. Convert it into hours, and specify what the notice contains. |
Best forEU controllers, DPOs, and procurement leads who have to clear a chatbot vendor through a data protection review, and who would rather check a document against Article 28 than take a compliance badge at face value.
If your organization also handles US health data, the equivalent contract is a Business Associate Agreement rather than a DPA, and the gating works differently: start with do you need a BAA for your website chatbot and the 12 questions to ask a vendor about a BAA.
Frequently asked questions
What is a DPA and why does a chatbot need one? A Data Processing Agreement is the contract GDPR Article 28 requires between a controller and a processor. A chatbot vendor that handles visitor conversations on your behalf is a processor, so the contract is mandatory rather than advisable. Article 28(3) also specifies what the document must contain, which is why a DPA review is a checklist against a fixed list rather than an open-ended legal exercise. Without a signed DPA the processing is non-compliant no matter how strong the vendor's security happens to be.
What must a DPA contain under Article 28? Article 28(3) requires the subject matter, duration, nature and purpose of processing, the type of personal data, the categories of data subjects, and the obligations and rights of the controller. It then lists eight processor obligations: process only on documented instructions, bind personnel to confidentiality, apply Article 32 security measures, respect the conditions for engaging another processor, assist with data subject rights, assist with security, breach notification and impact assessments, delete or return the data at the end at the controller's choice, and make available the information needed to demonstrate compliance and allow audits.
Does a chatbot DPA have to cover conversations, or just account data? It has to cover conversations, and this is the most common scoping failure. A vendor can hold a genuine DPA that covers only the account, billing, and support data of its own customers, while the visitor conversations flowing through the widget sit outside the described scope. Read the subject matter and categories of data subjects clauses specifically for end users of your website, not just for your staff. If conversations are not named, the document does not do the job you are buying it for.
How should subprocessor changes be handled in a DPA? Article 28(2) allows either specific or general written authorisation. Under general authorisation the processor must inform the controller of intended additions or replacements and give an opportunity to object, and Article 28(4) requires the same data protection obligations to flow down to the subprocessor while the original processor stays fully liable for its performance. What makes the clause workable in practice is the detail: a public list rather than one available on request, a stated notice period before the new subprocessor starts processing, a delivery method that reaches you, and a described objection route.
What transfer mechanism should a chatbot DPA name? For personal data leaving the EEA to a country without an adequacy decision, Chapter V requires appropriate safeguards, and the usual safeguard is the European Commission's Standard Contractual Clauses. The DPA should name the mechanism and, for SCCs, identify the module in use: Module Two for controller-to-processor and Module Three for processor-to-processor. After Schrems II, relying on SCCs also means completing a transfer impact assessment, which is the controller's document to produce using inputs from the vendor. Any document still relying on the Privacy Shield is out of date, because it was invalidated in 2020.
How quickly must a processor report a personal data breach? Article 33(2) requires the processor to notify the controller without undue delay after becoming aware of a personal data breach. That obligation exists because the 72 hour deadline in Article 33(1) belongs to the controller, and the clock is effectively unusable if the vendor takes a week to tell you. A good DPA converts without undue delay into a stated number of hours and commits to the content of the notice, so you are not chasing basic facts while your own deadline runs.
How is a SiteGPT DPA executed, and what if you are not on Enterprise? The DPA page states plainly that the agreement becomes binding only when signed by both parties, and that SiteGPT executes DPAs for customers on Enterprise plans as part of enterprise onboarding. The same page notes that baseline data processing terms for every plan are set out in the Terms and Conditions, and directs other customers to contact support to discuss requirements. So the generator produces a template, not an executed contract, and Enterprise is where signature happens.
Does SiteGPT offer EU data residency? No. The published subprocessor list names no EU-based subprocessor: Convex and Pinecone run in the United States on AWS, OpenAI, Cohere, Context.dev, Portkey, PostHog, DataFast, Google, Dub, Bento and AutoSend are United States, Cloudflare is listed as Global, and Paddle is United Kingdom and acts as an independent controller for payment data rather than as a subprocessor. If EU-only storage is a hard requirement, SiteGPT does not meet it. The transfer mechanism is Standard Contractual Clauses, plus the EU-U.S. Data Privacy Framework where the specific provider is certified.
Sources
- GDPR Article 28 for the required contents of a processor contract, the subprocessor authorisation rule in 28(2), and the flow-down and liability rule in 28(4)
- GDPR Article 32 for security of processing
- GDPR Article 33 for the controller's 72 hour deadline and the processor's obligation to notify without undue delay
- GDPR Chapter V for transfers of personal data to third countries, including Article 46 safeguards
- GDPR Article 27 for the representative requirement for organizations not established in the EU
- EDPB for guidance on standard contractual clauses and supplementary measures following Schrems II
- SiteGPT DPA page for the both-parties signature requirement, Enterprise execution at onboarding, the Terms and Conditions baseline, and the stated contents, verified 10 August 2026
- SiteGPT subprocessor list for every subprocessor and its stated country, the 10 day notice commitment, the email subscription, and the urgent-replacement carve-out, verified 10 August 2026
- SiteGPT privacy policy for the controller and processor split, the SCC and Data Privacy Framework wording, the Article 27 representatives, and the statement that service providers are primarily located in the United States, verified 10 August 2026
Last updated: August 2026. All SiteGPT legal pages were read directly on 10 August 2026.