CSV und CSA Veröffentlicht: 23.06.2026 · 11:00 Uhr 8 Min Lesezeit von

CSA-Methodik: Software in fünf Schritten risikobasiert prüfen

CSA umsetzen: Anwendungsbereich klären, Prozessrisiken bewerten, Prüfungen wählen und vorhandene Nachweise nutzen. Mit fünf praktischen Arbeitsschritten.

Unser Praxisablauf in fünf Schritten: Risiken bewerten, Anforderungen klären, Prüfungen wählen, Lieferantennachweise beurteilen und Änderungen im Betrieb steuern.

Computer Software Assurance (CSA) ist der risikobasierte Assurance-Ansatz der finalen FDA-Guidance für Software in der Medizinprodukteproduktion und im zugehörigen Qualitätsmanagementsystem. Unser Praxisablauf verbindet fünf Aufgaben: Prozessrisiken beurteilen, Anforderungen konkretisieren, Prüfungen auswählen, Lieferantennachweise bewerten und Änderungen im Betrieb steuern. Für andere Pharma-GxP-Systeme können diese Methoden eine risikobasierte CSV unterstützen; sie erweitern den direkten FDA-Scope nicht.

Die fünf Schritte sind unser Praxisvorschlag für die Umsetzung, keine wörtliche Fünf-Schritte-Vorgabe der FDA. Klären Sie vorab, ob Ihr Einsatz in den direkten Anwendungsbereich der Guidance fällt.

Im Projekt liegen Testentwürfe für viele Funktionen bereit. Einige sichern kritische Entscheidungen ab, andere prüfen einfache Hilfsabläufe. Werden beide gleich behandelt, wächst der Aufwand, ohne dass die zusätzliche Arbeit zwangsläufig die entscheidenden Risiken besser beherrscht. Für die Projektleitung lohnt sich deshalb ein gemeinsamer Blick mit Fachbereich und Quality auf die Frage, welcher Fehler welche Wirkung hätte.

Die FDA hat die finale CSA-Guidance im Februar 2026 revidiert und an der geänderten 21 CFR Part 820 Quality Management System Regulation (QMSR) ausgerichtet; sie ersetzt die Version vom September 2025. Der methodische Kern bleibt: Assurance-Aufwand folgt im direkten Scope dem Prozessrisiko. In der Praxis wird CSA jedoch oft als pauschales „weniger validieren“ missverstanden. Genau dort entstehen neue Audit-Risiken und falsche Scope-Aussagen.

Dieser Leitfaden zeigt die fünf Schritte einer sauberen CSA-Umsetzung — und wo die häufigsten Missverständnisse lauern.

Geltungsbereich und Grundgedanke von CSA

Computer Software Assurance ist ein risikobasierter Software-Assurance-Ansatz für Computer und automatisierte Datenverarbeitungssysteme in der Medizinprodukteproduktion oder im zugehörigen Quality Management System. Der Kern: Assurance-Aufwand und Records folgen dem Prozessrisiko und dem Intended Use.

Für die Umsetzung hilft eine einfache Reihenfolge: erst Einsatz und mögliche Fehler verstehen, dann geeignete Nachweise auswählen. Die folgende Tabelle ist unsere Arbeitshilfe für diese Abstimmung. Sie vergleicht keine angeblichen Erfolgsquoten verschiedener Methoden.

Entscheidungsfrage Was Ihr Team festhalten sollte
Welche Aufgabe übernimmt die Software? Eingaben, Verarbeitung, Ergebnis und spätere Verwendung
Welche Fehler wären relevant? Mögliche Wirkung und bereits vorhandene Kontrollen
Welche Nachweise existieren schon? Passende Version, Abdeckung und Einschränkungen
Was muss zusätzlich geprüft werden? Begründete Prüfziele und geeignete Ausführung
Wer entscheidet über das Ergebnis? Zuständigkeit, offene Befunde und Akzeptanz
Was löst später eine neue Bewertung aus? Relevante Änderungen am Einsatz oder System

Die 5 Schritte der CSA-Methodik

Schritt 1: Prozessrisiken vor dem Testentwurf bewerten

Vor dem Testentwurf steht die Frage: Welche Fehler einer Funktion sind vernünftigerweise vorhersehbar, auch wenn sie selten auftreten, und welche Folgen hätten sie für Prozess, Produktqualität und Sicherheit?

Die FDA-Guidance unterscheidet für ihre Empfehlungen zwischen hohem Prozessrisiko und nicht hohem Prozessrisiko. Ein hohes Prozessrisiko liegt vor, wenn ein Funktionsfehler ein Qualitätsproblem verursachen kann, das vorhersehbar die Sicherheit beeinträchtigt. Eigene feinere Kategorien sind möglich; eine starre Dreiteilung in hoch, mittel und niedrig schreibt die Guidance nicht vor.

Ergebnis für die Projektplanung: Eine dokumentierte Risikobewertung je Funktion oder Arbeitsschritt, die vorhersehbare Softwarefehler und ihre Prozesswirkung beschreibt. Bei einfachen Anwendungen mit nur einem Einsatzzweck kann nach der FDA-Guidance eine Bewertung auf Systemebene genügen. Aus dem Ergebnis leiten Sie die passenden Assurance-Aktivitäten ab.

Schritt 2: Anforderungen aus dem Arbeitsablauf ableiten

Beschreiben Sie Anforderungen am vorgesehenen Arbeitsablauf. Welche Aufgabe muss der Benutzer sicher abschließen können? Welche Eingaben braucht er, welches Ergebnis entsteht und was muss bei einem Fehler geschehen? Eine reine Feature-Liste lässt diese Zusammenhänge häufig offen.

Eine solche Anforderung lässt sich leichter in einen prüfbaren Fall übersetzen. Bei einer Freigabefunktion gehören etwa Zuständigkeit, zulässiger Ausgangsstatus, Ergebnis und unzulässige Bedienwege zusammen. Stimmen Fachbereich und Quality diese Punkte früh ab, werden Unklarheiten vor der Testausführung sichtbar.

Schritt 3: Gestaffelte Testtiefe nach Risiko

Wählen Sie den Prüfansatz passend zum bewerteten Risiko und zum Prüfziel. Die FDA-Guidance behandelt vorgegebene Testabläufe, Prüfungen ohne vollständig vorab festgelegte Einzelschritte und Kombinationen daraus. Sie ordnet diese Methoden nicht ausschließlich einer Risikokategorie zu. Auch bei hohem Prozessrisiko kann eine geeignete Prüfung ohne vollständiges Skript Teil des Nachweises sein.

Für Ihr Team heißt das: Beschreiben Sie, was die Prüfung zeigen soll und warum die gewählte Ausführung dafür geeignet ist. Ein gezielter Fehlerversuch kann eine andere Schwäche aufdecken als das Wiederholen eines vorhersehbaren Normalfalls. Halten Sie Ergebnis, Befunde und ihre Behandlung so fest, dass ein fachkundiger Reviewer die Schlussfolgerung nachvollziehen kann.

Eine bestimmte Methode garantiert weder weniger Aufwand noch eine feste Einsparung. Der praktische Effekt ergibt sich aus dem Einsatz, dem Systemstand, geeigneten vorhandenen Nachweisen und den noch offenen Fragen.

Schritt 4: Lieferantennachweise nutzen

Ein Lieferantenzertifikat beantwortet noch nicht, welche Ihrer Anforderungen tatsächlich geprüft sind. Ordnen Sie die vorhandenen Unterlagen dem vorgesehenen Einsatz zu. Für die praktische Bewertung nutzen wir folgende Fragen:

  • Wie wurde die Eignung des Lieferanten im anwendbaren Qualitätssystem beurteilt?
  • Welche eigene Anforderung und Softwareversion deckt der Beleg ab?
  • Welche Risiken und Funktionen wurden tatsächlich geprüft?
  • Wie werden spätere Lieferantenänderungen mitgeteilt und bewertet?
  • Wie lässt sich der Beleg der eigenen Anforderung und Risikoentscheidung zuordnen?
  • Welche Einschränkungen bestehen und welche eigenen Prüfungen fehlen?

Passende Lieferantennachweise können eigene Assurance-Aktivitäten ergänzen oder deren Umfang beeinflussen. Was sie abdecken und welche eigenen Nachweise verbleiben, muss nachvollziehbar sein. Die Verantwortung für die Eignungsbewertung bleibt beim regulierten Hersteller.

Schritt 5: Änderungen im Betrieb bewerten

Legen Sie fest, wie der geeignete Zustand im Betrieb erhalten wird und wann Einsatz, Risiken und Nachweise erneut zu bewerten sind. Berücksichtigen Sie Änderungen und Erkenntnisse aus dem Betrieb. Regelmäßige Überprüfungen und ihr Umfang werden im jeweils anwendbaren Qualitätsrahmen und anhand des Prozess- und Systemrisikos festgelegt.

Bei Patches, Updates oder neuen Integrationen bewerten Sie die Auswirkungen und bestimmen den erforderlichen Nachweisbedarf. Ein eng begrenzter Eingriff kann anders behandelt werden als eine wesentliche Prozessänderung. Ob wenige gezielte Prüfungen ausreichen oder umfangreichere Nachweise nötig sind, entscheidet die konkrete Bewertung.

Wer bewertet, prüft und entscheidet?

Vereinbaren Sie mit IT, QA und Fachbereich, wie Risiken beschrieben und Nachweise bewertet werden. Der Fachbereich erklärt die Verwendung, IT die technischen Abläufe, und die zuständigen Qualitätsverantwortlichen bringen die Anforderungen des Qualitätssystems ein. Lieferantenunterlagen müssen für diese Bewertung verständlich und zuordenbar sein.

Klären Sie an einem konkreten Fall auch die Entscheidungsbefugnisse: Wer darf verbleibende Risiken akzeptieren, wer bewertet eine Testabweichung und wer entscheidet über die Nutzung? Ein kurzer gemeinsamer Durchlauf deckt widersprüchliche Erwartungen häufig früher auf als die Überarbeitung zahlreicher Vorlagen.

Drei häufige Missverständnisse — und wie Sie sie vermeiden

Missverständnis 1: „CSA bedeutet weniger Tests.“

Die Anzahl der Tests ist kein ausreichendes Maß für die Absicherung. Begründen Sie die Auswahl am Risiko und prüfen Sie, ob die entscheidenden Fehler erkannt werden können. Eine geringere Menge an Dokumenten darf keine Lücke im Nachweis verdecken.

Missverständnis 2: „CSA ersetzt CSV.“

CSA ersetzt den Nachweis der Eignung für den Intended Use nicht. Für Software in der Medizinprodukteproduktion und im zugehörigen Qualitätsmanagementsystem beschreibt sie die risikobasierte Auswahl von Prüfungen und Nachweisen. Pharmazeutische GMP-, GCP-, GLP- oder GDP-Systeme außerhalb dieses Scopes folgen weiterhin ihren anwendbaren CSV- und GxP-Anforderungen.

Missverständnis 3: „Außerhalb des FDA-Scopes sind CSA-Methoden bedeutungslos.“

Die FDA-Guidance hat einen definierten US-regulatorischen Scope. Europäische GxP-Regelwerke und die GAMP 5 Second Edition unterstützen ebenfalls risikobasiertes Vorgehen, daraus entsteht aber keine unmittelbare CSA-Pflicht für DACH-Pharma. Methodische Übernahmen müssen im jeweils anwendbaren Rahmen begründet werden.

Was Sie als IT-Leiter konkret tun können

Für den Einstieg bietet sich folgende Reihenfolge an:

  1. Mit einem bestehenden System beginnen: Prüfen Sie die aktuelle Risikobewertung und vorhandene Nachweise. Halten Sie fest, welche Fragen für die nächste Änderung oder den nächsten Review offen sind. Eine heutige Bewertung ersetzt keine fehlenden historischen Belege.
  1. Nächster Projektzyklus: Modernisieren Sie die URS für das nächste Validierungsprojekt und verbinden Sie Anforderungen direkt mit Intended Use und Prozessrisiko.
  1. Portfolio-Rollout: Bauen Sie Kompetenz und Governance auf. IT, QA, Fachbereich und Lieferanten benötigen einen gemeinsamen Bewertungsstandard, klare Rollen und definierte Change Controls. Für die konkrete Umsetzung im Portfolio ist unsere CSV-Beratung der passende Rahmen.

Häufige Fragen zur Umsetzung von CSA

Richtet sich die FDA-CSA-Guidance an alle GxP-Systeme?

Nein. Ihr unmittelbarer Gegenstand ist Software in der Medizinprodukteproduktion und im zugehörigen Qualitätsmanagementsystem. Der Produktname oder eine allgemeine Einstufung als hoch oder niedrig kritisch erweitert diesen Scope nicht. Andere GxP-Systeme können geeignete risikobasierte Methoden im jeweils anwendbaren Rahmen nutzen. Daraus entsteht keine allgemeine FDA-CSA-Pflicht.

Wie steht CSA zur GAMP 5 Second Edition?

GAMP 5 Second Edition bietet einen risikobasierten Branchenrahmen für GxP-Computersysteme. Die FDA-CSA-Guidance behandelt ihren definierten Medizinprodukte-Scope. Beide können die Planung unterstützen; ordnen Sie die jeweiligen Empfehlungen dem konkreten Einsatz und den anwendbaren Anforderungen zu, statt sie als austauschbare Regelwerke zu behandeln.

Was kostet die Umstellung auf CSA?

Planungsrelevant sind vor allem der aktuelle Verfahrensstand, die Zahl betroffener Systeme, verfügbare Nachweise und die benötigte Schulung. Beginnen Sie mit einem abgegrenzten Anwendungsfall: Bewerten Sie Anforderungen, Prüfstrategie und Reviewaufwand, bevor Sie eine Umstellung des ganzen Portfolios kalkulieren. Wie ein solcher gemeinsamer Einstieg vorbereitet werden kann, beschreibt der Leitfaden zur Planung eines CSA-Workshops.

Regulatorische und fachliche Quellen

Quellenabgleich am 18. Oktober 2026: FDA-CSA-Guidance vom 3. Februar 2026 zu Anwendungsbereich, Prozessrisiko und Prüfmethoden. Redaktionell überarbeitet am 18. Oktober 2026.

Autor

Daniel Herrmann, Daniel Herrmann Consulting. Wir begleiten Unternehmen der Life Sciences bei GxP-Compliance und Computer System Validation. 17+ Jahre Erfahrung. 60+ validierte Systeme. 100 % Audit-Bestehensquote. 0 kritische Findings.

Sie möchten CSA für einen konkreten Einsatz prüfen?

Im kostenfreien telefonischen Erstgespräch besprechen wir in 15 Minuten Ihren Anwendungsfall, den aktuellen Nachweisstand und einen sinnvollen nächsten Arbeitsschritt.

Erstgespräch vereinbaren

Praxis & Zusammenarbeit

Den Prüfansatz an vorhersehbaren Fehlern ausrichten

Für den Einstieg in CSA wählen wir mit Fachbereich und Qualitätsverantwortlichen eine konkrete Softwareaufgabe. Wir klären den Anwendungsbereich, beschreiben mögliche Fehlerfolgen und vergleichen vorhandene Belege mit den noch offenen Prüfzielen. Manchmal ergibt sich daraus nur eine gezieltere Prüfung für die nächste Änderung. Soll die Arbeitsweise eines ganzen Teams weiterentwickelt werden, nehmen wir zusätzlich Anforderungen, Vorlagen und Entscheidungswege auf. Die gewählte Methode muss zum tatsächlichen Einsatz passen; aus dem Namen CSA leiten wir keine pauschale Einsparung ab.