Domäne · D5

Resilienz & Exit-Fähigkeit

„Kann der Dienst ohne prohibitiven Aufwand und in vertretbarer Zeit gewechselt werden?"

1. Strategische Bedeutung§

Resilienz und Exit-Fähigkeit misst die Wechselfähigkeit eines Dienstes und die Belastbarkeit im Störfall. Solange ein Dienst nicht innerhalb vertretbarer Frist und zu vertretbaren Kosten gegen einen anderen austauschbar ist, ist der Kunde strukturell von einem einzelnen Anbieter abhängig — unabhängig davon, wie sicher oder transparent dieser Anbieter im Einzelnen ist.

Diese Domäne adressiert die strukturelle Verhandlungsmacht. Sie ist die Domäne, die langfristige Preis-, Funktions- und Sicherheitsverhandlungen erst ermöglicht — und die im Krisenfall den Unterschied zwischen ungeplantem Ausfall und kontrollierter Migration macht.

Eine hohe Bewertung in D5 verlangt sowohl offene Schnittstellen als auch nachgewiesene Migrations- und Wiederanlauffähigkeit in realen Szenarien. Behauptete Portabilität ohne reproduzierbare Exit-Übung zählt nicht.

2. Kernkriterien§

Offene Standards und Datenportabilität
Anteil offener Standards an Schnittstellen und Datenformaten. Exportierbarkeit aller Kundendaten in offenen, dokumentierten Formaten — inklusive Metadaten.
Vollständig dokumentierte APIs
Versionierte, vertraglich stabile, vollständig dokumentierte Schnittstellen für alle administrativen und datenbezogenen Funktionen.
Exit-Plan und Exit-Kosten-Matrix
Dokumentierte Aufwands- und Kostenabschätzung für vollständige Migration in vergleichbare Zielumgebungen, inklusive Zeitplan.
Wiederanlauffähigkeit (BCM/DR)
RTO/RPO definiert, getestet und vertraglich verankert; Failover- und Restore-Verfahren regelmäßig erprobt.
Kompatibilität zu Konkurrenzdiensten
Nachgewiesene Migrationspfade in mindestens zwei konkurrierende Zielarchitekturen — idealerweise als reproduzierbare Referenzimplementierung.
Proprietäre Lock-in-Elemente
Transparente Auflistung aller proprietären Datenbanken, Funktionen, ML-Modelle oder Konfigurationsformate, die einen Wechsel erschweren.

3. Prüffragen (Auszug)§

Welche der vom Dienst genutzten Datenformate sind offen standardisiert?
Ist eine Referenzmigration in eine konkurrierende Zielumgebung dokumentiert und reproduzierbar?
Welche dokumentierte Exit-Kostenabschätzung liegt für die typische Kundenkonfiguration vor?
Welche RTO/RPO-Werte sind vertraglich verankert, und wann wurden sie zuletzt getestet?
Welche proprietären Komponenten besitzen kein funktionsäquivalentes offenes Pendant?

4. Akzeptierte Evidenz§

API-Spezifikationen (OpenAPI, AsyncAPI) inklusive Versionspolitik
Exit-Drehbuch mit Schätzung von Dauer, Kosten und Datenverlust-Risiko
Reproduzierbares Migrationsbeispiel in eine alternative Zielarchitektur
BCM/DR-Testprotokolle der letzten 24 Monate
Liste proprietärer Komponenten mit Risikobewertung

5. Level-Schwellen in dieser Domäne§

Level	Mindestanforderung in D5
L0	Exit-Möglichkeit grundsätzlich beschrieben; Datenexport in Standardformaten.
L2	APIs und Exportwege vollständig dokumentiert; Exit-Plan und RTO/RPO vertraglich fixiert.
L3	Nachgewiesener Exit in vertretbarer Zeit und Kosten; getestete Wiederanlaufverfahren; eingeschränkter proprietärer Lock-in.
L4	Reproduzierbare Migration in mindestens zwei Konkurrenzziele; jährliche Exit- und DR-Tests; vertragliche Migrationsgarantien.

6. Anschluss an bestehende Standards§

Standard	Was abgedeckt ist	Wo EDSO darüber hinausgeht
DORA	Exit-Strategien gefordert	Reproduzierbarer Wechsel und EU-Zielarchitekturen nicht spezifiziert
EUCS	Portabilitätsanforderungen teilweise	Nachweisbare Exit-Übung nicht gefordert
EU Data Act	Portabilitätsrechte gesetzlich verankert	Operationalisierbarkeit und Prüftiefe offen — EDSO konkretisiert

7. Typische Audit-Befunde§

API-Vollständigkeit nur für gängige Funktionen, kritische Administrationsoperationen nur über Web-UI
Export in offenem Format, aber ohne Metadaten und Berechtigungsbeziehungen
RTO/RPO vertraglich fixiert, aber seit Jahren nicht getestet
Exit-Kostenangaben ohne Referenz auf real durchgeführte Migration