Data processing agreement (DPA) clinical trials: cloud vendor risk and GDPR obligations

Cloud data platforms have become central to modern clinical research, enabling sponsors and contract research organisations (CROs) to store, process and analyse participant data at scale. Yet the 2024 Snowflake credential-theft campaign, in which a single vendor's absent multi-factor authentication (MFA) enforcement exposed data belonging to more than 165 organisations and an estimated 100 million individuals, has made one question urgent for life sciences teams: does your data processing agreement (DPA) clinical trials setup actually govern what happens when your cloud vendor fails?

This article applies the iliomad Funnel Framework to that question. The framework starts with the most stringent applicable regulation (the EU General Data Protection Regulation, Regulation 2016/679, hereafter GDPR), extracts its core obligations, and then layers in jurisdiction-specific requirements, so that sponsors maintain a globally consistent compliance posture while addressing local nuances in a structured, scalable way.

What is a data processing agreement in the context of clinical trials?

A data processing agreement (DPA) is a binding contract, required under Article 28 of the GDPR, that governs every instance in which a data processor handles personal data on behalf of a data controller. In clinical trials the sponsor typically acts as the data controller, and any cloud platform, CRO or laboratory that processes participant data on the sponsor's instructions must sign a DPA before processing begins.

Article 28(3) sets out a mandatory minimum content list for every DPA. The contract must specify the subject matter, duration, nature and purpose of the processing, the type of personal data involved and the categories of data subjects. It must also require the processor to act only on documented instructions, ensure confidentiality, implement appropriate technical and organisational security measures under Article 32, assist the controller with data subject rights requests and data protection impact assessments (DPIAs), and delete or return all personal data at the end of the engagement.

For clinical trials, the sensitivity of the data makes these clauses more than formalities. Health data is a special category under Article 9, and its processing requires both an explicit legal basis and heightened security measures. When that data sits inside a cloud data warehouse, the DPA is the primary contractual mechanism through which the sponsor can enforce its security expectations on the vendor.

Why does the Snowflake case matter for clinical trial data processing agreements?

The Snowflake supply-chain breach is directly relevant to life sciences organisations because many pharmaceutical sponsors, CROs and biostatistics teams rely on cloud data warehouses of precisely this type. Between April and September 2024, Connor Riley Moucka and co-conspirators used stolen credentials to access customer accounts on the Snowflake cloud platform, downloading terabytes of data including financial records, Social Security numbers and passport information. Reported victim losses exceeded USD 9.5 million, with more than USD 2.5 million paid in ransom (United States Department of Justice, guilty plea entered 6 August 2026).

No clinical trial sponsor was publicly named among the affected organisations, but the attack vector is precisely the one that threatens research data: a processor-level authentication failure that cascades across an entire customer base regardless of each customer's own security posture. That is the definition of a supply-chain risk, and it is the risk that a well-drafted data processing agreement (DPA) clinical trials document is designed to address contractually.

Three contractual gaps commonly leave sponsors exposed in this scenario.

First, absent mandatory MFA clauses. If the DPA does not explicitly require the vendor to enforce MFA for all accounts that can access trial data, the sponsor has no contractual basis on which to demand remediation or claim breach of contract when the vendor's default settings allow credential-only access.

Second, vague security obligations. Article 32 of the GDPR requires processors to implement measures appropriate to the risk, including encryption and ongoing confidentiality testing. A DPA that simply reproduces the statutory language without specifying encryption standards, patch cadence or penetration-testing frequency leaves the sponsor unable to audit compliance meaningfully.

Third, inadequate breach notification timelines. Article 33 of the GDPR requires controllers to notify their supervisory authority within 72 hours of becoming aware of a personal data breach. If the DPA does not oblige the processor to notify the controller within, for example, 24 hours of discovering an incident, the controller's 72-hour clock may expire before it has received enough information to act.

How should sponsors structure a DPA for cloud clinical trial platforms?

Sponsors should structure the DPA around four pillars: scope definition, security specifications, sub-processor governance and breach response. Each pillar translates a GDPR obligation into an operationally enforceable clause.

Pillar 1: Scope definition. The DPA must identify every category of participant data that may enter the cloud platform. In a clinical trial this typically includes demographic data, medical history, laboratory results, genomic data where applicable, electronic patient-reported outcomes (ePRO) and adverse event records. Naming these categories explicitly, rather than relying on generic language, ensures that any processing outside the named categories constitutes a breach of contract and triggers the notification regime.

Pillar 2: Security specifications. Article 32(1)(a) requires pseudonymisation and encryption as baseline measures. The DPA should translate this into minimum technical standards: for example, AES-256 encryption at rest, TLS 1.2 or higher in transit, role-based access controls, and mandatory MFA for every account tier that can query or export participant data. These specifications should be referenced in an annex that the vendor must update whenever it changes its security architecture, giving the sponsor an audit trail.

Pillar 3: Sub-processor governance. Article 28(2) prohibits processors from engaging sub-processors without the controller's prior specific or general written authorisation. Cloud platforms routinely rely on sub-processors for infrastructure, logging and support functions. The DPA must require the vendor to maintain an up-to-date sub-processor list, notify the sponsor of any intended changes with sufficient lead time for the sponsor to object, and impose equivalent data protection obligations on each sub-processor by contract. This clause is critical in supply-chain breach scenarios, where the initial compromise often occurs at a sub-processor level.

Pillar 4: Breach response. The DPA should specify the processor's notification obligation in hours, not days, and require the notification to include the nature of the breach, the categories and approximate number of data subjects affected, the likely consequences, and the measures taken or proposed. This mirrors the content required by Article 33(3) for controller notifications to supervisory authorities, so that the sponsor can pass the information directly upstream with minimal delay.

Focus: the example of France and the CNIL

In France, the Commission Nationale de l'Informatique et des Libertés (CNIL), the national data protection authority, has published specific guidance on cloud computing contracts and on the Méthodologie de Référence MR-001, which governs interventional clinical research. Under MR-001, sponsors must use a cloud processor that meets GDPR Article 28 requirements and must document that the processor's security measures are adequate for health data. The CNIL has indicated in its cloud guidance that vague contractual security language is insufficient and that DPAs must contain verifiable technical commitments. A sponsor using Snowflake or a comparable platform for French trial data must therefore ensure that its DPA contains the specific MFA, encryption and sub-processor provisions described above, and must retain evidence of vendor compliance for inspection.

Focus: the example of the United Kingdom and the ICO

The Information Commissioner's Office (ICO) enforces the UK GDPR, which was retained in domestic law following the UK's departure from the European Union. The UK GDPR imposes requirements on controller-processor contracts that are materially identical to those in EU GDPR Article 28. For clinical trials conducted at UK investigator sites, the sponsor's DPA with its cloud vendor must comply with UK GDPR requirements and must also be reviewed in light of the ICO's accountability framework, which expects organisations to demonstrate that processor contracts are actively monitored rather than signed and filed. Following high-profile cloud breaches, the ICO has signalled increased scrutiny of controller-to-processor due diligence, making robust DPA clauses and documented vendor audits a practical necessity for UK trial sponsors.

Focus: the example of Germany and the Bavarian data protection authority

Germany's federal structure means that pharmaceutical sponsors operating in Bavaria interact with the Bayerisches Landesamt für Datenschutzaufsicht (BayLDA) rather than a single national authority. The BayLDA has published detailed requirements for cloud processing contracts involving health data, including the expectation that sponsors conduct a transfer impact assessment where the cloud vendor's infrastructure involves servers outside the European Economic Area. For sponsors using US-headquartered cloud platforms with EU data residency options, the DPA must specify the contractual data residency commitment and must be supplemented by standard contractual clauses (SCCs) adopted by the European Commission under Article 46(2)(c) of the GDPR where any data flow to a third country occurs.

Focus: the example of the European Medicines Agency and EU CTR 536/2014

The EU Clinical Trials Regulation 536/2014 (EU CTR) governs clinical trials conducted in EU Member States and requires sponsors to maintain a trial master file that is accessible for inspection. Where trial data is stored in a cloud platform, the DPA must ensure that the sponsor can retrieve or access all data held by the processor within a timeframe that supports regulatory inspection obligations. Article 57 of the EU CTR requires sponsors to retain trial records for at least 25 years after the end of the trial. The DPA must therefore address data return and deletion obligations in a way that is compatible with this retention period, and must specify what happens to trial data if the vendor ceases to operate or is acquired.

Comparing key DPA clauses: minimum requirements versus best practice

The table below compares the minimum contractual content required by GDPR Article 28 with the enhanced clauses that supply-chain risk and clinical trial regulatory requirements justify in practice.

Clause areaGDPR Article 28 minimumBest practice for clinical trial cloud platformsProcessing instructionsProcessor acts only on controller instructionsDocumented instruction log with version control and audit trailSecurity measuresAppropriate technical and organisational measures per Article 32Named standards: AES-256 at rest, TLS 1.2+ in transit, mandatory MFA, annual penetration testSub-processorsPrior written authorisation, equivalent obligationsReal-time sub-processor register, 14-day advance notice of changes, controller right to object and suspendBreach notificationProcessor assists controller with Article 33/34 obligationsProcessor notifies controller within 24 hours of discovery, with Article 33(3)-compliant contentData subject rightsProcessor assists controller in respondingNamed response coordinator, maximum 48-hour internal SLA for assistanceData retention and deletionReturn or delete at end of engagementRetention schedule aligned to EU CTR Article 57 (25 years), certified deletion with written confirmationAudit rightsController may conduct audits or commission auditorAnnual right to audit, SOC 2 Type II report shared proactively, inspection-ready documentation retainedLiabilityProcessor liable for damage caused by non-complianceUncapped liability for breaches involving special category data, indemnity clause for regulatory fines

What steps should a sponsor take now to strengthen its data processing agreements?

Sponsors should treat DPA review as an ongoing compliance activity rather than a one-time contract exercise. The following five steps reflect the iliomad Funnel Framework applied to cloud vendor risk.

Step 1: Inventory all processors that touch participant data. Map every system involved in collecting, storing, transmitting or analysing clinical trial data. This includes eClinical platforms, cloud data warehouses, ePRO vendors, central laboratory systems and pharmacovigilance databases. Each relationship requires a compliant DPA under Article 28.

Step 2: Audit existing DPAs against the best-practice clause set. Compare each DPA in your inventory against the table above. Note gaps in security specificity, sub-processor governance and breach notification timelines. Prioritise remediation for processors that handle special category health data or genomic data.

Step 3: Insert mandatory MFA and encryption requirements. Following the Snowflake precedent, sponsors should negotiate explicit MFA requirements into every cloud platform DPA. The clause should specify that MFA is enforced by default for all user accounts and all API integrations that can access trial data, and that the vendor will notify the sponsor within 48 hours of any change to its authentication architecture.

Step 4: Conduct a DPIA where processing is high-risk. Article 35 of the GDPR requires a data protection impact assessment (DPIA) before processing that is likely to result in a high risk to data subjects. Large-scale processing of health data in a cloud environment meets this threshold. The DPIA should assess the risks arising from the vendor's authentication model, sub-processor chain and data residency arrangements, and should be reviewed whenever the vendor changes its security architecture.

Step 5: Verify jurisdiction-specific requirements. Layer in local obligations using the Funnel Framework. For French trials, verify MR-001 compliance. For UK trials, document ICO accountability measures. For trials in Germany or other Member States, confirm that any third-country data transfers are covered by SCCs or an adequacy decision, and that the DPA reflects the relevant supervisory authority's guidance.

The Snowflake case offers a rare, concrete deterrence data point: a successful prosecution of a cloud supply-chain attacker, with documented losses exceeding USD 9.5 million. For clinical trial sponsors, the lesson is not primarily about criminal enforcement. It is about the contractual architecture that determines whether a vendor's security failure becomes the sponsor's regulatory problem. A robust data processing agreement (DPA) clinical trials document, built around specific technical requirements and active vendor governance, is the instrument that separates a manageable incident from a GDPR enforcement action.

Ready to audit your clinical trial DPAs? Iliomad's clinical trials data protection team reviews controller-processor contracts against GDPR Article 28, EU CTR 536/2014 and local supervisory authority guidance, and delivers a gap report with prioritised remediation actions. Contact us to book a DPA review.