Stufe 5 – Reguliert / Audit-ready

Ziel: Externe Prüf- und Zulassungsfähigkeit.

Stufe 5 ist keine Optimierung von Stufe 4.
Sie entsteht nicht aus Ambition – sondern aus regulatorischer Notwendigkeit.

Hier genügt es nicht, kontrolliert zu arbeiten.
Man muss es extern beweisen können.

Qualität ist hier Zulassungsvoraussetzung.

---

Abgrenzung

	Stufe 4	Stufe 5
Governance	intern formalisiert	extern prüfbar
Traceability	vollständig	regulatorisch validiert
Security	systematisch	vorgeschrieben
Freigabe	CAB / interne Kontrolle	ggf. externe Zulassung

Stufe 5 bedeutet:
Das System unterliegt externen Normen, Gesetzen oder Zertifizierungen.

---

Typische Einsatzfälle

• Medizintechnik-Software (z. B. IEC 62304)
• Luftfahrt- oder Bahnsoftware (z. B. DO-178C)
• Automotive Safety (ISO 26262)
• Zahlungs- oder Identitätssysteme mit regulatorischer Aufsicht

---

Kontextbedingungen

Faktor	Erwartung
Lebensdauer	≥ 5 Jahre
Risiko	Existenziell (Haftung, Lizenz, Sicherheit)
Compliance	Gesetzlich oder regulatorisch verpflichtend
Audit	Regelmäßig und extern
Verfügbarkeit	Sehr hoch (z. B. 99,99 %+ je nach Kontext)

---

Anforderungen

• Vollständige, versionierte Traceability
  (Requirement → Design → Code → Test → Release)
• Signierte Artefakte + unveränderbare Audit Trails
• Unabhängige V&V (Verifikation & Validierung)
• Formal definierte Rollen mit klarer Verantwortlichkeit
• Dokumentierte Risikoanalyse gemäß Norm

---

Teststrategie (Richtwerte)

• Unit: 90–95 % auf sicherheitskritischen Modulen
• Integration: ≥ 80 % der relevanten Schnittstellen
• E2E/Systemtests: Vollständig für alle regulatorisch relevanten Flows
• Testfälle sind normativ referenziert

Coverage ist sekundär – normkonforme Nachweisführung ist primär.

---

Minimale Gates

• Traceability-Matrix vollständig
• Anforderungen eindeutig versioniert
• Signierte Builds & Releases
• Segregation of Duties umgesetzt
• Unabhängige V&V dokumentiert
• Externe oder unabhängige Reviews durchgeführt
• Evidence-Paket pro Release archiviert
• Datenschutz- & Risikoanalyse (z. B. DPIA) aktuell

Ohne vollständige Nachweisführung ist Stufe 5 nicht erfüllt.

---

Praktiken

• Formale Anforderungsverwaltung mit IDs
• Normkonforme Risikoanalyse
• Strenge Change Control
• Immutable Logs und Artefakt-Historie
• Release-Definition enthält Audit-Readiness
• Dokumentierte Schulungen und Kompetenznachweise (falls gefordert)

---

Rollen

• Software Architect (formale Architektur)
• Tech Lead
• Test Engineer
• DevOps Engineer
• Security Engineer / AppSec (Pflicht)
• Optional: SRE

Unabhängige Prüfrollen dürfen nicht in direkter Delivery-Verantwortung stehen.

---

Wirtschaftlicher Kontext

Stufe 5 verursacht:

• Sehr hohen Prozess- und Dokumentationsaufwand
• Längere Release-Zyklen
• Hohe Eintrittsbarrieren für Änderungen

Sie reduziert jedoch:

• Zulassungsrisiko
• Haftungsrisiko
• Lizenz- oder Betriebsverlust
• Regulatorische Sanktionen

Stufe 5 ist wirtschaftlich nur sinnvoll,
wenn sie regulatorisch oder vertraglich erforderlich ist.

---

Akzeptierte Realität

• Geschwindigkeit ist zweitrangig
• Änderungen sind teuer
• Flexibilität ist eingeschränkt
• Organisation und Tooling müssen stabil sein

---

Quellen

• IEC 62304: Medical Device Software Lifecycle
• ISO 26262: Functional Safety (Automotive)
• IEC 61508: Functional Safety
• RTCA DO-178C: Airborne Systems
• FAA AC 20-115D