Wie die EU-Regulierungen zusammenhängen: Ein integrierter Compliance-Ansatz

TL;DR

• Die europäische Regulierungslandschaft ist bewusst verzahnt: Die GDPR bildet das Fundament, darauf bauen NIS‑2, DORA, Cyber Resilience Act und Data Act auf – ergänzt durch das Cloud Sovereignty Framework als Beschaffungsleitlinie.
• Ein integrierter Ansatz reduziert den Aufwand erheblich: Ein solides ISMS nach ISO 27001, gelebte GDPR-Konformität und cloud-native Prinzipien decken große Teile der Anforderungen aller genannten Regulierungen gleichzeitig ab.
• NIS‑2 (ab Oktober 2024) und DORA (ab Januar 2025) fokussieren Cyber-Resilienz und operatives Risikomanagement; CRA (ab 2027) und Data Act (ab September 2025) verschieben den Fokus auf sichere Produkte, Interoperabilität und Vendor-Neutralität.
• Das Cloud Sovereignty Framework macht diese Anforderungen für Einkauf und Architektur messbar und verbindet Datenschutz, Security, Exit-Fähigkeit und Souveränität zu konkreten Auswahlkriterien für Cloud- und SaaS-Services.
• ayedo verfolgt einen integrierten Compliance-Ansatz: Wir kombinieren ISO‑27001-orientierte Prozesse, cloud-native Architektur-Patterns und EU-Regulierungswissen, um Organisationen strukturiert zu einer tragfähigen, auditierbaren Compliance-Strategie zu führen.

---

GDPR als Fundament: Privacy by Design als roter Faden

Die GDPR ist seit dem 25. Mai 2018 unmittelbar anwendbares Recht in der EU – und sie ist mehr als „nur“ Datenschutz. Sie definiert Prinzipien, die sich quer durch die gesamte Regulierungslandschaft ziehen:

• Datenminimierung, Zweckbindung, Transparenz
• Privacy by Design und by Default
• Sicherheit der Verarbeitung (Art. 32)
• Nachweispflichten (Accountability)

Diese Prinzipien sind anschlussfähig an alle weiteren Regulierungen:

• NIS‑2 und DORA konkretisieren „Sicherheit der Verarbeitung“ in Richtung organisatorischer und technischer Resilienz.
• Der Cyber Resilience Act überträgt Privacy/Security by Design auf die Ebene von Produkten und Software-Lieferketten.
• Der Data Act verbindet Datenschutz mit Interoperabilität, Datenzugang und Portabilität.

Organisationen, die GDPR nicht nur formal, sondern architektonisch ernst nehmen, schaffen sich damit eine tragfähige Basis:

• Klar definierte Datenflüsse und Datenklassen
• Rollen- und Berechtigungskonzepte, die sich in Identity- und Access-Management-Systemen wiederfinden
• Prozesse für Data Breaches, die sich mit Incident-Response-Prozessen nach NIS‑2/DORA harmonisieren lassen
• Dokumentation, die als Grundlage für Audits nach ISO 27001 und sektorale Prüfungen dient

Praktisch heißt das: Ein funktionierendes Datenschutz-Managementsystem (DSMS), das eng mit dem Informationssicherheits-Managementsystem (ISMS) verzahnt ist, ist kein „Add-on“, sondern die Basis für einen integrierten Compliance-Ansatz.

---

NIS‑2 und DORA: Cyber-Resilienz in der Fläche und im Finanzsektor

Mit NIS‑2 adressiert die EU ab dem 18. Oktober 2024 einen breiten Kreis von Betreibern kritischer und wichtiger Einrichtungen in 18 Sektoren – von Energie und Gesundheit bis hin zu digitalen Infrastrukturen. DORA tritt am 17. Januar 2025 in Kraft und fungiert als lex specialis für den Finanzsektor.

NIS‑2: Horizontal über 18 Sektoren

Die NIS‑2-Richtlinie fordert insbesondere:

• Systematisches Risikomanagement für Netz- und Informationssysteme
• Technische und organisatorische Maßnahmen zur Cyber-Resilienz
• Meldepflichten bei Sicherheitsvorfällen
• Management-Verantwortung und persönliche Haftung
• Berücksichtigung der Supply-Chain-Security

Viele dieser Anforderungen überlappen mit Art. 32 GDPR (Sicherheit der Verarbeitung) und mit ISO 27001:

• Risikomanagement: Bedrohungs- und Schwachstellenanalyse, Bewertung von Eintrittswahrscheinlichkeit und Impact
• Maßnahmenkataloge: Zugriffskontrollen, Netzwerksicherheit, Logging, Härtung, Backup & Recovery
• Incident-Response: Erkennung, Bewertung, Behandlung, Kommunikation
• Governance: Verantwortlichkeiten, Schulungen, Management-Reporting

DORA: Vertiefung für den Finanzsektor

DORA setzt genau an diesen Punkten an, geht aber tiefer:

• IKT-Risikomanagement mit klaren Kontrollzielen
• Kontinuierliches Testing, inklusive Threat-Led Penetration Testing (TLPT)
• Strenges Drittparteirisikomanagement: Vertragsanforderungen, Exit-Strategien, Konzentrationsrisiken
• Vereinheitlichte Berichts- und Meldepflichten für IKT-Incidents

Für Technologie- und Plattformverantwortliche bedeutet das: Wer ein ISMS nach ISO 27001 sauber implementiert, risikobasierte Security-Prozesse etabliert und diese cloud-nativ denkt, steht sowohl für NIS‑2 als auch für DORA deutlich besser da. Die regulatorische „Mehrarbeit“ ist geringer, wenn die Grundstrukturen bereits vorhanden sind.

---

CRA und Data Act: Security by Design und Interoperabilität auf Produktebene

Während NIS‑2 und DORA die operative Resilienz von Organisationen adressieren, konzentrieren sich der Cyber Resilience Act und der Data Act auf Produkte, Software und Datenökosysteme.

Cyber Resilience Act: Produkte müssen sicher konstruiert sein

Der CRA wird voraussichtlich ab 2027 voll anwendbar sein. Er verpflichtet Hersteller von Produkten mit digitalen Elementen – also faktisch große Teile der Software- und IoT-Industrie – zu:

• Security by Design über den gesamten Produktlebenszyklus
• Klarer Definition und Dokumentation der Sicherheitsfunktionen
• Erstellung und Pflege einer Software Bill of Materials (SBOM)
• Vulnerability-Management und koordinierter Vulnerability Disclosure
• Updatepflichten, insbesondere für Sicherheitsupdates
• Technischer Dokumentation als Grundlage für CE-Kennzeichnung

Auf Architekturseite fördert der CRA klare Modulgrenzen, reproduzierbare Builds, standardisierte Deployment-Prozesse und Transparenz in der Software-Supply-Chain – alles Prinzipien, die in modernen Cloud-Native-Stacks ohnehin Best Practice sind.

Data Act: Interoperabilität und Exit-Fähigkeit

Der Data Act wird ab dem 12. September 2025 anwendbar. Für Cloud-Provider, SaaS-Anbieter und Betreiber von Datenplattformen sind insbesondere folgende Punkte relevant:

• Datenportabilität und Interoperabilität – sowohl für Nutzer als auch zwischen Cloud-Diensten
• Verpflichtung zu offenen, dokumentierten Schnittstellen
• Vermeidung von technischem und vertraglichem Vendor Lock-in
• Verpflichtende Exit-Pläne und Runbooks für Daten- und Service-Migrationen
• Transparente Kostenmodelle für Migration und Datenzugriff

Für Cloud-Native-Architekturen ist das eine gute Nachricht: Wer ohnehin auf containerisierte Workloads, standardisierte Orchestrierung (z. B. Kubernetes) und offene Protokolle setzt, erfüllt bereits viele technische Voraussetzungen für Data-Act-Konformität. Die eigentliche Arbeit liegt in:

• Dokumentation der Portabilität
• Standardisierung der Exportformate
• Etablierung formaler Exit-Prozesse
• Vertragsgestaltung mit Kunden und Subdienstleistern

---

Cloud Sovereignty Framework: Beschaffung als Hebel für Compliance

Das Cloud Sovereignty Framework der EU-Kommission ist kein Gesetz, sondern ein Beschaffungsrahmen. Er hilft insbesondere öffentlichen Auftraggebern, Cloud- und Plattform-Dienste entlang von acht Souveränitätszielen (SOV‑1 bis SOV‑8) zu bewerten.

Wesentliche Verknüpfungen:

• SOV‑3 (Data Sovereignty) verlangt faktisch GDPR-Konformität und Klarheit über Datenzugriffe durch Drittstaaten.
• SOV‑4 (Operational Sovereignty) fordert Exit-Fähigkeit, Interoperabilität und damit direkte Anknüpfung an den Data Act.
• SOV‑7 (Security/Compliance) orientiert sich an der Erfüllung von NIS‑2- bzw. DORA-Anforderungen für Betrieb und Organisation.

Für Architektur- und Plattformverantwortliche ergibt sich daraus eine klare Leitlinie: Wenn Sie Infrastrukturen und Services so gestalten, dass sie in der SOV-Logik gut abschneiden, erhöhen Sie nicht nur Ihre Chancen in Ausschreibungen, sondern erfüllen gleichzeitig zentrale Anforderungen aus den zugrunde liegenden Regulierungen.

Praktisch bedeutet das:

• Klare Trennung von Datenebenen (z. B. personenbezogen, geschäftskritisch, öffentlich)
• Transparente Datenlokation (Regionen, Rechtsräume), idealerweise mit EU-Fokus
• Portabilität von Workloads zwischen Providern und/oder souveränen Plattform-Angeboten
• Nachweisbare Security- und Compliance-Prozesse, idealerweise durch ISO-Zertifizierungen

---

Synergien nutzen: Ein ISMS, GDPR und Cloud-Native als gemeinsamer Nenner

Die eigentliche Chance eines integrierten Compliance-Ansatzes liegt in den Synergien. Viele Anforderungen der Regulierungen sind strukturell identisch, wenn man sie auf eine abstrakte Ebene hebt.

ISO 27001 als Rückgrat

Ein Informationssicherheits-Managementsystem nach ISO 27001 bildet ein hervorragendes Raster, um Anforderungen aus GDPR, NIS‑2, DORA und CRA zu integrieren:

• Risikobasierter Ansatz: Risikoanalysen und -behandlung sind Kern von ISO 27001, NIS‑2, DORA und CRA.
• Organisation & Governance: Rollen, Verantwortlichkeiten, Policies, Schulungen.
• Technische Maßnahmen: Zugriffskontrolle, Kryptografie, Logging, Netzwerk- und Systemhärtung.
• Kontinuierliche Verbesserung: Plan-Do-Check-Act, interne Audits, Management-Reviews.

Statt für jede Regulierung eigene „Silos“ aufzubauen, können Sie die Anforderungen in ein einziges Control-Framework mappen und Überschneidungen bewusst nutzen.

GDPR- und Security-Management verzahnen

Die Verbindung von Datenschutz und Security ist zentral:

• Datenschutz-Folgenabschätzungen (DPIAs) können als Input für Risikoanalysen im ISMS dienen.
• Incident-Response-Pläne berücksichtigen gleichzeitig Data-Breach-Meldepflichten und NIS‑2-/DORA-Reporting.
• Rollen wie DPO (Datenschutzbeauftragter) und CISO arbeiten auf einer gemeinsamen Risikobasis statt in getrennten Bahnen.

Cloud-Native Entwicklung als Enabler

Cloud-native Prinzipien – insbesondere Automatisierung, Immutability, deklarative Infrastruktur und beobachtbare Systeme – unterstützen Compliance an vielen Stellen:

• Reproduzierbare Deployments helfen, CRA-Anforderungen an Produktkonsistenz und Updatefähigkeit zu erfüllen.
• Standardisierte APIs und lose Kopplung fördern Interoperabilität im Sinne des Data Act.
• Zentralisiertes Logging, Metriken und Tracing sind Grundlage für Incident Detection nach NIS‑2/DORA.
• Externalisierte Konfiguration und Secrets-Management unterstützen GDPR-konforme Trennung und Absicherung personenbezogener Daten.

Wer diese drei Ebenen – ISMS, Datenschutz und Cloud-Native-Architektur – bewusst aufeinander abstimmt, reduziert redundanten Aufwand und verkürzt Time-to-Compliance.

---

Organisatorische Schritte zu einem integrierten Compliance-Ansatz

Ein integrierter Ansatz entsteht nicht automatisch; er ist das Ergebnis bewusster Gestaltung. Aus der Praxis heraus haben sich folgende Schritte bewährt:

1. Gemeinsame Landkarte der Anforderungen erstellen

• Alle relevanten Regulierungen identifizieren (GDPR, NIS‑2, DORA, CRA, Data Act, ggf. branchenspezifische Normen).
• Anforderungen in einer gemeinsamen Control-Struktur abbilden – idealerweise entlang ISO 27001.
• Überschneidungen markieren: Wo deckt ein Control mehrere regulatorische Anforderungen ab?

2. Rollen und Governance klären

• Klare Verantwortlichkeiten: Wer verantwortet Datenschutz, Informationssicherheit, Cloud-Architektur, Produktentwicklung, Einkauf?
• Gremien etablieren (z. B. Security & Compliance Board), in denen technische und rechtliche Perspektiven zusammenkommen.
• Entscheidungsprozesse definieren, z. B. für die Auswahl neuer Cloud-Dienste oder für Architekturentscheidungen mit Compliance-Impact.

3. Technische Leitplanken festlegen

• Architekturprinzipien definieren, die sowohl Souveränität als auch Compliance unterstützen (z. B. „EU-first“-Regionen, portierbare Workloads, offene Standards).
• Mindestanforderungen an Lieferanten und Dienstleister formulieren (z. B. ISO-Zertifizierungen, Datenlokation, Exit-Szenarien).
• Platform-Engineering-Teams befähigen, Compliance-Anforderungen früh in Self-Service-Plattformen zu integrieren, statt später ad hoc nachzurüsten.

4. Dokumentation und Nachweisfähigkeit priorisieren

• Prozesse, Policies und technische Maßnahmen so dokumentieren, dass sie sowohl internen Stakeholdern als auch Auditoren verständlich sind.
• Tooling für Audit-Trails, Konfigurationshistorien und Evidence-Management etablieren.
• Reporting-Strukturen aufbauen, die Management und Aufsichtsgremien die nötige Transparenz geben – auch im Sinne der Management-Haftung unter NIS‑2.

5. Compliance als kontinuierlichen Prozess verstehen

• Regelmäßige Gap-Analysen in Bezug auf neue regulatorische Klarstellungen und Leitlinien.
• Retrospektiven nach Incidents und Audits, um Prozesse anzupassen.
• Schulungsprogramme für technische und nicht-technische Rollen, um Bewusstsein und Kompetenz auf aktuellem Stand zu halten.

---

Häufige Fragen

Bedeutet jede neue EU-Regulierung einen zusätzlichen Projekt- und Kostenblock?

Nicht zwingend – vorausgesetzt, Sie verfolgen einen integrierten Ansatz. Viele Anforderungen wiederholen sich mit leicht anderer Terminologie: Risikomanagement, Incident-Response, Dokumentation, Lieferkettenkontrolle, Datenschutzgrundsätze. Wenn Sie diese Aspekte in einem gemeinsamen Framework (z. B. ISO 27001 plus GDPR-DSMS) verankern, entstehen zusätzliche Aufwände vor allem dort, wo tatsächlich neue Themen hinzukommen – etwa SBOM und Vulnerability-Disclosure beim Cyber Resilience Act oder Exit-Runbooks im Data Act. Der Schlüssel ist, frühzeitig eine übergreifende Governance aufzubauen, statt Verordnungen isoliert nacheinander „abzuhaken“.

Wie kann ich Cloud-Souveränität und Portabilität praktisch umsetzen, ohne alles selbst zu betreiben?

Souveränität bedeutet nicht zwingend Voll-Selbstbetrieb im eigenen Rechenzentrum. Entscheidend ist, dass Sie:

• Klarheit über Datenlokation und Rechtsräume haben,
• Portabilität Ihrer Workloads und Daten nachweisen können,
• Exit-Szenarien mit Ihren Dienstleistern vertraglich und technisch abgesichert haben,
• und die Anforderungen aus GDPR, NIS‑2/DORA und Data Act in die Auswahl- und Architekturentscheidungen einbeziehen.

In der Praxis kann das eine Kombination aus europäischen Cloud-Anbietern, souveränen Managed-Services und eigenen, portierbaren Workloads sein. Platform-Engineering, standardisierte Deployments und saubere Schnittstellen sind hier wichtiger als die Frage „Cloud vs. On-Prem“.

Wie unterstützt ayedo beim Aufbau eines integrierten Compliance-Ansatzes?

ayedo kombiniert Architektur-, Plattform- und Compliance-Expertise. In Projekten übersetzen wir regulatorische Anforderungen (GDPR, NIS‑2, DORA, Cyber Resilience Act, Data Act) in konkrete organisatorische und technische Leitplanken: vom Design eines ISO‑27001-fähigen ISMS über Datenschutz- und Security-Governance bis hin zur Gestaltung souveräner Plattformen, die sich an den Zielen des Cloud Sovereignty Framework ausrichten. Unser Fokus liegt darauf, Strukturen zu schaffen, die langfristig tragfähig sind – nicht auf kurzfristigen Sichtprüfungen.

Weitere Fragen? Siehe unsere FAQ

---

Von der Theorie zur Umsetzung

Ein integrierter Compliance-Ansatz ist keine Folie, sondern eine Architekturentscheidung – organisatorisch wie technisch. Die EU-Regulierungen setzen dabei bewusst Anreize, in robuste Strukturen zu investieren: GDPR als Fundament, NIS‑2 und DORA für operative Resilienz, CRA und Data Act für sichere, portable Produkte und das Cloud Sovereignty Framework als Leitlinie für souveräne Beschaffung.

ayedo positioniert sich genau an dieser Schnittstelle: zwischen Regulierung, Cloud-Native-Technik und europäischer Souveränität. In gemeinsamen Projekten mit Kunden beginnen wir typischerweise mit einer konsolidierten Sicht auf Ihre bestehende Landschaft:

• Welche Prozesse und Kontrollen existieren bereits im Sinne von ISO 27001 und GDPR?
• Wie sind Ihre Plattformen und Workloads heute aufgebaut – und wie portierbar sind sie tatsächlich?
• Welche regulatorischen Anforderungen sind für Ihre Branche konkret relevant, und wo gibt es Synergien?

Darauf aufbauend entwickeln wir eine Zielarchitektur, die Compliance als Eigenschaft Ihres Systems mitdenkt: ISMS-Controls werden in Plattform- und Deployment-Standards übersetzt, Datenschutz und Security werden in Self-Service-Plattformen eingebettet, und Exit-Fähigkeit wird von Beginn an als Designziel verankert. So entstehen Infrastrukturen, die sich nicht nur auditieren lassen, sondern auch strategische Handlungsfähigkeit sichern – gerade im europäischen Kontext.

Wenn Sie aus der Vielzahl der Verordnungen eine konsistente, tragfähige Linie machen wollen, ist der erste Schritt eine integrierte Compliance-Strategie. Dabei unterstützen wir Sie gerne – von der konzeptionellen Ausrichtung bis zur praktischen Umsetzung in Ihrer Plattform- und Prozesslandschaft: Integrierte Compliance-Strategie