Das IKT-Drittparteienregister: die DORA-Pflicht, auf die auch NIS2-fitte Häuser nicht vorbereitet sind
DORA gilt seit Januar 2025 und verlangt mehr als gute Verträge: ein vollständiges Register aller IKT-Dienstleistungen, verbunden mit Funktionen, Kritikalität und Ausstiegsplänen. Warum das über NIS2-Lieferkettenarbeit hinausgeht, was ein lebendes Register ausmacht, und warum Verträge allein nicht reichen.
Viele Häuser haben ihre NIS2-Lieferkettenarbeit erledigt und gehen davon aus, damit sei auch DORA abgedeckt. Das ist ein teurer Irrtum. Für den Finanzsektor verlangt DORA ein Register der IKT-Drittparteien in einem Detailgrad, den NIS2 gar nicht kennt. Anwendbar ist die Verordnung seit dem 17. Januar 2025.
Was DORA konkret verlangt
Im Kern steht ein Register aller vertraglichen Vereinbarungen über IKT-Dienstleistungen (Artikel 28). Dieses Register ist mehr als eine Vertragsliste. Zu jedem Dienstleister gehört: welche Funktion er stützt, ob diese Funktion kritisch oder wichtig ist, welche Unterauftragnehmer dahinterstehen, und wie ein Ausstieg aussähe. Dazu kommen die Meldung schwerwiegender IKT-Vorfälle und Tests der digitalen Betriebsstabilität.
Warum Verträge allein kein Register sind
Ein Ordner voller Verträge beantwortet nicht die Frage, die im Ernstfall zählt: Was passiert mit unserer kritischen Funktion, wenn dieser Dienstleister ausfällt? Ein Register lebt von der Verknüpfung aus Vertrag, Dienstleister, gestützter Funktion, Kritikalität, Risiko und Ausstiegsplan. Erst diese Kette macht das Konzentrationsrisiko sichtbar, etwa wenn drei kritische Funktionen an einem einzigen Anbieter hängen. Ohne die Kette sieht man es nicht und kann im Ernstfall nicht handeln.
Warum NIS2-Arbeit nicht genügt
NIS2-Lieferkettensicherheit fragt vor allem: Ist der Lieferant sicher? DORA fragt zusätzlich: Was trägt dieser Dienstleister zu unseren kritischen Funktionen bei, und wie kommen wir wieder heraus? Anderer Detailgrad, andere Meldelogik, eine eigene Register-Pflicht. Wer NIS2 gemacht hat, besitzt eine gute Grundlage, aber noch nicht das DORA-Register.
Wie isidaten das umsetzt
Bei isidaten liegen die Bausteine des Registers auf einer gemeinsamen Objektbasis: Dienstleister und Auftragsverarbeiter, Verträge mit Typ, Status und Fristen, und die zugehörigen Risiken. Weil alles am selben Objekt hängt, entsteht das Register nicht als Nebenschauplatz, sondern als Nebenprodukt der ohnehin gepflegten Daten. Vorfälle und Fristen greifen auf dieselben Dienstleister zu. Wie das für DORA konkret aussieht, zeigen wir auf der DORA-Lösungsseite, oder direkt in einer Demo.
Fragen zu dieser Neuerung?
Sprechen Sie mit uns – wir zeigen Ihnen die Funktion gern in einer Demo.