Risk-Based VMP und Lifecycle: ICH Q9/Q10 und Change Control integrieren, um den validierten Zustand aufrechtzuerhalten

Risk-Based VMP und Lifecycle: wie man Validierung nachhaltig und verteidigbar macht

Ein wirksamer Validation Master Plan (VMP) darf nicht nur beschreiben, was validiert wurde. Er muss erklären, wie das Unternehmen entscheidet, was validiert werden muss, mit welcher Tiefe und wie der validierte Zustand über die Zeit aufrechterhalten wird.

Der zentrale Punkt ist: Der risk-based Approach ist keine Modeerscheinung. Er ist der einzige nachhaltige und verteidigbare Weg, Validierung zu steuern.

Zwei gegensätzliche Fehler führen häufig zu schwierigen Inspektionen:

• Under-Validation, also Lücken bei kritischen Assets, Prozessen oder Systemen;
• Over-Validation, also alles auf die gleiche Weise zu validieren, mit übermäßiger Dokumentation und zu vielen Tests, bis der Plan nicht mehr aufrechterhalten werden kann.

Der moderne Ansatz, der mit Annex 15 und der Logik von ICH Q9/Q10 übereinstimmt, fordert die Nutzung von Quality Risk Management, um Scope, Umfang der Aktivitäten und Aufrechterhaltung des validierten Zustands über den gesamten Lifecycle zu definieren.

Inhaltsverzeichnis

• Warum risk-based der einzige nachhaltige und verteidigbare Weg ist
• Step 1 — Schreiben Sie die Risk Policy klar in den VMP
• Step 2 — Übersetzen Sie Risiko in Validierungsstrategie
• Step 3 — Lifecycle: einmal validiert bedeutet nicht für immer validiert
• Step 4 — Change Control: der Punkt, an dem man gewinnt oder verliert
• Step 5 — Computergestützte Systeme: von dokumentarischer CSV zu risikobasierter Assurance
• Step 6 — Validierungs-KPI für reife Standorte
• Implementierungs-Roadmap 30–60–90 Tage
• FAQ zum risk-based VMP
• Möchten Sie risk-based und lifecycle wirklich auf Ihren VMP anwenden?

1. Warum risk-based der einzige nachhaltige und verteidigbare Weg ist

Ein Validierungssystem kann nicht alles gleich behandeln.

Ein kritischer Autoklav, eine sterile Utility, ein computergestütztes GxP-System und ein Equipment mit geringem Impact können nicht denselben Umfang an Testing, Evidenz und Review erfordern.

Der risk-based Approach dient dazu, zwei gefährliche Extreme zu vermeiden:

• zu wenig zu tun, wo das Risiko hoch ist;
• zu viel zu tun, wo das Risiko niedrig ist.

1.1 Under-Validation

Under-Validation liegt vor, wenn kritische Assets, Systeme oder Prozesse nicht mit ausreichender Tiefe qualifiziert oder validiert werden.

Typische Beispiele:

• ein GxP-System ist nicht im Scope enthalten;
• eine kritische Utility wurde nur oberflächlich qualifiziert;
• ein impacting Change wurde ohne Validation Impact Assessment geschlossen;
• Equipment wird in der Produktion verwendet, ohne ausreichende Evidenz;
• Cleaning Validation ist nicht proportional zum tatsächlichen Risiko.

In Audits führt dies sofort zu Fragen zur Fähigkeit des Unternehmens, Produktqualität, Patientensicherheit und Data Integrity zu kontrollieren.

1.2 Over-Validation

Over-Validation ist der gegenteilige Fehler: alles mit demselben Detailgrad zu validieren, auch wenn das Risiko niedrig ist.

Das Ergebnis ist ein schwerfälliges, langsames und schwer aufrechtzuerhaltendes System.

Typische Signale:

• zu viele Protokolle, die nicht wirklich notwendig sind;
• repetitive Tests ohne Rationale;
• time-based Requalification für alles, ohne Trends oder Kritikalität zu berücksichtigen;
• Backlog überfälliger Aktivitäten;
• riesige, aber wenig nützliche Dokumentation;
• Glaubwürdigkeitsverlust, weil der Plan nicht eingehalten wird.

Ein gut im VMP beschriebener risk-based Approach zeigt, dass das Unternehmen nicht „weniger Validierung“ macht, sondern die richtige Validierung dort durchführt, wo sie wirklich erforderlich ist.

2. Step 1 — Schreiben Sie die Risk Policy klar in den VMP

Der erste Schritt besteht darin, im VMP klar zu beschreiben, wie das Unternehmen Quality Risk Management auf Validierung anwendet.

Es reicht nicht aus, „risk-based approach“ zu schreiben. Sie müssen erklären, wie dieser Ansatz funktioniert.

2.1 Was die Risk Policy deklarieren muss

Im VMP sollten Sie angeben:

• welche Methode zur Risikobewertung verwendet wird;
• wie hohes, mittleres und niedriges Risiko definiert werden;
• welche Kriterien für Schweregrad, Wahrscheinlichkeit und Erkennbarkeit verwendet werden;
• wie Risiko mit dem Testumfang verknüpft wird;
• wie Risiko mit dem Evidenzniveau verknüpft wird;
• wann eine unabhängige QA Review erforderlich ist;
• wann Requalification oder Revalidation erforderlich ist;
• wie Risiko bei Change, Abweichungen oder Trends neu bewertet wird.

2.2 Beispiele verwendbarer Methoden

Sie können unterschiedliche Methoden verwenden, solange sie definiert und konsistent sind.

Beispiele:

• Matrix Schweregrad / Wahrscheinlichkeit / Erkennbarkeit;
• FMEA;
• Impact Assessment;
• Criticality Assessment;
• Risk Ranking Low / Medium / High;
• risk-based Testing Strategy.

Die Wahl des Tools ist weniger wichtig als die konsistente Anwendung.

2.3 Beispiel einer einfachen 3×3-Matrix

Eine einfache Matrix kann ausreichend sein, wenn sie gut dokumentiert ist.

Schweregrad

Bewertet den potenziellen Impact auf:

• Produktqualität;
• Patientensicherheit;
• Data Integrity;
• GMP-Compliance;
• Fähigkeit zur Prozesskontrolle.

Wahrscheinlichkeit

Bewertet, wie plausibel der Failure Mode ist, unter Berücksichtigung von:

• Komplexität des Systems;
• Historie von Abweichungen;
• Nutzungsfrequenz;
• operativer Kritikalität;
• vorheriger Erfahrung;
• Automatisierungsgrad oder manuellem Eingriff.

Erkennbarkeit

Bewertet, wie leicht der Fehler erkannt werden kann, bevor er das Produkt oder die Freigabe beeinflusst.

Beispiele für Faktoren:

• Alarme;
• Interlocks;
• In-Process Controls;
• QA Review;
• Audit Trail;
• Double Check;
• routinemäßiges Monitoring.

Das Ergebnis kann klassifiziert werden als:

• niedriges Risiko;
• mittleres Risiko;
• hohes Risiko.

Sie müssen nicht übermäßig komplex sein. Sie müssen konsistent, dokumentiert und verteidigbar sein.

3. Step 2 — Übersetzen Sie Risiko in Validierungsstrategie

Der eigentliche Wert eines risk-based VMP liegt darin, Risiko in eine operative Strategie zu übersetzen.

Viele VMP erklären Quality Risk Management, zeigen aber nicht, was sich dadurch in der Praxis ändert.

3.1 Hohes Risiko

Für Systeme, Prozesse oder Assets mit hohem Risiko sollte die Strategie Folgendes vorsehen:

• vollständige Qualifizierung oder Validierung;
• Worst-Case-Testing;
• robuste Evidenzen;
• unabhängige QA Review;
• strenge Akzeptanzkriterien;
• Abweichungen mit hohem Aufmerksamkeitsgrad managen;
• strukturierte Periodic Review;
• gegebenenfalls event-based Requalification oder Revalidation;
• starke Verbindung mit Change Control.

Beispiele:

• kritische Utilities;
• computergestützte GxP-Systeme mit Impact auf Freigabe oder Data Integrity;
• sterile Prozesse;
• Cleaning Validation für Hochrisikoprodukte;
• kritisches Equipment für CPP/CQA.

3.2 Mittleres Risiko

Für Assets oder Prozesse mit mittlerem Risiko kann die Strategie gezielter sein.

Beispiele für den Ansatz:

• Tests fokussiert auf kritische Parameter;
• Rationalisierung der Prüfungen;
• Verifizierung der wichtigsten Kontrollen;
• proportionale QA Review;
• vollständige, aber nicht übermäßige Dokumentation;
• Aufmerksamkeit auf sensible Punkte;
• Periodic Review auf Basis von Daten und Trends.

Das Ziel ist, Kontrolle aufrechtzuerhalten, ohne unnötige Dokumentation zu erzeugen.

3.3 Niedriges Risiko

Für Elemente mit niedrigem Risiko kann eine schlankere Verifizierung ausreichend sein.

Beispiele:

• Basisverifizierung;
• prozedurale Kontrollen;
• dokumentarische Bestätigung;
• dokumentiertes Commissioning, falls angemessen;
• begründeter Ausschluss aus dem GMP-Scope, falls anwendbar;
• Review nur bei relevantem Change.

Achtung: niedriges Risiko bedeutet nicht „keine Kontrolle“. Es bedeutet proportionale Kontrolle.

3.4 Die Brücke zwischen QRM und operativem Plan

Der wichtigste Teil besteht darin, jedes Risikoniveau mit einer praktischen Entscheidung zu verknüpfen.

Beispielhafte Logik:

• hohes Risiko → vollständiges Testing und robuste Review;
• mittleres Risiko → gezieltes Testing auf kritische Parameter;
• niedriges Risiko → Basisverifizierung und prozedurale Kontrolle.

Das ist die Brücke zwischen Quality Risk Management und Validierungsplan. Und genau diese Brücke fehlt in vielen VMP.

4. Step 3 — Lifecycle: einmal validiert bedeutet nicht für immer validiert

Ein häufiger Fehler besteht darin, Validierung als punktuelles Ereignis zu betrachten.

In Wirklichkeit kann ein heute validiertes System morgen nicht mehr unter Kontrolle sein, wenn sich der Prozess, die Software, Komponenten oder Trends ändern.

Validierung muss über den gesamten Lifecycle gesteuert werden.

4.1 Was der VMP erklären muss

Der VMP muss beschreiben, wie das Unternehmen:

• den validierten Zustand aufrechterhält;
• Performance überwacht;
• Trends und Abweichungen bewertet;
• entscheidet, ob requalifiziert werden muss;
• entscheidet, ob revalidiert werden muss;
• CPV, PQR/APR und Periodic Review integriert;
• Change Control und Validation Impact Assessment verbindet;
• Obsoleszenz, Upgrades und Decommissioning steuert.

4.2 Kritisches Equipment

Für kritisches Equipment kann eine nachhaltige Policy basieren auf:

• Periodic Review;
• event-based Triggern;
• Performance-Trends;
• relevanten Abweichungen;
• außerordentlicher Maintenance;
• Kalibrierungen außerhalb der Toleranz;
• impacting Changes;
• Nutzung des Systems.

Dieser Ansatz ist oft verteidigbarer als eine Requalification alle 12 Monate „unabhängig von allem“, sofern das Rationale gut dokumentiert ist.

4.3 Produktionsprozesse

Für Produktionsprozesse sollte der Lifecycle Folgendes umfassen:

• PPQ;
• Continued Process Verification;
• Trends kritischer Parameter;
• Trends von Abweichungen;
• PQR/APR;
• Bewertung von CAPA;
• Monitoring der Prozessfähigkeit;
• Bewertung möglicher Drift-Signale.

PQR/APR und CPV müssen echte Inputs werden, um zu entscheiden, ob der Prozess im validierten Zustand bleibt.

4.4 Kritische Utilities

Für kritische Utilities kann die Strategie umfassen:

• Initial Qualification;
• routinemäßiges Monitoring;
• mikrobiologische, chemische und physikalische Trends;
• Periodic Review;
• Deviation Management;
• Preventive Maintenance;
• Bewertung von Changes;
• gegebenenfalls gezielte Requalification.

Auch hier gilt immer dasselbe Prinzip: Daten und Risiko müssen Entscheidungen steuern.

5. Step 4 — Change Control: der Punkt, an dem man gewinnt oder verliert

Change Control ist häufig der Punkt, an dem der validierte Zustand aufrechterhalten oder verloren wird.

Ein scheinbar kleiner Change kann Impact auf kritische Parameter, Software, Data Flow, Recipes, Materialien, Cleaning oder Prozesskontrollen haben.

5.1 Validation Impact Assessment

Ein robuster Change Control muss immer einen Abschnitt Validation Impact Assessment enthalten.

Dieser Abschnitt muss Fragen beantworten wie:

• Ist das System validiert?
• Betrifft der Change kritische Parameter?
• Betrifft der Change Set-Points oder Recipes?
• Verändert der Change Data Flow oder Data Integrity?
• Verändert der Change Materialien, Komponenten oder Konfiguration?
• Hat der Change Impact auf Cleaning, Prozess oder Kontrollen?
• Sind Tests erforderlich?
• Ist Requalification erforderlich?
• Ist Revalidation erforderlich?
• Welche Dokumente müssen aktualisiert werden?
• Müssen VMP oder Master List aktualisiert werden?

5.2 Gutes Beispiel: proportionale Entscheidung

Fall: Austausch einer Temperatursonde an validiertem Equipment.

Risk Assessment:

• äquivalente Spezifikationen;
• keine Änderung des Funktionsprinzips;
• kein Impact auf Recipe oder Kontrolllogik;
• kritische Komponente, aber like-for-like ersetzt.

Proportionale Maßnahme:

• Kalibrierung;
• Funktionsprüfung;
• Aktualisierung der Records;
• dokumentierte Bewertung;
• keine vollständige OQ, wenn das Rationale zeigt, dass sie nicht erforderlich ist.

Dies ist ein Beispiel für eine proportionale und verteidigbare Entscheidung.

5.3 Schlechtes Beispiel: fast sicheres Finding

Fall: GxP-Software-Upgrade durch IT ohne Einbindung von QA/Validation.

Probleme:

• kein Validation Impact Assessment;
• keine Data-Integrity-Bewertung;
• kein dokumentiertes Testing kritischer Funktionen;
• keine Audit-Trail-Review;
• keine Aktualisierung der Dokumentation;
• keine Evidenz des validierten Zustands nach dem Change.

Im Audit ist dies ein fast sicheres Finding, weil nicht nachgewiesen werden kann, dass das System nach dem Change unter Kontrolle geblieben ist.

6. Step 5 — Computergestützte Systeme: von dokumentarischer CSV zu risikobasierter Assurance

Für computergestützte GxP-Systeme muss der VMP zwei Fehler vermeiden:

• CSV als dokumentarisches Dossier getrennt vom PQS zu behandeln;
• alles gleich zu testen, ohne kritische und nicht kritische Funktionen zu unterscheiden.

Der reifere Ansatz basiert auf Assurance, Risiko und Data Integrity.

6.1 Kritische Funktionen identifizieren

Im VMP oder CSV Plan muss klar sein, wie kritische Funktionen identifiziert werden.

Beispiele:

• Produktfreigabe;
• GMP-Berechnungen;
• Recipe Management;
• Audit Trail;
• Access Management;
• elektronische Signaturen;
• Data Flow;
• Datenerfassung;
• Backup und Restore;
• Schnittstellen mit anderen Systemen;
• Reports, die für GMP-Entscheidungen verwendet werden.

6.2 Robustes Testing dort durchführen, wo es erforderlich ist

Das robusteste Testing muss sich auf Funktionen konzentrieren, die Impact haben können auf:

• Produktqualität;
• Patientensicherheit;
• Data Integrity;
• regulatorische Compliance;
• GMP-Entscheidungen.

Für Funktionen mit niedrigem Impact kann die Dokumentation schlanker sein, sofern das Rationale klar ist.

6.3 Verschlanken, ohne Kontrolle zu verlieren

Ein moderner Ansatz bedeutet nicht, Kontrolle zu reduzieren.

Er bedeutet:

• redundante Tests zu eliminieren;
• Supplier Evidence zu nutzen, wenn anwendbar;
• internes Testing auf kritische Funktionen zu fokussieren;
• das Rationale zu dokumentieren;
• Data Integrity, Audit Trail, Zugänge und Backups unter Kontrolle zu halten.

Der VMP muss diese Logik klar und verteidigbar zeigen.

7. Step 6 — Validierungs-KPI für reife Standorte

Validierungs-KPI sind nicht immer verpflichtend, stellen aber ein Reifezeichen des Standorts dar.

Wenn ein Inspektor fragt:

„Wie messen Sie die Wirksamkeit des Validierungssystems?“

können gut gewählte KPI den Unterschied machen.

7.1 Nützliche KPI

Beispiele für nützliche KPI:

• Prozentsatz der Change Controls mit abgeschlossenem Validation Impact Assessment;
• durchschnittliche Closure Time von Validierungsabweichungen;
• Backlog überfälliger Requalifications;
• Prozentsatz der Periodic Reviews, die on-time abgeschlossen wurden;
• Trend von Abweichungen nach Kategorie: Equipment, IT, Utilities, Cleaning;
• Prozentsatz der validation-related CAPA, die on-time geschlossen wurden;
• Anzahl der Requalifications, die durch Changes oder Abweichungen ausgelöst wurden;
• Anzahl der Gaps, die während Periodic Review identifiziert wurden.

7.2 Wie KPI verwendet werden sollten

KPI müssen zu Entscheidungen führen.

Sie sollten genutzt werden, um:

• Backlog zu identifizieren;
• Prioritäten zu setzen;
• Eskalation auszulösen;
• Ressourcen zu begründen;
• die Strategie zur Aufrechterhaltung zu verbessern;
• Management Review oder Quality Council zu speisen.

Ein KPI ohne Entscheidung ist nur eine Zahl. Ein KPI, der Maßnahmen steuert, zeigt Governance.

8. Implementierungs-Roadmap 30–60–90 Tage

Wenn Sie den VMP stärker risk-based und lifecycle-oriented machen möchten, können Sie einer progressiven Roadmap folgen.

8.1 Von 0 bis 30 Tagen

Ziel: die dokumentarische Basis ausrichten.

Maßnahmen:

• Asset List, VMP, Maintenance und Calibration abgleichen;
• Konsistenz zwischen VMP und Master List prüfen;
• fehlende Assets oder Systeme identifizieren;
• Risikomatrix und Kriterien formalisieren;
• Kategorien High / Medium / Low definieren;
• mögliche kritische Gaps identifizieren;
• Owner für jede Maßnahme festlegen.

8.2 Von 31 bis 60 Tagen

Ziel: Risiko in operative Prozesse integrieren.

Maßnahmen:

• Validation Impact Assessment in Change Control integrieren;
• SOPs für Qualification und Validation aktualisieren;
• Validation Master List erstellen oder aktualisieren;
• Status und Daten den Assets zuweisen;
• Eskalation für High-Impact Changes definieren;
• Change Control, Abweichungen und CAPA mit der Validierungsstrategie verknüpfen.

8.3 Von 61 bis 90 Tagen

Ziel: das System im Lifecycle nachhaltig machen.

Maßnahmen:

• Policy zur Aufrechterhaltung des validierten Zustands definieren;
• Kriterien für CPV, Review, Requalification und Revalidation festlegen;
• Audit-Evidence-Paket je Kategorie erstellen;
• wesentliche KPI definieren;
• Periodic Review einrichten;
• reale Beispiele für risk-based Entscheidungen vorbereiten;
• VMP mit Management Review oder Quality Council integrieren, falls anwendbar.

9. FAQ zum risk-based VMP

9.1 Wann muss ich nach einem Change revalidieren?

Sie müssen revalidieren, wenn der Change kritische Parameter, Prozesskontrolle, Cleaning, Data Integrity oder Kontrollstrategien beeinflusst.

Die Entscheidung muss risk-based sein und im Change Control über ein Validation Impact Assessment dokumentiert werden.

9.2 Bedeutet risk-based, weniger Tests zu machen?

Nein.

Risk-based bedeutet, die richtigen Tests dort durchzuführen, wo das Risiko real ist, und gleichzeitig sowohl Lücken als auch unnötige Dokumentation zu vermeiden.

Das Ziel ist nicht, Arbeit zu reduzieren, sondern sie proportional, verteidigbar und nachhaltig zu machen.

9.3 Kann ich Supplier Documentation nutzen, um internes Testing zu reduzieren?

Ja, aber nur wenn die Lieferantendokumentation anwendbar, bewertet und mit Ihrer spezifischen Nutzung verknüpft ist.

Sie müssen prüfen:

• Scope des Dokuments;
• Version des Systems oder der Komponente;
• getestete Bedingungen;
• abgedeckte Funktionen;
• GxP-Kritikalität;
• mögliche Gaps gegenüber Ihrem Prozess.

9.4 Wie zeige ich, dass der Lifecycle unter Kontrolle ist?

Sie können dies nachweisen durch:

• Change Control mit Validation Impact Assessment;
• Periodic Review;
• CPV;
• PQR/APR;
• Trending;
• Deviations/CAPA;
• dokumentierte Requalification oder Revalidation;
• aktualisierte Master List;
• KPI, falls implementiert.

9.5 Wie vermeide ich Over-Validation?

Um Over-Validation zu vermeiden, müssen Sie:

• klare Risikokriterien definieren;
• Risiko und Testumfang miteinander verknüpfen;
• kritische und nicht kritische Funktionen unterscheiden;
• Supplier Evidence nutzen, wenn anwendbar;
• redundante Tests vermeiden;
• Backlog und nicht notwendige Aktivitäten periodisch überprüfen.

10. Möchten Sie risk-based und lifecycle wirklich auf Ihren VMP anwenden?

Wenn Sie wirklich einen risk-based und lifecycle-orientierten Ansatz mit sofort nutzbaren Modellen anwenden möchten – wie Risk Matrix, Impact Assessment, Master List, Lifecycle Tracker und reale Audit Cases –, finden Sie alles in der Premium-Guide von GuideGxP:

Validation Master Plan (VMP): Govern Validation and Defend It During Audits