CSA: risikobasierte Validierung statt CSV-Routine
Computer Software Assurance (CSA) ist kein Ersatzetikett für weniger Validierung und keine Umbenennung der CSV-Routine. Die FDA-Guidance, 2022 als Draft gestartet und seit September 2025 final, beschreibt einen risikobasierten Assurance-Ansatz für Production und Quality Management System Software im Medical-Device-Kontext. Für Pharma-Hersteller ist CSA vor allem methodisch relevant: Testtiefe, Anbieter-Evidenz, Automatisierung und Periodic Evaluation müssen am intended use und am GxP-Risiko ausgerichtet werden.
Computer Software Assurance (CSA) ist ein risikobasierter Ansatz, um Vertrauen in die Eignung von Software für ihren vorgesehenen Einsatz aufzubauen und über den Lebenszyklus zu erhalten. Für Pharma-Hersteller ist CSA vor allem eine Korrektur an überformalisierten Validierungsprogrammen: Nicht jede Funktion benötigt dieselbe Testtiefe, aber jede reduzierte Testtiefe benötigt eine dokumentierte Begründung.
Der Begriff stammt aus der FDA-Guidance Computer Software Assurance for Production and Quality Management System Software, 2022 als Draft veröffentlicht, am 24.09.2025 finalisiert und am 03.02.2026 an die neue Quality Management System Regulation (QMSR) angepasst. Die Guidance bezieht sich auf Software im Umfeld von Medical-Device-Produktion und Qualitätsmanagementsystemen. Im Pharma-GMP-Kontext entsteht die Relevanz indirekt: GAMP 5 Second Edition greift dieselbe risikobasierte Logik auf, Annex 11 verlangt seit Revision 1 ein begründetes Risikomanagement über den Lebenszyklus, und ICH Q9(R1) liefert den allgemeinen Rahmen für Quality Risk Management.
Einordnung der FDA-Guidance
Die FDA-Guidance beschreibt CSA als Ansatz für Computer und automatisierte Datenverarbeitungssysteme, die in der Produktion oder im Qualitätsmanagementsystem eingesetzt werden. Ziel ist nicht die Abschaffung von Computer System Validation (CSV), sondern eine andere Verteilung des Nachweisaufwands. Kritische Funktionen erhalten mehr Evidenz, unterstützende oder niedrig riskante Funktionen erhalten weniger formale, aber weiterhin nachvollziehbare Evidenz.
Der Scope ist wichtig. Die Guidance enthält, wie jede FDA-Guidance, nicht bindende Empfehlungen, und sie adressiert nicht allgemein jede Pharma-Software. Die Fassung vom 03.02.2026 gleicht sie an die QMSR an, die neue 21 CFR Part 820 mit ISO-13485-Inkorporation, anwendbar seit 02.02.2026. Relevant ist die Guidance, weil sie mehrere Punkte klar benennt, die auch in Pharma-IT-Projekten die Validierungsqualität bestimmen: intended use, funktionsbezogene Risikobewertung, Nutzung von Anbieter-Evidenz, angemessene Testmethoden und objektive Nachweise.
GAMP 5 Second Edition ist dabei kein EU-Rechtsakt. Der ISPE-Leitfaden prägt aber die Validierungspraxis in vielen Pharma-Unternehmen und macht risikobasierte, lebenszyklusorientierte Validierung auditfähig erklärbar. Annex 11 bleibt die regulatorische Basis im EU-GMP-Kontext. Dort sind Risikomanagement, Lieferantenbewertung, Validierung, Änderungskontrolle und Periodic Evaluation bereits angelegt.
CSV und CSA im Vergleich
Der Begriff Computer System Validation (CSV) beschreibt den dokumentierten Nachweis, dass ein computergestütztes System für seinen vorgesehenen regulierten Einsatz geeignet ist. In gewachsenen Validierungsprogrammen wurde daraus ein sehr formales V-Modell mit umfangreicher Skripttiefe, unabhängig davon, ob eine Funktion direkt produktqualitäts- oder patientensicherheitsrelevant war.
CSA setzt an diesem Punkt an. Der Nachweis soll weiterhin objektiv und prüfbar sein. Die Testtiefe wird jedoch am Risiko der Funktion ausgerichtet, nicht an einer pauschalen Erwartung gleicher Dokumentation für alle Anforderungen.
Der Unterschied liegt in drei Arbeitsweisen:
- Funktion statt Gesamtsystem. Ein eQMS, LIMS oder MES enthält Funktionen mit unterschiedlichem Risiko. Eine Audit-Trail-Funktion trägt ein anderes Risiko als eine reine Filteransicht.
- Evidenz statt Dokumentationsmasse. Ein Testprotokoll ist nur ein Evidenztyp. Anbieterunterlagen, automatisierte Testergebnisse, Konfigurationsreviews, Exploratory Testing und Monitoring können ebenfalls Evidenz liefern.
- Lebenszyklus statt Initialvalidierung. Der validierte Zustand endet nicht mit dem Validierungsbericht. Releases, Konfigurationsänderungen, Access Reviews, Periodic Evaluation und Abweichungen halten das System unter Kontrolle.
Das V-Modell bleibt verwendbar. Es verliert nur den Status einer mechanischen Standardantwort. Ein hochkritisches System kann weiterhin robuste, skriptierte Tests benötigen. Ein niedrig riskanter Unterstützungsprozess kann mit weniger formaler Testtiefe auskommen, wenn die Entscheidung begründet ist.
Sechs Verfahren für die Umstellung
CSA wird nicht über ein neues Schlagwort eingeführt. Die Methodik muss in den bestehenden Verfahren erkennbar werden.
Validierungsstrategie. Die Strategie beschreibt, wann das Unternehmen risikobasierte Testtiefe nutzt, welche Quellen anerkannt werden und wie Abweichungen vom Standardmodell begründet werden. Sie muss CSA nicht als Default erzwingen. Tragfähiger ist eine Regel: Der intended use und das Risiko der Funktion bestimmen die Evidenztiefe.
Risikobewertung. Die Bewertung darf nicht nur auf Systemebene stehen bleiben. Ein Systeminventar und eine GxP-Impact-Bewertung bleiben wichtig, aber die eigentliche Testentscheidung entsteht auf Funktions- oder Prozessschrittebene. Patientensicherheit, Produktqualität, Datenintegrität und regulatorische Aufzeichnungspflichten gehören in die Bewertung.
Teststrategie. Die Teststrategie ordnet Testmethoden dem Risiko zu. Robuste skriptierte Tests eignen sich für kritische Funktionen, etwa elektronische Signatur, Audit Trail, Chargenfreigabe oder automatisierte Qualitätsentscheidung. Begrenzte skriptierte Tests, unscripted testing, explorative Prüfung oder dokumentierte Konfigurationsreviews können bei niedrigerem Risiko ausreichen.
Change Control. Änderungen müssen nicht automatisch dieselbe Revalidierungstiefe auslösen. Ein Release mit Änderung an Suchfiltern braucht eine andere Bewertung als eine Änderung am Rollenmodell oder am Audit Trail. Die Change-Control-SOP muss daher Impact Assessment, Testauswahl und Freigabeentscheidung zusammenführen.
Lieferantenbewertung. CSA stärkt die Bedeutung von Anbieter-Evidenz. Anbieter-Testpakete, Release Notes, Entwicklungsprozess, Known Issues, Security Reports und Validierungsdokumentation können übernommen werden, wenn Qualität und Scope geprüft wurden. Eine ungeprüfte Ablage im Validierungsordner reicht nicht. Für Cloud-Systeme beschreibt der Beitrag zur Shared-Responsibility-Matrix für die GxP-Cloud, wie Anbieter-Evidenz und Anwenderpflichten zusammenspielen.
Periodic Evaluation. Annex 11 verlangt eine periodische Bewertung computergestützter Systeme, unter anderem anhand von Funktionalität, Abweichungen, Incidents, Änderungshistorie, Performance, Zuverlässigkeit, Security und Validierungsstatus. CSA passt gut dazu, weil der validierte Zustand nicht durch jährliche Formalakte, sondern durch laufende Evidenz stabil bleibt.
Testmethoden im CSA-Modell
CSA macht Testen nicht beliebig. Der Ansatz verlangt sogar mehr methodische Klarheit, weil reduzierte Testtiefe begründet werden muss.
Robust scripted testing bleibt für kritische Funktionen notwendig. Testschritte, erwartete Ergebnisse, objektive Evidenz und Review werden formal dokumentiert. Beispiele sind Audit-Trail-Funktion, elektronische Signatur, Schnittstellen zur Chargenfreigabe oder automatisierte Sperrlogik.
Limited scripted testing reduziert die Detailtiefe, ohne den Nachweis aufzugeben. Die Prüfung bleibt geplant und dokumentiert, aber nicht jeder Klick wird als eigener Schritt protokolliert. Diese Form eignet sich für Funktionen mit moderatem Risiko und gut verstandener Standardfunktionalität.
Unscripted oder exploratory testing kann Erkenntnisse liefern, wenn Tester fachkundig vorgehen und Beobachtungen dokumentieren. Diese Methode eignet sich vor allem für Usability, Workflow-Verständnis, Fehlbedienungen, Konfigurationslogik und Grenzfälle.
Anbieter-Evidenz kann eigene Tests ersetzen oder reduzieren, wenn sie zum eigenen intended use passt. Die Übernahme muss dokumentieren, welche Anbieteraktivität übernommen wird, welche Lücke bleibt und welche Anwenderprüfung zusätzlich erforderlich ist.
Automatisierte Tests unterstützen CSA, vor allem bei Regression, Konfigurationsvergleichen und wiederkehrenden Releases. Automatisierung ist aber kein Pflichtmerkmal von CSA. Annex 11 verlangt vielmehr, dass automatisierte Testtools und Testumgebungen selbst auf Eignung bewertet werden.
Audit-Perspektive
In einer GMP-Inspektion wird CSA nicht als Etikett geprüft. Entscheidend ist, ob die Validierungsentscheidung nachvollziehbar ist. Ein Inspektor wird fragen, welche Funktion GxP-relevant ist, welches Risiko sie trägt, welche Evidenz gewählt wurde und warum diese Evidenz ausreicht.
Drei Nachweise tragen die Argumentation:
- Traceability. URS, Risikoentscheidung, Testauswahl, Testevidenz und Freigabe müssen miteinander verbunden sein.
- Begründete Reduktion. Weniger formale Tests sind vertretbar, wenn Risiko, Anbieter-Evidenz und alternative Kontrollen dokumentiert sind.
- Kontrollierter Betrieb. Change Control, Periodic Evaluation, Incident Management und Access Reviews zeigen, dass das System nach der Initialvalidierung unter Kontrolle bleibt.
Problematisch wird CSA, wenn das Label nur die Testmenge reduziert. Dann entsteht kein modernerer Validierungsansatz, sondern eine Nachweislücke. Tragfähig wird CSA erst, wenn Risikoentscheidungen besser werden als vorher.
90-Tage-Pilot für Pharma-IT
Eine Umstellung aller Validierungsverfahren in 90 Tagen ist nicht realistisch. Ein 90-Tage-Pilot ist es, wenn er auf ein abgegrenztes System oder einen abgegrenzten Release-Prozess beschränkt bleibt.
Tag 1 bis 30: Methodik und Scope. FDA-Guidance (Fassung vom 03.02.2026), GAMP 5 Second Edition, Annex 11 und ICH Q9(R1) auswerten. Pilotanwendung festlegen. GxP-Scope, intended use, Funktionen und vorhandene Validierungsunterlagen erfassen.
Tag 31 bis 60: Verfahren und Matrix. Risikobewertung auf Funktionsebene erstellen. Teststrategie mit Testmethoden und Evidenztypen definieren. Anbieter-Evidenz prüfen und Lücken bestimmen. Change-Control-Bezug festlegen.
Tag 61 bis 90: Pilotnachweis. Ausgewählte Funktionen mit der neuen Testlogik prüfen. Ergebnisse reviewen. Abweichungen, offene Punkte und Aufwandseffekte dokumentieren. Validierungsstrategie und SOP-Entwürfe anhand des Piloten nachschärfen.
Das Ergebnis ist keine abgeschlossene CSA-Transformation. Es ist ein belastbarer Nachweis, ob der Ansatz in der Organisation funktioniert und wo SOPs, Templates, Rollen oder Tools angepasst werden müssen.