SaaS im GMP-Umfeld: Was der Vertrag mit dem Softwareanbieter regeln muss

Das folgende Beispiel ist fiktiv. Es dient dazu, die vertraglichen Fragen an einem zusammenhängenden Sachverhalt zu erläutern.

Ein Arzneimittelhersteller verwendet eine SaaS-Anwendung zur Führung elektronischer Chargenprotokolle. Die Produktion dokumentiert Arbeitsschritte und Prüfergebnisse in der Anwendung. Die Qualitätssicherung prüft die erfassten Informationen, bevor die Charge zur abschließenden Bewertung vorgelegt wird.

Der Anbieter betreibt die Anwendung in einer externen Cloud-Umgebung. Er übernimmt technische Wartung, Datensicherung und Softwareupdates. Der Hersteller legt die fachlichen Vorgaben fest und verantwortet die Verwendung des Systems in seinem GMP-Prozess.

Bei einer Behördeninspektion soll die Änderungshistorie einer Charge eingesehen werden. Gleichzeitig ist der SaaS-Dienst aufgrund einer Störung nicht erreichbar.

Nun entscheidet sich, was der Vertrag tatsächlich regelt: Können die benötigten Aufzeichnungen unabhängig von der laufenden Anwendung bereitgestellt werden? Wer ist für die Wiederherstellung zuständig? Welche Frist gilt? Welche Informationen erhält der Hersteller über Ursache und Auswirkungen der Störung?

Diese Fragen entstehen nicht erst mit dem Ausfall. Sie müssen bereits bei Vertragsabschluss beantwortet werden.

EU-GMP Annex 11 gilt für computergestützte Systeme, die im Rahmen GMP-regulierter Tätigkeiten eingesetzt werden. Die Validierung der Anwendung und die Qualifizierung der IT-Infrastruktur sind dabei zu unterscheiden. [1]

Annex 11 Nr. 3.1 verlangt formelle Vereinbarungen, wenn Dritte Leistungen im Zusammenhang mit computergestützten Systemen erbringen. Dazu zählen unter anderem Bereitstellung, Konfiguration, Integration, Validierung, Wartung, Änderung, Aufbewahrung und Datenverarbeitung. Die Verantwortlichkeiten des Dienstleisters müssen klar festgelegt sein.

Daneben regelt EU-GMP Kapitel 7 ausgelagerte Tätigkeiten. Nach Nr. 7.4 und 7.5 muss der Auftraggeber die ausgelagerten Tätigkeiten kontrollieren sowie Eignung und Kompetenz des Auftragnehmers bewerten. Nr. 7.16 betrifft die Verfügbarkeit der zugehörigen Aufzeichnungen und Nr. 7.17 das vertraglich zu ermöglichende Audit. [2]

Nicht jede SaaS-Leistung ist jedoch automatisch eine ausgelagerte Herstellung oder Prüfung im Sinne sämtlicher Vorschriften des Kapitels 7. Die konkrete Einordnung richtet sich nach dem Leistungsgegenstand. Für die Einbindung eines IT-Dienstleisters enthält Annex 11 Nr. 3 den unmittelbar einschlägigen Ausgangspunkt.

Im deutschen Recht sind ergänzend die jeweils anwendbaren Bestimmungen der AMWHV zu beachten. § 9 regelt Tätigkeiten im Auftrag. § 10 Abs. 2 enthält Anforderungen an elektronische Aufzeichnungssysteme, darunter Validierung sowie Verfügbarkeit und Lesbarkeit der aufbewahrungspflichtigen Daten. [3]

Auch die Sachkundige Person (Qualified Person, QP) behält ihre gesetzlich zugewiesene Verantwortung. Der Bezug einer Cloud-Anwendung verlagert die Chargenbewertung und Zertifizierung nicht auf den Softwareanbieter.

Das System liefert allerdings die Informationsgrundlage für diese Entscheidung. Vollständigkeit der Daten, Audit Trail, Berechtigungen und elektronische Signaturen müssen deshalb kontrolliert sein.

Mit „Hersteller“ ist in diesem Beitrag der Inhaber der Herstellungserlaubnis gemeint. Intern sollten die Zuständigkeiten – etwa Systemeigner, Qualitätssicherung und sachkundige Person – im Vertrag und in der Qualitätssicherungsvereinbarung konkret benannt werden.

Im Beispielsfall kann sich der Hersteller daher gegenüber der Behörde nicht allein darauf berufen, sein SaaS-Anbieter sei für die technische Verfügbarkeit zuständig.

Vor Vertragsabschluss ist zu bestimmen, welche Funktionen der Anbieter übernimmt und welches Risiko mit deren Ausfall oder fehlerhafter Ausführung verbunden ist.

Ausgangspunkt ist eine Beschreibung der tatsächlich erbrachten Leistung:

• Welche GMP-relevanten Prozesse hängen vom Dienst ab?
• Welche Daten, Metadaten und Audit Trails verarbeitet der Anbieter?
• Welche administrativen Rechte hat er, und darf er Konfiguration, Schnittstellen oder Datenstrukturen ändern?
• Welche Unterauftragnehmer sind eingebunden?

Ein Anbieter, der lediglich Infrastruktur bereitstellt, ist anders zu bewerten als ein Anbieter, der die Anwendung administriert und Änderungen einspielt.

Annex 11 Nr. 3.2 stellt bei der Anbieterauswahl auf Kompetenz und Zuverlässigkeit ab. Ob ein Audit erforderlich ist, richtet sich nach einer Risikobewertung. Daraus folgt keine allgemeine Pflicht, jeden SaaS-Anbieter vor Vertragsschluss vor Ort zu auditieren. [1]

Eine risikobasierte Lieferantenqualifizierung kann Anbieterfragebögen, Qualitätsnachweise, Bewertungen der Entwicklungs- und Änderungsprozesse, dokumentierte Prüfungen und Audits umfassen.

Für die elektronische Chargendokumentation sind insbesondere der Softwareentwicklungslebenszyklus, die Änderungskontrolle, die Release-Dokumentation, die Datensicherung und das Wiederherstellungsverfahren relevant.

Annex 11 Nr. 3.3 verlangt die Prüfung der vom Anbieter bereitgestellten Dokumentation handelsüblicher Software anhand der Nutzeranforderungen. Nach Nr. 3.4 müssen einschlägige Qualitätssystem- und Auditinformationen zu Softwareanbietern beziehungsweise Entwicklern für Inspektoren auf Anforderung verfügbar sein. [1]

ICH Q10 Abschnitt 2.7 ordnet die Bewertung und Überwachung ausgelagerter Tätigkeiten und eingekaufter Materialien in das pharmazeutische Qualitätssystem ein. [4]

Im Beispielsfall sollte der Hersteller deshalb nicht lediglich nach einer allgemeinen Zertifizierung des Cloud-Anbieters fragen. Er benötigt geeignete Nachweise dazu, wie die konkret genutzte Anwendung entwickelt, geändert, betrieben und nach einem Ausfall wiederhergestellt wird.

Der Vertrag sollte beschreiben, welche Leistungen, Systeme, Dokumentationen und Unterauftragnehmer Gegenstand einer Prüfung sein können.

Zu unterscheiden sind das Audit des Herstellers beim Dienstleister und der Informationszugang zuständiger Behörden. Annex 11 Nr. 3.4 betrifft ausdrücklich die Verfügbarkeit bestimmter Anbieterinformationen für Inspektoren.

Soweit zusätzlich EU-GMP Kapitel 7 auf eine konkret ausgelagerte Tätigkeit anwendbar ist, ist dessen Auditregelung nach Nr. 7.17 zu beachten. [2]

Bei mehrstufigen Cloud-Leistungen entsteht eine besondere Schwierigkeit: Der unmittelbare SaaS-Anbieter kann Hosting und Datensicherung an weitere Unternehmen vergeben, auf deren Einrichtungen und Dokumentationen er selbst nur beschränkt zugreifen darf.

Ein vertraglich zugesichertes Auditrecht muss daher zu den tatsächlich bestehenden Zugriffsmöglichkeiten passen. Alternativ sind geeignete, risikogerechte Prüfunterlagen und Nachweisverfahren zu vereinbaren. Praktisch ausübbar heißt auch: Vorankündigungsfristen, der Ablauf bei Behördeninspektionen und die Herausgabe relevanter Nachweise sind ausdrücklich geregelt.

Für den Hersteller elektronischer Chargenprotokolle ist insbesondere entscheidend, ob die benötigten System- und Qualitätsinformationen auch bei einer kritischen Störung oder einer behördlichen Nachfrage verfügbar sind.

Die Anforderungen an elektronische Aufzeichnungen bestehen unabhängig davon, ob die Daten auf eigenen Servern oder in einer SaaS-Umgebung gespeichert werden.

§ 10 Abs. 2 AMWHV verlangt im einschlägigen Anwendungsbereich, dass elektronisch gespeicherte Daten während der Aufbewahrungsfrist verfügbar sind und innerhalb einer angemessenen Frist lesbar gemacht werden können. [3]

Dass nicht verfügbare elektronische Daten bei Inspektionen tatsächlich beanstandet werden, zeigt etwa ein Warning Letter der US-Arzneimittelbehörde FDA vom 10. März 2025 an die International Laboratories Corp. in Thailand: Die Inspektoren dokumentierten mehrere elektronische Ergebnisse, die „not available for review“ waren, und der Hersteller hatte vollständige elektronische Rohdaten nicht aufbewahrt (21 CFR 211.68(b)). Ein SaaS-Fall war das nicht – das Grundproblem ist aber dasselbe: Daten, die bei der Inspektion nicht vorgelegt werden können, werden beanstandet. [8]

Beim fiktiven Hersteller fordert ein Inspektor die Änderungshistorie einer Charge an. Der SaaS-Dienst ist nicht erreichbar. Eine Supportmeldung mit dem Hinweis auf eine laufende Störung legt die angeforderten Daten noch nicht vor.

Die Vertragsgestaltung muss deshalb Antworten auf konkrete Fragen ermöglichen:

• Besteht ein geeigneter Notfallzugang zu erforderlichen Aufzeichnungen?
• Können Daten aus einer geprüften Sicherung oder einem geeigneten Archiv lesbar bereitgestellt werden?
• Welche Mitwirkung schuldet der Anbieter bei einer Behördeninspektion?
• Wie sind Wiederherstellung, Eskalation und Dokumentation einer Störung geregelt?

Eine solche Vereinbarung bedeutet nicht, dass in jeder Situation ein zweites vollständiges Produktivsystem betrieben werden muss. Entscheidend ist eine dem Risiko angemessene Vorsorge, die den gesetzlichen Anforderungen an Verfügbarkeit und Lesbarkeit gerecht wird.

Annex 11 Nr. 16 verlangt im GMP-Kontext außerdem Vorkehrungen für die Fortführung kritischer Prozesse bei Ausfällen computergestützter Systeme. [1]

Die bloße Zusage einer monatlichen Verfügbarkeitsquote ersetzt daher keine geeigneten Verfahren zur Bereitstellung erforderlicher Aufzeichnungen.

Bei Cloud-Anwendungen sind der SaaS-Anbieter und der Betreiber der technischen Infrastruktur häufig nicht identisch.

Für den Hersteller ist relevant, wo und durch wen Daten gespeichert, verarbeitet und gesichert werden, welche weiteren Dienstleister beteiligt sind und welche Änderungen der Anbieter an dieser Leistungskette vornehmen darf.

Der Vertrag sollte die maßgeblichen Hosting- und Unterauftragnehmerleistungen transparent beschreiben. Für wesentliche Änderungen können Informationspflichten, Bewertungsfristen sowie abgestufte Zustimmungs- oder Widerspruchsmechanismen vereinbart werden.

Übernimmt der SaaS-Anbieter eine Tätigkeit im Auftrag im Sinne von § 9 AMWHV, darf er ihm übertragene Arbeiten nur mit schriftlicher Genehmigung des Auftraggebers an Dritte weitervergeben (§ 9 Abs. 3 AMWHV). [3]

Nicht jeder neue Rechenzentrumsstandort führt zwangsläufig zu derselben GMP-Bewertung. Entscheidend sind Auswirkungen auf Infrastruktur, Datenintegrität, Verfügbarkeit, Sicherheit und gegebenenfalls den validierten Zustand der Anwendung.

Eine bloße Angabe wie „Hosting innerhalb der EU“ beantwortet diese Fragen nicht vollständig.

Im SaaS-Modell erfolgen Aktualisierungen häufig zentral durch den Anbieter. Funktionen, Schnittstellen oder Datenstrukturen können sich ändern, ohne dass der Hersteller selbst eine Installation veranlasst.

Annex 11 Nr. 10 verlangt ein kontrolliertes Vorgehen bei Änderungen einschließlich der Systemkonfiguration. Nr. 11 sieht die regelmäßige Bewertung computergestützter Systeme vor, unter anderem anhand von Änderungen, Vorfällen und dem Validierungsstatus. [1]

Der Vertrag sollte deshalb regeln, wie Änderungen angekündigt, dokumentiert und bewertet werden. Bei risikorelevanten Änderungen benötigt der Hersteller angemessene Vorlaufzeiten sowie Informationen zu den betroffenen Funktionen und Schnittstellen.

Change Control betrifft dabei nicht nur neue Programmversionen. Auch Änderungen an Infrastruktur, Datenbank oder Sicherheitseinstellungen können GMP-relevant sein, wenn sie Funktion, Verfügbarkeit oder Datenintegrität des Systems berühren. Zu regeln ist außerdem, welche Test- und Validierungsunterlagen der Anbieter bereitstellt und wie Notfalländerungen nachträglich dokumentiert und bewertet werden.

Im fiktiven Chargenprotokoll-System könnte ein Anbieter etwa den Ablauf der elektronischen Freigabe ändern. Der Hersteller muss beurteilen können, ob seine bisherigen Tests, Arbeitsanweisungen und Verantwortlichkeitszuordnungen weiterhin ausreichen.

Das bedeutet nicht, dass jeder Software-Patch eine vollständige Revalidierung auslöst. Umfang und Form der Maßnahmen richten sich nach dem Änderungsrisiko und den betroffenen Funktionen.

Ein Service Level Agreement (SLA) regelt typischerweise Verfügbarkeit, Reaktionszeiten, Wiederherstellungsziele und Supportzeiten. Konkrete Werte dafür schreiben weder die AMWHV noch der EU-GMP-Leitfaden vor; sie sind nach der Kritikalität des betroffenen Prozesses festzulegen.

Für GMP-relevante Anwendungen ist zusätzlich zu klären, welche Auswirkungen eine Störung auf laufende Herstellung, Prüfung und Dokumentation hat.

Der Vertrag sollte definieren, wann der Anbieter über Datenverluste, Integritätsabweichungen, unberechtigte Zugriffe oder erhebliche Systemstörungen informiert. Außerdem ist festzulegen, welche Informationen für Ursachenbewertung, Wiederherstellung und gegebenenfalls CAPA bereitgestellt werden.

Annex 11 Nr. 13 behandelt das Management von Vorfällen. Nr. 16 betrifft die Aufrechterhaltung kritischer Prozesse bei Systemausfällen. [1]

Im fiktiven Fall entscheidet sich bei der fehlenden Änderungshistorie, ob das SLA nur einen technischen Supportfall beschreibt oder auch die qualitätsrelevanten Folgen berücksichtigt.

Service Credits oder Vertragsstrafen ersetzen weder geeignete technische Vorkehrungen noch die erforderliche Mitwirkung bei der Aufklärung.

Die Pflichten zur Aufbewahrung GMP-relevanter Aufzeichnungen können die Laufzeit eines SaaS-Vertrags überdauern.

Für Aufzeichnungen über die Herstellung einschließlich der Freigabe, die Prüfung und das Inverkehrbringen verlangt § 20 Abs. 1 AMWHV eine Aufbewahrung mindestens bis ein Jahr nach Ablauf des Verfalldatums, jedoch nicht weniger als fünf Jahre. Dieselbe Vorschrift sieht die Aufbewahrung in einem geeigneten Bereich der von der Herstellungserlaubnis erfassten Räume vor. Wie diese Anforderung bei Aufzeichnungen erfüllt wird, die in einer externen Cloud-Umgebung gespeichert sind, sollte vor Vertragsschluss geklärt und dokumentiert werden – im Zweifel in Abstimmung mit der zuständigen Überwachungsbehörde. [3]

Der Vertrag sollte daher nicht nur ein allgemeines Recht auf Datenexport vorsehen. Er muss klären, welche Inhalte und Metadaten übergeben werden, welche Formate verwendet werden und ob die Beziehungen zwischen Datensätzen erhalten bleiben.

Ein Export einzelner PDF-Dateien reicht nicht zwangsläufig aus, wenn für die Interpretation auch Änderungshistorien, elektronische Signaturen, Zeitangaben oder Zuordnungen zwischen Chargen, Aufgaben und Ergebnissen erforderlich sind.

Zu regeln sind Übergangsfristen, Unterstützung bei der Migration, technische Zugänglichkeit bis zur vollständigen Übergabe sowie Löschung oder Rückgabe verbleibender Datenbestände. Gelöscht werden sollte erst nach ausdrücklicher Freigabe durch den Hersteller und nach dem Nachweis, dass die Daten vollständig und lesbar übergeben wurden.

Bei einem besonders kritischen, stark individualisierten System kann Source-Code-Escrow als zusätzliche vertragliche Absicherung für bestimmte Ausfallszenarien, etwa eine Anbieterinsolvenz, erwogen werden. Es besteht keine allgemeine GMP-Pflicht zur Quellcodehinterlegung. Bei SaaS reicht hinterlegter Quellcode allein regelmäßig nicht aus; der fortführbare Betrieb benötigt unter Umständen auch Daten, Infrastruktur, Konfiguration und Nutzungsrechte.

Im Beispielsfall muss der Hersteller auch nach einem Anbieterwechsel ältere Chargenprotokolle mitsamt erforderlicher Metadaten lesbar bereitstellen können.

Eine Exit-Klausel ist damit nicht nur wirtschaftliche Vorsorge. Sie dient auch der Fortführung bestehender regulatorischer Verpflichtungen.

SaaS-Verträge enthalten häufig Haftungsbeschränkungen, Ausschlüsse bestimmter Schäden und betragsmäßige Haftungsobergrenzen.

Solche Klauseln sind von der regulatorischen Verantwortungsverteilung zu unterscheiden.

Dass der Hersteller gegenüber der Behörde für seine GMP-relevanten Tätigkeiten verantwortlich bleibt, bedeutet nicht automatisch, dass der Anbieter zivilrechtlich für jede daraus entstehende Folge haftet. Umgekehrt befreit eine vertragliche Haftungsbegrenzung den Hersteller nicht von regulatorischen Pflichten.

Bei der Vertragsprüfung ist daher zu untersuchen, welche Schäden und Pflichtverletzungen erfasst sind, ob die Risikoverteilung zum Leistungsspektrum passt und ob die Klauseln nach dem anwendbaren Recht wirksam sind.

Besondere Aufmerksamkeit verdienen Datenverlust, fehlerhafte Änderungen, längere Nichtverfügbarkeit und Verletzungen von Vertraulichkeits- oder Mitwirkungspflichten.

Eine Aussage zur Wirksamkeit konkreter Haftungsklauseln ist ohne Kenntnis des Vertrags und der jeweiligen Konstellation nicht möglich.

Verarbeitet der SaaS-Anbieter personenbezogene Daten im Auftrag des Herstellers, kann Art. 28 DSGVO eine Auftragsverarbeitungsvereinbarung (AVV) erfordern. [5]

Personenbezogene Daten fallen auch in Produktions- und Qualitätssystemen an, etwa Benutzerkennungen, Daten elektronischer Signaturen oder Audit-Trail-Einträge.

Diese regelt insbesondere datenschutzrechtliche Weisungen, Unterauftragsverarbeiter, Sicherheit der Verarbeitung und Unterstützungspflichten.

Der GMP-relevante Vertragsbedarf betrifft dagegen beispielsweise Validierung, Änderungen, Qualitätssystemdokumentation, Auditierbarkeit und Aufbewahrung chargenbezogener Informationen.

Beide Regelungsbereiche können sich überschneiden. Eine AVV allein bildet die nach Annex 11 erforderliche Verantwortungsverteilung jedoch nicht zwangsläufig ab.

Die benötigten Regelungen müssen nicht zwingend in einem einzigen Vertragsdokument stehen.

Für eine GMP-relevante SaaS-Beauftragung bietet sich eine aufeinander abgestimmte Vertragsarchitektur an:

Die Bezeichnungen allein entscheiden nicht über die Eignung. Entscheidend ist der Inhalt der Vereinbarungen.

Außerdem sollte eine klare Rangfolge für widersprüchliche Vertragsbestimmungen festgelegt werden. Beispielsweise darf eine allgemeine Klausel über jederzeitige Softwareänderungen nicht unbemerkt die speziell geregelte Vorabinformation über qualitätskritische Änderungen aushebeln.

Beim fiktiven Hersteller müssen deshalb Hauptvertrag und Qualitätsvereinbarung zusammenpassen: Wenn die Qualitätsvereinbarung eine rechtzeitige Benachrichtigung bei kritischen Releases fordert, darf der Hauptvertrag diesen Anspruch nicht durch eine entgegenstehende Standardklausel entwerten.

Auch zwingende gesetzliche Anforderungen lassen sich durch eine vertragliche Vorrangregel nicht abbedingen.

Stand: 26. Oktober 2026

Die Europäische Kommission hat vom 7. Juli bis zum 7. Oktober 2025 einen Entwurf zur Überarbeitung von EU-GMP Annex 11 konsultiert. Gegenstand der Konsultation waren außerdem Kapitel 4 zur Dokumentation und ein neuer Annex 22 zur künstlichen Intelligenz. [6]

Die EudraLex-Übersicht führt Annex 11 weiterhin in der Fassung vom Januar 2011. Der Konsultationsentwurf ist deshalb nicht als geltendes Recht zu behandeln.

Der Entwurf sieht unter anderem eine stärkere Strukturierung des Lebenszyklus computergestützter Systeme und des Managements externer Lieferanten und Dienstleister vor. Weitere Themen betreffen Systemanforderungen, Validierung, Datenintegrität, Zugriffsverwaltung, Archivierung und Sicherheit. [7]

Für die Vertragsgestaltung folgen daraus noch keine unmittelbar geltenden neuen Anforderungen. Sinnvoll ist jedoch ein Verfahren, mit dem spätere regulatorische Änderungen bewertet und erforderliche Vertragsanpassungen vereinbart werden können.

Die Tabelle ist eine Orientierung für die Vertragsprüfung, kein vollständiges Vertragsmuster. Die erforderlichen Klauseln richten sich nach der eingesetzten Software, ihren Funktionen, dem regulierten Prozess und den übernommenen Anbieterleistungen.

Ein tragfähiger SaaS-Vertrag im GMP-Umfeld muss nicht möglichst umfangreich sein. Er muss die wesentlichen Abhängigkeiten so regeln, dass der Hersteller seine regulatorischen Aufgaben auch dann erfüllen kann, wenn der Anbieter das System betreibt, verändert oder die Vertragsbeziehung endet.

Autorenhinweis: Hannes Schubert ist Geschäftsführer der NESS Online GmbH, eines Technologieunternehmens für Compliance-Infrastruktur. Der Beitrag erläutert die regulatorische und vertragsrechtliche Perspektive unabhängig von einem konkreten Softwareprodukt. Dieser Fachbeitrag dient der allgemeinen Information und ersetzt keine Rechtsberatung im Einzelfall.