Lieferantenaudit beim Softwareanbieter: Was GMP verlangt und wie weit das Auditrecht reicht
Muss ein GMP-Betrieb seinen Softwareanbieter vor Ort auditieren? Wann Fragebogen, Dokumentenprüfung oder Remote-Audit reichen, wie weit das Auditrecht reicht und wie mit Befunden umzugehen ist.
Kurzfassung: Ein GMP-regulierter Hersteller muss die Eignung und Zuverlässigkeit externer Softwareanbieter risikobasiert beurteilen. Ein Vor-Ort-Audit ist dabei nicht für jeden Anbieter vorgeschrieben. Je nach Kritikalität der Anwendung kommen Fragebögen, dokumentenbasierte Bewertungen, Remote-Audits oder Vor-Ort-Prüfungen infrage. Das Auditrecht wird durch den Prüfzweck, berechtigte Vertraulichkeitsinteressen und die tatsächlich vereinbarten Zugangsrechte begrenzt. Die konkrete Prüfpflicht richtet sich nach dem anwendbaren GMP-Rahmen, der vertraglichen Einbindung und der Kritikalität des Systems.
Wer ein elektronisches Chargenprotokoll, ein Laborinformationssystem oder eine andere GMP-relevante Anwendung einkauft, trifft nicht nur eine technische Beschaffungsentscheidung. Der Betrieb verlässt sich auf die Entwicklungs-, Test-, Änderungs- und Betriebsprozesse eines Dritten.
Wie weit muss er diese Prozesse prüfen?
Das ist eine andere Frage als die Vertragsgestaltung. Der Beitrag zum SaaS-Vertrag im GMP-Umfeld behandelt, welche Leistungen, Informationspflichten und Rechte vertraglich geregelt werden sollten. Hier geht es darum, welche Bewertung im konkreten Einzelfall notwendig ist und was ein Audit wirklich nachweisen kann.
Annex 11 verlangt eine Risikobewertung – nicht immer einen Besuch vor Ort
Der unmittelbar einschlägige Ausgangspunkt ist EU-GMP Annex 11 Nr. 3. Dieser regelt die Einbindung von Lieferanten und Dienstleistern für computergestützte Systeme. [1]
Nr. 3.1 fordert formelle Vereinbarungen mit klarer Verantwortungsverteilung, wenn Dritte entsprechende Leistungen erbringen. Nr. 3.2 nennt Kompetenz und Zuverlässigkeit des Lieferanten als maßgebliche Auswahlfaktoren. Art und Umfang der Lieferantenprüfung sind risikobasiert festzulegen.
Damit folgt aus Annex 11 keine pauschale Verpflichtung, jeden Softwareanbieter jährlich oder vor dem ersten Einsatz persönlich vor Ort zu auditieren.
Ebenso falsch wäre der umgekehrte Schluss, ein allgemeiner Anbieterfragebogen genüge grundsätzlich.
Die erforderliche Prüfung hängt davon ab, welche Rolle das System im GMP-Prozess übernimmt, welche Risiken ein Fehler mit sich bringt und welche Nachweise bereits vorliegen.
Bei einem System, das lediglich unkritische Hilfsinformationen bereitstellt, kann die Bewertung weniger aufwendig ausfallen als bei einer Anwendung, deren Ergebnisse unmittelbar in die chargenbezogene Qualitätsentscheidung eingehen.
Auch der Zugriff auf Stammdaten, elektronische Signaturen, Audit Trails und aufbewahrungspflichtige Aufzeichnungen kann die Kritikalität beeinflussen.
Vier Prüfwege unterscheiden sich in ihrer Aussagekraft
Für die Lieferantenqualifizierung stehen unterschiedliche Instrumente zur Verfügung. Sie beantworten nicht dieselben Fragen.
| Prüfweg | Was er leisten kann | Wesentliche Grenze |
|---|---|---|
| Anbieterfragebogen | Grundlegende Aussagen zu Organisation, Qualitätssystem und Verfahren erheben | Antworten sind zunächst Selbstauskünfte |
| Dokumentenbasierte Bewertung | Konkrete Verfahrensbeschreibungen, Testberichte, Qualitätsnachweise und Änderungsunterlagen prüfen | Die tatsächliche Anwendung der Verfahren bleibt nur begrenzt beobachtbar |
| Remote-Audit | Dokumente vertiefen, Personen befragen, Stichproben und Systemansichten prüfen | Auswahl und Sichtbarkeit können durch den Anbieter eingeschränkt sein |
| Vor-Ort-Audit | Abläufe, Arbeitsumgebung, Rollen und tatsächliche Umsetzung unmittelbar untersuchen | Auch eine Vor-Ort-Stichprobe liefert keinen vollständigen Nachweis aller Vorgänge |
Ein Fragebogen kann eine geeignete erste Stufe sein. Er sollte jedoch nicht mit einer unabhängig überprüften Tatsachenfeststellung gleichgesetzt werden.
Eine dokumentenbasierte Bewertung geht weiter, wenn der Anbieter beispielsweise nachvollziehbare Nachweise zu Änderungskontrolle, Release-Freigaben, Testdurchführung oder Abweichungsbearbeitung vorlegt.
Beim Remote-Audit können verantwortliche Personen interviewt und bestimmte Arbeitsabläufe anhand realer Aufzeichnungen nachvollzogen werden. Ein kontrollierter Lesezugang zu ausgewählten Aufzeichnungen kann die Stichprobenprüfung erleichtern.
Ein Vor-Ort-Audit ermöglicht zusätzliche Beobachtungen, etwa zur tatsächlichen Organisation von Entwicklungs- und Testprozessen oder zur Durchführung festgelegter Kontrollen.
Welcher Prüfweg angemessen ist, sollte aus der begründeten Risikobewertung hervorgehen.
Beispiel: Ein Anbieter betreibt das elektronische Chargenprotokoll
Das folgende Beispiel ist fiktiv.
Ein Arzneimittelhersteller bezieht ein Electronic-Batch-Record-System als SaaS-Dienst. Der Anbieter entwickelt und wartet die Anwendung, betreibt die technische Infrastruktur und spielt neue Versionen ein.
Die Anwendung enthält qualitätsrelevante Chargendaten, dokumentierte Änderungen und Freigabeinformationen.
Die Qualitätssicherung des Herstellers hat eine positive Selbstauskunft des Anbieters erhalten. Sie möchte nun beurteilen, ob die zugesagten Verfahren zur Änderungskontrolle und Softwareprüfung tatsächlich angewendet werden.
Dazu wählt sie eine bereits veröffentlichte Softwareversion und verlangt die zugehörigen Unterlagen: Änderungsantrag, Risikobewertung, Testumfang, Testergebnisse, Abweichungsbehandlung und Freigabeentscheidung.
Im Audit zeigt sich, dass der Anbieter zwar über eine schriftliche Testanweisung verfügt, aber bei dieser Version die Behandlung eines fehlgeschlagenen Tests nicht nachvollziehbar dokumentiert hat.
Das ist ein konkreter Prüfungsbefund. Aus ihm folgt allerdings noch nicht automatisch, dass die Anwendung ungeeignet oder der Herstellerprozess nicht GMP-gerecht ist.
Entscheidend ist, welche Funktion betroffen war, ob die Änderung in den eingesetzten Systemstand gelangte und welche Auswirkungen auf die vom Hersteller genutzten Prozesse möglich sind.
Was beim Softwareanbieter geprüft werden sollte
Der Prüfgegenstand ergibt sich aus den Leistungen des Anbieters und dem Risiko der genutzten Anwendung.
Bei der Softwareentwicklung betrifft das beispielsweise die Festlegung von Anforderungen, Prüfverfahren, dokumentierte Testergebnisse, Fehlerbehandlung und die kontrollierte Freigabe neuer Versionen.
Bei SaaS-Diensten kommen Betriebsprozesse hinzu: Berechtigungsverwaltung, Sicherung und Wiederherstellung von Daten, Störungsmanagement, Konfigurationsänderungen und der Umgang mit Unterauftragnehmern.
Annex 11 Nr. 3.3 verlangt die Prüfung der mit handelsüblicher Software gelieferten Dokumentation im Hinblick auf die Nutzeranforderungen. Nach Nr. 3.4 müssen bestimmte Qualitätssystem- und Auditinformationen zu Softwarelieferanten beziehungsweise Entwicklern für behördliche Inspektoren auf Anforderung verfügbar sein. [1]
Das bedeutet nicht, dass der Hersteller jeden Entwicklungsschritt selbst wiederholen muss.
Die zentrale Frage lautet vielmehr, ob die vorgelegten Nachweise eine sachgerechte Beurteilung der übernommenen Anbieterleistung ermöglichen.
Beim fiktiven Anbieter wären daher nicht alle Quellcodedateien gleichermaßen wichtig. Relevanter könnte sein, ob die Änderung einer qualitätskritischen Freigabefunktion definiert, geprüft und kontrolliert in Betrieb genommen wurde.
Geschäftsgeheimnisse und Mandantentrennung begrenzen die Einsicht
Softwareanbieter müssen regelmäßig eigene Geschäftsgeheimnisse schützen. Bei Cloud-Diensten kommen Daten und Betriebsinformationen anderer Kunden hinzu.
Aus Annex 11 folgt regelmäßig kein schrankenloser Anspruch auf sämtliche Quellcodebestandteile oder fremde Kundendaten; Umfang und Modalitäten sind anhand des Prüfzwecks, des Vertrags und entgegenstehender Schutzinteressen zu bestimmen.
Umgekehrt darf die Berufung auf Geschäftsgeheimnisse nicht dazu führen, dass der Hersteller die Eignung eines für seine GMP-Tätigkeiten wesentlichen Dienstes überhaupt nicht mehr beurteilen kann.
Zwischen beiden Interessen sind geeignete Prüfwege zu wählen.
Möglich sind beispielsweise geschützte Dokumenteneinsicht, ausgewählte Testnachweise, anonymisierte Prozessbeispiele, Prüfungen in einer getrennten Umgebung oder ein Audit unter Vertraulichkeitsverpflichtungen.
Auch vorhandene unabhängige Prüfberichte können die Bewertung unterstützen. Ihre Aussagekraft hängt davon ab, ob Prüfgegenstand, Zeitraum, Umfang und festgestellte Abweichungen zum konkreten Einsatzfall passen.
Ein allgemeines Zertifikat ersetzt nicht die Risikobewertung des regulierten Anwenders.
Im fiktiven Fall müsste der Anbieter nicht zwingend den gesamten Quellcode offenlegen. Er müsste aber angemessen erklären und belegen können, wie die relevante Softwareänderung geprüft wurde und weshalb der Hersteller die vorgelegten Ergebnisse für seinen Einsatzzweck heranziehen kann.
Was passiert, wenn der Anbieter Unterlagen verweigert?
Eine verweigerte Auskunft ist nicht automatisch ein GMP-Verstoß. Zunächst ist zu klären, welche Informationen angefordert wurden, wofür sie benötigt werden und welche Rechts- oder Vertragsgrundlage den Zugang trägt. Die Reichweite des Zugangsrechts bestimmt sich zusätzlich nach dem konkreten Vertrag, dem Schutz von Geschäftsgeheimnissen nach dem Geschäftsgeheimnisgesetz (GeschGehG) und gegebenenfalls nach Datenschutz- und Geheimhaltungspflichten.
Der regulierte Anwender sollte den nicht aufklärbaren Punkt dokumentieren und bewerten, welche Unsicherheit für seinen konkreten Prozess verbleibt.
Anschließend können alternative Nachweise verlangt oder abgestufte Prüfmethoden vereinbart werden.
Wenn die erforderliche Bewertung auch damit nicht möglich ist, muss der Hersteller entscheiden, ob er den vorgesehenen Einsatz ausreichend begründen kann.
Je nach Risikolage kann es erforderlich sein, die Einführung zurückzustellen, bestimmte Funktionen nicht zu nutzen oder den Anbieter neu zu bewerten.
Ein allgemeiner Anspruch des Herstellers auf beliebige Geschäftsunterlagen lässt sich aus Annex 11 Nr. 3 allein nicht ableiten.
Auditbefunde müssen bewertet und nachverfolgt werden
Das Audit endet nicht mit einer Liste von Feststellungen.
Für jeden relevanten Befund ist zu beurteilen, welche Anforderung betroffen ist, wie sich die Abweichung auswirken könnte und welche weitere Aufklärung erforderlich wird.
Im Beispiel der unzureichend dokumentierten Softwareprüfung ist zu untersuchen, ob eine kritische Funktion betroffen war und welche Nachweise zur tatsächlich eingesetzten Version vorliegen.
Der Anbieter kann ergänzende Unterlagen liefern, die Ursache untersuchen und geeignete Korrektur- oder Vorbeugemaßnahmen festlegen.
Der Hersteller bewertet, ob diese Maßnahmen geeignet sind und ob vor ihrer vollständigen Umsetzung ein vertretbarer Einsatz möglich bleibt.
Dabei sind Feststellung, Risikobewertung, Maßnahme und Wirksamkeitsprüfung getrennt zu dokumentieren.
Die Zahl offener Auditbefunde allein entscheidet nicht über die Eignung eines Dienstleisters. Ein einzelner schwerwiegender Befund kann bedeutsamer sein als mehrere formale Dokumentationsabweichungen.
Kapitel 7 und AMWHV sind nicht auf jede SaaS-Leistung gleich anzuwenden
EU-GMP Kapitel 7 betrifft ausgelagerte GMP-regulierte Tätigkeiten. Sein Anwendungsbereich geht über die klassische Lohnherstellung hinaus, erfasst aber nicht ohne Prüfung jede technische Nebenleistung. [2]
Soweit Kapitel 7 einschlägig ist, verlangt es unter anderem die Bewertung der Eignung des Auftragnehmers sowie die Kontrolle ausgelagerter Tätigkeiten. Die zugehörigen Aufzeichnungen müssen dem Auftraggeber verfügbar sein; der Vertrag muss ein Audit der ausgelagerten Tätigkeiten ermöglichen. [2, Nr. 7.5, 7.16 und 7.17]
Für einen externen Softwareanbieter ist Annex 11 Nr. 3 der speziellere Ausgangspunkt. Die Einordnung ist funktionsbezogen; dieselbe SaaS-Leistung kann je nach ihrer Einbindung sowohl unter Annex 11 als auch unter die Anforderungen an ausgelagerte Tätigkeiten fallen.
Ergänzend können die deutschen Anforderungen der AMWHV relevant sein, insbesondere § 9 zu Tätigkeiten im Auftrag und § 10 Abs. 2 zu elektronischen Aufzeichnungssystemen. [3]
§ 11 AMWHV betrifft seinem Wortlaut nach insbesondere bestimmte Ausgangs- und Verpackungsmaterialien. Für Softwareanbieter folgt die Bewertung aus den Anforderungen an QM-System, ausgelagerte Tätigkeiten, computergestützte Systeme und Validierung; sie ist nicht schematisch mit der Materiallieferantenqualifizierung gleichzusetzen. [3]
Ob diese Vorschriften im konkreten Fall eingreifen und welche Prüfmaßnahmen angemessen sind, hängt von den tatsächlichen Leistungen und ihrer Bedeutung für den regulierten Herstellungsprozess ab.
Checkliste: Lieferantenaudit beim Softwareanbieter vorbereiten
Die Vorbereitung des Audits beginnt mit der Bestimmung der Risiken und offenen Punkte, die vor dem vorgesehenen GMP-Einsatz über den Anbieter geklärt werden müssen.
| Prüffrage | Was vor dem Audit feststehen sollte |
|---|---|
| Welche Leistungen sind GMP-relevant? | Betroffene Softwarefunktionen, Daten, Schnittstellen und Verantwortlichkeiten identifizieren. |
| Welcher Prüfumfang ist erforderlich? | Risiken bewerten und daraus Fragebogen, Dokumentenprüfung, Remote-Audit oder Vor-Ort-Audit auswählen. |
| Welche Nachweise werden benötigt? | Verfahrensbeschreibungen, Änderungsunterlagen, Testnachweise und geeignete Stichproben festlegen. |
| Welche Einsicht ist möglich? | Geschäftsgeheimnisse und Mandantentrennung berücksichtigen; geeignete alternative Prüfverfahren bestimmen. |
| Wer bewertet die Befunde? | Fachlich zuständige Personen, Bewertungskriterien und Eskalationswege vorab festlegen. |
| Wie wird das Audit abgeschlossen? | Feststellungen, erforderliche Maßnahmen, Fristen und Wirksamkeitsprüfung dokumentieren. |
Die Checkliste ist kein gesetzlich vorgeschriebener Standardfragenkatalog. Sie dient dazu, den risikobasiert festgelegten Prüfauftrag vorzubereiten und den benötigten Nachweisumfang nachvollziehbar zu bestimmen.
Im Beispiel des SaaS-Anbieters für elektronische Chargenprotokolle würde die Prüfung deshalb bei der konkreten Softwareversion, ihren qualitätsrelevanten Änderungen und den zugehörigen Testnachweisen ansetzen – nicht bei einer allgemeinen Liste sämtlicher Unternehmensprozesse.
Das Audit muss die entscheidende Unsicherheit aufklären
Ein GMP-Lieferantenaudit beim Softwareanbieter ist keine jährliche Pflichtübung mit festem Fragenkatalog.
Sein Zweck ist, die für den vorgesehenen Einsatz entscheidenden Risiken anhand geeigneter Nachweise zu beurteilen.
Ein Fragebogen kann dafür genügen, wenn Risiko und Informationslage dies tragen. Bei kritischen, unzureichend belegten Anbieterleistungen ist eine vertiefte Dokumentenprüfung oder ein Remote- beziehungsweise Vor-Ort-Audit erforderlich, soweit dies aus der Risikobewertung folgt.
Wo Unterlagen fehlen oder nur eingeschränkt offengelegt werden können, muss der regulierte Anwender die verbleibende Unsicherheit ausdrücklich bewerten.
Nicht die Zahl der geprüften Dokumente bestimmt die Qualität des Audits, sondern ob der Hersteller seine Entscheidung über die Eignung des Anbieters nachvollziehbar begründen kann.
Dieser Beitrag dient der allgemeinen regulatorischen Information und ersetzt keine Rechtsberatung im Einzelfall.
Regulatorische Hauptfundstellen
Rechtsstand: 28. Oktober 2026. Maßgeblich ist Annex 11 in der Revision Januar 2011. Der Konsultationsentwurf eines überarbeiteten Annex 11 wird nicht als geltende Fassung behandelt.
