IT-Infrastruktur-Qualifizierung - vom Rechenzentrum bis zur Cloud.
IT-Infrastruktur-Qualifizierung weist nach, dass die Infrastruktur, auf der GxP-Systeme laufen, spezifikationsgerecht aufgebaut ist und kontrolliert betrieben wird, vom eigenen Rechenzentrum bis zur Cloud. Der Nachweis ist dabei kein einmaliges Protokoll. Er entsteht aus einem kontrollierten Zustand, der risikobasiert aufgebaut und mit Werkzeugen und Monitoring gehalten wird.
Das Fundament unter jedem GxP-System.
EU GMP Annex 11 formuliert den Grundsatz in einem Satz: "The application should be validated; IT infrastructure should be qualified." Wie tief, sagt das Regelwerk nicht. Die Tiefe folgt dem Risiko der unterstützten GxP-Prozesse. Erfasst sind Hardware und Netzwerk, virtuelle Umgebungen, Betriebssysteme und Datenbanken.
Papiernachweis für einen Tag
Ein papierbasierter Nachweis bestätigt den Zustand eines Tages. Über den laufenden Betrieb sagt er wenig.
Kontrollierter Zustand im Betrieb
Der qualifizierte Zustand wird im IT-Qualitätsmanagementsystem gehalten, und Service-Management, Automation und Monitoring führen den Nachweis. Die Records dafür sind Build-Reports, Konfigurationsdatenbank und Monitoring-Protokolle. Für diese Records gelten die Anforderungen an die Datenintegrität nach ALCOA++.
Risikobasiert vom Bedarf zum kontrollierten Zustand.
Ein starres Phasenschema gibt es nicht. Jeder Schritt leitet sich aus dem Risiko der getragenen Prozesse ab. Wo das Risiko höher liegt, reicht der Nachweis tiefer.
- 1
Planung & Risikobewertung
Das Risiko der getragenen Prozesse wird bewertet. Daraus leiten sich Umfang und Tiefe der Qualifizierung je Komponente ab.
- 2
Anforderungen & Spezifikation
Die Infrastrukturanforderungen werden erfasst und dokumentiert. Dann wird geprüft, ob die geplante Auslegung diese Anforderungen erfüllt.
- 3
Aufbau & Verifizierung
Dokumentierter Nachweis, dass Hardware, virtuelle Infrastruktur und Infrastruktur-Software spezifikationsgerecht installiert und konfiguriert sind. Automatisierte Build-Reports und Infrastructure as Code (IaC) liefern ihn reproduzierbar. Lieferantendokumentation wird dabei so weit genutzt, wie das Risiko der Komponente es zulässt.
- 4
Akzeptanz & Freigabe
Der Funktionsnachweis wird in dem Umfang geführt, den die Risikobewertung aus Schritt 1 je Komponente festgelegt hat. Der Qualifizierungsreport schließt ab, und die Infrastruktur wird für den GxP-Einsatz freigegeben.
- 5
Kontrollierter Zustand im Betrieb
Change-, Configuration- und Security-Management, Patching und periodische Bewertung halten den Zustand. Konfigurationsdatenbank (CMDB) und Monitoring-Protokolle schreiben den Nachweis kontinuierlich fort.
Wie qualifiziert man Cloud-Infrastruktur, die man nicht besitzt?
Bei Cloud-Infrastruktur weist das regulierte Unternehmen die Kontrolle über den Anbieter nach, weil die Hardware nicht die eigene ist. An die Stelle der eigenen Hardware-Qualifizierung tritt die Qualifizierung des Anbieters. EU GMP Annex 11 verlangt den qualifizierten Zustand der IT-Infrastruktur unabhängig davon, wer sie betreibt, und die Verantwortung bleibt beim regulierten Unternehmen. Bereits die Fassung von 2011 fordert formale Vereinbarungen mit klaren Verantwortlichkeiten und macht die Notwendigkeit eines Audits von der Risikobewertung abhängig. Der Entwurf der Annex-11-Revision von 2025 führt das weiter aus. Er sieht zusätzlich eine laufende Aufsicht über vereinbarte Service Level und Kennzahlen vor, dazu Berichtspflichten und den Zugriff auf die Dokumentation vom eigenen Standort aus. Der GAMP Good Practice Guide "Enabling Innovation" ordnet dazu die Servicemodelle IaaS und PaaS nach der geteilten Verantwortung. Cloud-Infrastruktur ändert sich außerdem laufend, weil Kapazität mit dem Bedarf wächst und schrumpft. Patches kommen nach dem Zeitplan des Anbieters. Ein einmaliger Nachweis beschreibt deshalb einen Zustand, der mit dem nächsten Patch überholt ist. Nachweisbar ist die Kontrolle mit drei Instrumenten:
Für ausgelagerte Infrastruktur sind zwei Servicemodelle einschlägig, Infrastructure as a Service (IaaS) und Platform as a Service (PaaS). Sie unterscheiden sich darin, wie weit die Verantwortung des Anbieters reicht:
| Modell | Der Anbieter trägt | Ihr Nachweisfokus |
|---|---|---|
| IaaS | Rechenzentrum, Hardware und Virtualisierung als kontrollierten Dienst, ohne dass Sie Einblick in die physische Umgebung haben | Eigene Software-Schicht verifizieren (Betriebssysteme, Datenbanken, Middleware) und gelieferte Instanzen mit der Bestellung abgleichen, mit den Build-Reports des Anbieters als Nachweis |
| PaaS | Zusätzlich Betriebssysteme, Middleware, Datenbank-Dienste und Entwicklungsumgebung bis zur Laufzeitplattform | Kontrollen des Anbieters bewerten, die Plattform in ihrer laufenden Fortentwicklung überwachen, eigene Anwendungen und Deployments kontrolliert führen |
Software as a Service ist bewusst nicht Teil dieser Betrachtung. Eine gemietete Anwendung erfüllt unmittelbar Geschäftsprozesse und gehört in die Validierung des computergestützten Gesamtsystems, im Prozess und gegen den Intended Use.
Der Betrieb von Infrastruktur ist die Kernkompetenz der großen Anbieter, und ihre Kontrollen sind durch Zertifizierungen wie ISO 27001 und Attestierungen wie SOC 2 belegt. Nachzuweisen ist der kontrollierte Betrieb beim jeweiligen Anbieter.
Ein weiterer Treiber der Cloud-Nutzung ist die Rechenleistung. Training und Skalierung großer KI-Modelle übersteigen häufig die Kapazität unternehmenseigener Rechenzentren, und der Bedarf fällt stoßweise an. KI-Anwendungen im GxP-Umfeld, die auf solchen Modellen aufsetzen, beziehen ihre Rechenleistung aus der Cloud, und der Nachweis kontrollierter Cloud-Nutzung wird dann zur Voraussetzung für ihren GxP-Einsatz.
Risikobasierter Umfang nach Infrastrukturkomponente.
Der Qualifizierungsumfang richtet sich nach Komponententyp und Risiko. Standardkomponenten werden schlank nachgewiesen, konfigurierte und ausgelagerte Bausteine erhalten die Kontrolltiefe, die ihr Risiko verlangt. Für Systeme, die unmittelbar in der Herstellung stehen, kommt der Prozessnachweis hinzu, beschrieben unter Qualifizierung und Validierung produktionsnaher Systeme.
| Infrastrukturkomponente | Einordnung | Qualifizierungsfokus (risikobasiert) |
|---|---|---|
| Betriebssysteme, Datenbanken, Infrastruktur-Software | Standard-Infrastruktur-Software | Inventar, Version und Konfiguration, in der Konfigurationsdatenbank festgehalten, bei geringem Risiko bewusst schlank gehalten |
| Hardware, Netzwerk, Server | physische Infrastruktur | Abnahme gegen die Spezifikation, mit einem Funktionsnachweis, dessen Tiefe sich nach der Nähe der getragenen Prozesse zur Chargenentscheidung richtet |
| Virtuelle Infrastruktur, Infrastructure as Code (IaC) | konfiguriert | Der Code ist die Spezifikation. Einmal verifiziert, provisioniert er identisch, und jeder Lauf wird im Build-Report dokumentiert |
| Cloud-Services (IaaS, PaaS) | ausgelagert betrieben | Anbieter nach Risiko bewertet, Verantwortlichkeiten vertraglich zugeordnet, Service-Level laufend überwacht |
| Backup & Restore, Disaster Recovery | Prozess auf der Infrastruktur | Maßgeblich ist die geprobte Wiederherstellung unter realen Betriebsbedingungen |
| Change, Configuration & Security Management | betrieblicher Prozess | Die Betriebsprozesse halten den qualifizierten Zustand aufrecht und schreiben den Nachweis im laufenden Betrieb fort |
Endet die Qualifizierung am Rand des Shopfloors?
Nein, sie folgt den Daten. EU GMP Annex 11 gilt für alle computergestützten Systeme in GMP-Tätigkeiten. Prozessleitsysteme gehören dazu, und mit ihnen die Sensoren und Edge-Geräte, deren Daten GxP-Entscheidungen tragen. Die Produktionsebene (Operational Technology, OT) war lange eine eigene Welt. Prozessleitsysteme und Sensoren folgten der Automatisierungspyramide nach ISA-95 und blieben vom Unternehmensnetz getrennt. Diese Trennung löst sich auf. Ein ISPE-Konzeptpapier zu Pharma 4.0 aus dem Jahr 2024 beschreibt eine IT/OT-Architektur nach der NAMUR Open Architecture. Darin liefern intelligente Sensoren ihre Zustandsdaten über einen zweiten Kanal parallel zur Pyramide an Edge-Geräte und in die Cloud. Erprobt wurde die Architektur an einem GMP-Bioreaktor. Damit greifen die Kontrollen der IT bis auf den Shopfloor, und die Tiefe der Qualifizierung richtet sich nach dem Intended Use des Prozesses, in den die Daten eingehen. Ein Zustandssignal für die Wartung wird anders behandelt als ein Prozesswert, der in die Chargenfreigabe eingeht.
Qualifizierung, risikobasiert umgesetzt.
Wir begleiten den Weg von der Strategie bis zum Report und danach den Betrieb, in dem der qualifizierte Zustand gehalten wird. Dabei arbeiten wir mit IT-Betrieb, Qualitätssicherung und den Anbietern zusammen. Die ersten drei Punkte zeigen, wo die Arbeit ansetzt, je nachdem, wer die Qualifizierung anstößt.
Den Leitfaden für diesen Weg kennen wir von innen.
QFINITY hat am GAMP Good Practice Guide "Enabling Innovation" mitgewirkt. Der Guide beschreibt, wie der qualifizierte Zustand der IT-Infrastruktur mit Werkzeugen, Automation und Monitoring gehalten wird, vom eigenen Rechenzentrum bis zu IaaS und PaaS.
GAMP 5 Second Edition folgt demselben Ansatz, risikobasierte Kontrolle statt pauschaler Dokumentation. QFINITY hat daran im Kernteam mitgearbeitet. Infrastruktur lässt sich nicht in GxP und non-GxP aufteilen. Kontrolliert wird sie als Ganzes, mit einheitlichen IT-Praktiken und dem Nachweis aus den Werkzeugen.
Häufige Fragen zur IT-Infrastruktur im GxP-Umfeld.
Ja. Kein Regelwerk verbietet den Cloud-Betrieb. Gefordert ist nachweisbare Kontrolle über den Anbieter. Verantwortlich bleibt das regulierte Unternehmen. Es nimmt diese Verantwortung über die Bewertung des Anbieters, die Vereinbarungen mit ihm und das laufende Monitoring wahr. So führt es den Nachweis der Kontrolle. Damit steht die Cloud auch GxP-kritischen Anwendungen offen.
Nein. Das Phasenmodell DQ/IQ/OQ/PQ stammt aus der Qualifizierung stabiler Geräte. IT-Infrastruktur wird risikobasiert qualifiziert. Standardkomponenten werden schlank nachgewiesen, konfigurierte Bausteine tiefer, und der qualifizierte Zustand wird im Betrieb gehalten. Den Nachweis liefern die Records der Werkzeuge, vom Build-Report bis zum Monitoring-Protokoll.
Nicht zwingend. Welche Prüfung angemessen ist, richtet sich nach dem Risiko. Die Spannweite reicht von Zertifikaten und Standardberichten über postalische Audits bis zum Vor-Ort- oder gemeinsamen Audit bei hohem Risiko. Ein Audit belegt nur den Prüfzeitpunkt, deshalb müssen die Vereinbarungen über Service und Qualität sowie das laufende Monitoring der Leistung die Kontrolle dauerhaft sichern.
Nein. Eine solche Trennung ist weder praktikabel noch gefordert. Dieselbe Infrastruktur trägt regulierte wie nicht-regulierte Anwendungen und wird als Ganzes kontrolliert, nach denselben IT-Standards. Differenziert wird eine Ebene höher, denn der Intended Use der unterstützten Prozesse bestimmt, wie tief einzelne Komponenten nachgewiesen werden.
Annex 11 regelt Lieferanten und Dienstleister seit 2011 in einem eigenen Abschnitt: formale Vereinbarungen mit klaren Verantwortlichkeiten, die Notwendigkeit eines Audits nach Risikobewertung, Auditinformationen für Inspektoren. Der Entwurf von 2025 führt diesen Abschnitt deutlich weiter aus. Er stellt klar, dass das regulierte Unternehmen die volle Verantwortung behält. Zusätzlich sieht er vor: eine laufende Aufsicht über vereinbarte Service Level und Kennzahlen, regelmäßige und anlassbezogene Berichte, vereinbarte Unterstützung bei Inspektionen und den Zugriff auf die Dokumentation vom eigenen Standort aus. Bis zur Verabschiedung gilt Annex 11 in der Fassung von 2011. Wer den kontrollierten Zustand heute schon so führt, ist auf beide Fassungen vorbereitet.
Stand:
Die Infrastruktur in den kontrollierten Zustand bringen.
Im Erstgespräch ordnen wir Ihre Infrastruktur, Rechenzentrum wie Cloud, nach Risiko ein und klären, wo heute bei Verantwortlichkeiten und Nachweisen Lücken bestehen. Das Gespräch ist kostenfrei und dauert etwa 30 Minuten.
Erstgespräch vereinbaren
