ICF Data Protection Language for Site-to-Vendor Transfers: Attributing SCCs to the Correct Entity

Informed consent forms (ICFs) used in clinical trials frequently contain errors in the attribution of international data transfer safeguards. Specifically, ICFs drafted on behalf of a sponsor often reference the sponsor's own Standard Contractual Clauses (SCCs) when describing transfers that, in legal and operational reality, originate from the study site to a third-party vendor. This article explains the compliance gap, the applicable legal framework and the recommended practice for all future ICF drafting.

What are Standard Contractual Clauses and why does their attribution in an ICF matter?

Standard Contractual Clauses (SCCs) are pre-approved contractual mechanisms adopted by the European Commission under Article 46(2)(c) of Regulation (EU) 2016/679 (the General Data Protection Regulation, hereinafter GDPR) that allow controllers and processors to transfer personal data to third countries without an adequacy decision. The current SCCs were adopted by Commission Implementing Decision (EU) 2021/914 of 4 June 2021 and replaced all prior sets of model clauses.

In a clinical trial, an ICF is the document through which a participant is informed, prior to enrolment, of the nature of all processing activities that will affect their personal data, including any international transfers of that data. Article 13(1)(f) of the GDPR requires the data controller to inform data subjects, at the time their data is collected, of any intended transfers to third countries and of the existence or absence of an adequacy decision, or, where transfers are based on Article 46 safeguards, of the appropriate safeguards and the means by which to obtain a copy of them.

Attributing the wrong safeguard mechanism to the wrong entity is therefore not a matter of drafting style. It is a failure to fulfil the transparency obligation imposed by Article 13 GDPR, and it risks invalidating the consent and the transparency notice simultaneously.

What compliance gap arises when a sponsor's SCCs are cited for site-to-vendor transfers?

The compliance gap arises because the sponsor's SCCs do not cover transfers in which the sponsor is not a party to the relevant data-exporter role. Where a study site collects and transmits participant data directly to a vendor (for example, an electronic patient-reported outcome provider, a central laboratory or a biomarker analysis platform), the legal relationship in that transfer chain is between the study site, acting as data exporter, and the vendor, acting as data importer. The sponsor may act as a data controller for the overall study, but it is not the data exporter in that specific transfer.

A real-world compliance review identified precisely this situation in the context of a German-language ICF for a clinical oncology programme. The ICF draft, prepared by the compliance team, referenced the sponsor's documented SCC agreements as the transfer safeguard for all international data flows. However, a closer review of the actual transfer architecture confirmed that the sponsor had not executed SCC agreements that extended to the site-to-vendor relationship. The sponsor was not the data importer in those transfers, and therefore the SCCs the sponsor held were legally irrelevant to them. The applicable safeguard, if any, would need to be put in place by the study site as data exporter.

This finding had two consequences: first, an identified compliance gap under Article 13(1)(f) GDPR, because participants were being informed of a safeguard that did not apply to their data; second, an impact on operational delivery, because the ICF required immediate amendment before it could be used at any German investigational site.

Focus: The Example of Germany

Germany presents a particularly stringent environment for clinical trial data protection. The Bundesdatenschutzgesetz (BDSG), the German Federal Data Protection Act, supplements the GDPR at national level and is enforced by sixteen Länder-level data protection authorities as well as the Federal Commissioner for Data Protection and Freedom of Information (BfDI). German ethics committees, which review ICFs under both the GDPR and the EU Clinical Trials Regulation 536/2014 (EU CTR), have a well-documented practice of scrutinising transfer-related language with care. An ICF that references a sponsor's SCCs for transfers to which the sponsor is not a party is likely to be queried or rejected during the ethics committee review process. Under Article 28 of Regulation (EU) No 536/2014, the sponsor is responsible for ensuring that the ICF contains accurate information about all relevant aspects of the trial, including data transfers. An inaccurate transfer description therefore also engages the sponsor's obligations under the EU CTR, not only its obligations under the GDPR.

How should transfer safeguards be described in a clinical trial ICF when the study site is the data exporter?

When the study site is the entity that transfers participant data to a vendor located in a third country, the ICF should attribute responsibility for the appropriate safeguards to the study site, not to the sponsor. This is the legally accurate position and the one that satisfies Article 13(1)(f) GDPR.

In practical terms, this means that the relevant ICF section should state, in substance, that the study site will put in place appropriate safeguards, such as Standard Contractual Clauses, before transferring participant data to vendors located outside the European Economic Area (EEA). The specific mechanism need not always be named with precision in the ICF, provided the language is accurate and participants are directed to a contact point from whom they may obtain further details. However, where SCCs are named, they must be attributed to the correct exporting entity.

The following table contrasts the two drafting approaches and their legal effect:

‍

‍

The key principle is that the description in the ICF must match the actual transfer architecture. Before finalising any ICF that references SCCs, the drafting team should confirm, by reference to the data flow map and the executed agreements, which entity holds the SCC in the relevant transfer relationship.

What is the recommended practice for ICF drafting teams going forward?

The recommended practice is to conduct a transfer architecture review at the outset of ICF drafting for every study and every country, rather than assuming that a sponsor's existing SCC portfolio covers all transfers associated with the study.

The following steps reflect best practice:

Step 1: Map the actual data flows. For each category of participant data and each vendor to whom that data flows, identify the data exporter (the entity that initiates the transfer) and the data importer (the entity in the third country that receives the data). This mapping should distinguish clearly between flows from the sponsor to vendors and flows from the study site to vendors.

Step 2: Confirm which entity holds the relevant transfer safeguard. Where a vendor is located in a third country, confirm whether it is the sponsor or the study site that has executed the applicable SCCs or alternative Article 46 GDPR mechanism with that vendor. Do not assume that a sponsor's general SCC programme covers site-to-vendor transfers unless the executed agreements expressly reflect this.

Step 3: Draft the ICF transfer language to reflect step 1 and step 2 accurately. Where the study site is the data exporter for certain flows, attribute the responsibility for safeguards to the study site. Where the sponsor is the data exporter, attribute the safeguards to the sponsor. Where both relationships exist within a single study, the ICF may need to address each category of transfer separately.

Step 4: Document the review. Record the conclusions of the transfer architecture review in the study's data protection documentation, such as the Record of Processing Activities maintained pursuant to Article 30 GDPR or the Data Protection Impact Assessment (DPIA) conducted pursuant to Article 35 GDPR. This documentation supports accountability under Article 5(2) GDPR and provides an audit trail for supervisory authorities and ethics committees.

Step 5: Apply this approach consistently across studies. Once a transfer architecture approach has been agreed and validated for a particular study programme, apply the same logic to all country-specific ICF adaptations unless the transfer structure changes. Any change to the vendor landscape or the contractual arrangements should trigger a reassessment of the ICF transfer language.

Focus: The Example of Germany (Continued Operational Implications)

In Germany, the operational impact of miscategorised transfer language extends beyond the ethics committee review. German investigational sites, which typically act as independent data controllers or joint controllers for clinical trial data under the BDSG and the GDPR, may themselves be subject to audit by their Länder data protection authority. If the ICF in use at the site attributes transfer safeguards to the sponsor rather than to the site, and the site is in fact the data exporter, the site could be found to be operating without a valid transfer mechanism for those flows. Under Article 83(4) GDPR, infringements of Article 13 may attract administrative fines of up to EUR 10 million or 2% of total worldwide annual turnover, whichever is higher. Responsibility for such a finding could fall on the study site, the sponsor or both, depending on the controller and processor arrangements in the clinical site agreement.

‍

For expert support with ICF drafting, transfer architecture mapping, DPIA preparation and clinical trial data protection compliance across EU member states, contact iliomad's clinical trials data protection team.