Ein DORA-Register, kein DORA-Tool
Ein DORA-Drittdienstleister-Register verlangt keine eigene Software, sondern ein konfiguriertes Bewertungsraster auf einer Plattform, die Partner und Business Units ohnehin scort. Wie ein Register auf OpenScorecard abgebildet wird — und warum der Audit-Modus sich dabei ändert.
Die meisten Häuser kaufen für DORA ein eigenes Tool. Ein GRC-Modul, eine TPRM-Suite, ein Register-Produkt — jedes mit eigenem Datenmodell, eigener Vendor-Stammdatenpflege, eigenem Audit-Trail. Das ist die teuerste Art, eine Anforderung zu erfüllen, die strukturell schon zu dem passt, was eine Bewertungsplattform ohnehin tut: Bewertungssubjekte erfassen, mehrdimensional scoren, Veränderung verfolgen. Wie ein DORA-Register stattdessen als konfiguriertes Framework auf OpenScorecard entsteht.
Die Ausgangslage
Ein DORA-Drittdienstleister-Register ist keine Liste. Die Aufsicht verlangt eine kontinuierlich gepflegte, prüfungsfeste Sicht auf IKT-Dienstleister — mit Kritikalität pro Service-Beziehung, dokumentierter Substituierbarkeit, sichtbaren Konzentrationsrisiken und einem rückführbaren Pfad von jeder Aussage bis zur Quelle.
In der Praxis startet das Register fast immer als Excel-Aufsatz: Vendoren in Zeilen, Kritikalität pauschal pro Vendor statt pro Service, Konzentrationsrisiken nur sichtbar, wenn jemand händisch quersucht. Beim ersten ernsthaften Aufsichts-Besuch wird die Lücke teuer — nicht weil die Daten fehlen, sondern weil die Strecke von der Compliance-Aussage zurück zur Original-Quelle nicht trägt.
Warum kein eigenes Register-Tool
Ein DORA-Register tut strukturell dasselbe wie jede andere Bewertung auf der Plattform: Es erfasst Bewertungssubjekte (Vendoren), bewertet sie nach Dimensionen (Kritikalität, Substituierbarkeit, Konzentration), modelliert Beziehungen (Vendor zu Sub-Dienstleister zu Service) und führt einen Audit-Trail. Genau diese Struktur ist bei OpenScorecard die Plattform selbst.
DORA wird damit nicht zum Produkt, sondern zur Konfiguration: ein Bewertungssubjekt-Typ „IKT-Dienstleister", ein Satz Bewertungs-Dimensionen, ein Fragenkatalog für Vendor-Self-Assessments, ein Score-Mapping auf die DORA-Anforderungen. Kommt morgen ein DORA-Annex oder eine NIS-2-Verschärfung, ist das eine Konfigurations-Frage, kein Software-Projekt.
Wie das Register auf OpenScorecard entsteht
Kritikalität pro Service-Beziehung. Statt einem Score pro Vendor modelliert die Plattform Vendor ↔ Service ↔ Kritikalität. Ein Hyperscaler ist „kritisch" für die Trade-Platform und „nicht-kritisch" für das interne Lernportal — beide Beziehungen im selben Profil, getrennt bewertet.
Substituierbarkeit als Pflichtfeld. Pro Service-Beziehung: gibt es Alternativen, mit welchem Aufwand, in welchem Zeitfenster. Nicht als Freitext-Platzhalter, sondern als strukturiertes Attribut, das in das Scoring einfließt.
Konzentrationsrisiko aus dem Beziehungs-Graph. Weil Sub-Dienstleister-Beziehungen als Graph erfasst sind, ist die Frage „welche kritischen Services hängen am selben Tier-3-Anbieter?" eine Abfrage — keine dreitägige Excel-Quersuche.
Self-Assessments standardisiert. Vendor-Selbstauskünfte laufen gegen einen einheitlichen, runtime-konfigurierbaren Fragenkatalog. Antworten werden vergleichbar, weil sie gegen dasselbe Raster laufen — nicht jeder Vendor mit eigenem Fragebogen in eigenem Format.
Audit-Pfad bis zur Quelle. Jeder Register-Eintrag hat einen rückführbaren Weg zum Self-Assessment, zum externen Rating, zum Vorfall-Bericht — mit Zeitstempel und Versions-Historie. Die Aufsichts-Frage „woher kommt diese Kritikalitäts-Bewertung?" hat eine Antwort in Minuten.
Was sich am Audit-Modus ändert
Das jährliche DORA-Reporting wird von der Excel-Kampagne zur Pipeline-Aufgabe: Daten liegen strukturiert vor, der Report wird generiert, nicht erstellt. Die Strecke von der Aussage zur Quelle ist durchgängig, nicht durch manuelle Zwischenschritte unterbrochen. Und weil das Register auf derselben Plattform läuft wie die interne BU-Resilience-Bewertung, gibt es ein Datenmodell und einen Audit-Trail statt zwei getrennter Tool-Welten.
DORA ist hier nur die regulatorisch sichtbarste Ausprägung. Dieselbe Plattform trägt NIS-2-Lieferketten-Anforderungen, NIST CSF und NIST SP 800-171 für Lieferanten-Cybersecurity, den EU-Supply-Chain-Act, interne Reifegrad-Bewertungen und beliebige weitere Bewertungsraster — als Konfiguration, nicht als je eigenes Produkt. Wenn Ihr DORA-Register heute in Excel-Realität festhängt, klärt das Tactical Assessment, wie der Übergang aussieht.
