rebreak-monorepo/backend/docs/mail-outlook-oauth-dsgvo-review.md

Datenschutz-Memo: Microsoft als Sub-Auftragsverarbeiter (Outlook-IMAP-OAuth)

An: Chahine Brini (Geschäftsführung, Rebreak) Von: Hans Müller, externer Datenschutzbeauftragter Datum: 2026-05-13 Betreff: DSGVO-Review Outlook-IMAP-OAuth-Integration (Mail-Auto-Delete-Feature) Klassifikation: Internes Compliance-Memo, kein Rechtsrat

---

1. Gesamteinschätzung (Executive Summary)

Risiko-Klasse: Mittel — vorausgesetzt, die unten genannten Pflichten werden vor Live-Schaltung erledigt.

• Die OAuth2-Integration ist datenschutzrechtlich günstiger als die bisherige App-Passwort-Lösung (granular widerrufbare Scopes, Token-Rotation, kein Klartext-Credential bei Rebreak).
• Microsoft ist als Auftragsverarbeiter für Exchange Online seit Februar 2025 vollständig im EU Data Boundary — der Drittland-Transfer ist damit deutlich entschärft, aber nicht vollständig eliminiert (Support-Zugriffe, Telemetrie, Identity-Platform-Subsysteme können noch US-Routing enthalten).
• Microsofts Standard-DPA (Stand September 2025) erfüllt die Art. 28-Anforderungen formal — eine eigenständige Vertragsunterzeichnung ist für Consumer-/Free-Tier-OAuth in der Regel nicht möglich; die DPA gilt qua Akzeptanz der Microsoft Services Agreement bzw. App-Registration-Bedingungen. Dies sollten Sie einmal anwaltlich verifizieren lassen, da Rebreak hier als „Partner" und nicht als zahlender M365-Tenant agiert.
• Kein Blocker für Go-Live, aber Pflicht-Aufgaben (VVT, Datenschutzerklärung, User-Einwilligungstext, vollständige DB-seitige Token-Löschung + User-Information zum manuellen Entfernen unter account.microsoft.com, siehe Section 5.1) vor Aktivierung.

---

2. Sub-Auftragsverarbeiter-Konstellation (Art. 28 DSGVO)

2.1 Rolle von Microsoft

Datenfluss	Rolle Microsoft	Rolle Rebreak
User loggt sich bei login.microsoftonline.com ein (Browser → MS)	Verantwortlicher für das Microsoft-Konto des Users (eigene Privacy-Policy)	nicht beteiligt
MS gibt auth_code an Rebreak-Backend zurück	Verantwortlicher (User → MS, MS-Datenschutzerklärung)	wird hier zum Empfänger
Token-Storage + IMAP-Calls Rebreak → outlook.office365.com mit XOAUTH2	Auftragsverarbeiter (verarbeitet Mailbox-Inhalt im Auftrag Rebreaks)	Verantwortlicher
Rebreak liest/löscht Glücksspiel-Mails	reine Speicher-/Übermittlungsfunktion	Verantwortlicher mit Art. 9-Daten-Verarbeitung

Konsequenz: Microsoft ist im Sinne des Mail-Auto-Delete-Features ein Auftragsverarbeiter Rebreaks (Art. 28) — aber nur für die IMAP-/Postfach-Verarbeitung. Der OAuth-Identity-Vorgang selbst ist ein eigenverantwortliches Microsoft-Geschäft gegenüber dem Endnutzer.

2.2 Rechtsgrundlage für die Sub-AV-Beauftragung

Microsofts „Products and Services Data Protection Addendum (DPA)" in der Version September 2025 erfüllt die Mindestanforderungen aus Art. 28 Abs. 3 DSGVO formal.

Wichtige Einschränkung — anwaltliche Klärung empfohlen: Die DPA bindet Microsoft typischerweise nur gegenüber lizenzierten Customers (M365-Tenants). Für eine reine OAuth-App-Registration ohne kommerzielle MS-Lizenz greifen die Microsoft Services Agreement sowie die API Terms of Use. Hier ist nicht trivial, ob Rebreak einen DPA-Anspruch für die IMAP-Verarbeitung der Consumer-Postfächer der Endnutzer hat.

→ Empfehlung: Diese spezifische Konstellation („Anti-Sucht-App liest fremde Consumer-Postfächer via OAuth") anwaltlich prüfen lassen (1-2 Stunden Aufwand).

2.3 Drittland-Transfer (Kapitel V DSGVO)

Gute Nachricht: Microsoft hat das EU Data Boundary im Februar 2025 abgeschlossen. Exchange Online (und damit outlook.office365.com) speichert und verarbeitet Kunden- und pseudonymisierte personenbezogene Daten innerhalb der EU/EFTA.

Verbleibende Drittland-Aspekte:

• Microsoft Identity Platform (login.microsoftonline.com) ist eine globale Identitäts-Infrastruktur. Token-Refresh-Calls können je nach geografischer Routing-Policy auch US-Endpoints erreichen.
• Support-/Engineering-Zugriffe durch nicht-EU-Personal sind durch das im November 2025 eingeführte Data Guardian-Programm zwar EU-überwacht, aber nicht ausgeschlossen.
• Telemetrie/Diagnostik kann residuale US-Übermittlungen enthalten.

Konsequenz:

• EU-Standardvertragsklauseln (SCC) 2021/914 als Anhang zur DPA — Modul 2/3.
• EU-US Data Privacy Framework (DPF), Microsoft ist gelistet.
• Ein eigenständiges Transfer-Impact-Assessment (TIA) ist erforderlich, aber leicht erstellbar.

→ Empfehlung TIA: 2-3 Seiten, Template nach EDSA Recommendations 01/2020.

---

3. Verarbeitungsverzeichnis (Art. 30 DSGVO)

3.1 Neue VVT-Zeile „Outlook-Mail-Anbindung via OAuth2"

Feld	Inhalt
Bezeichnung	Outlook-IMAP-Anbindung via Microsoft Identity Platform (OAuth2)
Zweck	Erkennung und Löschung von Glücksspiel-Werbemails im Nutzer-Postfach (Sucht-Trigger-Minimierung)
Rechtsgrundlage	Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung) i.V.m. Art. 9 Abs. 2 lit. a DSGVO (ausdrückliche Einwilligung) — Wechsel auf Art. 9 Abs. 2 lit. h bei DiGA-Listung
Betroffene Personen	Registrierte Rebreak-Nutzer mit Microsoft-Consumer-Postfach (outlook.com, hotmail.com, live.com, msn.com)
Datenkategorien (Art. 6)	E-Mail-Adresse des Microsoft-Kontos, Display-Name des Microsoft-Kontos, OAuth-Access-Token, OAuth-Refresh-Token, Token-Ablaufdatum, technische Verbindungs-Metadaten (IMAP-Session-Logs)
Datenkategorien (Art. 9)	Indirekt: Verbindung „MS-Account-Inhaber X nutzt Anti-Glücksspiel-App" → Rückschluss auf Suchterkrankung möglich (siehe Abschnitt 6)
Empfänger / Sub-AV	Microsoft Ireland Operations Ltd., One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, Irland
Drittland-Transfer	Primär EU (EU Data Boundary, Exchange Online), residuale Transfers in USA für Identity-Platform/Support (SCCs 2021/914 + EU-US DPF)
Speicherdauer	Tokens: bis User-Disconnect oder 90 Tage Inaktivität (refresh-token-TTL); Verbindungs-Logs: 30 Tage rolling
TOMs	AES-256-Encryption-at-rest für Tokens, TLS 1.2+ in Transit, Zugriff auf Token-Tabelle nur durch Backend-Service-Account, Hetzner DE Hosting
Löschkonzept	Bei User-Disconnect oder Account-Löschung: vollständige Löschung aller Token-/Profil-Daten aus der Rebreak-DB. Microsoft stellt keinen Drittanbieter-Token-Revoke-Endpoint bereit (siehe Section 5.1) — daher zusätzlich User-Information mit Anleitung zum manuellen Entfernen unter account.microsoft.com → Sicherheit → Berechtigungen für Apps.

3.2 Sub-AV-Liste aktualisieren

Ja, Microsoft muss als Sub-AV ergänzt werden. Aktuelle Sub-AV-Liste sollte umfassen:

1. Hetzner Online GmbH (DE) — Hosting
2. Groq Inc. (USA) — Lyra-LLM-Inferenz
3. Stripe Payments Europe Ltd. (IE) / Stripe Inc. (USA) — Zahlungsabwicklung
4. Cloudflare Germany GmbH / Cloudflare Inc. (USA) — DNS/CDN
5. NEU: Microsoft Ireland Operations Ltd. (IE) — IMAP-Postfach-Verarbeitung bei Outlook-Mail-Anbindung
6. ggf. weitere Mail-Provider (Google, Apple, GMX, Yahoo) — hier bitte prüfen, ob diese ebenfalls noch nicht im VVT/Sub-AV-Liste stehen

→ Wichtiger Hinweis: Bei den anderen IMAP-Providern (Gmail, iCloud) stellt sich dieselbe Frage wie bei MS. Diese Inkonsistenz im aktuellen VVT sollte mit dieser Gelegenheit mit aufgeräumt werden.

---

4. Datenschutzerklärung — Update-Pflicht (Art. 13 DSGVO)

4.1 Neuer Textbaustein (Vorschlag, anwaltlich final reviewen lassen)

Verbindung mit Microsoft Outlook (consumer)

Wenn Sie Ihr persönliches Microsoft-Postfach (outlook.com, hotmail.com, live.com, msn.com) mit Rebreak verbinden, nutzen wir das standardisierte OAuth2-Verfahren der Microsoft Identity Platform. Sie loggen sich dabei direkt bei Microsoft ein — Ihre Zugangsdaten erreichen Rebreak zu keinem Zeitpunkt.

Nach erfolgreichem Login speichern wir verschlüsselt:

• einen Access-Token (Lebensdauer ca. 1 Stunde),
• einen Refresh-Token (Lebensdauer bis zu 90 Tage, ohne Nutzung).

Diese Tokens berechtigen Rebreak ausschließlich zu folgenden Zugriffen (OAuth-Scopes, nach Prinzip der Datenminimierung):

• IMAP.AccessAsUser.All (Lese-/Lösch-Zugriff auf Ihre E-Mail-Inbox)
• offline_access (technischer Refresh-Token-Bezug)
• openid (OAuth-Mindesthygiene)
• User.Read (Anzeige Ihres Namens in der Rebreak-App nach Verbindungs-Aufbau)

Aus Ihrem Microsoft-Konto-Profil lesen wir ausschließlich Ihren angezeigten Namen und Ihre E-Mail-Adresse (Scope User.Read), um eine freundliche Anzeige der verbundenen Verbindung in der App zu ermöglichen („Verbunden als …"). Keine weiteren Profil-Daten wie Kontakte, Kalender, Fotos, Telefonnummer, Job-Titel oder Manager-Informationen werden gelesen — auch wenn der Scope User.Read dies technisch erlauben würde. Wir wenden hier das Prinzip der Datenminimierung (Art. 5 Abs. 1 lit. c DSGVO) durch eine technische Selbstbeschränkung im Client-Code an.

Sub-Auftragsverarbeiter ist Microsoft Ireland Operations Ltd. (Dublin, Irland). Die Postfach-Verarbeitung erfolgt innerhalb des Microsoft EU Data Boundary (EU/EFTA). In Einzelfällen (Identity-Platform, Support) können Restdaten in die USA übermittelt werden — abgesichert durch die EU-Standardvertragsklauseln (Modul 2/3) und das EU-US Data Privacy Framework.

Sie können diese Verbindung jederzeit in den Rebreak-Einstellungen trennen. Wir löschen in diesem Fall alle bei uns gespeicherten Tokens und Profil-Daten vollständig aus unserer Datenbank. Microsoft stellt Drittanbieter-Apps technisch keinen Token-Widerruf-Endpoint zur Verfügung — für eine vollständige Entfernung der Rebreak-Berechtigung in Ihrem Microsoft-Konto empfehlen wir Ihnen daher, zusätzlich unter account.microsoft.com → Sicherheit → Berechtigungen für Apps die App „Rebreak" zu entfernen. Wir blenden Ihnen direkt nach dem Trennen in der App eine Schritt-für-Schritt-Anleitung dazu ein.

4.2 Unterschied „OAuth-Token-Storage vs App-Passwort-Storage"

Bei den Anbietern, die wir per App-Passwort anbinden (z.B. GMX, Yahoo, ggf. iCloud), speichern wir ein vom Nutzer im Anbieter-Account erzeugtes Anwendungs-Passwort verschlüsselt in unserer Datenbank. Bei den Anbietern mit OAuth2-Verfahren (Google, Microsoft Outlook) speichern wir stattdessen die zeitlich begrenzten OAuth-Tokens. OAuth ist hierbei das aus Datenschutzsicht vorzugswürdige Verfahren, da die Berechtigungen feiner granuliert, jederzeit per Mausklick im Anbieter-Account widerrufbar und automatisch nach Inaktivität ablaufend sind.

---

5. Betroffenenrechte

5.1 Recht auf Löschung (Art. 17)

Technische Einschränkung — Microsoft stellt keinen Drittanbieter-Revoke bereit:

Bei der Implementierung des Disconnect-Flows hat sich bestätigt: Die Microsoft Identity Platform unterstützt keinen RFC-7009-konformen revoke_token-Endpoint für Drittanbieter-Apps. Der einzige technisch verfügbare Pfad /oauth2/v2.0/logout beendet lediglich eine User-Browser-Session, invalidiert aber den Refresh-Token nicht (Microsoft Q&A: Identity Platform OAuth2 Revoke Access, Microsoft Q&A: How to revoke OAuth refresh token?).

Refresh-Tokens werden serverseitig bei Microsoft nur in den folgenden Fällen invalidiert:

1. Der User ändert sein Microsoft-Passwort.
2. Der User entfernt die Rebreak-App manuell unter account.microsoft.com → Sicherheit → Berechtigungen für Apps.
3. Die revokeSignInSessions-Graph-API wird vom User selbst aufgerufen (invalidiert dann alle Refresh-Tokens des Users, nicht nur Rebreak — daher kein geeigneter Anwendungs-Initiierungs-Pfad).
4. Ablauf der Token-Lebenszeit (90 Tage Inaktivität).

Bewertung im Lichte von Art. 17 DSGVO:

Microsofts OAuth-Plattform unterstützt keinen serverseitigen Token-Widerruf durch Drittanbieter-Apps. Rebreak löscht die gespeicherten Tokens beim User-Disconnect aus der eigenen Datenbank vollständig. Die User-Information enthält den expliziten Hinweis, dass für eine vollständige Trennung die Rebreak-App auch in den Microsoft-Konto-Einstellungen (account.microsoft.com → Sicherheit → Berechtigungen für Apps) entfernt werden sollte. Damit ist die Datenminimierungs-Pflicht aus Art. 17 in dem Umfang erfüllt, in dem Microsoft als Identity Provider technische Mittel zur Verfügung stellt.

→ Spec für rebreak-backend + rebreak-native: Beim Disconnect/Delete-Flow:

1. DB-seitig: Access-Token, Refresh-Token, Token-Ablaufdatum, Display-Name und gespeicherte E-Mail-Adresse des MS-Kontos vollständig aus der Datenbank entfernen (keine Soft-Delete-Flags auf Token-Spalten).
2. Audit-Log: Eintrag „mail_connection deleted: provider=microsoft, user_id=…, timestamp=…" — ohne Token-Inhalt.
3. User-Information (in-app, sofort nach Disconnect-Bestätigung): Hinweis-Screen mit Schritt-für-Schritt-Anleitung:

   „Wir haben Ihre Outlook-Verbindung in Rebreak vollständig gelöscht. Microsoft selbst behält den Zugriffs-Token jedoch bis zur nächsten Inaktivitäts-Phase (max. 90 Tage). Für eine vollständige sofortige Trennung öffnen Sie bitte account.microsoft.com → Sicherheit → „App-Berechtigungen verwalten" → wählen Sie „Rebreak" → „Diese App entfernen".

4. Best-effort Logout-Call: Optionaler Call an /oauth2/v2.0/logout ist möglich, hat aber keinen Token-revoking Effekt — daher nicht als Compliance-Maßnahme dokumentieren.

Offene Anwalts-Frage (siehe Section 9): Ob die User-Information als alleinige Maßnahme genügt, oder ob zusätzlich z. B. eine E-Mail-Erinnerung nach X Tagen versendet werden sollte.

5.2 Auskunftspflicht (Art. 15)

Im Datenexport-Endpoint muss enthalten sein:

• Für jede aktive Mail-Verbindung: Provider (Outlook), verbundene E-Mail-Adresse, Verbindungs-Zeitpunkt, die erteilten OAuth-Scopes (als lesbare Liste, nicht die kryptischen Scope-Strings), Token-Ablaufdatum.
• NICHT den Token-Inhalt selbst.

---

6. Art. 9 DSGVO — Besondere Kategorie (Suchterkrankung)

6.1 Der „Outing-Effekt" gegenüber Microsoft

Wenn ein User im OAuth-Consent-Screen liest „Rebreak (Anti-Glücksspiel-App) möchte auf Ihr Postfach zugreifen", erfährt Microsoft mittelbar, dass dieser MS-Account-Inhaber eine Anti-Sucht-App nutzt.

Bewertung: Keine Verarbeitung im Sinne von Art. 9 Abs. 1 durch Microsoft, weil MS keinen inhaltlichen Bezug herstellt. ABER: für den User ist die Sichtbarkeit relevant.

→ Empfehlung — User-Information vor Consent:

Hinweis: Microsoft zeigt Ihnen im nächsten Schritt einen Berechtigungsdialog. Der App-Name „Rebreak" erscheint dort und wird in Ihrer Microsoft-Konto-Übersicht unter „App-Berechtigungen" sichtbar. Falls Ihr Microsoft-Konto von anderen Personen mitgenutzt wird, sollten Sie das berücksichtigen.

6.2 Rechtsgrundlage Art. 9 Abs. 2

Status quo (vor DiGA-Listung) — Empfehlung: Art. 9 Abs. 2 lit. a (ausdrückliche Einwilligung)

→ Praxis-Frage: Wird die Art. 9-Einwilligung schon explizit für Gmail/iCloud/GMX-Connections eingeholt? Wenn nein, ist das ein bestehender Compliance-Gap.

Vorschlag Consent-Text (anwaltlich review):

Mit der Verbindung meines E-Mail-Postfachs willige ich ausdrücklich ein, dass Rebreak in meinem Postfach gezielt nach Glücksspiel-Werbemails sucht und diese löscht. Mir ist bewusst, dass aus dieser Verarbeitung Rückschlüsse auf eine Suchterkrankung möglich sind, und ich willige in diese Verarbeitung von Gesundheitsdaten gem. Art. 9 Abs. 2 lit. a DSGVO ausdrücklich ein. Diese Einwilligung kann ich jederzeit für die Zukunft widerrufen, indem ich die Mail-Verbindung in den Einstellungen trenne.

Zukunft (bei DiGA-Listung) — Wechsel auf Art. 9 Abs. 2 lit. h DSGVO.

---

7. DiGA-Aspekte

Kurzantwort: Microsoft als zusätzlicher Sub-AV macht den BfArM-Antrag marginal komplexer, nicht qualitativ anders.

• Microsoft ist datenschutzrechtlich „besser dokumentiert" als Groq und Stripe.
• ISO 27001, ISO 27018, BSI-C5-zertifiziert für Exchange Online (Microsoft Trust Center).
• DPA + DPF + EU Data Boundary erfüllen die „Stand der Technik"-Anforderung für einen Sub-AV.

→ Aktion: Microsoft als Sub-AV in das spätere DiGA-Datenschutz-Konzept-Dokument aufnehmen.

---

8. Konkrete To-Do-Liste, priorisiert

#	Aktion	Owner	Frist	Blocker für Outlook-Go-Live?
1	VVT-Zeile „Outlook-IMAP via MS Identity Platform" ergänzen	Brini (DSB-Vorlage liefere ich)	vor Go-Live	Ja
2	Sub-AV-Liste in Datenschutzerklärung um Microsoft Ireland erweitern	Brini + Anwalt-Review	vor Go-Live	Ja
3	Datenschutzerklärungs-Textbaustein „Outlook-Anbindung" + „OAuth vs App-Passwort" einfügen	Brini + Anwalt-Review	vor Go-Live	Ja
4	Art. 9-Einwilligungs-Flow im Mail-Connect-Onboarding implementieren (sofern noch nicht für andere Provider vorhanden)	rebreak-native + rebreak-backend	vor Go-Live	Ja
5	Vollständige DB-seitige Löschung aller MS-Token-/Profil-Daten bei Disconnect + Account-Löschung (kein Soft-Delete)	rebreak-backend	vor Go-Live	Ja
6	User-Information-Screen bei Disconnect mit Schritt-für-Schritt-Anleitung zum manuellen Entfernen unter account.microsoft.com (siehe Section 5.1)	rebreak-native + rebreak-backend	vor Go-Live	Ja
7	Datenexport-Endpoint (Art. 15) um mail_connections-Block (inkl. Display-Name + erteilte Scopes) ergänzen, falls nicht vorhanden	rebreak-backend	binnen 30 Tagen nach Go-Live	Nein
8	TIA (Transfer Impact Assessment, 2-3 Seiten) für MS-Sub-AV erstellen	DSB-Draft, Brini-Freigabe	binnen 30 Tagen nach Go-Live	Nein (aber dringend)
9	Anwaltliche Klärung „greift MS-DPA bei reiner OAuth-App-Registration?"	Anwalt	binnen 60 Tagen	Nein, aber Risiko-Minderung
10	Anwaltliche Klärung „User-Information vs. zusätzlicher Mail-Reminder zur Erfüllung Art. 17" (siehe Section 9)	Anwalt	binnen 60 Tagen	Nein
11	Microsoft-Sub-AV in DiGA-Datenschutz-Konzept einbauen	DSB + rebreak-strategist	wenn DiGA-Antrag aktuell wird	Nein
12	Bestehenden VVT auf Konsistenz prüfen (Gmail/iCloud/GMX als Sub-AV?)	DSB-Audit	binnen 60 Tagen	Nein (aber wichtig für Konsistenz)

---

9. Was ich nicht entscheiden kann (Anwalts-Themen)

1. Vertragsrechtliche Bindung der MS-DPA an OAuth-App-Registrationen ohne kommerzielle Lizenz — gehört in eine kurze juristische Stellungnahme.
2. Finaler Wortlaut der Einwilligungserklärung Art. 9 — Einwilligungstexte sollten anwaltlich gegen UWG/AGB-Recht geprüft sein.
3. Finaler Wortlaut der Datenschutzerklärungs-Änderungen — Ich liefere DSB-Vorlagen, die juristische Abnahme bleibt Anwalt.
4. AGB-Anpassung für das veränderte Verfahren (App-Passwort → OAuth).
5. Art. 17-Erfüllung trotz fehlendem MS-Revoke-Endpoint (siehe Section 5.1) — konkret: Erfüllt die in-app User-Information mit Anleitung zum manuellen Entfernen unter account.microsoft.com die Art. 17-Pflicht ausreichend, oder müssen wir zusätzlich z. B. eine E-Mail-Erinnerung nach X Tagen versenden, bzw. eine schriftliche Bestätigung der erfolgten Entfernung anfordern? Hier wäre auch eine kurze Einschätzung wertvoll, ob die fehlende technische Revoke-Möglichkeit als Haftungs-Risiko für Rebreak einzustufen ist oder als „auf Seite des Identity Providers liegend" akzeptiert wird.

---

10. Quellen

• Microsoft Products and Services Data Protection Addendum (DPA), Sept 2025 — aka.ms/DPA
• Microsoft EU Data Boundary — Microsoft Learn
• Microsoft Trust Center — EU Data Boundary Overview
• Microsoft EU Data Boundary Completion — Microsoft On the Issues, 26.02.2025
• Microsoft European Digital Commitments — One Year On, 29.04.2026
• Microsoft Identity Platform — OIDC Single Sign-Out / Token Revocation
• Microsoft Q&A — Identity Platform OAuth2 Revoke Access (kein Drittanbieter-Revoke-Endpoint)
• Microsoft Q&A — How to revoke OAuth refresh token? (Bestätigung der technischen Limitation)
• Microsoft Learn — Refresh tokens in the Microsoft identity platform
• Microsoft Graph — revokeSignInSessions (invalidiert alle Refresh-Tokens des Users, nicht nur Rebreak)
• EU-Standardvertragsklauseln 2021/914 — Europäische Kommission
• EDPB Recommendations 01/2020 — Supplementary Measures (TIA-Grundlage)
• BfArM DiGA-Leitfaden (Datenschutz-Anforderungen)
• DSGVO: Art. 6, 9, 13, 15, 17, 28, 30, 32, 33, 35 sowie Kapitel V

---

Mit freundlichen Grüßen Hans Müller Externer Datenschutzbeauftragter, Rebreak