CSV vs CSA: Zwanzig Jahre lang war die Computer System Validation gleichbedeutend mit endlosen Protokollen, Screenshots und Unterschriften auf jeder Seite. Mit der finalen FDA-Guidance Computer Software Assurance for Production and Quality Management System Software, veröffentlicht am 24. September 2025 und aktualisiert am 3. Februar 2026, wird Computer Software Assurance (CSA) zur offiziellen Referenz: weniger defensive Dokumentation, mehr kritisches Denken und risikobasiertes Testen. In diesem Beitrag sehen wir, was sich gegenüber der traditionellen CSV wirklich ändert, wie der neue Ansatz angewendet wird und was das für GxP-Fachleute bedeutet.
CSV vs CSA: Warum die FDA ihren Ansatz geändert hat
Die "klassische" CSV geht auf die FDA-Guidance General Principles of Software Validation (GPSV) von 2002 zurück — ein Dokument aus einer Zeit, in der Software größtenteils maßgeschneidert und on-premise installiert war. Im Laufe der Zeit ist die Anwendung der GPSV jedoch in überbordende Bürokratie ausgeartet: Zeile für Zeile unterschriebene Testskripte, Hunderte von Screenshots, doppelt geführte Papiernachweise. Das Ergebnis, das die FDA selbst festgestellt hat, ist paradox: Unternehmen stecken mehr Energie in die Erstellung von Dokumentation als in die tatsächliche Qualitätssicherung der Software.
CSA dreht die Perspektive um. Ziel ist nicht zu beweisen, dass alles auf dieselbe Weise getestet wurde, sondern den Assurance-Aufwand dort zu konzentrieren, wo das Risiko für Produktqualität und Patientensicherheit am höchsten ist — nach dem Prinzip des least burdensome approach. Die finale Guidance ersetzt formell Abschnitt 6 der GPSV von 2002 (den Teil zu Produktions- und Qualitätssystem-Software), während der Rest der GPSV in Kraft bleibt.
Vom Entwurf 2022 zur finalen Guidance: die Etappen
Der Weg der CSA war lang, und es lohnt sich, ihn nachzuzeichnen, denn viele Unternehmen sind beim Entwurf stehen geblieben:
- September 2022: Die FDA veröffentlicht den Guidance-Entwurf Computer Software Assurance for Production and Quality System Software.
- 24. September 2025: CDRH und CBER veröffentlichen die finale Guidance, die die zum Entwurf eingegangenen Kommentare berücksichtigt.
- 3. Februar 2026: Die FDA gibt eine aktualisierte Version mit dem Titel Computer Software Assurance for Production and Quality Management System Software heraus, angepasst an die Terminologie der QMSR (21 CFR Part 820, harmonisiert mit ISO 13485, anwendbar seit dem 2. Februar 2026).
Gegenüber dem Entwurf ergänzt die finale Version einen Terminologie-Abschnitt zu IaaS, PaaS und SaaS, stellt klar, dass das Framework auch auf KI-Tools anwendbar ist, die in der Produktion oder im Qualitätssystem eingesetzt werden, erweitert die Hinweise dazu, wie weit man sich auf die Dokumentation des Anbieters stützen kann, und betont die Präferenz für digitale Nachweise gegenüber Papier.
Wie CSA funktioniert: Intended Use, Risiko, Assurance
Die CSA-Methode gliedert sich in vier logische Schritte, die für jede Software (oder einzelne Funktion) im Geltungsbereich zu wiederholen sind:
- Intended Use identifizieren: Wird die Software (oder Funktion) direkt in der Produktion oder im Qualitätssystem eingesetzt, oder unterstützt sie diese nur?
- Prozessrisiko-Analyse: Kann ein Softwarefehler ein Qualitätsproblem verursachen, das die Sicherheit vorhersehbar beeinträchtigt? Wenn ja, ist das Prozessrisiko "high"; andernfalls "not high". Die FDA verwendet diese binäre Einstufung, lässt aber granularere Skalen zu (moderat, niedrig).
- Assurance-Aktivitäten auswählen, die dem Risiko angemessen sind: rigoroses scripted Testing für Hochrisiko-Funktionen, unscripted Methoden für den Rest.
- Nachweise dokumentieren: Intended Use, Risikoeinstufung, was getestet wurde, von wem und mit welchem Ergebnis.
Regulatorische Paradigmenwechsel wie dieser lassen sich am besten Stück für Stück verdauen: Abonnieren Sie The Pragmatic GMP, den kostenlosen wöchentlichen Newsletter von GuideGxP, für praxisnahe, audit-taugliche Analysen zu CSA, Annex 11 und Datenintegrität.
CSV vs CSA: der Vergleich Punkt für Punkt
| Aspekt | Traditionelle CSV (GPSV 2002) | CSA (finale Guidance 2025) |
|---|---|---|
| Ausgangspunkt | Validierung des gesamten Systems dokumentieren | Intended Use und Risiko für Patient/Qualität |
| Testing | Überwiegend scripted, einheitlich | Scripted nur bei hohem Risiko; unscripted sonst |
| Nachweise | Screenshots, Ausdrucke, manuelle Unterschriften | Digitale Records: Systemlogs, Audit Trails, Ergebnisse im Tool |
| Lieferanten | Vor-Ort-Audits und interne Revalidierung | Risikobasierte Nutzung der Anbieterdokumentation (ISO, SOC, SBOM) |
| Cloud und KI | Nicht berücksichtigt | IaaS/PaaS/SaaS und KI-Tools ausdrücklich im Geltungsbereich |
| Dokumentationsaufwand | Hoch, unabhängig vom Risiko | Risikoproportional (least burdensome) |
Scripted und unscripted Testing: Wie wählt man?
Die konkreteste Neuerung für Validierer ist die Legitimierung des unscripted Testing. Für Funktionen mit "not high" Risiko nennt die Guidance ausdrücklich Methoden wie Ad-hoc-Testing, Error-Guessing und Exploratory Testing: Der Tester arbeitet mit realistischen Szenarien und hält knapp fest, was er getan und beobachtet hat — ohne vorab genehmigte Schritt-für-Schritt-Skripte. Für Funktionen mit "high" Risiko bleibt ein rigoroseres, nachvollziehbares Testen — typischerweise scripted — empfohlen. Keine Methode ist jedoch gesetzlich vorgeschrieben: Die Wahl muss mit kritischem Denken begründet und in der Risikoanalyse dokumentiert werden.
Nachweise und Dokumentation: Was die FDA erwartet
CSA bedeutet nicht "keine Dokumente". Es bedeutet die richtigen Dokumente. Die Mindestakte, die ein Inspektor erwartet, umfasst: das Software-Inventar, gemappt auf die Intended Uses, die Prozessrisiko-Einstufung für jedes Element, die Beschreibung der durchgeführten Assurance-Aktivitäten, wer sie durchgeführt hat und die Ergebnisse. Die Guidance rät ausdrücklich von Screenshots und Papier-Duplikaten ab, wenn das System bereits Logs und Audit Trails erzeugt, die als Nachweis dienen können. Achtung bei einem oft missverstandenen Punkt: Sind die Records elektronisch, gilt weiterhin 21 CFR Part 11, und die FDA übt bei der Validierung von Produktions- und Qualitätssystem-Software keine Enforcement Discretion aus.
Und für Pharma? GAMP 5 und Annex 11
Formell ist die CSA eine Guidance für Medizinprodukte (Produktions- und QMS-Software unter 21 CFR Part 820). Ihre Prinzipien sind aber auch in der Pharmaindustrie bereits gängige Praxis: GAMP 5 Second Edition (ISPE, 2022) verankert Critical Thinking, agiles Testen und Lieferanten-Leverage in voller Übereinstimmung mit der CSA, und die laufende Revision des EU-GMP-Annex 11 geht in dieselbe risikobasierte Richtung. Wer im GxP-Umfeld arbeitet, kann den CSA-Ansatz daher in die eigene Validierungsmethodik übernehmen — mit Annex 11 und Part 11 als verbindlichen Referenzen für elektronische Aufzeichnungen.
GuideGxP-Empfehlung
Schreiben Sie nicht alle SOPs über Nacht um. Der Übergang von CSV zu CSA erfolgt schrittweise und mit soliden Nachweisen: Aktualisieren Sie zuerst die Risikobewertungs-SOP für computergestützte Systeme und führen Sie die Einstufung nach Intended Use und Prozessrisiko ein; legen Sie in der SOP fest, wann unscripted Testing zulässig ist und wie es dokumentiert wird; überarbeiten Sie die Lieferantenqualifizierung, um Zertifizierungen und Testpakete des Anbieters belastbar zu nutzen; und stellen Sie sicher, dass Audit Trails und Logs tatsächlich abrufbar sind, denn in der CSA sind sie Ihr primärer Nachweis. Im Audit lautet die Frage nicht "Wie viele Skripte haben Sie ausgeführt?", sondern "Wie haben Sie entschieden, wo Sie das Testen konzentrieren?".
Für eine inspektionsfeste Data-Integrity-Governance, Audit-Trail-Review und QC-Labor-Kontrollen werfen Sie einen Blick auf unsere Data Integrity im GMP-Umfeld – Operative Anleitung zu Governance, Audit Trail Review und QC-Laboren: die ideale Ergänzung, um CSA in Ihr PQS zu bringen.
