.png){kind=logo}
Für Finanzunternehmen reicht es nicht, Risiken nur vertraglich oder organisatorisch zu adressieren: DORA fordert IKT-Drittparteien-Risikomanagement, Exit-Strategien und den Schutz von Daten auch während der Verarbeitung. enclaive adressiert diese Anforderungen mit multi-cloud-fähigem Confidential Computing sowie kundenseitiger Schlüsselhoheit und Remote Attestation.
Entwickelt und betrieben in Deutschland. Bewährt in Projekten des öffentlichen Sektors.
DORA (Verordnung (EU) 2022/2554) schafft einen einheitlichen Rahmen für die digitale operationale Resilienz im europäischen Finanzsektor. Sie gilt unter anderem für Banken, Versicherer, Wertpapierfirmen, Zahlungs- und E-Geld-Institute, Kryptowerte-Dienstleister, Handelsplätze und Fondsverwalter. Für kritische IKT-Drittdienstleister schafft DORA zusätzlich einen europäischen Aufsichtsrahmen. Seit dem 17. Januar 2025 ist die Verordnung unmittelbar anzuwenden.
Drei organisatorische Punkte sind für die technische Umsetzung besonders relevant:
Die technische Umsetzung einiger Anforderungen stellt Finanzunternehmen vor größere Probleme, als es reine Gesetzestext vermuten lässt.
Die DORA-Bereiche, in denen Confidential Computing technische Kontrollen ergänzt – und welche Nachweise daraus für Auditoren und Aufsichtsbehörden entstehen können.
Workloads laufen in hardwareisolierten Confidential-Computing-Umgebungen. So werden Daten nicht nur at Rest und in Transit, sondern auch während der Verarbeitung geschützt.
Attestation-Ergebnisse dokumentieren, welche Workloads in einer verifizierten geschützten Ausführungsumgebung gelaufen sind. Bei entsprechender Protokollierung entsteht daraus nachvollziehbare technische Evidenz.
Kundenseitig kontrollierte Schlüssel und eine providerübergreifend einsetzbare Architektur reduzieren technische Abhängigkeiten und erleichtern den Wechsel auf eine andere unterstützte Infrastruktur.
Ein tatsächlich durchgeführter Migrationstest zeigt, ob Workload, Schlüsselkontrolle und Sicherheitsmechanismen auf der Zielinfrastruktur funktionieren – einschließlich dokumentiertem Aufwand und verbleibenden Abhängigkeiten.
Dieselben Schutzmechanismen können über verschiedene unterstützte Cloud- und On-Premises-Umgebungen hinweg eingesetzt werden. So muss das Sicherheitsmodell bei einer Multi-Provider-Strategie nicht für jeden Anbieter neu aufgebaut werden.
Bereitstellungs- und Konfigurationsdaten belegen, auf welchen Providern und Infrastrukturen der Workload mit denselben definierten Sicherheitskontrollen betrieben werden kann.
Remote Attestation ermöglicht eine unabhängige Prüfung von Identität, Konfiguration und Integrität der Ausführungsumgebung und des Workloads.
Kryptografisch signierte Attestation Reports können autorisierten Prüfern bereitgestellt und gegen die definierten Referenzwerte und Policies verifiziert werden.
Schlüssel und Secrets werden nur an Workloads freigegeben, deren attestierte Identität und Zustand den festgelegten Policies entsprechen. Infrastrukturprivilegien allein ermöglichen damit keinen regulären Klartextzugriff.
Key-Release-Logs zeigen, welcher verifizierte Workload wann Schlüsselmaterial erhalten hat – oder warum eine Freigabe verweigert wurde.
Attestation, Key Release und Policy Enforcement sind in den laufenden Betrieb integriert, statt erst für einen Audit nachträglich rekonstruiert zu werden.
Aktuelle Attestation-Ergebnisse sowie protokollierte Schlüssel- und Policy-Ereignisse können jederzeit abgerufen und in bestehende Kontroll- und Auditprozesse übernommen werden.
Die Artikelverweise dienen der Orientierung und stellen keine Rechtsberatung dar. Die technischen Regulierungsstandards (RTS) konkretisieren die jeweiligen DORA-Anforderungen.
enclaive setzt dort an, wo technische Schutzmaßnahmen und belastbare Nachweise gefragt sind. Confidential Computing, kundenseitig kontrollierte Schlüssel und Remote Attestation schützen Data in Use, begrenzen privilegierte Zugriffe und können auf Abruf technische Evidenz für Kontroll- und Auditprozesse liefern. So werden zentrale Schutzmaßnahmen nicht nur beschrieben, sondern technisch überprüfbar umgesetzt.
Was DORA-Verantwortliche wissen wollen
Macht uns der Einsatz von enclaive und Confidential Computing DORA-konform?
Nein. DORA-Compliance umfasst unter anderem IKT-Risikomanagement, Incident-Prozesse, Resilienztests, das Informationsregister, Verträge und technische Kontrollen. enclaive unterstützt konkrete technische Anforderungen und liefert zusätzliche Nachweise – die Gesamtverantwortung bleibt beim Finanzunternehmen
Wie unterstützt enclaive unsere Exit-Strategie?
Auf drei Arten: Schlüssel bleiben unter Ihrer Kontrolle, Sicherheitsmechanismen lassen sich cloud-agnostisch konsistent über unterschiedlichen Infrastrukturen einsetzen und Workloads können in Ihren eigenen Cloud-Accounts laufen. Damit wird ein Providerwechsel technisch besser plan- und testbar.
Wir fallen unter DORA und NIS2. Müssen wir beide Regelwerke parallel erfüllen?
Nicht für dieselben Anforderungen. Für Finanzunternehmen gilt DORA in zentralen Bereichen wie IKT-Risikomanagement und Incident Reporting als sektorspezifische Regelung anstelle der entsprechenden NIS2-Vorgaben. NIS2 kann außerhalb dieser Überschneidung oder für andere Gesellschaften einer Unternehmensgruppe weiterhin relevant sein. Die konkrete Abgrenzung sollte Ihre Rechts- bzw. Compliance-Abteilung vornehmen.
Unterstützt Confidential Computing auch Threat-Led Penetration Testing (TLPT)?
Ja – als Teil der zu testenden Sicherheitsarchitektur. Confidential Computing kann privilegierte Zugriffspfade auf sensible Workloads stark begrenzen; attestierungsgebundene Schlüsselfreigaben und Attestation-Ergebnisse schaffen zudem überprüfbare technische Informationen für den Test. Die TLPT-Pflicht selbst wird dadurch natürlich nicht ersetzt. DORA sieht TLPT für bestimmte Finanzunternehmen ausdrücklich vor.
Wenn enclaive ein IKT-Drittdienstleister ist: Was bedeutet das für Art. 30 DORA?
Ist enclaive entsprechend vertraglich eingebunden, gelten die einschlägigen DORA-Anforderungen an IKT-Drittdienstleister. Art. 30 verlangt unter anderem klar geregelte Leistungen, Sicherheitsanforderungen sowie – bei kritischen oder wichtigen Funktionen – Zugangs-, Inspektions- und Audit-Rechte.
Unser Cloud-Provider wird unter DORA bereits als kritischer IKT-Drittdienstleister beaufsichtigt. Reicht das nicht aus?
Nein. Die Aufsicht über einen kritischen IKT-Drittdienstleister ersetzt nicht Ihre eigenen DORA-Pflichten. IKT-Risikomanagement, laufende Überwachung, Konzentrationsrisiken und Exit-Strategien bleiben beim Finanzunternehmen. Confidential Computing kann die technische Abhängigkeit reduzieren, indem privilegierte Provider-Zugriffe auf geschützte Daten verhindert werden.
Bring your register, your gap analysis, or your exit-plan problem
Tell us where your DORA program stands — the RTS requirement still open, the concentration-risk finding, or the exit strategy your supervisor won't accept as written. We'll show you which controls close the technical gaps and what the evidence looks like.
