Inhaltsverzeichnis
Das Wichtigste vorab
Was unterscheidet IT-Infrastrukturqualifizierung von Softwarevalidierung?
Die Infrastrukturqualifizierung bewertet, ob die benötigte technische Basis kontrolliert bereitgestellt und betrieben wird. Die Anwendungsvalidierung weist die Eignung der konkreten Anwendung für ihren vorgesehenen Einsatz nach. Beide hängen zusammen: Ein qualifizierter Server beweist keine richtige Chargenlogik, und ein bestandener Anwendungstest ersetzt nicht alle Kontrollen von Backup, Zugriff oder Wiederherstellung.
Einordnung und Geltungsbereich
Annex 11 unterscheidet im Grundsatz Anwendung und IT-Infrastruktur. Daraus folgt kein für jede Architektur identisches Dokumentenpaket. Cloud, virtuelle Umgebung und lokaler Betrieb benötigen passende Systemgrenzen und Verantwortlichkeiten.
Die Grenze liegt bei der Funktion, nicht nur beim Liefervertrag
Eine technische Baseline erleichtert den Abgleich. Sie beschreibt den vorgesehenen Stand und relevante Einstellungen. Nicht jedes Detail muss in derselben Tiefe geprüft werden; kritische Abhängigkeiten müssen jedoch erkennbar sein. Änderungen an gemeinsamen Diensten können eine Bewertung mehrerer Anwendungen auslösen.
Bei ausgelagerten Leistungen sind Lieferantennachweise zu bewerten. Ein Zertifikat oder Servicebericht kann Teile der Infrastrukturkontrolle unterstützen, zeigt aber nicht automatisch die Eignung Ihrer konkreten Konfiguration. Halten Sie fest, welche Nachweise übernommen und welche Kontrollen selbst ausgeführt werden.
Infrastruktur und Fachanwendung aufeinander beziehen
Annex 11 unterscheidet die Validierung der Anwendung und die Qualifizierung der IT-Infrastruktur. Daraus folgt kein identischer Dokumentenumfang für jedes technische Gerät. Beschreiben Sie, welche Infrastrukturleistung die Fachanwendung benötigt und welche Ausfälle oder Fehlfunktionen ihre Daten und Prozesse beeinflussen können.
Erfassen Sie Server, Datenbank, Netzwerk, Speicher, Identitätsdienste, Zeitversorgung und weitere tatsächlich benötigte Komponenten. Bei Cloud-Diensten ist ein Teil davon beim Anbieter organisiert. Die Verantwortungsmatrix muss zeigen, welche Nachweise verfügbar sind und welche Aufgaben beim Kunden bleiben. Ein Cloudvertrag ersetzt diese Zuordnung nicht.
Beginnen Sie mit der benötigten Funktion: geeigneter Zugriff, Datenhaltung, Wiederherstellung oder zeitliche Zuordnung. Ein Inventar aller Geräte ist eine Grundlage, aber noch kein Eignungsnachweis. Die Qualifizierungsstrategie verbindet technische Leistung und vorgesehenen Anwendungsbetrieb.
Eine risikobezogene Infrastrukturmatrix erstellen
Benennen Sie Komponente, benötigte Eigenschaft, zuständige Stelle und Prüfmethode. Nicht jede Funktion muss in einem separaten IQ-, OQ- oder PQ-Dokument stehen. Vorhandene geeignete Betriebs- und Testnachweise können verwendet werden, wenn Stand und Aussage passen. Die Form folgt dem eigenen QMS und dem erforderlichen Nachweis.
Dokumentieren Sie gemeinsame Nutzung. Eine technische Änderung kann mehrere Fachanwendungen betreffen. Die Auswirkungsbewertung sollte diese Abhängigkeiten erkennen. Ein Server, der für eine Anwendung unkritisch wirkt, kann für einen anderen Prozess eine zentrale Rolle besitzen.
| Komponente | Benötigte Aussage | Eigener Nachweis |
|---|---|---|
| Speicher | Benötigte Daten bleiben verfügbar und richtig zugänglich | Geeignete Betriebs- und Wiederherstellungsprüfung |
| Identitätsdienst | Richtige Personen erhalten passende Zugänge | Repräsentative Rollen- und Ausfallfälle |
| Zeitversorgung | Ereignisse besitzen benötigten Zeitbezug | Prüfung gegen definierte Anforderung |
| Netzwerk | Relevante Datenwege funktionieren beherrschbar | Verbindung, Unterbrechung und Wiederanlauf |
| Datenbank | Anwendung nutzt den vorgesehenen Stand | Konfiguration und geeignete Funktionstests |
| Cloudbetrieb | Anbieter- und Kundenaufgaben sind abgedeckt | Bewertete Evidenz und eigene Kontrollen |
Beispiel: Wiederherstellung startet den Server, die Anwendung findet ihre Daten nicht
Das Szenario ist konstruiert. Ein Server wird aus einer Sicherung wiederhergestellt und ist erreichbar. Die Fachanwendung verweist jedoch auf einen nicht wiederhergestellten Dateispeicher mit Anhängen. Der technische Starttest besteht, die vollständige fachliche Recherche scheitert. Die benötigte Infrastruktur umfasst mehr als die eine virtuelle Maschine.
Erfassen Sie Datenbank, Dateispeicher, Identitäts- und Lizenzabhängigkeiten. Erproben Sie einen geeigneten Wiederherstellungsweg mit bekannten Referenzvorgängen. Prüfen Sie danach Anwendung, Datenbeziehung und benötigten Zugriff. Der Umfang richtet sich nach Architektur und Risiko; ein universelles Komplettausfallszenario für jedes System wird nicht angenommen.
Nach einem Befund wird die Wiederherstellungsbeschreibung korrigiert und erneut geprüft. Benennen Sie erforderliche Reihenfolge und Verantwortliche. Eine zusätzliche Backupdatei allein bestätigt noch nicht den vollständigen Wiederanlauf. Der Nachweis sollte die benötigte Leistung der Infrastruktur für die konkrete Anwendung zeigen.
| Testfall | Aktion | Erwartete Aussage |
|---|---|---|
| Technischer Start | Server und Dienste starten | Grundlage erreichbar |
| Datenzugriff | Bekannten Vorgang öffnen | Richtiger Datenbestand verfügbar |
| Anhang | Externe Datei recherchieren | Benötigte Beziehung und Inhalt vorhanden |
| Identität | Vorgesehene Fachrolle verwenden | Zugang funktioniert angemessen |
| Unterbrechung | Relevanten Datenweg kontrolliert unterbrechen | Erkennung und Wiederanlauf passen |
| Wiederherstellung | Vollständige Abhängigkeit herstellen | Fachliche Nutzung wieder möglich |
Lieferantenevidenz und eigene Prüfungen verbinden
Ein Anbieter kann Infrastrukturtests, Sicherheitsberichte oder Betriebsinformationen liefern. Prüfen Sie, welche konkrete Leistung und welcher Stand abgedeckt sind. Ein allgemeines Zertifikat ist kein Nachweis jeder kundenspezifischen Wiederherstellung oder Netzwerkverbindung. Die Bewertung sollte passende Evidenz nutzen und verbleibende Aufgaben benennen.
Bei geteilter Verantwortung müssen Übergabepunkte klar sein. Der Anbieter kann Speicher wiederherstellen, während der Kunde Anwendung und fachliche Daten prüft. Ein technisches SLA beantwortet nicht automatisch alle Qualitätsanforderungen. Benennen Sie, welche Entscheidung auf welcher Rückmeldung beruht.
Vermeiden Sie doppelte Prüfungen ohne zusätzliche Aussage. Wenn ein geeigneter Nachweis vorhanden ist, kann er verwendet werden. Gleichzeitig darf fehlende Evidenz nicht mit einem Verweis auf „Standardinfrastruktur“ übersprungen werden. Die Entscheidung richtet sich nach benötigter Leistung und tatsächlichem Risiko.
Änderungen, Patches und Kapazität angemessen bewerten
Eine Infrastrukturänderung kann Zugriff, Leistung oder Datenverarbeitung beeinflussen. Prüfen Sie betroffene Anwendungen und Betriebsbedingungen. Ein Sicherheitsupdate kann eine begrenzte Funktion betreffen oder einen breiteren Wiederanlauf erfordern. Die technische Bezeichnung allein bestimmt den Prüfumfang nicht.
Berücksichtigen Sie Kapazität und Last, soweit sie für den Einsatz relevant sind. Ein Test mit wenigen Datensätzen und einem Benutzer bestätigt nicht jede erwartete Betriebssituation. Definieren Sie die benötigte Leistung und eine geeignete Prüfung. Der Artikel setzt keine pauschale Antwortzeit oder universelle Lastzahl.
Erhalten Sie den Bezug zwischen geprüftem und produktivem Stand. Relevante Unterschiede in Netzwerk, Identität oder Speicher sind zu bewerten. Eine erfolgreich qualifizierte Plattform kann durch spätere unkontrollierte Änderung ihre bisherige Aussage verlieren. Change Control und laufende Bewertung bleiben verbunden.
Betrieb und Übergabe auf konkrete Aufgaben ausrichten
Benennen Sie Verantwortliche für Monitoring, Sicherung, Wiederherstellung und Störung. Technische und fachliche Bewertung sollten sich ergänzen. Ein grüner Infrastrukturmonitor bestätigt nicht automatisch richtige Geschäftsdaten. Umgekehrt kann ein fachlicher Fehler technische Untersuchung benötigen.
Übergeben Sie Architektur, Abhängigkeiten, Nachweise und Wiederanlaufanleitung. Eine praktische Übung mit einem bekannten Vorgang zeigt, ob das Team die notwendigen Schritte findet und versteht. Die Übergabe sollte auch Vertretung und externe Anbieter berücksichtigen.
Bei Stilllegung bleibt zu prüfen, welche Infrastruktur für historische Zugriffe noch benötigt wird. Ein alter Lizenz- oder Identitätsdienst kann weiterhin Archivfunktion unterstützen. Diese Abhängigkeit darf nicht unbemerkt mit einer anderen Anwendung beendet werden. Der Datenlebenszyklus verbindet Qualifizierung, Betrieb und geordneten Ausstieg.
Arbeitsvorlage: benötigte Infrastrukturleistung bis zur Anwendung prüfen
Wählen Sie eine konkrete Leistung wie Wiederherstellung nach Ausfall. Beschreiben Sie die vollständigen benötigten Komponenten. Im Beispiel hängen Datenbank, Anhänge, Identität und Lizenz zusammen. Ein technischer Serverstart bestätigt nur einen Teil dieser Kette. Die fachliche Nutzung sollte mit bekannten Referenzvorgängen geprüft werden.
Ordnen Sie Anbieter- und Kundenaufgaben eindeutig zu. Ein Cloudanbieter kann Speicher bereitstellen oder wiederherstellen, während der Kunde Anwendung und Datenkontext bestätigt. Die Matrix soll solche Übergabepunkte erklären. Ein allgemeines SLA oder Zertifikat ist kein Ersatz für die tatsächlich benötigte Gesamtleistung.
Ein Befund wird auf seine Ursache und andere betroffene Anwendungen geprüft. Gemeinsam genutzte Infrastruktur kann einen größeren Umfang besitzen als der zuerst getestete Fall. Die zusätzliche Bewertung sollte diese Abhängigkeit berücksichtigen und passende Nachweise verwenden, ohne jede unabhängige Funktion pauschal vollständig zu wiederholen.
| Leistungsfeld | Konstruierter Eintrag | Prüfaussage |
|---|---|---|
| Anwendung | Historischen Prüfauftrag öffnen. | Benötigte fachliche Funktion. |
| Datenbank | Bezeichneter wiederhergestellter Stand. | Richtige Daten verfügbar. |
| Dateispeicher | Zugehörige Anhänge. | Keine verlorene externe Beziehung. |
| Identität | Vorgesehene Fachrolle. | Zugriff und Grenze funktionieren. |
| Abhängigkeit | Benötigter Lizenz- oder Schlüsseldienst. | Technische Nutzbarkeit erhalten. |
| Übergabe | Zuständige Rollen und Wiederanlaufreihenfolge. | Betrieb kann den Weg praktisch ausführen. |
Die nächsten Schritte
- Benötigte Infrastrukturleistungen und Anwendungen zuordnen.
- Technischen Sollstand und Verantwortlichkeiten definieren.
- Kritische Bereitstellungs- und Betriebsfunktionen prüfen.
- Nachweise für gemeinsame Dienste kontrolliert wiederverwenden.
Häufige Fragen zu IT-Infrastruktur qualifizieren
Muss jedes Netzwerkgerät einzeln umfangreich qualifiziert werden?
Übernimmt der Cloud-Anbieter die gesamte Verantwortung?
Ist IQ/OQ/PQ für jede Infrastruktur vorgeschrieben?
Braucht jeder Infrastrukturbaustein ein separates IQ/OQ/PQ-Paket?
Nicht pauschal. Die benötigten Nachweise richten sich nach Aufgabe, Risiken und vorhandenem QMS. Geeignete vorhandene Betriebs-, Installations- und Funktionsnachweise können verwendet werden, wenn ihre Aussage passt. Entscheidend ist die nachvollziehbare Eignung der benötigten Infrastrukturleistung, nicht die bloße Zahl getrennt betitelter Dokumente.
Übernimmt ein Cloudanbieter die gesamte Qualifizierung?
Er kann wesentliche technische Leistungen und Nachweise bereitstellen. Der Kunde muss deren Eignung für den eigenen Einsatz bewerten und verbleibende Aufgaben übernehmen. Konfiguration, Zugänge, Schnittstellen und fachliche Nutzung können eigene Nachweise benötigen. Die konkrete Verantwortung folgt dem tatsächlich vereinbarten Betriebsmodell.
Wie unterscheiden wir Infrastrukturqualifizierung und Anwendungstest?
Die Infrastrukturprüfung bestätigt benötigte technische Leistungen und Bedingungen. Der Anwendungstest bestätigt die fachliche Funktion im vorgesehenen Einsatz. Beide können sich ergänzen. Ein erreichbarer Server beweist keine richtige Berechnung; ein richtiger Einzelwert beweist nicht automatisch vollständige Wiederherstellbarkeit oder geeignete gemeinsame Plattform.
Warum müssen externe Dateispeicher im Wiederherstellungstest vorkommen?
Weil Geschäftsrecords auf Anhänge oder andere Inhalte außerhalb der Datenbank verweisen können. Ein wiederhergestellter Hauptserver kann starten, während diese Informationen fehlen. Prüfen Sie bekannte vollständige Vorgänge. Der benötigte Umfang folgt der tatsächlichen Architektur und der fachlichen Aussage.
Quellen & fachlicher Stand
Die Quellen bilden den fachlichen Rahmen. Tabellen, Checklisten und ausdrücklich illustrative Beispiele sind eigene methodische Ableitungen, keine wörtlichen Normvorgaben. Herstellerinformationen sind auf die eingesetzte Version und Konfiguration zu beziehen.
- Europäische Kommission: EU-GMP Annex 11, Computerised Systems (2011)Principle sowie §§ 1, 3, 4.7, 7, 10 und 16: Anwendung, Infrastruktur, Verantwortung, Betrieb und Kontinuität. Geltende Fassung laut EudraLex am 14.10.2026; keine universelle Projekt- oder Fristvorgabe.
- Europäische Kommission: EU-GMP Annex 15, Qualification and Validation (2015)Qualifizierung und Validierung, ergänzt den spezifischen Rahmen für computergestützte Systeme.
Zuletzt fachlich geprüft am 14.10.2026.
Daniel Herrmann Consulting
Vom offenen Punkt zu einem nachvollziehbaren Vorgehen.
Wir unterstützen Sie dabei, die Ausgangslage einzuordnen, Verantwortlichkeiten zu klären und passende Nachweise im Betrieb umzusetzen. Welche Unterstützung sinnvoll ist, hängt von Ihrem System, Ihrem Team und dem konkreten Ziel ab.
- IT-GxP-Audit →
Offene Punkte und Prioritäten für Ihren Betrieb einordnen.
- IT-GxP-Consulting →
Vereinbarte Systemprojekte strukturiert umsetzen und übergeben.