GDPR research platform evaluation checklist for EU-facing research teams

A GDPR-compliant research platform must sign a valid Data Processing Agreement, restrict EU participant data to adequate storage regions, collect explicit consent before processing personal data, and respond to data subject rights requests within statutory deadlines. This checklist gives EU-facing research teams a structured way to verify each of those requirements before selecting or renewing a platform.

Why platform selection is a GDPR decision, not just an InfoSec one

Research teams that recruit or survey participants in the European Union, European Economic Area, or the UK are acting as Data Controllers under GDPR Article 4. Any platform used to recruit participants, run interviews, store screener responses, or process session recordings is a Data Processor. That relationship creates legal obligations on both sides, and those obligations begin the moment a screener form goes live, not after a project contract is signed.

InfoSec teams rightly focus on certifications such as SOC 2 and ISO 27001, along with network-layer security controls. A companion security checklist covers those requirements in depth. GDPR compliance for research work goes further: it covers the lawfulness of how you collect and use participant data, the mechanics of consent, the platform’s obligations when a participant requests deletion of their data, and how EU data moves to servers potentially located outside Europe. Research operations teams and legal counsel need to evaluate these dimensions independently of a security review.

The European Data Protection Board publishes binding guidelines on the use of cloud-based processors and international transfers that are directly relevant when evaluating research platforms.

Area 1: Data Processing Agreement

A signed DPA is a legal prerequisite before any EU participant data can be collected on a third-party platform. GDPR Article 28 specifies minimum clauses that must be present.

DPA clause	What to verify
Subject matter and duration	Matches your actual use case, not a generic template
Nature and purpose of processing	Covers recruitment, screening, interviews, and analysis
Categories of personal data	Lists all data types: name, email, job title, session recordings, screener responses
Data subject rights obligations	Platform commits to forwarding rights requests to you within a fixed window, typically 72 hours
Sub-processor list	Identifies all third parties the platform passes data to
Deletion on termination	Specifies destruction timeline and confirmation method

A key question to ask every vendor: Can the DPA be signed before you run a single study, rather than only under an enterprise contract? Platforms that require a minimum spend or a custom contract before offering a DPA create a compliance gap for smaller teams and project-based buyers.

Area 2: Data residency and cross-border transfer mechanisms

Personal data flows freely within the EEA by default under GDPR. Transfers to third countries require one of the following safeguards.

EU-US Data Privacy Framework: Applies to US-based vendors that have self-certified under the DPF program. Verify certification status directly at dataprivacyframework.gov before accepting a vendor’s claim.

Standard Contractual Clauses: The 2021 EU SCCs are the most common mechanism for vendors not covered by an adequacy decision. They should be included in or appended to the DPA, and the vendor should be able to confirm which module (Controller-to-Processor or Processor-to-Processor) applies.

Adequacy decisions: The European Commission has recognised a number of countries as providing adequate protection, including the UK, Switzerland, Japan, and Canada for commercial organisations. No additional transfer mechanism is required for transfers to these countries.

Questions to put to any vendor:

• Where are participant data and session recordings physically stored (country and cloud region)?
• Can data residency be restricted to EU/EEA regions?
• If US-based, are you DPF-certified, and do you include SCCs in the DPA?
• Which sub-processors also process EU participant data, and what transfer mechanisms do those sub-processors use?

Area 3: Participant consent and rights

Consent under GDPR must be freely given, specific, informed, and unambiguous. For research recruitment, this has direct implications for how screener forms and study invitation flows are designed on the platform.

Consent collection: The platform should support a consent confirmation step that logs the participant’s agreement before any personal data is collected. Pre-ticked boxes are not valid consent under GDPR Article 7. The consent record, including timestamp, version of consent text shown, and participant identifier, must be stored and retrievable on demand.

Withdrawal and objection: Participants have the right to withdraw consent at any time under Article 7(3). A compliant platform provides a withdrawal mechanism that triggers deletion or anonymisation of that participant’s data according to the policy disclosed at the point of consent.

Data Subject Access Requests: If a participant submits a DSAR, your organisation has 30 days to respond. A platform that cannot export all data associated with a participant identifier in a structured, portable format will slow this process and create operational risk.

Right to erasure: Verify whether the platform’s “delete” function means permanent removal or pseudonymisation, and check whether deleted records remain in backups and for how long.

For more detail on consent mechanics in AI-assisted research, including what to disclose when AI tools moderate or analyse sessions, see AI privacy in research: GDPR and participant consent.

Area 4: Data retention and deletion

GDPR’s storage limitation principle (Article 5(1)(e)) requires that personal data be kept no longer than necessary for the purpose for which it was collected. Research platforms often retain participant profiles, screener responses, and session metadata far longer than the study timeline requires.

Data type	Typical research team need	What to check
Screener responses from rejected participants	Delete after project close	May be retained indefinitely for panel management
Session recordings	30 to 90 days for analysis	Often retained for a year or more by default
Participant contact data	Delete or anonymise after study ends	Frequently retained in panel database
Incentive payment records	Retain for tax or audit purposes (typically 7 years)	Often held by a third-party payment sub-processor

Ask the vendor: What is the default retention period for each data category? Can retention periods be shortened per project? Is there an automated deletion workflow, or does deletion require a manual support ticket?

Area 5: Sub-processor transparency

Every tool the platform uses to process participant data is a sub-processor. GDPR Article 28(2) requires the Data Processor to inform the Data Controller of any intended sub-processor changes. Common sub-processors in research platforms include cloud infrastructure providers, AI transcription APIs, incentive payment processors, video hosting services, and email delivery tools.

A GDPR-compliant platform should:

• Maintain a publicly available or contractually accessible sub-processor list
• Notify you before adding or replacing a material sub-processor, giving you the right to object
• Confirm that each sub-processor is bound by GDPR-equivalent data protection obligations

Platforms that cannot produce a sub-processor list or describe their AI components vaguely represent a compliance risk. Any AI transcription, sentiment analysis, or AI-moderated interview features must be identified as sub-processors with their own transfer mechanisms documented.

Area 6: Incident response and breach notification

GDPR Article 33 requires that a Data Controller be notified of a personal data breach within 72 hours of the Processor becoming aware of it. Your DPA should specify:

• The Processor’s obligation to notify you without undue delay after becoming aware
• The minimum content of breach notifications: nature of breach, categories and approximate volume of records affected, likely consequences, and measures taken
• A named security contact or Data Protection Officer at the vendor

Ask directly: Has the vendor experienced any reportable breaches in the past three years, and if so, how were they handled? Vendors that cannot answer this question clearly, or that have no documented incident response procedure, carry elevated compliance risk.

If you are running studies across multiple EU markets, the guide to recruiting international research participants covers per-country consent and channel considerations alongside the compliance layer.

Documentation to request from vendors

Before signing with a research platform for EU-facing work, collect the following:

1. A pre-signed or template DPA covering GDPR Article 28 minimum clauses
2. Current sub-processor list with the transfer mechanism in use for each sub-processor
3. Confirmation of DPF self-certification or SCCs availability, depending on vendor location
4. Retention and deletion policy for all participant data categories
5. Breach notification procedure and response SLA
6. Relevant certifications (SOC 2 Type II, ISO 27001) as a supplement to the above

For guidance on structuring a broader platform evaluation covering capability, pricing, and procurement process, the research operations platform buying guide is a useful companion resource.

Platforms like CleverX include a standard DPA, EU data residency options, and consent collection built into the study workflow, which reduces the compliance setup overhead for research teams running EU-facing projects without a dedicated InfoSec team to manage the process.

The UK Information Commissioner’s Office also publishes practical guidance on appointing processors and drafting DPAs that is directly applicable to research teams using third-party platforms, even outside the UK.

Frequently asked questions

What makes a research platform GDPR-compliant?

A GDPR-compliant research platform must sign a Data Processing Agreement covering Article 28 minimum clauses, store EU participant data in an adequate region or apply valid transfer mechanisms such as SCCs or DPF certification, collect and log participant consent before any personal data is captured, support data subject rights including erasure and access, and maintain a transparent sub-processor list. Certification alone (SOC 2, ISO 27001) does not make a platform GDPR-compliant; the legal agreements and operational processes are equally important.

Do I need a Data Processing Agreement with my research platform?

Yes, if the platform processes personal data of EU or EEA residents on your behalf. Under GDPR Article 28, a signed DPA is a legal requirement before data collection begins. Running screener forms or collecting participant contact information on a platform without a DPA in place puts your organisation in breach of GDPR, even if the study itself is low-risk. Most established research platforms offer a standard DPA on request, and some include it in the standard terms for all accounts.

Can I store EU participant data on US-based research platforms?

Yes, provided a valid transfer mechanism is in place. The most common options are DPF self-certification (verify at dataprivacyframework.gov), Standard Contractual Clauses included in the DPA, or binding corporate rules for multinational organisations. A US-based platform that cannot demonstrate one of these mechanisms is not suitable for EU participant data under GDPR.

What consent requirements apply when recruiting EU participants?

GDPR Article 7 requires that consent be freely given, specific, informed, and unambiguous. For research recruitment this means participants see a clear description of the study purpose and data use before agreeing, consent is recorded with a timestamp, and pre-checked boxes are not used. Participants must also be informed of their right to withdraw. If your study collects special-category data such as health information or political opinion, Article 9 requires explicit consent, which is a higher standard.

How should I evaluate a research platform’s data retention and deletion policies?

Ask the vendor for the default retention period for each data type: screener responses, session recordings, contact data, and incentive payment records. Verify whether retention can be shortened on a per-project basis and whether deletion is permanent or pseudonymisation. Check whether deleted records persist in backups and for how long. Platforms should be able to confirm deletion in writing, either through an automated workflow or a support request with a documented SLA.

What GDPR documentation should I request before signing with a research platform?

Request a pre-signed or template DPA, the current sub-processor list with transfer mechanisms for each, confirmation of DPF certification or SCC availability, retention and deletion policies for all participant data categories, the vendor’s breach notification procedure and timeline, and relevant certifications such as SOC 2 Type II and ISO 27001. Vendors that are hesitant to produce any of these items before contract are a compliance risk and should be treated accordingly.