Inhaltsverzeichnis
Das Wichtigste vorab
Wie bewerten Sie einen Softwarelieferanten im GxP-Umfeld?
Beschreiben Sie zunächst Liefergegenstand, vorgesehenen Einsatz und Verantwortungsgrenzen. Bestimmen Sie danach, welche Nachweise zur Entwicklung, konkreten Version, Implementierung und Betriebsleistung erforderlich sind. Bewerten Sie vorhandene Unterlagen und offene Fragen proportional zur Kritikalität. Entscheiden Sie begründet über zusätzliche Prüfungen oder ein Audit und halten Sie Nutzungsumfang, Zuständigkeiten sowie Anlässe für eine Neubewertung fest.
- Softwarehersteller, Implementierungspartner und Betriebsdienstleister können unterschiedliche Nachweise benötigen.
- Ein Zertifikat beantwortet nur Fragen innerhalb seines tatsächlichen Geltungsbereichs.
- Lieferantenbelege können genutzt werden; die Eignung des eigenen Einsatzes bleibt zu bewerten.
- Support, Änderungen und Datenherausgabe vor der Auswahl konkret vereinbaren.
Zuerst die Leistung abgrenzen, dann den Lieferanten bewerten
„Softwarelieferant“ kann den Hersteller eines Standardprodukts, einen Konfigurationspartner oder einen Betreiber mit Zugriff auf Ihre Daten meinen. Häufig sind mehrere Unternehmen beteiligt. Halten Sie fest, wer entwickelt, installiert, konfiguriert, integriert, aktualisiert und betreibt. Ein guter Nachweis für eine dieser Aufgaben belegt nicht automatisch die übrigen.
Dieser Artikel bezieht sich auf computergestützte Prozesse in der GMP-Herstellung von Humanarzneimitteln. Annex 11 adressiert Software- und Dienstleistungsanbieter ausdrücklich. Kapitel 7 kommt ergänzend für tatsächlich ausgelagerte GMP-Tätigkeiten in Betracht. Materiallieferanten, Medizinprodukte und klinische Prüfungen haben zusätzliche oder andere Anforderungen; deren Auditregeln lassen sich nicht pauschal auf jeden Softwarekauf übertragen.
Trennen Sie außerdem die Qualitätssystembewertung des Anbieters von der Validierung Ihres vorgesehenen Einsatzes. Ein kontrollierter Entwicklungsprozess schafft Vertrauen in die Lieferung. Er beweist noch nicht, dass Ihre Freigaberegel richtig konfiguriert wurde. Ebenso belegt qualifizierte Infrastruktur allein keine fachlich geeignete Anwendung. Der Lieferantenbewertung folgt deshalb eine nachvollziehbare Zuordnung zu Ihren Anforderungen.
Die Prüftiefe aus Einsatz und Eingriffsmöglichkeiten ableiten
Bewerten Sie nicht nur den Produktnamen oder die Unternehmensgröße. Entscheidend sind unter anderem betroffene Entscheidungen, Daten, Ausfallfolgen und Eingriffsmöglichkeiten. Ein Supportdienst mit administrativem Zugang kann für die Datenintegrität wichtiger sein als ein Anbieter ohne Zugang zum laufenden System.
Berücksichtigen Sie, was Sie selbst erkennen und kontrollieren können. Ein unbemerkter Fehler in einem automatischen Ergebnisimport erfordert andere Nachweise als eine Funktion, deren Ausgabe vollständig gegen eine verlässliche Quelle geprüft wird. Unbekannte Architektur oder unklare Verantwortung wird als offene Frage behandelt, nicht als niedriges Risiko.
Die folgende Matrix ist eine eigene Arbeitshilfe. Sie ordnet keine feste Auditpflicht zu und vergibt keine universellen Lieferantenklassen.
| Liefergegenstand | Wesentliche Fragestellung | Gezielt anzufordernde Evidenz |
|---|---|---|
| Standardsoftware für qualitätsrelevante Daten | Wie werden relevante Funktionen entwickelt, geprüft und freigegeben? | Versionierte Spezifikation, Testnachweise, Freigabe und Umgang mit Fehlern. |
| Kundenspezifische Konfiguration oder Schnittstelle | Wer setzt Ihre Anforderungen um und kontrolliert Änderungen? | Konfigurationsstand, Mapping, anforderungsbezogene Prüfungen und Übergabe. |
| Cloudbetrieb und Datensicherung | Wer schützt Daten und stellt sie bei Störungen wieder bereit? | Verantwortungsmodell, Sicherungs-/Wiederherstellungsbelege und Störungsprozess. |
| Wartung mit privilegiertem Zugriff | Wie werden Eingriffe autorisiert und nachvollziehbar? | Zugriffsverfahren, Eingriffsprotokoll und Eskalation bei unerwarteten Folgen. |
| Archiv- oder Exit-Leistung | Bleiben erforderliche Aufzeichnungen langfristig nutzbar? | Lieferformate, Umfang, Metadatenbezug und überprüfbare Übergabekriterien. |
SDLC-Nachweise anhand eines konkreten Releases beurteilen
Der Software Development Lifecycle, kurz SDLC, beschreibt den Entwicklungslebenszyklus. Für die Bewertung ist ein tatsächlich durchlaufener Fall oft aufschlussreicher als eine lange Liste guter Absichten. Bitten Sie für eine relevante Änderung um eine nachvollziehbare Verbindung zwischen Anforderung, Umsetzung, Prüfung, Fehlerbehandlung und Freigabe.
Das muss nicht für jeden Lieferanten der vollständige Quellcode sein. Je nach Risiko können freigegebene Verfahrensauszüge, anonymisierte Beispieldatensätze, Testzusammenfassungen oder eine Einsicht unter Vertraulichkeitsvereinbarung geeignet sein. Beurteilen Sie, ob der Beleg die konkrete Frage beantwortet. Eine interne Richtlinie zur Prüfung ist etwas anderes als ein Nachweis ihrer tatsächlichen Anwendung.
Fragen Sie nach bekannten Fehlern und ihrem Einfluss auf den angebotenen Stand. Interessant ist beispielsweise, wie ein Fehler in einer Berechnung eingegrenzt wurde, welche Versionen betroffen waren und wie Kunden informiert wurden. Die bloße Aussage, es gebe ein Ticketsystem, erklärt diesen Ablauf nicht.
Lassen Sie Versionsnummern und Produktbestandteile eindeutig zuordnen. Bei mehreren Komponenten kann ein Testpaket zur Plattform passen, während ein kundenspezifisches Zusatzmodul fehlt. Dokumentieren Sie diese Grenze, statt aus einem allgemeinen Entwicklungsstandard eine Freigabe aller Komponenten abzuleiten.
Lieferantenpakete auf ihren tatsächlichen Umfang prüfen
Ein Lieferantenpaket kann Standardfunktionen, eine konkrete Installation oder auch vereinbarte kundenspezifische Abläufe abdecken. Entscheidend ist der Inhalt. Prüfen Sie Version, Konfiguration, Testumgebung, ausgeführte Schritte, Ergebnisse und bewertete Abweichungen. Die Bezeichnungen IQ, OQ oder PQ allein beantworten diese Fragen nicht.
Ordnen Sie die Belege Ihren Benutzeranforderungen zu. Ein generischer Schnittstellentest kann beispielsweise das Übertragungsprotokoll abdecken, während das Mapping Ihrer Materialnummern offenbleibt. Wenn der Anbieter genau dieses Mapping mit den vereinbarten Fällen geprüft hat und die Nachweise belastbar sind, muss die Leistung nicht allein wegen ihrer externen Durchführung wiederholt werden.
Bewerten Sie auch vorausgesetzte Kundenmaßnahmen. Ein Test kann nur für ein bestimmtes Rollenmodell oder eine bestimmte Datenbankkonfiguration gelten. Halten Sie solche Bedingungen in der Übergabe fest. Ein Lieferantenbericht, der nur einen grünen Gesamtstatus zeigt, braucht gegebenenfalls ergänzende Erläuterung, bevor er eine risikorelevante Anforderung tragen kann.
Quellen: [2]
Wann Unterlagen genügen und wann ein Audit sinnvoll ist
Annex 11 verlangt eine risikobasierte Entscheidung über die Notwendigkeit eines Audits. Daraus folgt weder ein vollständiges Vor-Ort-Audit für jeden Anbieter noch ein genereller Verzicht bei bekannten Marken. Beginnen Sie mit der Frage, welche relevante Unsicherheit durch ein Audit tatsächlich geklärt werden soll.
Bei einem Zertifikat prüfen Sie Aussteller, Gültigkeit, erfasste Organisation, Tätigkeiten und Standorte. ISO unterscheidet Zertifizierung und Akkreditierung; ein Logo allein belegt deren Status nicht. Ein Managementsystemzertifikat und ein Bericht über einen einzelnen technischen Dienst können beide nützlich sein, aber unterschiedliche Fragen beantworten. Keines ist automatisch der Nachweis Ihrer Anwendungsvalidierung.
Ein gezieltes Remote-Audit kann beispielsweise einen Releaseprozess nachvollziehen. Wenn die nötigen Aufzeichnungen nicht zugänglich sind oder wesentliche Angaben widersprüchlich bleiben, reicht eine Präsentation möglicherweise nicht. Definieren Sie dann zusätzliche Einsicht, eine passendere Auditform oder eine andere Beschaffungsentscheidung. Auch ein fremder Auditbericht ist nach Umfang, Aktualität, Kompetenz der Prüfer und verbleibenden Einschränkungen zu beurteilen.
Zuständigkeiten vor Vertragsabschluss konkret machen
Formale Vereinbarungen sollten zur tatsächlich bezogenen Leistung passen. Ein allgemeiner Verweis auf „GMP-konformen Betrieb“ lässt offen, wer eine Störung bewertet, welche Informationen verfügbar sind und wer über eine Änderung entscheidet. Arbeiten Sie deshalb mit konkreten Verantwortlichkeiten und eindeutig benannten Ansprechpartnern.
Für Ihren Prozess können etwa diese Punkte entscheidend sein: Meldung relevanter Änderungen und Fehler, Zugang zu geeigneten Nachweisen, Mitwirkung bei Untersuchungen, supportseitige Eingriffe, Sicherung und Wiederherstellung sowie Datenzugriff am Vertragsende. Stimmen Sie die Inhalte zwischen Einkauf, QA, IT und den zuständigen Vertragsverantwortlichen ab.
Übernehmen Sie Zeitangaben nicht ungeprüft aus einer Vertriebsfolie. Klären Sie, ob eine Reaktionszeit nur die Annahme einer Anfrage oder tatsächlich die Wiederaufnahme Ihres Prozesses betrifft. Veröffentlicht der Anbieter einen konkreten Releaseablauf, beziehen Sie ihn ein. Vertrag, Leistungsbeschreibung und tatsächlich praktizierter Prozess müssen zusammenpassen; nicht jede wichtige Information steht ausschließlich im Vertrag.
Dienstleisterkette, Support und Datenexit mitbewerten
Lassen Sie die für Ihren Dienst relevante Kette erklären: Wer betreibt die Anwendung, wer die Infrastruktur, wer verwaltet Sicherungen und wer kann auf Inhalte zugreifen? Eine Liste bekannter Cloudmarken reicht nicht, wenn die Verantwortungsgrenzen unklar bleiben. Für ausgelagerte GMP-Tätigkeiten beschreibt Kapitel 7 Anforderungen an die Bewertung und Vereinbarung weiterer Unterauftragnehmer.
Daraus folgt kein pauschaler Vor-Ort-Auditauftrag für jeden beteiligten Rechenzentrumsanbieter. Prüfen Sie, welche geeigneten Nachweise und vertraglichen Kontrollmöglichkeiten Ihr direkter Anbieter bereitstellt. Offene Abhängigkeiten müssen in der Entscheidung sichtbar bleiben. Eine Datenschutzvereinbarung beantwortet nicht automatisch alle Fragen zu qualitätsrelevanten Aufzeichnungen.
Planen Sie den Datenexit bereits bei der Auswahl. Fordern Sie einen repräsentativen Export oder eine nachvollziehbare Beschreibung von Umfang und Format an. Entscheidend sind neben Dateien gegebenenfalls Versionen, Beziehungen, Unterschriftsinformationen und Historien. Prüfen Sie, ob die Daten ohne dauerhaftes Abonnement verstanden werden können und welche Unterstützung oder Zusatzkosten für die Übergabe vereinbart sind.
Für den laufenden Betrieb zählt außerdem, wie Zugriffe beendet, Notfalleingriffe dokumentiert und Störungen kommuniziert werden. Ein Sicherungsdienst ist nur dann sinnvoll eingeordnet, wenn auch Verantwortung und Nachweise zur Wiederherstellung geklärt sind.
Illustratives Szenario: Cloud-QMS plus Implementierungspartner
Dieses Beispiel ist frei entwickelt und beschreibt keinen Kundenfall. Ein kleines Pharmaunternehmen möchte ein Cloud-QMS für SOPs, Trainings und Abweichungen einsetzen. Der Softwareanbieter liefert ein Releasepaket; ein separater Partner übernimmt Altdokumente und konfiguriert Rollen. Die Infrastruktur wird durch einen weiteren Dienstleister betrieben.
Die Bewertung wird in drei Leistungsanteile getrennt. Für die Software sind Release- und Funktionsbelege relevant. Beim Partner stehen Mapping, Konfiguration und Übergabe im Mittelpunkt. Für den Betrieb werden Zugriff, Wiederherstellung und Dienstleisterverantwortung betrachtet. Ein gutes Zertifikat des Cloudanbieters schließt die Fragen zur Migration nicht.
Die folgende Entscheidungsnotiz zeigt, wie konkrete Feststellungen zu Maßnahmen führen können. Die genannten Bedingungen sind nur illustrativ. Insbesondere bedeutet eine offene Zeile keine automatische Erlaubnis, unter beliebigen Auflagen produktiv zu starten.
| Feststellung | Bedeutung für den vorgesehenen Einsatz | Nächster Nachweis oder Entscheidung |
|---|---|---|
| Releasepaket passt zur angebotenen Version. | Vorhandene Funktionsbelege können zugeordnet werden. | Kundenanforderungen und Konfigurationsbedingungen abgleichen. |
| Migrationspartner zeigt nur eine Demo. | Erhalt historischer Versionen ist noch nicht belegt. | Repräsentativen Probelauf mit Herkunft, Version und Abnahme durchführen. |
| Support kann privilegiert zugreifen. | Eingriffe können qualitätsrelevante Daten beeinflussen. | Autorisierung und nachvollziehbares Eingriffsprotokoll beurteilen. |
| Wiederherstellung ist nur als Leistung genannt. | Praktischer Wiederanlauf bleibt unklar. | Passende Nachweise und kundenbezogene Verantwortungen klären. |
| Export enthält nur aktuelle PDF-Dateien. | Historische Beziehungen könnten fehlen. | Benötigten Aufzeichnungsumfang vergleichen; Eignung nicht voraussetzen. |
| Wesentliche offene Punkte bleiben unbeantwortet. | Die geplante Nutzung ist noch nicht belastbar begründet. | Auswahl oder Umfang anpassen; keine pauschale Freigabe durch Punktesumme. |
Freigabeumfang und Anlässe für Neubewertung festhalten
Dokumentieren Sie, für welchen Liefergegenstand und Einsatz die Bewertung gilt. Ein Anbieter kann für eine Standardsoftwarelieferung geeignet sein, während ein neuer Betriebsservice separat betrachtet werden muss. Vermeiden Sie deshalb eine unbefristete Freigabe „für alles“, die später als Ersatz für jede weitere Prüfung verwendet wird.
Anlässe für eine Neubewertung können relevante Versions- oder Architekturänderungen, neue Leistungen, geänderte Unterauftragnehmer, wiederholte Supportprobleme oder eine fehlgeschlagene Wiederherstellung sein. Auch die eigene Nutzung kann sich ändern: Ein zuvor nebensächlicher Bericht wird plötzlich Grundlage einer GMP-Entscheidung.
Planen Sie eine angemessene Überwachung und prüfen Sie offene Maßnahmen auf Abschluss und Wirkung. Die Intensität richtet sich nach Leistung, Risiko und Erfahrung; ein universelles jährliches Voll-Audit lässt sich daraus nicht ableiten. Bei gravierenden neuen Erkenntnissen warten Sie nicht auf einen beliebig gewählten Kalendertermin.
Checkliste für die gemeinsame Auswahlentscheidung
Eine gute Bewertung endet mit einer begründeten Entscheidung, nicht mit einer maximal langen Dokumentenanforderung. Nutzen Sie die folgende Checkliste für das Gespräch zwischen QA, IT, Einkauf und Prozessverantwortlichen. Fehlende Angaben werden sichtbar zugeordnet; sie werden nicht als erfülltes Kriterium gezählt.
- Liefergegenstand, relevante Version und tatsächlich beauftragte Unternehmen sind klar.
- GMP-Einsatz, Daten und kritische Entscheidungen sind beschrieben.
- Erforderliche Prüftiefe und wichtigste Unsicherheiten sind begründet.
- Entwicklungs- und Releasebelege passen zu den betrachteten Komponenten.
- Herstellerpaket, Kundenanforderungen und verbleibende Tests sind zugeordnet.
- Zertifikate und Auditberichte sind nach Umfang und Aktualität bewertet.
- Supportzugriff, Störungen und Änderungen haben geregelte Zuständigkeiten.
- Relevante Subdienstleister und ihre Kontrollnachweise sind berücksichtigt.
- Datenherausgabe, Aufbewahrung und Wiederherstellung sind praktisch geklärt.
- Freigabeumfang, offene Bedingungen und Neubewertungsanlässe sind dokumentiert.
Häufige Fragen zu Softwarelieferanten bewerten
Müssen wir jeden Softwarelieferanten vor Ort auditieren?
Nein, Annex 11 knüpft die Notwendigkeit eines Audits an eine Risikobewertung. Entscheidend ist, welche Unsicherheit zur konkreten Leistung verbleibt. Vorhandene belastbare Nachweise können ausreichen; bei kritischen offenen Fragen kann zusätzliche Prüfung nötig sein. Begründen Sie Umfang und Methode. Übertragen Sie Auditvorgaben für Wirkstoffhersteller nicht ohne Prüfung auf einen Softwareanbieter mit anderem Liefergegenstand.
Quellen: [2]
Reicht ein ISO-Zertifikat für die Lieferantenfreigabe?
Ein Zertifikat ist ein möglicher Baustein. Prüfen Sie Gültigkeit, Aussteller und Geltungsbereich sowie die tatsächlich erfasste Organisation und Leistung. Es beantwortet nicht automatisch Fragen zu Ihrer Version, Konfiguration oder Datenmigration. Ergänzen Sie passende Nachweise für den vorgesehenen Einsatz. Ein bekanntes Logo ist weder eine vollständige Lieferantenbewertung noch der Nachweis einer kundenspezifischen Validierung.
Welche SDLC-Unterlagen sollten wir anfordern?
Beginnen Sie mit den risikorelevanten Fragen: Anforderungssteuerung, Versionskontrolle, Tests, Fehlerbehandlung und Releaseentscheidung. Bitten Sie um Belege, die die tatsächliche Anwendung des beschriebenen Prozesses zeigen. Je nach Risiko können freigegebene Auszüge oder eine kontrollierte Einsicht geeignet sein. Eine vollständige Kopie jedes internen Dokuments oder des gesamten Quellcodes ist kein universelles Ziel der Bewertung.
Kann ein Herstellerpaket unsere eigenen Tests ersetzen?
Es kann geeignete Nachweise liefern und damit Wiederholungen vermeiden. Prüfen Sie die tatsächliche Abdeckung, einschließlich Version, Konfiguration und Kundenabläufen. Ein umfangreiches Paket darf nicht pauschal auf Standardtests reduziert werden. Nicht abgedeckte Anforderungen benötigen jedoch andere belastbare Nachweise. Entscheidend ist eine nachvollziehbare Zuordnung, nicht die Frage, ob der Test intern oder extern ausgeführt wurde.
Quellen: [2]
Müssen wir Implementierungspartner und Hersteller getrennt betrachten?
Wenn sie unterschiedliche Leistungen erbringen, sollten diese Leistungen unterscheidbar bewertet werden. Der Hersteller kann eine Produktfunktion belegen, während der Partner Ihr Mapping oder Rollenmodell umsetzt. Prüfen Sie die jeweilige Verantwortung und den Übergabenachweis. Eine gemeinsame Bewertung ist möglich, solange diese Grenzen sichtbar bleiben und keine kritische Aufgabe zwischen den Beteiligten ungeklärt bleibt.
Was tun wir, wenn der Anbieter keine vertraulichen Unterlagen herausgibt?
Klären Sie zuerst, welche Information Sie tatsächlich benötigen und warum. Eine Einsicht unter Vertraulichkeitsvereinbarung, ein passender Auditbericht oder ein begrenzter Nachweisauszug kann geeignet sein. Bewerten Sie, ob die konkrete Unsicherheit dadurch behoben wird. Bleiben kritische Fragen unbeantwortet, muss dies die Auswahl oder den Nutzungsumfang beeinflussen; ein ausgefüllter Marketingfragebogen beseitigt die Lücke nicht.
Wer ist für Cloud-Subdienstleister verantwortlich?
Die Rollen müssen in der tatsächlichen Leistungskette geklärt sein. Für ausgelagerte GMP-Tätigkeiten beschreibt Kapitel 7 die Bewertung und Vereinbarung weiterer Unterauftragnehmer. Prüfen Sie, wie Ihr direkter Anbieter deren Leistungen kontrolliert und relevante Informationen bereitstellt. Das verlangt nicht automatisch ein eigenes Vor-Ort-Audit jedes Infrastrukturunternehmens. Die für Ihren Betrieb wesentlichen Abhängigkeiten dürfen aber nicht unbekannt bleiben.
Welche Punkte sollten vor dem Vertragsabschluss geklärt sein?
Vor allem Leistungsumfang, Verantwortungen, Zugriff, relevante Änderungen, Störungen, Nachweiszugang und Datenherausgabe. Stimmen Sie Reaktions- und Wiederanlaufziele mit dem tatsächlichen Prozessbedarf ab. Beziehen Sie veröffentlichte Lieferantenprozesse ein und klären Sie deren Verbindlichkeit für Ihren Dienst. Allgemeine Compliance-Zusagen helfen wenig, wenn im konkreten Störungsfall niemand Daten, Ansprechpartner oder geeignete Belege bereitstellen kann.
Wie oft müssen wir einen bereits freigegebenen Lieferanten neu bewerten?
Es gibt für alle Softwarelieferanten kein einheitliches sinnvolles Intervall. Legen Sie eine angemessene Überwachung fest und berücksichtigen Sie relevante Änderungen und Erfahrungen. Neue Betriebsleistungen, geänderte Dienstleisterketten oder kritische Störungen können eine frühere Bewertung auslösen. Eine unveränderte, gut belegte Leistung benötigt nicht allein wegen eines Kalendereintrags denselben Prüfaufwand wie eine grundlegend geänderte Architektur.
Wie verhindert ein kleines Unternehmen eine überladene Lieferantenbewertung?
Starten Sie mit den wenigen Entscheidungen, die den geplanten Einsatz tatsächlich tragen müssen. Ordnen Sie jeder wichtigen Frage einen passenden Beleg und einen Verantwortlichen zu. Nutzen Sie vorhandene qualifizierte Evidenz, bündeln Sie Rückfragen und begründen Sie zusätzliche Prüfungen. Verzichten Sie auf Dokumentensammlungen ohne Bewertungsziel. Kritische Lücken dürfen dabei nicht durch eine hohe Gesamtpunktzahl oder eine allgemeine Managementunterschrift verdeckt werden.
Quellen & fachlicher Stand
Behörden- und Leitfadenquellen wurden am 6. Oktober 2026 geöffnet. Schwerpunkt ist die Software- und Dienstleisterbewertung für Humanarzneimittel-GMP. Kapitel 7 wird auf tatsächlich ausgelagerte GMP-Tätigkeiten bezogen. Tabellen, Szenario und Checkliste sind eigene illustrative Arbeitshilfen, keine durchgeführten Audits oder Kundenfälle.
- Europäische Kommission: EudraLex Volume 4 – EU Guidelines for Good Manufacturing Practice
- Europäische Kommission: EU-GMP Annex 11 – Computerised Systems
- Europäische Kommission: EU-GMP Chapter 7 – Outsourced Activities
- ICH Q9(R1): Quality Risk Management – FDA Final Guidance
- PIC/S PI 041-1: Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments
- Europäische Kommission: EU-GMP Chapter 4 – Documentation
- ISO: Certification
Zuletzt fachlich geprüft am 06.10.2026.
Daniel Herrmann Consulting
Lieferantennachweise auf Ihren tatsächlichen Einsatz ausrichten
Daniel Herrmann Consulting unterstützt QA, IT und Einkauf dabei, benötigte Evidenz festzulegen, vorhandene Belege einzuordnen und offene Fragen vor Einführung oder Erweiterung gezielt zu klären.
- IT-GxP-Audit →
Vorhandene Lieferantennachweise, Zuständigkeiten und offene Risiken bewerten.
- IT-GxP-Consulting →
Bewertungsstruktur, Nachweiszuordnung und Betriebsübergabe gemeinsam ausarbeiten.