DORA-Informationsregister: Leitfaden mit ISO 27001

Es ist Dienstag, 09:15 Uhr. Sarah, CISO eines schnell wachsenden Fintech-Unternehmens, sitzt mit ihrem Compliance-Manager, der Rechtsabteilung, der Beschaffungsleitung und dem Cloud-Architekten in einer Bereitschaftsprüfung. Der externe Berater übernimmt die Rolle eines DORA-Prüfers einer Aufsichtsbehörde.

„Vielen Dank für die Präsentation“, sagt er. „Bitte stellen Sie Ihr Informationsregister gemäß DORA Article 28 bereit, einschließlich der vertraglichen IKT-Vereinbarungen, die kritische oder wichtige Funktionen unterstützen, der Transparenz zur Unterauftragsvergabe, der Asset-Verantwortung und der Nachweise, dass das Register im Rahmen Ihres IKT-Risikomanagementrahmens gepflegt wird.“

Die erste Antwort klingt selbstbewusst: „Wir haben eine Lieferantenliste.“

Dann beginnen die Fragen.

Welche Lieferanten unterstützen die Zahlungsautorisierung? Welche Verträge enthalten Auditrechte, Unterstützung bei Vorfällen, Zusagen zu Datenstandorten, Kündigungsrechte und Exit-Unterstützung? Welche SaaS-Plattformen verarbeiten personenbezogene Kundendaten? Welche Cloud-Services unterstützen kritische oder wichtige Funktionen? Welche Subunternehmer stehen hinter dem Managed-Security-Anbieter? Welcher interne Asset-Verantwortliche hat die Abhängigkeit genehmigt? Welche Risiken im Risikobehandlungsplan nach ISO/IEC 27001:2022 sind mit diesen Anbietern verknüpft? Welche Einträge im Statement of Applicability begründen die Kontrollen?

Um 10:30 Uhr hat das Team vier Tabellenkalkulationen, einen CMDB-Export, einen SharePoint-Ordner mit PDF-Verträgen, eine Datenschutzliste der Auftragsverarbeiter, einen Cloud-Abrechnungsbericht und ein manuell gepflegtes SaaS-Tracking geöffnet. Keines dieser Artefakte stimmt mit den anderen überein.

Genau darin liegt die praktische Herausforderung des DORA-Informationsregisters im Jahr 2026. Die DORA-Umsetzung hat sich von „wir brauchen eine Roadmap“ zu „zeigen Sie mir die Nachweise“ verschoben. Für Finanzunternehmen, IKT-Drittdienstleister, CISOs, interne Auditoren und Compliance-Teams ist das Register keine administrative Vorlage mehr. Es ist das verbindende Gewebe zwischen IKT-Verträgen, Lieferantenrisiko, Unterauftragsketten, Cloud-Services, IKT-Assets, kritischen Funktionen, Governance-Verantwortung und Nachweisen nach ISO/IEC 27001:2022.

Der Ansatz von Clarysec ist einfach: Bauen Sie das DORA-Informationsregister nicht als separates Compliance-Artefakt auf. Bauen Sie es als lebende Nachweisschicht innerhalb Ihres ISMS auf, gestützt durch Asset-Management, Lieferantensicherheit, Governance der Cloud-Nutzung, Zuordnung gesetzlicher und regulatorischer Verpflichtungen, Audit-Metadaten und nachvollziehbare Risikobehandlung.

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls identifiziert drei Ankerkontrollen aus ISO/IEC 27001:2022 Anhang A als besonders relevant für dieses Thema: A.5.9, Inventar von Informationen und anderen zugehörigen Assets; A.5.19, Informationssicherheit in Lieferantenbeziehungen; und A.5.20, Berücksichtigung von Informationssicherheit in Lieferantenvereinbarungen. Diese Kontrollen sind kein zusätzlicher Papieraufwand. Sie bilden das operative Rückgrat, um nachzuweisen, dass das Register vollständig, verantwortet, aktuell und auditierbar ist.

Was DORA vom Informationsregister erwartet

DORA gilt seit dem 17. Januar 2025 und schafft ein Regelwerk für IKT-Resilienz im Finanzsektor, das IKT-Risikomanagement, Vorfallmeldung, Resilienztests, Drittparteienrisiken, vertragliche Vereinbarungen, Aufsicht über kritische IKT-Drittdienstleister und aufsichtsrechtliche Durchsetzung umfasst. Für Finanzunternehmen, die auch nach nationaler NIS2-Umsetzung erfasst sind, wirkt DORA als sektorspezifischer Rechtsakt der Union für die entsprechenden Anforderungen an das Cybersicherheitsrisikomanagement und die Meldung von Vorfällen.

Die Registerpflicht ist Teil der DORA-Disziplin zum Management von IKT-Drittparteienrisiken. DORA Article 28 verlangt von Finanzunternehmen, IKT-Drittparteienrisiken als Bestandteil des IKT-Risikomanagementrahmens zu steuern, auch bei Nutzung von IKT-Anbietern voll verantwortlich für die Einhaltung zu bleiben, ein Informationsregister über vertragliche Vereinbarungen zu IKT-Dienstleistungen zu führen und Vereinbarungen zu unterscheiden, die kritische oder wichtige Funktionen unterstützen.

DORA Article 29 ergänzt Anforderungen zu Konzentrations- und Unterauftragsrisiken. Dazu gehören Ersetzbarkeit, mehrfache Abhängigkeiten von demselben oder verbundenen Anbietern, Unterauftragsvergabe in Drittstaaten, insolvenzbedingte Einschränkungen, Datenwiederherstellung, Einhaltung des Datenschutzes sowie lange oder komplexe Unterauftragsketten.

DORA Article 30 definiert anschließend die Vertragsinhalte, die Auditoren erwarten werden. Dazu gehören Servicebeschreibungen, Bedingungen für die Unterauftragsvergabe, Orte der Datenverarbeitung, Datenschutzverpflichtungen, Zugriffs- und Wiederherstellungspflichten, Service Levels, Unterstützung bei Vorfällen, Zusammenarbeit mit Behörden, Kündigungsrechte, Teilnahme an Schulungen, Auditrechte und Exit-Strategien für Vereinbarungen, die kritische oder wichtige Funktionen unterstützen.

Ein ausgereiftes DORA-Informationsregister muss vier praktische Fragen beantworten.

Ein schwaches Register ist eine Tabellenkalkulation, die die Beschaffung einmal im Jahr aktualisiert. Ein starkes Register ist ein gesteuerter Datenbestand, der Lieferantenportfolio, Asset-Inventar, Cloud-Register, Vertrags-Repository, Datenschutzaufzeichnungen, Business-Continuity-Pläne, Incident-Playbooks, Risikoregister und Nachweise nach ISO/IEC 27001:2022 miteinander verbindet.

Warum ISO 27001 der schnellste Weg zu einem belastbaren DORA-Register ist

ISO/IEC 27001:2022 gibt Organisationen die Managementsystemstruktur, die DORA-Nachweisen häufig fehlt. Die Abschnitte 4.1 bis 4.4 verlangen, dass die Organisation Kontext, interessierte Parteien, gesetzliche, regulatorische und vertragliche Verpflichtungen, Geltungsbereich, Schnittstellen und Abhängigkeiten festlegt. Genau hier gehört DORA in das ISMS, weil das Register davon abhängt, welche Finanzdienstleistungen, IKT-Anbieter, Kunden, Behörden, Cloud-Plattformen und ausgelagerten Prozesse in den Geltungsbereich fallen.

Die Abschnitte 5.1 bis 5.3 verlangen Führung, Ausrichtung der Richtlinien, Ressourcen, Verantwortlichkeiten und Berichterstattung an die oberste Leitung. Das ist relevant, weil DORA Article 5 dem Leitungsorgan die Verantwortung zuweist, den IKT-Risikomanagementrahmen zu definieren, zu genehmigen, zu überwachen und dafür rechenschaftspflichtig zu bleiben, einschließlich Richtlinien für IKT-Drittdienstleistungen und Meldekanäle.

Die Abschnitte 6.1.1 bis 6.1.3 sind der Punkt, an dem das Register risikobasiert wird. ISO/IEC 27001:2022 verlangt einen wiederholbaren Risikobeurteilungsprozess, Risikoverantwortliche, Analyse von Eintrittswahrscheinlichkeit und Auswirkungen, Risikobehandlung, Kontrollauswahl, ein Statement of Applicability und die Genehmigung des Restrisikos durch den Risikoverantwortlichen. Ein DORA-Register, das nicht mit der Risikobehandlung verknüpft ist, bleibt eine statische Liste. Ein Register, das mit Risikoszenarien, Kontrollen und Verantwortlichen verknüpft ist, wird zu Auditnachweis.

Die Abschnitte 8.1 bis 8.3 überführen Planung anschließend in gesteuerte Betriebsabläufe. Sie unterstützen dokumentierte Informationen, operative Planung und Steuerung, Änderungskontrolle, Steuerung extern bereitgestellter Prozesse, geplante Risikoneubewertungen, Umsetzung der Risikobehandlung und Nachweisaufbewahrung. Das ist für 2026 entscheidend, weil Aufsichten nicht nur fragen, ob ein Register zu einem bestimmten Zeitpunkt existierte. Sie fragen, ob neue Verträge, geänderte Services, neue Subunternehmer, Cloud-Migrationen und Exit-Ereignisse im Governance-Zyklus erfasst werden.

Die Kontrollebene des Anhangs A verstärkt denselben Punkt. Lieferantenbeziehungen, Lieferantenvereinbarungen, IKT-Lieferkettenrisiken, Überwachung von Lieferantendiensten, Beschaffung und Exit von Cloud-Services, Vorfallmanagement, Aufrechterhaltung des Geschäftsbetriebs, gesetzliche und regulatorische Verpflichtungen, Datenschutz, Backups, Protokollierung, Überwachung, Kryptografie und Schwachstellenmanagement tragen alle zur Qualität des Registers bei.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint erläutert die Asset-Grundlage in der Phase „Controls in Action“, Step 22:

In seiner strategischsten Form dient ein Asset-Inventar als zentrales Nervensystem Ihres ISMS. Es informiert darüber, wie Zugriff bereitgestellt wird (8.2), wo Verschlüsselung anzuwenden ist (8.24), welche Systeme Backups benötigen (8.13), welche Protokolle erfasst werden (8.15) und sogar, wie Klassifizierungs- und Aufbewahrungsrichtlinien durchgesetzt werden (5.10, 8.10).

Dieses Zitat bringt den praktischen Punkt auf den Punkt. Sie können kein verlässliches DORA-Informationsregister führen, wenn das zugrunde liegende Asset-Inventar nicht verlässlich ist. Wenn Ihr Register „Core Banking SaaS“ ausweist, Ihr Asset-Inventar aber keine APIs, Servicekonten, Datenbestände, Protokollquellen, Verschlüsselungsschlüssel, Backup-Abhängigkeiten und Verantwortlichen zeigt, ist das Register aus Auditsicht unvollständig.

Das Clarysec-Datenmodell: ein Register, viele Nachweissichten

Ein DORA-Informationsregister sollte Ihr Lieferantenregister, Asset-Register oder Cloud-Register nicht ersetzen. Es sollte sie verbinden. Clarysec gestaltet das Register üblicherweise als zentrale Nachweisschicht mit gesteuerten Beziehungen zu bestehenden ISMS-Aufzeichnungen.

Das minimal tragfähige Modell umfasst sieben verknüpfte Objekte.

Diese Struktur ermöglicht es einem Register, mehrere Nachweisanfragen zu bedienen. Eine DORA-Aufsicht kann vertragliche Vereinbarungen einsehen, die kritische oder wichtige Funktionen unterstützen. Ein ISO-Auditor kann Lieferantenkontrollen auf Referenzen zu Anhang A und Risikobehandlung zurückverfolgen. Ein GDPR-Prüfer kann Auftragsverarbeiter, Datenkategorien, Standorte und Datenschutzverpflichtungen sehen. Ein an NIST orientierter Assessor kann Lieferketten-Governance, Lieferantenkritikalität, Vertragsanforderungen und Lebenszyklusüberwachung prüfen.

Das Register wird damit mehr als eine Antwort auf „Wer sind unsere Anbieter?“. Es wird zu einem Abhängigkeitsgraphen.

Richtliniengrundlagen, die das Register auditierbar machen

Das Richtlinienset von Clarysec gibt dem Register ein operatives Zuhause. Für KMU beginnt die Third-Party and Supplier Security Policy-sme Richtlinie zur Lieferanten- und Drittparteiensicherheit - KMU mit einer klaren Registeranforderung:

Ein Lieferantenregister muss durch den administrativen oder Beschaffungskontakt geführt und aktualisiert werden. Es muss Folgendes enthalten:

Dieselbe KMU-Richtlinie legt fest, dass Verträge definierte Sicherheitsverpflichtungen enthalten müssen:

Verträge müssen verbindliche Klauseln enthalten, die Folgendes abdecken:

Auch wenn die zitierten Klauseln Feldlisten und Kategorien verbindlicher Klauseln in der Richtlinie selbst einführen, ist die Umsetzungsbotschaft eindeutig: Lieferanten-Governance muss dokumentiert, zugewiesen und vertraglich durchgesetzt werden.

Für Unternehmensumgebungen liegt Clarysecs Supplier Dependency Risk Management Policy Richtlinie zum Management von Risiken aus Lieferantenabhängigkeiten noch näher an den aufsichtlichen Erwartungen von DORA:

Lieferantenabhängigkeitsregister: Das VMO muss ein aktuelles Register aller kritischen Lieferanten führen, einschließlich Angaben zu bereitgestellten Services/Produkten, ob es sich um eine Single-Source-Beziehung handelt, verfügbaren alternativen Lieferanten oder Ersetzbarkeit, aktuellen Vertragsbedingungen sowie einer Bewertung der Auswirkungen, falls der Lieferant ausfallen oder kompromittiert werden sollte. Das Register muss Lieferanten mit hoher Abhängigkeit eindeutig kennzeichnen, z. B. solche, für die keine schnell verfügbare Alternative besteht.

Dies lässt sich sauber auf die DORA Article 29-Anforderungen zu Konzentrations- und Ersetzbarkeitsrisiken abbilden. Wenn ein Lieferant eine Single-Source-Beziehung darstellt, eine kritische Funktion unterstützt, in einem Drittstaat tätig ist, eine lange Unterauftragskette nutzt und keinen getesteten Exit-Pfad hat, darf das Register dieses Risiko nicht in einem Freitextfeld verbergen. Es muss es kennzeichnen, einen Verantwortlichen zuweisen und mit der Risikobehandlung verbinden.

Clarysecs Enterprise-Third party and supplier security policy Richtlinie zur Lieferanten- und Drittparteiensicherheit macht den Geltungsbereich ausdrücklich:

Sie umfasst sowohl direkte Lieferanten als auch, soweit anwendbar, deren Subunternehmer und schließt Drittsoftware, Infrastruktur, Support und Managed Services ein.

Dieser Satz beschreibt eine häufige DORA-Lücke. Viele Organisationen erfassen direkte IKT-Anbieter, dokumentieren aber keine Subunternehmer, Unterauftragsverarbeiter, Werkzeuge für Managed Services, Support-Plattformen oder in einen Service eingebettete Drittsoftware.

Vertragsnachweise sind ebenfalls entscheidend. Dieselbe Enterprise-Richtlinie enthält:

Rechte zur Auditierung, Prüfung und Anforderung von Sicherheitsnachweisen

Diese Formulierung sollte in Ihrer Checkliste zur Vertragsprüfung sichtbar sein. Wenn ein Vertrag mit einem kritischen IKT-Anbieter keine Audit- oder Nachweisrechte enthält, muss das Register eine Abhilfemaßnahme ausweisen.

Asset-Nachweise sind ebenso wichtig. Clarysecs KMU-Asset Management Policy Richtlinie zum Asset-Management - KMU hält fest:

Die IT-Leitung muss ein strukturiertes Asset-Inventar führen, das mindestens die folgenden Felder enthält:

Die Enterprise-Asset Management Policy Richtlinie zum Asset-Management hält entsprechend fest:

Das Asset-Inventar muss mindestens Folgendes enthalten:

Das Register muss nicht jedes Asset-Feld duplizieren, es muss aber auf das Asset-Inventar verweisen. Wenn eine SaaS-Lösung zur Zahlungsüberwachung die Betrugserkennung unterstützt, sollte das DORA-Register mit dem Anwendungs-Asset, dem Datenbestands-Asset, den Servicekonten, API-Integrationen, Protokollquellen und dem Geschäftsverantwortlichen verknüpft sein.

Cloud-Services verdienen eine eigene Sicht. Clarysecs KMU-Cloud Usage Policy Richtlinie zur Nutzung von Cloud-Diensten - KMU verlangt:

Ein Register für Cloud-Services muss durch den IT-Dienstleister oder GM geführt werden. Es muss Folgendes erfassen:

Dies ist besonders wertvoll für die Erkennung von Shadow IT. Ein DORA-Register, das außerhalb der Beschaffung erworbene Cloud-Services ausschließt, wird die praktische Vollständigkeitsprüfung nicht bestehen.

Schließlich macht Clarysecs Legal and Regulatory Compliance Policy Richtlinie zur rechtlichen und regulatorischen Einhaltung Cross-Compliance zu einer ISMS-Anforderung:

Alle gesetzlichen und regulatorischen Verpflichtungen müssen innerhalb des Informationssicherheits-Managementsystems (ISMS) bestimmten Richtlinien, Kontrollen und Verantwortlichen zugeordnet werden.

Das ist die Brücke vom DORA-Register zu ISO 27001-Nachweisen. Das Register sollte nicht nur Lieferanten zeigen. Es sollte zeigen, welche Richtlinien, Kontrollen und Verantwortlichen die regulatorische Verpflichtung erfüllen.

Abbildung von DORA-Anforderungen auf ISO 27001 und Clarysec-Nachweise

Die folgende Tabelle verbindet die wesentlichen Registererwartungen mit Kontrollen aus ISO/IEC 27001:2022 Anhang A und praktischen Clarysec-Nachweisartefakten.

An dieser Stelle hört das Register auf, eine Tabellenkalkulation zu sein, und wird zu einem Nachweismodell. Jede Zeile sollte einen Vertragsverantwortlichen, Lieferantenverantwortlichen, Serviceverantwortlichen, Geschäftsverantwortlichen und Compliance-Verantwortlichen haben. Jede kritische Beziehung sollte über einen Risikoeintrag, eine Checkliste für Vertragsklauseln, eine Asset-Verknüpfung und einen Überwachungsrhythmus verfügen.

Praxisbeispiel: einen IKT-Vertrag auf ISO 27001-Nachweise abbilden

Angenommen, ein Finanzunternehmen nutzt eine cloudbasierte Plattform für Betrugsanalysen. Der Service nimmt Transaktionsmetadaten auf, unterstützt Echtzeit-Betrugsscorings, integriert sich in die Zahlungsplattform, speichert pseudonymisierte Kundenkennungen, nutzt einen Cloud-Hosting-Subunternehmer und stellt Managed Support von einem genehmigten Drittstaatenstandort bereit.

Eine schwache Registerzeile lautet: „Anbieter: FraudCloud. Service: Betrugsanalyse. Vertrag unterzeichnet. Kritisch: ja.“

Eine aufsichtstaugliche Registerzeile sieht deutlich anders aus.

Nun kann das Compliance-Team ein stimmiges Nachweispaket erstellen. Das Lieferantenregister belegt, dass der Anbieter existiert und einen Verantwortlichen hat. Das Asset-Inventar belegt, dass die internen Systeme, APIs, Datenbestände und Protokolle bekannt sind. Die Vertragscheckliste belegt, dass verbindliche DORA-Klauseln geprüft wurden. Die Risikobeurteilung belegt, dass Konzentration, Unterauftragsvergabe, Datenschutz und operative Resilienz berücksichtigt wurden. Das Statement of Applicability zeigt, welche Kontrollen ausgewählt wurden. Die Überwachungsprüfung belegt, dass die Vereinbarung nach dem Onboarding nicht in Vergessenheit geraten ist.

Der Zenith Blueprint, Phase Risikomanagement, Step 13, empfiehlt genau diese Art der Nachvollziehbarkeit:

Verordnungen querverweisen: Wenn bestimmte Kontrollen speziell umgesetzt werden, um GDPR, NIS2 oder DORA einzuhalten, können Sie dies entweder im Risikoregister als Teil der Begründung der Risikoauswirkungen oder in den SoA-Notizen vermerken.

So wird das DORA-Register zu ISO 27001-Nachweis statt zu paralleler Bürokratie.

In der Lieferanten- und Subunternehmerkette scheitert Registerqualität am häufigsten

Die größten Registermängel entstehen nicht durch fehlende Hauptanbieter. Sie entstehen durch verdeckte Abhängigkeitsketten.

Ein Managed-Security-Anbieter kann eine SIEM-Plattform, einen Endpoint-Telemetrie-Agenten, ein Ticketsystem und ein Offshore-Triage-Team nutzen. Ein Zahlungsdienstleister kann von Cloud-Hosting, Identitätsdiensten, Betrugsdatenbanken und Settlement-Konnektivität abhängen. Ein SaaS-Anbieter kann sich auf mehrere Unterauftragsverarbeiter für Analytik, E-Mail, Observability, Kundensupport und Backups stützen.

DORA Article 29 lenkt den Fokus auf Konzentrations- und Unterauftragsrisiken. NIS2 Article 21 verlangt ebenfalls Sicherheit der Lieferkette für direkte Lieferanten und Dienstleister und erwartet, dass Einrichtungen lieferantenspezifische Schwachstellen, die Gesamtqualität von Produkten, Cybersicherheitspraktiken von Lieferanten und Verfahren für sichere Entwicklung berücksichtigen. Für Finanzunternehmen, die unter DORA fallen, fungiert DORA als sektorspezifisches Regelwerk für überlappende NIS2-Anforderungen an Cybersicherheitsrisikomanagement und Vorfallmeldung; die Logik der Lieferkette ist jedoch ausgerichtet.

Clarysecs Zenith Blueprint, Phase „Controls in Action“, Step 23, gibt eine praktische Anweisung:

Identifizieren Sie für jeden kritischen Lieferanten, ob er Subunternehmer oder Unterauftragsverarbeiter einsetzt, die Zugriff auf Ihre Daten oder Systeme haben können. Dokumentieren Sie, wie Ihre Informationssicherheitsanforderungen an diese Parteien weitergegeben werden, entweder über die Vertragsbedingungen Ihres Lieferanten oder über Ihre eigenen direkten Klauseln.

Genau hier benötigen viele Organisationen 2026 Nachbesserung. Verträge, die vor der DORA-Vorbereitung geschlossen wurden, enthalten möglicherweise keine Transparenz zu Subunternehmern, Rechte auf Auditnachweise, Zusammenarbeit mit Behörden, Unterstützung bei Vorfällen, Exit-Unterstützung oder Zusagen zu Standorten. Das Register sollte daher einen Status zur Vertragsnachbesserung enthalten, z. B. abgeschlossen, Lücke akzeptiert, Neuverhandlung läuft oder Exit-Option erforderlich.

Cross-Compliance: DORA, NIS2, GDPR und NIST benötigen dieselbe Wahrheit über Abhängigkeiten

Ein gut gestaltetes DORA-Informationsregister unterstützt mehr als DORA.

NIS2 Article 20 macht Cybersicherheit durch Genehmigung, Aufsicht und Schulung zur Verantwortung des Leitungsorgans. Article 21 verlangt Risikoanalyse, Richtlinien, Umgang mit Vorfällen, Kontinuität, Sicherheit der Lieferkette, sichere Beschaffung und Wartung, Wirksamkeitsbewertung, Cyberhygiene, Kryptografie, HR-Sicherheit, Zugriffskontrolle, Asset-Management und MFA, sofern angemessen. Diese Bereiche überschneiden sich stark mit ISO/IEC 27001:2022 und dem Nachweismodell des Registers.

GDPR ergänzt die Rechenschaftspflicht im Datenschutz. Sein räumlicher Anwendungsbereich kann für Organisationen innerhalb und außerhalb der EU gelten, die personenbezogene Daten im Kontext von Niederlassungen in der EU verarbeiten, Waren oder Dienstleistungen für Personen in der EU anbieten oder deren Verhalten beobachten. Die GDPR-Definitionen von Verantwortlichem, Auftragsverarbeiter, Verarbeitung, Pseudonymisierung und Verletzung des Schutzes personenbezogener Daten sind direkt relevant für die IKT-Lieferantenzuordnung. Wenn das DORA-Register IKT-Anbieter und Subunternehmer identifiziert, aber keine Rollen bei der Verarbeitung personenbezogener Daten, Datenkategorien, Standorte und Sicherheitsmaßnahmen ausweist, unterstützt es keine GDPR-Nachweise.

NIST CSF 2.0 bietet eine weitere hilfreiche Perspektive. Die GOVERN-Funktion verlangt, dass Organisationen Auftrag, Erwartungen der Interessenträger, Abhängigkeiten, gesetzliche und vertragliche Anforderungen, Services, von denen andere abhängen, und Services, von denen die Organisation abhängt, verstehen. Die GV.SC-Ergebnisse zur Lieferkette fordern ein Programm zum Management von Risiken in der Lieferkette, definierte Lieferantenrollen, Integration in das Unternehmensrisikomanagement, Lieferantenkritikalität, Vertragsanforderungen, Due Diligence, Lebenszyklusüberwachung, Vorfallskoordination und Planung nach Beendigung der Geschäftsbeziehung.

Eine praktische Cross-Compliance-Sicht sieht wie folgt aus.

Der Zweck besteht nicht darin, fünf Compliance-Arbeitsstränge zu schaffen. Der Zweck besteht darin, ein Nachweismodell zu schaffen, das für jedes Rahmenwerk gefiltert werden kann.

Aus Sicht des Auditors

Eine DORA-Aufsicht wird sich auf Vollständigkeit, kritische oder wichtige Funktionen, vertragliche Vereinbarungen, Unterauftragsvergabe, Konzentrationsrisiko, Governance, Berichterstattung und die Frage konzentrieren, ob das Register gepflegt wird. Sie kann eine Stichprobe kritischer Anbieter anfordern und erwartet dann Vertragsklauseln, Risikobeurteilungen, Exit-Strategien, Bedingungen zur Unterstützung bei Vorfällen und Nachweise zur Aufsicht durch das Management.

Ein Auditor nach ISO/IEC 27001:2022 wird beim ISMS-Geltungsbereich, den interessierten Parteien, regulatorischen Verpflichtungen, der Risikobeurteilung, dem Statement of Applicability, der operativen Steuerung und den dokumentierten Informationen beginnen. Er wird prüfen, ob Lieferantenbeziehungen und Asset-Inventare gepflegt werden, ob extern bereitgestellte Prozesse gesteuert werden, ob Änderungen Neubewertungen auslösen und ob Nachweise die behauptete Umsetzung der Kontrollen stützen.

Ein Assessor nach NIST CSF 2.0 fragt häufig nach aktuellen und Zielprofilen, Governance-Erwartungen, Abhängigkeitsabbildung, Lieferantenkritikalität, Vertragsintegration, Lebenszyklusüberwachung und priorisierten Verbesserungsmaßnahmen.

Ein an COBIT 2019 orientierter Auditor wird typischerweise Governance-Verantwortung, Prozessverantwortlichkeit, Entscheidungsrechte, Leistungsüberwachung, Risikoberichterstattung und Assurance prüfen. Er wird fragen, ob das Register in die Unternehmensführung eingebettet ist und nicht nur durch Compliance gepflegt wird.

Zenith Controls hilft, diese Perspektiven zu übersetzen, indem das Thema in den Kontrollen A.5.9, A.5.19 und A.5.20 aus ISO/IEC 27001:2022 Anhang A verankert wird und anschließend eine Cross-Compliance-Interpretation genutzt wird, um Assets, Lieferantenbeziehungen und Lieferantenvereinbarungen mit regulatorischen, Governance- und Auditerwartungen zu verbinden. Das ist der Unterschied zwischen „wir haben ein Register“ und „wir können das Register belastbar vertreten“.

Clarysecs KMU-Audit and Compliance Monitoring Policy Richtlinie zur Audit- und Compliance-Überwachung - KMU adressiert ebenfalls die Nachweisqualität:

Metadaten, z. B. wer sie wann und aus welchem System erhoben hat, müssen dokumentiert werden.

Diese Anforderung ist klein, aber wirkungsvoll. Bei einer Nachweisanforderung im Jahr 2026 ist eine Tabellenkalkulation ohne Erhebungsmetadaten schwach. Ein Registerexport mit Quellsystem, Extraktionsdatum, verantwortlichem Eigentümer, Genehmigungsstatus und Prüfturnus ist deutlich stärker.

Häufige Feststellungen zum DORA-Informationsregister im Jahr 2026

Die häufigsten Feststellungen sind praktischer Natur.

Erstens: Unvollständigkeit des Registers. Cloud-Services, Support-Werkzeuge, Monitoring-Plattformen, Entwicklerwerkzeuge, Ticketsysteme und Datenanalyseplattformen fehlen häufig, weil sie durch die Beschaffung nicht als IKT-Services klassifiziert wurden.

Zweitens: schwache Kritikalitätslogik. Manche Teams stufen Anbieter auf Grundlage des Ausgabenvolumens als kritisch ein, nicht anhand der geschäftlichen Auswirkungen. DORA interessiert, ob der IKT-Service eine kritische oder wichtige Funktion unterstützt.

Drittens: Lücken bei Vertragsnachweisen. Ältere Lieferantenvereinbarungen enthalten häufig keine DORA-fähigen Klauseln zu Auditrechten, Unterstützung bei Vorfällen, Unterauftragsvergabe, Zusammenarbeit mit Behörden, Servicestandorten, Datenrückgabe, Kündigung und Exit-Unterstützung.

Viertens: mangelhafte Asset-Verknüpfung. Register listen Anbieter auf, verknüpfen diese aber nicht mit Anwendungen, Datenbeständen, APIs, Identitäten, Protokollen, Infrastruktur oder Business Services. Dies erschwert die Auswirkungsanalyse bei Vorfällen und Lieferantenausfällen.

Fünftens: Intransparenz bei Subunternehmern. Die Organisation kennt den Hauptanbieter, kann aber nicht erklären, welche Unterauftragsverarbeiter oder technischen Anbieter den Service unterstützen.

Sechstens: fehlende Änderungs-Auslöser. Ein Anbieter fügt einen neuen Unterauftragsverarbeiter hinzu, ändert die Hosting-Region, migriert die Architektur oder ändert den Support-Zugriff, aber niemand aktualisiert das Register oder bewertet das Risiko neu.

Siebtens: kein Nachweisrhythmus. Es gibt keine definierte Häufigkeit für Lieferantenüberprüfung, Vertragsprüfung, Asset-Validierung, Abgleich des Cloud-Registers oder Managementberichterstattung.

Diese Probleme sind lösbar, aber nur, wenn das Register Verantwortliche und Workflows hat.

Ein praktischer 30-Tage-Verbesserungsplan

Beginnen Sie mit dem Geltungsbereich. Identifizieren Sie alle Geschäftsfunktionen, die nach DORA kritisch oder wichtig sein können. Listen Sie für jede Funktion die IKT-Services auf, von denen sie abhängt. Beginnen Sie nicht mit Beschaffungsausgaben. Beginnen Sie mit der operativen Abhängigkeit.

Gleichen Sie die zentralen Datenquellen ab: Lieferantenregister, Vertrags-Repository, Asset-Inventar und Register für Cloud-Services. Ergänzen Sie Datenschutzaufzeichnungen zu Auftragsverarbeitern und Incident-Response-Abhängigkeiten, soweit relevant. Das Ziel ist nicht Perfektion am ersten Tag. Das Ziel ist ein einheitliches Registerrückgrat, in dem Unbekanntes klar gekennzeichnet ist.

Klassifizieren Sie Lieferanten und Services anhand von Kriterien wie unterstützter Funktion, Datensensitivität, operativer Ersetzbarkeit, Konzentration, Unterauftragsvergabe, Standorten, Auswirkungen von Vorfällen, Wiederherstellungszeit und regulatorischer Relevanz.

Prüfen Sie Verträge für jede kritische oder wichtige IKT-Vereinbarung. Prüfen Sie, ob der Vertrag Servicebeschreibungen, Bedingungen für die Unterauftragsvergabe, Standorte, Datenschutzverpflichtungen, Zugriff und Wiederherstellung, Service Levels, Unterstützung bei Vorfällen, Auditrechte, Zusammenarbeit mit Behörden, Kündigung, Teilnahme an Schulungen und Exit-Unterstützung enthält.

Ordnen Sie ISO-Nachweise für jede kritische Vereinbarung zu. Verknüpfen Sie Asset-Aufzeichnungen, Risikobeurteilungseinträge, SoA-Kontrollen, Lieferanten-Due-Diligence, Überwachungsprüfungen, Kontinuitätspläne, Incident-Playbooks und Nachweise zur Exit-Strategie.

Legen Sie den Prüfturnus fest. Kritische Anbieter können quartalsweise Überprüfung, jährliche Assurance, Vertragsprüfung vor Verlängerung und sofortige Neubewertung bei wesentlichen Änderungen erfordern. Nicht kritische Anbieter können jährlich oder bei auslösenden Ereignissen überprüft werden.

Nutzen Sie diese Checkliste, um das Register in einen operativen Prozess zu überführen:

• Benennen Sie einen DORA-Registerverantwortlichen und einen stellvertretenden Verantwortlichen.
• Verknüpfen Sie jede Registerzeile mit einer Vertragskennung und einem Lieferantenverantwortlichen.
• Verknüpfen Sie jeden kritischen oder wichtigen IKT-Service mit Geschäftsfunktion und Asset-Aufzeichnungen.
• Ergänzen Sie Felder für Subunternehmer und Unterauftragsverarbeiter, auch wenn sie zunächst als unbekannt markiert werden.
• Ergänzen Sie den Status von Vertragsklauseln für DORA-kritische Bedingungen.
• Ergänzen Sie Risiko- und SoA-Referenzen nach ISO/IEC 27001:2022.
• Ergänzen Sie GDPR-Rolle, personenbezogene Daten und Standortfelder, soweit anwendbar.
• Ergänzen Sie Prüfturnus und Metadaten zur letzten Überprüfung.
• Erstellen Sie Eskalationsregeln für fehlende Klauseln, unbekannte Subunternehmer und hohes Konzentrationsrisiko.
• Berichten Sie Kennzahlen zur Registerqualität an das Management.

An dieser Stelle wirken Clarysecs 30-Schritte-Umsetzungsmethode, Richtlinienset und Zenith Controls zusammen. Der Zenith Blueprint liefert den Umsetzungspfad, von Risikobehandlung und SoA-Nachvollziehbarkeit in Step 13 über das Asset-Inventar in Step 22 bis zu Lieferantenkontrollen in Step 23. Die Richtlinien definieren, wer Register führen muss, welche vertraglichen und Asset-Nachweise vorhanden sein müssen und wie Compliance-Metadaten erfasst werden. Zenith Controls liefert den Cross-Compliance-Kompass, um dieselben Nachweise über DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST und COBIT 19-Auditerwartungen hinweg abzubilden.

Machen Sie das Register zum Nachweis, bevor die Aufsicht danach fragt

Wenn Ihr DORA-Informationsregister noch immer eine Tabellenkalkulation ist, die nicht mit Verträgen, Assets, Lieferanten, Subunternehmern und ISO 27001-Nachweisen verbunden ist, ist 2026 das Jahr, dies zu beheben.

Beginnen Sie mit dem Zenith Blueprint Zenith Blueprint, um Risikobehandlung, Asset-Inventar und Lieferanten-Governance zu verbinden. Nutzen Sie Zenith Controls Zenith Controls, um Kontrollen A.5.9, A.5.19 und A.5.20 aus ISO/IEC 27001:2022 Anhang A in Cross-Compliance-Nachweise zu überführen. Operationalisieren Sie die Anforderungen anschließend über Clarysecs Richtlinien zu Lieferanten, Assets, Cloud, rechtlicher Einhaltung und Audit-Überwachung, einschließlich Richtlinie zur Lieferanten- und Drittparteiensicherheit - KMU, Richtlinie zum Management von Risiken aus Lieferantenabhängigkeiten, Richtlinie zur Lieferanten- und Drittparteiensicherheit, Richtlinie zum Asset-Management - KMU, Richtlinie zum Asset-Management, Richtlinie zur Nutzung von Cloud-Diensten - KMU, Richtlinie zur rechtlichen und regulatorischen Einhaltung und Richtlinie zur Audit- und Compliance-Überwachung - KMU.

Der beste Zeitpunkt, die Registerqualität zu verbessern, ist vor einer Anfrage der Aufsicht, einem internen Audit, einem Lieferantenausfall oder einer Vertragsverlängerung. Der nächstbeste Zeitpunkt ist jetzt. Laden Sie die relevanten Clarysec-Richtlinien herunter, gleichen Sie Ihr aktuelles Register mit dem oben dargestellten Nachweismodell ab und buchen Sie eine DORA-Registerbewertung, um verstreute Lieferantendaten in aufsichtstaugliche Nachweise zu verwandeln.