Rollen im Rahmen der DSGVO

1) Grundlegende Definitionen und Prinzipien

Controller (Controller): Bestimmt selbstständig die Zwecke und Methoden der Verarbeitung personenbezogener Daten (PD). Trägt die Hauptverantwortung für die Rechtmäßigkeit, Transparenz, Rechte der Subjekte, Sicherheit-TOMs, Auswahl und Kontrolle der Verarbeiter.
Prozessor: verarbeitet PD nur nach dokumentierten Anweisungen des Controllers, stellt TOMs zur Verfügung, hilft bei den Rechten der Probanden und Vorfällen, führt Aufzeichnungen und ermöglicht Audits.
Gemeinsame Kontrolleure: Zwei + Personen definieren gemeinsam Ziele und Wege; eine transparente Aufgabenverteilung und eine Anlaufstelle für die Akteure gefordert werden.
Sub-Prozessor: vom Prozessor angezogener Anbieter; ist nur mit vorheriger schriftlicher Genehmigung des für die Verarbeitung Verantwortlichen und gleichwertigen Verpflichtungen zulässig.

Die goldene Regel: Wer entscheidet, warum und wie zu verarbeiten - das ist der Controller; wer nur „gemäß den Anweisungen ausführt“ - der Prozessor.

2) Wie man die Rolle in der Praxis definiert (Entscheidungsbaum)

1. Wer legt die Geschäftsziele für die Verarbeitung fest?

→ Sie? Eher ein Controller.

2. Können Sie Daten für Ihre Zwecke (Analytics, Marketing) wiederverwenden?

→ Ja → Controller (oder gemeinsame Kontrolle, wenn die Ziele geteilt werden).

3. Weisen Sie auf die genauen Mittel/Einschränkungen der anderen Partei hin, und Ihre Ziele sind abgeleitet?

→ Ja → Prozessor.

4. Gibt es ein gemeinsames Produkt/eine gemeinsame Plattform mit Zieldefinition durch beide Parteien?

→ Ja → joint controllers (brauchen Kunst. 26 arrangement).

5. Beziehen Sie die Cloud/den Anbieter für Ihren Auftrag mit ein?

→ Verkäufer - Subprozessor; Sie sind der Verantwortliche; Ihr Hauptverarbeiter ist verpflichtet, Ihre Erlaubnis dafür einzuholen.

3) Rollen im iGaming-Ökosystem - Beispielmatrix

4) Verantwortlichkeiten nach Rollen (RACI auf hohem Niveau)

5) Dokumente und Vereinbarungen

DPA (Data Processing Agreement): Ein für das Schema obligatorischer Controller → Prozessor.
Minimum: Thema/Kategorien PD, Ziele/Anweisungen, TOMs, Datenschutz, Hilfe bei DSAR/DPIA, Meldung von Vorfällen, Löschung/Rückgabe von Daten, Audit, Subprozessoren (Zustimmungsliste/Mechanismus).
Art. 26 Arrangement (Joint Controllers): transparente Aufgabenverteilung (Information, DSAR, Kontaktstelle), das Wesen der Rollen in der öffentlichen Politik.
SCCs/UK IDTA + DTIA: obligatorisch bei Übertragungen außerhalb des EWR/UK bei fehlender Angemessenheit.
RoPA: Register der Verarbeitungsvorgänge beim Verantwortlichen und beim Auftragsverarbeiter (eigener Satz).
Marketing-/SDK-Bedingungen: Verbot der Sekundärnutzung, klare Rollen und Ziele.

6) Kritische Bereiche und typische Fehler

1. Rollenmischung: Der „Auftragsverarbeiter“ verwendet die Daten für seine eigenen Zwecke → in Wirklichkeit ist es der Controller/Co-Controller.
2. Subprozessoren ohne Erlaubnis: Der Prozessor fügt einen Anbieter ohne Ihre Zustimmung hinzu.
3. DPA „leer“: Es gibt keine klaren Anweisungen für Retention/Delete/Incidents/Audit.
4. Intransparente Mitsteuerung: keine Kunst. 26 - Beschwerden und Strafrisiken.
5. Marketing SDKs: Anbieter ziehen PDs für sich - Sie sind für die Offenlegung und Rechtmäßigkeit verantwortlich.
6. PSP/Banken: Betrachten Sie sie als Prozessoren - ein Fehler; Meist sind es einzelne Controller.

7) DPA Mini-Vorlage (Fragmente der Formulierung)

Zweck und Art der Verarbeitung: „Der Auftragsverarbeiter verarbeitet PD ausschließlich zur KYC-Verifizierung auf Anweisung des Verantwortlichen“.
Anweisung: „Jede Änderung der Zwecke bedarf der schriftlichen Zustimmung des Verantwortlichen“.
Unterauftragsverarbeiter: "Der Auftragsverarbeiter nimmt keine Unterauftragsverarbeiter ohne vorherige schriftliche Genehmigung in Anspruch; ein aktuelles Register führt und veröffentlicht".
Sicherheit: „Der Prozessor unterstützt TOMs (Verschlüsselung, Pseudonymisierung, Zugangskontrolle, Protokollierung), die nicht niedriger als in Anhang A beschrieben sind“.
Vorfälle: „Der Auftragsverarbeiter benachrichtigt den Controller unverzüglich und stellt alle Informationen für die Benachrichtigung der Regulierungsbehörde und der Unternehmen zur Verfügung“.
Löschen/Zurückgeben: „Am Ende des Dienstes löscht/gibt der Prozessor die PD zurück und löscht die Kopien in den Backups planmäßig“.
Audit: „Der Controller ist berechtigt, Audits/Fragebögen/externe Berichte (SOC2/ISO) mit angemessener Benachrichtigung durchzuführen“.

8) DPIA/DTIA und grenzüberschreitende

DPIA: der Controller startet; Der Prozessor liefert Informationen über Systeme, Risiken und TOMs.
DTIA: SCCs/IDTA - Bewertung der Durchsetzungsumgebung des Empfängers, zusätzliche Maßnahmen (E2EE, Clientschlüssel, Quasi-Anonymisierung, Schlüsselspeicherung in EC/UK).

9) Umgang mit Betroffenenrechten (DSAR) in verteilten Rollen

Controller: nimmt die Anfrage an, verifiziert die Identität, koordiniert die Sammlung, antwortet innerhalb der Frist (in der Regel ≤30 Tage).
Prozessor: liefert prompt Uploads/löscht auf Anweisung, reagiert nicht direkt auf das Subjekt (sofern nicht anders vorgeschrieben).
Gemeinsame Kontrolleure: Geben Sie in der Vereinbarung den „Ansprechpartner“ und den Datenaustausch für die Antwort an.

10) Sicherheit und Vorfälle: Wer macht was

Controller: Incident Policy, DPA/User Notification Plan, CAPA Management.
Prozessor: sofortige Benachrichtigung des Controllers, technische Forensik, Inhalt, Protokolle, Hilfe bei Benachrichtigungen.
Gemeinsame Kontrolleure: harmonisierte Meldematrix; einheitliche Kommunikationslinie.

11) Retention, Löschung, Testdaten

Controller: legt Aufbewahrungsfristen für Zwecke/Gesetze (AML, Buchhaltung) fest, veröffentlicht in der Politik.
Prozessor: implementiert Löschung/Anonymisierung nach Zeitplan, separat - Reinigung von Backups; Verbot der Verwendung von PD in einer Testumgebung ohne Maskierung/Synthetik.

12) Betriebliche Integration (Praxis)

CAB/Change: jeder Rollen-/Unterprozessor-/Gebietswechsel - über CAB und DPA/SCCs-Bearbeitungen.
Data Map & RoPA: Live-Stream-Karte; der Verantwortliche hat Ziele und Empfänger, der Auftragsverarbeiter hat Kategorien und Vorgänge.
Vendor Management: Due Diligence vor dem Onboarding (ISO/SOC2, Pentest, Incident Policy, Datengeographie).
Audits: Checklisten, Fragebögen, selektive PII-Zugriffsprotokolle, Löschlogik.

13) Checkliste „Rolle definieren“

• Wer legt die Ziele und wichtigsten Verarbeitungsparameter fest?
• Kann PD für eigene Zwecke wiederverwendet werden?
• Hat die zweite Partei eine eigenständige Rechtsgrundlage?
• Wer ist dem Subjekt gegenüber verantwortlich (DSAR)?
• Braucht man eine DPA (Art. 28) oder Arrangement (Art. 26)?
• Gibt es Subprozessoren und einen Matching-Mechanismus?
• Wird es grenzüberschreitende Transfers geben und welcher Mechanismus (SCCs/IDTA)?

14) Häufig gestellte Fragen (FAQ)

PSP - Prozessor oder Controller?
In der Regel ein separater Controller: eigene Zwecke (Zahlungsdienste, Betrugsprävention, regulatorische Berichterstattung).

Kann der KYC-Anbieter ein Foto speichern, um die Models zu trainieren?
Nur mit dem Status eines Verantwortlichen (mit separater Grundlage und Offenlegung) oder mit Ihrer ausdrücklichen Zustimmung und korrekter Rechtsgrundlage. Ansonsten ist es verboten.

Der Affiliate, der den Spieler mitgebracht hat, ist der Prozessor?
Häufiger ein einzelner Controller: Er sammelt PD für seine eigenen Zwecke. Gemeinsame Kampagnen erfordern eine explizite Rollenverteilung.

Cloud-Server-Logging - wessen Daten?
Die Verarbeitung von Protokollen ist die Pflicht des Verarbeiters zur Gewährleistung der Sicherheit; Wiederverwendung für ihre Zwecke erfordert einen separaten Grund (sonst nicht möglich).

15) Mini-Rollenrichtlinie (Snippet für internen Standard)

1. Standardmäßig fungiert der Betreiber als Controller für alle PD-Ströme von Spielern/Partnern.
2. Jeder Anbieter mit Zugriff auf PD - wird als Prozessor (DPA) oder als separater Controller (für eigene Zwecke) ausgeführt.
3. Die Hinzufügung eines Unterauftragsverarbeiters bedarf der schriftlichen Zustimmung und Aktualisierung des Registers.
4. Jeder Rollen-/Gebiets-/Zielwechsel erfolgt über CAB, DPO und Legal.
5. DSAR und Incidents - koordiniert durch den Controller, die Prozessoren reagieren im SLA.

16) Fahrplan für die Umsetzung

Wochen 1-2: Inventar der Datenströme und Rollen; Entwurf der Matrix „Wer ist wer“; Aktualisierung von RoPA.
Woche 3-4: Abschluss/Update DPA, Art. 26 (soweit erforderlich), Register der Unterverarbeiter; Erstellung von Prüfungsfragebögen.
Monat 2: DTIA/SCCs/IDTA, Aktualisierung der öffentlichen Richtlinien, Teamschulung.
Monat 3 +: regelmäßige Lieferantenaudits, DSAR-Test, Vorfalltabletop, Rollenüberprüfung bei Produkt-/Marketingänderungen.

17) Kurzvorlage „Rollenmatrix“ (Beispiel)

TL; DR

Wir definieren die Rolle durch die Zwecke und Methoden der Verarbeitung: Sie entscheiden „warum/wie“ - der Controller; Sie führen auf Anweisung - Prozessor; gemeinsam entscheiden - joint controllers. Wir formalisieren das in DPA/Art. 26, führen RoPA, kontrollieren Unterauftragsverarbeiter, stellen DPIA/DTIA, Rechte von Themen und Sicherheit zur Verfügung. Klare Rollenmatrix = weniger regulatorische Risiken, weniger strittige Bereiche und schnellere Audits.