Diese Woche hat Dries Buytaert auf LinkedIn einen Satz geschrieben, der in Procurement-Abteilungen von Banken, Versicherungen und regulierter Industrie hängenbleiben sollte: „Ein europäischer Vendor heute kann morgen ein US-Vendor sein."

Der Kontext ist die Salesforce-Übernahme von Contentful - ein Headless-CMS, das als europäischer Vendor positioniert war. Über Nacht ändert sich die Eigentümerstruktur, und damit die rechtliche Realität für jeden Customer, der Contentful in einer regulierten Branche einsetzt. Das ist kein Salesforce-Bashing. Das ist Procurement-Realität. Und es ist nicht der erste M&A-Move dieser Art und nicht der letzte.

Dieser Post ist nicht der zweite Migration-FUD-Post zu diesem Thema. Den Tech-Cut haben wir gestern bereits geliefert. Hier geht es um die Procurement-Ebene: 5 Klauseln, die du in den nächsten 30 Tagen in deinen DXP-MSAs durchgehen solltest, und die architektonische Antwort, die das Risiko strukturell reduziert.

Warum gerade jetzt? CLOUD-Act, DORA und die Realität der Eigentümerstruktur

Der US CLOUD Act erlaubt US-Behörden den Zugriff auf Daten, die von US-Unternehmen kontrolliert werden - unabhängig vom physischen Speicherort der Daten. Wenn dein DXP-Vendor heute deutsch oder schweizerisch ist und morgen Teil eines US-Konzerns wird, ändert sich diese Zugriffsmöglichkeit über Nacht. Datenresidenz „in Frankfurt" reicht in dem Moment nicht mehr, in dem der Mutterkonzern in San Francisco sitzt.

Für DACH-Banken, Versicherer, Healthcare-Anbieter und Public-Sector-Customer bedeutet das: Die Eigentümerstruktur des Vendors ist Teil der Compliance-Architektur. Sie wird damit zu einer Procurement-Frage, nicht nur einer Marketing-Frage.

DORA (Digital Operational Resilience Act) macht die Lage für Finanzdienstleister explizit: ICT-Drittparteien müssen identifiziert, klassifiziert und auf Konzentrations- und Substituierbarkeits-Risiko geprüft sein. Ein DXP-Vendor, dessen Eigentumsverhältnisse sich ändern können und dessen Frontend-Layer untrennbar mit dem Backend verbunden ist, erfüllt die Substituierbarkeits-Anforderung nicht. Mehr zum DORA-Kontext im DORA-und-Storefront-Post.

5 Procurement-Klauseln für die nächsten 30 Tage

Diese fünf Klauseln gehören in jeden DXP- und CMS-Vertrag, der in regulierten Branchen läuft. Wenn sie aktuell nicht drin sind, ist das eine Gesprächsgrundlage mit dem Vendor - und im Worst Case eine Exit-Vorbereitung.

1. Change-of-Control-Klausel mit Customer-Exit-Recht

Eine Change-of-Control-Klausel ist Standard in M&A-affinen Verträgen - aber selten in DXP-MSAs. Sie sollte präzise sein: Bei Wechsel der ultimativen Mehrheitsbeteiligung des Vendors (insbesondere bei Wechsel der Country-of-Incorporation der Muttergesellschaft) entsteht ein außerordentliches Kündigungsrecht mit definierter Frist und voller Daten-Portierungs-Pflicht des Vendors. Ohne Vertragsstrafe für den Customer.

Konkret: Welche Frist (typisch 60-120 Tage), welche Datenformate (offene Standards, nicht Vendor-proprietär), welche Migrations-Unterstützung (Service-Level für den Vendor während der Exit-Phase).

2. Data-Sovereignty-Klausel mit Sub-Processor-Audit-Recht

Datenresidenz in der EU ist eine Aussage über den Speicherort. Sie ist keine Aussage über die Datenkontrolle. Eine Data-Sovereignty-Klausel sollte den Unterschied explizit machen: keine Übertragung von Customer-Daten an Sub-Processor außerhalb der EU ohne vorherige schriftliche Zustimmung, jährliches Audit-Recht für den Customer, vollständige Sub-Processor-Liste mit jurisdiktioneller Zuordnung.

Bei einem Vendor-Eigentümerwechsel wird die Sub-Processor-Kette typisch neu geordnet - diese Klausel macht das sichtbar und steuerbar.

3. Frontend-Decoupling-Klausel

Diese ist neu in vielen DXP-Verträgen - und sie ist der direkteste Hebel auf Substituierbarkeits-Risiko. Die Klausel verpflichtet den Vendor, sämtliche Content- und Commerce-Daten über dokumentierte, offene APIs (REST, GraphQL) zugänglich zu machen, ohne dass die Frontend-Rendering-Schicht des Vendors zwingend genutzt werden muss. Konkret: Wenn der Vendor das Frontend morgen einstellt oder unzugänglich macht, bleibt der Datenzugriff erhalten und die Migration auf einen alternativen Frontend-Layer (Eigenbau oder FMP) ist innerhalb von 90 Tagen möglich.

Diese Klausel ist die vertragliche Spiegelung einer technischen Architektur-Entscheidung: Entkopplung von Backend und Frontend. Mehr zum technischen Hintergrund auf unserer Headless-Frontend-Hub-Seite.

4. Concentration-Risk-Klausel (DORA-relevant)

Für DORA-pflichtige Customer ist diese Klausel kein Nice-to-have. Sie verpflichtet den Vendor zur jährlichen Offenlegung seiner kritischen Sub-Processor und deren Konzentrationsrisiken (Cloud-Hyperscaler-Lock-in, CDN-Single-Source-Abhängigkeit, Authentifizierungs-Vendor-Konzentration). Plus: Verpflichtung des Vendors, bei materiellen Änderungen der Sub-Processor-Topologie den Customer innerhalb 30 Tagen schriftlich zu informieren.

5. SCC- und TIA-Pflicht-Klausel mit Re-Negotiation-Trigger

Standard Contractual Clauses und Transfer Impact Assessments sind DSGVO-Pflicht für jeden Datenexport in Drittländer. Die meisten DXP-MSAs haben Standard-SCCs als Anhang. Was häufig fehlt: eine Re-Negotiation-Trigger-Klausel, die SCC und TIA bei materiellen Änderungen der Vendor-Eigentumsstruktur oder bei rechtlichen Entwicklungen im Vendor-Heimatland (Beispiel: neue Surveillance-Gesetzgebung) zwingend neu verhandelt.

Diese fünf Klauseln zusammen bilden die Procurement-Linie. Sie ersetzen keine technische Architektur - aber sie machen die technische Architektur vertraglich durchsetzbar.

Die architektonische Antwort: Frontend-Layer-Entkopplung als Datenhoheits-Strategie

Hier wird die Procurement-Frage zur Architektur-Frage. Eine vertragliche Change-of-Control-Klausel hilft, wenn der Vendor wechselt. Sie hilft nicht, wenn der Customer den Vendor wechseln will, weil das Frontend untrennbar mit dem Backend verbunden ist.

Die strukturelle Antwort: Der Frontend-Layer wird als unabhängige Architektur-Schicht behandelt. Er sitzt auf den APIs des Backend-DXP, aber er gehört nicht zum DXP-Vertrag. Das ist das Grundprinzip einer Frontend Management Platform - und es ist der Kern der Decoupling-Strategie.

Drei konkrete Konsequenzen für regulierte Customer:

Erstens: Wenn der DXP-Vendor wechselt (Eigentümerwechsel oder Vendor-Wechsel), bleibt die Frontend-Schicht stabil. Migration heißt: neuer Connector, nicht neuer Storefront. Implementierungszeit für einen DXP-Wechsel sinkt von typisch 6-18 Monaten auf 4-12 Wochen.

Zweitens: Der Frontend-Layer ist eigenständig hostbar - auf EU-Infrastruktur, mit dokumentierten Sub-Processor, in einem separaten Vertragsverhältnis. Das schließt den CLOUD-Act-Vektor auf der Frontend-Ebene.

Drittens: Die DORA-Substituierbarkeits-Anforderung wird erfüllbar. Backend-Wechsel wird ein konfigurations-getriebener Prozess, kein Replatforming-Projekt. Das ist die Substituierbarkeit, die DORA verlangt - sichtbar gemacht im DORA-Storefront-Kontext.

Mehr zur Daten-Hoheits-Argumentation und zum CLOUD-Act-Kontext findest du in unserem Digital-Sovereignty-Post vom April.

Was das in 30 Tagen konkret heißt

Diese Woche: Die DXP- und CMS-MSAs deines Hauses listen. Welche sind in regulierten Use-Cases im Einsatz (Banking, Insurance, Healthcare, öffentlicher Sektor)? Die Liste ist deine Arbeitsgrundlage.

Nächste zwei Wochen: Die 5 Klauseln gegen jede MSA prüfen. Wo gibt es Lücken? Bei welchen Verträgen ist eine Nachverhandlung realistisch? Bei welchen ist der Exit-Pfad vorzubereiten?

In den nächsten 30 Tagen: Architektonische Bewertung. Wo ist der Frontend-Layer untrennbar mit dem Backend verbunden? Wo ist eine Entkopplung mit moderatem Aufwand realisierbar? Das ist die Grundlage für die Roadmap der nächsten 12 Monate.

Der TCO-Aspekt ist nicht zu unterschätzen. Eine DXP-Lizenz ist der sichtbarste Kostenpunkt - aber die Migrationskosten bei einem Vendor-Wechsel sind oft das 10- bis 20-fache der Jahreslizenz. Wer einen entkoppelten Frontend-Layer hat, reduziert diese Migrationskosten strukturell. Mehr zu DXP-Total-Cost-of-Ownership 2026 als Hintergrund.

Die Botschaft

Vendor-Stabilität ist keine Eigenschaft, die man bei der Vendor-Auswahl einmal prüft und dann ablegt. Sie ist eine Eigenschaft, die sich ändern kann - über Nacht, durch eine M&A-Transaktion in einem anderen Land.

Für regulierte Branchen heißt das: Procurement-Klauseln + architektonische Entkopplung gehen Hand in Hand. Beide einzeln sind unvollständig. Beide zusammen reduzieren das Risiko strukturell.

Salesforce/Contentful ist nicht der erste Fall. Er wird nicht der letzte sein. Die Frage ist nicht, ob der nächste Vendor-Wechsel passiert - sondern ob deine Verträge und deine Architektur darauf vorbereitet sind.

19 Tage K5 Berlin - und ab heute 30 Tage Procurement-Realitätscheck.