Warum die Pharma-Compliance bei Hyperscalern an ihre Grenzen kommt
Christof Layher
Wer im regulierten Umfeld arbeitet, kennt die Situation.
Cloud wird strategisch gefordert. Digitalisierung sowieso.
Aber sobald es um Supplier Qualification, Audits oder GxP-Compliance geht, fühlt sich alles plötzlich an wie im Jahr 2005.
Im ChaosHacker-Talk mit Robert Geiger-Lebailly ging es genau um dieses Spannungsfeld:
Wie bewertet man Cloud-Provider korrekt, wenn die regulatorische Welt noch auf klassische Lieferantenmodelle ausgelegt ist?
Und die ehrliche Antwort ist:
Mit den aktuellen Methoden wird es zunehmend schwierig.
Das liegt nicht daran, dass Compliance falsch ist.
Es liegt daran, dass sich die Realität schneller verändert hat als unsere Bewertungsmodelle.
Das Grundproblem: GxP wurde nicht für Cloud geschrieben
Viele der heute relevanten Regeln stammen aus einer Zeit, in der IT noch lokal war.
Annex 11
Annex 15
21 CFR Part 11
Sie definieren Anforderungen sinnvoll und notwendig – aber sie gehen implizit davon aus, dass man es mit einem Lieferanten zu tun hat, den man vollständig kontrollieren kann.
Bei klassischen Szenarien funktioniert das:
- Auftragslabor
- Lohnhersteller
- Softwarelieferant mit On-Prem Installation
- lokaler IT-Dienstleister
Bei Cloud-Providern sieht die Realität anders aus.
Ein Hyperscaler betreibt tausende Kunden gleichzeitig.
In mehreren Regionen.
Mit hochstandardisierten Prozessen.
Mit automatisierten Deployments.
Mit globalen Security-Modellen.
Und genau hier beginnt die Reibung.
Supplier Qualification in der Theorie vs. Praxis
In vielen SOPs steht sinngemäß:
- Kritischer Lieferant → Audit erforderlich
- Hohes Risiko → Vor-Ort-Audit
- Lieferant muss vollständig bewertet werden
Das klingt logisch.
Bis man versucht, es umzusetzen.
Versuch mal
- SAP
- Microsoft
- AWS
- Google Cloud
vor Ort zu auditieren.
Rein formal ist die Forderung nachvollziehbar.
Praktisch ist sie kaum umsetzbar.
Deshalb passiert in der Realität oft Folgendes:
- Standardfragebogen wird verschickt
- Antworten passen nur teilweise
- Begriffe werden unterschiedlich verstanden
- Risiko bleibt unklar
- Entscheidung wird trotzdem getroffen
Das ist kein strukturiertes Risikomanagement.
Das ist Improvisation mit Dokumentation.
Gleiche Begriffe – unterschiedliche Bedeutung
Ein Punkt aus dem Gespräch war besonders treffend:
Nur weil zwei Unternehmen das gleiche Wort verwenden, heißt das nicht, dass sie das Gleiche meinen.
Typische Beispiele:
Quality Management
User Access Management
Validation
Change Control
Training
Security
In Pharma bedeutet Quality oft:
- unabhängige QA-Organisation
- formale SOP-Struktur
- dokumentierte Freigaben
- Audit-Trail-basierte Prozesse
In der Cloud bedeutet Quality oft:
- standardisierte Prozesse
- automatisierte Checks
- Control Frameworks
- Zertifizierungen
- Monitoring
Beides kann korrekt sein.
Aber es ist nicht dasselbe.
Wenn man das nicht versteht, bewertet man falsch.
Warum SOC-Reports und Zertifizierungen so wichtig sind
Viele Cloud-Provider arbeiten mit standardisierten Prüfberichten wie
SOC 1
SOC 2
ISO 27001
ISO 9001
ISO 22301
CSA STAR
NIST-Frameworks
Diese Reports sind nicht Marketing.
Sie sind genau dafür gemacht, Vertrauen skalierbar zu machen.
Ein einzelner Kunde kann keinen Hyperscaler vollständig auditieren.
Aber ein unabhängiger Prüfer kann Controls bewerten, die für alle Kunden gelten.
Im Gespräch ging es auch um erweiterte Modelle wie SOC-Reports mit zusätzlichen GxP-Controls, um regulatorische Anforderungen besser abzubilden.
Das ist ein realistischer Weg.
Nicht perfekt.
Aber skalierbar.
Und Skalierbarkeit ist bei Cloud kein Nice-to-Have, sondern Voraussetzung.
Der risikobasierte Ansatz wird oft falsch verstanden
Regulatorisch wird ständig vom risk-based approach gesprochen.
In der Praxis bedeutet das häufig:
kritisch = Audit
hoch kritisch = Vor-Ort-Audit
sehr kritisch = mehr Audit
Das ist kein Risikomanagement.
Das ist Eskalation ohne Differenzierung.
Ein echtes Risiko-Assessment müsste auch fragen:
- Wie transparent ist der Anbieter?
- Wie etabliert ist die Plattform?
- Wie viele Kunden nutzen sie?
- Welche Zertifizierungen existieren?
- Welche Controls sind nachgewiesen?
- Wie stabil ist der Betrieb historisch?
Ein Anbieter mit tausenden Kunden und geprüften Control-Frameworks kann im Supplier-Risiko niedriger sein als ein kleiner, kaum geprüfter Dienstleister.
Das fühlt sich ungewohnt an.
Ist aber logisch.
Warum wir neue Bewertungsmodelle brauchen
Cloud ist kein Sonderfall mehr.
Cloud ist Standard.
Und wenn die Realität Standard ist, kann sie nicht mehr mit Sonderlösungen bewertet werden.
Was wir brauchen:
- klarere Erwartungen an Cloud-Provider
- harmonisierte Supplier-Qualification-Ansätze
- akzeptierte Prüfberichte statt individueller Audits
- echte Risikobewertung statt Checkbox-Compliance
- mehr Dialog zwischen Industrie, Providern und Regulatoren
Nicht weniger Compliance.
Bessere Compliance.
Fazit
Die größte Herausforderung bei der Digitalisierung im regulierten Umfeld ist nicht die Technik.
Es ist die Fähigkeit, unsere Denkmodelle anzupassen.
Solange wir Cloud wie einen Lohnhersteller auditieren,
werden wir immer zwischen Innovation und Regulierung hängen.
Wenn wir anfangen, Regulierung digital zu denken,
wird Compliance nicht schwächer.
Sie wird realistischer.
Video zur Diskussion im ChaosHacker-Talk: