Markteintritt in Saudi-Arabien für den deutschen Mittelstand: was gilt, für wen, und warum die Antwort von der Konstellation abhängt und nicht vom Land

Problem in der Praxis

Der teuerste Fehler beim Markteintritt ist die Frage "Welche Norm gilt in Saudi-Arabien?". Sie verleitet dazu, ein Regelwerk zu suchen und den Rest für erledigt zu halten. Wer die ECC-2:2024 findet, liest "national verbindlich" und baut ein Programm gegen 108 Hauptcontrols, das er möglicherweise nicht braucht, während er die Datenschutzpflichten übersieht, die ihn tatsächlich treffen. Wer umgekehrt das PDPL für eine Kopie der DSGVO hält, übersieht die eigenständigen Regeln zur Übermittlung ins Ausland, zur Registrierung und zum Datenschutzbeauftragten.

Der zweite Fehler ist der Schluss vom fehlenden Sitz auf fehlende Pflichten. "Wir haben dort keine Gesellschaft" beantwortet beim PDPL nichts, weil Art. 2 Abs. 1 an den Wohnsitz der betroffenen Personen anknüpft. Beim CST-Regelwerk beantwortet es nur die Registrierungsfrage, nicht die Frage, ob das Regelwerk für einen Dienst an saudische Kunden gilt.

Der dritte Fehler betrifft Zulieferer. Ein deutsches Unternehmen, das selbst keiner saudischen Cybersicherheitspflicht unterliegt, unterschreibt einen Vertrag mit einer saudischen Behörde, einem CNI-Betreiber oder einer Bank und übernimmt damit Anforderungen, die es nicht geprüft hat: Standortvorgaben für Cybersecurity-Managed-Service-Zentren mit Fernzugriff, Cloud im Königreich, Zustimmungsvorbehalte der Aufsicht. Diese Anforderungen stehen in Regelwerken, deren Adressat der Kunde ist, und erscheinen erst im Vertragsentwurf.

CISO-Einordnung

Die Prüfreihenfolge. Für jede Einheit und jedes Geschäftsmodell vier Fragen in dieser Reihenfolge:

1. Verarbeiten wir personenbezogene Daten im Königreich oder Daten von Personen mit Wohnsitz im Königreich? Dann ist das PDPL zu prüfen.
2. Ist unser Kunde eine staatliche Stelle, eine mit ihr verbundene Gesellschaft oder ein Unternehmen, das CNI besitzt, betreibt oder hostet? Dann treffen uns die NCA-Controls, über den Vertrag oder, als Cloud-Anbieter dieses Kunden, unmittelbar. Und sind wir selbst eine mit einer staatlichen Stelle verbundene Gesellschaft, auch außerhalb des Königreichs? Dann gilt die ECC unmittelbar.
3. Erbringen wir Cloud-Dienste für Kunden mit Wohnsitz oder Adresse im Königreich? Dann gilt das CST-Regelwerk für diese Dienste. Unabhängig davon: Kontrollieren wir Rechenzentrum oder wesentliche Infrastruktur eines im Königreich gehosteten und genutzten Cloud-Systems? Dann besteht eine Registrierungspflicht. Und beziehen wir selbst Cloud-Dienste mit Wohnsitz oder Adresse im Königreich? Dann treffen uns die Kundenpflichten des CST-Regelwerks, etwa die Wahl der Datenklassifizierung. Werden Inhalte oder Daten eines Kunden ohne Wohnsitz oder Adresse im Königreich dort verarbeitet oder gespeichert, gelten nach Ziff. 3-1-2 nur einzelne, dort aufgezählte Vorschriften.
4. Ist unser Kunde ein von der SAMA beaufsichtigtes Institut oder ein Kapitalmarktinstitut unter Aufsicht der CMA? Dann kommen deren Anforderungen über den Vertrag, und für eigene beaufsichtigte Einheiten unmittelbar.

Anwendbarkeitsmatrix. Die Matrix ordnet sechs typische Konstellationen eines deutschen Mittelständlers den Regelwerken zu. "Gilt" heißt: das Regelwerk adressiert diese Konstellation nach seinem eigenen Geltungsbereich, vorbehaltlich der Tatbestandsprüfung im Einzelfall. "Über Vertrag" heißt: das Regelwerk adressiert den Kunden, der die Anforderungen weitergeben muss oder wird. "Nein" heißt: das Regelwerk adressiert diese Konstellation nicht.

Was die Zeilen tragen und wo sie enden. Zeile A ist die häufigste und die am meisten unterschätzte: der Export ohne Einheit. Hier greift aus dem saudischen Recht regelmäßig nur das PDPL, und auch das nur, wenn Daten von Personen mit Wohnsitz im Königreich verarbeitet werden. Zeile D ist die, in der Zulieferer überrascht werden: Die ECC-2:2024 verlangt von ihren Adressaten, Anforderungen an Dritte vertraglich durchzusetzen, und eine dieser Anforderungen ist der Standort von Cybersecurity-Managed-Service-Zentren für Überwachung und Betrieb mit Fernzugriff. Ein aus Deutschland betriebenes Security Operations Center passt dazu nicht. Zeile C zeigt den Weg, auf dem ein deutsches Unternehmen ohne eigene saudische Gesellschaft am häufigsten unmittelbar unter NCA-Controls fällt: als Cloud-Anbieter staatlicher Stellen oder von CNI-Betreibern, der nach CCC-2:2024 ECC und CCC einhalten muss, auch wenn er selbst nicht unter die ECC fällt. Daneben erfasst die ECC unmittelbar auch die mit staatlichen Stellen verbundenen Gesellschaften, und zwar innerhalb und außerhalb des Königreichs.

Zwei Begriffe lassen die Matrix offen, und das ist kein Mangel der Matrix, sondern der Quellen: Was eine "verbundene Gesellschaft" einer staatlichen Stelle ist, definieren die vorliegenden NCA-Texte nicht, und die Einstufung als CNI nimmt die NCA vor, deren Verfahren in den vorliegenden Quellen nicht beschrieben ist. Wer an einem Gemeinschaftsunternehmen mit einer staatlichen Stelle beteiligt ist oder Anlagen betreibt, die als CNI in Betracht kommen, klärt die Frage mit Kunde und Behörde, nicht mit der Matrix.

Datenschutz: was beim PDPL anders sitzt als in der DSGVO. Ausgangspunkt ist die Einwilligung; das Gesetz lässt andere Grundlagen nur in den Fällen zu, die es selbst nennt, darunter das berechtigte Interesse, das für sensible Daten nicht zur Verfügung steht und nach der Ausführungsverordnung eine vorab dokumentierte Abwägung verlangt. Der Datenschutzbeauftragte hängt an drei Fallgruppen (öffentliche Stelle mit Verarbeitung in großem Umfang, Kerntätigkeit mit regelmäßiger und systematischer Überwachung, Kerntätigkeit mit sensiblen Daten), nicht an einer Beschäftigtenzahl. Das nationale Register der Verantwortlichen betrifft nach den vorliegenden SDAIA-Regeln Verantwortliche im Königreich in vier Fällen; für Verantwortliche außerhalb des Königreichs kündigen die Regeln eigene Registrierungsregeln an, die dem Korpus nicht vorliegen. Einzelheiten stehen in saudi-arabien-004.

Daten nach Deutschland. Eine saudische Einheit, die Kunden- oder Beschäftigtendaten an die deutsche Zentrale übermittelt, folgt dieser Grundregel nach Art. 29 PDPL: ein zulässiger Zweck, zu dem nach der Übermittlungsverordnung auch notwendige zentrale Verarbeitungen zählen, und drei Bedingungen, nämlich keine Beeinträchtigung der nationalen Sicherheit oder lebenswichtiger Interessen des Königreichs, ein angemessenes Schutzniveau nach Bewertung der Behörde und Begrenzung auf das Minimum. Davon gibt es Ausnahmen: Nach Art. 29 Abs. 3 PDPL gelten die drei Bedingungen nicht in Fällen äußerster Notwendigkeit zum Schutz des Lebens oder lebenswichtiger Interessen der betroffenen Person oder zur Verhütung, Untersuchung oder Behandlung von Krankheiten; nach Art. 4 der Übermittlungsverordnung kann der Verantwortliche in bestimmten Fallgruppen von der Angemessenheit, vom Mindestumfang oder von beiden befreit sein, nie von der Sicherheitsbedingung, und zwar nur mit den dort genannten Garantien wie SDAIA-Standardvertragsklauseln, verbindlichen gemeinsamen Regeln oder einem zertifizierten Empfänger. Wo eine Übermittlung auf solche Garantien angewiesen ist, ersetzen EU-Standardvertragsklauseln das saudische Instrumentarium nicht. Ob Deutschland auf der Angemessenheitsliste der SDAIA steht, ist in den vorliegenden Quellen nicht belegt. Einzelheiten stehen in saudi-arabien-005.

Vorfälle. Der Verantwortliche meldet eine Datenpanne der SDAIA nach Art. 24 der Ausführungsverordnung binnen höchstens 72 Stunden ab Kenntnis, wenn sie die Daten oder Betroffenen schädigen oder deren Rechten oder Interessen zuwiderlaufen kann; Meldepflichten gegenüber der NCA bleiben unberührt. Ein Auftragsverarbeiter muss sich nach Art. 17 der Ausführungsverordnung vertraglich verpflichten, den Verantwortlichen ohne unangemessene Verzögerung zu benachrichtigen. Cloud-Anbieter melden Datenverletzungen nach dem CST-Regelwerk ohne unangemessene Verzögerung an CST und Kunden. Im Finanzsektor verlangen SAMA-Framework und CMA-Leitlinien eine sofortige Meldung bestimmter Vorfälle an die jeweilige Aufsicht. Wer in mehreren Konstellationen zugleich steht, hat mehrere Meldewege mit verschiedenen Auslösern. Einzelheiten stehen in saudi-arabien-006, saudi-arabien-003 und saudi-arabien-007.

Daten im Land. Ein allgemeines Lokalisierungsgebot enthält keines der vorliegenden Cloud-Regelwerke; die NCA hat Lokalisierungsvorgaben aus den Controls gestrichen und an das National Data Management Office (NDMO) der SDAIA verwiesen, dessen Vorgaben dem Korpus nicht vorliegen. Standortbindungen entstehen trotzdem an mehreren Stellen: Daten staatlicher Stellen dürfen nach dem CST-Regelwerk das Königreich grundsätzlich nicht verlassen, Cybersecurity-Managed-Service-Zentren für Überwachung und Betrieb mit Fernzugriff müssen für ECC-Adressaten im Königreich liegen, hybride oder öffentliche Cloud-Dienste von SAMA-Instituten sollen grundsätzlich in Saudi-Arabien liegen (interne Private Clouds sind von diesem Abschnitt ausgenommen), und die CMA-Leitlinien sehen nach ihrer englischen Fassung Cloud-Nutzung im Königreich vor. Wer einen Speicherort in Deutschland als Architekturprinzip anbietet, prüft je Kunde, ob eine dieser Bindungen greift.

Sprache und Verbindlichkeit. Alle hier ausgewerteten Texte sind englische Übersetzungen; verbindlich ist jeweils der arabische Text, wie die NCA-Dokumente, das CST-Regelwerk und die CMA-Leitlinien ausdrücklich sagen. Für vertragsrelevante Auslegungsfragen ist die arabische Fassung heranzuziehen.

Umsetzungsperspektive

1. Konstellationen je Einheit und je Geschäftsmodell erfassen. Nicht "Saudi-Arabien ja oder nein", sondern Zeilen A bis F der Matrix: Ein Unternehmen kann zugleich exportieren (A), eine Servicegesellschaft haben (B) und einen Cloud-Dienst anbieten (C).
2. PDPL zuerst, weil es fast immer greift. Datenflüsse mit Bezug zu Personen mit Wohnsitz im Königreich erheben, Rechtsgrundlagen saudisch begründen, Übermittlungen nach Deutschland nach Art. 29 und der Übermittlungsverordnung absichern, Meldeweg für die 72 Stunden einrichten.
3. Kundenprofil vor Vertragsunterzeichnung klären. Ist der Kunde staatlich, staatlich verbunden, CNI, SAMA- oder CMA-beaufsichtigt? Die Antwort bestimmt, welche Anforderungen im Vertrag auf Sie zukommen.
4. Standortbindungen früh in die Architektur. SOC-Betrieb, Cloud-Region, Fernwartung und Backup-Standort gegen die Bindungen aus ECC, CST-Regelwerk und Finanzaufsicht prüfen, bevor ein Angebot abgegeben wird.
5. Für Cloud-Angebote die CST-Frage stellen. Gilt das Regelwerk für den Dienst? Kontrollieren wir im Königreich Rechenzentrum oder wesentliche Infrastruktur und müssen uns registrieren? Bedienen wir staatliche oder CNI-Kunden und fallen damit unter ECC und CCC?
6. Arabische Fassungen beschaffen, wo Verträge daran hängen. Die englischen Texte dienen der Orientierung; Auslegungsstreit entscheidet der arabische Text.

Typische Fehler

1. Die ECC-2:2024 wird als Pflicht für jedes Unternehmen mit Saudi-Geschäft behandelt, obwohl sie unmittelbar nur staatliche Stellen samt verbundener Gesellschaften und CNI-Betreiber bindet.
2. Das PDPL wird verneint, weil keine saudische Gesellschaft besteht, obwohl Art. 2 Abs. 1 an den Wohnsitz der betroffenen Personen anknüpft.
3. Das PDPL wird als DSGVO-Kopie behandelt; Einwilligungslogik, Datenschutzbeauftragter, Register und Übermittlungsregeln werden nicht eigenständig geprüft.
4. Der Datenexport an die deutsche Zentrale wird mit EU-Standardvertragsklauseln abgesichert, obwohl das saudische Recht eigene Instrumente vorsieht.
5. Ein deutsches SOC wird einem ECC-verpflichteten Kunden angeboten, ohne die Standortanforderung für Cybersecurity-Managed-Service-Zentren mit Fernzugriff zu prüfen.
6. Für Cloud-Angebote wird nur die Registrierung geprüft und übersehen, dass das CST-Regelwerk auch ohne Registrierungspflicht für Dienste an Kunden im Königreich gilt.
7. Das abgelöste "Cloud Computing Regulatory Framework" wird zitiert statt des geltenden CST-Regelwerks.
8. Anforderungen der Finanzaufsicht werden erst im Vertragsentwurf entdeckt, obwohl der Zustimmungsvorbehalt der SAMA für Auslagerung und Cloud den Zeitplan bestimmt.

Risiken und Trade-offs

Eine zu weite Einordnung kostet Geld und Zeit: Ein ECC-Programm für ein Unternehmen, das nur exportiert, bindet Kapazität, die beim PDPL fehlt. Eine zu enge Einordnung ist das größere Risiko, weil sie sich erst zeigt, wenn ein Kunde den Vertrag vorlegt oder eine Datenpanne gemeldet werden muss. Das PDPL sieht für Verstöße Verwarnung oder Geldbuße bis fünf Millionen Riyal vor, bei Wiederholung bis zum Doppelten, und für die rechtswidrige Offenlegung oder Veröffentlichung sensibler Daten in der Absicht, die betroffene Person zu schädigen oder einen persönlichen Vorteil zu erlangen, Freiheitsstrafe bis zu zwei Jahren, Geldstrafe bis drei Millionen Riyal oder beides.

Zwischen Standortbindung und Konzernarchitektur besteht ein echter Zielkonflikt. Ein zentraler Betrieb in Deutschland ist günstiger und einheitlicher; saudische Kunden aus Staat, CNI und Finanzsektor verlangen über ihre Regelwerke häufig Betrieb oder Speicherung im Königreich. Die Entscheidung, ob man diese Kundengruppen mit einer saudischen Betriebsplattform bedient oder bewusst nicht bedient, ist eine Geschäftsentscheidung mit Sicherheitsfolgen und gehört auf die Leitungsebene.

Schließlich der Trade-off zwischen Selbsteinschätzung und Behördenklärung: Wo die Quellen offen sind, etwa bei verbundenen Gesellschaften, CNI-Einstufung oder Registrierung ausländischer Verantwortlicher, ist eine Anfrage bei der zuständigen Behörde belastbarer als jede interne Auslegung, legt aber das eigene Geschäftsmodell offen.

Entscheidungspunkte

• Welche Konstellationen der Matrix treffen auf unsere Einheiten und Geschäftsmodelle zu, und wer verantwortet die Einordnung?
• Bedienen wir saudische Kunden aus Staat, CNI oder Finanzsektor, und sind wir bereit, die damit verbundenen Standortbindungen zu erfüllen?
• Wie sichern wir Datenflüsse aus dem Königreich nach Deutschland nach saudischem Recht ab, und wer prüft den Stand der Angemessenheitsliste?
• Wer betreibt den Meldeweg für die 72-Stunden-Meldung an die SDAIA, und wie verzahnen wir ihn mit Meldungen an NCA, CST oder Finanzaufsicht?
• Holen wir für offene Einordnungsfragen eine Auskunft der zuständigen Behörde ein?

Praktische Empfehlungen

• Die Matrix als erste Seite des Markteintrittskonzepts führen, je Einheit eine Zeile, mit Datum und Grundlage der Einordnung.
• In Angebote an saudische Kunden eine Frage nach deren regulatorischem Profil (staatlich, CNI, SAMA, CMA) aufnehmen.
• Für das PDPL ein eigenes Verzeichnis und eigene Rechtsgrundlagen führen, nicht das DSGVO-Verzeichnis übersetzen.
• Für Cloud- und SOC-Angebote die Standortfrage vor dem Preis klären.
• Arabische Originalfassungen der für Verträge maßgeblichen Regelwerke beschaffen und Auslegungsfragen mit örtlicher Rechtsberatung klären.
• Die Einordnung bei jedem neuen Kunden aus Staat, CNI oder Finanzsektor und bei jeder neuen saudischen Einheit erneut prüfen.

Relevante Normreferenzen

• PDPL (Königliches Dekret M/19 vom 09.02.1443 AH, geändert durch M/148 vom 05.09.1444 AH): Art. 2 Abs. 1 (Geltungsbereich, Verarbeitung außerhalb des Königreichs), Art. 29 (Übermittlung ins Ausland), Art. 30 (Aufsicht), Art. 35 und 36 (Strafen und Geldbußen); Ausführungsverordnung Art. 24 (Meldung von Datenpannen), Art. 32 (Datenschutzbeauftragter); Regulation on Personal Data Transfer outside the Kingdom; SDAIA-Regeln zum nationalen Register der Verantwortlichen.
• NCA Essential Cybersecurity Controls ECC-2:2024: Scope of Work and Applicability; Control 4-1-3-2 (Cybersecurity-Managed-Service-Zentren für Überwachung und Betrieb mit Fernzugriff im Königreich).
• NCA Cloud Cybersecurity Controls CCC-2:2024: Scope of Work, Implementation and Compliance.
• CST Regulations for the Provision of Cloud Computing Services (RS10, vierte Fassung, Oktober 2023): Ziff. 3-1 (Geltungsbereich), 3-2 (Registrierung), 3-3 (Kundendaten und Standort).
• SAMA Cyber Security Framework (Rundschreiben 381000091275 vom 24.05.2017): Abschnitte 1.4 (Anwendbarkeit), 3.4 (Dritte, Auslagerung, Cloud).
• CMA Cybersecurity Guidelines for Capital Market Institutions: Abschnitte 2 (Geltung), 4.4 (Dritte und Cloud).
• Vertiefung in diesem Track: saudi-arabien-002 (NCA und ECC), saudi-arabien-003 (Cloud), saudi-arabien-004 bis 006 (PDPL), saudi-arabien-007 (Finanzsektor). Abgrenzung: DSGVO im dsgvo-Track, NIS-2 im nis2-Track, C5 im c5-Track, DORA im dora-Track; keine Gleichwertigkeitsaussage zwischen diesen Werken und den saudischen Regelwerken.