Seit dem 17. August 2026 muss Apple sein App Tracking Transparency Framework auf Anordnung des Bundeskartellamts überarbeiten, weil die Warnhinweise vor Drittanbieter-Tracking Wettbewerber benachteiligten. Das ändert nichts an der DSGVO-Pflicht, die für dieselben App-Anbieter ohnehin schon gilt, macht aber sichtbar, wie wenig ATT und DSGVO-Einwilligung tatsächlich dasselbe Problem lösen.
Wer eine App mit Nutzern in der EU betreibt, kommt an der DSGVO nicht vorbei, unabhängig davon, was Apples oder Googles Plattformregeln verlangen. Anders als bei Websites lässt sich mobile Compliance auch nicht einfach nachrüsten: SDKs von Werbenetzwerken, Analyseanbietern und Crash-Reporting-Diensten laufen tief im App-Code, oft bevor eine Einwilligungsabfrage überhaupt gerendert wurde, und Google Play sowie der App Store setzen eigene Prüfmechanismen darüber.
Das Wichtigste in Kürze
➤ Für Apps mit Nutzern in Deutschland gilt neben der DSGVO zusätzlich das TDDDG (bis Mai 2024: TTDSG) – jeder Zugriff auf im Endgerät gespeicherte Informationen, nicht nur Cookies, benötigt eine Einwilligung nach § 25 TDDDG.
- Das Bundeskartellamt hat Apple am 17. August 2026 verpflichtet, sein ATT-Framework binnen vier Monaten umzubauen (Quelle: netzpolitik.org, August 2026) – ATT ersetzt aber keine DSGVO-Einwilligung, beide Abfragen bleiben nötig.
- Die Hamburgische Datenschutzbehörde prüft laut ihrem Jahresbericht 2025 einen Fall, in dem eine bekannte Dating-App über eingebettete Werbe-SDKs präzise Standortdaten an Dritte weitergab, obwohl die Datenschutzerklärung dies nicht abbildete.
- Für Auskunftsersuchen gilt auch bei Apps die Monatsfrist aus Art. 12 Abs. 3 DSGVO, verlängerbar um zwei weitere Monate bei Komplexität – die Verlängerung muss innerhalb des ersten Monats begründet mitgeteilt werden.
- Die EDPB hat Transparenz- und Informationspflichten nach Art. 12 bis 14 DSGVO zum Schwerpunktthema ihrer koordinierten Prüfaktion 2026 gemacht; 25 europäische Aufsichtsbehörden bewerten dieses Jahr gezielt, ob Datenschutzhinweise vollständig und verständlich sind.
Warum mobile DSGVO-Compliance anders funktioniert als bei Websites
Bei einer Website liegt die Kontrolle über Tracking-Technologien fast vollständig beim Betreiber: Ein Consent-Management-Tool blockiert Skripte im Browser, bis eine Einwilligung vorliegt. Bei einer App ist die Verantwortung auf mehrere Parteien verteilt, die selten koordiniert handeln.
App-Publisher integrieren typischerweise ein Bündel an Dritt-SDKs für Analyse, Werbung, Crash-Reporting und Push-Benachrichtigungen. Jedes dieser SDKs kann eigenständig auf Geräte-Kennungen zugreifen, sobald es initialisiert wird, und diese Initialisierung liegt im Code des SDK-Anbieters, nicht im sichtbaren UI-Layer der App. Ein Publisher, der nur die Consent-Banner-Logik prüft, aber nicht das tatsächliche Netzwerkverhalten der eingebundenen SDKs, kontrolliert damit nur die Oberfläche, nicht den eigentlichen Datenfluss. Genau diese Lücke zwischen angezeigter Einwilligungsoption und tatsächlichem SDK-Verhalten hat die Hamburgische Datenschutzbehörde im Fall der Dating-App Lovoo dokumentiert, wie weiter unten dargestellt.
Hinzu kommt eine zweite Ebene: App Store und Google Play haben eigene Richtlinien zu Tracking und Werbekennungen, die parallel zur DSGVO gelten, sie aber nicht ersetzen. Ein Plattform-Gatekeeper kann eine App wegen fehlender Store-Konformität ablehnen, ohne dass damit automatisch DSGVO-Konformität hergestellt ist, und umgekehrt.
Anwendbarkeit der DSGVO auf mobile Apps
Der räumliche Anwendungsbereich nach Art. 3 DSGVO knüpft nicht an den Sitz des App-Anbieters an, sondern an das Verhalten der betroffenen Personen: Bietet eine App Nutzern in der EU ihre Dienste an oder beobachtet sie deren Verhalten (etwa durch Standortdaten oder Nutzungsprofile), greift die DSGVO unabhängig davon, wo der Anbieter registriert ist. Eine App aus den USA oder Asien, die im deutschen oder europäischen App-Store-Markt aktiv beworben wird oder gezielt EU-Nutzer adressiert, fällt damit unter die DSGVO, auch ohne EU-Niederlassung.
Verantwortlicher: die natürliche oder juristische Person, die über Zweck und Mittel der Datenverarbeitung entscheidet – bei den meisten Apps der Publisher.
Auftragsverarbeiter: wer personenbezogene Daten im Auftrag und nach Weisung des Verantwortlichen verarbeitet, etwa ein Backend-Hosting-Anbieter.
Bei eingebetteten Dritt-SDKs ist diese Rollenverteilung selten so klar. Ein Werbe-SDK, das Nutzerprofile für eigene Zwecke bildet und über mehrere Apps hinweg mit anderen Datenquellen verknüpft, agiert regelmäßig als eigener Verantwortlicher oder als gemeinsam Verantwortlicher nach Art. 26 DSGVO, nicht als reiner Auftragsverarbeiter des Publishers. Diese Einordnung entscheidet darüber, wer im Schadensfall haftet und wer welche Informationspflichten trägt, und sie muss vertraglich vor der Integration eines SDKs geklärt werden, nicht erst im Streitfall.
Personenbezogene Daten in mobilen Apps
Apps erheben typischerweise mehr Kategorien personenbezogener Daten als eine vergleichbare Website, weil sie tieferen Zugriff auf das Gerät haben:
Geräte- und Werbekennungen: die Werbe-ID (IDFA unter iOS, GAID unter Android) identifiziert ein Gerät über Apps hinweg und gilt als personenbezogenes Datum, sobald sie einer Person zuordenbar wird.
Standortdaten: von grober, netzwerkbasierter Ortung bis zu präziser GPS-Position; präzise Standortdaten unterliegen nach den EDPB-Leitlinien 2/2023 zum technischen Anwendungsbereich von Art. 5 Abs. 3 ePrivacy-Richtlinie (finale Fassung vom 7. Oktober 2024) einer strengeren Einwilligungspflicht, weil ihr Zugriff über das Endgerät selbst erfolgt.
Verhaltens- und Nutzungsdaten: Klickpfade, Sitzungsdauer, In-App-Käufe, die zu Nutzungsprofilen aggregiert werden können.
Diagnose- und Absturzdaten: Crash-Reports enthalten häufig Gerätekennungen, IP-Adressen und teils Nutzereingaben zum Zeitpunkt des Absturzes.
Ein Absturzbericht wirkt technisch harmlos, wird aber personenbezogen, sobald er mit einer Geräte- oder Nutzerkennung verknüpft ist. Diese Einordnung entscheidet, ob ein Crash-Reporting-SDK überhaupt in die Kategorie "erforderlich" fällt oder eine eigene Einwilligung braucht.
Rechtsgrundlagen für die Datenverarbeitung in Apps
Einwilligung ist in der Praxis die Rechtsgrundlage, auf die sich App-Anbieter für Tracking, Werbe-Personalisierung und die meisten Analyse-SDKs stützen müssen, weil der Zugriff auf gespeicherte Geräteinformationen bereits durch § 25 TDDDG (siehe unten) eine gesonderte Einwilligung verlangt, bevor Art. 6 DSGVO überhaupt greift.
Berechtigtes Interesse nach Art. 6 Abs. 1 lit. f DSGVO trägt für Kernfunktionen, die ohne die Datenverarbeitung technisch nicht funktionieren würden (etwa Absturzberichte zur reinen Fehlerbehebung ohne Profilbildung), aber nicht für Werbe-Tracking oder Profilbildung über mehrere Apps hinweg. Die Grenze verläuft dort, wo die Verarbeitung für den Nutzer nicht mehr vorhersehbar ist: Eine Interessenabwägung, die Werbe-Tracking als "berechtigtes Interesse" des Publishers einstuft, hält einer Prüfung durch eine Aufsichtsbehörde in aller Regel nicht stand, weil der Nutzer eine solche Verarbeitung bei der Nutzung einer App vernünftigerweise nicht erwartet.
Vertragserfüllung nach Art. 6 Abs. 1 lit. b DSGVO deckt nur Daten, die für die konkret nachgefragte Leistung notwendig sind, etwa die Lieferadresse bei einer Shopping-App, nicht aber zusätzliche Datenpunkte, die dem Geschäftsmodell, aber nicht der Leistung selbst dienen.
TDDDG und DSGVO: zwei Pflichtenkreise, die parallel gelten
Für Anbieter mit Nutzern in Deutschland kommt zur DSGVO eine zusätzliche, eigenständige Pflicht hinzu: das Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz (TDDDG), das am 14. Mai 2024 das bis dahin geltende TTDSG in der Substanz nahezu unverändert abgelöst hat und lediglich den Begriff "Telemedien" durch "digitale Dienste" ersetzt hat, um an das Digitale-Dienste-Gesetz anzuknüpfen.
§ 25 TDDDG setzt Art. 5 Abs. 3 der ePrivacy-Richtlinie um und verlangt eine Einwilligung für jedes Speichern von Informationen auf einem Endgerät oder jeden Zugriff auf dort bereits gespeicherte Informationen, unabhängig von der Technologie. Das schließt nicht nur Website-Cookies ein, sondern ausdrücklich auch den Zugriff einer App auf Werbekennungen, lokale Speicherbereiche oder Gerätesensoren. Eine App, die beim ersten Start ein Werbe-SDK initialisiert, das die Werbe-ID ausliest, greift damit auf im Endgerät gespeicherte Informationen zu und braucht dafür eine § 25-TDDDG-Einwilligung, bevor überhaupt geprüft wird, ob die anschließende Datenverarbeitung eine Rechtsgrundlage nach Art. 6 DSGVO hat.
Diese Doppelstruktur wird in der Praxis oft übersehen: Ein Team, das nur die DSGVO-Rechtsgrundlage für die Datenverarbeitung selbst prüft, aber nicht den vorgeschalteten Zugriffsschritt nach § 25 TDDDG, lässt genau die Einwilligungsabfrage aus, die für die meisten Werbe- und Analyse-SDKs überhaupt zuerst nötig wäre.
| Regelungsbereich | DSGVO | TDDDG (bis Mai 2024: TTDSG) |
|---|---|---|
| Was wird geregelt | Verarbeitung personenbezogener Daten insgesamt | Speichern/Auslesen von Informationen auf dem Endgerät, technologieneutral |
| Auslösender Schritt | Jede Verarbeitung personenbezogener Daten | Der reine Zugriffsschritt, auch ohne dass die Daten schon personenbezogen sein müssen |
| Räumlicher Bezug | EU-weit über Art. 3 DSGVO | Nur in Deutschland als nationale Umsetzung der ePrivacy-Richtlinie |
| Praktische Folge für Apps | Rechtsgrundlage für Werbeprofilbildung, DSAR-Fristen, DPIA-Pflicht | Einwilligungspflicht vor SDK-Initialisierung, unabhängig vom späteren Verarbeitungszweck |
| Zuständige Behörde | Landesdatenschutzbehörden, EDPB-Koordination | Landesdatenschutzbehörden (keine eigene TDDDG-Aufsicht) |
Die CNIL hat mit ihrer am 27. März 2025 verabschiedeten und im April 2025 veröffentlichten Empfehlung zu mobilen Anwendungen einen vergleichbaren Ansatz für Frankreich formuliert und verlangt darin ausdrücklich, dass Publisher ihre SDK-Anbieter vor der Integration prüfen und die Verantwortlichkeiten vertraglich klären. Das zeigt, dass die deutsche TDDDG-Logik kein nationaler Sonderweg ist, sondern Teil eines europaweiten Trends, App-spezifische ePrivacy-Durchsetzung neben der DSGVO auszubauen.
Einwilligungsanforderungen und Implementierungsarchitektur in der App
Eine wirksame Einwilligung nach DSGVO und TDDDG muss freiwillig, spezifisch, informiert und unmissverständlich erklärt werden und ebenso leicht widerrufbar sein, wie sie erteilt wurde. Für Apps heißt das konkret: eine granulare Auswahl nach Zweck (Analyse, Werbung, Personalisierung getrennt abwählbar), keine vorausgefüllten Zustimmungsfelder und ein jederzeit erreichbarer Einstellungsbereich, über den die Einwilligung ohne Medienbruch widerrufen werden kann.
Die Architekturfrage, mit der die meisten Teams ringen, ist nicht, ob eine Einwilligungsabfrage nötig ist, sondern wie sie technisch eingebettet wird, und das ist zuerst eine Compliance-Entscheidung, keine reine Entwicklerfrage. Eine In-App-Einwilligungsoberfläche lässt sich grob auf zwei Arten umsetzen: als native UI-Komponente, die direkt im App-Framework läuft, oder als eingebettete WebView, die eine webbasierte Oberfläche innerhalb der App darstellt.
Der native Ansatz hat den Vorteil, dass die Einwilligungsabfrage vor jeder anderen App-Logik ausgeführt werden kann, weil sie Teil desselben Startzyklus ist, der auch die SDK-Initialisierung steuert. Das verkleinert das Risiko, dass ein Werbe- oder Analyse-SDK bereits Daten sendet, bevor die Einwilligungsentscheidung überhaupt getroffen wurde, ein Muster, das Aufsichtsbehörden als "verdeckte Vorab-Aktivierung" einstufen. Der WebView-Ansatz ist schneller über mehrere Plattformen hinweg auszurollen, bringt aber ein zusätzliches Prüfrisiko mit sich: Wenn die WebView selbst erst nach dem App-Start geladen wird, kann in der Zeit dazwischen bereits SDK-Code laufen, sodass die eigentliche Reihenfolge, auf die es nach § 25 TDDDG ankommt, technisch nicht mehr eingehalten wird, auch wenn die Banner-Oberfläche selbst korrekt aussieht.
Für Publisher mit Nutzern auf mehreren Geräten kommt die Frage der geräteübergreifenden Synchronisierung hinzu: Widerruft ein Nutzer die Einwilligung auf dem Smartphone, muss diese Entscheidung nachvollziehbar auch für dasselbe Konto auf einem Tablet gelten, was eine konto- statt reine Gerätekennung als Speicherpunkt für die Einwilligungsentscheidung voraussetzt. Wer die Einwilligung ausschließlich lokal auf dem Gerät speichert, kann diesen Fall nicht abbilden und riskiert, dass ein Widerruf auf einem Gerät auf den übrigen Geräten desselben Nutzers wirkungslos bleibt.
Secure Privacys Consent-Plattform bildet mobile Einwilligungen bereits heute als eigenen Bereich neben Website-, Formular- und individuellen Consent-Flows im selben Dashboard ab, mit derselben lückenlosen, exportierbaren Protokollierung wie auf der Web-Seite. Das reduziert zumindest das Risiko, Einwilligungsnachweise für App-Nutzer in einem separaten System pflegen zu müssen, das bei einer Prüfung nicht mit den Website-Nachweisen zusammengeführt werden kann.
SDK- und Tracker-Governance
Die zentrale organisatorische Aufgabe ist ein laufend gepflegtes SDK-Inventar: welches SDK, von welchem Anbieter, zu welchem Zweck, mit Zugriff auf welche Datenkategorien. Ohne dieses Inventar kann ein Publisher weder die eigene Datenschutzerklärung korrekt formulieren noch im Auskunftsfall zuverlässig sagen, welche Daten tatsächlich wohin geflossen sind.
Zweckbindung bedeutet hier konkret: Ein SDK, das für Absturzberichte eingebunden wurde, darf nicht ohne gesonderte Prüfung und gegebenenfalls gesonderte Einwilligung zusätzlich Werbeprofile bilden, selbst wenn der Anbieter diese Funktion technisch mitliefert. Viele SDK-Anbieter bündeln mehrere Funktionen (Analyse, Crash-Reporting, Push, Werbung) in einem einzigen Paket, was die Zweckbindung auf Publisher-Seite erschwert, wenn nicht einzeln geprüft wird, welche Teilfunktion tatsächlich aktiv genutzt wird.
Laufzeit-Blockierung heißt, dass ein SDK erst nach positiver Einwilligung tatsächlich Daten senden darf, nicht nur, dass ein Consent-Banner angezeigt wurde. Das ist ein Unterschied zwischen einer Compliance-Behauptung und einer tatsächlichen technischen Kontrolle, und genau diesen Unterschied prüfen Aufsichtsbehörden inzwischen aktiv nach, wie der Fall der Dating-App unten zeigt.
Vertragsklauseln mit SDK-Anbietern sollten vor der Integration klären, ob der SDK-Anbieter als Auftragsverarbeiter oder als eigener Verantwortlicher handelt, welche Datenkategorien er verarbeitet, ob er die Daten an weitere Dritte weitergibt und wie er auf einen Löschungs- oder Auskunftsantrag reagiert. Ein Publisher, der diese Fragen erst nach einer Beschwerde klärt, hat gegenüber der Aufsichtsbehörde eine deutlich schwächere Position als einer, der die Antworten vertraglich dokumentiert hat, bevor das SDK überhaupt live ging.
Secure Privacys automatisches Scanning erkennt und kategorisiert eingebundene Tracking-Technologien und aktualisiert sich bei Änderungen selbst; dieselbe Logik, mit der die Plattform Website-Tracker überwacht, lässt sich auf die Governance-Frage bei App-SDKs übertragen, auch wenn die technische Erfassung bei nativen Apps anders ansetzt als im Browser.
Datenschutzhinweise innerhalb der App
Ein Datenschutzhinweis, der nur als externer Link zu einer Website-Datenschutzerklärung eingebunden ist, erfüllt die Informationspflichten nach Art. 13 und 14 DSGVO nicht vollständig, wenn die App selbst Datenkategorien oder Zwecke verarbeitet, die auf der verlinkten Seite nicht abgebildet sind. Die Informationen müssen für die App-spezifischen Verarbeitungen (Standort, Push, Werbekennung) so konkret sein, dass ein Nutzer ohne juristische Vorkenntnisse versteht, was mit seinen Daten geschieht.
In der Praxis bewährt sich eine zweistufige Struktur: eine kurze, kontextuelle Information direkt an der Stelle, an der eine Berechtigung angefragt wird (etwa beim ersten Zugriff auf den Standort), ergänzt durch eine vollständige, jederzeit einsehbare Datenschutzerklärung innerhalb der App selbst, nicht nur auf der Website des Anbieters.
Zusätzlich verlangen beide großen App-Stores eigene, standardisierte Datenschutzangaben: Apples "Privacy Nutrition Label" in App Store Connect (seit Dezember 2020 verpflichtend) und Googles "Data Safety"-Abschnitt im Play Store (verpflichtend seit Juli 2022). Diese Store-Angaben ersetzen die Datenschutzerklärung nicht, müssen aber inhaltlich zu ihr passen. Aufsichtsbehörden ziehen Widersprüche zwischen Store-Angabe und tatsächlicher Datenschutzerklärung inzwischen aktiv als Beleg für eine Transparenzverletzung nach Art. 12 bis 14 DSGVO heran, gerade weil diese Artikel 2026 im Fokus der koordinierten EDPB-Prüfaktion stehen.
Betroffenenrechte und DSAR-Bearbeitung für mobile Nutzer
Das Auskunftsrecht nach Art. 15 DSGVO und die übrigen Betroffenenrechte gelten für App-Nutzer identisch wie für Website-Nutzer. Die Frist aus Art. 12 Abs. 3 DSGVO beträgt einen Monat nach Eingang des Antrags und kann bei komplexen oder zahlreichen Anfragen um bis zu zwei weitere Monate verlängert werden, wobei die betroffene Person innerhalb des ersten Monats über die Verlängerung und deren Gründe informiert werden muss.
Bei Apps kommt eine praktische Schwierigkeit hinzu, die bei Websites seltener auftritt: Ein Nutzer, der eine App löscht, ohne vorher einen Löschungsantrag zu stellen, hinterlässt seine Daten häufig weiter bei mehreren Dritt-SDK-Anbietern, die unabhängig vom Publisher eigene Kopien der Daten halten können. Eine vollständige Auskunft muss deshalb auch die Daten umfassen, die bei Verarbeitern und mitverantwortlichen SDK-Anbietern liegen, nicht nur die im eigenen Backend gespeicherten Datensätze. Ohne das SDK-Inventar aus dem vorherigen Abschnitt lässt sich diese Vollständigkeit kaum belastbar nachweisen.
Datenschutz-Folgenabschätzungen für mobile Apps
Eine Datenschutz-Folgenabschätzung (DPIA) nach Art. 35 DSGVO wird verpflichtend, wenn eine Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen mit sich bringt. Für Apps ist das typischerweise dann der Fall, wenn systematisch und umfassend Standortdaten erhoben werden, wenn ein Scoring oder Profiling-Verfahren über Nutzerverhalten hinweg eingesetzt wird oder wenn besonders sensible Daten (Gesundheits-, biometrische Daten) verarbeitet werden.
Der häufigste Auslöser in der Praxis ist die Kombination aus Standortdaten und Werbeprofilbildung über mehrere Sitzungen hinweg, exakt das Muster, das im eingangs erwähnten Lovoo-Fall untersucht wird. Eine DPIA sollte deshalb nicht erst geschrieben werden, wenn eine Aufsichtsbehörde nachfragt, sondern vor der Integration jedes neuen SDKs, das systematisch Standort- oder Verhaltensdaten verarbeitet, aktualisiert werden.
iOS vs. Android: ATT und Google Consent Mode v2
ATT und DSGVO-Einwilligung lösen unterschiedliche Probleme und ersetzen sich gegenseitig nicht. ATT regelt den technischen Zugriff auf die IDFA auf Betriebssystemebene; die DSGVO-Einwilligung regelt, ob und wozu die dahinterliegende Datenverarbeitung überhaupt erlaubt ist. Ein Nutzer kann die DSGVO-Einwilligung ablehnen und den ATT-Zugriff trotzdem erlauben, oder umgekehrt, und beide Antworten müssen unabhängig voneinander respektiert werden. In der Praxis sollte die DSGVO-Einwilligungsabfrage vor der ATT-Abfrage laufen, weil eine Ablehnung der DSGVO-Einwilligung bereits ausschließt, dass Daten verarbeitet werden, unabhängig davon, was der ATT-Dialog später ergibt.
Die vom Bundeskartellamt am 17. August 2026 angeordnete Überarbeitung des ATT-Frameworks betrifft die Wettbewerbsdimension: Apple muss die "Warnhand"-Symbolik und den Begriff "Tracking" aus den Dialogen für Drittanbieter entfernen, Drittanbietern mehr Raum (4.000 Zeichen) zur Erklärung ihres Geschäftsmodells geben und eigene Tracking-Abfragen an dieselben Standards binden wie die der Konkurrenz, innerhalb von vier Monaten nach der Entscheidung. Das ändert die Optik und den Ablauf des ATT-Dialogs, aber nicht die parallele DSGVO-Pflicht, die App-Anbieter ohnehin erfüllen müssen.
Auf Android-Seite verlangt Googles Consent Mode v2 seit den ab dem 28. Januar 2026 verschärften Google-Play-Richtlinien eine ausdrückliche, durch aktives Nutzerhandeln erklärte Einwilligung für alle vier Consent-Signale (analytics_storage, ad_storage, ad_user_data, ad_personalization), bevor entsprechende Google-Dienste Daten empfangen dürfen. Technisch müssen diese Signale früh im App-Lebenszyklus gesetzt werden, damit nachgeschaltete Google-SDKs die Nutzerentscheidung tatsächlich respektieren, statt sie erst nachträglich zu berücksichtigen.
| Kriterium | Apple ATT | Google Consent Mode v2 |
|---|---|---|
| Regelungsebene | Plattform-Richtlinie (Apple), seit 17.8.2026 kartellrechtlich angepasst | Plattform-Richtlinie (Google), verschärft seit 28.1.2026 |
| Was wird abgefragt | Zugriff auf die Werbekennung (IDFA) | Vier einzelne Consent-Signale für Analyse und Werbung |
| Ersetzt DSGVO-Einwilligung? | Nein | Nein |
| Reihenfolge zur DSGVO-Einwilligung | Nach der DSGVO-Einwilligung abfragen | Signale müssen die zuvor erfasste DSGVO-Entscheidung widerspiegeln |
| Konsequenz bei Ablehnung | IDFA bleibt für diese App nicht zugänglich | Betroffene Google-Dienste dürfen keine Daten empfangen |
Häufige DSGVO-Fehler bei mobilen Apps
Die technische Wahrheitslücke: ein Consent-Banner zeigt eine Auswahlmöglichkeit, während im Hintergrund SDKs unabhängig davon weiter Daten senden. Genau dieses Muster untersuchte die Hamburgische Datenschutzbehörde laut ihrem 2025er Jahresbericht bei einer bekannten deutschen Dating-App (Lovoo): Präzise Standortdaten wurden über eingebettete Werbe-SDKs an Drittanbieter weitergegeben, obwohl die Weitergabe standardmäßig aktiviert war und Nutzer sie über den Einstellungsdialog nicht wirksam unterbinden konnten. Das Unternehmen habe die Datenübertragung nach Konfrontation mit den Prüfungsergebnissen gestoppt; das Prüfverfahren war zum Zeitpunkt der Veröffentlichung noch nicht abgeschlossen.
Vorab-Aktivierung von SDKs: Analyse- oder Werbe-SDKs initialisieren beim App-Start, bevor überhaupt eine Einwilligungsentscheidung getroffen wurde, oft weil das SDK tief in Framework-Startroutinen eingebunden ist, die kein Team gesondert geprüft hat.
Schatten-Analytics: ein zweites Analyse- oder Attributions-SDK läuft parallel zum offiziell dokumentierten, meist aus einem älteren Marketing-Integrationsprojekt, ohne dass es im aktuellen SDK-Inventar oder in der Datenschutzerklärung auftaucht.
Fehlende oder funktionslose Einwilligungsprotokolle: Es existiert kein durchsuchbarer Nachweis, wann welcher Nutzer welche Einwilligung erteilt oder widerrufen hat, was im Auskunfts- oder Prüfungsfall dazu führt, dass der Publisher die eigene Rechtsgrundlage nicht belegen kann.
Compliance automatisieren
Manuelles Nachhalten von SDK-Inventar, Einwilligungsprotokollen und Fristen für Auskunftsersuchen skaliert nicht über mehr als eine Handvoll Apps oder Märkte hinweg. Ein zentrales Consent-Dashboard, das Web- und mobile Einwilligungen im selben System mit lückenloser, exportierbarer Protokollierung führt, verkürzt genau die Lücke zwischen dokumentierter Zustimmung und tatsächlichem Datenfluss, die im Lovoo-Fall zum Prüfverfahren geführt hat. Secure Privacys automatisches Compliance-Scanning aktualisiert sich bei Änderungen an eingebundenen Trackern selbst und liefert damit die laufende Inventar-Grundlage, die eine DPIA oder eine Auskunftsantwort ohnehin voraussetzt, ohne dass ein Team das SDK-Verzeichnis jeden Monat händisch neu abgleichen muss.
Compliance-Checkliste für mobile Apps
- SDK-Inventar mit Anbieter, Zweck und Datenzugriff vollständig und aktuell führen
- Rollen (Verantwortlicher, Auftragsverarbeiter, gemeinsam Verantwortliche) für jedes SDK vertraglich vor Integration klären
- § 25-TDDDG-Einwilligung vor jedem Zugriff auf gespeicherte Geräteinformationen einholen, granular nach Zweck
- Technisch prüfen, ob SDKs erst nach positiver Einwilligung tatsächlich Daten senden, nicht nur, ob ein Banner angezeigt wird
- Widerruf der Einwilligung geräte- und plattformübergreifend für dasselbe Nutzerkonto wirksam umsetzen
- In-App-Datenschutzhinweise für app-spezifische Verarbeitungen (Standort, Push, Werbekennung) separat von der Website-Erklärung pflegen
- DSAR-Prozess so gestalten, dass er auch Daten bei Dritt-SDK-Anbietern innerhalb der Monatsfrist erfasst
- DPIA vor Integration jedes neuen Standort- oder Profiling-SDKs aktualisieren, nicht erst bei Anfrage einer Behörde
- DSGVO-Einwilligung vor der ATT-Abfrage unter iOS einholen, beide Antworten unabhängig respektieren
- Google Consent Mode v2-Signale früh im App-Lebenszyklus setzen, damit nachgeschaltete Google-Dienste sie tatsächlich berücksichtigen
Wer prüfen will, wie granular die eigene Einwilligungsarchitektur bereits ist, findet einen strukturierten Einstieg in unserem Leitfaden zum Einwilligungsmanagement.
FAQ
Ersetzt Apples App Tracking Transparency die DSGVO-Einwilligung?
Nein. ATT regelt nur den Zugriff auf die IDFA auf Betriebssystemebene, während die DSGVO-Einwilligung darüber entscheidet, ob die eigentliche Datenverarbeitung überhaupt erlaubt ist. Beide Abfragen müssen unabhängig voneinander eingeholt werden, und die DSGVO-Einwilligung sollte vor der ATT-Abfrage erfolgen.
Gilt das TDDDG auch für Apps außerhalb Deutschlands?
Das TDDDG gilt für den Zugriff auf Endgeräte von Nutzern in Deutschland, unabhängig davon, wo der App-Anbieter registriert ist. Eine App mit Nutzern in Deutschland muss § 25 TDDDG beachten, selbst wenn ihr Anbieter außerhalb der EU sitzt, sobald sie Nutzer in Deutschland adressiert.
Was ist der Unterschied zwischen TDDDG und TTDSG?
Es handelt sich um dieselbe Rechtsgrundlage unter neuem Namen: Das TDDDG hat am 14. Mai 2024 das TTDSG inhaltlich fast unverändert abgelöst und lediglich den Begriff "Telemedien" durch "digitale Dienste" ersetzt, um an das neue Digitale-Dienste-Gesetz anzuknüpfen.
Wie lange hat ein Unternehmen Zeit, ein Auskunftsersuchen eines App-Nutzers zu beantworten?
Ein Monat nach Eingang des Antrags, mit der Möglichkeit einer Verlängerung um bis zu zwei weitere Monate bei komplexen oder zahlreichen Anfragen, sofern die betroffene Person innerhalb des ersten Monats über die Verlängerung informiert wird (Art. 12 Abs. 3 DSGVO).
Braucht jede App eine Datenschutz-Folgenabschätzung?
Nein, nur wenn die Verarbeitung voraussichtlich ein hohes Risiko mit sich bringt, etwa bei systematischer, umfassender Standorterfassung oder Profiling über mehrere Sitzungen hinweg. Apps ohne solche Verarbeitungen benötigen keine DPIA, sollten die Einschätzung aber bei jeder neuen SDK-Integration erneut prüfen.
Die technische Wahrheitslücke zwischen angezeigtem Consent-Banner und tatsächlichem SDK-Verhalten ist genau das Risiko, das eine Aufsichtsbehörde wie im Lovoo-Fall zuerst prüft, und manuell lässt sich diese Lücke über mehrere Apps und Märkte hinweg kaum verlässlich schließen. Secure Privacys Cookie & Consent-Lösung führt Web- und mobile Einwilligungen im selben Dashboard mit lückenloser, exportierbarer Protokollierung, automatischem Tracker-Scanning und validierten DSAR-Formularen zusammen, sodass App-Publisher und Website-Betreiber denselben Compliance-Nachweis aus einer Hand führen können. Jetzt eine Demo vereinbaren, um die eigene SDK- und Einwilligungslandschaft zu prüfen.