---
name: "DORA-Exit-Strategie- & Exit-Plan-Vorlage"
version: "1.0"
updated: "2026-07-23"
source: "https://www.orbiqhq.com/de/vorlagen/dora-exit-strategie-vorlage"
license: "Kostenlos nutz- und anpassbar innerhalb Ihrer Organisation. Namensnennung willkommen. Keine Rechtsberatung."
legal_basis:
  - "https://eur-lex.europa.eu/eli/reg/2022/2554/oj"          # DORA — Verordnung (EU) 2022/2554 (Art. 28(7), 28(8), 30(3)(f))
  - "https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj"      # RTS zur IKT-Drittparteien-Leitlinie (Art. 10 — Exit-Pläne)
---

# DORA-Exit-Strategie- & Exit-Plan-Vorlage (maschinenlesbar)

Zweck: DORA-konforme Exit-Strategien und Exit-Pläne je vertraglicher Vereinbarung für
IKT-Dienstleistungen zur Unterstützung kritischer oder wichtiger Funktionen dokumentieren und
pflegen (Verordnung (EU) 2022/2554, Artikel 28(8); Delegierte Verordnung (EU) 2024/1773 der
Kommission, Artikel 10). Diese Datei ist in sich geschlossen: Ein Agent kann aus den
nachstehenden Definitionen eine Exit-Strategie auf Unternehmensebene aufbauen, je erfasster
vertraglicher Vereinbarung einen Exit-Plan-Datensatz erzeugen und das Test-/Überprüfungsprotokoll
führen.

Strukturregel: EIN Exit-Plan-Datensatz je vertraglicher Vereinbarung, die eine kritische oder
wichtige Funktion unterstützt (RTS Art. 10) — niemals ein generischer Plan für den gesamten
Dienstleisterbestand. Exit-Plan-Datensätze haken über `contract_ref` in das Informationsregister
ein (siehe die begleitende Datei dora-register-of-information-starter.md).

Geschützte Ergebnisse (Art. 28(8)) — jeder Exit muss abgeschlossen werden ohne:
1. Unterbrechung des Geschäftsbetriebs;
2. Einschränkung der Einhaltung regulatorischer Anforderungen;
3. Beeinträchtigung der Kontinuität und Qualität der Dienstleistungen für Kunden.

Jurisdiktionshinweise: Norwegen wendet Art. 28(8) unverändert an (norwegisches DORA-Gesetz in
Kraft seit 01.07.2025, Finanstilsynet; Pläne sollen realistisch sein und regelmäßig getestet
werden). UK kennt kein DORA, aber PRA SS2/21 verlangt je wesentlicher Auslagerungsvereinbarung
eine dokumentierte, getestete Exit-Strategie mit Unterscheidung stressed vs. non-stressed —
das Enum `trigger_class` unten deckt beide Regime ab. In Deutschland verlangt die
BaFin-Aufsichtsmitteilung zur DORA-Umsetzung (08.07.2024), Exit-Strategien und -Pläne gegenüber
dem alten BAIT/VAIT-Niveau deutlich zu stärken — plausible Szenarien, angemessene Annahmen,
ausreichende Tests.

---

## 1. Exit-Strategie (Unternehmensebene) — ein Datensatz

| # | Feld | Typ | Definition / Regel |
|---|---|---|---|
| 1 | `entity_legal_name` | Text | Eingetragener juristischer Name |
| 2 | `entity_lei` | Text (LEI-20) | Legal Entity Identifier |
| 3 | `competent_authority` | Text | NCA (BaFin, DNB, CBI, AMF, Finanstilsynet, …) |
| 4 | `strategy_owner` | Text (Rolle) | Verantwortliche Rolle, z. B. Leitung Drittparteien-Risikomanagement |
| 5 | `approval_body` | Text | Leitungsorgan oder Gremium + Freigabedatum |
| 6 | `in_scope_contract_refs` | Liste von `contract_ref` | Alle Vereinbarungen, die kritische oder wichtige Funktionen unterstützen (Art. 3(22)); müssen mit dem Informationsregister übereinstimmen |
| 7 | `risk_scenarios` | feste Liste | MUSS abdecken: `provider_failure`, `quality_deterioration`, `business_disruption`, `material_deployment_risk`, `art_28_7_termination` (Art. 28(8) Unterabs. 1) |
| 8 | `substitutability_scale` | Enum-Definition | z. B. `easily_substitutable` / `substitutable_with_effort` / `difficult` / `not_substitutable` — an den RoI-B_07-Bewertungen ausrichten |
| 9 | `market_scan_cadence` | Text | Wie oft Alternativen je Dienstleistungskategorie neu bewertet werden |
| 10 | `review_cadence` | Text | Mindestens jährlich + bei wesentlichen Änderungen |
| 11 | `last_review` / `next_review` | Datum (ISO 8601) | Überprüfungsdaten der Strategie |

## 2. Exit-Plan — ein Datensatz JE Vereinbarung

### 2.1 Identifikation

| # | Feld | Typ | Definition / Regel |
|---|---|---|---|
| 1 | `contract_ref` | Text, eindeutig | PRIMÄRSCHLÜSSEL — muss im Informationsregister (B_02) existieren |
| 2 | `provider_legal_name` | Text | IKT-Drittdienstleister |
| 3 | `provider_id` | Text | LEI oder EUID (juristische Personen in der EU); LEI (juristische Personen aus Drittländern) |
| 4 | `ict_service_type` | Enum `S01`–`S19` | Geschlossene Liste nach ITS (EU) 2024/2956 Anhang III |
| 5 | `cif_supported` | Text | Unterstützte kritische oder wichtige Funktion + Verweis auf die Begründung nach Art. 3(22) |
| 6 | `plan_owner` | Text (Rolle) | Pflegt den Plan |
| 7 | `activation_decision_maker` | Text (Rolle/Gremium) | Befugt, den Exit auszulösen |
| 8 | `plan_version` / `plan_date` | Text / Datum | Versionskontrolle |

### 2.2 Trigger

| # | Feld | Typ | Definition / Regel |
|---|---|---|---|
| 1 | `trigger_class` | Enum: `planned` / `stressed` | Stressed = Ausfall/Insolvenz oder ein Umstand nach Art. 28(7); erfüllt zugleich die stressed/non-stressed-Aufteilung des PRA SS2/21 |
| 2 | `planned_triggers` | Liste von Text | z. B. Vertragsablauf ohne Verlängerung, strategisches Insourcing |
| 3 | `stressed_triggers` | Liste von Enum | `provider_insolvency` / `art_28_7_a_breach` / `art_28_7_b_monitoring_findings` / `art_28_7_c_ict_risk_weaknesses` / `art_28_7_d_supervisability` / `ctpp_oversight_recommendation` |
| 4 | `trigger_indicators` | Liste von Text | KRIs, die jeden Trigger sichtbar machen (SLA-Verletzungszähler, Vorfallshäufigkeit, Finanzlage-Flags) |

### 2.3 Alternativlösung

| # | Feld | Typ | Definition / Regel |
|---|---|---|---|
| 1 | `alternatives_assessed` | Liste von {name, assessed_date, result} | Bewertete Alternativanbieter |
| 2 | `inhouse_option` | {feasible: Boolean, notes} | Bewertung der Wiedereingliederung ins eigene Haus (Art. 28(8) Unterabs. 4) |
| 3 | `selected_route` | Enum: `alternative_provider` / `in_house` / `hybrid` | Gewählter Exit-Weg |
| 4 | `substitutability` | Enum nach Strategieskala | Aktuelle Einstufung |

### 2.4 Übergangsplan

| # | Feld | Typ | Definition / Regel |
|---|---|---|---|
| 1 | `phases` | geordnete Liste von {phase, duration, description} | Typisch: Vorbereitung → Datenmigration → Parallelbetrieb → Cutover → Stilllegung |
| 2 | `data_inventory` | Liste von {dataset, volume, location} | Beim Dienstleister gehaltene Daten |
| 3 | `data_return_format` | Text | Vereinbarte Exportformate — vertraglich garantiert |
| 4 | `secure_transfer_method` | Text | Mechanismus + Verschlüsselung bei der Übertragung + Integritätsprüfung („sicher und vollständig überführen", Art. 28(8)) |
| 5 | `parallel_run_window` | Text | Dauer + Erfolgskriterien |
| 6 | `rollback_criteria` | Text | Bedingungen, unter denen der Cutover zurückgenommen wird |
| 7 | `closure_steps` | Liste von Text | Löschbestätigung, Zugriffsentzug, RoI-Aktualisierung |

### 2.5 Vertragliche Anker

| # | Feld | Typ | Definition / Regel |
|---|---|---|---|
| 1 | `transition_period` | Text | Verpflichtende angemessene Übergangsfrist nach Art. 30(3)(f) |
| 2 | `notice_period_entity` / `notice_period_provider` | Ganzzahl (Tage) | Kündigungsfristen |
| 3 | `data_return_clauses` | Text | Klauselverweise + garantierte Formate |
| 4 | `transition_assistance` | Text | Migrationsunterstützungspflichten des Dienstleisters inkl. Kosten |
| 5 | `schedule_fit` | Boolean | REGEL: Die Summe der `phases`-Dauern MUSS in die `transition_period` passen; falls false → Vertragsnachbesserung, Plan nicht ausführbar |

### 2.6 Notfallmaßnahmen, Kosten, Governance

| # | Feld | Typ | Definition / Regel |
|---|---|---|---|
| 1 | `contingency_measures` | Liste von Text | Interims-Kontinuitätsmaßnahmen während des Exits (Art. 28(8) letzter Unterabs.) |
| 2 | `client_impact_mitigation` | Text | Schutz von Kontinuität/Qualität der Kundendienstleistungen |
| 3 | `compliance_safeguards` | Text | Meldepflichten, Datenschutz-Kontinuität, Aufbewahrung während der Migration |
| 4 | `exit_cost_estimate` | Zahl + Währung | Einmalige Migrationskosten + Gebühren für Übergangsunterstützung |
| 5 | `resourcing` | Text | Teams, FTE-Wochen, Schlüsselpersonen-Abhängigkeiten |

## 3. Test- & Überprüfungsprotokoll — Datensätze nur anfügen

| # | Feld | Typ | Definition / Regel |
|---|---|---|---|
| 1 | `test_date` | Datum (ISO 8601) | |
| 2 | `contract_ref` | Text | Getestete Vereinbarung |
| 3 | `scenario` | Enum: `unforeseen_interruption` / `persistent_interruption` / `provider_insolvency` / `quality_deterioration` / `planned_exit` / weitere | RTS Art. 10: Tests MÜSSEN unvorhergesehene und anhaltende Serviceunterbrechungen berücksichtigen |
| 4 | `test_type` | Enum: `tabletop` / `walkthrough` / `partial_data_extraction` / `restore_verification` / `full_simulation` | Bei den kritischsten Vereinbarungen: reale Datenextraktionstests einschließen |
| 5 | `participants` | Liste von Text | |
| 6 | `findings` | Text | z. B. Export-Durchsatz unter der Annahme |
| 7 | `remediation` | {actions, closed_date} | Daraus resultierende Plan-Aktualisierungen |
| 8 | `next_test` | Datum | Kadenzregel: mindestens ein Test je Vereinbarung und Überprüfungszyklus; risikobasierte Frequenz |

## 4. Aktivierungs-Runbook (Sequenz)

1. `declare` — Entscheidungsträger bestätigt den Trigger, erklärt den Exit (geplant/Stress), protokolliert Entscheidung + Zeitpunkt
2. `notify` — interne Stakeholder; Dienstleister (vertragliche Kündigung); zuständige Behörde wo erforderlich; Kunden gemäß Plan
3. `freeze` — Scope-Änderungen einfrieren; Daten-Snapshot sichern; Dateninventar erneut validieren
4. `execute` — Übergangsphasen gegen das Fenster nach Art. 30(3)(f) ausführen; bei Bedarf Notfallmaßnahmen hochfahren
5. `verify` — Datenrückgabe im vereinbarten Format; Integrität verifiziert; Löschbestätigung des Dienstleisters; Zugriffe entzogen
6. `close` — Informationsregister aktualisieren; Post-Exit-Review; Erkenntnisse in Strategie und verbleibende Pläne einspeisen

## 5. Beispieldatensatz (fiktiv, gekürzt)

```yaml
contract_ref: CTR-2024-018
provider_legal_name: CloudCore GmbH
ict_service_type: S17
cif_supported: "Zahlungsverarbeitung Privatkunden (kritisch, RoI B_06.01)"
trigger_class: stressed
stressed_triggers: [provider_insolvency, art_28_7_c_ict_risk_weaknesses]
selected_route: alternative_provider   # HanseCloud AB, bewertet 2026-03
phases:
  - {phase: preparation, duration: 4w}
  - {phase: data_migration, duration: 6w}   # nach Extraktionstest vom 2026-04-22 von 4w auf 6w umgeplant
  - {phase: parallel_run, duration: 4w}
  - {phase: cutover, duration: 1w}
  - {phase: decommission, duration: 3w}
transition_period: "24 Monate ab Kündigung"
schedule_fit: true
data_return_format: "PostgreSQL-Dumps + S3-kompatibler Objektexport, AES-256 bei der Übertragung, SHA-256-Manifeste"
contingency_measures: ["Zahlungswarteschlange im eingeschränkten Betrieb über Sekundärstandort, RTO 4h"]
last_test: {date: 2026-04-22, scenario: persistent_interruption, test_type: partial_data_extraction}
```