GxP-Konfigurationsbaseline: den geprüften Stand sichern

Einordnung und Geltungsbereich

Annex 11 nennt Change- und Konfigurationsmanagement. Die konkrete Form einer Baseline ist eine methodische Ausgestaltung. Nicht jede technische Einstellung benötigt denselben Dokumentations- und Prüfaufwand.

Quellen: [1]

Ein belastbarer Stand ist auffindbar, verständlich und vergleichbar

Verbinden Sie die Baseline mit der Freigabe und den zugehörigen Nachweisen. Eine Liste ohne Datum, Systembezug oder verantwortliche Stelle lässt offen, ob sie einen Plan, einen Teststand oder die Produktion beschreibt. Verwenden Sie eindeutige Kennungen und kontrollierte Ablage.

Bei Änderungen muss erkennbar sein, was sich gegenüber dem bisherigen Stand verändert. Ein kompletter neuer Export kann dabei helfen, ersetzt aber nicht die Bewertung der relevanten Differenzen. Automatisierte Vergleiche sollten dynamische und fachlich unerhebliche Felder bewusst behandeln, damit wichtige Abweichungen nicht in Rauschen verschwinden.

Quellen: [1]

Den freigegebenen Stand als zusammengehöriges System beschreiben

Eine Konfigurationsbaseline bezeichnet den für den vorgesehenen Einsatz relevanten Referenzstand. Dazu können Softwareversion, kritische Parameter, Rollen, Schnittstellen und fachliche Stammdaten gehören. Die Auswahl folgt der tatsächlichen Wirkung. Ein Screenshot des Versionsdialogs beschreibt eine komplexe Anwendung selten vollständig.

Unterscheiden Sie aktuelle Konfiguration, genehmigte Änderung und geprüften Stand. Diese können auseinanderliegen. Ein freigegebener Change ist noch keine Bestätigung seiner Umsetzung. Ein aktueller Export kann bereits eine ungeprüfte Änderung enthalten. Die Baseline sollte deshalb den Bezug zwischen Sollstand, Nachweis und tatsächlichem Betrieb sichtbar machen.

Annex 11 behandelt kontrollierte Änderungen an computergestützten Systemen. Der Begriff Baseline ist hier eine methodische Hilfe für deren Nachvollziehbarkeit. Es wird kein universelles Formular mit einer vorgeschriebenen Zahl von Feldern angenommen. Nutzen Sie vorhandene Konfigurations- und Änderungsverfahren, wenn diese die benötigte Aussage geeignet abbilden.

Quellen: [1]

Eine schlanke, risikobezogene Baselinevorlage verwenden

Erfassen Sie Komponenten, deren Änderung die Funktion oder Datenintegrität beeinflussen kann. Dekorative Einstellungen müssen nicht automatisch dieselbe Tiefe wie ein Berechnungsparameter erhalten. Beschreiben Sie jedoch die Auswahl, damit wichtige Abhängigkeiten nicht nur wegen schwieriger Erfassung fehlen.

Benennen Sie Quelle und Zeitpunkt jedes Standnachweises. Ein manuell gepflegter Wert kann veraltet sein; ein Export kann mehr oder weniger als den benötigten Umfang enthalten. Prüfen Sie, ob der Nachweis den tatsächlichen Zustand zuverlässig beschreibt. Ein Dateiname wie „final“ ist dafür kein ausreichender Versionsbezug.

Quellen: [1]

Beispiel: unveränderte Software, geänderte Schnittstellenregel

Das Szenario ist konstruiert. Die Anwendungsversion bleibt gleich, aber ein Mapping ändert die Umrechnung eines Messwerts. Ein Inventar, das nur Produktversionen erfasst, meldet keinen Unterschied. Die fachliche Verarbeitung hat sich dennoch verändert. Die Baseline muss deshalb den relevanten Mappingstand einschließen.

Bereiten Sie einen bekannten Datenfall vor. Vergleichen Sie genehmigte Regel, tatsächliche Konfiguration und Ergebnis im Empfänger. Dokumentieren Sie die Quelle des Konfigurationsnachweises. Wird eine Differenz entdeckt, prüfen Sie Zeitpunkt und betroffenen Datenumfang. Eine nachträgliche Anpassung des Baselineblatts macht eine ungeprüfte Änderung nicht rückwirkend bewertet.

Nach Korrektur oder geeigneter Bewertung wird der neue Stand eindeutig bestätigt. Wiederholen Sie passende Referenzfälle. Erhalten Sie den früheren Bezug, damit historische Ergebnisse erklärbar bleiben. Die Baseline ist damit ein kontrollierter Übergang zwischen Ständen, keine ständig überschriebene Liste ohne Geschichte.

Quellen: [1]

Abweichungen zwischen Soll und Ist bewerten

Eine Differenz kann dokumentarisch oder technisch sein. Vielleicht wurde die zulässige Änderung umgesetzt, aber der Nachweis nicht aktualisiert. Vielleicht wurde tatsächlich ungeprüft verändert. Diese Fälle benötigen unterschiedliche Behandlung. Klären Sie Ursache und mögliche Datenwirkung, bevor eine Liste nur formal korrigiert wird.

Benennen Sie, welche Nutzung bis zur Klärung angemessen ist. Ein falsch dokumentierter kosmetischer Parameter hat andere Folgen als eine ungeklärte Ergebnisregel. Die Entscheidung richtet sich nach konkreter Wirkung. Pauschales Blockieren jeder Differenz und pauschales Akzeptieren jeder Differenz sind gleichermaßen unpräzise.

Verknüpfen Sie die Bewertung mit Change, Incident oder Abweichung, soweit passend. Der Standnachweis sollte auf die führende Entscheidung verweisen. Vermeiden Sie widersprüchliche Kopien derselben Freigabe in mehreren Dateien. Eine klare Referenz ist oft besser als redundante Texte.

Quellen: [1]

Baseline bei Änderung und Wiederherstellung verwenden

Vor einer Änderung hilft die Baseline, betroffene Komponenten und Abhängigkeiten zu erkennen. Nach Übernahme bestätigt sie den neuen tatsächlichen Stand. Für Wiederherstellung kann sie zeigen, welche Versionen und Einstellungen zusammen benötigt werden. Ein Backup ohne passende Konfigurationsinformation kann diese Aufgabe nur begrenzt erfüllen.

Prüfen Sie Unterschiede zwischen Test und Produktion. Andere Endpunkte, Rollen oder Datenmengen können die Aussage eines Tests verändern. Die Baseline sollte relevante Unterschiede benennen, statt vollständige Identität zu behaupten. Geeignete zusätzliche Kontrollen bestätigen die Übertragbarkeit auf den vorgesehenen Betrieb.

Bei Cloud-Diensten stehen nicht immer alle technischen Details zur Verfügung. Dokumentieren Sie verfügbare Anbieterinformationen und eigene Konfiguration. Fehlende Transparenz wird risikobezogen bewertet. Eine unbekannte Komponente sollte nicht durch eine erfundene Versionsnummer scheinbar vollständig dokumentiert werden.

Quellen: [1]

Pflege und Übergabe praktikabel organisieren

Benennen Sie Zuständigkeit und Auslöser für Aktualisierung. Eine Baseline, die nur beim jährlichen Audit geöffnet wird, kann den laufenden Änderungsprozess kaum unterstützen. Integrieren Sie die Pflege in tatsächliche Übernahme- und Betriebsabläufe. Die notwendige Form hängt von Systemgröße und vorhandenen Werkzeugen ab.

Üben Sie eine Recherche: Welcher Stand galt bei einem bezeichneten Ergebnis und welcher Change führte zum aktuellen Zustand? Ein berechtigter Mitarbeiter sollte die Antwort mit den vorgesehenen Unterlagen finden. Wenn dies nur der ursprüngliche Administrator kann, fehlt möglicherweise eine geeignete Übergabe.

Quellen: [1]

Arbeitsvorlage: Sollstand, Teststand und tatsächlichen Betrieb vergleichen

Wählen Sie eine kritische Funktion und erfassen Sie die dafür relevanten Stände. Im Beispiel hängt eine Ergebnisumrechnung von Anwendung, Mapping und Parameter ab. Der Vergleich soll zeigen, ob die geprüfte Kombination tatsächlich betrieben wird. Ein identischer Produktname ist kein ausreichender Standbezug.

Führen Sie Unterschiede als bewertete Befunde. Eine Dokumentationslücke und eine ungeprüfte technische Änderung haben unterschiedliche Bedeutung. Klären Sie Ursache und Datenwirkung, bevor nur der Baselineeintrag angepasst wird. Die aktuelle Liste darf keine rückwirkende Scheinfreigabe erzeugen.

Eine Baseline kann auf mehrere geeignete technische Nachweise verweisen. Sie muss nicht jeden Wert redundant kopieren. Wichtig sind eindeutige Referenzen und verständliche Zuständigkeit. Prüfen Sie praktisch, ob ein anderer berechtigter Mitarbeiter den Stand und seine fachliche Bedeutung findet.

Quellen: [1]

Die nächsten Schritte

• Kritische Konfigurationselemente auswählen und begründen.
• Geprüften Stand mit Systembezug und Datum sichern.
• Änderungen gegen diese Baseline bewerten.
• Aktiven Betriebsstand regelmäßig und anlassbezogen abgleichen.