CSA-Methodik: Risk-Based Validation in 5 Schritten erklärt

Computer Software Assurance (CSA) ist der risikobasierte Assurance-Ansatz der finalen FDA-Guidance für Software in der Medizinprodukteproduktion und in Quality Management Systems. Fünf Schritte strukturieren die Umsetzung: Anwendbarkeit, Risikobewertung, Use-Case-Zentrierung, angemessene Assurance-Aktivitäten und Lifecycle-Governance. 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 ein DHC-Praxis-Modell für die Umsetzung. Sie sind keine wörtliche Fünf-Schritte-Vorgabe der FDA.

Ihr Team validiert ein neues System nach einem etablierten CSV-Framework. Alle Funktionen werden ähnlich tief getestet, die Dokumentation wächst, das Go-Live-Datum rückt nach hinten. Im Steering wird gefragt, warum es nicht schneller geht — obwohl jeder im Raum weiß, dass ein großer Teil der Tests auf Funktionen entfällt, die niemand kritisch nutzt.

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.

Was CSA wirklich ist (und was nicht)

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.

Moderne CSA-Ansätze ermöglichen es, Test-Aufwand und Dokumentation stärker auf risikorelevante Funktionen zu fokussieren. Statt jedes Feature gleich tief zu dokumentieren, jeden Workflow zu testen und jede Konfiguration zu belegen, lenkt CSA Aufmerksamkeit gezielt dorthin, wo Risiko entsteht. So entstehen schlankere Validierungs-Pakete — und Teams gewinnen Zeit für risikoorientiertes Denken.

CSA dreht die Logik um. Die Frage lautet nicht mehr „Was müssen wir alles testen?”, sondern „Wo kann ein Fehler echten Schaden verursachen — und wie reduzieren wir genau dieses Risiko?”.

Legacy-CSV-Umsetzung vs. moderner CSA-Ansatz

Aspekt	Legacy-CSV-Umsetzung	Moderner CSA-Ansatz
Test-Strategie	Volltestung aller Funktionen	Risikobasiert: Fokus auf hohes Risiko
Dokumentations-Output	oft template- und mengengetrieben	angemessen und risikobegründet
Vendor-Hebel	eigene Tests dominant	Vendor Evidence strukturiert eingebunden
Tempo	durch Volltestung gebremst	durch passende Assurance-Aktivitäten fokussiert
Mindset	Dokumentation first	Prozessrisiko und Intended Use first
FDA-/Guidance-Bezug	anerkannt, aber oft dokumentationslastig umgesetzt	von der CSA-Guidance gestützt
Audit-Belastbarkeit	branchenüblich	gleich oder besser bei durchgängig risikobasierter Umsetzung

Die 5 Schritte der CSA-Methodik

Schritt 1: Risikobewertung vor Test-Skript

Vor jedem Test steht die Frage: Was kann fehlgehen, wie wahrscheinlich ist es, wie schwerwiegend wäre es?

Die Bewertung erfolgt nach ICH Q9 — strukturiert, dokumentiert, nachvollziehbar. Jede Funktion erhält eine Risiko-Klassifikation: hoch, mittel, niedrig. Diese Klassifikation steuert ab sofort jeden weiteren Schritt.

Praktischer Output: Eine Risiko-Matrix pro System, die vorhersehbare Softwarefehler und ihren Einfluss auf den Prozess bewertet. Hochrisiko-Funktionen erhalten eine tiefere, nachvollziehbar begründete Assurance.

Schritt 2: Use-Case-zentrierte Anforderungen

User Requirements Specifications (URS) werden in CSA nicht mehr als reine Feature-Liste geschrieben. Stattdessen beschreiben sie die kritischen User-Journeys: Welche Aufgaben muss der Nutzer im Alltag erfolgreich abschließen — und welche Fehler dürfen dabei nicht passieren?

Das schärft die URS in zwei Richtungen. Erstens: Sie wird kürzer und präziser. Zweitens: Sie liefert direkt die Testfälle, die später benötigt werden. In unseren Projekten reduziert eine gut geschriebene URS den späteren Validierungsaufwand spürbar.

Schritt 3: Gestaffelte Testtiefe nach Risiko

Statt jede Funktion mit dokumentierten Test-Skripten zu prüfen, wird die Testtiefe an das Risiko angepasst:

• High Risk: Ausführliche, dokumentierte Test-Skripte mit nachvollziehbarer Evidenz
• Medium Risk: Stichproben-Testung, ergänzt durch Vendor Evidence und dokumentierte Risikobegründung
• Low Risk: Reduzierte Testtiefe — abhängig von Intended Use, qualifiziertem Lieferantenstatus, GxP-Kritikalität und dokumentierter Risikobegründung. Eine Hersteller-Erklärung allein reicht nicht; die Bewertung muss begründet und nachvollziehbar sein.

Dieser Schritt erzeugt den zentralen Effizienzhebel. Der tatsächliche Effekt hängt von Intended Use, Prozessrisiko, Systemkomplexität und verwertbarer Lieferantenevidenz ab und wird nicht pauschal zugesagt.

Schritt 4: Vendor Evidence sauber strukturieren

Vendor Evidence ist mehr als „ISO-Zertifikat akzeptieren”. Die FDA-Guidance erlaubt es, Lieferanten-Verantwortung als Teil der Validierungs-Evidenz zu nutzen — aber nur unter klaren Voraussetzungen:

• Lieferantenqualifizierung: Der Lieferant ist nach GxP-Kriterien bewertet und freigegeben
• Intended Use definiert: Was wird vom System erwartet, in welchem regulatorischen Kontext?
• GxP-Kritikalität klassifiziert: Welche regulatorische Bedeutung hat die jeweilige Funktion?
• Change Control vereinbart: Wie wird mit Lieferanten-Updates umgegangen?
• Traceability gesichert: Vendor Evidence ist eindeutig zur eigenen Risikobewertung verknüpft
• Evidenz-Bewertung dokumentiert: Hersteller-Tests werden nicht ungeprüft übernommen, sondern bewertet

Mit diesem Setup können qualifizierte Lieferantennachweise eigene Assurance-Aktivitäten gezielt ergänzen oder reduzieren. Die Verantwortung für die Eignungsbewertung bleibt beim Hersteller.

Schritt 5: Kontinuierliche Anpassung im Lifecycle

CSA ist kein einmaliger Setup-Akt vor dem Go-Live. Nach Go-Live werden Risikobewertungen in festgelegten Intervallen und bei wesentlichen Änderungen überprüft. Das Intervall folgt dem jeweiligen Prozess- und Systemrisiko.

Bei Patches, Updates oder neuen Integrations-Punkten wird das Risiko-Profil neu bewertet, nicht das gesamte System neu validiert. Das hält den laufenden Validierungs-Aufwand niedrig und sichert gleichzeitig die kontinuierliche Compliance.

Governance: Die unsichtbare Voraussetzung

CSA funktioniert nur, wenn IT, QA, Fachbereich und Lieferant dieselbe Risiko-Logik verwenden. Eine isolierte Methodik-Umstellung in der IT-Abteilung greift nicht — die Risiko-Bewertung muss als gemeinsamer Bewertungsstandard zwischen allen Stakeholdern verankert werden.

Praktisch bedeutet das: Ein gemeinsamer Risk-Assessment-Standard, klare Schnittstellen-Vereinbarungen, ein abgestimmtes Change-Management und regelmäßige Stakeholder-Reviews. Wo dieser Konsens fehlt, produziert CSA Reibungsverluste statt Effizienz.

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

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

CSA bedeutet gezieltere Tests. Bei hochrisiko-relevanten Funktionen wird sogar tiefer getestet — weil die Aufmerksamkeit gezielt dort konzentriert wird. Wer CSA als Spar-Programm interpretiert, produziert genau die Audit-Findings, die der Ansatz verhindern soll.

Missverständnis 2: „CSA ersetzt CSV.”

CSA ersetzt den Nachweis der Eignung für den Intended Use nicht. Sie beschreibt im direkten Medizinprodukteproduktion-/QMS-Scope, wie Assurance-Aktivitäten und Records risikobasiert gewählt werden. Pharmazeutische GMP-, GCP-, GLP- oder GDP-Systeme außerhalb dieses Scopes folgen weiterhin ihren anwendbaren CSV- und GxP-Anforderungen.

Missverständnis 3: „CSA gilt nur für den FDA-Markt.”

Die FDA-Guidance hat einen definierten US-regulatorischen Scope. Europäische GxP-Regelwerke und GAMP 5 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

Drei Hebel, in dieser Reihenfolge:

1. Erster Hebel: Eine retrospektive Risikobewertung eines aktiv validierten Systems. Sie zeigt, welche Assurance-Aktivitäten im nächsten Zyklus neu begründet werden müssen.

2. Nächster Projektzyklus: Modernisieren Sie die URS für das nächste Validierungsprojekt und verbinden Sie Anforderungen direkt mit Intended Use und Prozessrisiko.

3. Portfolio-Rollout: Bauen Sie Kompetenz und Governance auf. IT, QA, Fachbereich und Lieferanten benötigen einen gemeinsamen Bewertungsstandard, klare Rollen und definierte Change Controls.

Häufige Fragen

Eignet sich CSA für alle GxP-Systeme?

Nein. Direkte Anwendbarkeit hängt nicht von „hoch” oder „niedrig” kritisch und nicht vom Produktnamen ab. Entscheidend ist, ob das System in der Medizinprodukteproduktion oder im Quality Management System eingesetzt wird. Andere GxP-Systeme können geeignete risikobasierte Methoden nutzen, ohne dadurch in den FDA-CSA-Scope zu fallen.

Wie steht CSA zur GAMP 5 Second Edition?

Sehr gut kompatibel. GAMP 5 Second Edition stützt risikobasierte Validierung methodisch und ist mit der CSA-Logik gut vereinbar. Beide Frameworks lassen sich ohne Konflikt parallel anwenden.

Was kostet die Umstellung auf CSA?

Der Aufwand hängt vom Reifegrad Ihrer aktuellen Validierungs-Praxis ab. Ein Strategiegespräch klärt in 30 Minuten, wo Ihr aktuelles Validierungs-Setup steht und welche CSA-Hebel realistisch sind.

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)
• ICH: Q9(R1) Quality Risk Management, Step 4
• Europäische Kommission: EU-GMP Annex 11 — Computerised Systems
• eCFR: 21 CFR Part 11 — Electronic Records; Electronic Signatures

---

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.