Ein Digital-Abo verkauft sich nicht an der Bezahlschranke. Es verkauft sich in den Sekunden davor, w…
DORA-Compliance im E-Commerce: Was die Verordnung für Composable-Frontends im Finanzsektor bedeutet
Es gibt einen Moment in jedem Compliance-Projekt, in dem aus einer juristischen Verordnung plötzlich eine Architekturfrage wird. Bei DORA, dem Digital Operational Resilience Act der Europäischen Union, ist dieser Moment für viele Banken, Versicherer und regulierte E-Commerce-Plattformen genau jetzt erreicht. Die Verordnung ist seit Anfang 2025 vollumfänglich anwendbar, und in den vergangenen Monaten hat sich gezeigt: Die schwierigste Frage ist selten "Sind wir compliant?", sondern "Welche Teile unseres Stacks fallen überhaupt unter den Geltungsbereich und wie behandeln wir den Rest?".
Dieser Beitrag richtet sich an IT-Architekten, CISOs und Digital-Verantwortliche in regulierten Branchen, die ihre digitalen Storefronts neu bewerten müssen. Wir erklären, was DORA für die Frontend-Schicht moderner Finanz- und Versicherungsanwendungen bedeutet, warum eine Composable-Commerce-Architektur das Risiko strukturell reduziert und welche konkreten Schritte Sie heute gehen können, um Ihren digitalen Vertriebskanal DORA-konform aufzustellen.
DORA in einem Satz: Worum geht es wirklich?
DORA verpflichtet Finanzunternehmen, ihre gesamte IKT-Lieferkette so aufzustellen, dass sie Störungen widerstehen, schnell reagieren und sich erholen können. Anders als die DSGVO, die primär Datenflüsse adressiert, geht es bei DORA um Funktionsfähigkeit unter Druck. Was passiert, wenn ein Cloud-Anbieter ausfällt? Wenn eine API über Stunden nicht erreichbar ist? Wenn ein Sicherheitsvorfall Teile Ihrer Customer Journey lahmlegt?
Die Antwort darauf darf nicht erst im Krisenfall gesucht werden. DORA verlangt, dass Sie sie vorab dokumentieren, testen und gegenüber der zuständigen Aufsichtsbehörde belegen können. Dazu zählen ein vollständiges Verzeichnis aller IKT-Drittdienstleister (Article 28), klare vertragliche Mindeststandards und ein Risikomanagement, das auch Lieferketten zweiter Ordnung berücksichtigt.
Für E-Commerce-Verantwortliche in der Finanzbranche heißt das: Ihre Storefront, Ihr Headless-CMS, Ihr Content-Delivery-Layer alles, was zwischen Kunde und Kernsystem steht ist Teil dieses Risikobildes. Auch dann, wenn diese Komponenten formal nicht als "kritisch" eingestuft werden.
Kritisch oder nicht kritisch? Die wichtigste Frage zuerst
DORA unterscheidet zwischen "kritischen IKT-Drittdienstleistern" und normalen Anbietern. Diese Klassifizierung entscheidet über die Tiefe der Anforderungen, die Aufsichtsrechte der Behörden und die vertraglichen Rahmenbedingungen.
Eine Composable-Commerce-Plattform für die Storefront fällt in den meisten Konstellationen nicht in die kritische Kategorie. Sie liefert Inhalte, rendert Produktdetails, übersetzt Marketingbotschaften in Pixel aber sie verarbeitet keine Transaktionen, sie hält keine Kontostände und sie führt keine Kreditprüfungen durch. Diese Trennung ist genau der Hebel, den DORA belohnt.
Es gibt aber Konstellationen, in denen die Klassifizierung kippt. Wenn Ihre Storefront den authentifizierten Kundenbereich einer Versicherung darstellt, dort Vertragsdokumente verfügbar macht, Schadenmeldungen entgegennimmt oder Onboarding-Flows für regulierte Produkte abbildet, dann werden Aufsichtsbehörden den Frontend-Layer durchaus als geschäftskritisch werten. Die Klassifizierung erfolgt also nicht über den Anbieter, sondern über den konkreten Anwendungsfall.
Die erste Aufgabe für Ihr Team ist deshalb eine ehrliche Bestandsaufnahme: Welche Funktionen laufen heute über Ihre Storefront? Welche davon sind kundenseitig kritisch also so beschaffen, dass ihr Ausfall einen meldepflichtigen IKT-bezogenen Vorfall im Sinne von Article 19 auslöst?
Warum Composable Commerce das DORA-Risiko strukturell senkt
Die Architektur Ihres digitalen Vertriebskanals ist keine ästhetische Entscheidung. Sie ist eine Risikoentscheidung. Und genau hier zeigt sich der eigentliche regulatorische Vorteil moderner Composable-Architekturen.
Eine monolithische Plattform koppelt Frontend, Business-Logik, Datenpersistenz und Integrationen in einer Codebasis. Wenn ein Modul kompromittiert wird, sind oft mehrere Funktionen betroffen. Das Risikoprofil ist breit, die Wiederherstellung komplex, die Tests aufwendig.
Eine Composable-Architektur trennt diese Schichten konsequent. Ihr Frontend kommuniziert über APIs mit dem Kernsystem, dem Identity-Provider, der Kontoverwaltung. Fällt der Frontend-Layer aus, bleibt das Kernsystem funktionsfähig. Fällt eine spezialisierte Komponente aus, lässt sie sich isoliert ersetzen, ohne den Rest des Stacks anzufassen. Diese Isolation ist nicht nur eine technische Eleganz sie ist im Sinne von DORA Article 6 ein konkreter Beitrag zur digitalen operativen Resilienz.
Drei Eigenschaften machen den Unterschied:
- Klar abgegrenzte Verantwortungsbereiche, die im IKT-Risikomanagement-Rahmen sauber dokumentierbar sind.
- Unabhängige Wiederherstellbarkeit einzelner Komponenten ohne Dominoeffekte auf Kernsysteme.
- Granulare Sicherheitskontrollen, weil jede Komponente ihren eigenen Threat-Model-Kontext hat und nicht im Schatten eines monolithischen Sicherheitskonzepts steht.
Was Sie von Ihrem Frontend-Anbieter im DORA-Kontext erwarten dürfen
DORA Articles 28 bis 30 definieren konkrete Anforderungen an Verträge mit IKT-Drittdienstleistern. Auch wenn Ihre Storefront-Plattform nicht als kritisch eingestuft ist, sollten Sie folgende Punkte in der Lieferantenbewertung adressieren:
Informationsregister und Asset-Transparenz. Ihr Anbieter sollte ein vollständiges Verzeichnis seiner eigenen Sub-Lieferanten führen und Ihnen die Daten liefern, die Sie zum Befüllen Ihres "Register of Information" nach den Implementing Technical Standards (ITS) benötigen.
Vorfallsmanagement mit klaren Eskalationsketten. Wenn ein sicherheitsrelevantes Ereignis auftritt, müssen Sie es innerhalb der DORA-Fristen melden können. Ohne klare SLAs und Eskalationspfade auf Anbieterseite ist das illusorisch.
Resilienztests. Penetration-Tests, regelmäßige Vulnerability-Scans, Wiederherstellungsübungen für die Plattform sollten mindestens jährlich erfolgen und auditierbar dokumentiert sein.
Vertragliche Bereitschaft. Ihr Anbieter sollte vorbereitete DORA-Addenda anbieten, die die Mindestinhalte aus Article 30 abdecken: Service-Beschreibung, Performance-Targets, Reporting-Pflichten, Audit-Rechte, Exit-Strategie.
Geografische Datenhaltung und Sub-Processing-Transparenz. Gerade im DACH-Raum spielt die Frage, in welchem Rechtsraum welche Daten verarbeitet werden, eine wachsende Rolle. Anbieter, die Sub-Processing transparent machen, ersparen Ihnen langwierige Klärungen mit der internen Compliance.
Praktische Schritte: So bewerten Sie Ihren Storefront-Layer DORA-konform
Wenn Sie heute mit der Bewertung beginnen, empfehlen wir folgende Reihenfolge:
Schritt 1 Funktionsinventur. Listen Sie jede Funktion Ihrer Storefront einzeln auf: Produkt-Browsing, Filter, Account-Management, Onboarding, Schadenmeldung, Vertragsdownload. Klassifizieren Sie jede einzeln nach Auswirkungsrisiko bei Ausfall.
Schritt 2 Datenflusskarte. Zeichnen Sie nach, welche Daten zwischen Storefront, Kernsystem, Identity-Provider und Drittanbietern fließen. DORA verlangt vor allem Klarheit über genau diese Schnittstellen.
Schritt 3 Klassifizierung der Komponenten. Nicht jede Komponente ist gleich risikoreich. Eine Marketing-Landingpage hat ein anderes Risikoprofil als ein authentifizierter Self-Service-Bereich. Behandeln Sie diese Risikoklassen unterschiedlich.
Schritt 4 Lieferantenbewertung. Gleichen Sie die Anforderungen aus den Articles 28-30 mit den Antworten Ihrer Anbieter ab. Wo gibt es Lücken? Wo brauchen Sie zusätzliche Vertragsanpassungen?
Schritt 5 Resilienztest am realen Use Case. Spielen Sie ein Szenario durch: Was passiert, wenn Ihr Frontend-Provider drei Stunden ausfällt? Welche Customer-Journeys brechen ab? Welche bleiben dank Composable-Trennung verfügbar?
Schritt 6 Dokumentation und Register-Pflege. Halten Sie alles in einem versionierten Register fest. DORA verlangt nicht nur, dass Sie es einmal aufschreiben, sondern dass Sie es kontinuierlich pflegen.
Internationale Dimension: DORA und Cross-Border-Storefronts
Viele Finanzdienstleister im DACH-Raum betreiben Storefronts in mehreren EU-Ländern. DORA ist zwar eine harmonisierte Verordnung, aber nationale Aufsichtsbehörden interpretieren einzelne Resilienzanforderungen unterschiedlich. Das gilt insbesondere für die Definition meldepflichtiger Vorfälle und die Anforderungen an Stresstests im Rahmen des Threat-Led Penetration Testing (TLPT).
Composable-Frontends bieten hier einen pragmatischen Vorteil: Internationalisierung lässt sich auf der Präsentationsschicht abbilden, während die regulatorische Logik im Backend bleibt. So können Sie für jedes Land die jeweils geforderten Funktionen abbilden von Cookie-Bannern über lokale Identifikationsverfahren bis hin zu sprachspezifischen Compliance-Hinweisen ohne dass jede Anpassung tief in den Kern Ihres Stacks eingreift.
Mehrsprachige Storefronts sollten dabei keine Workaround-Architektur sein. Wer von Anfang an auf einen internationalisierungsfähigen Frontend-Stack setzt, hat im DORA-Audit einen starken Beleg für strukturierte Risikobeherrschung.
Häufig gestellte Fragen zur DORA-Compliance von Composable Frontends
Wer entscheidet, ob meine Storefront als kritisch eingestuft wird?
Die Klassifizierung obliegt dem Finanzunternehmen selbst und basiert auf dessen eigener IKT-Risikoanalyse. Maßgeblich ist nicht der Anbieter, sondern die Funktion, die der Frontend-Layer im Geschäftsmodell übernimmt.
Reicht eine ISO-27001-Zertifizierung des Frontend-Anbieters für DORA aus?
ISO 27001 und SOC 2 Type 2 sind wichtige Bausteine, decken aber nicht alle DORA-Anforderungen ab. Insbesondere die Pflichten zur Vorfallsmeldung, zum Register of Information und zu vertraglichen Mindeststandards gehen über klassische Sicherheitszertifizierungen hinaus.
Müssen wir unsere Storefront migrieren, um DORA-konform zu werden?
Nicht zwingend. Wer heute auf einer monolithischen Plattform sitzt, kann durch ein klares Risikomanagement und vertragliche Anpassungen Compliance erreichen. Der Aufwand ist allerdings deutlich höher als bei einer composable Architektur, weil Sie weniger architektonische Hebel haben, um Risiko zu isolieren.
Wie verhalten sich DORA und DSGVO zueinander?
Beide Verordnungen ergänzen sich. DSGVO regelt den Umgang mit personenbezogenen Daten, DORA regelt die operative Widerstandsfähigkeit der IT-Systeme, die diese Daten verarbeiten. In der Praxis sollten beide Compliance-Programme verzahnt werden ein gemeinsames Verzeichnis der Verarbeitungstätigkeiten und IKT-Drittdienstleister spart erheblichen Aufwand.
Fazit: Resilienz als Architekturentscheidung
DORA ist keine Verordnung, die mit einem zusätzlichen Modul oder einem nachgelagerten Audit erledigt ist. Sie verlangt, dass Resilienz in die Architektur Ihres digitalen Vertriebskanals eingebaut ist. Composable Commerce liefert dafür die strukturellen Voraussetzungen: klare Schnittstellen, isolierte Wiederherstellbarkeit, granulare Risikokontrolle.
Wenn Sie heute eine Storefront-Strategie für 2026 und darüber hinaus entwickeln, sollten Sie DORA nicht als Bremsklotz behandeln, sondern als Argument für genau jene Architektur, die ohnehin bereits aus Geschwindigkeits- und Customer-Experience-Gründen Sinn ergibt. Das Frontend ist längst kein Beiwerk mehr es ist eine eigenständige, regulierte Schicht im Stack. Wer das früh anerkennt, kommt sowohl im Audit als auch im Markt schneller voran.
Sprechen Sie mit unserem Team darüber, wie eine composable Storefront-Architektur Ihren regulatorischen Rahmen unterstützt und wo wir als deutscher Anbieter konkret vertragliche und technische Bausteine für Ihre DORA-Bewertung beisteuern können.
Mehr zur Laioutr-Plattform
Mehr dazu: Der Finanz-Case für ein Investment in eine Composable Frontend Management Platform und Audit Logs in Composable Commerce: Wie lückenlose Nachvollziehbarkeit zum Wettbewerbsvorteil wird.