{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-07-29T16:43:22.585Z"},"content":[{"type":"documentation","id":"09c82800-77b0-4072-b14f-3e1d4075f496","slug":"research-vendor-dpa-review","title":"Reviewing a Research Vendor DPA: Article 28 Clauses, Sub-Processors, and Transfer Annexes","url":"https://www.koji.so/docs/research-vendor-dpa-review","summary":"In customer research you are the controller and the platform is your processor, so Article 28(1) makes a weak DPA your exposure rather than the vendor's. Article 28(3) requires eight clauses: documented instructions, confidentiality, Article 32 security, sub-processor conditions, assistance with data subject rights, assistance with breach notification and DPIAs, deletion or return at end of service, and audit rights. The two that decide operability are sub-processor authorisation and deletion. General sub-processor authorisation is only workable when notice is real and the objection right carries a termination remedy; EDPB Opinion 22/2024 requires visibility of the full chain and ongoing, risk-scaled verification. The substance sits in the annexes: Annex I processing description, Annex II technical measures, Annex III sub-processor list, plus the correct SCC module. AI research tools need four extra clauses covering model training, named model and transcription providers, derived artefacts, and AI disclosure.","content":"## The short answer\n\n**In customer research you are the controller and the platform is your processor — which means the DPA is not the vendor protecting itself from you. It is you discharging your own legal obligation.** Article 28(1) forbids a controller from using a processor that does not provide sufficient guarantees. If you sign a weak DPA, the exposure lands on you.\n\nTwo clauses decide whether you can actually operate: **sub-processor authorisation** and **deletion or return of data at the end of the service**. Everything else is important; those two are the ones that will either let you run a study and honour a participant deletion request, or quietly prevent you from doing so.\n\nAnd the substance is almost never in the clauses. It is in the annexes.\n\n## First: confirm the roles\n\nYou determine the purposes and means of the research — what you ask, whom you ask, and why. That makes you the controller. The platform processes on your instructions, making it a processor. This is the standard shape and the one the DPA should reflect.\n\nThe thing to look for is a vendor asserting **controller** status for its own purposes — most often improving or training models on your interview data. That is not a footnote. It changes who is accountable to your participants, and it means your participants' words are being used for a purpose your consent notice probably never described. It is the single most consequential line in an AI research vendor's DPA.\n\n## The eight clauses Article 28(3) requires\n\nA compliant DPA must bind the processor to:\n\n| | Requirement |\n|---|---|\n| (a) | Process only on the controller's **documented instructions**, including for international transfers |\n| (b) | Ensure personnel authorised to process are under a **duty of confidentiality** |\n| (c) | Implement **Article 32 security measures** |\n| (d) | Respect the **sub-processor** authorisation and flow-down conditions in 28(2) and 28(4) |\n| (e) | **Assist the controller** in responding to data subject rights requests |\n| (f) | Assist with **breach notification** (Arts. 33–34), **DPIAs** (Art. 35), and prior consultation (Art. 36) |\n| (g) | **Delete or return** all personal data at the end of the service, at the controller's choice |\n| (h) | Make information available for **audits and inspections**, and immediately flag any instruction that appears to infringe the GDPR |\n\nBeyond the eight, the agreement must also specify the **subject-matter, duration, nature and purpose of processing, the types of personal data, and the categories of data subjects**. That specification usually lives in Annex I, and it is where vague drafting does the most damage: \"customer data\" is not a description of categories of personal data, and a reviewer who accepts it has not scoped anything.\n\nClause (e) deserves special attention for research teams. When a participant sends you an access or deletion request, you have one month — and you will need the vendor's help inside that window. A DPA that promises assistance \"where commercially reasonable\" has given you nothing. See [DSARs for research data](/docs/dsar-research-data) for what the clock actually demands.\n\n## Sub-processors: the clause that decides everything\n\nGDPR offers two authorisation models:\n\n- **Specific authorisation** — the processor obtains your written consent before engaging each sub-processor.\n- **General authorisation** — the processor informs you of intended additions or replacements and gives you the opportunity to object.\n\nAlmost every SaaS vendor uses general authorisation, and that is normal. What separates a workable clause from a decorative one:\n\n1. **A named, maintained list**, not a category description. \"Cloud hosting providers\" is not a sub-processor disclosure.\n2. **A real notice period before the change takes effect** — 30 days is common, and anything under 14 makes objection theoretical.\n3. **A push notification mechanism you can subscribe to.** A list on a web page you are expected to check is not notice.\n4. **An objection right with a remedy attached.** This is the clause reviewers most often miss. If you may object but the vendor may proceed anyway, and you have no right to terminate without penalty, you have a right to send an email. The objection right must be paired with termination and a refund of prepaid fees.\n5. **Flow-down.** The same obligations must be imposed on each sub-processor by written contract, and the original processor stays fully liable to you for their performance.\n\nThe EDPB raised the bar here in **Opinion 22/2024** (9 October 2024). Its position: the processor must be able to provide details of **every sub-processor down the chain**, along with information about their processing, and the controller has an obligation to check that all of them can meet GDPR obligations — irrespective of the risk level, though risk properly affects how deep the verification goes. It is also an **ongoing** duty, not a one-time gate at signature. Controllers are not required to review every sub-processing contract systematically, but they must be in a position to.\n\nFor AI research tools this is not academic. Interview audio and transcripts typically route to a model provider and often a separate transcription provider. If a vendor cannot name that chain, you cannot assess it — and you cannot complete an erasure request across it.\n\n## The annexes are the document\n\nThe clauses are largely boilerplate. The annexes are where a DPA is either specific or useless.\n\n- **Annex I** — the parties, and the description of processing: categories of data subjects, types of personal data, sensitivity, frequency, duration, purpose. If you handle health, biometric, or children's data, it must say so.\n- **Annex II** — the technical and organisational measures. Look for encryption in transit and at rest, access control, logging, and a stated breach process. A page of adjectives with no specifics is a finding.\n- **Annex III** — the sub-processor list, where general authorisation is used.\n\nIf the DPA covers transfers outside the EEA, it should incorporate the **EU Standard Contractual Clauses** adopted in Commission Implementing Decision (EU) 2021/914. Check that the correct module is selected: **Module Two** for controller-to-processor, **Module Three** for processor-to-processor. The wrong module is a surprisingly common drafting error and it makes the transfer mechanism incoherent. For UK data you need the **UK International Data Transfer Addendum**, and Switzerland requires its own adjustments. Where personal data leaves the EEA you should also expect a transfer impact assessment; our guide to [research data residency and international transfers](/docs/research-data-residency-international-transfers) covers the mechanism choices.\n\n## The AI-specific clauses to add\n\nStandard DPA templates predate AI-moderated research. Four things to check for explicitly:\n\n1. **No training on your data.** Get an unambiguous statement that participant data is not used to train or improve models, including the vendor's sub-processors' models. In the contract, not in a FAQ.\n2. **Model and transcription providers named as sub-processors.** With the retention period each applies to prompts, inputs, and outputs.\n3. **Retention of derived artefacts.** Transcripts, embeddings, summaries, and analysis outputs are all personal data if the individual is identifiable. Clause (g) should reach them, not only the raw recording.\n4. **AI disclosure to participants.** Under the EU AI Act, participants must be told they are interacting with an AI. Confirm the product does this by default rather than leaving it to researcher discipline — see the [EU AI Act guide](/docs/eu-ai-act-user-research-compliance).\n\n## Red flags\n\n- The vendor claims **controller** status for product improvement or model training.\n- **No named sub-processor list**, or a list of categories rather than companies.\n- An **objection right with no termination remedy**.\n- **Assistance with data subject requests limited to \"commercially reasonable efforts\"** with no timeframe.\n- **Audit rights reduced to a questionnaire** with no inspection option at any tier.\n- **Deletion on termination is \"may\" rather than \"shall\"**, or omits derived artefacts.\n- **SCCs referenced but not attached**, or attached with no module selected.\n- **Reluctance to sign a DPA at all.** This tells you how the vendor treats data obligations generally.\n\n## Where Koji stands\n\nKoji signs a DPA with business customers — not only at an enterprise tier — because the obligation the DPA discharges belongs to every customer running research on real people, regardless of plan size. A team on a self-serve plan has the same Article 28(1) duty as a team on an annual contract.\n\nKoji's architecture also shortens the chain you have to review. Interviews run asynchronously over a link rather than through a scheduled video call, so there is no third-party meeting recorder in the processing chain — one fewer sub-processor to assess, one fewer copy of the conversation to chase on a deletion request, and consent captured in the interview flow rather than announced at the top of a call.\n\nBecause analysis runs on transcripts, and Koji's six structured question types — `open_ended`, `scale`, `single_choice`, `multiple_choice`, `ranking`, and `yes_no` — produce typed, predictable fields, the Annex I description of processing is unusually easy to write accurately. Knowing exactly which categories of personal data a study collects is the difference between an annex that scopes something and an annex that says \"customer data\".\n\nFor enterprise data-handling arrangements, contact the Koji team.\n\n## Frequently asked questions\n\n**Do I need a DPA with a research platform?**\nYes, if participants are in a jurisdiction with GDPR-style rules. Article 28(3) requires a written contract whenever a processor handles personal data for you, and Article 28(1) makes using a processor without sufficient guarantees your breach, not theirs.\n\n**Who is the controller in a customer research study?**\nYou are. You determine the purposes and means — what is asked, of whom, and why. The platform is your processor. Treat a vendor claiming controller status for its own purposes as a significant finding.\n\n**What is the difference between specific and general sub-processor authorisation?**\nUnder specific authorisation the processor gets your written consent before each new sub-processor. Under general authorisation it notifies you of intended changes and you may object. General authorisation is normal; it is only workable when the notice period is real and the objection right carries a termination remedy.\n\n**Do I have to check every sub-processor myself?**\nThe EDPB's Opinion 22/2024 says the processor must be able to give you details of the full chain, and that you must verify they can meet GDPR obligations — with the depth of verification scaled to risk, and reviewed on an ongoing basis. You are not required to systematically review every sub-processing contract.\n\n**Which SCC module applies to a research platform?**\nModule Two for controller-to-processor transfers, which is the usual shape when you are the controller. Module Three applies processor-to-processor, further down the chain. Check the module is actually selected — an unselected module is a drafting defect.\n\n**Should the DPA say anything about AI model training?**\nYes. Standard templates predate AI research tools. Insist on an explicit statement that participant data is not used to train or improve models, that model and transcription providers are named sub-processors, and that deletion reaches derived artefacts such as transcripts and summaries.\n\n## Related Resources\n\n- [Structured Questions Guide](/docs/structured-questions-guide) — the six question types, and why typed data makes Annex I accurate\n- [GDPR-Compliant AI User Research](/docs/gdpr-compliant-ai-user-research) — the controller obligations the DPA discharges\n- [Enterprise Security for AI Research Platforms](/docs/enterprise-security-ai-research-platforms) — SOC 2, SSO, and the wider vendor security review\n- [Research Data Residency and International Transfers](/docs/research-data-residency-international-transfers) — SCCs, transfer impact assessments, and where data lives\n- [DSARs for Research Data](/docs/dsar-research-data) — the requests your DPA has to help you answer inside a month\n- [AI Governance for Customer Research](/docs/ai-governance-frameworks-research) — ISO 42001, the NIST AI RMF, and the questions procurement asks\n- [AI Interview Data Privacy & Security](/docs/ai-interview-data-privacy-security) — the buyer's evaluation guide this pairs with","category":"Research Operations","lastModified":"2026-07-29T03:20:43.798337+00:00","metaTitle":"Reviewing a Research Vendor DPA: Article 28, Sub-Processors, SCCs","metaDescription":"You are the controller, so a weak DPA is your exposure. The eight Article 28(3) clauses, the sub-processor terms that decide whether you can operate, and the annexes that hold the real answers.","keywords":["research vendor dpa review","data processing agreement research tool","gdpr article 28 clauses","sub-processor authorisation","edpb opinion 22/2024","standard contractual clauses module two","controller processor research","dpa annex ii tom","ai vendor dpa model training","research platform contract review"],"aiSummary":"In customer research you are the controller and the platform is your processor, so Article 28(1) makes a weak DPA your exposure rather than the vendor's. Article 28(3) requires eight clauses: documented instructions, confidentiality, Article 32 security, sub-processor conditions, assistance with data subject rights, assistance with breach notification and DPIAs, deletion or return at end of service, and audit rights. The two that decide operability are sub-processor authorisation and deletion. General sub-processor authorisation is only workable when notice is real and the objection right carries a termination remedy; EDPB Opinion 22/2024 requires visibility of the full chain and ongoing, risk-scaled verification. The substance sits in the annexes: Annex I processing description, Annex II technical measures, Annex III sub-processor list, plus the correct SCC module. AI research tools need four extra clauses covering model training, named model and transcription providers, derived artefacts, and AI disclosure.","aiDifficulty":"intermediate","aiEstimatedTime":"12 min"}],"pagination":{"total":1,"returned":1,"offset":0}}