Inhaltsverzeichnis
Das Wichtigste vorab
Was gehört in einen brauchbaren Validierungsplan?
Der Plan verbindet vorgesehenen Gebrauch und Systemstand mit benötigten Ergebnissen, geeigneten vorhandenen Belegen, Ausführungsvoraussetzungen und Entscheidungswegen. Er benennt Zuständigkeiten, relevante Abhängigkeiten und den Umgang mit Änderungen und Abweichungen. Umfang und Tiefe folgen dem konkreten Risiko. Die vorgeschlagene Struktur ist eine Arbeitshilfe; ein gleichnamiges separates Dokument, eine feste Phasenanzahl oder ein universeller Zeitplan sind nicht für jedes System vorgegeben.
- Planen Sie überprüfbare Arbeitsergebnisse statt ausschließlich Dokumenttitel.
- Benennen Sie den Systemstand und die Voraussetzungen jeder relevanten Prüfung.
- Nutzen Sie geeignete vorhandene Nachweise mit ihrer dokumentierten Reichweite.
- Halten Sie Änderungen und noch offene Entscheidungen sichtbar, bevor die Ausführung darauf aufbaut.
1. Eine gemeinsame Planungsfrage beantworten
Die entscheidende Frage lautet: Was müssen wir für diesen vorgesehenen Gebrauch noch nachvollziehbar zeigen, und wie werden wir das erreichen? Ein Validierungsplan beantwortet diese Frage vorausschauend. Er hilft, unpassende Testtermine, fehlende Eingangsdokumente und ungeklärte Zuständigkeiten rechtzeitig zu erkennen. Ein Testprotokoll beschreibt dagegen die konkrete Prüfung; ein Bericht bewertet, was tatsächlich durchgeführt und beobachtet wurde.
Der regulatorische Beispielrahmen hier ist Humanarzneimittel-GMP. Annex 11 behandelt risikobasierte Validierung und Lebenszyklusnachweise für computergestützte Systeme. Annex 15 beschreibt unter anderem das standortbezogene Validierungsprogramm beziehungsweise eine gleichwertige Dokumentation. Seine konkreten Qualifizierungsstufen stehen im Anlagen-, Einrichtungs-, Versorgungs- und Prozesskontext; für Computersysteme verweist er auf Annex 11.
Unterscheiden Sie deshalb Standort-VMP, systembezogene Planung und einzelne Prüfunterlagen. Annex 15 nennt separate Pläne bei großen und komplexen Projekten als mögliche Hilfe zur Klarheit. Daraus wird keine Pflicht zu einem identischen Dokumenttitel für jede Software. Ihre geregelte Dokumentation muss die benötigten Entscheidungen tragen; die folgenden Arbeitshilfen zeigen eine mögliche Umsetzung.
2. Gebrauch, Grenze und betrachteten Stand festhalten
Beginnen Sie mit dem geplanten Gebrauch: Wer nutzt welche Funktion für welchen Prozess? Beschreiben Sie dann den betrachteten Stand von Anwendung, Konfiguration, relevanten Schnittstellen und Daten. Für eine Erweiterung kann der Plan auf eine bestehende Systembeschreibung verweisen und die Änderung präzise abgrenzen. Er muss nicht die gesamte Historie des Systems erneut erzählen.
Ein Ausschluss ist erst hilfreich, wenn seine Bedeutung klar ist. „ERP nicht im Umfang“ genügt beispielsweise nicht, wenn das ERP die für den Druck verwendeten Daten liefert. Dann muss mindestens feststehen, welche Daten und Kontrollen an dieser Grenze vorausgesetzt werden. Ein tatsächlich unveränderter, nicht betroffener Bereich kann begründet außerhalb der neuen Prüfungen bleiben.
Ordnen Sie offene Annahmen einem Verantwortlichen und einem benötigten Klärungszeitpunkt zu. Der Plan darf zu Beginn einen Entwicklungsstand haben. Bevor eine Prüfung auf einer bestimmten Annahme aufbaut, muss aber erkennbar sein, ob sie noch offen ist oder bereits belegt wurde. Ein geplanter Konfigurationsstand ist noch keine bestätigte Testvoraussetzung.
3. Benötigte Ergebnisse statt Dokumentmengen planen
Formulieren Sie für jede relevante Arbeit, welches Ergebnis sie liefern soll. „Berechtigungsnachweis“ bedeutet beispielsweise: Die vorgesehenen Rollen können erlaubte Handlungen ausführen; nicht berechtigte Handlungen werden unter den festgelegten Bedingungen verhindert. Ob der Beleg in einem eigenen Protokoll oder als Abschnitt einer größeren Prüfung entsteht, ist eine nachgelagerte Organisationsentscheidung.
Die folgende Struktur macht deutlich, was bereits bekannt ist und was noch erarbeitet werden muss. Verweisen Sie auf gelenkte Unterlagen, statt ihre Inhalte mehrfach zu kopieren. Ein kurzer Plan kann belastbar sein, wenn die Bezüge eindeutig sind. Ein umfangreicher Plan kann trotzdem Lücken haben, wenn er Ergebnisse nur mit „gemäß Standard“ bezeichnet, ohne den passenden Standard zu benennen.
| Planinhalt | Konkrete Aussage | Wozu sie gebraucht wird |
|---|---|---|
| Gebrauch und Stand | Betrachteter Prozess, Release und relevante Konfiguration | Der Leser erkennt, wofür die Planung gilt. |
| Grenzen und Abhängigkeiten | Einbezogene Schnittstellen sowie begründete Ausschlüsse | Außerhalb des Projekts liegende Voraussetzungen werden nicht übersehen. |
| Benötigte Ergebnisse | Zu belegende fachliche Aussagen und ihr Bezug zu Anforderungen/Risiken | Dokumentanzahl wird nicht mit Aussagekraft verwechselt. |
| Vorhandene Evidenz | Geeignete Belege mit Revision und Übernahmeentscheidung | Verfügbare Nachweise werden gezielt genutzt. |
| Ausführungsvoraussetzungen | Teststand, Daten, Rollen, Hilfsmittel und benötigte Entscheidungen | Prüfungen beginnen auf einer nachvollziehbaren Grundlage. |
| Zuständigkeit und Übergabe | Ergebnisverantwortlicher und zuständige Entscheidung mit Vertretung | Offene Punkte und Übergaben erhalten einen konkreten Adressaten. |
| Akzeptanz und Befunde | Bezug zu Kriterien, Umgang mit Abweichungen und erforderliche Auswertung | Die Bewertung wird vor der Durchführung vorbereitet. |
| Fortschreibung und Abschluss | Änderungsanlässe, Statusführung und geplante Zusammenführung der Ergebnisse | Planung bleibt mit dem tatsächlichen Projektstand verbunden. |
4. Vorhandene Nachweise mit ihrer Reichweite einplanen
Unterscheiden Sie neue Prüfungen, bereits geeignete Evidenz und noch zu bewertende Unterlagen. Ein vorhandener Hersteller- oder Partnerbericht kann eine eigene Anforderung einschließlich Ihrer Konfiguration bereits abdecken. Dann sollte der Plan dieses Ergebnis verwenden, statt aus Gewohnheit einen weiteren identischen Test vorzusehen. Voraussetzung ist eine nachvollziehbare Eignungsentscheidung.
Der Plan muss den vollständigen Übernahmebogen nicht wiederholen. Er kann auf ihn verweisen und dessen Ergebnis sowie verbleibende Bedingungen übernehmen. Bleibt etwa die lokale Druckerkonfiguration offen, ist genau diese Lücke einzuplanen. „Lieferantenpaket liegt vor“ beschreibt dagegen noch nicht, welche Aussage damit tatsächlich gestützt wird.
Planen Sie Rückfragen und notwendige Zugänge früh ein. Ein Bericht, der erst nach dem vorgesehenen Testbeginn geliefert wird, kann bis dahin keine gesicherte Grundlage bilden. Ebenso bleibt ein versprochener Herstellerbeleg zunächst eine Abhängigkeit. Die Planung darf das geplante Ergebnis nicht bereits als vorhanden ausweisen. Das verhindert, dass eine Terminübersicht unbemerkt einen Nachweisstatus vortäuscht.
5. Voraussetzungen für sinnvolle Prüfungen benennen
Legen Sie fest, was vor einer jeweiligen Prüfung bereitstehen muss. Dazu können bestätigte Anforderungen, ein identifizierter Teststand, passende Rollen, vorbereitete Datensätze und bewertete Hilfsmittel gehören. Nicht jede Prüfung benötigt dieselben Eingaben. Ein Dokumentenreview kann früher möglich sein als ein physischer Drucktest, der einen bestimmten Drucker, eine Vorlage und geeignetes Material voraussetzt.
Beschreiben Sie relevante Unterschiede zwischen Test- und späterer Betriebsumgebung. Entscheidend ist, ob sie die geplante Aussage beeinflussen. Ein Test mit einem anderen Druckertreiber kann beispielsweise nicht ohne weitere Begründung die vorgesehene Druckkombination vertreten. Ein bloßer Unterschied im Rechnernamen muss dagegen nicht dieselbe Bedeutung haben. Die Bewertung bleibt funktionsbezogen.
Definieren Sie außerdem den Ausgangszustand und das Vorgehen nach fehlgeschlagenen oder unterbrochenen Prüfungen. Müssen Druckaufträge entfernt, Testdaten zurückgesetzt oder Rollen wiederhergestellt werden? Solche Voraussetzungen gehören in die geeignete Testunterlage; der Plan stellt sicher, dass sie rechtzeitig erarbeitet werden. Eine Terminfreigabe allein ersetzt diese Vorbereitung nicht.
6. Kriterien und den Umgang mit Befunden vorsehen
Verweisen Sie auf die gültigen Akzeptanzkriterien und benennen Sie, wie Ergebnisse dagegen bewertet werden. Eine allgemeine Formulierung wie „alle Tests erfolgreich“ bleibt unvollständig, wenn offen ist, welche Tests zum Umfang gehören oder wie nicht ausführbare Fälle behandelt werden. Ein geplanter Test, eine Ausführung und eine fachliche Schlussfolgerung sind unterschiedliche Zustände.
Regeln Sie den Weg für Abweichungen, ohne im Plan schon jede spätere Lösung vorwegzunehmen. Wer erfasst den Befund, wer beurteilt seine Bedeutung und welche Nachweise werden nach einer Korrektur benötigt? Verweisen Sie dafür auf den vorhandenen geregelten Prozess. Der Plan soll sicherstellen, dass Ergebnisse nicht durch Weglassen eines fehlgeschlagenen Schritts scheinbar vollständig werden.
Eine Freigabe für einen nächsten Arbeitsschritt ist von der späteren Entscheidung über die produktive Nutzung zu unterscheiden. Annex 15 behandelt bedingte Übergänge zur nächsten Qualifizierungsstufe unter bestimmten Voraussetzungen. Diese Passage begründet keine pauschale Erlaubnis, ein beliebiges Computersystem mit offenen kritischen Fragen produktiv zu verwenden. Die abschließende Nutzungsentscheidung bleibt ein eigener Gegenstand.
7. Ein fiktives Etikettierrelease konkret planen
Das folgende Szenario ist ausdrücklich konstruiert: keine Kundenimplementierung, kein tatsächlicher Test und keine Aussage über ein bestimmtes Produkt. Ein Unternehmen führt im vorhandenen Etikettiersystem das Release L-2 ein. Es umfasst zwei überarbeitete Vorlagen im Satz V-7, eine geänderte Rollenzuordnung und den vorgesehenen Drucker D-1. Die Druckengine bleibt im Beispiel unverändert. Auftragsdaten werden manuell eingegeben; eine ERP-Anbindung ist nicht Bestandteil dieses Releases.
Der fachliche Bedarf ist bereits beschrieben: Nur die passende freigegebene Vorlage darf für den jeweiligen Auftrag verwendet werden. Artikelkennung, Charge und Verfalldatum müssen nach den festgelegten Regeln auf dem Etikett erscheinen. Ohne erforderliche Chargenangabe soll im angenommenen Ablauf kein Druckauftrag entstehen. Diese Regeln sind Voraussetzungen des Beispiels, keine pauschalen Vorgaben für jedes Etikettiersystem.
Ein bewerteter Herstellerbericht belegt im Szenario bestimmte unveränderte Funktionen der Druckengine. Er enthält jedoch nicht die neu eingeführten lokalen Vorlagen und den vorgesehenen Treiberstand. Der Plan übernimmt das begründet geeignete Ergebnis und plant die lokalen Nachweise ergänzend. Ein anderer Bericht könnte mehr abdecken; die Grenze ergibt sich hier aus dem ausdrücklich angenommenen Lieferumfang.
8. Aus dem Beispiel ausführbare Ergebnisaufträge machen
Die zweite Arbeitshilfe zeigt einen Ausschnitt des Beispielplans. Alle Kennungen und Dokumente sind erfunden. Die Tabelle behauptet keine erfolgreichen Tests, sondern ordnet geplante Ergebnisse ihren Voraussetzungen zu. Der Fachbereich klärt die erwarteten Etiketteninhalte, IT beziehungsweise Systemverantwortlicher bestätigt den technischen Stand, und die geregelte Bewertung der Nachweise erfolgt durch die intern befugten Personen.
Angenommen, der vorgesehene Treiber wird kurz vor dem Drucktest ersetzt: Der Ergebnisauftrag bleibt bestehen, seine Voraussetzung ist aber nicht mehr erfüllt. Zuerst wird die Änderung bewertet und der betrachtete Stand aktualisiert. Danach ist zu entscheiden, welche Belege noch passen und welche Prüfung auf dem neuen Stand erforderlich ist. Bereits geeignete unveränderte Nachweise werden dadurch nicht automatisch wertlos.
| Geplantes Ergebnis | Benötigte Voraussetzung | Vorgesehener Nachweis | Offener Entscheidungspunkt |
|---|---|---|---|
| Gebrauch und L-2-Stand sind eindeutig abgegrenzt. | Bestätigte Beschreibung von V-7, D-1 und Rollenänderung | Review der referenzierten Anforderungs- und Konfigurationsstände | Ungeklärte Vorlagenzuordnung vor darauf aufbauendem Test lösen. |
| Geeignete Engine-Nachweise werden genutzt. | Bewerteter Bericht für unveränderte relevante Engine-Funktionen | Referenz auf konkreten Übernahmeentscheid | Relevante Einschränkung oder Abweichung vor Nutzung beurteilen. |
| Lokale Etiketten enthalten die richtigen Auftragsdaten. | V-7, bestätigter Treiber, D-1 und definierte Sollbeispiele | Vergleich der vorgesehenen Inhalte mit tatsächlichem Druck und zugehöriger Aufzeichnung | Bedeutung eines Treiber- oder Materialwechsels vor Ausführung klären. |
| Berechtigungen und fehlende Pflichtangabe werden passend behandelt. | Festgelegte Rollen und vorbereitete gültige/ungültige Testdaten | Erlaubte und unerlaubte Handlung sowie Druckverhinderung gezielt prüfen | Erwartetes Verhalten muss vor Durchführung eindeutig sein. |
| Ergebnisse lassen sich für L-2 zusammenhängend bewerten. | Ausführungsbelege und zugeordnete Befunde liegen vor. | Geplante Zusammenführung gegen den festgelegten Umfang | Nicht abgedeckte Aussagen sichtbar halten und Maßnahmen entscheiden. |
9. Den Plan kontrolliert fortschreiben
Ein Plan ist keine nachträgliche Erfolgserzählung. Halten Sie fest, wann und warum sich Umfang, Voraussetzungen oder vorgesehene Nachweise ändern. Die aktuelle Fassung sollte den gültigen Arbeitsstand zeigen; die Änderungsgeschichte macht nachvollziehbar, welche Entscheidung zu welchem Zeitpunkt getroffen wurde. Das ist besonders wichtig, wenn Prüfungen bereits begonnen haben.
Verwechseln Sie einen Terminwechsel nicht automatisch mit einer fachlichen Änderung. Verschiebt sich nur die Verfügbarkeit eines Prüfers, kann eine organisatorische Anpassung genügen. Ändern sich dagegen Rollen, Datenfluss oder Akzeptanzkriterien, sind Auswirkungen auf Risiko und Nachweise zu bewerten. Die Dokumentation sollte diese unterschiedlichen Bedeutungen erkennen lassen.
Planen Sie von Anfang an, wie Ergebnisse zusammengeführt werden. Der spätere Bericht soll geplanten Umfang, tatsächliche Durchführung, Abweichungen und verbleibende Aussagen verständlich verbinden. Er muss nicht den Plan wortgleich wiederholen. Nach Abschluss werden relevante Voraussetzungen und offene Maßnahmen in den geregelten Betrieb beziehungsweise die zuständige Nutzungsentscheidung übergeben; der Plan ersetzt diese Entscheidungen nicht.
10. Mit den richtigen Eingaben starten
Für den Start brauchen Sie einen nachvollziehbaren Systemgebrauch, den betrachteten Änderungsumfang, eine erste Risikobewertung und eine Übersicht geeigneter vorhandener Unterlagen. Noch offene Punkte dürfen sichtbar bleiben, sofern klar ist, wann sie für weitere Arbeiten gebraucht werden. Prozessverantwortlicher, IT beziehungsweise Systemverantwortlicher und QA sollten die Planung gemeinsam auf fachliche und organisatorische Lücken prüfen.
Aufwand entsteht vor allem durch ungeklärte Prozessregeln, wechselnde Konfiguration, nicht verfügbare Testumgebungen und schwer zuzuordnende Fremdbelege. Beginnen Sie mit einem wichtigen Ergebnisauftrag und klären Sie seine Voraussetzungen vollständig. Dadurch wird früh sichtbar, ob Ihr Projekt eine kurze ergänzende Planung oder eine umfangreichere Koordination benötigt. Eine feste Seitenzahl oder pauschale Wochenangabe hilft dabei wenig.
- Gebrauch, Systemstand und betrachtete Änderung eindeutig benannt.
- Benötigte Ergebnisse mit Anforderungen und Risiken verbunden.
- Vorhandene Belege und ihre tatsächlich bewertete Reichweite referenziert.
- Ausführungsvoraussetzungen und offene Abhängigkeiten termingerecht zugeordnet.
- Akzeptanzkriterien, Befundweg und Entscheidungsbefugnisse bekannt.
- Änderungsanlässe und Fortschreibung geregelt.
- Zusammenführung der Ergebnisse und Übergabe an spätere Entscheidungen geplant.
Häufige Fragen zu Validierungsplan
Ist ein Validierungsplan dasselbe wie ein Validierungsmasterplan?
Nein. Ein VMP oder eine entsprechende Dokumentation beschreibt das standortbezogene Qualifizierungs- und Validierungsprogramm. Die hier gezeigte Planung verbindet dagegen einen bestimmten Systemgebrauch oder eine Änderung mit benötigten Ergebnissen. Beide können aufeinander verweisen. Entscheidend ist, dass der jeweilige Zweck verständlich erfüllt wird; ein weiterer Dokumenttitel allein schafft noch keinen zusätzlichen Nachweis.
Quellen: [3]
Braucht jedes kleine Softwareupdate einen eigenen umfangreichen Plan?
Die Planung sollte zum Umfang und zur Bedeutung der Änderung passen. Ein kleiner klar abgegrenzter Eingriff kann über vorhandene geregelte Unterlagen mit einer gezielten Ergänzung geplant werden. Prüfen Sie betroffene Anforderungen, Risiken, Voraussetzungen und Nachweise. Annex 15 macht aus seiner Aussage zu großen und komplexen Projekten keine universelle Forderung nach einem gleich langen separaten Plan für jedes Update.
Wie genau muss der Systemstand im Plan beschrieben sein?
So, dass die geplanten Aussagen und ihre Voraussetzungen zugeordnet werden können. Relevante Versionen, Konfigurationen, Schnittstellen und gegebenenfalls Geräte müssen erkennbar sein. Sie dürfen auf geeignete vorhandene Unterlagen verweisen. Ein Produktname allein reicht nicht, wenn unterschiedliche Vorlagen oder Rollen das Verhalten verändern. Nicht jede irrelevante technische Einzelheit muss dagegen im Plan wiederholt werden.
Müssen alle späteren Testschritte bereits im Plan stehen?
Nein. Der Plan beschreibt benötigte Ergebnisse, Vorgehen und Voraussetzungen. Ausführliche Eingaben, Schritte und Belege können in den zugehörigen Testunterlagen stehen. Erkennbar bleiben muss, welche Frage damit beantwortet werden soll und wann die Unterlagen bereitstehen müssen. Ein Verweis auf noch nicht vorhandene Tests ist zunächst eine geplante Aufgabe, kein schon erfüllter Nachweis.
Wie berücksichtigen wir ein Hersteller-Validierungspaket?
Übernehmen Sie das Ergebnis einer nachvollziehbaren Eignungsbewertung mit seiner Reichweite. Der Plan benennt, welche eigene Aussage dadurch gestützt wird und welche Bedingung oder Ergänzung noch offen ist. Hersteller- oder Partnerunterlagen können auch kundenspezifische Funktionen ausreichend abdecken. Eine pauschale Wiederholung ist deshalb ebenso wenig begründet wie eine automatische Komplettübernahme allein aufgrund des Paketnamens.
Dürfen wir beginnen, obwohl einzelne Voraussetzungen noch fehlen?
Unabhängige vorbereitende Arbeiten können möglich sein. Entscheidend ist, ob die fehlende Voraussetzung für den jeweiligen nächsten Schritt benötigt wird. Ein Review muss nicht zwangsläufig auf einen noch ausstehenden Drucker warten; ein aussagekräftiger Test der vorgesehenen Druckkombination dagegen schon. Halten Sie diese Abhängigkeit ausdrücklich fest. Ein allgemeiner Projektstart ersetzt keine Beurteilung der konkreten Ausführbarkeit.
Wer arbeitet an der Planung mit, und wer entscheidet?
Prozessverantwortliche erläutern den fachlichen Gebrauch, IT oder Systemverantwortliche die relevanten technischen Bedingungen und QA den geregelten Nachweisweg. Die Entscheidung erfolgt durch die intern dafür befugten Personen. In einem KMU können Rollen zusammenfallen, wenn Kompetenz und Befugnis klar bleiben. Eine feste Unterschriftenzahl oder universelle Organisationsstruktur folgt aus den Quellen nicht.
Was passiert, wenn sich die Konfiguration während der Prüfung ändert?
Bewerten Sie, welche geplanten oder bereits belegten Aussagen betroffen sind. Aktualisieren Sie den betrachteten Stand und die notwendigen Voraussetzungen, bevor darauf aufbauende Prüfungen fortgesetzt werden. Geeignete unveränderte Belege können weiterhin nutzbar sein. Der Plan sollte die Entscheidung nachvollziehbar referenzieren; er darf alte und neue Stände nicht unbemerkt zu einem scheinbar einheitlichen Ergebnis vermischen.
Ist ein genehmigter Plan bereits eine Freigabe für den produktiven Einsatz?
Nein. Er beschreibt, wie die benötigte Evidenz entstehen und bewertet werden soll. Erst tatsächliche Ergebnisse, ihre Bewertung und die weiteren relevanten Betriebsbedingungen tragen eine spätere Nutzungsentscheidung. Auch die in Annex 15 behandelte Freigabe zur nächsten Qualifizierungsstufe ist nicht automatisch eine allgemeine Produktivfreigabe. Halten Sie die verschiedenen Entscheidungen und ihren jeweiligen Umfang auseinander.
Welche Unterlagen sollten wir für den ersten Planungstermin mitbringen?
Hilfreich sind Gebrauch beziehungsweise URS, Änderungsbeschreibung, relevante Systemübersicht, Risikostand und vorhandene Lieferantenbelege. Ergänzen Sie bekannte Engpässe wie fehlende Testdaten, Geräte oder Ansprechpartner. Der Aufwand hängt vor allem von diesen offenen Abhängigkeiten und der Komplexität des vorgesehenen Ergebnisses ab. Eine erste vollständig durchgearbeitete Ergebniszeile zeigt den Klärungsbedarf besser als eine Schätzung anhand der Dokumentseiten.
Quellen & fachlicher Stand
Quellen am 6. Oktober 2026 geöffnet. Regulatorischer Beispielrahmen ist Humanarzneimittel-GMP. Annex 15 wird in seinem Qualifizierungs- und Validierungskontext verwendet, ohne alle Anlagenprüfungen auf Software zu übertragen. Tabellen, Checkliste und Etikettierrelease sind eigene illustrative Arbeitshilfen; sie beschreiben keine ausgeführten Tests oder Kundenimplementierung.
- Europäische Kommission: EudraLex Volume 4, aktuelle Humanarzneimittel-GMP-Übersicht
- EU-GMP Annex 11: Computerised Systems, Revision Januar 2011
- EU-GMP Annex 15: Qualification and Validation, Revision 2015
- EU-GMP Kapitel 4: Documentation, Revision Januar 2011
- ICH Q9(R1): Quality Risk Management, europäische Step-5-Fassung 2023
Zuletzt fachlich geprüft am 06.10.2026.
Daniel Herrmann Consulting
Aus offenen Aufgaben eine ausführbare Validierungsplanung machen
Daniel Herrmann Consulting unterstützt Sie dabei, benötigte Ergebnisse abzugrenzen, vorhandene Evidenz einzuplanen und Voraussetzungen für aussagekräftige Prüfungen rechtzeitig zu klären.
- IT-GxP-Audit →
Vorhandene Planung auf fehlende Ergebnisse, Abhängigkeiten und unklare Nachweisstände prüfen.
- IT-GxP-Consulting →
Systembezogene Ergebnisplanung und geregelte Fortschreibung gemeinsam ausarbeiten.