Privacy, Residenz und DSDR auf Argonos

z mit Privacy gleichsetzt, baut Controls, die in der Prüfung auseinanderfallen: Die Daten liegen in der EU, Support greift remote zu, Exporte landen im globalen Warehouse, und ein.

Lösung: Führe drei Spuren getrennt und weise sie getrennt nach.

In einem Satz: Führe drei Spuren getrennt und weise sie getrennt nach.

Problem

„Europäischer Hersteller“ und „On-Prem / souveräne Cloud“ werden oft als Privacy-Ergebnis verkauft. Sie sind Deployment- und Jurisdiktionsentscheidungen — keine automatische Erfüllung von Zweckbindung, Löschpflicht oder Auskunft. Wer Residenz mit Privacy gleichsetzt, baut Controls, die in der Prüfung auseinanderfallen: Die Daten liegen in der EU, Support greift remote zu, Exporte landen im globalen Warehouse, und ein Betroffenenbegehren stoppt an der Plattformgrenze.

Argonos als Decision-/Intelligence-Oberfläche verschärft das Muster. Personenbezogene und sensitive Merkmale fließen in Workspaces, Annotationen, Ableitungen und Freigaben. Die Oberfläche macht Nutzung produktiv — und multipliziert Pfade, auf denen Zweckbindung, Minimierung und Löschbarkeit enden können, ohne dass jemand den Product Path vollständig kennt.

Der dritte Fehler ist die Vermischung dreier Spuren in einem Foliennarrativ. Residenz sagt, wo und unter welchem Vertrag Daten liegen. Privacy sagt, welche Zwecke und Schutzmaßnahmen für personenbezogene Merkmale gelten. DSDR sagt, wie Auskunft, Korrektur, Löschung und Sperre über den gesamten Product Path wirksam werden. Eine Spur kann grün sein, während die anderen rot bleiben — und genau das fällt in Audits und Incident-Reviews auf.

Konzepte und Abgrenzung: PII & Privacy, DSDR, Host vs Cloud. Vorarbeit in der Serie: Zugriff und ABAC, Betriebsgrenze.

Entscheidung

Führe drei Spuren getrennt und weise sie getrennt nach:

1. Privacy Controls — Klassifikation, Zweck, Minimierung, Masking/Filter und Effective-Privacy-Tests in der Plattform.
2. Residenz & Vertrag — Region, Subprozessoren, Support- und Remote-Admin-Pfade, Escrow/Exit, dokumentierte Ausnahmen.
3. DSDR — Löschen, Sperren, Korrigieren, Auskunft über den gesamten Product Path inklusive Upstream und Downstream.

Argonos setzt um, was die Authority entscheidet — innerhalb der Plattformgrenze. Außerhalb braucht es Übergabe-Controls mit Owner. Souveränes Deployment ist Eingabe in Spur 2, nicht Ersatz für Spur 1 oder 3.

Der Pilot gilt nur, wenn alle drei Spuren für dasselbe Datenprodukt eine benannte Authority, einen Durchsetzung-Punkt und einen Nachweis besitzen. Fehlt eine Spur, ist der Pilot unvollständig — unabhängig davon, wie „EU-nah“ die Infrastruktur wirkt.

Scope und Abgrenzung

Scope-in sind personenbezogene und sensitive Merkmale im Pilotprodukt, ihre Klassifikation und Zweckbindung, die Residenz- und Supportmatrix der relevanten Dienste sowie DSDR-Pfade vom Source of Truth bis zu Exporten, Sandboxes und Analytics-Kopien.

Scope-in sind außerdem Legal Holds und dokumentierte Ausnahmen: Sie unterbrechen DSDR bewusst und müssen mit Owner, Begründung und Ablauf geführt werden — sonst werden sie zu stillen Dauerzuständen.

Scope-out sind allgemeine Datenschutzprogramme, Verarbeitungsverzeichnisse und DPIAs als Organisationsartefakte. Sie werden referenziert (System, Identifier, Owner), aber nicht in die Plattformkopie gezogen. Scope-out sind auch Controls außerhalb der Betriebsgrenze, solange kein Nachfolge-Control benannt ist — dann gilt der Pfad als Blind Spot, nicht als „automatisch mitgeregelt“.

Ausdrücklich nicht Ziel ist ein Privacy-Label auf dem Herstellerlogo. Die Aussage „europäisch / souverän“ ersetzt keine Feldklassifikation und keinen Löschlauf.

Rollen und Entscheidungsrechte

• Data Owner: bestätigt Zweck, zulässige Nutzung und akzeptiertes Restrisiko für personenbezogene Merkmale im Product Record.
• Privacy / Datenschutzbeauftragte-Funktion: ist autoritativ für Klassifikationsrahmen, Zweckbindung und Beurteilung von Residenz- und Transferfragen; konsumiert Plattformnachweise, ersetzt sie nicht.
• Data Steward: hält Kontext, Feldkatalog und Review-Vorbereitung aktuell; löst keine Legal-Hold- oder Ausnahmeentscheidungen allein.
• technischer Betreiber: setzt Masking, Filter, Zugriffssperren und technische Lösch-/Sperraktionen innerhalb der Plattform um.
• Plattform-/Dienstleister-Admin: betreibt Support- und Admin-Zugänge unter Vertrag und Zeitfenster; ist nicht Accountable für Business Purpose.
• Legal / Vereinbarung verantwortliche Person: verantwortet Residenzaussagen, Subprozessorlisten und Escrow-Hinweise gegenüber dem tatsächlichen Deployment.

Die häufigste Lücke ist die fehlende Trennung zwischen Custodian und Privacy Authority. Wer die Maskierung konfigurieren kann, entscheidet damit noch nicht über Zweck oder Löschpflicht.

Drei Spuren, ein Product Identifier

Jeder Nachweis trägt denselben stabilen Product Identifier wie in Verantwortung und Stewardship. Ohne diese Verknüpfung bleiben Residenzmatrix, Privacy-Test und DSDR-Lauf drei lose Dokumente.

Halte je Spur fest: Authority, Durchsetzung-Punkt, Evidenzquelle, Review-Cadence und bekannte Blind Spots. Blind Spots werden benannt, nicht beschönigt — etwa Exporte ohne Revocation-Test oder Supportzugriffe ohne Zeitfenster.

Privacy Controls in der Decision-Fläche

Privacy auf Argonos beginnt nicht mit einem UI-Tag. Sie beginnt mit owned Sensitivitätsklassen, Zweck je Product Record, erlaubten Consumern und Ableitungen sowie einem Test, der Wirkung zeigt: Analyst A sieht Feld X, Analyst B nicht — mit Audit, Identität, Zeitpunkt und Policy-/Rollenversion.

OSINT- und Fremddaten erhöhen das Risiko vor dem ersten Workspace. Herkunft, Rechtsgrundlage, Weitergabefähigkeit und Löschbarkeit müssen vor dem Ingest geklärt sein. Ein Ingest „zum Ausprobieren“ ohne diese Klärung erzeugt später Product Paths, die niemand mehr löschen kann, weil die Quelle selbst unklar ist.

Minimierung ist eine Betriebsentscheidung: Welche Attribute braucht der Decision Use Case wirklich? Welche Ableitungen dürfen PII weitertragen? Collaboration-Features — Teilen, Annotation, Export — sind Produktivität und Exfiltrationspfad zugleich; ihre Grenzen gehören zur Privacy-Spur, nicht nur zur Access-Story.

PII- und DSDR-Pillars aus dem Eight-Pillars-Modell bleiben Organisationspflichten. Die Plattform liefert Durchsetzung und Spuren; sie ersetzt weder den Privacy-Rahmen noch die Betroffenenprozess-Organisation. Wer Pillars nur „in Argonos“ abhaken will, verwechselt Werkzeug und Operating Model — siehe PII & Privacy und DSDR.

Residenz ohne Wunschdenken

Prüfe servicegenau, nicht plattformglobal:

• Speicherort der Nutzdaten und der Metadaten
• Telemetrie, Logging und Backup-Pfade
• Support- und Remote-Admin-Zugänge inklusive Hersteller und Partner
• Unterauftragnehmer und Subprozessoren mit Region und Zweck

Dokumentiere Ausnahmen schriftlich mit Owner und Ablauf. „Air-gapped“ ohne Prozess für Patches, Keys und Incident-Response ist ein Betriebsrisiko, kein Privacy-Automatismus. Hosting-Entscheidung und Governance-Fit: Host vs Cloud.

Residenznachweise müssen zum Nachweiszeitraum passen. Ein Vertrag von vor drei Jahren, der das heutige Deployment nicht mehr beschreibt, ist kein Nachweis — er ist eine offene Abweichung.

DSDR über die Plattformgrenze

Für jedes personenbezogene Product gilt die Pflicht über den gesamten Path, nicht nur innerhalb der Argonos-Oberfläche:

Wo die Plattform endet, endet der automatische Lauf — nicht die Pflicht. An der Grenze steht ein Nachfolge-Control mit Owner, sonst bleibt ein Blind Spot im Evidence Pack.

Legal Holds unterbrechen Löschung bewusst. Sie brauchen Identifier, Begründung, Owner, Reviewdatum und Aufhebungsbedingung. Ein Hold ohne Ablauf- oder Reviewmechanismus ist eine versteckte Ausnahme.

Häufige Anti-Muster

Souveränität als Privacy-Stempel

EU-nah oder On-Prem ersetzt keine Klassifikation, keinen Zweck und keinen Effective-Privacy-Test.

Residenzmatrix einmalig und vergessen

Deployment und Supportpfade ändern sich. Eine veraltete Matrix ist schlimmer als keine, weil sie Sicherheit vortäuscht.

DSDR nur in der Plattform-UI

Auskunft und Löschung, die Exporte und Warehouse-Kopien ignorieren, erfüllen die Pflicht nicht.

Maskierung ohne Zweckbindung

Technischer Schutz ohne owned Zweck erzeugt Scheinsicherheit und falsche Consumer-Erwartungen.

Legal Hold ohne Owner

Dauerhafte Sperren ohne Review werden zu undokumentierten Betriebsmodellen.

Fremddaten ohne Löschbarkeit

Ingest ohne geklärte Herkunft und Löschkette erzeugt Product Paths, die später nicht mehr geschlossen werden können.

Umsetzung in 45 Tagen

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 — Argonos Governance
• Lernpfad — Argonos Governance

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.

Schritt 1: Spuren und Scope trennen

Pilotprodukt wählen, Product Identifier festziehen, Privacy-, Residenz- und DSDR-Authorities benennen, Blind Spots listen.

Schritt 2: Privacy-Mindestset

Klassifikation und Zweck im Product Record, erlaubte Consumer, ein Effective-Privacy-Test (sichtbar/unsichtbar) mit Audit-Bezug.

Schritt 3: Residenz und Support

Servicegenaue Matrix für Speicher, Metadaten, Telemetrie, Support und Subprozessoren; Abweichungen als Ausnahme mit Ablauf.

Schritt: DSDR-Kette

Auskunfts-, Korrektur- und Lösch-/Sperrpfad inklusive Out-of-Platform-Nachfolge; Legal Holds registrieren.

Schritt: Stichprobe und Übergabe

Eine Betroffenenanfrage oder Löschsimulation end-to-end durchspielen, Lücken priorisieren, Pack-Eingaben für den nächsten Serienteil vorbereiten.

Messung

• Anteil der Pilotfelder mit owned Klassifikation und Zweck
• Anteil der Dienste mit aktueller Residenz-/Support-Aussage (nicht älter als Review-Cadence)
• Zeit bis zur Beantwortung einer Auskunftsanfrage für das Pilotprodukt
• Anteil der Auskunfts- und Löschrechte-Läufe mit dokumentierter Out-of-Platform-Kaskade
• Anzahl offener Blind Spots ohne verantwortliche Person
• Anteil der Privacy-Tests mit Identity, Zeitpunkt und Richtlinie-/Rollenversion
• Alter und Reviewstatus aktiver Legal Holds und Residenz-Ausnahmen

Checkliste

• Privacy, Residenz und Auskunfts- und Löschrechte sind als getrennte Spuren mit Authority geführt.
• Product Identifier verknüpft alle drei Spuren.
• Klassifikation und Zweck je Pilotprodukt sind owned, nicht nur getaggt.
• Effective-Privacy-Test (sichtbar/unsichtbar) ist dokumentiert und auditbezogen.
• Residenzmatrix ist servicegenau und reviewfähig.
• Support- und Remote-Admin-Pfade sind vertraglich und zeitlich begrenzt.
• Subprozessoren und Telemetriepfade sind erfasst oder als Ausnahme geführt.
• Auskunfts- und Löschrechte-Kette umfasst Upstream, Argonos und Downstream-Kopien.
• Out-of-Platform-Pfade haben Nachfolge-Kontrollregeln mit verantwortliche Person.
• Legal Holds haben verantwortliche Person, Begründung und Reviewdatum.
• Fremd-/OSINT-Ingest hat geklärte Herkunft und Löschbarkeit.
• Blind Spots sind benannt und priorisiert.
• Eine Stichprobe (Auskunft oder Löschen/Sperren) wurde durchgespielt.
• Hosting-Entscheidung ist von Privacy- und Auskunfts- und Löschrechte-Nachweis getrennt dokumentiert.

Artefakt

Das Ergebnis ist eine Privacy–Residenz–DSDR-Karte je Pilotprodukt. Sie hält je Spur Authority, Durchsetzung, Evidenz, Review-Cadence und Blind Spots fest und verweist auf Product Record, Residenzmatrix und DSDR-Pfadregister.

Ergänzt wird sie durch das Protokoll des Effective-Privacy-Tests und durch das Register aktiver Legal Holds und Residenz-Ausnahmen. Diese drei Teile beantworten die Prüffrage: Was war Deployment, was war Privacy-Control, und was war Betroffenenrecht — ohne Vermischung.

Die Karte wird versioniert. Material Changes an Deployment, Zweck oder Exportpfaden erzeugen eine neue Version und lösen den Privacy-Test sowie die DSDR-Stichprobe erneut aus.

Werkzeuge und Referenzen

• personenbezogene Daten/Auskunfts- und Löschrechte Readiness Checker
• Authority Matrix Builder
• Access Recertification Checklist
• personenbezogene Daten & Privacy Governance
• Auskunfts- und Löschrechte Governance
• Host vs Cloud
• Zugriff und ABAC auf Argonos
• Argonos als Betriebsgrenze
• Glossary: personenbezogene Daten, Data Subject Rights, Data Residency