Wie europäische SaaS-Anbieter durch den Nachweis architekturbedingter Datensouveränität Enterprise-RFPs gewinnen

Wenn europäische SaaS-Anbieter auf Unternehmens-RFPs von Banken, Versicherungen oder regulierten Branchen reagieren, verlangen Sicherheitsfragebögen zunehmend vom Kunden kontrollierte Verschlüsselungsschlüssel, geografisch isolierte Datenverarbeitung und vertragliche Garantien, die den Zugriff ausländischer Behörden ausschließen. Diese Anforderungen spiegeln das Bewusstsein der Unternehmenskunden wider, dass vertragliche Datenverarbeitungsvereinbarungen und Standardvertragsklauseln keinen vollständigen Schutz bieten, wenn Plattformen auf Infrastrukturen basieren, die von Nicht-EU-Unternehmen mit extraterritorialer Rechtsbefugnis kontrolliert werden.

Der Wandel im Beschaffungswesen ist strukturell, nicht zyklisch. DORA, NIS2 und die EDPB-Leitlinien nach Schrems II haben die Anforderungen an die Datensouveränität in Finanzdienstleistungen, Versicherungen, Behörden und kritischen Infrastrukturen von „bevorzugt“ auf „verpflichtend“ angehoben. SaaS-Anbieter, die ihre Plattformen auf Standard-Hyperscale-Cloud-Architekturen aufgebaut haben, stehen nun vor binären Qualifikationsentscheidungen – noch bevor eine kommerzielle Bewertung beginnt. Ausschlaggebend ist allein, ob ihre Architektur spezifische technische Fragen zu Schlüsselverwaltung und Bereitstellungsflexibilität beantworten kann.

Dieser Beitrag beleuchtet, was Beschaffungsteams tatsächlich prüfen, welche Rahmenwerke die Anforderungen bestimmen und welche Architekturentscheidungen darüber entscheiden, ob ein SaaS-Anbieter in europäischen Unternehmenssegmenten wettbewerbsfähig ist.

Executive Summary

Kernaussage: Europäische SaaS-Anbieter, die um Unternehmenskunden konkurrieren, sehen sich Beschaffungsanforderungen gegenüber, die architektonische Datensouveränität statt vertraglicher Zusicherungen verlangen – Anbieter, die keine kundengesteuerte Schlüsselverwaltung und Bereitstellungsoptionen ohne Klartextzugriff des Anbieters nachweisen können, werden noch vor der kommerziellen Bewertung automatisch ausgeschlossen.

Warum das relevant ist: Die Europäische Bankenaufsichtsbehörde meldete, dass 73 % der Kreditinstitute 2024–2025 ihre Lieferantenbewertungen anpassten, um das CLOUD-Act-Risiko zu adressieren. SaaS-Anbieter mit souveränen Bereitstellungsoptionen berichten von 15–30 % höheren Vertragswerten, 40–60 % kürzeren Verkaufszyklen und einer 3–5-fachen Pipeline-Ausweitung im regulierten Sektor innerhalb von 12–18 Monaten nach Einführung entsprechender Funktionen.

5 wichtige Erkenntnisse

1. Unternehmens-RFPs fordern jetzt technische Architektur als Nachweis der Datensouveränität, nicht nur vertragliche Zusagen. Sicherheitsfragebögen von Banken, Versicherern und Behörden enthalten verpflichtende Anforderungen an kundengesteuerte Verschlüsselungsschlüssel und Bereitstellungsoptionen, die Klartextzugriff des Anbieters ausschließen. SaaS-Anbieter, die lediglich „Daten verschlüsselt während der Übertragung und im ruhenden Zustand“ ohne Details zur Schlüsselverwaltung angeben, werden automatisch disqualifiziert.
2. DORA schafft verbindliche Technologieanforderungen, die direkt auf SaaS-Anbieter im Finanzsektor durchschlagen. Artikel 30 verlangt von Finanzunternehmen, dass Verträge mit ICT-Dienstleistern Datenstandort, Schlüsselverwaltung und Exit-Strategien adressieren. Anbieter, deren Infrastruktur vom Provider verwaltete Verschlüsselungsschlüssel nutzt, bestehen die DORA-Prüfung nicht – unabhängig von vertraglichen Regelungen.
3. NIS2 weitet Anforderungen an Datensouveränität auf 18 Sektoren aus. Mitgliedstaaten müssen Unternehmen in Energie, Transport, Gesundheit, digitaler Infrastruktur, öffentlicher Verwaltung, kritischer Produktion und weiteren Sektoren als unter die Anforderungen an Cybersicherheit und Lieferkettenrisikomanagement fallend benennen – inklusive Prüfung der Datensouveränitätsarchitektur von ICT-Dienstleistern.
4. Nach Schrems II reichen Standardvertragsklauseln ohne ergänzende technische Maßnahmen nicht mehr aus. Die EDPB-Leitlinien betonen, dass Verantwortliche sich nicht allein auf SCCs verlassen dürfen, wenn Daten in Länder mit übermäßigem Behördenzugriff fließen. Unternehmenskunden verlangen von SaaS-Anbietern den Nachweis kundengesteuerter Verschlüsselung als wichtigste Zusatzmaßnahme – vertragliche DPAs ohne technische Souveränitätsarchitektur erfüllen die Beschaffungsanforderungen nicht.
5. Wettbewerbsdifferenzierung hängt zunehmend von Bereitstellungsflexibilität und Verschlüsselungsarchitektur ab. SaaS-Anbieter mit ausschließlich Multi-Tenant-Cloud verlieren gegen Wettbewerber mit On-Premises-Optionen, Private-Cloud-Installationen oder gehärteten virtuellen Appliances mit kundengesteuerten Schlüsseln. Souveräne Architektur schafft Preissetzungsmacht, beschleunigt Verkaufszyklen und eröffnet regulierte Branchen, die Wettbewerbern verschlossen bleiben.

Warum Unternehmensbeschaffung jetzt architektonische Datensouveränität verlangt

Beschaffungsprozesse in Unternehmen haben sich nach Schrems II und den EDPB-Leitlinien grundlegend verändert. Sicherheitsfragebögen, die früher eine DSGVO-Compliance-Bestätigung akzeptierten, verlangen heute detaillierte technische Nachweise, wie die Architektur unbefugten Datenzugriff verhindert – und die Fragen sind so konkret, dass allgemeine Compliance-Aussagen nicht mehr genügen.

Die EBA-Leitlinie 2024 übersetzt CLOUD-Act-Risiko in explizite RFP-Anforderungen, die 73 % der Kreditinstitute anwenden

Beschaffungsteams im Finanzsektor erhielten von der Europäischen Bankenaufsichtsbehörde die klare Vorgabe, dass US-basierte Cloud-Anbieter auch bei EU-Rechenzentren ein CLOUD-Act-Risiko darstellen. Die EBA-Leitlinie 2024 zum Lieferantenrisikomanagement vermerkt, dass 73 % der Kreditinstitute ihre Bewertungen entsprechend angepasst haben – und diese Anforderungen schlagen direkt auf RFPs durch, die SaaS-Anbieter erfüllen müssen. Versicherer unter Solvency II stehen vor ähnlichen Vorgaben, da nationale Aufsichtsbehörden in mehreren Mitgliedstaaten verlangen, dass Versicherer von ICT-Dienstleistern technische Maßnahmen zum Schutz vor unbefugtem Zugriff auf Versicherungsdaten einfordern.

Behördenbeschaffung bringt nationale Sicherheitsanforderungen, die Multi-Tenant-Cloud-Architekturen nicht erfüllen können

Beschaffung im öffentlichen Sektor ist durch nationale Sicherheitsanforderungen zusätzlich komplex. Mehrere EU-Staaten untersagen Behörden, Cloud-Dienste zu nutzen, bei denen Nicht-EU-Unternehmen technischen Datenzugriff haben. SaaS-Anbieter für den öffentlichen Sektor müssen nachweisen, dass Verschlüsselungsschlüssel und Administrationszugriffe ausschließlich beim Kunden oder einer EU-Einheit liegen – eine Anforderung, die Hyperscale-Cloud-Plattformen als Infrastruktur unabhängig vom physischen Standort der Rechenzentren ausschließt.

RFP-Sicherheitsfragebögen enthalten jetzt binäre Qualifikationskriterien, die Anbieter vor der kommerziellen Bewertung ausschließen

Sicherheitsfragebögen in RFPs stellen Fragen wie: „Unterstützt Ihre Plattform kundengesteuerte Verschlüsselungsschlüssel in HSMs unter exklusiver Kontrolle des Kunden?“ oder „Kann Ihre Lösung On-Premises oder in Private-Cloud-Infrastruktur bereitgestellt werden?“ oder „Haben Personen außerhalb der EU technischen Zugriff auf Kundendaten?“ Diese Fragen schaffen binäre Qualifikationskriterien. Anbieter, die „nein“ antworten, werden automatisch disqualifiziert – Preis, Funktionen, Referenzen und alle anderen Wettbewerbsvorteile spielen keine Rolle mehr. Architekturentscheidungen aus der Produktentwicklung bestimmen direkt die adressierbare Marktgröße im europäischen Unternehmenssegment.

DSGVO- und Post-Schrems-II-Anforderungen an die technische Architektur von SaaS

Artikel 32 der DSGVO verlangt von Auftragsverarbeitern „geeignete technische und organisatorische Maßnahmen“, darunter Pseudonymisierung, Verschlüsselung und Maßnahmen zur Sicherstellung von Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit. Für SaaS-Anbieter ergeben sich daraus grundlegende Sicherheitsanforderungen, die Beschaffungsteams durch technische Prüfungen verifizieren – doch seit Schrems II liegt die Messlatte deutlich höher.

Anbietergesteuerte Verschlüsselung erfüllt formal Artikel 32 DSGVO, scheitert aber am EDPB-Standard zur Schlüsselkontrolle durch den Verantwortlichen

Die Leitlinien der Artikel-29-Datenschutzgruppe betonen, dass Verschlüsselung nur dann ausreichenden Schutz bietet, wenn der Verantwortliche die alleinige Kontrolle über die Entschlüsselungsschlüssel behält. Viele SaaS-Plattformen verschlüsseln zwar im ruhenden Zustand und während der Übertragung, behalten aber die Schlüsselverwaltung beim Anbieter. Solche Architekturen erfüllen die Verschlüsselungsanforderung nur oberflächlich, scheitern aber am EDPB-Standard zur Schlüsselkontrolle – und erfahrene Beschaffungsteams fragen gezielt nach: Wer hält die Entschlüsselungsschlüssel, und könnten Sie gezwungen werden, diese herauszugeben?

EDPB-Leitlinien zu ergänzenden Maßnahmen schaffen eine dreistufige technische Hierarchie, die nur kundengesteuerte HSMs vollständig erfüllen

Schrems II stellte klar, dass Standardvertragsklauseln allein keinen ausreichenden Schutz bieten, wenn Daten in Länder mit Überwachungsmaßnahmen ohne europäisches Schutzniveau transferiert werden. Die EDPB-Leitlinien zu ergänzenden Maßnahmen differenzieren zwischen Verschlüsselung mit anbietergesteuerten Schlüsseln (begrenzter Schutz) und Verschlüsselung mit ausschließlich kundengesteuerten Schlüsseln (effektiver Schutz). Für SaaS-Anbieter ergibt sich eine technische Hierarchie: Verschlüsselung im ruhenden Zustand und während der Übertragung implementieren; Schlüsselverwaltung getrennt von Anwendungsdaten nachweisen; Schlüssel ausschließlich unter Kontrolle des Kunden in Hardware-Sicherheitsmodulen nachweisen. Unternehmensbeschaffung verlangt heute die dritte Stufe – Anbieter, die nur die ersten beiden erfüllen, scheitern an der Qualifikationshürde.

DORA- und NIS2-Technologieanforderungen für SaaS-Anbieter

DORA schafft verbindliche Technologieanforderungen für Finanzunternehmen, die direkt auf ICT-Dienstleister durchschlagen. Artikel 28(5) verlangt die Bewertung aller ICT-Drittanbieter. Artikel 30 schreibt Verträge vor, die Sicherheitsmaßnahmen wie Datenschutz, Verschlüsselung und Business Continuity sicherstellen.

DORA Artikel 30 schafft spezifische Prüfpflichten, die Multi-Tenant-Cloud-Architekturen nicht erfüllen können

Artikel 30(2)(j) verlangt die Berücksichtigung des „Datenverarbeitungsstandorts“, während Artikel 30(2)(k) Regelungen zu „Datenzugriff, Wiederherstellung, Rückgabe und Löschung“ fordert. Für Finanzunternehmen entstehen daraus Prüfpflichten, die über das hinausgehen, was eine Datenverarbeitungsvereinbarung leisten kann. Artikel 28(3) verlangt „Exit-Strategien“ für die „vollständige Datenentfernung“ – Plattformen, bei denen Kundendaten unter anbietergesteuerten Schlüsseln verschlüsselt bleiben, erfüllen diese Anforderung nicht, da die vollständige Löschung die Mitwirkung des Anbieters erfordert. Die technischen Standards der Europäischen Bankenaufsicht betonen, dass Finanzinstitute nachweisen müssen, dass Cloud-Anbieter eine „starke logische Trennung“ umsetzen und die Schlüsselverwaltung dem Kunden die Kontrolle über den gesamten Schlüssel-Lebenszyklus ermöglicht.

NIS2 weitet vergleichbare Anforderungen an Datensouveränität auf 18 Sektoren außerhalb des Finanzsektors aus

NIS2 überträgt ähnliche Anforderungen auf weitere Sektoren. Die Richtlinie gilt für wesentliche und wichtige Einrichtungen in 18 Branchen – Energie, Transport, Gesundheit, digitale Infrastruktur, öffentliche Verwaltung, kritische Produktion und weitere – und verlangt Lieferketten-Cybersicherheit sowie Resilienzprüfung von ICT-Dienstleistern. Die nationale Umsetzung variiert, aber in mehreren Ländern wurden explizite Anforderungen an die Datensouveränität für SaaS-Anbieter eingeführt. In der Praxis zeigt sich dies in Beschaffungsbewertungen: Anbieter mit reiner Multi-Tenant-Cloud und anbietergesteuerten Schlüsseln erhalten niedrige Bewertungen, während Anbieter mit On-Premises-Bereitstellung und kundengesteuerten Schlüsseln hohe Bewertungen erzielen und die technische Qualifikation bestehen.

Technische Architektur-Anforderungen, die Unternehmenskunden prüfen

Beschaffungsteams in Unternehmen konzentrieren sich bei der technischen Due Diligence auf spezifische Architekturmerkmale, die über die Erfüllung der Anforderungen an Datensouveränität entscheiden. Zu wissen, was geprüft wird – und in welcher Reihenfolge – ist genauso wichtig wie die Architektur selbst.

Schlüsselverwaltung steht im Fokus – nur kundengesteuerte HSMs erfüllen die strengste Stufe

Die Schlüsselverwaltung steht an erster Stelle. Kunden unterscheiden zwischen anbietergesteuerten Schlüsseln, kundengesteuerten Schlüsseln in Cloud-HSMs und kundengesteuerten Schlüsseln in HSMs unter exklusiver Kontrolle des Kunden. Nur die dritte Stufe erfüllt die strengen Souveränitätsanforderungen, da sie technische Zugriffswege für Anbieter oder Hyperscaler auf Klartextdaten ausschließt. Die Bereitstellungsflexibilität ist das zweite zentrale Kriterium – Kunden prüfen, ob Anbieter On-Premises-Installationen, Private-Cloud-Bereitstellungen oder gehärtete virtuelle Appliances unterstützen, die Souveränitätsvorteile bei geringerer Betriebs-Komplexität bieten. Reine Multi-Tenant-Cloud-Architekturen werden in vielen RFPs automatisch disqualifiziert – unabhängig von anderen Funktionen.

Administrative Zugriffskontrollen sind der dritte Prüfpunkt – dauerhafter Zugriff birgt Risiken, die Richtlinien allein nicht verhindern

Administrative Zugriffskontrollen sind der dritte Prüfpunkt. Beschaffungsteams prüfen, welche Mitarbeiter des Anbieters auf Kundenumgebungen zugreifen können, von welchen Standorten aus und ob administrative Tätigkeiten die Zustimmung des Kunden erfordern. Architekturen, bei denen Support-Teams des Anbieters dauerhaften Zugriff haben, bestehen die Souveränitätsprüfung nicht, da technische Möglichkeiten Risiken schaffen – ein Anbieter kann gezwungen oder kompromittiert werden, unabhängig von internen Richtlinien. Datenresidenz-Kontrollen, Audit-Logging und IAM-Integration sind weitere Prüfpunkte. Die Prüfung erfolgt meist in Architektur-Workshops mit detaillierten Diagrammen; Anbieter ohne belastbare Architektur erhalten zu niedrige Bewertungen für die nächste Verhandlungsrunde.

Wettbewerbsdynamik, wenn Souveränität zur RFP-Anforderung wird

Architektonische Datensouveränität als verpflichtende RFP-Anforderung führt zu einer Marktsegmentierung, in der SaaS-Anbieter mit souveränen Fähigkeiten Chancen erhalten, die Wettbewerbern mit Standard-Cloud-Architektur verschlossen bleiben. Die Wettbewerbsvorteile sind messbar und wachsen mit der Zeit.

Souveräne Architektur bringt 15–30 % höhere Vertragswerte und 40–60 % kürzere Verkaufszyklen im Unternehmensgeschäft

Die Preisdynamik verschiebt sich deutlich, wenn Anbieter eine souveräne Architektur nachweisen. Unternehmenskunden erkennen, dass kundengesteuerte Verschlüsselung und flexible Bereitstellung echte technische Differenzierung durch Entwicklungsaufwand bedeuten. SaaS-Anbieter berichten von 15–30 % höheren Vertragswerten bei Deals mit Souveränitätsanforderung im Vergleich zu ähnlichen Verträgen ohne diese Vorgabe. Der Verkaufszyklus verkürzt sich, weil die architektonische Souveränität das Hauptargument gegen eine Beschaffungsentscheidung ausräumt – Anbieter berichten, dass sich Verkaufszyklen von 9–12 auf 4–6 Monate verkürzen, wenn sie die Souveränität bereits im Erstgespräch belegen, da Sicherheitsprüfungen, die sonst Monate dauern, auf die Architekturprüfung reduziert werden.

Verdrängung von Hyperscale-Anbietern beschleunigt sich mit steigendem Regulierungsdruck

Die Verdrängung von etablierten Hyperscale-basierten Anbietern nimmt zu. Europäische Unternehmen, die SaaS-Plattformen auf Hyperscale-Infrastruktur nutzen, stehen unter wachsendem Druck von Aufsichtsbehörden und internen Compliance-Teams, auf souveräne Alternativen umzusteigen. Mehrere europäische SaaS-Anbieter berichten, dass 40–60 % ihrer neuen Unternehmensabschlüsse durch die Verdrängung von Wettbewerbern mit fehlender Souveränität entstehen – Kunden, die mit dem bisherigen Anbieter zufrieden waren, aber nun regulatorische Anforderungen erfüllen müssen. Die Markterweiterung ist der größte langfristige Effekt: Anbieter ohne souveräne Architektur werden systematisch aus Finanzdienstleistungen, Versicherungen, Behörden und kritischer Infrastruktur ausgeschlossen, während Anbieter mit Souveränitätsfunktionen eine 3–5-fache Pipeline-Ausweitung in diesen Sektoren innerhalb von 12–18 Monaten verzeichnen.

Umsetzungsaspekte

SaaS-Anbieter, die Funktionen zur architektonischen Datensouveränität einführen, stehen vor technischen, operativen und kommerziellen Entscheidungen, die Time-to-Market und Kundenerlebnis beeinflussen.

Architektur der Schlüsselverwaltung ist die wichtigste Entscheidung und bestimmt, welche Anforderungen ein Anbieter erfüllen kann

Die Entscheidung zur Schlüsselverwaltungsarchitektur ist entscheidend. Anbieter müssen festlegen, ob sie On-Premises-HSMs, Cloud-HSM-Services europäischer Anbieter oder gehärtete virtuelle Appliances unterstützen. Die meisten Anbieter implementieren mehrere Optionen, damit Kunden je nach Sicherheitsanforderung und Betriebsfähigkeit wählen können – die Architektur wird an die regulatorische Umgebung des Kunden angepasst, statt einen Ansatz für alle zu wählen, der manche Kunden überzeugt und andere disqualifiziert. Das Bereitstellungsmodell ist die zweite große Entscheidung: On-Premises-Installationspakete, Private-Cloud-Automatisierung oder containerisierte Implementierungen. Erfolgreiche Anbieter unterstützen mehrere Bereitstellungsmodelle auf einer gemeinsamen Codebasis, um den Wartungsaufwand zu minimieren.

Dauerhaften administrativen Zugriff zu eliminieren erfordert Prozessanpassung, ist aber unverzichtbar für souveräne Architektur

Die Architektur für administrativen Zugriff muss so gestaltet werden, dass Anbieter keinen dauerhaften Zugang zu Kundenumgebungen haben. Notfallzugriffe erfolgen über Break-Glass-Verfahren mit vollständigem Audit-Trail. Datenresidenz-Kontrollen stellen sicher, dass Speicherung, Verarbeitung, Backup und Monitoring die vom Kunden vorgegebenen geografischen Grenzen einhalten. Dokumentations- und Zertifizierungsanforderungen steigen mit souveräner Architektur deutlich – Anbieter benötigen detaillierte technische Dokumentation für Sicherheitsprüfungen, Architekturdiagramme für Beschaffungsbewertungen und ggf. unabhängige Zertifizierungen zur Validierung von Souveränitätsansprüchen. Investitionen in Dokumentation sind genauso wichtig wie technische Entwicklung, da Beschaffungsteams Anbieter ohne klare technische Nachweise nicht weiter berücksichtigen – unabhängig von der tatsächlichen Architektur. Kommerzielle Aspekte umfassen Preisanpassungen – souveräne Bereitstellungsoptionen erzielen typischerweise 20–40 % Preisaufschlag, was technische Differenzierung und Betriebsaufwand widerspiegelt.

Der Umstieg von Hyperscale-Architektur sollte inkrementell über 18–24 Monate erfolgen, nicht als Komplett-Neuentwicklung

Anbieter mit Hyperscale-Cloud-Infrastruktur können zur souveränen Architektur wechseln, ohne die Plattform komplett neu zu entwickeln. Zunächst wird kundengesteuerte Verschlüsselung mit Bring-Your-Own-Key-Funktionen eingeführt, wobei die Souveränität noch begrenzt ist. Im zweiten Schritt werden containerisierte Deployment-Pakete für Private-Cloud-Installationen auf kundeneigener Infrastruktur entwickelt. Drittens erfolgt die Partnerschaft mit europäischen Infrastrukturprovidern für souveräne Cloud-Services. Neue Produktmodule werden von Anfang an mit Bereitstellungsflexibilität konzipiert. Erfolgreiche Umstellungen erfolgen über 18–24 Monate in iterativen Schritten – entscheidend ist, Souveränität als Produktstrategie und nicht als optionale Funktion zu verankern, da die damit verbundene Marktsegmentierung mit der Zeit immer größere Vorteile bringt.

Wie Kiteworks europäischen SaaS-Anbietern hilft, Anforderungen an Datensouveränität zu erfüllen

Europäische SaaS-Anbieter agieren in einem Markt, in dem architektonische Datensouveränität im regulierten Unternehmensumfeld vom Differenzierungsmerkmal zum Pflichtprogramm geworden ist. Die erfolgreichen Anbieter sind nicht zwangsläufig größer oder funktionsreicher – sie sind diejenigen, deren Architektur die spezifischen technischen Fragen zur Qualifikation beantworten kann. Souveräne Architektur schafft Preissetzungsmacht, beschleunigt Verkaufszyklen, ermöglicht die Verdrängung von Hyperscale-basierten Wettbewerbern und erweitert den adressierbaren Markt um bislang verschlossene Sektoren. Für SaaS-Anbieter auf Standard-Cloud-Infrastruktur stellt sich nicht die Frage, ob, sondern wie schnell sie Souveränitätsfunktionen einführen, bevor sich das Wettbewerbsfenster schließt.

Kiteworks bietet europäischen SaaS-Anbietern die architektonischen Datensouveränitätsfunktionen, die für den Gewinn von Unternehmens-RFPs in Finanzdienstleistungen, Versicherungen, Behörden und regulierten Branchen erforderlich sind. Die Plattform verwendet vom Kunden kontrollierte Verschlüsselungsschlüssel, die nie die Kundeninfrastruktur verlassen. Selbst wenn Kiteworks behördliche Anordnungen erhält oder Sicherheitsvorfälle auftreten, verfügen wir über keinerlei technische Möglichkeit, auf Kundendaten zuzugreifen.

Die Plattform unterstützt flexible Bereitstellung – einschließlich On-Premises-Installation im Rechenzentrum des Kunden, Private-Cloud-Bereitstellung in europäischen Einrichtungen unter Kundenkontrolle und gehärtete virtuelle Appliances, die Souveränitätsvorteile bei geringerer Betriebs-Komplexität bieten. SaaS-Anbieter können ihren Kunden die passende Bereitstellungsoption für deren Sicherheitsanforderungen und Betriebsfähigkeit anbieten und so RFP-Anforderungen an souveräne Architektur in unterschiedlichen Kundensegmenten erfüllen.

Kiteworks integriert Secure Email, Filesharing, Managed File Transfer und Web-Formulare in eine einheitliche Architektur, mit der SaaS-Anbieter sensible Datenkommunikation über eine einzige souveräne Plattform steuern. Diese Integration vereinfacht die Implementierung kundengesteuerter Schlüssel, reduziert die Komplexität der Anbieterbeziehung und ermöglicht einheitliches Audit-Logging zur Erfüllung der DORA- und NIS2-Anforderungen.

Für SaaS-Anbieter, die DORA-regulierte Finanzinstitute bedienen, erfüllt die Architektur der Plattform die Anforderungen von Artikel 30 an Verschlüsselung, Datenstandortkontrolle und Exit-Strategien. Kundengesteuerte Verschlüsselungsschlüssel adressieren die Vorgaben aus Artikel 30(2)(k) zu Datenzugriff und -löschung, während die Bereitstellungsflexibilität die Anforderungen aus Artikel 30(2)(j) zur geografischen Verarbeitung erfüllt. Die Exit-Funktionen der Plattform ermöglichen Kunden einen Umstieg ohne Mitwirkung von Kiteworks und verhindern Vendor-Lock-in bei gleichzeitiger Erfüllung der DORA-Exit-Strategie-Anforderungen.

Erfahren Sie mehr darüber, wie Kiteworks europäische SaaS-Anbieter beim Gewinn von Unternehmens-RFPs durch architektonische Datensouveränität unterstützt – vereinbaren Sie noch heute eine individuelle Demo.

Weitere Ressourcen

Blog Post

• eBook
  Datensouveränität und DSGVO
• Blog Post
  Vermeiden Sie diese Fallstricke bei der Datensouveränität
• Blog Post
  Best Practices für Datensouveränität
• Blog Post
  Datensouveränität und DSGVO [Verständnis von Datensicherheit]