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

Computer Software Assurance (CSA) ist die finale FDA-Guidance für risikobasierte Software Assurance in der Medizinprodukteproduktion und in Quality Management Systems. Die im Februar 2026 revidierte Guidance ersetzt die Fassung vom September 2025 und richtet sie an der geänderten 21 CFR Part 820 Quality Management System Regulation (QMSR) aus. Für andere Pharma-GxP-Kontexte können die Methoden eine risikobasierte CSV unterstützen; der direkte FDA-Scope wird dadurch nicht erweitert.

Die FDA hat ihre finale Guidance „Computer Software Assurance for Production and Quality Management System Software” im Februar 2026 revidiert. Diese Fassung ersetzt die Final Guidance vom 24. September 2025 und berücksichtigt die Änderungen an 21 CFR Part 820 durch die Quality Management System Regulation (QMSR). Der inhaltliche Kern bleibt: Test-Volumen ist kein Synonym für Software Assurance. Für IT-Leiter, QA-Verantwortliche und Business Process Owner ist deshalb zuerst der Scope zu klären. Dieser Beitrag zeigt, was CSA von verbreiteter CSV-Praxis unterscheidet, wann die FDA-Guidance direkt greift und wie sich die risikobasierten Methoden sauber übertragen lassen.

Was CSA wirklich ist — die Definition der FDA

Computer Software Assurance ist die methodische Antwort der FDA auf eine seit Jahren wachsende Diskrepanz. Auf der einen Seite stand die etablierte CSV-Praxis: dokumentationsschwer, testintensiv, in der Tendenz formalistisch. Auf der anderen Seite stand die Realität moderner Software-Entwicklung: agil, iterativ, cloud-basiert, mit immer kürzeren Release-Zyklen. CSA schließt diese Lücke.

Der Scope ist klar umrissen: CSA gilt für Computer und automatisierte Datenverarbeitungssysteme, die in der Produktion von Medizinprodukten oder im zugehörigen Quality Management System eingesetzt werden. Dazu können je nach Intended Use etwa Produktions-, Labor-, Trainings-, Dokumenten- oder Qualitätsanwendungen gehören. Software as a Medical Device folgt eigenen regulatorischen Anforderungen. Ein LIMS, MES oder ERP-Modul fällt nicht allein wegen seines Produktnamens unter CSA; entscheidend sind Herstellerkontext und Intended Use.

Im Kern verschiebt CSA die Logik der Validierung: weg von „testen Sie alles, was technisch testbar ist”, hin zu „bewerten Sie risikobasiert, was die Patientensicherheit und Produktqualität schützt”. Diese Verschiebung ist keine Aufweichung der Anforderungen. Sie ist eine Präzisierung dessen, was Validierung leisten soll: Sicherheit für Patient und Produkt — nicht Vollständigkeit von Test-Skripten.

Wichtig für die Einordnung: CSA existiert parallel zu 21 CFR Part 11 und 21 CFR Part 820. Die regulatorischen Pflichten — Audit-Trails, elektronische Signaturen, Datenintegrität, Quality-System-Anforderungen — bleiben unverändert. CSA ändert nicht, was Sie nachweisen müssen. CSA ändert, wie Sie es nachweisen.

CSV vs CSA im direkten Vergleich

Die folgende Tabelle zeigt die zentralen Verschiebungen zwischen klassischer CSV-Praxis und der FDA-CSA-Methodik:

Aspekt	dokumentenlastige CSV-Praxis	CSA (FDA Final Guidance, revidiert 2026)
Grundansatz	Compliance-First	Assurance-First (Patient + Produkt)
Test-Philosophie	Volltestung, scripted	Risikobasiert, fokussiert
Dokumentations-Tiefe	Umfangreich, prozedural	Schlank, nutzenorientiert
Denkmodus	Beweise alles	risikobasierte Begründung
Validierungs-Effort	Hoch, oft proportional zur Funktionszahl	Proportional zum Risiko
Patient-Safety-Fokus	Implizit	Explizit, primär
Audit-Trail	Test-Volumen-orientiert	Beurteilungs-Begründung-orientiert
Modernisierungs-Anschluss	Schwer kompatibel mit Agile/DevOps	Nativ unterstützt

Die Vergleichstabelle zeigt: CSA ist nicht weniger als CSV — CSA ist anders strukturiert. Wer die zweite Spalte gegen die dritte liest und denkt „weniger Aufwand = weniger Sicherheit”, hat den Punkt verfehlt. CSA reduziert Redundanz, nicht Substanz. Die Audit-Belastbarkeit bleibt — sie entsteht nur durch dokumentierte Bewertung statt durch dokumentiertes Test-Volumen.

„CSA ist nicht weniger CSV. CSA ist klüger CSV.”

Die vier Kernprinzipien der FDA-Methodik

Für die Umsetzung verdichten wir die Guidance auf vier Arbeitsprinzipien. Das ist ein DHC-Praxis-Modell, keine wörtliche FDA-Gliederung. Es bildet einen handhabbaren Rahmen für Software Assurance im direkten CSA-Scope.

Erstes Prinzip: Intended Use definieren. Bevor validiert wird, muss klar sein, wofür die Software eingesetzt wird. Eine LIMS-Funktion, die Probenidentifikationen erzeugt, hat einen anderen Intended Use als eine LIMS-Funktion, die Sample-Labels druckt. Die FDA verlangt diese Differenzierung explizit — und nicht erst im Test-Skript, sondern bereits in der Validierungsplanung.

Zweites Prinzip: Risiko bewerten. Welche Funktionen können bei Fehlverhalten die Patientensicherheit oder Produktqualität beeinträchtigen? Diese Frage steuert den gesamten Validierungs-Aufwand. Hochrisiko-Funktionen werden ausführlich getestet. Niedrigrisiko-Funktionen werden — mit dokumentierter Begründung — reduziert oder über Lieferanten-Erklärungen abgedeckt. Die Risikobewertung ist kein Anhang; sie ist das Steuerungs-Instrument.

Drittes Prinzip: Assurance Activities planen. Risikobasiert wird entschieden, welche Aktivitäten den nötigen Vertrauensnachweis liefern: scripted oder unscripted Testing, Lieferanten-Nachweise, Monitoring und weitere geeignete Methoden. Die Auswahl muss zum Intended Use und Prozessrisiko passen; scripted Testing ist nicht pauschal vorgeschrieben.

Viertes Prinzip: Records angemessen führen. Die Dokumentation orientiert sich am Aufwand der Assurance Activities. Eine ausführlich getestete Hochrisiko-Funktion erhält vollständige Test-Records. Eine über Lieferanten-Bewertung abgedeckte Niedrigrisiko-Funktion erhält eine knappe Begründungs-Dokumentation. Die Idee: jede Seite Dokumentation hat einen Zweck. Was keinen Zweck hat, wird auch nicht produziert.

Diese vier Prinzipien wirken zusammen. Wer das erste vernachlässigt, kann das zweite nicht sauber bewerten. Wer das dritte falsch wählt, produziert beim vierten entweder zu wenig oder zu viel. CSA ist methodisch — und genau dadurch entsteht der Effizienzgewinn.

Wann CSA gilt — und wann weiterhin CSV

Die Frage „CSA oder CSV” ist nicht binär. Beide Methodiken bestehen 2026 parallel — mit klarem Anwendungsbereich:

CSA gilt direkt für: Computer und automatisierte Datenverarbeitungssysteme in der Medizinprodukteproduktion oder im Quality Management System eines Medizinprodukteherstellers. Ob LIMS, MES, ERP-, Dokumenten-, Trainings- oder Qualitätsanwendung in den Scope fällt, hängt vom konkreten Intended Use ab.

Andere CSV-Rahmen bleiben relevant für: pharmazeutische GMP-, GCP-, GLP- oder GDP-Systeme außerhalb dieses direkten Scopes sowie für andere regulatorische Kontexte. Risikobasierte Assurance kann dort nach GAMP 5, ICH Q9 und den jeweils anwendbaren Regeln umgesetzt werden, ohne die FDA-CSA-Guidance als unmittelbare Anforderung auszugeben.

Software als Medizinprodukt (SaMD) folgt einer eigenen regulatorischen Logik. 21 CFR Part 820, IEC 62304 und die jeweiligen FDA-Guidances zu AI/ML-SaMD bilden hier den Rahmen. CSA-Prinzipien sind methodisch verwandt, aber nicht direkt anwendbar.

Praktisch bedeutet das für Ihre IT-Landschaft: klassifizieren Sie zuerst Herstellerkontext, Intended Use und regulatorische Grundlage. Nur Systeme im direkten Scope werden als FDA-CSA-Anwendung geführt. Für andere GxP-Systeme können geeignete Methoden übernommen werden, müssen aber in ihrem eigenen Regelwerk begründet bleiben.

Was sich praktisch in Ihrer Validierungs-Strategie ändert

Wer die CSA-Methodik konsequent anwendet, sieht in drei Bereichen messbare Veränderungen.

Test-Volumen kann gezielt sinken. Wenn Prozessrisiko, Intended Use und verwertbare Lieferantennachweise es tragen, können pauschal geskriptete Tests durch passendere Assurance-Aktivitäten ersetzt werden. Das Ergebnis ist nicht automatisch weniger Arbeit, sondern ein besser begründeter Einsatz der Arbeit.

Dokumentations-Struktur verändert sich. CSV-Dokumentation ist klassischerweise vorlagengetrieben — jede Funktion wird nach demselben Schema beschrieben. CSA-Dokumentation ist begründungsgetrieben — jede Funktion wird nach ihrem Risiko-Profil dokumentiert. Vorlagen bleiben hilfreich, aber sie werden zu Werkzeugen, nicht zu Pflicht-Strukturen.

Die Begründung wird zum zentralen Nachweis. Ihr Dossier muss zeigen, warum eine Funktion als hoch oder nicht hoch im Prozessrisiko bewertet wurde und weshalb die gewählten Assurance-Aktivitäten angemessen sind. Audit-Vorbereitung fokussiert deshalb nicht nur Testnachweise, sondern auch den nachvollziehbaren Entscheidungspfad.

Konkret heißt das für Ihre Validierungsstrategie: Anwendbarkeit klären, Risikobewertungen und Teststrategien neu ausrichten, Reviewer-Kompetenz aufbauen und betroffene Verfahren anpassen. Zeitplan und Aufwand hängen von Portfolio, Governance, Systemrisiko und verfügbarem Nachweisbestand ab.

Der Weg zur Implementierung — wo Sie anfangen

CSA-Einführung ist kein Big-Bang-Projekt. Sie ist ein strukturierter Übergang in vier Schritten:

1. System-Bestand klassifizieren. Welche Ihrer GxP-Systeme fallen unter CSA-Anwendungsbereich? Welche nicht? Eine einfache Klassifikations-Tabelle reicht als Startpunkt.
2. CSA-Pilotsystem auswählen. Beginnen Sie mit einem klar abgegrenzten System im direkten CSA-Scope, dessen Prozessrisiko und Nachweisbestand eine belastbare Pilotbewertung erlauben.
3. Methodik im Pilot anwenden. Risikobewertung, Assurance Activities, angemessene Records — die vier Prinzipien im Pilot durchziehen. Dokumentieren Sie, was funktioniert und was anzupassen ist.
4. Framework skalieren. Auf Basis des Piloten passen Sie Ihr SOP-Set, Ihre Vorlagen und Ihre Reviewer-Schulung an. Dann rollen Sie die Methodik auf das gesamte System-Portfolio aus.

Der Zeitplan wird nach Anzahl und Kritikalität der Systeme, betroffenen Verfahren, Reviewer-Kompetenz und Governance-Reife festgelegt. Der Pilot liefert die belastbare Grundlage für den Rollout. Für die strukturierte Übertragung auf Ihr Portfolio bietet unsere CSV-Beratung den passenden Rahmen.

Häufige Fragen

Ersetzt CSA das CSV-Framework vollständig?

Nein. CSA beschreibt im direkten Scope einen Ansatz für Software Assurance; die Pflicht zum Eignungsnachweis bleibt bestehen. Außerhalb der Medizinprodukteproduktion und des zugehörigen Quality Management Systems gelten die jeweils anwendbaren CSV- und GxP-Anforderungen. 21 CFR Part 11 und die Anforderungen des Quality Management Systems bleiben unberührt.

Gilt CSA auch außerhalb der USA, etwa für EU-Pharma?

CSA ist eine FDA-Guidance mit einem definierten US-regulatorischen Scope. Risikobasierte Methoden sind auch mit europäischen GxP-Ansätzen anschlussfähig, daraus entsteht jedoch keine unmittelbare CSA-Pflicht für EU-Pharma. Die anwendbare Rechts- und Guidance-Basis muss pro System festgelegt werden.

Wie verhalten sich CSA und GAMP 5 2nd Edition zueinander?

Sie können sich ergänzen, sind aber nicht austauschbar. GAMP 5 Second Edition ist breiter und unterstützt risikobasierte Validierung in unterschiedlichen GxP-Kontexten. FDA CSA gilt direkt für Software in der Medizinprodukteproduktion und in Quality Management Systems. Methodische Übereinstimmungen helfen bei der Umsetzung; die Erfüllung beider Referenzen muss dennoch separat begründet werden.

Primärquellen

• FDA: Computer Software Assurance for Production and Quality Management System Software, revidierte Final Guidance (Februar 2026)
• ISPE: GAMP 5 Guide, Second Edition (Juli 2022)
• eCFR: 21 CFR Part 820 — Quality Management System Regulation
• eCFR: 21 CFR Part 11 — Electronic Records; Electronic Signatures
• ICH: Q9(R1) Quality Risk Management, Step 4 (Januar 2023)
• FDA: Case for Quality

---

Autor

Daniel Herrmann Consulting — Boutique-Beratung für GxP-Compliance und Computer System Validation in Pharma, Biotech und MedTech. 15+ Jahre Hands-on-Expertise. 60+ validierte Systeme. 100 % Audit-Bestehensquote. 0 kritische Findings.