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 adressiert Computer und automatisierte Datenverarbeitungssysteme, die in der Medizinprodukteproduktion oder im Quality Management System nach 21 CFR Part 820 eingesetzt werden. Für andere pharmazeutische GxP- und EU-Kontexte gilt sie nicht 1:1; übertragbar ist nur die risikobasierte Denkweise, die gegen die jeweils anwendbaren Anforderungen geprüft werden muss. Wichtig zuerst: CSA ist kein neuer Standard, der CSV ablöst, und keine Erlaubnis, weniger zu validieren. Sie beschreibt, wie Medizinproduktehersteller Vertrauen in die eingesetzte Automatisierung herstellen — mit einem anderen Schwerpunkt.

Der Kerngedanke in diesem FDA-Geltungsbereich: 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

Innerhalb dieses FDA-Geltungsbereichs dreht CSA 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.

Im FDA-Geltungsbereich verlagert CSA Arbeit vom Abschreiben zum Begründen; außerhalb ist dieser Denkansatz methodische Orientierung, keine FDA-Vorgabe.

Was sich für Ihre Validierungsstrategie konkret ändert

Für Software im FDA-Geltungsbereich beschreibt CSA vier mögliche Verschiebungen. Außerhalb dieses Scopes — etwa in Arzneimittel-GMP-/EU-Kontexten — sind sie keine FDA-Vorgaben, sondern methodische Orientierung und gegen die jeweils anwendbaren Anforderungen zu prüfen:

• 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 QMSR-Anforderungen nach 21 CFR Part 820 bleiben in Kraft; Part 11 gilt nur, soweit dessen eigener Geltungsbereich eröffnet ist. CSA empfiehlt einen Ansatz, ersetzt diese Anforderungen aber nicht.
• Sie gilt für Produktions-/QMS-Software im Medizinproduktebereich. Die Denkweise kann auf Arzneimittel-GMP- und EU-Kontexte (EU-Annex 11, GAMP 5 2nd Edition) übertragen werden — 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.

Häufige Fragen

Was ist der Unterschied zwischen CSA und CSV?

Im FDA-Geltungsbereich für Software in der Medizinprodukteproduktion oder im QMS nach Part 820/QMSR verfolgen CSV und CSA dasselbe Ziel — den Nachweis, dass ein System für seinen vorgesehenen Zweck geeignet ist und unter Kontrolle bleibt. In der Praxis ist CSV dokumentationsgetrieben geworden, wo häufig das Dokument selbst zum Ziel wird und nicht der Nachweis dahinter. CSA setzt beim Risiko einer Funktion an und richtet die Testtiefe danach aus: schlanker Nachweis für Low-Risk-Funktionen, robustes skriptbasiertes Testen dort, wo Produktqualität oder Patientensicherheit direkt berührt sind. Außerhalb dieses Scopes ist CSA methodische Orientierung, keine FDA-Vorgabe.

Ersetzt CSA die klassische CSV?

Nein. CSA ist eine nicht bindende FDA-Guidance im Scope für Software in der Medizinprodukteproduktion oder im QMS nach Part 820/QMSR, kein neuer Standard und keine Erlaubnis, weniger zu validieren. Außerhalb dieses Scopes schafft sie keine zusätzliche FDA-Pflicht; ihre risikobasierte Denkweise kann dort methodische Orientierung geben.

Was empfiehlt die FDA CSA Guidance?

Für Software in der Medizinprodukteproduktion oder im QMS nach Part 820/QMSR empfiehlt die Guidance einen risikobasierten Gedankengang in vier Schritten: den Intended Use einer Funktion bestimmen, das Risiko einstufen, die passende Assurance-Aktivität wählen und den Nachweis angemessen erfassen. Für die Assurance-Aktivität nennt die FDA ein Spektrum von unscripted testing (ad-hoc/exploratory) bis scripted testing (limitiert oder robust), abgestuft nach Risiko. Tragend ist dabei Critical Thinking: Jede Risikoeinstufung muss begründet sein, eine leere „geringes Risiko“-Behauptung genügt im Audit nicht.

Gilt CSA auch für Arzneimittelhersteller und in der EU?

Die CSA-Guidance adressiert Software in der Medizinprodukteproduktion oder im Quality Management System nach 21 CFR Part 820. Ein Arzneimittel-GMP- oder EU-Kontext allein eröffnet diesen Geltungsbereich nicht. Für einen davon getrennten Pharma-/EU-Anwendungsfall ist sie nicht direkt anwendbar. Ihre risikobasierte Denkweise kann dort als methodische Orientierung neben den jeweils anwendbaren Anforderungen, etwa EU-Annex 11, dienen; daraus folgt keine 1:1-Geltung. GAMP 5 ist davon getrennte, nicht bindende Industrie-Guidance.

Wie passt CSA zu GAMP 5?

CSA und GAMP 5 2nd Edition (2022) verfolgen dieselbe Stoßrichtung: risikobasierte Validierung mit Critical Thinking statt Schema-Dokumentation. GAMP 5 ist der ISPE-Branchenleitfaden für den Lebenszyklus computergestützter GxP-Systeme; CSA ist die FDA-Guidance für Software in der Medizinprodukteproduktion und im QMS nach 21 CFR Part 820, die den Aufwand vom Dokumentieren zum belastbaren Begründen verschiebt — auf Pharma-GMP und EU-Kontexte methodisch übertragbar, ohne 1:1-Geltung. Beide ergänzen sich: Der GAMP-Lebenszyklus und seine Kategorien bleiben als Werkzeuge nutzbar, während CSA Assurance-Aufwand und Nachweistiefe an Risiko und Intended Use ausrichtet.