Residenz- und Souveränitäts-Gates

Residenz sagt, wo Daten und oft auch Admin-Metadaten liegen dürfen. Souveränität betrifft Entscheidungs- und Zugriffskontrolle über Jurisdiktionen hinweg. Hosting ohne Gates verschiebt das Risiko in den laufenden Betrieb.

Dieser Teil setzt Residenzklasse, getrennte Regionen und Transfer-Gates vor das Binding — auf den Admin-Grenzen aus Teil 2. Vertiefung: Serie Data Sovereignty, Einstieg Operating Model.

Vorher: Control Plane vs. Data Plane. Weiter: Exit- und Portabilitäts-Evidenz.

z sagt, wo Daten und oft auch Admin-Metadaten liegen dürfen. Souveränität betrifft Entscheidungs- und Zugriffskontrolle über Jurisdiktionen hinweg. Hosting ohne Gates verschiebt das Risiko in den laufenden Betrieb.

Lösung: Vor Binding einer Region oder eines Providers gelten eine Residenzklasse je Datenkategorie (Owner plus Legal/Steward), getrennte erlaubte Regionen für Data Plane und Control Plane, Transfer- und Support-Gates, Evidenz dass die Konfiguration den Gates entspricht, sowie ein Ausnahmeweg mit Freigeber und Ablauf.

In einem Satz: Kein Regions- oder Provider-Binding ohne Residenzklasse, getrennte Plane-Regionen und durchsetzbares Gate.

Entscheidung

Vor Binding einer Region oder eines Providers:

1. Residenzklasse je Datenkategorie (Owner + Legal/Steward);
2. erlaubte Regionen für Data Plane und Control Plane getrennt;
3. Transfer-/Support-Gates (wer darf remote administrieren);
4. Evidenz, dass Konfiguration den Gates entspricht;
5. Ausnahmeweg mit Freigeber und Ablauf.

Ein Catalog-Feld „EU“ ohne durchsetzbare Region-Policy ist kein Gate.

Workflow

1. Kategorien mappen

Der Data Owner und Legal/Steward vergeben Residenzklassen für PII, Zahlungsdaten, Betriebsgeheimnisse und öffentliche Analytics — nicht eine Klasse für alles. Artefakt ist die Kategorie-Map mit erlaubten Regionen. Der Steward hält die Map gegen reale Workloads. Wird der Schnitt übersprungen, wandert ein Pilot mit sensiblen Daten in dieselbe Region wie öffentliche Analytics, und „EU“ im Catalog bleibt Label.

2. Control Plane nicht vergessen

Logs, Tickets, Identity Provider und Backup-Indizes können außerhalb der Data-Region liegen. Der Platform Owner entscheidet Control-Plane-Residenz explizit; der Custodian dokumentiert den Standort. Teil 2 hat die Flächen getrennt — hier bekommt jede Fläche eine Region. Wird nur die Speicherplatte betrachtet, kann Admin-Metadaten den Residenz-Claim weiter brechen.

3. Gate vor Provisioning

Region, Encryption und Key-Custody werden geprüft, bevor Workloads entstehen — siehe Multi-Cloud-Grenzen in der Sovereignty-Serie. Der Steward hängt das Gate in den Change-Prozess; der Custodian blockiert Provisioning ohne erfüllte Checks. Ein Gate nach dem ersten sensiblen Workload ist zu spät: Drift ist dann Betrieb, nicht Entscheidung.

4. Laufende Drift-Kontrolle

Der Custodian meldet Regionsdrift (neue Buckets, Replica, Support-Region); der Steward eskaliert an den Owner. Artefakt ist der Drift-Report plus offene Ausnahmen mit Ablauf. Ohne laufende Kontrolle gilt die Provisioning-Entscheidung nur am ersten Tag, und ein vergessenes Replica verschiebt Residenz still.

5. Consumer-Zusage

Der Data Product Owner kommuniziert Residenzgrenzen an Consumer — nicht nur intern. Artefakt ist die Residenz-Zusage im Product Contract. Fehlt sie, verlassen sich Consumer auf ein unausgesprochenes Promise, und Exit- oder Audit-Fragen im nächsten Teil haben keine Consumer-Wahrheit zum Abgleich.

Handoffs

Anti-Patterns

• Nur Speichermedium betrachten, Admin-Metadaten ignorieren
• „Souveräne Cloud“ als Label ohne Gates
• Ausnahme ohne Ablauf für „Pilot in US-Region“
• Catalog-Zertifizierung statt Region-Richtlinie
• Sovereignty-Serie nicht anbinden und lokal neu erfinden

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Warehouse modernisieren
• Lernpfad — Warehouse modernisieren

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Drei Datenkategorien mit Residenzklasse versehen.
2. Control-Plane-Standort für eine Plattform dokumentieren.
3. Ein Provisioning-Gate in den Change-Prozess hängen.
4. Offene Regions-Ausnahmen mit Ablaufdatum versehen.