Compliance Compass: EU-Regulierungen für Software, SaaS und Cloud-Hosting

TL;DR

• Die EU hat mit GDPR, NIS‑2, DORA, CRA, Data Act und dem Cloud Sovereignty Framework ein kohärentes Regelwerk geschaffen, das Datenschutz, Cyber-Resilienz, digitale Souveränität und Interoperabilität systematisch stärkt.
• Für Betreiber von Software, SaaS und Cloud-Hosting bedeutet das: klare Anforderungen an Security-by-Design, Datenverarbeitung, Exit-Fähigkeit, Drittparteirisiken und Governance – aber auch wiederverwendbare Bausteine, die viele Pflichten gleichzeitig adressieren.
• Die gemeinsamen Ziele der Regelungen sind: Schutz personenbezogener und geschäftskritischer Daten, Widerstandsfähigkeit gegenüber Cybervorfällen, Reduktion von Vendor Lock-in und ein souveräner europäischer Technologiestandort.
• Strategisch sinnvoll ist ein integrierter Ansatz: Ein sauberes ISMS, cloud-native Architektur, dokumentierte Prozesse sowie transparente Lieferketten können große Teile der Anforderungen aller sechs Regulierungen parallel abdecken.
• ayedo unterstützt Organisationen dabei, diese Regulierungen in tragfähige Architektur-, Plattform- und Prozessentscheidungen zu übersetzen und so Compliance als strukturierten Wettbewerbsvorteil zu nutzen – von der Analyse bis zur betriebenen Plattform.

---

Warum ein Compliance-Compass nötig ist

Die europäische Regulierungslandschaft ist in den letzten Jahren deutlich dichter geworden. Das ist kein Zufall, sondern Ausdruck eines klaren politischen Ziels: Europa will im digitalen Raum nicht nur Konsument, sondern eigenständiger Gestalter sein. Dazu gehören verlässlicher Datenschutz, robuste Infrastrukturen, faire Wettbewerbsbedingungen und ein Mindestmaß an technologischer Unabhängigkeit.

Für Sie als Verantwortliche:r für Software, SaaS oder Cloud-Hosting heißt das: Compliance ist nicht mehr nur ein Thema für Rechtsabteilungen. Architektur, Betriebsmodelle, Lieferantenwahl und Produktstrategie sind unmittelbar betroffen.

Die gute Nachricht: Die sechs zentralen Regulierungen sind kein unüberschaubares Patchwork. Viele Anforderungen greifen ineinander und lassen sich mit einem konsistenten technischen und organisatorischen Ansatz adressieren. Genau hier hilft ein gedanklicher „Compliance-Compass“.

---

Die sechs zentralen EU-Regulierungen im Überblick

1. GDPR – Datenschutz-Grundverordnung

Die GDPR ist seit dem 25.05.2018 anwendbar und bildet die Grundlage fast aller weiteren EU-Regelungen im digitalen Raum. Sie adressiert:

• Schutz personenbezogener Daten und Betroffenenrechte
• Rechtmäßigkeit und Transparenz der Verarbeitung
• „Privacy by Design and Default“
• Sicherheit der Verarbeitung (Art. 32), inkl. technischer und organisatorischer Maßnahmen
• Meldepflichten bei Datenschutzverletzungen

Praktische Bedeutung für Software- und SaaS-Betreiber:

• Architektur und Datenmodelle müssen Datenschutzprinzipien berücksichtigen (Datenminimierung, Zweckbindung, Löschkonzepte).
• Logging, Monitoring und Backups sind so zu gestalten, dass sie Sicherheit erhöhen, ohne Datenschutz zu verletzen.
• Hosting-Entscheidungen – insbesondere bei außereuropäischen Hyperscalern – müssen unter dem Blickwinkel internationaler Datentransfers rechtlich belastbar sein.

GDPR ist damit das Fundament, auf dem NIS‑2, DORA, CRA, Data Act und das Cloud Sovereignty Framework aufbauen.

2. NIS‑2 – Network and Information Security

Die NIS‑2-Richtlinie trat am 16.01.2023 in Kraft und muss bis zum 17.10.2024 in nationales Recht umgesetzt sein. Sie richtet sich an Betreiber wesentlicher und wichtiger Einrichtungen in 18 Sektoren (u. a. Energie, Gesundheit, digitale Infrastruktur, Cloud-Computing).

Kernanforderungen:

• Risikomanagement und Sicherheitskonzepte für Netz- und Informationssysteme
• Incident-Detection, -Meldung und -Response
• Business Continuity und Disaster Recovery
• Management-Verantwortung und -Haftung
• Sicherheit in der Lieferkette, inklusive IKT-Dienstleistern und Cloud-Providern

Für Cloud- und SaaS-Betreiber ergibt sich zweierlei: Sie können selbst direkt unter NIS‑2 fallen oder werden als kritische Dienstleister von ihren Kunden faktisch in die Pflicht genommen. In beiden Fällen sind nachweisbare Prozesse, Metriken und technische Schutzmaßnahmen gefragt.

3. DORA – Digital Operational Resilience Act

Der Digital Operational Resilience Act (DORA) ist seit dem 16.01.2023 in Kraft und gilt ab dem 17.01.2025 unmittelbar. Er betrifft Finanzinstitute (Banken, Versicherungen, Zahlungsdienstleister etc.) und ihre IKT-Dienstleister.

DORA baut auf NIS‑2 auf, geht aber im Finanzsektor deutlich weiter:

• IKT-Risikomanagement mit klaren Verantwortlichkeiten
• Strukturiertes Incident-Management inkl. Meldung an Aufsichtsbehörden
• Regelmäßige Resilienztests (u. a. Threat-Led Penetration Testing)
• Strenge Anforderungen an Outsourcing und Drittparteimanagement
• Vertrags- und Steuerungsanforderungen an Cloud-Provider und SaaS-Anbieter

Wenn Sie Dienste für Finanzunternehmen bereitstellen, wird DORA Ihre Architektur- und Betriebsentscheidungen prägen – selbst wenn Sie nicht unmittelbar reguliert sind. Multi-Region-Strategien, Exit-Konzepte und testbare Notfallprozesse werden zu harten Anforderungen, nicht zu „Best Practices“.

4. CRA – Cyber Resilience Act

Der Cyber Resilience Act (CRA) ist im Frühjahr 2024 in Kraft getreten. Nach einer Übergangsfrist von voraussichtlich 36 Monaten wird er ab 2027 anwendbar sein. Er richtet sich an Hersteller und Anbieter vernetzter Software- und Hardwareprodukte.

Zentrale Elemente:

• Security by Design und Default über den gesamten Produktlebenszyklus
• Dokumentationspflichten und Security-Baselines je nach Kritikalität
• Verpflichtende Schwachstellenmanagement-Prozesse und Coordinated Vulnerability Disclosure
• Bereitstellung von Sicherheitsupdates über definierte Zeiträume
• Anforderungen an Software Bill of Materials (SBOM) für viele Produktklassen

Für Software- und SaaS-Anbieter bedeutet das: Sicherheitsanforderungen sind nicht mehr nur vertraglicher „Goodwill“, sondern rechtlich verankerte Produkteigenschaften. Build-Pipelines, Release-Prozesse und Dependency-Management müssen entsprechend ausgerichtet werden.

5. Data Act – Datenportabilität und Interoperabilität

Der Data Act ist am 11.01.2024 in Kraft getreten und gilt mit Wirkung ab dem 12.09.2025. Er verfolgt zwei Ziele:

• Mehr Zugang zu Nutzungsdaten von vernetzten Produkten und Diensten
• Reduktion von Vendor Lock-in, insbesondere im Cloud- und SaaS-Bereich

Relevante Anforderungen für Cloud- und SaaS-Betreiber:

• Transparente Datenzugangs- und Portabilitätsrechte für Kunden
• Verpflichtung zur Unterstützung von Wechseln zwischen Cloud-Diensten („Switching“) mit funktionaler Äquivalenz
• Anforderungen an offene und dokumentierte Schnittstellen
• Begrenzung bzw. schrittweiser Abbau von Exit-Gebühren

Damit wird Exit-Fähigkeit – also die Möglichkeit, eine Anwendung samt Daten in eine andere Umgebung zu verlagern – zu einem regulierten Feature. Architekturentscheidungen zu Datenformaten, API-Design, Mandantenfähigkeit und Automatisierung sind unmittelbar betroffen.

6. Cloud Sovereignty Framework

Das Cloud Sovereignty Framework der EU-Kommission ist kein Gesetz, sondern ein Beschaffungsrahmen, der seit 2022 eingesetzt und weiterentwickelt wird. Es bewertet Cloud-Dienste entlang mehrerer Souveränitätsziele (SOV-1 bis SOV-8), z. B.:

• Datenhoheit und GDPR-Konformität
• Operationale Souveränität, inklusive Exit-Fähigkeit und Reversibilität
• Schutz vor extraterritorialem Zugriff fremder Rechtsordnungen
• Sicherheits- und Compliance-Reifegrad, u. a. im Lichte von NIS‑2 und DORA

Öffentliche Auftraggeber, aber zunehmend auch regulierte Unternehmen, nutzen dieses Framework, um geeignete Provider und Betriebsmodelle auszuwählen. Für Betreiber von Plattformen und SaaS-Lösungen wird es damit zu einem strategischen Verkaufsargument, die Kriterien des Cloud Sovereignty Frameworks nachweislich zu erfüllen.

---

Gemeinsame Ziele: Souveränität, Sicherheit, Interoperabilität

Über alle sechs Regelwerke hinweg lassen sich drei Leitmotive erkennen, die sich gegenseitig verstärken.

Digitale und datenbezogene Souveränität

• GDPR sichert die informationelle Selbstbestimmung von Personen.
• Der Data Act stärkt die Souveränität von Unternehmen über „ihre“ Daten und Nutzungsinformationen.
• Das Cloud Sovereignty Framework adressiert die Souveränität europäischer Institutionen gegenüber außereuropäischen Infrastrukturen.

Für Ihre Architektur heißt das: Sie sollten bewusst entscheiden, wo Daten liegen, wie sie verarbeitet werden und wie Sie Abhängigkeiten von einzelnen Providern begrenzen. Multi-Cloud- oder „Dual-Vendor“-Strategien, standardisierte Schnittstellen und eine klare Datenklassifikation werden wichtiger Bestandteil der Governance.

Sicherheit und operative Resilienz

• NIS‑2 und DORA fokussieren auf organisatorische und technische Resilienz von Infrastrukturen und Services.
• Der Cyber Resilience Act verschiebt Security-Anforderungen tiefer in das Produktdesign und in den Entwicklungsprozess.
• Die GDPR verankert Sicherheitsanforderungen explizit in Art. 32 („Sicherheit der Verarbeitung“).

Das gemeinsame Bild: Sicherheit ist kein Add-on mehr, sondern eine Querschnittsanforderung über Design, Entwicklung, Betrieb und Lieferkette. Für Sie heißt das:

• ISMS und Risk-Management sind nicht mehr optional, sondern zentraler Ordnungsrahmen.
• Observability, strukturierte Incident-Response und getestete Recovery-Szenarien sind Kernelemente der Architektur.
• Lieferanten- und Drittparteimanagement wird zu einem kontinuierlichen Prozess, nicht zu einer jährlichen Fragebogenübung.

Interoperabilität und Reduktion von Lock-in

• Der Data Act fordert ausdrücklich Wechselmöglichkeiten und funktionale Äquivalenz beim Providerwechsel.
• Der CRA setzt voraus, dass Security-Eigenschaften klar dokumentiert und überprüfbar sind – was standardisierte Schnittstellen und Formate fördert.
• Das Cloud Sovereignty Framework privilegiert Anbieter, die Interoperabilität, Offenheit und Portabilität nachweisen können.

Das Ergebnis ist ein klarer Trend hin zu offenen Standards, transparenten APIs und portablen Anwendungen. Für Cloud-native Software ist das eine große Chance: Wer im Design auf Containerisierung, offene Protokolle und standardisierte Plattformen setzt, ist automatisch besser für diese Anforderungen gerüstet.

---

Wie die Puzzleteile zusammenspielen

Statt sechs getrennte Baustellen zu sehen, lohnt es sich, die Überschneidungen zu nutzen.

GDPR als Fundament

Die GDPR liefert mit Privacy by Design, Datenminimierung und Sicherheitsanforderungen die Basis:

• Datenklassifikation, Löschkonzepte und Zugriffskontrollen zahlen gleichzeitig auf NIS‑2, DORA und Cloud-Souveränität ein.
• Transparente Verarbeitung und dokumentierte Rechtsgrundlagen erleichtern die Erfüllung von Audit- und Berichtspflichten in anderen Regulierungen.

Wer hier sauber aufgestellt ist, hat bereits einen erheblichen Teil der „Hausaufgaben“ für weitere Regulierungen erledigt.

NIS‑2 und DORA: Resilienz auf Organisations- und Sektorebene

NIS‑2 und DORA fordern beide:

• ein strukturiertes IKT-Risikomanagement,
• klare Verantwortlichkeiten im Management,
• Melde- und Reaktionsprozesse für Incidents
• und ein Mindestmaß an Testing und Dokumentation.

Der Unterschied: DORA schärft diese Anforderungen für den Finanzsektor und bezieht Anbieter von IKT-Diensten explizit ein. Für Sie kann es sinnvoll sein, die strengeren DORA-Anforderungen als Referenz zu nehmen – auch wenn Sie nicht im Finanzsektor sind. Das erzeugt einen zukunftssicheren Standard, der NIS‑2-Anforderungen in anderen Sektoren meist übererfüllt.

CRA und Data Act: Produkt- und Plattformebene

Der Cyber Resilience Act und der Data Act fokussieren auf Produkteigenschaften:

• CRA: Sicherheit, Schwachstellenmanagement, Update-Fähigkeit, SBOMs
• Data Act: Interoperabilität, Datenportabilität, Exit-Fähigkeit

Beide zusammen fördern einen Lifecycle-Ansatz: Sie entwickeln, betreiben und pflegen Produkte so, dass sie sowohl sicher als auch portabel sind. In der Praxis bedeutet das:

• klare Trennung von Konfiguration, Daten und Code
• dokumentierte, stabile APIs
• automatisierte Bereitstellung und Migrationspfade (z. B. Infrastructure as Code, automatisierte Exports)
• reproduzierbare Umgebungen, um Migrationen und Notfälle realistisch testen zu können

Cloud Sovereignty Framework als Übersetzer in die Beschaffung

Das Cloud Sovereignty Framework verdichtet diese Vorgaben in konkrete Bewertungskriterien für Cloud-Services:

• Datenschutz- und Souveränitätsanforderungen aus GDPR und Data Act
• Resilienz- und Governance-Anforderungen aus NIS‑2 und DORA
• Security-by-Design-Aspekte aus dem CRA

Damit wird Compliance plötzlich sehr konkret: Entweder Ihre Plattform und Ihre Services erfüllen bestimmte Souveränitätslevels (z. B. SEAL-Level), oder Sie werden bei Ausschreibungen kaum berücksichtigt.

---

Praktische Bedeutung für Software-, SaaS- und Hosting-Betreiber

Für die Unternehmenspraxis stellt sich weniger die Frage „Welches Gesetz gilt für mich?“, sondern: Wie richte ich Organisation, Architektur und Prozesse so aus, dass ich nicht bei jedem neuen Regulierungstext bei null beginne?

1. Governance und Verantwortlichkeiten klären

• Benennen Sie klare Verantwortliche für Informationssicherheit, Datenschutz und Compliance (CISO, DPO, Compliance Officer), mit definierten Schnittstellen zu Engineering und Betrieb.
• Verankern Sie Pflichten explizit im Management: NIS‑2 und DORA adressieren Leitungsorgane ausdrücklich.
• Etablieren Sie ein ISMS (z. B. nach ISO 27001) als gemeinsamen Rahmen – viele Anforderungen aller Regulierungen lassen sich darin systematisch abbilden.

2. Architekturentscheidungen bewusst treffen

• Setzen Sie auf portierbare, containerisierte Anwendungen und offene Standards, um Anforderungen aus Data Act und Cloud Sovereignty Framework zu erfüllen.
• Trennen Sie Mandanten und Datenbereiche sauber – im Sinne der GDPR, aber auch für Resilienztests und Exit-Szenarien.
• Planen Sie Security- und Privacy-by-Design in Ihrer Architektur: Verschlüsselung, Identity & Access Management, Geheimnisverwaltung, Audit-Logging, sichere Update-Mechanismen.

3. Lieferketten und Provider strategisch managen

• Klassifizieren Sie Ihre IKT-Dienstleister nach Kritikalität und Abhängigkeit.
• Verankern Sie in Verträgen Anforderungen aus NIS‑2, DORA, Data Act und CRA: Reporting, Audit-Rechte, Exit-Klauseln, Sicherheitsstandards.
• Bewerten Sie Cloud-Provider nach Kriterien des Cloud Sovereignty Frameworks: Datenstandorte, Rechtsraum, Exit-Fähigkeit, Zertifizierungen, technische Souveränitätsfeatures.

4. Dokumentation und Nachweisfähigkeit sicherstellen

Regulatoren und Kunden werden nicht nur auf Policies schauen, sondern auf gelebte Praxis:

• Halten Sie Sicherheits- und Datenschutzkonzepte, Architekturentscheidungen und Migrationsszenarien nachvollziehbar fest.
• Etablieren Sie regelmäßige Tests (Notfallübungen, Restore-Tests, Migrations-Probeläufe) und dokumentieren Sie Ergebnisse.
• Sorgen Sie für durchgängige Telemetrie: Logs, Metriken und Traces sind nicht nur für den Betrieb wertvoll, sondern auch für Incident-Analysen und regulatorische Nachweise.

5. Zeitachsen im Blick behalten

• NIS‑2: Nationale Gesetze müssen bis zum 17.10.2024 umgesetzt sein – viele Aufsichten werden ab 2025 ernsthaft prüfen.
• DORA: Ab dem 17.01.2025 gelten die Anforderungen verbindlich für Finanzinstitute und ihre Dienstleister.
• Data Act: Ab dem 12.09.2025 müssen insbesondere Cloud- und SaaS-Anbieter Exit-Anforderungen erfüllen.
• Cyber Resilience Act: Bis 2027 verbleibt eine Übergangszeit – zu spät, um Security-by-Design erst dann in den Entwicklungsprozess zu bringen.

Ein gestaffelter Fahrplan, der diese Daten berücksichtigt, hilft, Investitionen zu bündeln und Doppelarbeit zu vermeiden.

---

Häufige Fragen

Gilt wirklich jede dieser Regelungen für mein Unternehmen?

Nicht jede Regulierung gilt unmittelbar für jedes Unternehmen. Die GDPR betrifft praktisch alle Organisationen, die personenbezogene Daten von EU-Bürgern verarbeiten. NIS‑2, DORA und der Cyber Resilience Act definieren dagegen spezifische Sektoren, Schwellenwerte und Produktkategorien.

In der Praxis wirken viele Anforderungen jedoch mittelbar: Wenn Ihre Kunden reguliert sind, werden sie vertraglich ähnliche Pflichten an Sie weiterreichen – etwa zu Security, Incident-Response, Portabilität oder Audit-Fähigkeit. Es lohnt sich deshalb, die Regelungen nicht isoliert nach „gilt/gilt nicht“ zu betrachten, sondern zu prüfen, welche Prinzipien für Ihr Geschäftsmodell ohnehin sinnvoll sind.

Wie kann ich verhindern, dass ich für jede Regulierung ein getrenntes Projekt aufsetzen muss?

Der Schlüssel ist ein integrierter Ansatz:

• Ein zentrales ISMS (z. B. ISO 27001) als Rahmen für Risk-Management, Policies und Kontrollen
• Ein einheitliches Architektur- und Plattformkonzept, das Portabilität, Security-by-Design und Observability ab Werk mitbringt
• Gemeinsame Prozesse für Incident-Response, Change-Management, Supplier-Management und Dokumentation

Auf dieser Basis können Sie einzelne regulatorische Anforderungen eher als „zusätzliche Schichten“ verstehen, die Sie in einem bestehenden System verankern – statt jeweils neue Silos aufzubauen.

Welche Rolle spielt die Wahl des Cloud-Providers für meine Compliance?

Die Wahl des Providers ist wichtig, aber sie ersetzt nicht die eigene Verantwortung. Ein souveräner, europäischer Provider mit starken Sicherheits- und Compliance-Fähigkeiten macht es einfacher, GDPR, NIS‑2, DORA, Data Act und das Cloud Sovereignty Framework zu erfüllen. Gleichzeitig bleiben Sie als Verantwortliche:r für die Gesamtarchitektur, Konfiguration, Prozesse und Lieferkette zuständig.

Wichtiger als „Hyperscaler vs. europäischer Provider“ ist ein klares Zielbild: Welche Daten dürfen wo liegen? Wie stellen Sie Exit-Fähigkeit sicher? Welche Souveränitätsanforderungen haben Ihre Kunden? Daraus ergeben sich oft hybride Modelle, in denen Sie bewusst mehrere Provider und Betriebsformen kombinieren.

Weitere Fragen? Siehe unsere FAQ

---

Von der Theorie zur Umsetzung

Die größte Herausforderung liegt selten darin, eine weitere Regulierungsübersicht zu lesen. Die eigentliche Kunst besteht darin, diese Vorgaben in tragfähige Architektur-, Plattform- und Organisationsentscheidungen zu übersetzen – ohne Ihr Engineering-Team mit juristischen Details zu überfrachten.

Genau hier setzt ayedo an.

Wir entwickeln und betreiben cloud-native Plattformen, die Datenschutz, Security, Resilienz und Portabilität von Anfang an berücksichtigen. Gemeinsam mit Ihren Fachbereichen und Ihrer Rechtsabteilung übersetzen wir Anforderungen aus GDPR, NIS‑2, DORA, Cyber Resilience Act, Data Act und dem Cloud Sovereignty Framework in:

• ein konsistentes Plattformdesign – von Netzwerksegmentierung über Identity & Access Management bis zu Observability
• Betriebsprozesse, die Incident-Response, Change-Management, Backup/Restore und Exit-Szenarien realistisch abbilden
• dokumentierte Referenzarchitekturen und Runbooks, die gegenüber Auditoren und Kunden belastbar sind

Unser Anspruch dabei ist pragmatisch: Wir kombinieren regulatorische Anforderungen mit technischen Best Practices, statt abstrakte „Compliance-Programme“ zu entwerfen. So entsteht eine Infrastruktur, die nicht nur compliant ist, sondern Ihre Produktentwicklung beschleunigt und neue Kundensegmente öffnet – etwa im öffentlichen Sektor oder in regulierten Branchen.

Wenn Sie Ihre Compliance-Strategie mit Ihrer technischen Realität in Einklang bringen möchten, sprechen Sie uns an: Kostenlose Erstberatung