Stufe 4 – High Assurance
Ziel: Nachweisbare Sicherheit, Stabilität und Kontrollierbarkeit bei hohem Risiko.
Stufe 4 geht über „stabiler Betrieb“ hinaus.
Hier reicht es nicht mehr, gute Prozesse zu haben –
sie müssen reproduzierbar, prüfbar und belegbar sein.
Qualität ist hier nicht nur Ergebnis, sondern Nachweis.
Abgrenzung
| Stufe 3 | Stufe 4 | Stufe 5 | |
|---|---|---|---|
| Monitoring | SLO-basiert | Auditierbar dokumentiert | Reguliert |
| Releases | kontrolliert | formal freigegeben | extern prüfbar |
| Security | Threat Model (light) | systematische Risikoanalyse | regulatorisch vorgeschrieben |
| Traceability | teilweise | vollständig | formal validiert |
Stufe 4 ist die erste Stufe mit formaler Governance-Verantwortung.
Typische Einsatzfälle
- Finanzsysteme mit Compliance-Anforderungen
- Sicherheits- oder sicherheitsnahe Funktionen (Safety / Security)
- Plattformen mit strengen Verfügbarkeitszielen (99,9 %+)
- Systeme mit möglicher Auditpflicht
Kontextbedingungen
| Faktor | Erwartung |
|---|---|
| Lebensdauer | ≥ 2 Jahre |
| Risiko | Hoch bis kritisch |
| Governance | Formale Freigabeprozesse |
| Compliance | Audit-Anforderungen möglich |
| Änderungen | Dokumentierte Change Control |
Anforderungen
- Signierte Artefakte und auditable Pipelines
- Vollständige Traceability
(Anforderung → Ticket → Code → Test → Release) - Systematische Security Reviews
- Regelmäßige Pen-Tests
- Formale Freigabeprozesse (z. B. CAB)
Teststrategie (Richtwerte)
- Unit: 85–95 % auf kritischen Modulen
- Integration: ≥ 70 % der relevanten Schnittstellen
- E2E: Vollständige Abdeckung aller geschäftskritischen Flows
- Testfälle sind Anforderungen zugeordnet
Coverage allein ist nicht ausreichend –
Nachvollziehbarkeit ist entscheidend.
Minimale Gates
- Threat Model aktualisiert bei Major Changes
- Vollständige Traceability für Releases
- Signierte Builds & Releases
- SLOs definiert, gemessen und historisiert
- Incident Drills regelmäßig durchgeführt
- Access Reviews dokumentiert
- Audit Trails vorhanden
- E2E-Testfälle an Anforderungen gebunden
Stufe 4 verlangt formalisierte Kontrolle – nicht nur gute Praxis.
Praktiken
- Strenge Reviews inkl. Security Review
- Dokumentierte Change-Control-Prozesse
- Rollback- und Disaster-Recovery-Tests
- Runbooks regelmäßig validiert
- Blameless Post-Mortems mit Maßnahmen-Tracking
- Evidence-Pakete pro Release
Rollen
- Software Architect (Architektur-Integrität)
- Tech Lead (Delivery + Qualitätsbalance)
- Test Engineer (V&V)
- DevOps Engineer (auditable Pipelines)
- Security Engineer / AppSec (Risikosteuerung)
Governance-Verantwortung muss explizit zugewiesen sein.
Wirtschaftlicher Kontext
Stufe 4 erhöht:
- Prozesskosten
- Dokumentationsaufwand
- Time-to-Market
Sie reduziert jedoch:
- Haftungsrisiken
- Audit-Risiken
- Sicherheitsvorfälle mit hohen Folgekosten
- Betriebsunterbrechungen mit regulatorischer Relevanz
Stufe 4 ist wirtschaftlich sinnvoll,
wenn Fehler rechtliche oder sicherheitskritische Folgen haben.
Hinweis zu ISO 27001
ISO/IEC 27001 beschreibt Anforderungen an ein ISMS.
Stufe 4 operationalisiert diese Anforderungen im Produktkontext.
Ein Zertifikat ersetzt keine technische Qualität –
es verlangt nachvollziehbare Kontrollen.
Akzeptierte Risiken
- Höhere Komplexität im Prozess
- Längere Lieferzyklen
- Geringere Flexibilität bei kurzfristigen Änderungen
Diese Kosten sind bewusst akzeptiert, um Risiko systematisch zu reduzieren.