Governance von Cloud-Regionen für GDPR, NIS2 und DORA

Um 08:17 Uhr an einem Dienstagmorgen erhält Maria, CISO eines schnell wachsenden europäischen Fintechs, die Nachricht, die jeder regulierte Cloud-Kunde früher oder später fürchtet.

Das Beschaffungsteam leitet eine kurze Lieferantenmitteilung weiter:

“Unser Anbieter für Cloud-Analysen verlagert die EU-Kundentelemetrie aus Performance-Gründen in eine neue Region. Nach seiner Aussage gibt es keine Auswirkungen auf die Sicherheit. Können wir zustimmen?”

Bevor Maria antworten kann, trifft eine zweite Benachrichtigung des primären Cloud-Service-Providers ein. Mit Wirkung in 90 Tagen wird der Anbieter sein “globales Support-Modell optimieren”, indem er Tier-2-Support-Tickets über einen neuen Unterauftragsverarbeiter routet. Eine kurze Prüfung zeigt: Der Unterauftragsverarbeiter hat seinen Sitz in einem Land ohne GDPR-Angemessenheitsbeschluss.

Um 09:00 Uhr sind Recht, Datenschutz, Resilienz, Beschaffung, Cloud Engineering und Finanz-Compliance bereits im Thread. Der DPO fragt, ob ein Transfer Impact Assessment erforderlich ist. Der Resilienzmanager fragt, ob die neue Region den Wiederherstellungsplan für einen kritischen Service beeinflusst. Die Leitung der Finanz-Compliance fragt, ob der Anbieter im DORA-Informationsregister für IKT-Drittdienstleister erscheint. Das Cloud-Team prüft die Produktionsdatenebene und erkennt, dass das Problem über Analytics hinausgeht. Backups, Betriebsprotokolle, Support-Tickets, Data-Lake-Exporte, Break-Glass-Zugriff und Zugriffe durch Unterauftragsverarbeiter können sämtlich in den Geltungsbereich fallen.

Das ist das tatsächliche Cloud-Governance-Problem im Jahr 2026.

Die meisten Organisationen haben eine Cloud-Richtlinie. Viele haben ein Lieferantenregister. Einige verfügen über eine GDPR-Übermittlungsbewertung. Weniger Organisationen können die schwierigere Auditfrage nachweisbar beantworten:

Wo genau befinden sich regulierte Daten und kritische IKT-Verarbeitung, wer kann von wo darauf zugreifen, was geschieht im Failover-Fall, und welche vertragliche Kontrolle verhindert, dass der Anbieter die Antwort ohne Genehmigung ändert?

Das ist Governance von Cloud-Regionen. Sie ist kein einzelnes rechtliches Kontrollkästchen. Sie ist ein lebendes Kontrollsystem über ISO/IEC 27001:2022, Cloud- und Lieferantenmaßnahmen nach ISO/IEC 27002:2022, Rechenschaftspflicht nach GDPR, Service-Resilienz nach NIS2 und IKT-Drittparteienaufsicht nach DORA hinweg.

Datenresidenz ist jetzt eine operative Kontrolle

Über Jahre wurde “EU-only Hosting” als Klausel in einem Auftragsverarbeitungsvertrag behandelt. Das reicht nicht mehr aus. Ein modernes Programm für Cloud-Datenresidenz und Governance von Cloud-Regionen muss mindestens sechs operative Ebenen abdecken:

1. Primäre Produktionsregionen für Speicher und Rechenleistung.
2. Regionen für Backup, Archivierung und Disaster Recovery.
3. Speicherorte für Protokollierung, Überwachung, SIEM- und Observability-Daten.
4. Support-Zugriff, einschließlich Remote-Administration und Break-Glass-Zugriff.
5. Unterauftragsverarbeiter und Unterauftragnehmer, einschließlich Managed Services und Marketplace-Komponenten.
6. Datenübermittlungspfade zwischen Umgebungen, APIs, Analyseplattformen und Kundensupport-Werkzeugen.

GDPR macht dies unvermeidbar, weil personenbezogene Daten Online-Kennungen, IP-Adressen, Kundenkontokennungen, Benutzerdatensätze, Gerätekennungen, betriebliche Metadaten und Support-Aufzeichnungen umfassen können. Verarbeitung ist ebenfalls weit definiert und umfasst Speicherung, Zugriff, Nutzung, Offenlegung, Löschung und Vernichtung. “Wir senden nur Protokolle” ist keine sichere Ausnahme, wenn diese Protokolle Kennungen enthalten.

GDPR Article 5 enthält außerdem den Grundsatz der Rechenschaftspflicht. Verantwortliche müssen die Grundsätze der Rechtmäßigkeit, Verarbeitung nach Treu und Glauben, Transparenz, Zweckbindung, Datenminimierung, Speicherbegrenzung, Integrität und Vertraulichkeit nicht nur einhalten. Sie müssen die Einhaltung auch nachweisen können. Governance von Cloud-Regionen ist ein Weg, wie dieser Nachweis belastbar wird.

NIS2 erweitert das Thema von Datenschutz auf Resilienz. Nach Article 21 müssen wesentliche und wichtige Einrichtungen geeignete technische, operative und organisatorische Maßnahmen umsetzen, um Risiken für Netz- und Informationssysteme zu steuern, die für den Betrieb oder die Leistungserbringung genutzt werden. Die aufgeführten Maßnahmen umfassen Sicherheit der Lieferkette, Aufrechterhaltung des Geschäftsbetriebs, Backup-Management, Disaster Recovery, Krisenmanagement, Zugriffskontrolle, Asset-Management, Verschlüsselung und Wirksamkeitsbewertung. Wenn eine Entscheidung über eine Cloud-Region die Verfügbarkeit oder Wiederherstellung eines im Geltungsbereich liegenden Services beeinflusst, ist sie nicht nur eine Datenschutzfrage. Sie ist eine Resilienzfrage.

Für Finanzunternehmen erhöht DORA den Maßstab weiter. DORA gilt ab dem 17. Januar 2025 und legt Anforderungen an das IKT-Risikomanagement, die Vorfallmeldung, Tests der digitalen operationalen Resilienz, das IKT-Drittparteienrisikomanagement und vertragliche Vereinbarungen fest. Article 28 verlangt von Finanzunternehmen, IKT-Drittparteienrisiken als integralen Bestandteil des Rahmenwerks für das Management von IKT-Risiken zu steuern, Register vertraglicher Vereinbarungen zu führen, Konzentrationsrisiken zu bewerten und Exits für kritische oder wichtige Funktionen zu planen. Article 30 erwartet vertragliche Klarheit über Standorte der Service- und Datenverarbeitung, Audit- und Zugangsrechte, Unterstützung bei Vorfällen, Untervergabe, Wiederherstellung, Rückgabe und Exit-Transition.

DORA fungiert als sektorspezifisches Regelwerk für Finanzunternehmen, während NIS2 in der breiteren Lieferkette weiterhin relevant bleibt, insbesondere für Anbieter von Cloud-Computing-Diensten, Rechenzentrumsanbieter und Managed Service Provider. Ein einzelner nicht geprüfter Unterauftragsverarbeiter kann daher einen Dominoeffekt über finanzielle Resilienz, Sicherheit der Lieferkette und Datenschutzverpflichtungen auslösen.

Einfach ausgedrückt: Wenn ein reguliertes Unternehmen nicht steuern kann, wo seine Cloud-Verarbeitung stattfindet, kann es IKT-Drittparteienrisiken nicht glaubwürdig steuern.

ISO 27001 als Anker des Managementsystems nutzen

ISO/IEC 27001:2022 bietet die Struktur, um Unsicherheit über Datenresidenz in ein kontrolliertes Managementsystem zu überführen.

Die Abschnitte 4.1 bis 4.4 verlangen, dass die Organisation das ISMS im Kontext definiert, einschließlich interner und externer Themen, Anforderungen interessierter Parteien, gesetzlicher, regulatorischer und vertraglicher Verpflichtungen sowie Schnittstellen und Abhängigkeiten zu anderen Organisationen. Für die Governance von Cloud-Regionen sollte der ISMS-Geltungsbereich Cloud-Services, ausgelagerte IKT-Verarbeitung, kritische Serviceabhängigkeiten und regulierte Datenflüsse ausdrücklich einschließen.

Die Abschnitte 5.1 bis 5.3 machen die Führung rechenschaftspflichtig. Die oberste Leitung muss die Informationssicherheitsleitlinie und Informationssicherheitsziele an der strategischen Ausrichtung ausrichten, Ressourcen bereitstellen, Verantwortlichkeiten zuweisen und sicherstellen, dass über die ISMS-Leistung berichtet wird. Hier wird Cloud-Residenz zum Thema für Management und Leitungsorgan, insbesondere für NIS2-Einrichtungen, bei denen Leitungsorgane Cybersicherheits-Risikomanagementmaßnahmen genehmigen und überwachen müssen, sowie für DORA-Finanzunternehmen, bei denen das Leitungsorgan für die IKT-Risiko-Governance verantwortlich ist.

Die Abschnitte 6.1.1 bis 6.1.3 stellen den Risikomotor bereit. Die Organisation benötigt einen wiederholbaren Risikobeurteilungsprozess, Risikoverantwortliche, Kriterien für Auswirkungen und Eintrittswahrscheinlichkeit, Behandlungsoptionen, ausgewählte Maßnahmen, eine Anwendbarkeitserklärung und Restrisikoakzeptanz. Eine Änderung der Cloud-Region sollte nicht über eine informelle E-Mail genehmigt werden. Sie sollte eine Risikobeurteilung oder Änderungsprüfung auslösen, wenn sie regulierte Daten, kritische Funktionen, Lieferanten oder Annahmen zur Aufrechterhaltung des Geschäftsbetriebs betrifft.

Abschnitt 8.1 überführt Planung in operative Steuerung. Prozesse müssen umgesetzt, kontrolliert, dokumentiert, gesteuert geändert und auf extern bereitgestellte, für das ISMS relevante Produkte und Dienstleistungen erweitert werden. Die Abschnitte 8.2 und 8.3 verlangen Neubewertung und Behandlung in geplanten Abständen oder bei wesentlichen Änderungen. Cloud-Region-Migration, Backup-Replikation, eine neue Protokollierungsplattform oder eine Änderung des Support-Unterauftragsverarbeiters sind sämtlich Kandidaten für eine Neubewertung.

Der Maßnahmenkatalog ISO/IEC 27002:2022 liefert anschließend die praktische Kontrollfamilie. Zu den relevantesten Maßnahmen gehören:

• 5.9 Inventar von Informationen und anderen zugehörigen Assets.
• 5.14 Informationsübertragung.
• 5.15 Zugriffskontrolle.
• 5.19 Informationssicherheit in Lieferantenbeziehungen.
• 5.20 Behandlung der Informationssicherheit in Lieferantenvereinbarungen.
• 5.22 Überwachung, Überprüfung und Änderungsmanagement von Lieferantendiensten.
• 5.23 Informationssicherheit bei Nutzung von Cloud-Diensten.
• 5.29 Informationssicherheit bei Störungen.
• 5.30 IKT-Bereitschaft für die Aufrechterhaltung des Geschäftsbetriebs.
• 5.31 Gesetzliche, satzungsmäßige, regulatorische und vertragliche Anforderungen.
• 5.34 Datenschutz und Schutz von PII.
• 5.36 Einhaltung von Richtlinien, Regeln und Standards für Informationssicherheit.
• 8.11 Datenmaskierung.
• 8.12 Verhinderung von Datenabfluss.
• 8.13 Informationssicherung.
• 8.15 Protokollierung.
• 8.16 Überwachungsaktivitäten.
• 8.20 Netzwerksicherheit.
• 8.24 Nutzung von Kryptografie.
• 8.25 Sicherer Entwicklungslebenszyklus.
• 8.27 Sichere Systemarchitektur und Engineering-Grundsätze.
• 8.32 Änderungsmanagement.

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls behandelt ISO/IEC 27002:2022 Control 5.23, Informationssicherheit bei Nutzung von Cloud-Diensten, als präventive Maßnahme zur Unterstützung von Vertraulichkeit, Integrität und Verfügbarkeit, mit operativer Befähigung im Bereich der Sicherheit von Lieferantenbeziehungen und mit Sicherheitsdomänen über Governance, Ökosystem und Schutz hinweg. Der Leitfaden verknüpft 5.23 mit 5.19 Lieferantenbeziehungen, 5.14 Informationsübertragung, 5.9 Asset-Inventar, 8.11 und 8.12 Datenmaskierung und Verhinderung von Datenabfluss, 8.20 Netzwerksicherheit und 8.25 Secure Development Lifecycle.

Eine zentrale Beobachtung aus Zenith Controls lautet:

“Cloud-Service-Provider (CSPs) fungieren als kritische Lieferanten; daher gelten alle Kontrollen zur Lieferantenauswahl, Vertragsgestaltung und zum Risikomanagement nach 5.19. 5.23 geht jedoch weiter, indem es cloud-spezifische Risiken adressiert, etwa Mandantenfähigkeit, Transparenz des Datenstandorts und Modelle geteilter Verantwortung.”

Dieser Satz beschreibt den Governance-Wandel. Ein Cloud-Anbieter ist nicht einfach ein weiterer Lieferant. Er ist häufig der Ort, an dem regulierte Verarbeitung stattfindet.

Die versteckten Residenzfallen: Backups, Protokolle, Support und Unterauftragsverarbeiter

Die meisten Fehler bei der Datenresidenz beginnen nicht in der Produktionsdatenbank. Sie beginnen in unterstützenden Systemen, die nie ordnungsgemäß in die Datenflussprüfung einbezogen wurden.

Backups sind das klassische Beispiel. Eine SaaS-Plattform kann in Frankfurt oder Dublin laufen, während automatisierte Backups aus Resilienz- oder Kostengründen an anderer Stelle repliziert werden. Enthält das Backup personenbezogene Daten, Kundendatensätze, Authentifizierungsprotokolle oder regulierte Transaktionshistorien, ist die Backup-Region relevant. Nach NIS2 Article 21 gehören Backup-Management und Disaster Recovery zur Sicherheitsbasislinie. Nach DORA erfordern die Kontinuität kritischer oder wichtiger Funktionen und getestete Exit-Strategien Kenntnisse über Wiederherstellungsstandorte und Wiederherstellungsabhängigkeiten.

Protokolle sind ein weiterer Schwachpunkt. Sicherheitsteams zentralisieren Telemetrie in SIEM-, Observability- und Data-Lake-Services. Diese Protokolle können IP-Adressen, Benutzerkennungen, Administratoraktivitäten, Zahlungsmetadaten, fehlgeschlagene Authentifizierungsversuche, Kundenkontokennungen oder Support-Trace-Daten enthalten. Wenn Protokolle in einen globalen Überwachungsdienst verschoben werden, kann die Organisation eine grenzüberschreitende Datenübermittlung geschaffen haben, ohne es zu bemerken.

Clarysecs Richtlinie zur Protokollierung und Überwachung - KMU Richtlinie zur Protokollierung und Überwachung - KMU adressiert Lieferantennachweise direkt:

“Verträge müssen Anbieter verpflichten, Protokolle mindestens 12 Monate aufzubewahren und auf Anfrage Zugriff zu gewähren.”

Dieses Zitat stammt aus dem Abschnitt “Governance-Anforderungen”, Richtlinienklausel 5.5.1.3. Für die Governance der Datenresidenz sollte dieselbe Vertragsprüfung bestätigen, wo diese Protokolle aufbewahrt werden, wer darauf zugreifen kann und ob Protokollnachweise während einer Untersuchung eines Informationssicherheitsvorfalls oder einer Anfrage von Aufsichtsbehörden verfügbar sind.

Support-Zugriff ist subtiler. Ein Anbieter kann Daten in der EU hosten, während Support-Ingenieure außerhalb der EU auf Kundenumgebungen, Datenbank-Snapshots, Diagnosepakete oder Ticket-Anhänge zugreifen können. Ob dies akzeptabel ist, hängt von den betroffenen Daten, dem Übermittlungsmechanismus, der Rolle, den vertraglichen Schutzmaßnahmen, Zugriffskontrollen und der Protokollierung ab. Die Architektur kann regional sein, während das menschliche Zugriffsmodell global ist.

Unterauftragsverarbeiter schaffen den letzten blinden Fleck. Ihr direkter Lieferant kann sich auf Cloud-Infrastruktur, Content-Delivery-Netzwerke, verwaltete Datenbanken, Ticketsysteme, Analysedienste, Offshore-Support-Teams oder Sicherheitsanbieter stützen. DORA Article 29 verlangt die Bewertung von Untervergaberisiken, Drittstaatenanbietern, Einschränkungen bei der Datenwiederherstellung, Einhaltung von Datenschutzanforderungen und komplexen Untervergabeketten. NIS2 Article 21 verlangt, dass Einrichtungen die Cybersicherheitspraktiken direkter Lieferanten und Dienstleister berücksichtigen. GDPR verlangt, dass Auftragsverarbeiter Unterauftragsverarbeiter so steuern, dass die Fähigkeit des Verantwortlichen zur Einhaltung erhalten bleibt.

Clarysecs Richtlinie zur Lieferanten- und Drittparteiensicherheit - KMU Richtlinie zur Lieferanten- und Drittparteiensicherheit - KMU macht dies praxisnah:

“Wenn Lieferanten verpflichtet sind, Daten außerhalb des Standorts zu speichern, muss das Unternehmen Zusicherungen zu Datenschutz, physischer Sicherheit und geografischem Speicherort einholen (z. B. EU-only Hosting, sofern nach GDPR erforderlich).”

Dies stammt aus dem Abschnitt “Anforderungen an die Umsetzung der Richtlinie”, Richtlinienklausel 6.2.4. Dieselbe Richtlinie verlangt außerdem:

“Beschränkungen weiterer Untervergabe ohne Genehmigung”

Dieses Zitat stammt aus dem Abschnitt “Governance-Anforderungen”, Richtlinienklausel 5.3.5. Zusammen verwandeln diese Klauseln Residenz in einen Workflow des Lieferantenmanagements, nicht in eine Beschaffungspräferenz.

Richtlinien in durchsetzbare Governance von Cloud-Regionen überführen

Governance von Cloud-Regionen muss durchsetzbar, überprüfbar und auditierbar sein.

Für KMU legt die Richtlinie zur Nutzung von Cloud-Diensten - KMU Richtlinie zur Nutzung von Cloud-Diensten - KMU die Baseline fest:

“Praktiken zur Datenresidenz und zum Datenschutz entsprechen den anwendbaren gesetzlichen Anforderungen (z. B. GDPR).”

Dies stammt aus dem Abschnitt “Governance-Anforderungen”, Richtlinienklausel 5.2.3. Dieselbe Richtlinie verlangt, dass Aufzeichnungen zur Cloud-Governance Folgendes enthalten:

“Das Land oder die Region, in der Daten gespeichert werden”

Dieses Zitat stammt aus dem Abschnitt “Governance-Anforderungen”, Richtlinienklausel 5.3.4.

Für größere Organisationen ist die Richtlinie zur Nutzung von Cloud-Diensten Richtlinie zur Nutzung von Cloud-Diensten hinsichtlich der vertraglichen Durchsetzung ausdrücklicher:

“Anforderungen an die Datenresidenz müssen vertraglich durchgesetzt werden (z. B. EU-only Speicherung für GDPR-regulierte Daten).”

Dies stammt aus dem Abschnitt “Anforderungen an die Umsetzung der Richtlinie”, Richtlinienklausel 6.6.2. Außerdem heißt es dort:

“Grenzüberschreitende Datenübermittlungen müssen GDPR Chapter V und, soweit anwendbar, DORA Article 28 entsprechen.”

Dies stammt aus dem Abschnitt “Anforderungen an die Umsetzung der Richtlinie”, Richtlinienklausel 6.6.3.

Die Enterprise-Version legt außerdem besonderes Augenmerk auf:

“Zusicherungen zur Datenresidenz und zum Dateneigentum”

Dieses Zitat stammt aus dem Abschnitt “Rollen und Verantwortlichkeiten”, Richtlinienklausel 4.5.1.2.

Die Richtlinie zur Lieferanten- und Drittparteiensicherheit Richtlinie zur Lieferanten- und Drittparteiensicherheit ergänzt die Vertragsebene, indem sie Folgendes verlangt:

“Anforderungen an die Datenverarbeitung, einschließlich Speicherort, Zugriffskontrollen sowie Klauseln zur Rückgabe oder Vernichtung”

Dieses Zitat stammt aus dem Abschnitt “Governance-Anforderungen”, Richtlinienklausel 5.3.2.

Schließlich identifiziert die Richtlinie zur rechtlichen und regulatorischen Einhaltung Richtlinie zur rechtlichen und regulatorischen Einhaltung Änderungen, die eine Compliance-Überprüfung auslösen sollten, darunter:

“Änderungen an Datenübermittlungsmechanismen, Unterauftragsverarbeitern oder grenzüberschreitenden Datenflüssen”

Dies stammt aus dem Abschnitt “Governance-Anforderungen”, Richtlinienklausel 5.3.1.1.

Diese Dokumente sollten nicht als getrennte Dateien betrieben werden. In einem reifen ISMS werden sie zu einem gemeinsamen Betriebsmodell: Cloud-Inventar, Datenflussregister, Lieferantenregister, Vertragsmatrix, Risikobeurteilung, Übermittlungsprüfung, Änderungsgenehmigung und Auditnachweispaket.

Ein Governance-Register für Cloud-Regionen aufbauen

Ein praktisches Register verwandelt Cloud-Residenz von einer Annahme in einen Nachweis. Beginnen Sie mit einem kritischen kundenbezogenen Service, insbesondere einem Service, der voraussichtlich in den Geltungsbereich von NIS2, DORA-Kunden-Due-Diligence oder GDPR-Prüfung fällt.

Verbinden Sie das Register anschließend mit der Umsetzung.

In Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint konzentriert sich die Phase Controls in Action, Step 23, auf organisatorische Maßnahmen 5.19 bis 5.37, einschließlich Lieferantenvereinbarungen und Cloud-Service-Governance. Der Blueprint weist darauf hin, dass Lieferantenvereinbarungen mehr als generische Vertraulichkeit abdecken müssen:

“In vielen Branchen definieren Lieferantenvereinbarungen auch Dateneigentum und Rechtsraum. Wo werden Daten verarbeitet? Wer behält die Kontrolle? Gibt es Übermittlungsbeschränkungen? Gibt es cloud-spezifische Kontrollen wie Datensegmentierung, Schlüsseleigentum oder geografische Beschränkungen? Diese Elemente sind nicht nur rechtlich; sie sind operative Sicherheitsfragen, insbesondere in regulierten Sektoren.”

Dieselbe Phase und derselbe Schritt behandeln das Änderungsmanagement von Lieferanten:

“Die meisten Lieferantenbeziehungen beginnen mit guten Absichten. Eine gründliche Prüfung, klare Erwartungen, unterzeichnete Vereinbarungen (siehe 5.20), vielleicht sogar eine Sicherheitscheckliste. Aber was passiert ein Jahr später, wenn der Lieferant vorschlägt, Ihre Daten in eine neue Cloud-Region zu verlagern?”

Das ist Marias Dienstagmorgen-Problem. Das Register gibt dem CISO die Möglichkeit, vor Genehmigung der Verlagerung zu antworten.

Der Zenith Blueprint klärt außerdem die Governance-Bedeutung der Cloud-Maßnahme 5.23:

“Ein fehlerhaft konfigurierter Storage Bucket, ein öffentlich exponiertes Dashboard oder übermäßige Berechtigungen in einer Cloud-IAM-Konfiguration – das sind keine Cloud-Ausfälle. Es sind Governance-Versäumnisse.”

In der Phase Controls in Action, Step 22, behandelt der Blueprint Informationsübertragung und stellt fest:

“Wenn personenbezogene Daten grenzüberschreitend übermittelt werden, muss die Methode Datenschutz- und Rechtsverpflichtungen entsprechen, nicht nur internen Präferenzen.”

Diese Aussage ist für Cloud-Teams wichtig. Verschlüsselung, sichere APIs und private Konnektivität sind notwendig, ersetzen aber keine rechtliche und regulatorische Governance von Übermittlungen.

Den ersten 90-minütigen Nachweis-Workshop durchführen

Beginnen Sie nicht damit, das gesamte Unternehmen zu kartieren. Starten Sie mit einem kritischen Service und führen Sie einen fokussierten Workshop mit Cloud Engineering, Beschaffung, Recht, Datenschutz, Resilienz und Security Operations durch.

Erstens: Listen Sie jede Cloud- oder Lieferantenkomponente auf, die den Service speichert, verarbeitet, überträgt, sichert, überwacht oder unterstützt. Beziehen Sie kleinere Systeme wie Uptime-Monitoring, Ticket-Anhänge, Fehlerverfolgung, Support-Screen-Sharing-Werkzeuge und Diagnoseexporte ein.

Zweitens: Kennzeichnen Sie jede Datenkategorie. Wenn das Team sagt “nur Metadaten”, hinterfragen Sie die Annahme. Metadaten können weiterhin personenbezogene Daten oder vertrauliche Kundendaten sein.

Drittens: Verifizieren Sie die Region anhand von Nachweisen. Nutzen Sie Cloud-Konsolenkonfigurationen, Backup-Richtlinien, SIEM-Tenancy-Einstellungen, Anlagen zum Auftragsverarbeitungsvertrag, Listen von Unterauftragsverarbeitern, Vertragsbedingungen, Dokumentation zu Support-Zugriffen und CSP-Auditberichte. Verlassen Sie sich nicht nur auf Zusicherungen des Vertriebs.

Viertens: Erfassen Sie Lücken im ISMS-Risikoregister. Beispiele sind: “Backup-Replikationsregion vertraglich nicht beschränkt”, “Support-Zugriff aus Drittstaat ohne dokumentierten Genehmigungs-Workflow”, “SIEM-Protokolle werden global aufbewahrt”, “Liste der Unterauftragsverarbeiter identifiziert die Hosting-Region nicht” oder “DORA-Register unterscheidet Abhängigkeiten kritischer oder wichtiger Funktionen nicht”.

Fünftens: Legen Sie die Behandlung fest. Behandlungen können Vertragsänderung, Region Lock, Kundenbenachrichtigung, Verschlüsselung mit kundenseitig verwalteten Schlüsseln, Tokenisierung, Protokollminimierung, neue Lieferantengenehmigung, Aktualisierung der Exit-Strategie oder Restrisikoakzeptanz durch den Risikoverantwortlichen umfassen.

Sechstens: Bewahren Sie Nachweise auf. Auditoren werden nicht nur fragen, was Sie entschieden haben. Sie werden fragen, woher Sie wissen, dass es umgesetzt wurde.

Einen Nachweissatz auf ISO, GDPR, NIS2, DORA und NIST CSF 2.0 abbilden

Ein starkes Programm für die Governance von Cloud-Regionen vermeidet doppelte Compliance-Arbeit. Dieselben Nachweise können mehrere Verpflichtungen unterstützen, wenn sie richtig strukturiert sind.

NIST CSF 2.0 ist als integrierende Ebene nützlich. Seine GOVERN-Funktion passt zu gesetzlichen, regulatorischen, vertraglichen und datenschutzbezogenen Verpflichtungen, Risikobereitschaft, Rechenschaftspflicht, Richtlinien und Aufsicht. Die Kategorie GV.SC Lieferkette lässt sich gut auf DORA-Erwartungen an IKT-Drittparteien, NIS2-Anforderungen an die Lieferkette und ISO-Lieferantenkontrollen abbilden.

COBIT 2019 und eine ISACA-Auditperspektive prüfen häufig dieselben Fakten anhand von Governance-Zielen: Eigentum, Entscheidungsbefugnisse, Risikooptimierung, Lieferantenleistung, Nutzenrealisierung und Assurance. Ein Prüfer im COBIT-Stil beginnt möglicherweise nicht mit “Welche Cloud-Region ist konfiguriert?” Er beginnt vielleicht mit “Wer hat die Befugnis, eine Regionsänderung zu genehmigen, wie wird Risiko eskaliert, und woher weiß das Management, dass Cloud-Lieferanten innerhalb der Toleranz bleiben?”

Deshalb erfasst das Clarysec-Modell Verantwortliche, Genehmigungspunkte, vertragliche Nachweise und Managementberichte, nicht nur technische Einstellungen.

Auf die Fragen der Auditoren vorbereiten

Governance von Cloud-Regionen ist ein perfektes Beispiel dafür, wie unterschiedliche Auditoren dieselbe Kontrolle aus unterschiedlichen Blickwinkeln betrachten.

Ein ISO/IEC 27001:2022-Auditor wird mit Geltungsbereich, Anforderungen interessierter Parteien, Risikobeurteilung und Anwendbarkeitserklärung beginnen. Er wird fragen, ob gesetzliche, regulatorische und vertragliche Anforderungen identifiziert sind, ob Cloud- und Lieferantenkontrollen einbezogen wurden, ob Risiken bewertet wurden, ob Kontrollen umgesetzt sind und ob Nachweise aufbewahrt werden. Er kann einen Cloud-Service stichprobenartig auswählen und Onboarding-Prüfung, Vertragsklauseln, Regionskonfiguration, Überwachungsprüfung und Änderungsgenehmigung anfordern.

Eine Datenschutzaufsichtsbehörde oder ein GDPR-Prüfer wird sich auf personenbezogene Daten konzentrieren. Gefragt wird, welche personenbezogenen Daten verarbeitet werden, wo sie gespeichert sind, von wo aus darauf zugegriffen wird, welche Auftragsverarbeiter und Unterauftragsverarbeiter beteiligt sind, ob Übermittlungsmechanismen dokumentiert sind, ob ein Transfer Impact Assessment erforderlich ist und ob geeignete technische und organisatorische Maßnahmen bestehen. Protokolle, Support-Daten und Backups erhalten häufig Aufmerksamkeit, weil Organisationen sie unterschätzen.

Ein NIS2-Auditor oder eine zuständige Behörde wird sich auf Services im Geltungsbereich konzentrieren. Geprüft werden Management-Rechenschaftspflicht nach Article 20, Risikomanagementmaßnahmen nach Article 21, Kontinuität, Backup-Management, Disaster Recovery, Incident Handling, Sicherheit der Lieferkette, Zugriffskontrolle, Asset-Management und Wirksamkeitsbewertung.

Eine DORA-Aufsicht oder ein internes Auditteam wird nach IKT-Risiko-Governance, Aufsicht durch das Leitungsorgan, dem Informationsregister für IKT-Drittdienstleistervereinbarungen, Zuordnung kritischer oder wichtiger Funktionen, Konzentrationsrisiko, Untervergaberisiko, Datenverarbeitungsstandorten, Auditrechten, Unterstützung bei der Vorfallmeldung, Kontinuitätstests und Exit-Plänen suchen. DORA ist eindeutig: Auslagerung überträgt keine Rechenschaftspflicht.

Zenith Controls unterstützt Sicherheitsverantwortliche bei der Vorbereitung auf diese Auditstile, weil es Kontrollbeziehungen querverweist. Für ISO/IEC 27002:2022 Control 5.20, Behandlung der Informationssicherheit in Lieferantenvereinbarungen, verknüpft Zenith Controls diese mit 5.19 Lieferantenbeziehungen, 5.14 Informationsübertragung, 5.22 Lieferantenüberwachung, 5.11 Rückgabe von Vermögenswerten und 5.36 Einhaltung von Richtlinien, Regeln und Standards. Für Control 5.22, Überwachung, Überprüfung und Änderungsmanagement von Lieferantendiensten, verknüpft es die laufende Lieferantenaufsicht mit 5.29 Sicherheit bei Störungen, 8.8 Management technischer Schwachstellen, 5.15 Zugriffskontrolle, 8.27 sichere Systemarchitektur und Engineering-Grundsätze sowie 5.36 Einhaltung.

Diese kontrollübergreifende Sicht ist wichtig, weil eine Regionsänderung nie nur eine Regionsänderung ist. Sie kann Lieferantenrisiko, Übermittlungsrisiko, Zugriffsrisiko, Kontinuitätsrisiko, Nachweise für die Reaktion auf Informationssicherheitsvorfälle und vertragliche Einhaltung verändern.

Diese CISO-Checkliste 2026 vor Genehmigung einer Cloud-Änderung nutzen

Nutzen Sie diese Checkliste, bevor Sie eine neue Cloud-Region, einen grenzüberschreitenden Verarbeitungspfad, einen Backup-Standort, eine Protokollierungsplattform, ein Support-Modell oder eine kritische IKT-Lieferantenänderung genehmigen.

Wenn die Antwort auf eine Frage “wir nehmen an” lautet, ist die Kontrolle für regulierte Betriebsabläufe nicht reif genug.

Die Roadmap zur Mängelbehebung

Der Weg zur Mängelbehebung ist praktikabel, wenn er im ISMS verankert ist.

1. Bestätigen Sie, dass der ISMS-Geltungsbereich Cloud-Services, kritische IKT-Abhängigkeiten und regulierte Datenverarbeitung umfasst.
2. Erstellen Sie das Governance-Register für Cloud-Regionen für priorisierte Services.
3. Ordnen Sie jeden Service Datenkategorien, Regionen, Backup-Standorten, Support-Zugriffen und Unterauftragsverarbeitern zu.
4. Prüfen Sie Lieferantenvereinbarungen auf Klauseln zu Speicherort, Übermittlung, Audit, Vorfall, Untervergabe, Rückgabe und Vernichtung.
5. Aktualisieren Sie das Risikoregister für Lücken, Konzentrationsrisiken und nicht dokumentierte Übermittlungen.
6. Stimmen Sie, soweit anwendbar, das DORA-Informationsregister für IKT-Drittdienstleister und die NIS2-Kartierung von Serviceabhängigkeiten ab.
7. Validieren Sie die technische Durchsetzung, einschließlich Region Locks, Backup-Richtlinien, Protokollierungseinstellungen, Verschlüsselung, Zugriffskontrollen und Schlüsselmanagement.
8. Bereiten Sie ein Auditnachweispaket mit Screenshots, Verträgen, Risikodatensätzen, Genehmigungen, Überprüfungsprotokollen und Testergebnissen vor.
9. Etablieren Sie einen Änderungsauslöser für neue Regionen, Unterauftragsverarbeiter, Übermittlungsmechanismen oder kritische Änderungen an Lieferantendiensten.
10. Berichten Sie Risiken der Cloud-Residenz, Ausnahmen und Restrisikoentscheidungen an das Management.

Das ist keine theoretische Compliance. Es ist der Unterschied zwischen einer Cloud-Landschaft, die einer Auditprüfung standhält, und einer, die von mündlichen Zusicherungen abhängt.

Der Business Case: Souveränität, Resilienz und Vertrauen

Führungskräfte betrachten Governance der Datenresidenz manchmal als Einschränkung der Cloud-Agilität. In der Praxis verbessert reife Governance von Regionen die Agilität, weil Teams die Regeln kennen, bevor sie kaufen, bauen oder migrieren.

Ein Produktteam kann schneller starten, wenn genehmigte Regionen klar sind. Die Beschaffung kann schneller verhandeln, wenn verpflichtende Klauseln bereits definiert sind. Recht kann Übermittlungen schneller bewerten, wenn Datenflüsse dokumentiert sind. Security Operations kann schneller untersuchen, wenn Protokollspeicherorte und Zugriffsrechte bekannt sind. Das Leitungsorgan kann Risikoentscheidungen schneller treffen, wenn Konzentrationsrisiko, Auswirkungen auf die Kontinuität und Restrisikoakzeptanz sichtbar sind.

Für Kunden, insbesondere regulierte Kunden, wird dies zu einem Vertrauenssignal. Ein SaaS-Anbieter, der erklären kann, wo Daten gespeichert sind, wie Backups gesteuert werden, wie Support-Zugriff kontrolliert wird, wie Unterauftragsverarbeiter genehmigt werden und wie Regionsänderungen überprüft werden, wird einen Anbieter übertreffen, der nur sagt: “Wir nutzen einen führenden Cloud-Anbieter.”

Im Jahr 2026 ist diese Unterscheidung relevant. NIS2 hat Cybersicherheits-Governance zu wesentlichen und wichtigen Einrichtungen in der gesamten EU gebracht. DORA hat die IKT-Drittparteienaufsicht zu einer formalen Disziplin des Finanzsektors gemacht. GDPR-Rechenschaftspflicht bleibt zentral. ISO/IEC 27001:2022 stellt das Managementsystem bereit, das alles zusammenhält.

Nächste Schritte mit Clarysec

Wenn Ihre Organisation nicht beantworten kann, wo regulierte Daten und kritische IKT-Verarbeitung über Produktion, Backups, Protokolle, Support-Zugriffe und Unterauftragsverarbeiter hinweg stattfinden, ist jetzt der Zeitpunkt, die Lücke zu schließen.

Clarysec kann Sie beim Aufbau eines Nachweispakets für die Governance von Cloud-Regionen unterstützen, mit:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint für phasenweise ISO-Umsetzung und Auditbereitschaft.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls zur Abbildung von Cloud- und Lieferantenkontrollen nach ISO/IEC 27002:2022 auf operative Nachweise und kontrollrahmenübergreifende Erwartungen.
• Richtlinie zur Nutzung von Cloud-Diensten Richtlinie zur Nutzung von Cloud-Diensten und Richtlinie zur Nutzung von Cloud-Diensten - KMU Richtlinie zur Nutzung von Cloud-Diensten - KMU für Anforderungen an Cloud-Datenresidenz.
• Richtlinie zur Lieferanten- und Drittparteiensicherheit Richtlinie zur Lieferanten- und Drittparteiensicherheit und Richtlinie zur Lieferanten- und Drittparteiensicherheit - KMU Richtlinie zur Lieferanten- und Drittparteiensicherheit - KMU für Lieferantenverträge, Untervergabe und Zusicherungen zur geografischen Speicherung.
• Richtlinie zur Protokollierung und Überwachung - KMU Richtlinie zur Protokollierung und Überwachung - KMU für Protokollaufbewahrung und Anbieternachweise.
• Richtlinie zur rechtlichen und regulatorischen Einhaltung Richtlinie zur rechtlichen und regulatorischen Einhaltung für Auslöser zur Compliance-Überprüfung bei Übermittlungsmechanismen, Unterauftragsverarbeitern und grenzüberschreitenden Datenflüssen.

Beginnen Sie mit einem kritischen Service, einem Cloud-Anbieter und einem Register. Innerhalb weniger Workshops können Sie von Annahmen zu Nachweisen gelangen und von fragmentierter Compliance zu gesteuerter Cloud-Resilienz.

Laden Sie das Clarysec-Toolkit herunter, fordern Sie eine Demo an oder buchen Sie eine Bewertung der Governance von Cloud-Regionen, um Ihre Zusagen zur Cloud-Residenz in auditbereite Nachweise zu überführen.