Reviewing a Research Vendor DPA: Article 28 Clauses, Sub-Processors, and Transfer Annexes

The short answer

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.

Two 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.

And the substance is almost never in the clauses. It is in the annexes.

First: confirm the roles

You 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.

The 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.

The eight clauses Article 28(3) requires

A compliant DPA must bind the processor to:

Beyond 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.

Clause (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 for what the clock actually demands.

Sub-processors: the clause that decides everything

GDPR offers two authorisation models:

• Specific authorisation — the processor obtains your written consent before engaging each sub-processor.
• General authorisation — the processor informs you of intended additions or replacements and gives you the opportunity to object.

Almost every SaaS vendor uses general authorisation, and that is normal. What separates a workable clause from a decorative one:

1. A named, maintained list, not a category description. "Cloud hosting providers" is not a sub-processor disclosure.
2. A real notice period before the change takes effect — 30 days is common, and anything under 14 makes objection theoretical.
3. A push notification mechanism you can subscribe to. A list on a web page you are expected to check is not notice.
4. 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.
5. 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.

The 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.

For 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.

The annexes are the document

The clauses are largely boilerplate. The annexes are where a DPA is either specific or useless.

• 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.
• 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.
• Annex III — the sub-processor list, where general authorisation is used.

If 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 covers the mechanism choices.

The AI-specific clauses to add

Standard DPA templates predate AI-moderated research. Four things to check for explicitly:

1. 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.
2. Model and transcription providers named as sub-processors. With the retention period each applies to prompts, inputs, and outputs.
3. 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.
4. 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.

Red flags

• The vendor claims controller status for product improvement or model training.
• No named sub-processor list, or a list of categories rather than companies.
• An objection right with no termination remedy.
• Assistance with data subject requests limited to "commercially reasonable efforts" with no timeframe.
• Audit rights reduced to a questionnaire with no inspection option at any tier.
• Deletion on termination is "may" rather than "shall", or omits derived artefacts.
• SCCs referenced but not attached, or attached with no module selected.
• Reluctance to sign a DPA at all. This tells you how the vendor treats data obligations generally.

Where Koji stands

Koji 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.

Koji'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.

Because 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".

For enterprise data-handling arrangements, contact the Koji team.

Frequently asked questions

Do I need a DPA with a research platform? Yes, 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.

Who is the controller in a customer research study? You 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.

What is the difference between specific and general sub-processor authorisation? Under 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.

Do I have to check every sub-processor myself? The 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.

Which SCC module applies to a research platform? Module 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.

Should the DPA say anything about AI model training? Yes. 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.

Related Resources

• Structured Questions Guide — the six question types, and why typed data makes Annex I accurate
• GDPR-Compliant AI User Research — the controller obligations the DPA discharges
• Enterprise Security for AI Research Platforms — SOC 2, SSO, and the wider vendor security review
• Research Data Residency and International Transfers — SCCs, transfer impact assessments, and where data lives
• DSARs for Research Data — the requests your DPA has to help you answer inside a month
• AI Governance for Customer Research — ISO 42001, the NIST AI RMF, and the questions procurement asks
• AI Interview Data Privacy & Security — the buyer's evaluation guide this pairs with