Software-Risikomanagement nach ISO 14971 & IEC 62304
So identifizieren, bewerten und dokumentieren Sie Software-Risiken normgerecht
Kontakt aufnehmenWarum Software-Risikomanagement so entscheidend ist
Softwarefehler gehören zu den häufigsten Ursachen für sicherheitsrelevante Zwischenfälle bei Medizinprodukten. Die IEC 62304 und die ISO 14971 definieren deshalb klare Anforderungen an das Risikomanagement über den gesamten Software-Lebenszyklus.
Ziel ist nicht nur die Vermeidung von Abstürzen, sondern die systematische Beherrschung aller Gefährdungssituationen, die durch Softwarefunktionen, Fehlbedienungen oder unerwartete Zustände entstehen.
Grundlagen zur Dokumentation finden Sie in unserer Einführung in die Softwaredokumentation.
Wie ISO 14971 und IEC 62304 zusammenwirken
Beide Normen müssen gemeinsam umgesetzt werden:
- ISO 14971: beschreibt das allgemeine Risikomanagement für Medizinprodukte.
- IEC 62304: beschreibt, wie Risiken speziell im Softwarekontext behandelt werden müssen.
IEC 62304 baut auf ISO 14971 auf – und ergänzt sie um spezifische Softwareanforderungen wie:
- Analyse softwarebedingter Gefährdungen
- Fehlerauswirkungen auf das Gesamtsystem
- Risikokontrollen in Softwarearchitektur und -design
- Verifikation der Risikokontrollmaßnahmen
- Traceability von Risiken zu Anforderungen & Tests
Eine vollständige Anleitung zur Norm finden Sie in unserer IEC-62304-Schritt-für-Schritt-Anleitung.
Der Software-Risikomanagementprozess im Überblick
Der Prozess folgt einem klaren Muster, das für alle Softwareklassen (A, B, C) gilt – mit steigendem Dokumentationsaufwand für höhere Klassen.
1. Gefährdungen identifizieren
Beispiele für softwarebezogene Gefährdungen:
- falsche Berechnungen oder Ergebnisse
- nicht erkennbare Fehlerzustände
- UI-Fehlbedienungen durch unklare Texte oder Symbole
- Deadlocks, Abstürze, Speicherfehler
- fehlende oder fehlerhafte Warnhinweise
- inkorrekte Kommunikation mit Hardware oder Netzwerken
2. Risikoanalyse (ISO 14971)
Für jede Gefährdung wird bewertet:
- Schweregrad
- Auftretenswahrscheinlichkeit
- Erkennbarkeit
Die Kombination ergibt das Gesamtrisiko – Grundlage für Risikokontrollen.
3. Risikokontrollmaßnahmen festlegen
Typische softwarebezogene Maßnahmen:
- Validierungslogiken & Plausibilitätsprüfungen
- Fallback-Zustände & sichere Defaults
- Zweitprüfungen (Double Checks)
- UI-Texte & Fehlermeldungen
- redundante Berechnungen
- Testabdeckung kritischer Pfade
4. Risikokontrollen implementieren & dokumentieren
Die IEC 62304 verlangt, dass Maßnahmen während Design, Implementierung und Tests sichtbar werden:
- Designbeschreibung mit sicherheitsrelevanten Entscheidungen
- Softwarearchitektur mit Risikozuordnung
- Testfälle, die Kontrollen explizit verifizieren
- Traceability: Risiko → Maßnahme → Testnachweis
5. Restrisiko bewerten
Nach Umsetzung der Maßnahmen muss das Restrisiko akzeptabel sein – gemäß ISO 14971.
6. Risikoüberwachung & Änderungen
- Bewertung von Softwareupdates (Impact Analysis)
- Überwachung im Feld (PMS / PMCF)
- Analyse von Fehlermeldungen und Supportanfragen
Typische Fehler im Software-Risikomanagement
- Risiken werden nicht software-spezifisch betrachtet → Analyse bleibt zu allgemein.
- Traceability fehlt → Risiko nicht zu Design oder Test verknüpft.
- UI-Fehler werden nicht als Risiken eingestuft → Inkonsistenz mit IEC 62366-1.
- Risikokontrollen sind nicht dokumentiert → Auditabweichungen.
- Implementierung und Risikoakte passen nicht zusammen.
- Softwareupdates werden nicht risikobasiert bewertet.
Weitere kritische Fehler erläutern wir auf unserer Seite Typische Fehler in Softwaredokumentationen.
Best Practices für erfolgreiches Software-Risikomanagement
- Risikoakte früh starten – ideal ab der ersten Funktionsdefinition.
- Risikoreview in jedem Sprint (bei agiler Entwicklung).
- UI-Texte, Warnhinweise & Fehlermeldungen integrieren (IEC 62366-1).
- Traceability mit automatisierten Tools oder klaren Tabellen sicherstellen.
- PRAXIS: Architektur zuerst, Risiko danach, Tests zum Schluss verknüpfen.
- Änderungsmanagement konsequent durchführen → Impact Analysis.
Eine praktische Schritt-für-Schritt-Struktur für die Dokumentation finden Sie in unserer Vorlage für Softwaredokumentation.