Inhaltsverzeichnis
Das Wichtigste vorab
Wie lässt sich ein bestehendes System nachträglich validieren?
Beschreiben Sie den heutigen Einsatzzweck, Systemstand und Datenfluss. Bewerten Sie vorhandene Nachweise gegen die erforderlichen Funktionen und Kontrollen. Priorisieren Sie offene Punkte nach Prozessrisiko und Unsicherheit; sichern Sie kritische Abläufe zuerst ab. Ergänzen Sie nachvollziehbare Prüfungen mit heutigem Datum und entscheiden Sie ausdrücklich über den zulässigen Nutzungsumfang. Alte Tests oder Freigaben dürfen dabei nicht erfunden werden.
- Fehlende Dokumente und tatsächlich ungeeignete Kontrollen getrennt bewerten.
- Vorhandene Belege qualifiziert nutzen und ihre Grenzen offen festhalten.
- Neue Prüfungen zeigen den geprüften Zustand heute, nicht automatisch die Vergangenheit.
- Betriebsentscheidung, Maßnahmen und Wirksamkeitskontrolle brauchen klare Verantwortliche.
Was „nachträglich validieren“ bei einem Bestandssystem bedeutet
Die EMA behandelt bestehende Systeme in ihrer öffentlich verfügbaren Annex-11-Frage 6 ausdrücklich: Benutzeranforderungen definieren, Lücken analysieren und die Anforderungen verifizieren. Das ist eine fachliche Bestandsbewertung. Sie ist keine Erlaubnis, heutige Dokumente als vermeintliche Originalunterlagen einer früheren Einführung auszugeben.
Unterscheiden Sie drei Fragen: Ist der heutige Ablauf geeignet? Welche Nachweise tragen diese Aussage? Welche Unsicherheit besteht hinsichtlich früherer Daten und Entscheidungen? Ein heute erfolgreich geprüfter Berechnungsweg kann die erste Frage beantworten. Er beweist nicht, dass vor fünf Jahren derselbe Algorithmus mit denselben Einstellungen eingesetzt wurde.
Der Leitfaden betrachtet computergestützte Abläufe in der GMP-Herstellung von Humanarzneimitteln. Der verwendete Annex 11 ist in der aktuellen EU-Dokumentübersicht als Fassung Januar 2011 gelistet. Entwürfe werden nicht als geltende Anforderungen behandelt. Medizinprodukte, klinische Prüfungen und andere GxP-Bereiche benötigen eine eigene Zuordnung; das Wort „Legacy“ schafft keine generelle Ausnahme.
Den tatsächlichen Zustand aufnehmen, bevor Dokumente ergänzt werden
Beginnen Sie mit einem gemeinsam beobachteten Prozessdurchlauf. Lassen Sie sich zeigen, wo Daten entstehen, wer sie verändert, welche Ergebnisse weitergegeben werden und worauf eine Qualitätsentscheidung beruht. Erfassen Sie auch Exporte, manuelle Übertragungen und lokale Dateien. Gerade ein scheinbar kleines Hilfsprogramm kann den entscheidenden Wert für einen größeren Prozess liefern.
Zum technischen Stand gehören Anwendungsversion, relevante Konfiguration, Datenbank, Schnittstellen und Betriebsumgebung. Zum fachlichen Stand gehören Anwendungsfälle, Nutzerrollen, Arbeitsanweisungen und maßgebliche Aufzeichnungen. Verknüpfen Sie beides: Welcher konfigurierte Grenzwert wirkt in welchem Prozess, und wer darf ihn ändern?
Sichern Sie den vorgefundenen Zustand, bevor Einstellungen korrigiert werden. Ein datierter Konfigurationsexport oder eine dokumentierte Bestandsaufnahme kann erklären, was untersucht wurde. Eine Aussage eines langjährigen Mitarbeiters ist nützlich für die Suche nach Belegen, aber nicht automatisch ein Ersatz für einen fehlenden Test. Kennzeichnen Sie Erinnerung, direkt beobachteten Zustand und dokumentierte Historie unterschiedlich.
Vorhandene Nachweise nutzen, ohne ihre Aussage zu überdehnen
Sichten Sie Lieferantentests, Installationsprotokolle, Abnahmen, Wartungsunterlagen, Änderungsaufzeichnungen, Fehlermeldungen und Schulungen. Prüfen Sie jeweils Herkunft, Datum, Gegenstand, Ergebnis und Bezug zum heutigen System. Ein Beleg kann vollständig brauchbar, teilweise brauchbar oder für die konkrete Frage ungeeignet sein.
Ein ausführliches Lieferantenpaket kann auch konkrete Konfigurationen und anwendungsnahe Abläufe abdecken. Reduzieren Sie es nicht pauschal auf allgemeine Entwicklungsnachweise. Umgekehrt sagt die Überschrift „PQ“ allein wenig darüber aus, ob Ihre Schnittstelle und Ihre Rollen geprüft wurden. Entscheidend sind die tatsächlich ausgeführten Schritte und dokumentierten Voraussetzungen.
Die folgende Arbeitshilfe zeigt typische Bewertungsentscheidungen. Sie ist keine vorgeschriebene Dokumentenliste. Halten Sie für jede Übernahme kurz fest, welche Anforderung abgedeckt wird und welche Einschränkung bleibt.
| Vorhandener Beleg | Was er unterstützen kann | Was zusätzlich zu klären ist |
|---|---|---|
| Alter Test mit Testdaten und Ergebnis | Verhalten der damals geprüften Funktion. | Version, Konfiguration und relevante Änderungen seit der Prüfung. |
| Lieferantenpaket | Nachgewiesene Funktionen und gegebenenfalls vereinbarte Kundenkonfiguration. | Prüfumfang, Voraussetzungen und nicht abgedeckte Kundenanforderungen. |
| Jahrelange Betriebshistorie | Hinweise auf Zuverlässigkeit, Störungen und tatsächliche Nutzung. | Ob Fehler überhaupt erkannt und vollständig dokumentiert wurden. |
| Konfigurationsexport von heute | Aktueller technischer Ausgangsstand. | Kein automatischer Beweis früherer Einstellungen oder Freigaben. |
| Backup-Protokoll | Durchführung eines Sicherungsvorgangs. | Lesbarkeit, Vollständigkeit und nachgewiesene Wiederherstellbarkeit. |
Dokumentationslücke und Prozessrisiko getrennt priorisieren
Ein fehlendes Deckblatt ist anders zu beurteilen als eine ungeschützte Berechnungsformel. Beides kann einen Bearbeitungsbedarf auslösen, aber die unmittelbaren Folgen unterscheiden sich. Beschreiben Sie jede Lücke deshalb konkret: betroffener Anwendungsfall, fehlende Information oder unwirksame Kontrolle, mögliche Auswirkung und bereits vorhandene Absicherung.
Fragen Sie anschließend: Welche Entscheidung hängt daran? Wie könnte ein Fehler entstehen? Würde er vor einer relevanten Verwendung auffallen? Welche Unsicherheit bleibt? „Bisher ist nichts passiert“ reicht nicht, wenn eine falsche Auswertung jahrelang unbemerkt geblieben sein könnte.
Verwenden Sie nachvollziehbare Prioritäten statt einer scheinbar präzisen Gesamtzahl. Eine kritische Nachweislücke sollte nicht durch viele erfüllte, aber nebensächliche Kriterien rechnerisch verschwinden. ICH Q9(R1) stellt klar, dass Risikomanagement keine ansonsten unzulässige Praxis rechtfertigt. Die in diesem Artikel verwendete Priorisierung dient der Reihenfolge und Tiefe der Bearbeitung, nicht einer pauschalen Risikofreigabe.
Kritische Abläufe absichern und Grenzen offen benennen
Bei einem aktuellen Risiko kommt die Schutzmaßnahme vor der kosmetischen Vervollständigung des Ordners. Mögliche Ansatzpunkte sind eingeschränkte Änderungsrechte, ein gesicherter Datenpfad, eine geeignete unabhängige Kontrolle oder die vorläufige Aussetzung einer betroffenen Funktion. Welche Maßnahme trägt, muss für den konkreten Fehlerweg bewertet werden.
Eine zweite Person kann beispielsweise eine Übertragung gegen eine verlässliche Quelle prüfen. Sie kann aber keine gelöschten Originaldaten wiederherstellen oder zuverlässig erkennen, was in einem unvollständigen Bericht fehlt. Benennen Sie deshalb für jede Übergangskontrolle den nachweisbaren Nutzen und den verbleibenden blinden Bereich.
PIC/S beschreibt zusätzliche Kontrollen für bestehende Systeme, verlangt aber deren Eignung; die Leitlinie ist selbst keine eigenständige Rechtsnorm. Halten Sie Verantwortlichen, Gültigkeitsdauer, Überwachung und Ausstiegskriterium der Maßnahme fest. Wenn ein erforderlicher Zustand mit den verfügbaren Kontrollen nicht tragfähig erreicht wird, ist die betroffene Nutzung einzuschränken oder auszusetzen. Eine unterschriebene Risikoanalyse macht eine ungeeignete Kontrolle nicht wirksam.
Neue Prüfungen kontrolliert planen und ausführen
Prüfen Sie nach Möglichkeit in einer geeigneten Testumgebung. Dokumentieren Sie relevante Unterschiede zum Produktivsystem, etwa Schnittstellen, Datenmenge oder Berechtigungen. Ein Test in einer leeren Standardinstallation beantwortet nicht automatisch die Frage nach Ihrer gewachsenen Konfiguration.
Wenn eine Prüfung im Betrieb erforderlich ist, legen Sie vorab Umfang, Testdatenkennzeichnung, Freigaben, Sicherung, Rückfallweg und Abbruchkriterien fest. Verhindern Sie, dass Testdaten in reale Berichte, Schnittstellen oder Freigabeentscheidungen gelangen. Auswertungs- oder Löschtests mit echten Produktionsdaten sind keine beiläufige Bestandsaufnahme.
Protokollieren Sie Ausführungstag, Umgebung, Ausgangsstand, Erwartung, Ergebnis und Abweichungen. Die folgende Matrix ist eine eigene illustrative Planungshilfe. Sie behauptet keine bereits ausgeführten Tests und ersetzt keine auf Ihr System abgestimmte Prüfanweisung.
| Prüffeld | Kontrollierter Test | Ergebnis und Grenze |
|---|---|---|
| Berechnung | Bekannte Eingaben und Grenzfälle gegen unabhängig bestimmtes Soll prüfen. | Belegt die geprüfte Berechnung im dokumentierten aktuellen Stand. |
| Berechtigung | Testbenutzer ohne Änderungsrecht versucht eine Konfigurationsänderung. | Unzulässige Aktion verhindert; zulässiger Weg separat bestätigt. |
| Schnittstelle | Eindeutigen Testdatensatz einschließlich eines ungültigen Pflichtfelds übertragen. | Zuordnung und Fehlerbehandlung nachvollziehbar; keine echten Aufträge beeinflusst. |
| Wiederherstellung | Gesicherten Stand in isolierter Umgebung wiederherstellen und lesen. | Relevante Daten und Kontext vorhanden; Produktionsumgebung bleibt geschützt. |
| Abbruch | Test bei unerwartetem Einfluss auf reale Vorgänge stoppen. | Ereignis erfassen, Auswirkungen bewerten und erst nach Entscheidung fortsetzen. |
Illustratives Szenario: Alte Laborsoftware mit unklarem Nachweisstand
Das folgende Szenario ist frei entwickelt, kein Kundenfall. Eine Laborsoftware übernimmt Messwerte und berechnet einen Ergebnisbericht. Ein Lieferantenprotokoll liegt für eine frühere Version vor. Der aktuelle Berichtsaufbau wurde später geändert, und mehrere Mitarbeiter besitzen weitreichende Rechte. Ob Originaldaten nachträglich verändert werden können, ist noch nicht geklärt.
Das Team startet mit drei getrennten Arbeitsaufträgen: Erstens den Datenweg und die tatsächlichen Rechte feststellen. Zweitens die aktuelle Berichtsberechnung kontrolliert prüfen. Drittens klären, welche früheren Ergebnisse von der Berichtsänderung betroffen sein könnten. Ein aktueller Rechentest erledigt den dritten Auftrag nicht.
Als Testdatum werden 48,0 Einheiten bei einem spezifizierten Faktor 2,5 verwendet. Der erwartete Wert beträgt 120,0 Einheiten. Zusätzlich wird ein leerer Faktor geprüft: Erwartet wird die vorab definierte Fehlerbehandlung, nicht stillschweigend ein Ergebnis von null. Diese Zahlen illustrieren nur die Prüflogik und sind keine analytische Methode.
Die Rechteprüfung kann zuerst Maßnahmen erfordern, während die Dokumentenbewertung parallel läuft. Ein belastbarer alter Test wird übernommen, wenn sein Geltungsbereich weiterhin passt. Der neue Test bekommt das tatsächliche Ausführungsdatum. Fehlende historische Informationen bleiben als Unsicherheit benannt; sie werden nicht mit einer neu geschriebenen Erfolgsgeschichte ersetzt.
Wer entscheidet über Nutzung und frühere Auswirkungen?
Die Entscheidung gehört in den bestehenden Qualitätsprozess. Prozessverantwortliche beurteilen den fachlichen Einsatz, Systemverantwortliche und IT die technische Situation, QA die Nachweisführung und qualitätsrelevanten Folgen. Die konkret erforderlichen Entscheidungsbefugnisse müssen in Ihrer Organisation festgelegt sein; sie ergeben sich nicht automatisch aus der Projektleiterrolle.
Dokumentieren Sie die Entscheidung so, dass sie später verständlich bleibt: freigegebener Umfang, Einschränkungen, Begründung, offene Punkte, Fristen und erneuter Bewertungsanlass. Eine begrenzte Nutzung darf nicht mit einer uneingeschränkten Bestätigung des gesamten Systems verwechselt werden. Werden neue Erkenntnisse bekannt oder trägt eine Kontrolle nicht, ist die Entscheidung erneut zu prüfen.
Bei Anzeichen fehlerhafter oder unvollständiger qualitätsrelevanter Daten müssen Ausmaß und mögliche Auswirkungen auf frühere Entscheidungen untersucht werden. Ein CSV-Projekt ersetzt diese Untersuchung nicht. Für FDA-regulierte Arzneimittelprozesse erläutert die Datenintegritäts-Guidance die Untersuchung von Umfang, Ursachen und Auswirkungen besonders deutlich. Ob weitere Produktmaßnahmen oder Kommunikation erforderlich sind, beurteilen die dafür zuständigen Funktionen anhand des konkreten Sachverhalts.
Aus der Gap-Liste einen abschließbaren Maßnahmenplan machen
Geben Sie jeder Lücke einen Verantwortlichen und ein überprüfbares Abschlusskriterium. „Dokumentation verbessern“ ist zu ungenau. Besser ist beispielsweise: aktueller Schnittstellenstand beschrieben, Zuordnung der Pflichtfelder bestätigt, Fehlerfälle geprüft und Ergebnis bewertet. So lässt sich erkennen, ob der konkrete Sachverhalt geklärt wurde.
Trennen Sie technische Qualifizierung und Anwendungsvalidierung. Ein nachgewiesen eingerichteter Server oder eine funktionierende Sicherung belegt noch nicht den vorgesehenen fachlichen Prozess. Umgekehrt ersetzt ein erfolgreicher Anwenderdurchlauf nicht die nötigen Nachweise über die unterstützende Infrastruktur. Beide Bereiche können vorhandene Evidenz nutzen und müssen sinnvoll zusammenpassen.
Binden Sie dauerhafte Änderungen in Change Control ein. Prüfen Sie nach Abschluss, ob die Maßnahmen im Alltag wirken und neue Änderungen erfasst werden. Eine periodische Bewertung sollte nicht erneut dieselben unbekannten Zustände aufdecken. Falls Ersatz oder Stilllegung die tragfähige Lösung ist, planen Sie Datenzugriff und Aufbewahrung mit; ein neues System beseitigt alte Nachweispflichten nicht.
Checkliste für die erste gemeinsame Bestandsbewertung
Für das erste Arbeitsgespräch brauchen Sie keinen neu formatierten Validierungsordner. Hilfreicher sind ein nachvollziehbarer Prozessdurchlauf, der tatsächliche Systemstand und ein geordneter Zugang zu vorhandenen Unterlagen. Die folgende Checkliste dient als Vorbereitung, nicht als pauschales Freigabeformular.
- GMP-Einsatz, Datenwege und relevante Qualitätsentscheidungen sind benannt.
- Anwendung, Konfiguration, Schnittstellen und Infrastruktur sind identifiziert.
- Vorhandene Belege sind mit Herkunft, Datum und Geltungsbereich erfasst.
- Dokumentationslücken, technische Schwächen und historische Unsicherheit sind getrennt.
- Unmittelbare Risiken und geeignete Schutzmaßnahmen sind bewertet.
- Neue Tests haben Sollkriterien, geeignete Umgebung und einen kontrollierten Ablauf.
- Auswirkungen auf frühere Daten werden bei entsprechenden Hinweisen gesondert untersucht.
- Entscheidungsbefugnis, Nutzungsgrenzen und Eskalation sind geklärt.
- Maßnahmen besitzen Verantwortliche, Termine und überprüfbare Abschlusskriterien.
- Wirksamkeit, Änderungen und langfristiger Datenzugriff sind im Betrieb verankert.
Häufige Fragen zu Validierungslücken im Bestand
Darf ein bestehendes GMP-System nachträglich validiert werden?
Die EMA beschreibt für bestehende Systeme die Definition von Benutzeranforderungen, eine Gap-Analyse und die Verifikation dieser Anforderungen. Praktisch bewerten Sie damit den tatsächlichen Einsatz und ergänzen fehlende Nachweise. Das ist von einer erfundenen ursprünglichen Validierung zu unterscheiden. Dokumentieren Sie, was heute geprüft wurde, welche historischen Belege nutzbar sind und welche Aussagen über die Vergangenheit weiterhin nicht belegt werden können.
Müssen wir ein System ohne vollständigen Ordner sofort abschalten?
Die Dokumentenlage allein beantwortet das nicht. Prüfen Sie zuerst den vorgesehenen Prozess, vorhandene Kontrollen und mögliche Folgen. Eine reine Nachweislücke ist anders zu behandeln als eine aktuell unbeherrschte Gefahr für Daten oder Produktqualität. Kann eine notwendige Kontrolle nicht wirksam sichergestellt werden, muss die betroffene Nutzung eingeschränkt oder ausgesetzt werden. Zuständige Funktionen entscheiden anhand dokumentierter Tatsachen, nicht anhand des Alters der Software.
Welche alten Unterlagen dürfen wir weiterverwenden?
Nutzbar sind Unterlagen, deren Herkunft, Prüfumfang und Bezug zum betrachteten System nachvollziehbar sind. Prüfen Sie insbesondere Version, Konfiguration und spätere Änderungen. Ein alter Test kann eine unveränderte Funktion ausreichend belegen, während eine neue Schnittstelle ergänzende Prüfung benötigt. Halten Sie die Übernahmeentscheidung samt Grenze fest; ein pauschales Verwerfen aller Altunterlagen ist ebenso wenig hilfreich wie ihre ungeprüfte Anerkennung.
Reicht jahrelanger störungsfreier Betrieb als Nachweis?
Betriebserfahrung ist relevante Information, aber kein universeller Beweis. Entscheidend ist, ob Fehler erkannt worden wären und wie vollständig Vorfälle dokumentiert wurden. Ein unbemerkter Rechenfehler kann lange bestehen. Nutzen Sie Betriebshistorie zusammen mit Anforderungen, technischen Kontrollen und gezielten Prüfungen. Formulieren Sie „keine bekannten Vorfälle“ nicht zu „nachweislich fehlerfrei“ um.
Dürfen wir eine fehlende URS heute erstellen?
Ja, Sie können die aktuellen Benutzeranforderungen heute beschreiben und freigeben. Kennzeichnen Sie den tatsächlichen Erstellungszeitpunkt und den bewerteten Einsatz. Trennen Sie erforderliches Verhalten vom bloß beobachteten Ist-Zustand; sonst würde jeder bestehende Fehler zur Anforderung erklärt. Frühere Anforderungen dürfen nur dann als historisch belegt bezeichnet werden, wenn entsprechende Quellen vorhanden sind.
Kann eine zweite Person fehlende technische Kontrollen ersetzen?
Nur wenn die zusätzliche Kontrolle den konkreten Fehlerweg wirksam abdeckt und ihr Einsatz nachgewiesen wird. Ein Gegencheck gegen eine verlässliche Quelle kann helfen. Er erkennt jedoch nicht automatisch fehlende Originaldaten oder unbekannte Manipulationen. Bewerten Sie Eignung, Grenzen und neue Risiken; dokumentieren Sie Überwachung und gegebenenfalls das Ende einer Übergangslösung. „Vier Augen“ ist kein allgemeiner Ersatznachweis.
Wie testen wir sicher, wenn es kein Testsystem gibt?
Bewerten Sie zuerst geeignete Alternativen, etwa eine isolierte Kopie mit repräsentativem Stand. Ist eine Prüfung in Produktion erforderlich, müssen Testdaten, Auswirkungen, Rechte, Rückfall und Abbruch vorher geregelt sein. Schließen Sie unkontrollierte Einflüsse auf reale Aufzeichnungen und Entscheidungen aus. Ist das für einen Test nicht beherrschbar, darf er nicht einfach im laufenden Betrieb ausprobiert werden.
Beweist ein heute bestandener Test auch die früheren Ergebnisse?
Nein. Er belegt zunächst nur den dokumentierten geprüften Zustand. Für eine Aussage zu früheren Ergebnissen brauchen Sie zusätzlich einen nachvollziehbaren Zusammenhang, etwa unveränderte Versionen, Konfigurationen und Datenwege. Bei Hinweisen auf eine frühere Fehlfunktion ist eine eigene Auswirkungsbewertung erforderlich. Fehlende historische Informationen bleiben eine begründete Unsicherheit und werden nicht durch ein aktuelles Testergebnis rückwirkend beseitigt.
Brauchen wir eine neue IQ, OQ und PQ für das gesamte System?
Nicht allein wegen dieser drei Dokumenttitel. Legen Sie fest, welche Anforderungen und Kontrollen zu belegen sind, und bewerten Sie vorhandene Evidenz. Die technische Infrastruktur und die Anwendung haben unterschiedliche Prüfgegenstände. Ergänzen Sie die tatsächlich fehlenden Nachweise in einer nachvollziehbaren Struktur. Welche Dokumentbezeichnungen Ihr Qualitätsprozess verwendet, ist weniger entscheidend als Abdeckung, Ergebnis und bewertete Abweichungen.
Wann ist die Bearbeitung der Validierungslücken abgeschlossen?
Wenn der festgelegte Umfang nachvollziehbar bewertet, notwendige Kontrollen wirksam umgesetzt und die erforderlichen Nachweise akzeptiert sind. Offene Punkte dürfen nicht nur aus der Liste verschwinden; verbleibende Einschränkungen und Folgemaßnahmen müssen ausdrücklich entschieden sein. Prüfen Sie zudem, ob Change Control und periodische Bewertung den erreichten Zustand erhalten. Ein neuer Ordner mit vielen Unterschriften ist ohne diese Verbindung kein belastbares Abschlusskriterium.
Quellen & fachlicher Stand
Primärquellen wurden am 6. Oktober 2026 geöffnet. Der Schwerpunkt liegt auf Humanarzneimittel-GMP. PIC/S und FDA-Guidances werden mit ihrem jeweiligen Status und Geltungsbereich eingeordnet. Tabellen, Checkliste und Laborbeispiel sind eigene illustrative Arbeitshilfen; es wurden keine realen Systemprüfungen oder Kundenfälle dargestellt.
- Europäische Kommission: EudraLex Volume 4 – EU Guidelines for Good Manufacturing Practice
- Europäische Kommission: EU-GMP Annex 11 – Computerised Systems
- EMA: GMP/GDP Questions and Answers – Annex 11 und Datenintegrität
- Europäische Kommission: EU-GMP Chapter 4 – Documentation
- 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 1 – Pharmaceutical Quality System
- FDA: Data Integrity and Compliance With Drug CGMP – Questions and Answers
Zuletzt fachlich geprüft am 06.10.2026.
Daniel Herrmann Consulting
Den tatsächlichen Nachweisbedarf Ihres Bestandssystems klären
Daniel Herrmann Consulting unterstützt Sie bei der Bestandsbewertung, der Priorisierung konkreter Risiken und der Planung nachvollziehbarer Prüfungen. Vorhandene Evidenz wird dabei gezielt einbezogen.
- IT-GxP-Audit →
Dokumentationsstand, Prozesskontrollen und offene Nachweislücken strukturiert bewerten.
- IT-GxP-Consulting →
Maßnahmen, Anforderungen und kontrollierte Nachprüfungen gemeinsam mit QA und IT umsetzen.