Quality & Compliance · fachlich-regulatorisch
Significon entwirft das Qualitätssystem, in dem GMP- und GDP-Vorgaben zur geprüften Spezifikation werden, validiert den einzelnen Systemzustand im Vorhaben und schließt mit Testmanagement die Lücke, die an jeder Systemgrenze entsteht. Audit-Readiness ist das Ergebnis dieser Kette — nicht ein separates Projekt.
Das Problem
Die vier Muster unten stehen in fast jeder gewachsenen Systemlandschaft, unabhängig vom Regelwerksstand. Keines ist der Fehler einzelner Personen. Jedes wird durch eine Revision sichtbar, nicht durch sie verursacht.
01
Der Ordner ist vollständig, das Bild darin ist zwei Releases alt. Zwischen dem dokumentierten und dem laufenden Systemzustand liegen Änderungen, die einzeln jeweils zu klein für eine erneute Prüfung schienen. In der Inspektion zählt nicht, wie viel dokumentiert ist, sondern ob das Dokumentierte das System beschreibt, das läuft.
02
Zwei Fehler mit derselben Ursache: entweder wird alles gleich tief geprüft, oder es wird geprüft, was sich leicht prüfen lässt. Annex 11 stellt den Umfang in Abschnitt 1 unter eine begründete und dokumentierte Risikobewertung. Wer keine hat, hat entweder zu viel getestet und kann es nicht rechtfertigen — oder zu wenig und hat es nicht gemerkt.
03
Jedes System ist für sich validiert. Der Prozess läuft über drei. Was an der Schnittstelle geschieht — welches Feld übernommen wurde, welcher Status gewonnen hat, welcher Zeitstempel gilt — ist in keinem der drei Vorhaben Prüfgegenstand, weil es in keinem der drei Anforderungen steht. Migrationen zeigen diese Lücke zuverlässig, und meist zu spät.
04
SOPs sind geschrieben, das Qualitätsmanagementsystem ist zertifiziert, der Dokumentationsstandard liegt vor. Trotzdem entscheidet jedes Projekt neu, was „validiert" bedeutet. Eine Vorgabe, die in der URS nicht auftaucht, wird nicht getestet — und ist in der Inspektion nicht Entlastung, sondern die Frage, warum sie nicht befolgt wurde.
Der Ansatz
Wir arbeiten von der Vorgabe zur Spezifikation und von der Spezifikation zum Nachweis, in dieser Richtung. Damit steht am Anfang nicht das Testprotokoll, sondern die Frage, welche Bedingung erfüllt werden muss und wer sie stellt: das Regelwerk, das Qualitätssystem, der Prozess. Erst danach steht fest, was zu spezifizieren und was zu prüfen ist.
Über die Tiefe entscheidet die Risikobewertung, nicht die Vorlage. Annex 11 verlangt den validierten Zustand und stellt den Umfang unter eine begründete und dokumentierte Risikobewertung; GAMP 5 ist der etablierte Rahmen, in dem dieser Zustand hergestellt wird, und ICH Q9 in der Fassung Q9(R1) liefert die Methode für die Begründung. Die Begründung selbst schuldet das Unternehmen — kein Leitfaden nimmt sie ihm ab.
KI kommt in diesen Prozessen als eingerahmter Schritt vor: definierte Eingabe, menschliche Freigabe, Audit Trail. Der verbindliche Rahmen dafür ist Annex 11 — kein Entwurf.
Aus dem, was das Regelwerk verlangt, wird eine Anforderung, die geprüft werden kann; aus der Anforderung eine Funktion, aus der Funktion ein Testfall. Jeder Schritt hat einen Vorgänger, auf den er sich beruft, und einen Nachfolger, der ihn belegt.
Vor jedem Testplan steht die Frage, welcher Fehler welche Wirkung auf Patient, Produkt und Daten hätte. Diese Antwort bestimmt die Tiefe. Eine übernommene Vorlage bestimmt sie nicht — und im Audit wird nach der Begründung gefragt, nicht nach der Vorlage.
Change Control und Periodic Review sind keine Nacharbeiten. Sie sind die Bedingung, unter der eine Abnahme über den Tag der Unterschrift hinaus eine Aussage bleibt. Deshalb gehören sie in das Vorhaben und nicht in die Zeit danach.
Die Kette
Links die Spezifikation, rechts der Nachweis, dazwischen die Zuordnung. Was oben liegt, gibt vor; was unten schließt, kehrt zurück.
Drei Dinge stehen in diesem Bild, die im Alltag auseinanderfallen. Erstens die Zuordnung: jede Anforderung wird gegen genau die Stufe geprüft, auf der sie formuliert wurde — die Traceability Matrix ist keine Anlage, sie ist die Verbindung selbst. Zweitens die Unterscheidung aus Annex 11: die Anwendung wird validiert, die IT-Infrastruktur qualifiziert; über den Umfang entscheidet eine begründete und dokumentierte Risikobewertung. Drittens der Rücklauf: die Freigabe zum Betrieb schließt das Vorhaben, nicht den Zustand. Jede Änderung führt in die Kette zurück, und der Periodic Review fragt, ob sie das getan hat.
Die Lösung
Die Kette ist eine; die Arbeit daran teilt sich in drei Zuständigkeiten. Sie greifen an denselben Anforderungen und unterscheiden sich in der Reichweite: was für alle Vorhaben gilt, was ein einzelnes Vorhaben leistet, und was über das Vorhaben hinausreicht.
Vorgabe
Bevor ein einzelnes System validiert wird, muss stehen, woran gemessen wird. Wir bauen diese Ebene auf und pflegen sie: das GDP-Qualitätssystem mit seinen SOPs, das Qualitätsmanagementsystem nach ISO 9001 oder ISO 13485 und den Zustand, in dem eine Inspektion keine Sonderlage ist.
Validierter Zustand
Ein System kommt über ein Vorhaben mit Anfang und Ende in den validierten Zustand. Das Ende ist die dokumentierte Abnahme und die Freigabe zum produktiven Betrieb — nicht der letzte Testbericht. Über die Tiefe entscheidet die Risikobewertung, methodisch nach ICH Q9.
Nachweis
Der Prozess läuft über Systemgrenzen, das Vorhaben endet an ihnen. Was dazwischen liegt, braucht eine eigene Teststrategie und einen eigenen Nachweis: Migration, Schnittstelle, Regression über den Lebenszyklus, Anwenderabnahme über mehrere Fachbereiche hinweg.
Zusatzinfo · Stand der Annex-11-Revision
Annex 11 ist seit dem 30. Juni 2011 in Kraft. Am 7. Juli 2025 wurden die Revision von Annex 11, die Revision von Kapitel 4 und ein neuer Annex 22 zur Konsultation gestellt; die Konsultation ist seit dem 7. Oktober 2025 beendet, eine finale Fassung und Übergangsfrist stehen noch nicht fest. Betroffen ist nicht ein einzelnes Projekt, sondern der gesamte Bestand validierter Systeme, der seit 2011 auf Annex 11 gebaut wurde.
Zu Annex 22: Der Entwurf nimmt generative KI und große Sprachmodelle aus seinem Anwendungsbereich aus. Wer heute einen KI-Schritt in einem GxP-Prozess betreibt, arbeitet damit unter Annex 11 — dem Regelwerk, das in Kraft ist, nicht unter dem Entwurf.
Warum Significon
Wer den Dokumentationsstandard schreibt, kennt den Testfall, der ihn später prüft. Sind Vorgabe, Spezifikation und Test auf drei Zulieferer verteilt, entsteht die Lücke genau an den Übergängen — und dort setzt die Nachfrage in der Inspektion an.
Diese Seite nennt bei jedem Regelwerk seinen Status: in Kraft, verbindlicher Teil des Leitfadens, Industrieleitfaden, Entwurf. Dieselbe Trennung liegt unseren Dokumenten zugrunde. Eine Anforderung, die sich stillschweigend auf einen Entwurf beruft, ist angreifbar — wir kennzeichnen sie, bevor jemand fragt.
Wir verkaufen keine Software und erteilen keine Zertifikate. Daraus folgt, dass eine Empfehlung zu Systemwahl, Prüfumfang oder Nacharbeit bei uns keinen Umsatz an anderer Stelle auslöst — und dass wir in der Systemauswahl auf Ihrer Seite des Tisches sitzen.
Welcher Teil Ihres validierten Bestands wird zur Nacharbeit, wenn das Regelwerk wechselt?
Ein Gespräch über den Bestand und die Reihenfolge — kein Angebot.