CSA vs CSV: Was die FDA Final Guidance für Ihre Validierungsstrategie bedeutet

Worum es geht: CSA ist eine Methode, kein neues Regelwerk

Die FDA hat die Guidance „Computer Software Assurance for Production and Quality System Software“ zunächst als Entwurf (Draft) im September 2022 vorgelegt und am 24. September 2025 als finale Guidance veröffentlicht; im Februar 2026 folgte eine aktualisierte Fassung (jetzt „… Quality Management System Software“, terminologisch an die QMSR angepasst). Sie richtet sich an Hersteller von Medizinprodukten, ist in ihrer Denkweise aber für jede regulierte Software relevant. Wichtig zuerst: CSA ist kein neuer Standard, der CSV ablöst, und keine Erlaubnis, weniger zu validieren. Es ist eine Methode, wie Sie die bestehende Validierungspflicht erfüllen — mit einem anderen Schwerpunkt.

Der Kerngedanke: Nicht jede Funktion einer Software trägt das gleiche Risiko für Patient und Produkt. Ein Algorithmus, der eine Freigabeentscheidung berechnet, ist etwas anderes als ein Konfigurationsfeld, das die Farbe eines Dashboards setzt. CSA fordert, diesen Unterschied vor dem Testen zu treffen und den Aufwand danach auszurichten — statt für jede Funktion dieselbe Skript-Tiefe zu produzieren.

Das eigentliche Problem: CSV ist dokumentationsgetrieben geworden

Computerized System Validation ist als Prinzip unverändert richtig: Sie weisen nach, dass ein System für seinen vorgesehenen Zweck geeignet ist und unter Kontrolle bleibt. In der Praxis hat sich daraus über Jahre eine Routine entwickelt, in der das Dokument zum Ziel wurde und nicht der Nachweis dahinter.

Die FDA benennt diese Schieflage in der Guidance ausdrücklich. Sie beobachtet, dass ein erheblicher Teil des Validierungsaufwands in das Erstellen, Prüfen und Pflegen von Dokumentation fließt — und nicht in das Testen selbst. Typische Symptome kennen Sie:

• Hundertseitige Testprotokolle für unkritische, konfigurierte Standardfunktionen.
• Screenshots, die belegen sollen, dass ein Button funktioniert, den der Hersteller millionenfach getestet hat.
• Teams, die bei jedem Update aus Angst vor dem Auditor die volle Skript-Tiefe wiederholen, statt das tatsächliche Änderungsrisiko zu bewerten.

Das Ergebnis ist teuer und — das ist der unbequeme Punkt — oft nicht sicherer. Dokumentationslast korreliert nicht automatisch mit Patientensicherheit. Sie kann sie sogar verdecken, wenn der reale Test im Papierberg untergeht.

Was CSA praktisch anders macht: Risiko zuerst, Methode danach

CSA dreht die Reihenfolge um. Statt mit der Frage „Welches Protokoll schreiben wir?“ zu beginnen, beginnt CSA mit „Welches Risiko trägt diese Funktion?“. Erst aus der Risikoeinstufung folgt, wie viel Nachweis angemessen ist. Die Guidance skizziert dafür einen vierstufigen Gedankengang:

• 1. Intended Use bestimmen. Wofür wird die Funktion eingesetzt — direkt qualitäts-/sicherheitsrelevant oder unterstützend?
• 2. Risiko einstufen. Hohes Risiko, wenn ein Versagen Produktqualität oder Patientensicherheit direkt gefährdet; geringeres Risiko bei indirekter oder unterstützender Funktion.
• 3. Assurance-Aktivität wählen. Die FDA nennt ein Spektrum: unscripted testing (ad-hoc / exploratory), scripted testing (limitiert oder robust) — abgestuft nach Risiko.
• 4. Nachweis angemessen erfassen. Festhalten, was das Ergebnis und seine Beurteilbarkeit belegt — nicht mehr.

Der praktische Effekt: Für eine konfigurierte Low-Risk-Funktion kann ein nachvollziehbar dokumentierter exploratorischer Test ausreichen. Für eine High-Risk-Funktion, die GxP-Entscheidungen direkt beeinflusst, erwartet die FDA weiterhin robustes, skriptbasiertes Testen mit belastbarem Nachweis. Sie verteilen Ihr Budget dorthin, wo Risiko entsteht — nicht gleichmäßig über alles.

Critical Thinking statt Häkchen-Routine

Der Begriff, der die ganze Guidance trägt, ist Critical Thinking. CSA verlangt eine begründete Entscheidung — pro Funktion, pro Risiko, pro Testintensität — statt einer reflexhaften Wiederholung desselben Protokolls. Das ist eine Befreiung und eine Bürde zugleich.

Befreiung, weil Sie unkritische Funktionen nicht mehr mit derselben Tiefe wie kritische behandeln müssen. Bürde, weil Sie die Einstufung verantworten und belegen müssen. Ein leeres Protokoll mit dem Hinweis „geringes Risiko“ ist kein Critical Thinking — es ist eine Behauptung. Was der Auditor sehen will, ist die Begründung: Warum wurde diese Funktion so eingestuft, und warum ist die gewählte Test-Tiefe dafür angemessen?

Genau diese Begründungskette ist der wunde Punkt. Sie lebt häufig im Kopf erfahrener Validierer und nicht im System. Genau hier setzt das Trust-Prinzip von traqx an: Ein KI-Vorschlag zur Risikoeinstufung oder zur Test-Tiefe ist immer ein Vorschlag mit Quellenbezug — die Entscheidung trifft der Mensch, und der Audit-Trail hält fest, wer was auf welcher Grundlage entschieden hat. CSA verlagert Arbeit vom Abschreiben zum Begründen; eine belastbare Begründungs-Architektur ist deshalb kein Komfort, sondern Voraussetzung.

CSA verlagert Arbeit vom Abschreiben zum Begründen — eine belastbare Begründung wird zur Voraussetzung.

Was sich für Ihre Validierungsstrategie konkret ändert

Wenn Sie heute klassisch nach CSV validieren, ist der Umstieg kein Rip-and-Replace. Es sind vier Verschiebungen, die Sie schrittweise vornehmen können:

• Risikoeinstufung wird zur ersten Aktivität, nicht zur Anlage am Ende. Ohne dokumentierte Einstufung lässt sich der reduzierte Aufwand nicht rechtfertigen.
• Sie nutzen die Vorleistung des Anbieters. Bei etablierter Standardsoftware (GAMP-Kategorie 3/4) dürfen Sie auf die Tests des Herstellers aufsetzen, statt sie zu wiederholen — Sie testen Ihre Konfiguration und Ihren Use-Case, nicht das Produkt.
• Der Nachweis wird schlanker, aber nicht beliebig. Weniger Screenshots, dafür belastbare Aussagen darüber, was getestet wurde, mit welchem Ergebnis und warum es genügt.
• Updates werden risikobasiert behandelt. Ein Patch ohne GxP-relevante Funktionsänderung erfordert nicht die volle Requalifizierung — die Änderungsbewertung entscheidet.

Wichtig ist die Konsistenz: Die FDA akzeptiert reduzierten Aufwand dort, wo das Risiko gering ist — sie erwartet im Gegenzug, dass High-Risk-Funktionen wirklich gründlich geprüft werden. CSA ist kein Rabatt auf Validierung, sondern eine Umverteilung. Wer es als Sparprogramm missversteht, schwächt genau die Stellen, auf die der Auditor zuerst schaut.

Die ehrlichen Grenzen: Wo CSA nichts ändert

Zum Schluss die unbequeme Nüchternheit, ohne die jede CSA-Darstellung unvollständig wäre:

• Es ist eine FDA-Guidance, kein bindendes Gesetz. Guidances stellen die aktuelle Auffassung der Behörde dar. Die zugrunde liegenden Anforderungen (21 CFR Part 11, Part 820) bleiben unverändert in Kraft. CSA ist der empfohlene Weg, sie zu erfüllen — nicht ihre Aufhebung.
• Sie ist auf Medical-Device-Software zugeschnitten. Die Methodik ist auf Arzneimittel-GMP und EU-Kontexte (EU-Annex 11, GAMP 5 2nd Edition) übertragbar — aber 1:1-Geltung dürfen Sie daraus nicht ableiten. Prüfen Sie den Geltungsbereich für Ihren konkreten Fall.
• Weniger Doku heißt nicht weniger Verantwortung. Die Beweislast verschiebt sich vom Protokoll zur Begründung. Wenn Ihre Einstufung nicht trägt, hilft auch ein schlanker Nachweis nicht — er macht die Lücke nur sichtbarer.
• KI ändert daran nichts Grundsätzliches. Ein Werkzeug kann Risikoeinstufungen und Testtiefe vorschlagen und Nachweise konsistent festhalten. Die regulatorische Verantwortung für die Entscheidung bleibt beim Menschen — bei CSV wie bei CSA.