Zusammenfassung
Die EU-Verordnung über klinische Prüfungen (CTR, Verordnung 536/2014) ist inzwischen vollständig anwendbar. Seit Januar 2025 müssen alle klinischen Prüfungen in der Europäischen Union über das Clinical Trials Information System (CTIS) eingereicht und verwaltet werden. Dieses zentrale EMA-Portal ersetzt 27 getrennte nationale Verfahren. Für eClinical-SaaS-Anbieter – darunter EDC-Systeme, Plattformen für elektronische Trial Master Files (eTMF), CTMS sowie IRT/RTSM-Lösungen – ist CTR-Compliance verpflichtend und umfasst eine von vielen Anbietern unterschätzte Dimension der Datenarchitektur.
Die CTR schreibt keine Verschlüsselungsstandards vor. Sie gilt jedoch im Rahmen der DSGVO, die dem Risiko angemessene technische Maßnahmen verlangt. Die in der Verordnung verankerten Erwartungen an Datensouveränität – einschließlich des Zugriffs zuständiger nationaler Behörden auf Anforderung – wirken sich unmittelbar darauf aus, wie Patientendaten gespeichert, verschlüsselt und kontrolliert werden. Zusammen mit dem ungelösten Konflikt zwischen den Übermittlungsvorgaben der DSGVO und dem US CLOUD Act entsteht für eClinical-SaaS-Unternehmen auf US-Hyperscalern ein strukturelles Problem: Ihre Architektur kann mit den durch die CTR begründeten Datenzugriffspflichten rechtlich unvereinbar sein.
Kundenseitig kontrollierte Verschlüsselung – konkret BYOK mit HSM-gestützter, rechtlich isolierter Schlüsselverwaltung – ist die architektonische Antwort auf diesen Konflikt. Dieses Whitepaper erläutert die Gründe und die Konsequenzen für Ihre Plattform.
1. Die CTR in Kraft: Was sich 2025 geändert hat
Die Verordnung (EU) Nr. 536/2014 ersetzte die Richtlinie 2001/20/EG. Zuvor mussten Sponsoren in jedem EU-Mitgliedstaat, in dem eine Prüfung stattfinden sollte, getrennte Genehmigungen der zuständigen Behörde und Ethikkommission einholen. Die CTR führte über CTIS ein einheitliches Antragsverfahren mit koordinierter Bewertung durch die Mitgliedstaaten und festgelegten Genehmigungsfristen ein.
Die Verordnung trat im Januar 2022 mit einer dreijährigen Übergangsfrist in Kraft. Seit Januar 2025 müssen alle neuen Prüfungen das CTIS-Verfahren nutzen; nach der alten Richtlinie genehmigte Prüfungen wurden migriert oder abgeschlossen.
Für eClinical-SaaS-Unternehmen ergeben sich aus der vollständigen Anwendbarkeit der CTR insbesondere folgende praktische Auswirkungen:
Über CTIS eingereichte Daten sind für alle relevanten zuständigen nationalen Behörden (NCA) und die EMA zugänglich. Dadurch entsteht ein föderiertes Datenzugriffsmodell, das sich grundlegend von den bilateralen Beziehungen zwischen Sponsor und Behörde unter der Richtlinie unterscheidet.
Prüfungsdaten müssen nach Abschluss der Prüfung mindestens 25 Jahre archiviert werden (Artikel 58). Diese Aufbewahrungspflicht gilt für das vollständige Dossier des Prüfpräparats, nicht nur für veröffentlichte Ergebnisse. eClinical-Plattformen, die als führende Systeme für Prüfungsdaten dienen, übernehmen diese Archivierungspflicht in ihrer Leistungskette.
Aufgrund der Transparenz- und Veröffentlichungspflichten nach Artikel 37 und 38 CTR müssen Prüfungsergebnisse einschließlich zusammenfassender Daten auf Patientenebene innerhalb festgelegter Fristen an CTIS übermittelt werden. Die Daten müssen in zugänglichen, maschinenlesbaren Formaten vorliegen.
Keine dieser Anforderungen ist rein technischer Natur. Jede hat jedoch Folgen für die Datenarchitektur: Wer darf unter welchen Bedingungen auf welche Daten zugreifen, und wie wird dies protokolliert?
2. Das Problem der Datensouveränität bei US-basierten Cloud-Plattformen
Die meisten eClinical-SaaS-Unternehmen, darunter viele europäische Gründungen, betreiben ihre Infrastruktur auf AWS, Azure oder Google Cloud, häufig in Regionen außerhalb der EU. Aus DSGVO-Sicht ist dies nicht grundsätzlich problematisch, sofern geeignete Übermittlungsmechanismen (SCC, TIA) bestehen. An der Schnittstelle von CTR und DSGVO entsteht jedoch ein besonderer Souveränitätskonflikt, den die Wahl einer Cloud-Region allein nicht löst.
Der US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) ermöglicht US-Strafverfolgungsbehörden, Cloud-Anbieter mit Hauptsitz in den USA zur Herausgabe weltweit gespeicherter Daten zu verpflichten, auch aus EU-Regionen. Damit können US-Behörden nach US-Recht potenziell auf in EU-Regionen von AWS, Azure oder Google Cloud gehostete Daten klinischer Prüfungen zugreifen – unabhängig vom Schutz der DSGVO.
Der Europäische Datenschutzausschuss hat klargestellt, dass eine Speicherung in EU-Regionen diesen Konflikt nicht löst, wenn der Cloud-Anbieter US-Recht unterliegt. Schrems II bestätigte, dass für die Bewertung des Übermittlungsrisikos der Rechtsrahmen des Datenimporteurs und nicht nur der physische Speicherort entscheidend ist.
Für eClinical-SaaS-Anbieter entsteht daraus ein konkretes Risiko: Sponsoren, die nach DSGVO Verantwortliche für Patientendaten sind, verlangen zunehmend vertragliche Zusicherungen, dass Nicht-EU-Stellen nicht aufgrund außereuropäischen Rechts auf ihre Daten zugreifen können. Kann Ihre Plattform dies nicht architektonisch gewährleisten, verlieren Sie Aufträge großer EU-Pharmaunternehmen an entsprechend aufgestellte Wettbewerber.
Die architektonische Lösung besteht nicht darin, Hyperscaler zu verlassen; das wäre operativ unpraktikabel und wirtschaftlich nicht wettbewerbsfähig. Stattdessen muss der Hyperscaler aus der Kette der Verschlüsselungsschlüssel entfernt werden.
3. Kontrolle über Verschlüsselungsschlüssel als Souveränitätsmechanismus
In einer standardmäßigen Cloud-KMS-Konfiguration verwaltet der Cloud-Anbieter die Verschlüsselungsschlüssel. Ruhende Daten in S3, Azure Blob Storage oder Google Cloud Storage sind verschlüsselt, die Schlüssel werden jedoch vom Cloud-Anbieter gehalten und verwaltet. Eine CLOUD-Act-Anordnung an den Anbieter kann daher Daten im Klartext ergeben.
Bei BYOK mit extern verwalteten Schlüsseln hält der Cloud-Anbieter nur Chiffretext. Die Verschlüsselungsschlüssel befinden sich in einem HSM außerhalb seiner Infrastruktur, betrieben von einem nicht dem US-Recht unterliegenden Rechtsträger. Eine CLOUD-Act-Anordnung liefert somit Chiffretext, der ohne den dem Cloud-Anbieter nicht vorliegenden Schlüssel nicht entschlüsselt werden kann.
Diese Architekturänderung entfaltet rechtliche Wirkung, weil sie den Cloud-Anbieter aus der Datenzugriffskette entfernt. Für die DSGVO bedeutet dies: Selbst wenn der Anbieter Daten herausgeben muss, handelt es sich um unverständlichen Chiffretext statt nutzbarer personenbezogener Daten. Die Datensouveränität ist technisch gewährleistet und nicht nur vertraglich zugesichert.
Für eClinical-SaaS-Anbieter erfüllt BYOK mit extern verwalteten Schlüsseln gleichzeitig die Anforderungen dreier Gruppen:
Sponsoren als Verantwortliche erhalten eine nachweisbare technische Garantie, dass weder der Cloud-Anbieter noch über ihn handelnde US-Strafverfolgungsbehörden auf Patientendaten zugreifen können. Damit erfüllen sie ihre eigenen Datenschutzpflichten gegenüber betroffenen Personen.
Zuständige nationale Behörden erhalten eine Architektur, die Daten klinischer Prüfungen unter rechtlicher Kontrolle der EU hält und den in der CTR verankerten Erwartungen an Datensouveränität entspricht.
Der eClinical-Anbieter kann die von Einkaufsteams großer Pharmaunternehmen zunehmend vor Vertragsabschluss gestellte Frage „Wo liegen meine Daten und wer kann darauf zugreifen?“ belastbar beantworten.
4. Bedeutung für Anbieter von EDC, eTMF, CTMS und IRT
Je nach Sensibilität und regulatorischer Bedeutung der gespeicherten Daten wirkt sich die CTR-Frage der Datensouveränität auf die Kategorien von eClinical-Plattformen unterschiedlich aus.
Electronic-Data-Capture-Systeme (EDC) speichern klinische Primärdaten auf Patientenebene, die nach Artikel 9 DSGVO zu den besonderen Kategorien personenbezogener Daten gehören. Dies ist die höchste Sensibilitätsstufe. EDC-Anbieter unterliegen den strengsten Souveränitätspflichten und der intensivsten regulatorischen Prüfung. Für Anbieter in regulierten EU-Märkten ist BYOK praktisch unverzichtbar.
Electronic-Trial-Master-File-Systeme (eTMF) enthalten die wesentlichen Dokumente der regulatorischen Prüfungsakte. Nach Artikel 58 CTR ist diese Akte 25 Jahre zu archivieren. Der lange Aufbewahrungszeitraum und die regulatorische Bedeutung der Dokumente machen Datensouveränität bei eTMF insbesondere für die Langzeitarchivierung architektonisch relevant.
Clinical Trial Management Systems (CTMS) enthalten Betriebs- und Prüfstellendaten, die seltener patientenidentifizierende Informationen, aber häufig wirtschaftlich sensible Protokoll- und Prüfstelleninformationen umfassen. Datensouveränität ist hier sowohl wirtschaftlich als auch regulatorisch relevant.
IRT/RTSM-Systeme (Interactive Response Technology / Randomization and Trial Supply Management) speichern Randomisierungscodes und Behandlungszuweisungen, die für die Integrität der Prüfung entscheidend sind. Unbefugter Zugriff auf entblindete Randomisierungsdaten kann die wissenschaftliche Validität gefährden. Die Schlüsselverwaltung für IRT-Systeme betrifft daher neben dem Datenschutz auch die wissenschaftliche Integrität.
Die praktische Anforderung ist stets gleich: Der eClinical-Anbieter muss einem Sponsor wahrheitsgemäß zusichern können, dass der Cloud-Anbieter keinen Zugriff auf Klartextdaten hat und das Sicherheitsteam des Kunden den Schlüsselzugriff kontrollieren und bei Bedarf entziehen kann.
5. BYOK für eClinical-Plattformen implementieren: Architekturüberlegungen
Die BYOK-Implementierung für eine eClinical-SaaS-Plattform erfordert Entscheidungen auf mehreren Ebenen des Technologie-Stacks.
Schlüsselumfang. Zunächst ist festzulegen, welche Daten durch kundenseitig kontrollierte Schlüssel geschützt werden. Bei EDC-Systemen sollten dies alle Patientendaten sein, mindestens sämtliche besonderen Kategorien nach Artikel 9 DSGVO. Bei eTMF und CTMS bestimmen die vertraglichen Anforderungen des Sponsors und die Datenklassifizierungsrichtlinie der Plattform den Umfang.
Schlüssel-Mandantenmodell. Die meisten eClinical-Plattformen bedienen mehrere Sponsoren auf gemeinsamer Infrastruktur. Die Schlüsselarchitektur sollte Schlüssel je Sponsor isolieren: Die Daten jedes Sponsors werden mit Schlüsseln verschlüsselt, die ausschließlich dessen Sicherheitsteam kontrolliert. Mandantenfähigkeit ist damit auch auf der Verschlüsselungs- und nicht nur auf der Anwendungsebene erforderlich.
Cloud-KMS-Integration. Native BYOK-Integrationen mit AWS KMS External Key Store (XKS), Azure Key Vault Managed HSM BYOK und Google Cloud KMS External Key Manager ermöglichen kundenseitig kontrollierte Schlüssel für alle cloud-nativen Verschlüsselungsoperationen, darunter Speicher, Datenbanken und Message Queuing, ohne Änderungen an der Anwendungsebene. Das Cloud KMS führt die Operationen mit dem externen Schlüssel aus, der das externe HSM niemals verlässt.
Schlüssel-Governance und Lebenszyklus. Kundenseitig kontrollierte Schlüssel benötigen zugängliche Governance-Funktionen für Rotation, Sperrung und Widerruf. Der externe Schlüsselverwaltungsdienst muss diese Funktionen dem Sicherheitsteam des Sponsors praktisch nutzbar bereitstellen – über eine API, eine Verwaltungskonsole oder einen delegierten Managed Service.
Audit-Protokollierung. Jeder Schlüsselzugriff muss mit Identität des Anfragenden (Cloud-Dienst), verwendetem Schlüssel, betroffenem Datenobjekt (soweit identifizierbar) und Zeitstempel protokolliert werden. Die Protokolle müssen für behördliche Prüfungen exportierbar sein. Nach den Audit-Trail-Anforderungen der CTR und den Datenintegritätsstandards der GCP (ICH E6(R3)) ist diese Protokollierung verpflichtend.
Langfristige Schlüsselverfügbarkeit. Die 25-jährige Archivierungspflicht der CTR stellt die Schlüsselverwaltung vor eine oft übersehene Herausforderung: Schlüssel für archivierte Daten müssen über den gesamten Zeitraum verfügbar bleiben oder die Daten sicher mit neuen Schlüsseln erneut verschlüsselt werden. Jede BYOK-Architektur für eClinical-Plattformen muss daher eine langfristige Schlüsselverwahrung vorsehen.
6. Wie Alcazarix die Datensouveränität im eClinical-Bereich unterstützt
Alcazarix bietet Managed BYOK als Service mit den für eClinical-CTR-Compliance erforderlichen architektonischen und rechtlichen Eigenschaften.
Unsere Schlüsselverwaltungsinfrastruktur läuft in zwei rechtlich isolierten Umgebungen: Alcazarix Canada für nordamerikanische und Alcazarix Germany für EU-Bereitstellungen. Sie werden jeweils von den getrennten Rechtsträgern Alcazarix, Inc. und Alcazarix Europe B.V. betrieben. Unter von Alcazarix Europe B.V. verwalteten Schlüsseln verschlüsselte EU-Prüfungsdaten unterliegen somit ausschließlich europäischem Recht; es gibt keine US-Muttergesellschaft, die nach US-Überwachungs- oder Strafverfolgungsrecht verpflichtet werden könnte.
Wir unterstützen nativ die Schlüsselisolierung je Sponsor. eClinical-SaaS-Anbieter können so eine mandantenfähige Schlüsselverwaltung implementieren, in der jeder Sponsor seinen eigenen Schlüssel-Namespace kontrolliert. Dies entspricht der GCP-Erwartung, dass Sponsoren die Kontrolle über ihre Prüfungsdaten behalten.
Unsere Integrationen mit AWS KMS XKS, Azure Key Vault Managed HSM BYOK und Google Cloud KMS EKM decken die Cloud-Plattformen ab, auf denen die meisten eClinical-SaaS-Lösungen betrieben werden, ohne Änderungen an der Anwendungsebene. Schlüsseloperationen erfolgen in der Alcazarix-Infrastruktur; Schlüssel verlassen unsere HSMs niemals im Klartext.
Für die Langzeitarchivierung bieten wir Schlüsselverwahrungsvereinbarungen zur 25-jährigen Aufbewahrungspflicht, einschließlich dokumentierter Verfahren für Neuverschlüsselung und langfristige Übertragung der Schlüsselverwahrung.
Alcazarix ist eine gezielt entwickelte Alternative zu etablierten HSM-Anbietern. Wir verlangen weder On-Premises-HSM-Hardware noch den Aufwand einer FIPS-Zertifizierung oder gerätebasierte Preismodelle, durch die Thales und Utimaco für SaaS-Bereitstellungsmodelle unwirtschaftlich werden.
7. Fazit
Mit der vollständigen Anwendbarkeit der EU CTR im Jahr 2025 wurde Datensouveränität für eClinical-SaaS-Anbieter von einem Zukunftsthema zur aktuellen Pflicht. Die Kombination aus DSGVO-Übermittlungsvorgaben, dem Zugriff des US CLOUD Act auf Cloud-Speicher in EU-Regionen und dem föderierten Zugriffsmodell der CTR schafft ein strukturelles Problem, das Verträge allein nicht lösen können. Es erfordert eine architektonische Antwort.
Kundenseitig kontrollierte Verschlüsselung – BYOK mit HSM-gestützter, rechtlich isolierter externer Schlüsselverwaltung – ist diese Antwort. Sie entfernt den Cloud-Anbieter aus der Datenzugriffskette, schafft eine nachweisbare technische Garantie europäischer rechtlicher Kontrolle und ermöglicht eClinical-SaaS-Anbietern, die Datensouveränitätsfragen großer EU-Pharmakunden vor Vertragsabschluss überzeugend zu beantworten.
Diese Architektur sollte nicht erst aufgebaut werden, wenn ein Sponsor sie in einem Beschaffungsfragebogen verlangt. Der richtige Zeitpunkt ist jetzt, solange CTR-Compliance-Programme noch finalisiert werden und die Architektur von Anfang an integriert statt nachträglich ergänzt werden kann.
Weitere Informationen darüber, wie Alcazarix die Datensouveränität im eClinical-Bereich unterstützt, erhalten Sie unter hello@alcazarix.com oder auf alcazarix.com.