Computer Software Assurance
Computer Software Assurance, kurz CSA, wird häufig als Ersatz für Computer System Validation dargestellt. Das ist zu einfach. Die finale FDA-Guidance vom 3. Februar 2026 beschreibt CSA als risikobasierten Ansatz, um Vertrauen darin aufzubauen und zu erhalten, dass Produktions- und QMS-Software für ihren Intended Use geeignet ist. Die Validierungspflicht verschwindet dadurch nicht. Der Fokus verschiebt sich auf angemessene Assurance statt maximaler Dokumentation.
Dynamics 365 Validierung bei AENUMA · GAMP 5 bei Dynamics 365
Die FDA hat am 3. Februar 2026 ihre finale Guidance „Computer Software Assurance for Production and Quality Management System Software“ veröffentlicht. Sie ersetzt die im September 2025 veröffentlichte Fassung und berücksichtigt den seit 2. Februar 2026 wirksamen Quality Management System Regulation-Rahmen, der ISO 13485:2016 in 21 CFR Part 820 einbezieht.
Für Hersteller mit FDA-Bezug ist das deshalb keine theoretische Diskussion. Die Guidance beschreibt den aktuellen FDA-Blick darauf, wie Software in Produktion und Qualitätsmanagement risikobasiert abgesichert werden kann.
Die FDA beschreibt CSA ausdrücklich als einen risikobasierten Ansatz, um Vertrauen in die Eignung der Software für ihren Intended Use herzustellen und über den Lebenszyklus aufrechtzuerhalten. Der Unterschied liegt also nicht zwischen „validieren“ und „nicht validieren“.
Der Unterschied liegt in der Frage, wie viel Assurance für welches Risiko angemessen ist und welche Aktivitäten dafür den besten Nachweis liefern.
| Klassischer Fehlansatz | CSA-orientierter Ansatz |
|---|---|
| Jede Funktion gleich tief testen | Test- und Assurance-Tiefe aus Risiko ableiten |
| Dokumentmenge als Qualitätsmerkmal | Objektive Evidenz mit klarem Zweck |
| Nur geskriptete Tests akzeptieren | Auch geeignete unscripted und exploratory Methoden nutzen |
| Lieferantentests ignorieren | Nachweise von Entwicklern, Lieferanten und Cloud-Anbietern risikobasiert nutzen |
| Validierung endet mit Go-live | Validierten Zustand über den Lebenszyklus erhalten |
Die FDA stellt die Identifikation des Intended Use an den Anfang ihres CSA Risk Frameworks. Zuerst wird geklärt, ob die Software direkt für Produktion oder QMS eingesetzt wird, diese Prozesse unterstützt oder nur allgemeine Geschäftsprozesse abbildet.
Für Dynamics 365 ist diese Unterscheidung besonders hilfreich. Ein Accounting-Prozess kann außerhalb des relevanten Scopes liegen, während dieselbe Plattform gleichzeitig Chargenfreigaben, Qualitätsprüfungen oder Reklamationsdaten steuert.
Vertiefung: Intended Use für Dynamics 365
Die FDA richtet die Assurance-Tiefe daran aus, welches Risiko für Sicherheit oder Qualität entstehen kann, wenn die Software nicht wie vorgesehen funktioniert. Je höher dieses Risiko, desto mehr Rigor kann angemessen sein.
Das bedeutet nicht, nur die Wahrscheinlichkeit eines Softwarefehlers zu betrachten. Entscheidend ist die mögliche Auswirkung des Fehlers auf den Herstellprozess, das QMS und letztlich die Qualität beziehungsweise Sicherheit des Medizinprodukts.
Ein besonders relevanter Punkt der CSA-Guidance ist die Offenheit für unterschiedliche Assurance-Methoden. Neben klassischen geskripteten Tests können je nach Risiko beispielsweise exploratory oder andere weniger stark geskriptete Testansätze sinnvoll sein.
Das ist kein Freibrief für informelles „Durchklicken“. Auch ein unscripted Test braucht einen definierten Zweck, qualifizierte Personen, ein nachvollziehbares Ergebnis und angemessene Evidenz. Der Unterschied ist, dass nicht jede Beobachtung vorab in einem umfangreichen Schritt-für-Schritt-Skript beschrieben werden muss.
Die FDA schließt Cloud-Modelle ausdrücklich in den Scope ihrer Guidance ein, wenn sie als Teil von Produktion oder QMS eingesetzt werden. Gleichzeitig erlaubt der CSA-Ansatz, Assurance-Aktivitäten anderer Parteien wie Entwickler, Lieferanten oder Cloud Service Provider risikobasiert zu berücksichtigen.
Für Dynamics 365 ist das zentral: Microsoft verantwortet und testet einen großen Teil der Plattform. Der Hersteller muss nicht so tun, als hätte er die Standardsoftware selbst entwickelt. Er muss aber verstehen, welche Verantwortung bei Microsoft liegt und welche bei ihm selbst verbleibt: Konfiguration, Rollen, Daten, Schnittstellen, Erweiterungen und der konkrete Intended Use.
GAMP 5 verfolgt ebenfalls einen risikobasierten Lebenszyklusansatz und betont die Eignung für den vorgesehenen Zweck. Deshalb ist CSA nicht der Gegenentwurf zu GAMP. Für Unternehmen mit EU- und FDA-Anforderungen können beide Ansätze in einer gemeinsamen Validierungsstrategie zusammengeführt werden.
Wichtig ist die regulatorische Einordnung: CSA ist eine FDA-Guidance. Sie ersetzt nicht ISO 13485, ISO/TR 80002-2, das eigene QMS oder andere anwendbare Anforderungen.
Ein Hersteller nutzt Supply Chain Management, um eingehende Materialchargen zu prüfen und bis zur Freigabe zu blockieren. Ein Fehler könnte dazu führen, dass nicht freigegebenes Material in der Produktion verwendet wird. Hier ist ein höheres Assurance-Niveau sinnvoll: klare Anforderungen, Risikobewertung, negative Tests, Rollenprüfung und nachvollziehbare Freigabe.
Ein anderer Teil derselben Lösung erzeugt einen internen Bericht ohne Einfluss auf Produktion oder QMS. Dort kann die Assurance deutlich schlanker ausfallen.
CSA bedeutet nicht dokumentationsfrei. Die FDA spricht von einem angemessenen Record der durchgeführten Assurance-Aktivitäten. Für ein Dynamics-Projekt sollten mindestens die relevanten Entscheidungen nachvollziehbar bleiben:
Die Dokumentation sollte Evidenz sichern, nicht Beschäftigung erzeugen.
Ein Unternehmen muss nicht sein gesamtes QMS umbenennen. Sinnvoller ist eine inhaltliche Prüfung: Fordert das Verfahren unnötig dieselbe Test- und Dokumentationstiefe für jede Software? Nutzt es Lieferantennachweise? Erlaubt es risikobasierte Methoden? Berücksichtigt es Cloud-Software und kontinuierliche Änderungen?
Wenn das bestehende CSV-Verfahren diese Prinzipien bereits abbildet, ist der Abstand zu CSA häufig kleiner als die Begriffsdiskussion vermuten lässt.
Hat die FDA CSV abgeschafft?
Nein. Die FDA beschreibt CSA als risikobasierten Ansatz für die Assurance und Validierung von Produktions- und QMS-Software. Die Verpflichtung, relevante Software für ihren Intended Use abzusichern, bleibt bestehen.
Gilt CSA auch in Deutschland?
CSA ist FDA-Guidance und damit besonders für Hersteller mit US-/FDA-Bezug relevant. Für EU- und deutsche Anforderungen müssen die jeweils anwendbaren Normen, regulatorischen Vorgaben und das eigene QMS betrachtet werden.
Darf man mit CSA weniger testen?
Der Testaufwand darf geringer sein, wenn das Risiko dies rechtfertigt und andere Assurance-Aktivitäten ausreichendes Vertrauen schaffen. Für kritische Funktionen kann dagegen hohe Testtiefe erforderlich bleiben.
Ist exploratory testing jetzt immer ausreichend?
Nein. Die Methode muss zum Risiko und zur Funktion passen. Für kritische oder komplexe Kontrollen können geskriptete Tests weiterhin sinnvoll oder notwendig sein.
Der relevante Wandel ist nicht von CSV zu CSA als neues Etikett. Er ist der Wechsel von dokumentengetriebener Validierung zu begründeter, risikobasierter Assurance. Für moderne SaaS-Plattformen wie Dynamics 365 ist das ein deutlich praktikableres Betriebsmodell.
Nächster Schritt: Validation Health Check oder Dynamics 365 Validierung.
Weiterlesen: Validierungsplan für Dynamics 365
Weiterlesen: Revalidierung bei Updates
Weitere Beiträge zu Validierung und Assurance
FDA: Computer Software Assurance, Final Guidance, 3. Februar 2026
ISO: ISO/TR 80002-2:2017
Stand: 17. August 2026. Organisatorische und technische Einordnung, keine rechtliche Einzelfallprüfung.
