IQ/OQ/UAT für konfigurierbare Software

Executive summary

Viele regulierte Organisationen beschreiben ihre Validierungsprogramme als „aufwändig“, „langsam“ und „teuer“, fühlen sich aber dennoch während Audits unsicher. Diese Spannung ist kein Widerspruch, sondern eine häufige Folge davon, dass Validierung zu einer Leistungsübung anstatt zu einem Nachweissystem wird. Teams erstellen große Mengen an Dokumenten und Testskripten, doch die Nachweise lassen sich nicht eindeutig mit dem beabsichtigten Verwendungszweck , dem tatsächlichen operationellen Risiko oder den Kontrollflächen verknüpfen, die für die Aufsichtsbehörden relevant sind. Unter Druck – sei es bei einem Audit, einer Abweichung oder Bedenken hinsichtlich der Datenintegrität – reduzieren Validierungsergebnisse die Unklarheit nicht, sondern verstärken sie mitunter sogar.

Dieses Whitepaper stellt einen praxisorientierten, herstellerneutralen Ansatz zur Validierung von Computersystemen (CSV) für konfigurierbare Software vor, einschließlich SaaS-Software und On-Premise-Software. Der Ansatz folgt einer einfachen Regel: Validierung der Kontrollschnittstellen, die Schäden verhindern und die Datenintegrität schützen , und Vermeidung von Tests, die lediglich der „Hautprüfung“ dienen. Rahmenwerke wie GAMP 5 sind weiterhin nützlich, jedoch nur, wenn sie mit klarer Definition der Systemkategorie, der Verantwortlichkeiten des Anbieters und des risikobasierten Umfangs angewendet werden.

Das Dokument orientiert sich am IQ/OQ/UAT-Lebenszyklus – IQ , OQ und UAT – und legt den Schwerpunkt auf die vorgelagerten Arbeiten, die bestimmen, ob diese Phasen glaubwürdige Nachweise liefern: Definition des Verwendungszwecks, Einhaltung der Anforderungen, Risikobewertung und eine Rückverfolgbarkeitsstruktur, die Tests mit Kontrollen und Kontrollen mit Risiken verknüpft. Wo elektronische Aufzeichnungen und Signaturen relevant sind, unterstützt dasselbe Modell nachvollziehbare Erwartungen gemäß 21 CFR Part 11 und Annex 11 , die durch Tests der Bedienoberfläche anstelle von Funktionschecklisten umgesetzt werden.

Das Ziel ist praxisorientiert: die Zeit bis zur validierten Nutzung verkürzen, ohne die Kontrolle zu schwächen. Dies wird erreicht, indem der Fokus auf das Wesentliche beschränkt, die Abgrenzung zwischen Lieferant und Kunde gestärkt, robuste Testnachweise erstellt und ein Änderungsmanagement-Zyklus implementiert wird, der den validierten Zustand stets aktuell hält.

Abstract

Die Validierung von Computersystemen in regulierten Umgebungen wird häufig anhand des Dokumentationsumfangs und nicht anhand der Qualität der Nachweise betrachtet. Dies führt zu langwierigen Projekten, die bei Audits und Untersuchungen weiterhin Unsicherheiten hinterlassen. Dieser Beitrag schlägt ein praktisches, risikobasiertes Betriebsmodell zur Validierung konfigurierbarer Software – bereitgestellt als SaaS oder On-Premise – vor, das auf wenigen grundlegenden Elementen basiert: Verwendungszweck, Risiko, Kontrollschnittstellen und durch Rückverfolgbarkeit verknüpfte Nachweispakete.

Das Modell strukturiert die Validierungsarbeit anhand von IQ/OQ/UAT und legt dabei Wert auf Lieferanten-/Standortgrenzen, Kontrollflächenprüfung (Identität, Zugriff, Audit-Trails, elektronische Signaturen, Datenaufbewahrung, Ausnahmebehandlung) sowie Änderungskontrollverfahren, die den validierten Zustand langfristig erhalten. Der Ansatz entspricht den Erwartungen, die üblicherweise gemäß 21 CFR Part 11 und Annex 11 für elektronische Datensätze diskutiert werden, und verwendet risikobasierte CSV-Methoden, die mit den GAMP-5-Prinzipien übereinstimmen.

1) Was „Validierung“ bedeutet (und was sie nicht ist)

Validierung wird häufig als „Funktionsnachweis des Systems“ beschrieben, was zwar richtig, aber unvollständig ist. In regulierten Bereichen bedeutet Validierung den Nachweis, dass ein computergestütztes System für seinen vorgesehenen Zweck geeignet ist und dass seine Nutzung weder die Produktqualität, die Patientensicherheit (sofern zutreffend) noch die Integrität der Datensätze beeinträchtigt. Das praktische Ergebnis ist kein Ordner, sondern ein nachvollziehbarer Kontrollzustand, der im Rahmen einer Prüfung belegt werden kann.

Validierung ist nicht dasselbe wie das Testen jeder einzelnen Funktion. Sie ist auch nicht dasselbe wie das Vertrauen auf Zusicherungen von Anbietern. Es handelt sich um eine strukturierte Argumentation, die durch Belege gestützt wird und typischerweise in Form von Artefakten wie einem Validierungs-Masterplan (VMP) , einer Risikoanalyse, Anforderungen, Rückverfolgbarkeit und Testergebnissen dokumentiert ist. Die wichtigste Eigenschaft dieser Artefakte ist ihre Verknüpfung : Jeder Test dient dem Nachweis der Beherrschung eines mit der beabsichtigten Nutzung verbundenen Risikos.

Wenn elektronische Aufzeichnungen und Signaturen relevant sind, werden Erwartungen wie die Zuordnung von Aktionen und die lückenlose Nachweisbarkeit von Änderungen häufig in 21 CFR Part 11 formuliert . Im europäischen Kontext werden ähnliche Erwartungen oft in Annex 11 festgelegt . In beiden Fällen ist der praktische Test derselbe: Kann die Organisation nachweisen, dass die Aufzeichnung vertrauenswürdig ist, ohne auf narrative Erläuterungen angewiesen zu sein?

2) Warum Bestätigung zum Theater wird

Validierung verkommt zur reinen „Inszenierung“, wenn Teams sichtbare Aktivitäten statt revisionssicherer Nachweise priorisieren. Dies ist kein moralisches Versagen, sondern eine vorhersehbare Reaktion auf unklare Erwartungen, die Angst vor einer Offenlegung im Rahmen einer Prüfung und den Wunsch, Diskussionen über den Umfang zu vermeiden. In der Praxis äußert sich diese Inszenierung in umfangreichen Testinventaren ohne Bezug zum Risiko, generischen Anforderungsdokumenten und Rückverfolgbarkeitsmatrizen, die lediglich Vollständigkeit vortäuschen sollen.

Häufige Fehlermuster sind branchen- und modellübergreifend konsistent:

• Umfangsausweitung: „Alles testen“ ersetzt eine risikobasierte Argumentation und führt zu langen Bearbeitungszeiten, ohne das Vertrauen zu stärken.
• Funktionsorientierte Skripte: Die Tests orientieren sich eher an Bildschirmen und Menüs als an den vorgesehenen Nutzungs- und Kontrollzielen.
• Schwache Lieferanten-/Standortgrenzen: Die Verantwortlichkeiten sind unklar, was zu doppelten Tests oder, schlimmer noch, zu ungetesteten Annahmen führt.
• Unzureichende Anzahl negativer Tests: Die Programme überprüfen zwar „normale Abläufe“, beweisen aber nicht, dass verbotene Handlungen verhindert werden.
• Änderungssteuerungsdrift: Der validierte Zustand wird einmalig erreicht, geht dann aber durch unkontrollierte Konfigurationen und Releases verloren.
• Integrationslücken: Schnittstellen werden als „IT-Rohrleitungen“ behandelt, obwohl bei Audits häufig Integritätsprobleme an den Schnittstellen festgestellt werden.
• Rekordverdächtiges Vertrauensdefizit: Teams können das Verhalten von Audit-Trails, kontrollierte Bearbeitungen, Aufbewahrung oder die Durchsetzung der Identität nicht klar erklären.

Die Lösung besteht nicht in mehr Dokumentation. Die Lösung besteht darin, die Validierung als eine kleine Anzahl miteinander verknüpfter Aussagen zu strukturieren – Verwendungszweck, Risiko, Kontrollen, Nachweise – und die Anstrengungen auf die Bereiche zu konzentrieren, in denen Fehler zu realem Schaden oder regulatorischen Risiken führen.

3) Das Validierungsmodell: Verwendungszweck, Risiko, Nachweise

Ein Validierungsprogramm ist dann am effektivsten, wenn es eine einfache Argumentstruktur verwendet, die sich auf Nachfrage schnell erläutern lässt. Das hier verwendete Modell umfasst vier Grundelemente, die sich nahtlos in die tägliche Arbeit und Validierungsartefakte übertragen lassen: Verwendungszweck , Risiko , Kontrollfläche und Nachweispaket.

Dieses Modell unterstützt naturgemäß risikobasierte CSV-Ansätze. Es begrenzt zudem Diskussionen: Anstatt darüber zu streiten, ob „jeder Bildschirm“ getestet werden muss, konzentrieren sich die Teams darauf, ob die Kontrollmechanismen, die den bestimmungsgemäßen Gebrauch schützen, nachweislich zuverlässig sind, auch bei Ausnahmefällen und Änderungen.

4) Systemgrenzen: Lieferant vs. Standort, konfigurierbar vs. kundenspezifisch

Unklare Zuständigkeitsgrenzen sind einer der häufigsten Gründe für einen übermäßigen Validierungsaufwand. Sind die Verantwortlichkeiten nicht eindeutig definiert, kommt es standardmäßig zu Doppelarbeit: Der Standort testet, was der Lieferant bereits zusichert, und der Lieferant geht davon aus, dass der Standort das übernimmt, was er tatsächlich nicht kontrollieren kann. Ein nachvollziehbares Validierungsprogramm definiert explizit: (1) was der Lieferant als kontrolliertes Produkt bereitstellt, (2) was der Standort konfiguriert, (3) wie der Standort prozedural vorgeht und (4) was gemeinsam genutzt wird.

Konfigurierbare Software verändert die Validierungspraxis. Konfiguration bedeutet typischerweise, dass vordefinierte Funktionen über Einstellungen, Rollen und Workflows aktiviert und eingeschränkt werden, anstatt durch neuen Code erstellt zu werden. Dies reduziert im Allgemeinen die Softwarekomplexität, kann aber die operative Komplexität erhöhen, wenn die Governance unzureichend ist. Die Validierungsfrage lautet daher: Sind Konfigurationen im Rahmen der vorgesehenen Nutzung kontrolliert, nachvollziehbar und getestet?

Klarheit in diesem Bereich verkürzt die Validierungszeit unmittelbar. Sie verringert auch die Anfälligkeit für Audits: Wenn Prüfer fragen „Wer kontrolliert das?“, kann das Unternehmen eindeutig antworten und nachweisen, dass diese Kontrollen funktionieren.

5) Zu prüfende Steuerflächen

Die Validierungsbemühungen sollten sich auf die Kontrollmechanismen konzentrieren, die Schaden verhindern und die Integrität der regulierten Datensätze schützen. In der Praxis handelt es sich dabei nicht um „Funktionen“, sondern um Systemverhalten, das Identität, Status, Autorisierung und nachvollziehbare Änderungen gewährleistet. Wo elektronische Datensätze verwendet werden, werden die Erwartungen gemäß Teil 11 und Anhang 11 häufig an diesen Stellen umgesetzt, einschließlich sicherer, mit Zeitstempel versehener Prüfprotokolle und kontrollierter Bedeutung elektronischer Signaturen.

Beachten Sie, was fehlt: Tests, die lediglich bestätigen, dass ein Bildschirm geladen wird oder ein Benutzer durch ein Menü navigieren kann. Solche Tests mögen während Schulungen hilfreich sein, stärken aber selten ein Validierungsargument. Validierungsnachweise sollten dort am stärksten sein, wo ein Fehler ein reales Risiko darstellt und wo sich Prüfer bei der Überprüfung der Vertrauenswürdigkeit von Aufzeichnungen konzentrieren.

6) Anforderungen, Rückverfolgbarkeit und Testdesign

Die Qualität der Anforderungen bestimmt die Qualität der Validierung. Sind die Anforderungen generisch, sind auch die Tests generisch; sind die Tests generisch, hält die Validierung einer kritischen Prüfung nicht stand. Bei konfigurierbarer Software sollten die Anforderungen so formuliert sein, dass sie das kontrollierte Verhalten beschreiben und nicht nur Funktionen wiederholen („Das System soll“).

Eine praktische Struktur besteht darin, Folgendes zu trennen:

• Verwendungszweckangaben: Welche regulierten Tätigkeiten werden unterstützt und auf welche Aufzeichnungen wird zurückgegriffen?
• Kritische Anforderungen: Erwartungen an die Kontrolloberfläche (Identität, Zugriff, Prüfprotokolle, Bedeutung der elektronischen Signatur, Gültigkeit).
• Konfigurationsanforderungen: Standortspezifische Arbeitsabläufe, Rollen und Regeln (mit Versionierung und Genehmigungen).
• Schnittstellenanforderungen: Welche Daten überschreiten Grenzen, Latenztoleranz, Fehlerbehandlung und Datenabgleich?

Rückverfolgbarkeit ist das Bindeglied. Sie sollte als lebendige Struktur gepflegt werden, die Verwendungszweck, Risiko, Anforderung, Test und Nachweis miteinander verknüpft. Bei korrekter Umsetzung verhindert sie sowohl übermäßiges als auch unzureichendes Testen: Jeder Test hat seinen Sinn, und jede kritische Anforderung wird nachweislich verifiziert.

Bei konfigurierbaren Systemen sollten Konfigurationselemente als kontrollierte Objekte behandelt werden. Jede Änderung eines Workflows, einer Rolle oder einer Regel sollte einen kontrollierten Änderungsdatensatz mit Folgenabschätzung und entsprechenden erneuten Tests generieren. Ohne diese Vorgehensweise wird der validierte Zustand zu einer Momentaufnahme und nicht zu einer dauerhaften Betriebsbereitschaft.

7) IQ für moderne Bereitstellungen (SaaS und On-Premise)

Ziel der Identitätsprüfung (IQ) ist der Nachweis, dass das System gemäß den definierten Anforderungen installiert (oder bereitgestellt) wurde und die Umgebung für den vorgesehenen Zweck geeignet ist. Bei älteren On-Premise-Modellen lag der Fokus der IQ typischerweise auf Serverspezifikationen, Betriebssystemeinstellungen, Datenbankversionen und installierten Komponenten. Bei SaaS-Modellen verlagert sich der Schwerpunkt der IQ häufig auf dokumentierte Kontrollen des Anbieters und Nachweise für die Bereitstellung, das Identitätsmanagement und die Anbindung an die Standortumgebung.

Ein praxisorientierter Ansatz zur Integrationsqualitätsprüfung (IQ) für moderne Implementierungen konzentriert sich auf die Aspekte, die der Standort tatsächlich überprüfen und kontrollieren kann. Die IQ-Nachweise sollten glaubwürdig , aber nicht vollständig sein. Bei SaaS umfasst die IQ üblicherweise die Prüfung der Lieferantendokumentation und die Überprüfung der vom Kunden gesteuerten Elemente vor Ort: Benutzerbereitstellung, Rollenkonfiguration, Konnektivität, Endpunktkonfiguration, Zeitsynchronisierung und alle lokalen Komponenten wie Etikettendrucker, Scanner oder Waagenschnittstellen (siehe gegebenenfalls die Abschnitte „Integration von Waagen“ und „Integration von Etikettendruckern“ ).

Die interne Qualitätssicherung (IQ) sollte nicht versuchen, die internen Infrastrukturkontrollen des Lieferanten durch Vor-Ort-Tests nachzuweisen. Stattdessen sollte der Standort sicherstellen, dass er die Nachweise des Lieferanten ordnungsgemäß geprüft (Lieferantenqualifizierung) und die vom Kunden gesteuerte Konfiguration und Abhängigkeiten verifiziert hat. Diese klare Abgrenzung spart Zeit und verbessert die Rechtssicherheit.

8) OQ: Bedienelemente prüfen, nicht Funktionen anklicken

OQ (Open Quality) ist der Punkt, an dem viele Validierungsprogramme zwar ein hohes Datenvolumen aufweisen, aber das Vertrauen in die Validierung nicht stärken. Die effektivsten OQ-Protokolle orientieren sich an Kontrollzielen und kritischen Verhaltensweisen: Wer darf was tun, was wird verhindert, was wird protokolliert und wie werden Ausnahmen behandelt? Der Schwerpunkt sollte auf Negativtests liegen: Versuche, verbotene Aktionen auszuführen, geschützte Felder zu bearbeiten und Genehmigungs- oder Sperrlogik zu umgehen.

OQ mit Fokus auf Bedienoberflächen umfasst typischerweise:

• Rollenbasierter Zugriff: Überprüfen Sie gegebenenfalls die Rollen mit den geringsten Berechtigungen und die Trennungsregeln.
• Verhalten des Prüfprotokolls: Überprüfen, ob eine zuordenbare Prüfhistorie für geschützte Datensatzfelder erstellt wurde.
• Elektronische Signaturen (sofern verwendet): Überprüfung der Bedeutung, der Verbindlichkeit und der Änderungen der Signatur nach der Unterzeichnung.
• Halte-/Freigabe- und Statuslogik: Überprüfen Sie, ob verbotene Aktionen aufgrund des Status blockiert sind.
• Ausnahmeerfassung: Prüfen Sie, ob Abweichungen/Überschreibungen mit Begründung und Genehmigung erfasst werden.
• Aufbewahrung und Export: Überprüfung des Abrufs vollständiger Datensätze und Exporte ohne Kontextverlust.

Ein praktischer OQ (Operatives Qualitätsquidding) ist relativ kompakt, aber aussagekräftig. Er zeigt, dass das System relevante Verhaltensweisen verhindert und protokolliert, auch unter widrigen Bedingungen. Enthält der OQ keine Negativ- und Ausnahmetests, bietet er selten ein hohes Maß an Sicherheit für die Auditierung.

9) Benutzerakzeptanztest (UAT): Nachweis der Funktionsfähigkeit des Prozesses im realen Einsatz

Die Benutzerakzeptanztests (UAT) sind der Punkt, an dem die praktische Realität auf die Validierungsargumente trifft. Ein häufiger Fehler ist es, UAT als Schulung zu betrachten. Schulungen sind wichtig, aber UAT liefert den Nachweis: Sie zeigt, dass echte Benutzer den vorgesehenen Prozess unter realistischen Bedingungen ausführen können, während die Bedienelemente wie erwartet funktionieren.

Hochwertige UAT-Szenarien sind durchgängig und umfassen normale Abläufe, erwartete Schwankungen sowie mindestens einige plausible Ausnahmen. Sie sollten außerdem zeigen, dass die Verfahrenskontrollen des Unternehmens mit dem Systemverhalten übereinstimmen. Wenn der Prozess auf „systemfremde“ Workarounds angewiesen ist, um Aufgaben zu erledigen, deutet dies darauf hin, dass die beabsichtigte Nutzung nicht wie definiert erreicht wird.

Wenn der Benutzerakzeptanztest (UAT) auf diese Weise strukturiert ist, wird er zu einem wertvollen Validierungsartefakt: Er zeigt, dass das System nicht nur technisch korrekt, sondern auch betrieblich geeignet ist und dass die während des realen Betriebs erstellten Aufzeichnungen vertrauenswürdig bleiben.

10) Prüfprotokolle, Datenintegrität und Vertrauen in Datensätze

Das Vertrauen in die Aufzeichnungen ist bei Prüfungsfragen oft ausschlaggebend. Kann ein Unternehmen nicht klar darlegen, wie Aufzeichnungen vor unberechtigten Änderungen geschützt werden oder wie Änderungen transparent erfolgen, steigt die Aufmerksamkeit des Prüfers schnell. Der praktische Ankerpunkt ist die Datenintegrität , die üblicherweise durch Prinzipien wie ALCOA+ zum Ausdruck gebracht wird.

Im Kontext der Validierung bedeutet dies den Nachweis, dass Datensätze nachvollziehbar, zeitnah erstellt und mit einer zuverlässigen Änderungshistorie archiviert sind. Der Prüfpfad ist nicht einfach nur vorhanden; sein Verhalten muss verstanden und dargestellt werden: Welche Felder werden geprüft, was löst einen Prüfeintrag aus, wie werden Änderungsgründe erfasst, welche Genehmigungen sind erforderlich und was wird verhindert (z. B. das Löschen regulierter Datensätze oder Änderungen ohne nachvollziehbare Gründe)?

Eine vertretbare Haltung umfasst Tests und Verfahrenskontrollen für:

• Definition des geschützten Feldes: welche Bereiche und Ereignisse als reguliert oder kritisch gelten.
• Regeln zur Begründung von Änderungen: wann eine Begründung zwingend erforderlich ist und wie diese überprüft wird.
• Bedeutung der Unterschrift: wie elektronische Signaturen an den Datensatzstatus gebunden werden und wie Änderungen nach der Signatur verarbeitet werden.
• Speicherung und Abruf: wie lange Datensätze gespeichert werden und wie vollständig der Kontext bei Exporten erhalten bleibt.

Dies sind keine theoretischen Bedenken. Genau darauf konzentrieren sich Audits in der Regel, wenn elektronische Aufzeichnungen Freigabeentscheidungen, Untersuchungen, Abweichungen oder kundenorientierte Nachweise unterstützen.

11) Integration und Schnittstellen: Wo Audits Lücken aufdecken

Integrationen werden oft als technische Projekte behandelt, Audits betrachten sie jedoch als Beweisgrenzen. Wenn Identität, Status und Zeitstempel systemübergreifend übertragen werden, können selbst kleine Unklarheiten erhebliche Sicherheitslücken verursachen. Ein typisches Beispiel ist ein widersprüchlicher Status zwischen Systemen (z. B. „freigegeben“ in einem System, während ein Datensatz in einem anderen System tatsächlich gespeichert ist) oder Datensätze, die während der Übertragung ihren Kontext verlieren.

Eine vertretbare Validierungsstrategie für die Integration umfasst:

• Schnittstellenverträge: klare Definitionen von Feldern, Bedeutungen und Ereigniszeitpunkten.
• Fehlerbehandlung: Was passiert, wenn Nachrichten fehlschlagen, verspätet eintreffen oder doppelt ankommen (siehe Message-Broker-Architektur sofern zutreffend).
• Versöhnung: wie Quell- und Zielsysteme verglichen und Unterschiede behoben werden (siehe Synchronisierung der Stammdaten).
• Überprüfbarkeit: Nachvollziehbare Verknüpfung zwischen auslösendem Ereignis und empfangendem Datensatz, einschließlich der Information, wer/was/wann.

Integrationstests sollten sich auf kritische Schnittstellen konzentrieren – solche, die Identität, Status, Genehmigungen und die Vollständigkeit regulierter Datensätze beeinflussen – und nicht auf „alles, was integriert werden kann“. Ziel ist es, eine einheitliche Datenbasis über den gesamten Prozess hinweg zu gewährleisten.

12) Validierungs-KPIs für den Gesundheitszustand und Betriebsrhythmus

Validierung ist kein einmaliger Meilenstein, sondern ein kontinuierlicher Prozess. Programme verschlechtern sich, wenn Veränderungen die Steuerung überfordern, Konfigurationen ohne Folgenabschätzung geändert werden oder Nachweise nicht schnell genug verfügbar sind. Kennzahlen helfen, Abweichungen frühzeitig zu erkennen, bevor die Organisation im Rahmen eines Audits zu einer grundlegenden Umstrukturierung gezwungen wird.

Ein einfacher Ablauf hat sich bewährt: monatliche Überprüfung der Änderungskontroll- und Audit-Trail-Signale, vierteljährliche Übungen zur Beweissicherung und regelmäßige Überprüfung der Lieferantenfreigaben und der Standortkonfigurations-Baselines. Ziel ist es, den validierten Status aktuell zu halten und nicht um seiner selbst willen Aktivitäten zu generieren.

13) Branchenhinweise: Was ändert sich je nach Branche?

Das Validierungsmodell ist branchenübergreifend stabil. Was sich ändert, ist die Risikoausrichtung: Welche Datensätze sind am kritischsten, welche Prozesspunkte bergen die größten Risiken bei Kontrollversagen und welche Integrationsgrenzen sind am stärksten gefährdet? Die folgende Tabelle bietet einen praktischen Überblick; sie ist nicht vollständig.

Unabhängig vom Sektor legt ein zuverlässiges Programm Wert auf dieselben Grundprinzipien: Vertrauen in die Aufzeichnungen, Verhinderung verbotener Handlungen, Beweissicherung und nachhaltige Kontrolle durch gesteuerte Veränderungen.

14) Umsetzungsfahrplan

Der schnellste Weg zu einem langsamen Validierungsprogramm führt über einen umfangreichen Testbestand. Ein besser abgesichertes Programm hingegen beginnt mit der Definition von Verwendungszweck und Risiko, regelt die Kontrollmechanismen und erstellt anschließend kompakte, aussagekräftige Nachweispakete. Der folgende Fahrplan zielt darauf ab, die Zykluszeit zu verkürzen, ohne die Kontrollmöglichkeiten zu beeinträchtigen.

Schlussbemerkung

Eine tragfähige Validierungsstrategie definiert sich nicht durch die Größe der Dokumentation. Sie definiert sich vielmehr dadurch, ob die Organisation schnell und konsistent nachweisen kann, dass die beabsichtigte Nutzung kontrolliert wird, kritische Risiken durch Systemverhalten und -verfahren minimiert werden und elektronische Aufzeichnungen ohne narrative Rekonstruktion vertrauenswürdig sind. In der Praxis wird dies durch die Validierung von Kontrollflächen, die Sicherstellung der Rückverfolgbarkeit und ein diszipliniertes Änderungsmanagement erreicht, das den validierten Zustand langfristig erhält.

Leser, die weiterführende Definitionen wünschen, können die in diesem Dokument verlinkten Glossarseiten konsultieren. Dort werden unter anderem Begriffe wie CSV , GAMP 5 , IQ , OQ , UAT , Audit-Trail und Datenintegrität erläutert . Diese Verweise sind optional; das oben beschriebene Betriebsmodell ist bewusst herstellerneutral.