GxP-Fernwartung: Lieferantenzugriffe kontrollieren

1. Fernwartung als konkrete Tätigkeit abgrenzen

Annex 11 § 3.1 nennt Wartung über Fernzugriff ausdrücklich als Beispiel einer Drittleistung. Hinzu kommen die passenden Kontrollen für Berechtigungen, Änderungen und Vorfälle. Maßgeblich ist hier die am 7. Oktober 2026 weiterhin gelistete Fassung Januar 2011 im Humanarzneimittel-GMP-Bereich.

Der einzelne Einsatz braucht einen verständlichen Auftrag. „System reparieren“ lässt offen, welche Umgebung, Daten oder Einstellungen betroffen sein dürfen. Benennen Sie die beobachtete Störung, den freigegebenen Untersuchungsumfang und die zuständige betriebliche Ansprechperson. Ein bestehender Vertrag kann die allgemeinen Regeln tragen; der konkrete Vorgang macht ihre Anwendung nachvollziehbar.

Quellen: [1] [5]

2. Vor dem Zugriff die notwendigen Informationen bereitstellen

Beschreiben Sie Zielsystem und Instanz eindeutig. Eine ähnliche Bezeichnung von Test- und Produktivumgebung kann erhebliche Verwechslungen verursachen. Legen Sie fest, welche Daten für die Untersuchung erforderlich sind und ob sensible Inhalte sichtbar werden. Datenschutz- und Informationssicherheitsfragen benötigen gegebenenfalls ihre eigene fachliche Bewertung.

Klären Sie außerdem den Ausgangszustand: Welche Version und Konfiguration sind relevant, welche Vorgänge laufen gerade und welche Einschränkungen gelten? Wenn eine Änderung vorgesehen ist, müssen ihre Voraussetzungen zum vereinbarten Änderungsverfahren passen. Die bloße Anwesenheit einer internen Person am Bildschirm ersetzt keine vorherige Verständigung über erlaubte Eingriffe.

Quellen: [1] [4]

3. Einen begrenzten Supportauftrag formulieren

Die folgende eigene Arbeitshilfe strukturiert einen Einsatz. Sie schreibt kein bestimmtes Ticketsystem oder Fernwartungsprodukt vor. Wichtig ist, dass Auftrag, Person und Tätigkeit zusammengeführt werden können und dass relevante Erweiterungen des Auftrags nicht unbemerkt erfolgen.

Ein zunächst lesender Diagnosezugriff kann sich im Verlauf als unzureichend erweisen. Dann ist zu entscheiden, ob und unter welchen Bedingungen ein schreibender Eingriff zulässig ist. Diese Entscheidung sollte an der möglichen Wirkung ausgerichtet sein. Eine kleine technische Änderung kann fachlich bedeutsam sein, etwa wenn sie eine Materialstatuszuordnung beeinflusst.

Quellen: [1] [3]

4. Zugriff passend begrenzen und authentifizieren

Bewerten Sie Rechte, erreichbare Systeme und nutzbare Zugangswege. Der Zugriff sollte die beauftragte Tätigkeit ermöglichen, ohne unnötig weitere Daten oder Umgebungen zu öffnen. Individuelle Identifizierbarkeit ist wichtig, damit ein technischer Zugang einer tatsächlichen Person zugeordnet werden kann.

PIC/S PI 041-1 behandelt Fernzugriff auf kritische Daten über das Internet einschließlich zusätzlicher Authentifizierungstechniken. Übertragen Sie diese konkrete Schutzfrage auf Ihre Architektur. Daraus folgt keine universelle Gleichsetzung von Fernzugriff, elektronischer Signatur und einem bestimmten Produkt. Auch eine starke Anmeldung hilft wenig, wenn anschließend unbeschränkte Rechte oder unbeobachtete alternative Zugänge bestehen bleiben.

Quellen: [1] [4]

5. Illustrativer Einsatz mit vorab definiertem Soll

Das Beispiel ist konstruiert: In DOC-P erscheint für Dokument SOP-018 eine falsche Anzeige. Der freigegebene Auftrag erlaubt zunächst nur lesende Diagnose. Der Support erkennt eine Konfigurationsursache und schlägt eine Änderung vor. Im eigenen Sollmodell darf er diese erst nach der zusätzlichen betrieblichen Entscheidung durchführen.

Nach der Änderung werden die richtige Anzeige und der Bezug zur gültigen Dokumentrevision geprüft. Der Zugriff endet anschließend kontrolliert. Die folgende Matrix beschreibt erwartete Ergebnisse, keinen durchgeführten Produkttest. Insbesondere wird nicht unterstellt, dass jedes Fernwartungswerkzeug Sitzungen oder Rechte auf dieselbe Weise beendet.

Quellen: [1] [4] [2]

6. Tätigkeiten verständlich nachweisen

Eine erfolgreiche Anmeldung belegt nicht alle danach ausgeführten Handlungen. Wählen Sie Nachweise, die relevante Tätigkeiten und Änderungen erkennen lassen. Das können geeignete technische Protokolle, Konfigurationsvergleiche und ein konkreter Tätigkeitsbericht sein. Welche Kombination benötigt wird, richtet sich nach Auftrag und möglicher Wirkung.

Eine vollständige Bildschirmaufzeichnung ist nicht als pauschale Pflicht aus den zitierten Passagen abzuleiten. Sie würde zudem nicht automatisch die fachliche Bewertung ersetzen. Entscheidend ist, ob Sie später nachvollziehen können, welche relevanten Eingriffe stattfanden, ob sie erlaubt waren und ob die erwartete Wirkung ohne ungeklärte Nebenfolgen erreicht wurde.

Quellen: [1] [4] [2]

7. Zugriff und Störung getrennt abschließen

Prüfen Sie, wie der Zugang tatsächlich beendet wird. Das Entfernen einer Berechtigung kann je nach System anders auf bestehende Sitzungen wirken als auf neue Anmeldungen. Auch zusätzlich angelegte Konten, vorübergehende Netzwerkfreigaben oder abgelegte Hilfsdateien können relevant bleiben. Der konkrete Abbau muss zur technischen Umgebung passen.

Bewerten Sie unabhängig davon das fachliche Ergebnis. Ist die Störung behoben, sind veränderte Daten oder Einstellungen geprüft und sind offene Fragen dokumentiert? Annex 11 § 13 unterscheidet die Bewertung aller Vorfälle von der Ursachenidentifikation kritischer Vorfälle. Nicht jeder technische Fehler benötigt automatisch dieselbe formale Ursachenarbeit; seine möglichen Folgen dürfen aber nicht unbewertet bleiben.

Quellen: [1] [4]

8. Den Ablauf im kleinen Team praktikabel machen

Vereinbaren Sie einen regulären Weg und einen begrenzten Notfallweg. Wenn die normalerweise zuständige Person nicht erreichbar ist, muss klar sein, wer entscheiden kann und welche Eingriffe zulässig bleiben. Ein ständig offener umfassender Zugang ist keine notwendige Folge einer kleinen Organisation.

Gehen Sie den Ablauf mit IT, Systemverantwortung, QA und Dienstleister an einem konkreten Fall durch. Prüfen Sie dabei auch, ob die geforderten Nachweise tatsächlich erzeugt und bereitgestellt werden können. Ein ideales Formular hilft wenig, wenn der Vertrag, das Werkzeug oder die Bereitschaftsorganisation die vorgesehenen Schritte nicht unterstützt.

• Zielinstanz, Anlass, benannte Person und Anfangsumfang geklärt.
• Rechte und Authentifizierung zur tatsächlichen Architektur passend bewertet.
• Erweiterung vom Lesen zum Ändern kontrolliert geregelt.
• Relevante Tätigkeits- und Ergebnisnachweise vereinbart.
• Wirksames Zugriffsende einschließlich zusätzlicher Freigaben geprüft.
• Fachlicher Abschluss, offene Punkte und Vorfallbewertung dokumentiert.

Quellen: [1] [3] [4]