Rollenregister der Anbieter, Unterauftragsverarbeiter und Datenschutzangaben zu SDKs in E-Commerce-Apps

Ein Unterauftragsverarbeiter ist ein Auftragsverarbeiter, den ein anderer Auftragsverarbeiter beauftragt. Die meisten Anbieter, die Sie direkt beauftragen, etwa ein Cloud-Hoster, ein Analyseanbieter oder ein App-Baukasten, sind deshalb Ihre Auftragsverarbeiter und keine Unterauftragsverarbeiter. Eine E-Commerce-App braucht daher ein Rollenregister der Anbieter für den gesamten Stack und zusätzlich Listen der Unterauftragsverarbeiter für die Ketten von Auftragsverarbeitern darin. Diese Unterscheidung entscheidet über Verträge, Genehmigungen und Offenlegungen.

Dieser Leitfaden trennt die vier Dokumente, erklärt, wie Sie die tatsächliche Rolle eines Anbieters einschätzen, und behandelt SDK-Angaben, Datenübermittlungen und Datenschutzangaben in den Stores. Er ergänzt unseren Leitfaden zu Datenschutz und Einwilligung in mobilen E-Commerce-Apps.

Kurz gesagt. Legen Sie ein Rollenregister der Anbieter für den gesamten Stack an. Erfassen Sie für jeden Anbieter Datenfluss, Zweck, rechtliche Rolle, Standort, Vertrag und Löschweg. Führen Sie Listen der Unterauftragsverarbeiter für die Ketten von Auftragsverarbeitern darin selbst, oder lassen Sie sich diese geben. Erstellen Sie aus dem Register Ihre Datenschutzerklärung, die Angaben für App Store und Play sowie den Bildschirm für die Einwilligung. Kopieren Sie das Register nicht in jedes dieser Dokumente.

Umfang, und was dieser Leitfaden nicht ist. Dies ist ein praktischer Leitfaden, keine Rechtsberatung. Die rechtliche Rolle eines Anbieters und der richtige Übermittlungsmechanismus hängen von Ihren konkreten Datenflüssen und Verträgen ab, und diese ändern sich. Erarbeiten Sie die Analyse mit Ihrer Rechtsberatung, und prüfen Sie die aktuellen Anforderungen der Plattformen und Aufsichtsbehörden an der Quelle, bevor Sie sich darauf verlassen.

Vier Dokumente, vier Zielgruppen

Führen Sie diese als getrennte Dokumente, weil sie unterschiedlichen Zielgruppen und Zwecken dienen:

Das Register ist die interne maßgebliche Quelle. Die anderen drei Dokumente leiten sich daraus ab, haben aber jeweils eigene Zielgruppen und Regeln. Typische Fehler sind, das interne Register als Datenschutzerklärung zu veröffentlichen oder es als Liste der Unterauftragsverarbeiter zu bezeichnen.

Zuerst kommt die Frage nach der Rolle, und die tatsächlichen Verhältnisse entscheiden sie

Klären Sie die rechtliche Rolle eines Anbieters, bevor Sie ihn eintragen. Die Einordnung verändert Ihre Pflichten. Verstehen Sie diese Beispiele aus dem E-Commerce als Ausgangspunkt für eine Prüfung, nicht als feststehende Einordnungen:

Zwei Punkte sind wichtiger als die Tabelle. Erstens: Die tatsächlichen Verhältnisse bestimmen die Rolle, nicht die Bezeichnung im Vertrag. Ein Auftragsverarbeitungsvertrag (AVV) kann ein Unternehmen nicht zu Ihrem Auftragsverarbeiter machen, wenn es selbst entscheidet, warum und wie es Daten nutzt, oder Daten für eigene Zwecke weiterverwendet. Fragen Sie, wer entscheidet, warum und wie die Daten verarbeitet werden. Werbe- und Mess-SDKs verdienen besondere Aufmerksamkeit, weil App-Baukasten, Marke, Analyseanbieter und Werbeplattform in verschiedenen Datenflüssen unterschiedliche Rollen haben können.

Zweitens: Eine gemeinsame Verantwortlichkeit bringt eine eigene Anforderung mit sich. Nach Artikel 26 DSGVO müssen gemeinsam Verantwortliche in einer Vereinbarung transparent festlegen, wer welche Pflichten übernimmt, und das Wesentliche dieser Vereinbarung muss den betroffenen Personen zur Verfügung gestellt werden. „Wir und die Plattform sind gemeinsam Verantwortliche“ ist also der Anfang einer Pflicht, kein abgehakter Punkt. Die richtigen Rollen sind auch die Voraussetzung dafür, dass sich Löschungen an die richtige Stelle weiterleiten lassen, wie unser Leitfaden zur Datenübersicht beschreibt.

Empfohlene Felder für das Rollenregister der Anbieter

Führen Sie das Register intern und so detailliert, dass es Ihre Rechtsberatung, Löschanfragen und eine Aufsichtsbehörde unterstützt. Diese Felder dienen dem Betrieb und sind kein vorgeschriebenes öffentliches Format:

• Name der juristischen Person (die tatsächliche Vertragspartei).
• Dienst und Verarbeitungszweck.
• Datenkategorien, um die es geht.
• Rolle: Verantwortlicher, Auftragsverarbeiter, Unterauftragsverarbeiter, gemeinsam Verantwortlicher oder eigenständig Verantwortlicher.
• Vertragspartei, Hosting-Standorte und Standorte mit Fernzugriff (der Verarbeitungsort allein reicht selten aus).
• Weitere Empfänger, an die der Anbieter Daten weitergibt, und die zugehörige Analyse der Übermittlung.
• Vertragsreferenz (der AVV oder ein anderer Vertrag), intern abgelegt, da ein AVV in der Regel ein vertraulicher Geschäftsvertrag ist und nicht zum öffentlichen Verlinken gedacht.
• Datum der Aufnahme, Status und Zuständigkeit.

Beschreiben Sie den Prozess für Änderungsmitteilungen in dem Dokument, das zu seiner Zielgruppe passt. Mitteilungen nach Artikel 28 gehen an die Verantwortlichen eines Auftragsverarbeiters. Datenschutzerklärungen richten sich an Verbraucher. Nehmen Sie diesen Prozess nicht in jede Anbieterzeile auf.

Der typische Anbieter-Stack einer E-Commerce-App

Die Stacks von E-Commerce-Apps sind oft länger als erwartet, und die Rollen unterscheiden sich. Personenbezogene Daten können an folgende Stellen gelangen:

• Cloud-Hosting und Datenbank-Infrastruktur
• Content Delivery Network (CDN)
• Authentifizierungsanbieter
• Fehlerüberwachung und Absturzberichte
• Produktanalyse
• Infrastruktur für den Versand von Push-Benachrichtigungen
• Kundensupport-Plattform
• E-Mail- und SMS-Anbieter
• Data Warehouse
• Attributions- und Werbe-SDKs
• Integrationen mit Shopify und dem Checkout
• Dienste von Apple und Google

Einige davon sind klar Ihre Auftragsverarbeiter. Andere, vor allem Werbe-, Zahlungs- und App-Store-Anbieter, können für einen Teil oder alle ihrer Tätigkeiten in einer anderen Rolle handeln. Gehen Sie die Liste Anbieter für Anbieter durch und ordnen Sie die Rolle bewusst zu.

Was Listen der Unterauftragsverarbeiter sind

Eine Liste der Unterauftragsverarbeiter zeigt den Verantwortlichen eines Auftragsverarbeiters, welche Dienstleister dieser Auftragsverarbeiter einsetzt. Als Marke sind für Sie die Listen relevant, die Ihre Auftragsverarbeiter über ihre eigenen Dienstleister veröffentlichen oder bereitstellen. Eine eigene Liste führen Sie nur, wenn Sie selbst für jemand anderen als Auftragsverarbeiter tätig sind.

Der Mechanismus dahinter ist vertraglich und keine Funktion für Verbraucher. Hat ein Verantwortlicher einem Auftragsverarbeiter nach Artikel 28 DSGVO eine allgemeine Genehmigung erteilt, Unterauftragsverarbeiter einzusetzen, muss der Auftragsverarbeiter den Verantwortlichen über geplante Hinzufügungen oder Ersetzungen informieren und ihm die Möglichkeit geben, Einspruch zu erheben. Das ist eine Pflicht des Auftragsverarbeiters gegenüber seinem Verantwortlichen. Es ist kein Recht der Verbraucher, und eine öffentliche Seite „Wir haben unsere Anbieter aktualisiert“ erfüllt diese Pflicht nicht. Halten Sie beides getrennt: Die Mitteilung mit Einspruchsmöglichkeit nach Artikel 28 läuft die Kette der Auftragsverarbeiter hinauf, die Transparenz gegenüber Verbrauchern läuft über Ihre Datenschutzerklärung.

Was die Datenschutzerklärung offenlegt (und was nicht)

Die Datenschutzerklärung ist ein Dokument für Verbraucher. Sie legt offen, was die Kundschaft wissen muss, nicht das gesamte interne Register. Eine Datenschutzerklärung nennt in der Regel die Zwecke, die Kategorien der Daten, die Empfänger oder Kategorien von Empfängern, die Rechte der Kundschaft und, soweit erforderlich, Übermittlungen. Beachten Sie „Empfänger oder Kategorien von Empfängern“: Oft müssen Sie in der öffentlichen Erklärung nicht jede juristische Person aus Ihrem Register namentlich nennen, und vertrauliche AVVs veröffentlichen Sie in der Regel nicht. Entscheiden Sie bewusst, was die Erklärung namentlich nennt und was sie nur als Kategorie angibt, und halten Sie sie im Einklang mit dem Register dahinter. Die Einstellungen für die Kundschaft, auf die diese Erklärung verweist, behandelt der Abschnitt zum Datenschutzcenter in unserem Leitfaden zu Datenschutz und Einwilligung.

Internationale Datenübermittlungen

Behandeln Sie Übermittlungen als rechtliche Prüfung, nicht als Blick auf die Landkarte. „Die Daten werden im Ausland gehostet“ ist keine Analyse. Prüfen Sie bei personenbezogenen Daten aus dem EWR oder dem Vereinigten Königreich, ob es sich um eine beschränkte internationale Übermittlung handelt und, falls ja, welcher aktuelle Mechanismus greift. Das kann ein Angemessenheitsbeschluss sein, Standardvertragsklauseln, das International Data Transfer Agreement (IDTA) des Vereinigten Königreichs oder dessen Addendum oder ein zertifizierter Rahmen wie das EU-US Data Privacy Framework. Seit Schrems II reicht ein Mechanismus allein unter Umständen nicht aus. Möglicherweise brauchen Sie zusätzlich eine Risikobewertung der Übermittlung.

Entscheidend ist der tatsächliche Datenfluss, nicht nur der Standort eines Servers: die Vertragsparteien, Fernzugriffe durch den Support aus anderen Ländern, Weiterübermittlungen und wer Datenexporteur und wer Datenimporteur ist. Dokumentieren Sie die Analyse pro Anbieter, und geben Sie den Mechanismus eines bestimmten Anbieters nicht als feststehend an, weil Anbieter ihre Vertragsgesellschaften, Regionen und Rahmenwerke ändern. Klären Sie den aktuellen Stand mit Ihrer Rechtsberatung.

AVVs und Verträge

Die zugeordnete Rolle bestimmt den Vertrag, den Sie brauchen. Ist ein Anbieter Ihr Auftragsverarbeiter, verlangt die DSGVO einen Auftragsverarbeitungsvertrag mit den Inhalten nach Artikel 28 (Verarbeitung nur auf Ihre Weisung, Vertraulichkeit, Sicherheit, Regeln für Unterauftragsverarbeiter, Löschung oder Rückgabe am Ende und Unterstützung bei Prüfungen). Ist ein Anbieter gemeinsam mit Ihnen verantwortlich, brauchen Sie eine Vereinbarung nach Artikel 26, die die Pflichten verteilt und deren Wesentliches den betroffenen Personen zur Verfügung steht. Ist ein Anbieter eigenständig verantwortlich, erteilen Sie ihm keine Weisungen. Ein Vertrag zur Auftragsverarbeitung ist dann das falsche Instrument, und Sie sollten stattdessen seine eigenen Bedingungen verstehen. Den Vertrag an die Rolle anzupassen gehört dazu, die Rolle richtig zu bestimmen.

SDK-Angaben prüfen, statt sich auf eine Funktionsliste zu verlassen

SDKs von Drittanbietern können Daten erheben, für die Sie verantwortlich sind. „Wir haben nur diese Funktionen aktiviert“ sagt Ihnen nicht, was Sie angeben müssen. Ein eingebettetes SDK kann sich automatisch initialisieren, Diagnosedaten erheben, Berechtigungen anfordern oder sein Verhalten mit einem Update ändern, auch wenn die für die Kundschaft sichtbare Funktion ausgeschaltet ist. Prüfen Sie, was die fertige App tatsächlich tut: SDK-Version und Konfiguration, Berechtigungen und APIs, Netzwerkaufrufe und Endpunkte sowie die Dokumentation des Anbieters.

Erfassen Sie die SDK-spezifischen Details im Register, denn darauf stützen sich die Formulare der Stores und der Bildschirm für die Einwilligung:

• Name und Anbieter des SDK sowie die Version
• Zuständigkeit auf Ihrer Seite
• Autostart und Standardverhalten (initialisiert es sich vor der Einwilligung?)
• Berechtigungen und API-Zugriffe, die es anfordert
• Daten, die das Gerät verlassen, und an welche Endpunkte
• Abhängigkeit von der Einwilligung (wartet es auf ein Einwilligungssignal?)
• Feature-Flag oder Konfiguration, die es steuert
• Zuordnung zu den Angaben bei Apple und Play für die Daten, die es verarbeitet

Zu Apples Privacy Manifests im Besonderen: Sie sind keine pauschale Regel im einfachen Sinn von „jedes SDK braucht ein Manifest“. Apple verlangt Privacy Manifests für die Nutzung bestimmter APIs, deren Verwendung begründet werden muss (Required-Reason-APIs), und für die Datenerhebung einer App, mit besonderen Anforderungen für eine Reihe häufig genutzter SDKs von Drittanbietern. Außerdem ersetzen Manifests nicht die korrekte Beantwortung der Datenschutzfragen im App Store. Weil ein zusätzliches SDK Ihre Angaben ändern und, wenn es unternehmensübergreifend trackt, eine ATT-Abfrage auslösen kann, gehören SDK-Inventar und Einwilligungsdesign in dasselbe Gespräch. Mehr dazu im Artikel App Tracking Transparency: Wann eine E-Commerce-App ATT braucht und wie Sie richtig fragen.

Apple und Google brauchen jeweils eine eigene Zuordnung der Store-Angaben

Gehen Sie nicht davon aus, dass ein einziges Register beide Stores automatisch befüllt, denn Apple und Google verwenden deutlich unterschiedliche Definitionen und Systematiken. Das Register liefert die Grundlage für die Store-Angaben, aber dazwischen liegt ein Zuordnungsschritt mit einer zuständigen Person und einer Freigabe:

• Apples Datenschutzangaben im App Store fragen nach Datentypen, dem Nutzungszweck, ob die Daten mit der Identität der Person verknüpft sind und ob sie für Tracking im Sinne von Apple genutzt werden.
• Der Abschnitt „Datensicherheit“ bei Google Play fragt nach Erhebung und Weitergabe nach Googles eigenen Definitionen, nach Zwecken, ob die Erhebung erforderlich oder optional ist, und nach Angaben zu Sicherheit und Löschung für die gesamte App. Google weist darauf hin, dass sich seine Systematik deutlich von der eines anderen Stores unterscheiden kann und dass die Angabe für das gesamte App-Paket gilt: Wenn eine beliebige verteilte Version oder Region Daten erhebt oder weitergibt, gehört das in der Regel in die Angabe.

Benennen Sie eine zuständige Person für die Zuordnung der Angaben. Testen Sie die Zuordnung am fertigen Build, und halten Sie sie mit dem Store-Eintrag abgestimmt. Dabei hilft unser Leitfaden So füllen Sie Ihren App-Store-Eintrag aus, ohne abgelehnt zu werden.

Aktuell halten, im richtigen Dokument

Jedes Dokument muss gepflegt werden. Aktualisieren Sie das Rollenregister der Anbieter, wenn Sie einen Anbieter hinzufügen, entfernen oder ändern, und passen Sie danach die betroffenen Dokumente an. Wenn Sie als Auftragsverarbeiter tätig sind, erfüllen Sie die Mitteilungspflicht mit Einspruchsmöglichkeit nach Artikel 28 gegenüber den Verantwortlichen. Wenn sich Praktiken ändern, die Verbraucher betreffen, aktualisieren Sie die Datenschutzerklärung und informieren Sie so, wie es das jeweilige Recht verlangt. Ein allgemeingültiges Recht von Verbrauchern auf Benachrichtigung über geänderte Unterauftragsverarbeiter gibt es nicht.

Checkliste zu Anbietern

Prüfen Sie vor der Veröffentlichung:

1. Ein Rollenregister der Anbieter für den gesamten Stack, einschließlich der Anbieter innerhalb von SDKs.
2. Eine geprüfte Rolle für jeden Anbieter, gemessen am tatsächlichen Datenfluss und Vertrag, wobei die Realität entscheidet (nicht die Bezeichnung).
3. Listen der Unterauftragsverarbeiter, die Sie von Ihren Auftragsverarbeitern erhalten, und die Sie nur dort selbst führen, wo Sie als Auftragsverarbeiter tätig sind.
4. Der passende Vertrag je Rolle: ein AVV nach Artikel 28 für Auftragsverarbeiter, eine Vereinbarung nach Artikel 26 für gemeinsam Verantwortliche und ein Verständnis der Bedingungen eigenständig Verantwortlicher.
5. Eine Analyse der Übermittlung je Anbieter für Daten aus dem EWR und dem Vereinigten Königreich, mit Mechanismus und Bewertung, wenn es sich um eine beschränkte Übermittlung handelt.
6. Eine Prüfung der SDKs im fertigen Build, mit ausgefüllten SDK-spezifischen Feldern im Register.
7. Eine Zuordnung der Store-Angaben für Apple und Google, mit zuständiger Person und Freigabe.
8. Eine Datenschutzerklärung, die Empfänger oder Kategorien, Rechte und Übermittlungen offenlegt und zum Register passt.
9. Ein Änderungsprozess, der das richtige Dokument für die richtige Zielgruppe aktualisiert.

Wie NAPPS hilft

NAPPS ist einer der Anbieter in diesem Bild. NAPPS kann seine eigene Rolle und seine Dienste dokumentieren, aber keine rechtlichen Entscheidungen für Sie treffen.

Zur Orientierung zuerst die Rolle: Wenn Sie der Verantwortliche sind und NAPPS direkt mit der Verarbeitung der Kundendaten Ihrer App beauftragen, wäre NAPPS in der Regel Ihr Auftragsverarbeiter. Unterauftragsverarbeiter ist NAPPS nur innerhalb einer entsprechenden Kette, in der ein anderer Auftragsverarbeiter NAPPS beauftragt. Was davon auf Sie zutrifft, gehört in Ihre Prüfung und in den Vertrag, nicht in eine pauschale Einordnung. Zwei Dinge sollten Sie bei NAPPS anfordern und anhand aktueller, öffentlicher Unterlagen prüfen, statt sie ungeprüft zu übernehmen: einen Auftragsverarbeitungsvertrag und die eigene Liste der Unterauftragsverarbeiter für die Infrastruktur hinter der App. Diese Liste deckt die Infrastruktur von NAPPS ab, nicht Ihre Anbieter für Analyse, Werbung, Support und anderes. Und die SDK-Disziplin von oben gilt auch hier: Was Sie angeben, richtet sich danach, was die fertige App tatsächlich tut, einschließlich allem, was sich automatisch initialisiert, und nicht nur nach den Funktionen, die Sie aktiviert haben. Was NAPPS nicht tut: die Rolle eines Anbieters festlegen, Übermittlungsmechanismen auswählen oder Ihre Datenschutzerklärung schreiben. Wie das Register mit der Löschung zusammenhängt, erklärt unser Leitfaden zu Aufbewahrung und Löschung. Das Gesamtbild der Veröffentlichung beschreibt unser Leitfaden So machen Sie aus Ihrem Shopify-Shop eine mobile App (2026).

Direkt aus der Quelle

Diese Vorgaben ändern sich, prüfen Sie daher die aktuellen Fassungen:

• Europa: der Text der DSGVO (Auftragsverarbeiter und AVVs nach Artikel 28, gemeinsam Verantwortliche nach Artikel 26, Übermittlungen nach Kapitel V) sowie die Leitlinien des EDSA zu Standardvertragsklauseln und zur Bewertung von Übermittlungen.
• Apple: die Anforderungen an die Datenschutzangaben (App privacy details) sowie die Regeln zu Privacy Manifests und Required-Reason-APIs für Apps und die aufgeführten SDKs von Drittanbietern.
• Google: die Anforderungen an den Abschnitt „Datensicherheit“ bei Google Play.

Das Fazit

Legen Sie ein Rollenregister der Anbieter für den gesamten Stack an. Bewerten Sie jeden Anbieter danach, was er tatsächlich tut, nicht danach, wie sein Vertrag ihn nennt. Halten Sie Listen der Unterauftragsverarbeiter, Datenschutzerklärung und Zuordnung der Store-Angaben getrennt. Analysieren Sie dann die Übermittlungen, passen Sie die Verträge an die Rollen an, prüfen Sie die SDKs der fertigen App, und aktualisieren Sie das richtige Dokument, wenn sich etwas ändert. So erhalten Sie eine brauchbare Übersicht Ihrer Anbieter statt einer bloßen Sammlung von Logos.

Wenn Sie eine Shopify-App planen und SDK-Angaben, Datenschutzangaben in den Stores und die Dokumentation Ihrer Anbieter von Anfang an sauber regeln möchten, buchen Sie ein 20-minütiges Gespräch mit dem NAPPS-Team, und wir zeigen Ihnen, wie das in einer nativen App zusammenspielt, bevor Sie mit der Entwicklung beginnen.