Wissensraum · Deep Dive 21 von 22
Das ICT-Register
unter DORA
Die erste Frage im DORA-Audit lautet fast immer: «Zeigen Sie mir Ihr ICT-Drittanbieter-Register.» Was danach passiert, entscheidet sich nicht im Audit — sondern in den Monaten davor.
DORA Art. 28 · Register vs. Vendor-Liste · Kritikalitätsklassifikation · Sub-Outsourcing-Transparenz · Exit-Strategien · Leitungsverantwortung
Was dieser Deep Dive Ihnen zeigt
Was das ICT-Informationsregister nach DORA Art. 28 Abs. 3 tatsächlich enthalten muss – und warum eine blosse Kreditoren- oder Vendorliste der Anforderung nicht genügt, unabhängig vom verwendeten Werkzeug.
1. Warum das Register der Startpunkt jedes DORA-Audits ist
DORA Art. 28 Abs. 3 verpflichtet Finanzunternehmen, ein Informationsregister über sämtliche vertraglichen Vereinbarungen zur Nutzung von ICT-Dienstleistungen zu führen und aktuell zu halten (nicht bloss eine Anbieterliste — eine Anbieterbeziehung kann mehrere Verträge und Dienste umfassen). Das Register ist nicht ein Compliance-Dokument unter vielen – es ist die Grundlage für sämtliche weitere Drittanbieter-Governance: Risikoanalysen, Vertragsprüfungen, Exit-Strategien, Resilienztests und das Monitoring kritischer Abhängigkeiten.
Nach unserer Erfahrung gehört das Informationsregister häufig zu den ersten in einer DORA-Prüfung angeforderten Nachweisen: «Zeigen Sie mir Ihr Register.» Was die Aufsicht sieht, prägt den Verlauf des Audits. Ein vollständiges, strukturiertes, aktuelles Register signalisiert: Diese Organisation hat DORA verstanden. Eine Vendorliste aus dem Beschaffungssystem signalisiert das Gegenteil.
Einordnung
Das Register ist kein statisches Dokument. DORA verlangt, dass es «auf dem neuesten Stand» gehalten wird – Art. 28 Abs. 3. Eine Übersicht, die vor 18 Monaten erstellt und seitdem nicht aktualisiert wurde, erfüllt die Anforderung nicht.
2. Was eine Vendorliste nicht ist – und was das Register leisten muss
Der häufigste Fehler: Unternehmen verwechseln ihr Beschaffungssystem oder ihre Vertragsdatenbank mit dem ICT-Register nach DORA. Der Unterschied liegt nicht in der Form, sondern im Inhalt und in der Logik.
Vendorliste: wer bezahlt wird. Informationsregister: welche ICT-Dienste aufgrund welcher Vereinbarung welche Funktionen unterstützen.
Eine Vendorliste enthält alle Lieferanten mit aktiven Rechnungsbeziehungen. Das ICT-Informationsregister nach DORA erfasst die vertraglichen Vereinbarungen über ICT-Dienstleistungen – unabhängig davon, ob Gebühren anfallen und ob der Anbieter intern als «IT-Dienstleister» klassifiziert wird. Ein Softwarehersteller, der eine in kritische Prozesse eingebettete Bibliothek im Rahmen einer vertraglichen Vereinbarung pflegt, gehört ins Register; ob er eine Rechnung stellt, ist dabei nicht entscheidend. Eine reine Open-Source-Bibliothek ohne Dienstleistungs- oder Vertragsbeziehung ist dagegen nicht automatisch als ICT-Drittdienstleistungsvertrag zu erfassen.
Das Register klassifiziert – es zählt nicht nur auf.
Art. 28 Abs. 3 DORA verlangt insbesondere, die vertraglichen Vereinbarungen zu unterscheiden, die ICT-Dienste zur Unterstützung kritischer oder wichtiger Funktionen betreffen. Das ist keine Ja/Nein-Entscheidung, sondern eine begründete Bewertung: Welche Geschäftsprozesse hängen an dieser Dienstleistung? Was passiert bei Ausfall? Wie schnell kann gewechselt werden? Ohne Kritikalitätsklassifikation ist das Register regulatorisch wertlos.
Sub-Outsourcing muss sichtbar sein.
DORA verlangt Transparenz über Sub-Outsourcing: Die vertraglichen Bedingungen dafür regelt Art. 30 DORA (Vertragsinhalte), und im Informationsregister (Art. 28 Abs. 3 i. V. m. der ITS (EU) 2024/2956) müssen die eingesetzten Sub-Dienstleister sichtbar sein. Ein Cloud-Provider, der seinerseits kritische Dienste auslagert, erzeugt Abhängigkeiten, die im eigenen Register sichtbar sein müssen. Das ist das am häufigsten übersehene Element – und das Element, das in DORA-Audits am häufigsten zu Findings führt.
Exit-Strategien gehören ins Register – nicht in ein separates Dokument.
Für jeden Dienst, der eine kritische oder wichtige Funktion unterstützt, verlangt DORA Art. 28 Abs. 8 eine dokumentierte Exit-Strategie. Diese muss nicht im Register selbst ausformuliert sein – aber das Register muss auf sie verweisen und zeigen, dass sie existiert. Ein Register ohne Exit-Referenzen ist für kritische Dienstleister unvollständig.
3. Was das Register mindestens enthalten muss
DORA Art. 28 Abs. 3 i. V. m. der ITS (EU) 2024/2956 definiert den Mindestinhalt des Registers. Die folgende Tabelle zeigt, was für jeden Eintrag dokumentiert sein muss – und was über den Mindestinhalt hinaus operativ notwendig ist.
| Feld | DORA-Anforderung | Praktische Bedeutung |
|---|---|---|
| Name und Sitz | Art. 28 Abs. 3 DORA + ITS (EU) 2024/2956 – Pflicht | Vollständiger juristischer Name, Registrierungsland. Relevant für Rechtsordnung und regulatorische Zuordnung. |
| Art der Dienstleistung | Art. 28 Abs. 3 DORA + ITS (EU) 2024/2956 – Pflicht | Konkrete Leistungsbeschreibung – nicht «IT-Dienstleister», sondern «Cloud-Hosting kritischer Kernsysteme» oder «Authentifizierungsdienst». |
| Standorte der Datenverarbeitung | Art. 28 Abs. 3 DORA + ITS (EU) 2024/2956 – Pflicht | Wo werden Daten verarbeitet und gespeichert? Für Souveränitätsfragen, Datenschutz und regulatorische Compliance entscheidend. |
| Sub-Dienstleister | Art. 28 Abs. 3 DORA + ITS (EU) 2024/2956 – Pflicht | Welche weiteren Anbieter setzt der Dienstleister für die erbrachten Leistungen ein? Häufig nicht bekannt – muss aktiv erhoben werden. |
| Kritikalitätsklassifikation | Art. 28 Abs. 3 – Pflicht | Kritisch / Wesentlich / Standard – mit dokumentierter Begründung. Nicht optional für Dienstleister, die kritische Funktionen unterstützen. |
| Vertragsdatum und -laufzeit | Operativ erforderlich | Wann läuft der Vertrag aus? Relevant für Exit-Planung und Verlängerungsentscheidungen unter regulatorischen Anforderungen. |
| Exit-Strategie-Referenz | Art. 28 Abs. 8 DORA (Exit-Strategien) – für Dienste zur Unterstützung kritischer oder wichtiger Funktionen Pflicht | Verweis auf das Exit-Strategiedokument oder direkte Kurzbeschreibung des Ausstiegspfads. Nicht «TBD». |
| Verantwortlicher intern | Operativ erforderlich | Wer ist intern für diesen Dienstleister verantwortlich? Ohne Named Owner ist das Register nicht steuerbar. |
| Letztes Review-Datum | Aktualisierungspflicht Art. 28 Abs. 3 | Wann wurde der Eintrag zuletzt inhaltlich geprüft und bestätigt? Ohne Datum ist die Aktualitätspflicht nicht nachweisbar. |
Ein Register ohne Kritikalitätsklassifikation ist eine Adressliste. Ein Register ohne Exit-Referenzen für kritische Dienstleister ist unvollständig. Ein Register ohne letztes Review-Datum ist regulatorisch nicht vertretbar.
4. Die Kritikalitätsklassifikation – das Herzstück des Registers
Die Kritikalitätsbewertung ist die intellektuell anspruchsvollste Aufgabe beim Aufbau des Registers. Sie ist keine Ja/Nein-Entscheidung, sondern eine strukturierte Risikobeurteilung entlang vier Dimensionen:
Prozessabhängigkeit
Eine ICT-Dienstleistung unterstützt eine kritische oder wichtige Funktion, wenn ihr Ausfall diese Funktion des Finanzunternehmens beeinträchtigt. Bewertet wird die konkrete Dienstleistung, nicht pauschal der Anbieter als juristische Person. Die Klassifikation folgt dem Prozess.
Substituierbarkeit
Ein Dienstleister mit hoher Substituierbarkeit – viele alternative Anbieter, geringe Migrationskosten – kann tiefer klassifiziert werden als ein Dienstleister mit faktischem Lock-in.
Ausfallwirkung
Was passiert konkret bei einem Ausfall von 22 oder 24 Stunden? Die Ausfallwirkungsanalyse verbindet den Dienstleister mit den RTO/RPO-Anforderungen der abhängigen Prozesse.
Konzentrationsrisiko
Wie viele kritische Prozesse hängen an diesem einen Anbieter? Das Register muss diese Aggregation sichtbar machen.
Einordnung
Die Kritikalitätsklassifikation ist eine Entscheidung des Managements – nicht der IT. DORA Art. 5 legt die Verantwortung für das ICT-Risikomanagement-Framework beim Leitungsorgan.
5. Beispiel: So sieht ein konformer Register-Ausschnitt aus
Das folgende Beispiel zeigt drei Einträge mit unterschiedlicher Kritikalitätsstufe.
| Anbieter | Leistung | Datenhaltung | Sub-Anbieter | Kritikalität | Exit-Strategie |
|---|---|---|---|---|---|
| CloudProvider AG | Hosting Kernsysteme, Zahlungsabwicklung | Frankfurt (DE) | Equinix, Akamai | Kritisch | Ja – EXIT-001 |
| AuthService GmbH | Authentifizierung / MFA | Amsterdam (NL) | AWS Frankfurt | Wesentlich | Ja – EXIT-004 |
| DocuSign Inc. | Elektronische Signatur | USA | AWS (USA) | Standard | Alternativanbieter verfügbar |
6. Fallstudie: Das Register, das keines war
Ausgangssituation
Ein mittelgroßes Finanzdienstleistungsunternehmen bereitet sich auf eine DORA-Prüfung vor. Der CISO legt dem Prüfer eine Excel-Tabelle mit 214 Einträgen vor – alle Lieferanten, mit denen in den letzten drei Jahren Verträge bestanden haben.
Was folgt
Vier DORA-Findings: Fehlendes Register, keine Kritikalitätsklassifikation, keine Exit-Strategien für kritische Dienstleister, fehlende Sub-Outsourcing-Transparenz. Das Unternehmen erhält eine Nachbesserungsfrist von drei Monaten.
Die eigentliche Ursache
Niemand hatte den Unterschied zwischen einer Vendorliste und einem DORA-konformen Register erklärt. Das Beschaffungsteam hatte getan, was es konnte. Das Ergebnis war operativ plausibel – regulatorisch unbrauchbar.
7. Wie ein DORA-konformes Register aufgebaut wird
Vollständige Inventur – nicht nur Verträge
Der Ausgangspunkt ist eine Vollerhebung aller ICT-Abhängigkeiten. Erfahrungsgemäß sind 20–40 % der tatsächlichen ICT-Abhängigkeiten nicht in der Vertragsdatenbank erfasst.
Kritikalitätsbewertung – strukturiert, begründet, dokumentiert
Die Bewertung wird schriftlich begründet – nicht als Ampelfarbe vergeben. Ein Auditor fragt nach der Begründung, nicht nach der Farbe.
Sub-Outsourcing erheben – aktiv, nicht passiv
Sub-Dienstleister-Information muss aktiv bei den Drittdienstleistern erhoben werden – DORA Art. 30 verlangt solche Klauseln für Dienste zur Unterstützung kritischer oder wichtiger Funktionen.
Exit-Strategien – konkret, nicht konzeptionell
Für jeden Dienst, der eine kritische oder wichtige Funktion unterstützt, muss eine Exit-Strategie existieren, die tatsächlich funktioniert: Migrationsdauer, Alternative, technische Voraussetzungen, Datenmigration.
Review-Zyklus – mit Owner und Datum
Der Review-Zyklus für kritische Einträge: mindestens jährlich, bei wesentlichen Änderungen ad hoc. Das gesamte Register wird mindestens jährlich dem Leitungsorgan vorgelegt.
8. Was das Leitungsorgan wissen muss
Was das Leitungsorgan wissen muss
Das Register ist eine Management-Pflicht, keine IT-Aufgabe
Praxis-Impuls
Stellen Sie sich drei Fragen: Haben Sie ein Register, das alle ICT-Abhängigkeiten enthält? Enthält jeder Eintrag eine begründete Kritikalitätsklassifikation, Sub-Outsourcing-Information und Exit-Strategiereferenz? Wurde das Register in den letzten zwölf Monaten inhaltlich geprüft und dem Leitungsorgan vorgelegt?
Was bleibt
Eine Vendorliste ist kein ICT-Register. DORA verlangt ein strukturiertes Dokument mit Kritikalitätsklassifikation, Sub-Outsourcing-Transparenz und Exit-Strategiereferenzen.
Die Kritikalitätsklassifikation ist die wichtigste intellektuelle Leistung beim Registeraufbau. Sie folgt dem Prozess – nicht dem Vertragstyp – und muss begründet sein.
Sub-Outsourcing ist der häufigste blinde Fleck. Wer nicht weiß, welche Drittdienstleister seine eigenen Drittdienstleister einsetzen, erfüllt die Register- und Vertragsanforderungen (Art. 28 Abs. 3, Art. 30 DORA) nicht.
Das Register ist Chefsache. DORA Art. 5 legt die Verantwortung für das ICT-Risikomanagement beim Leitungsorgan. Das Register ist das zentrale Dokument dieses Systems.