CSV (Computer System Validation) und CSA für vernetzte Systeme

Vernetzte Systeme bestehen aus Embedded Devices, Cloud-Services, Mobile Apps und Datenflüssen über mehrere Anbieter. CSV (Computer System Validation) und CSA (Computer Software Assurance) brauchen hier einen klaren Scope, der Datenintegrität absichert, ohne das komplette Ökosystem zu validieren.

Entscheidend sind belastbare Grenzen, Traceability über Komponenten hinweg und eine Teststrategie, die mit Änderungen skaliert.

TL;DR

Scope aus Intended Use und Risiko ableiten — nicht aus reinen Architekturdiagrammen.
Traceability von Anforderungen zu Risiken (ISO 14971) und Tests über alle Komponenten hinweg.
Gestufte Tests: Component, Integration und gezielte End-to-End-Nachweise für kritische Workflows.
Change Control mit Impact-Assessment und, wo relevant, IEC 62304-konformer Lifecycle-Evidenz.

CSA lebt von nachvollziehbaren Assurance-Levels. Wenn klar dokumentiert ist, warum Low-Risk-Funktionen nur geskriptete Checks brauchen und High-Risk-Workflows volle Protokolle, wird die Strategie auditierbar.

Warum das relevant ist

Regulatorisch stehen Datenintegrität und Software-Validierung im Fokus. FDA erwartet eine begründete CSV/CSA-Strategie; bei softwarekritischen Funktionen kann Evidenz auch in einer 510(k)-Einreichung referenziert werden. ISO 13485 verlangt versionierte, prüfbare Validierungsunterlagen.

Geschäftlich führt Overscoping zu langsamen Releases, während Underscoping Audit-Findings und ungeplante Revalidierungen auslöst.

Auch unter EU MDR erwarten Auditoren nachvollziehbare Datenflüsse und dokumentierte Validierungsgrenzen für vernetzte Systeme.

Je höher der Automatisierungsgrad, desto wichtiger sind klare Schnittstellen- und Datenverantwortlichkeiten.

Wie „gut“ aussieht

Gute CSV/CSA-Evidenz macht Scope und Risikoanbindung transparent.

Systemgrenzen klar dokumentiert: in-scope, supportend, out-of-scope mit Begründung.
Datenflüsse und Interfaces (APIs, Protokolle, Datenformate) unter Change Control.
Risikobasierte Tests, End-to-End nur für kritische Use Cases.
Vendor-Evidenz wird bewertet und begründet, nicht ungeprüft übernommen.
Lifecycle- und Change-Control-Evidenz gemäss IEC 62304, wenn Device-Software betroffen ist.

Zusätzlich hilft eine klare Klassifizierung der Datenpfade: welche Daten beeinflussen Produkt- oder Freigabeentscheidungen und welche sind rein informativ. Das steuert den Testumfang erheblich.

Evidenz-/Artefakt-Checkliste

Die Artefakte müssen Scope-Entscheide und objektive Testergebnisse belegen.

CSV/CSA-Plan mit Systemgrenzen, Intended Use und Validierungsstrategie.
Systeminventar mit versionierten Komponenten (Firmware, App, Backend).
Datenflussdiagramme und Interface-Spezifikationen mit Revisionen.
Risikoanalyse und Traceability-Matrix Anforderungen → Risiken → Tests.
Component-, Integration- und End-to-End-Testprotokolle und -berichte.
Nachweise für Audit Trail, Rollen/Berechtigungen und Datenintegrität.
Change-Impact-Assessments, Release Notes und Regressionstests.
Issue Log oder Punch List mit Abweichungen, Owner und Schliess-Evidenz.
CSA-Teststrategie mit begründeter Testtiefe je Risiko-Kategorie.
Monitoring- oder Trend-Checks, die Post-Release-Verhalten absichern.
Versionierte Testskripte und Ausführungslogs für automatisierte Checks.
Nachweise für Daten-Export, Retention und Backup/Restore.

Bei automatisierten Tests sollten Logs, Skriptversionen und Testdaten eindeutig referenziert sein, damit die Ergebnisse reproduzierbar bleiben.

Häufige Audit-/QA-Fragen

Was ist im Scope und was explizit ausserhalb — mit Begründung?
Wie wird Datenintegrität über Device, Cloud und App gesichert?
Welche Tests sind Component vs Integration vs End-to-End?
Wie werden Vendor-Änderungen bewertet und dokumentiert?
Wo ist die Evidenz, dass Versionen und Interfaces kontrolliert sind?

Diese Fragen lassen sich oft in einem kurzen Scope-Workshop und einer aktualisierten Traceability-Matrix beantworten.

Typische Fehlermodi

Scope wird von Architektur abgeleitet, nicht von Intended Use und Risiko.
Traceability endet auf Komponentenebene, Integrationsrisiken bleiben offen.
End-to-End-Tests sind zu breit und erzeugen Retest-Last bei jedem Release.
Vendor-Evidenz wird ohne Bewertung akzeptiert.
Change-Control-Daten passen nicht zu den getesteten Versionen.
Automatisierte Tests laufen, aber die Ausführungslogs fehlen.

Viele Findings entstehen, weil Scope-Entscheide nicht dokumentiert sind und später nicht nachvollzogen werden können.

Wann Unterstützung sinnvoll ist

Wenn Scope unklar ist oder Updates immer Full Retests auslösen, hilft eine fokussierte CSV/CSA-Strategie. Ein kurzer Scope-Check deckt oft die grössten Hebel auf. Für einen risikobasierten Validierungsplan Kontakt aufnehmen.