DSGVO bei der App-Entwicklung

DSGVO bei der App-Entwicklung beginnt nicht beim Login-Flow — sie beginnt bei der Architektur-Entscheidung. „Privacy by Design” steht in DSGVO Art. 25 wörtlich drin: Datenschutz muss schon „bei der Festlegung der Mittel für die Verarbeitung” eingebaut werden. Wer das auf die Zeit nach dem Build verschiebt, landet bei nachträglichen Umbauten — die teuer sind und oft nicht sauber gehen. Dieser Guide ordnet ein, was du vor dem ersten Commit entscheiden musst, ohne anwaltliche Themen zu ersetzen.

Was Privacy by Design konkret heißt

Drei DSGVO-Artikel sind im Build-Kontext zentral:

• Art. 25 — Datenschutz durch Technikgestaltung. Verpflichtung, geeignete Maßnahmen schon in der Architektur zu treffen, nicht erst im Betrieb.
• Art. 32 — Sicherheit der Verarbeitung. „Stand der Technik” — die App muss dem aktuellen Stand entsprechen, nicht dem von vor zwei Jahren. Der Begriff wird vom BSI im IT-Grundschutz operationalisiert.
• Art. 28 — Auftragsverarbeitung. Jede:r externe Dienstleister, der für dich Daten verarbeitet, braucht einen Auftragsverarbeitungsvertrag. Auch wenn er „nur” Hosting macht.

Konkret heißt das im Build: Datenminimierung als Default, Hosting-Region als bewusste Wahl, SDK-Auswahl als Compliance-Frage, dokumentierte Datenflüsse als Pflicht.

Drei Architektur-Entscheidungen mit DSGVO-Folgen

In der Spec-Phase fallen drei Entscheidungen, die später nicht mehr leicht rückgängig zu machen sind.

1. Hosting-Region

EU-Hosting ist nicht nur eine Vorliebe — es ist in vielen Branchen die einzige saubere Option. US-Hosting funktioniert technisch, schiebt aber das Problem Schrems-II und mögliche Aufsichts-Beanstandungen ins Projekt. Die EU-Kommission hat mit dem EU-US Data Privacy Framework einen Rahmen geschaffen — der ist nicht selbstverständlich stabil, und einige Branchen (Gesundheit, öffentlicher Sektor, Banking) akzeptieren ihn ohnehin nicht.

Default für DACH-Apps: EU-Hosting (idealerweise Deutschland), entweder bei einem deutschen Cloud-Anbieter (Hetzner, IONOS) oder bei einem Hyperscaler in einer EU-Region (AWS Frankfurt, Azure Germany, Google Cloud Frankfurt). Der Aufpreis gegenüber US-Hosting ist im niedrigen einstelligen Bereich pro Monat — der Compliance-Vorteil ist dagegen massiv.

2. SDK-Auswahl

Jedes SDK, das du einbaust, ist ein Datenschutz-Vertrag. Analytics, Crash-Reporting, Push, Maps, Auth — alle senden Daten. Drei Fragen pro SDK vor dem Einbau:

• Was sendet es? Geräte-IDs, IP-Adressen, Session-Daten, personenbezogene Identifier.
• Wohin? Hosting-Region des Anbieters. Drittland → Schrems-II-Frage.
• Auftragsverarbeitungsvertrag verfügbar? Wenn der Anbieter keinen Standard-AVV bietet, ist es im Zweifel kein produktiv einsetzbares SDK.

In der Praxis schließt das Google Analytics in der Standard-Konfiguration, einige US-zentrische Crashlogging-Tools und manche Push-Provider von vornherein aus — oder erlaubt sie nur in einer EU-konformen Variante. Apple verlangt zudem seit Frühjahr 2024 ein Privacy-Manifest für SDKs, die personenbezogene Daten verarbeiten — wenn ein SDK kein gepflegtes Manifest liefert, fliegt die App im Review.

3. Datenfluss und -minimierung

DSGVO-Datenminimierung heißt: erhebe nur, was du brauchst, speichere nur, was du brauchst, lösche, was nicht mehr nötig ist. Drei typische Architektur-Entscheidungen:

• Anonyme statt namentliche IDs, wenn der Use-Case sie zulässt.
• Lokale Verarbeitung statt Server-Roundtrip, wenn möglich (Bildbearbeitung, Sensor-Daten).
• Lösch-Routinen ab Tag 1, nicht später nachgerüstet. Welcher Datensatz wird wann automatisch gelöscht?

Was nicht im Code minimiert ist, wird im Betrieb zur Belastung — und ist im Schadensfall der Punkt, an dem ein Aufsichts-Verfahren teuer wird.

Auftragsverarbeitungsverträge schon vor dem ersten Commit

Im Spec werden externe Dienste festgelegt: Hosting, Push, Auth, Payments, Analytics. Mit allen, die personenbezogene Daten verarbeiten, brauchst du einen Auftragsverarbeitungsvertrag — vor dem ersten Commit, nicht nach dem Launch.

Der typische Stack einer App hat fünf bis zehn solcher Verträge. Die häufigsten Kategorien:

• Hosting (AWS, Azure, GCP, Hetzner, IONOS) — Standard-AVV, meist online verfügbar.
• Auth (Auth0, Clerk, Firebase Auth, Supabase) — meist Standard-AVV.
• Push (Firebase, Apple Push, OneSignal) — bei einigen US-Anbietern Schrems-II-relevant.
• Crash-Reporting und Analytics (Sentry, Plausible, Matomo, GA4, Crashlytics) — Sentry, Plausible und Matomo bieten EU-Hosting an, andere brauchen Aufwand.
• Payments (Stripe, Adyen, Mollie) — branchenspezifisch.

Eine App ohne dokumentierte AVV-Kette ist eine App, die in jeder Aufsichts-Anfrage ins Wanken gerät — und der Bau einer solchen Kette nach dem Launch ist deutlich teurer als ihre Anlage in der Spec-Phase.

Privacy-Manifest und Data-Safety-Form

Was Apple und Google verlangen, ist nicht „nice to have” — es ist Submission-Pflicht.

• Apple Privacy Manifest. Pflicht seit Frühjahr 2024. Maschinenlesbare Beschreibung, welche Daten die App und alle eingebauten SDKs erheben und wozu. SDKs ohne Manifest sind kein produktiver Einbau mehr.
• Google Data-Safety-Form. Pflicht für jede Play-Submission. Manuell ausgefülltes Formular im Play Console, das die Datennutzung deklariert. Muss zur tatsächlichen Datennutzung konsistent sein — Inkonsistenz ist Reject-Grund und im Wiederholungsfall Account-Risiko.

Beide Pflichten klemmen reproduzierbar an Apps, die das erst am Submission-Tag prüfen. In der Spec-Phase entsteht eine Tabelle: welches Datum, welcher SDK, welcher Zweck, welche Speicherdauer. Diese Tabelle ist Grundlage für Privacy-Manifest, Data-Safety-Form und Datenschutzerklärung — drei Dokumente aus einer Quelle.

Dokumentations-Pflichten ab Build-Start

DSGVO verlangt nicht nur Maßnahmen — sie verlangt Nachweise. Was im Build entsteht, ist nicht Tech-Doku, sondern Compliance-Doku:

• Verarbeitungsverzeichnis (Art. 30) — was die App mit welchen Daten macht. Wird im Spec angelegt, im Build gepflegt, im Betrieb fortgeschrieben.
• Datenschutz-Folgenabschätzung (Art. 35), wenn die App in eine der „hochriskanten” Kategorien fällt: große Mengen personenbezogener Daten, sensible Datenarten (Gesundheit, biometrische, finanzielle Daten), systematisches Monitoring. Die Datenschutzkonferenz veröffentlicht Listen, wann eine DPIA Pflicht ist.
• Technische und organisatorische Maßnahmen (TOM) — dokumentierte Sicherheits-Architektur. Das ist das, was du im Schadensfall vorlegst, um „geeignete Maßnahmen” nachzuweisen.

Was nicht im Build dokumentiert ist, lässt sich nachträglich nur mühsam rekonstruieren — und ist im Aufsichts-Verfahren der Punkt, an dem die Beweislast kippt.

Was nicht in der Verantwortung des Entwicklungsteams liegt

Klare Trennung, damit niemand sich auf falsche Erwartungen verlässt:

• Datenschutzkonzept und -strategie. Gehört zur Datenschutzbeauftragten oder zum eigenen Compliance-Team.
• Verträge mit Endkunden. Einwilligungstexte, AGBs, Datenschutzerklärungen für eure Nutzer:innen — wir liefern die technische Faktenlage, die rechtliche Formulierung passiert anwaltlich.
• Aufsichtskommunikation. Beanstandungen und Rückfragen einer Aufsichtsbehörde gehen nicht über das Entwicklungsteam.
• Branchen-spezifische Regulierung. MDR (Medizinprodukte), BaFin (Banking), KRITIS (kritische Infrastruktur) — eigene Doku- und Audit-Pflichten, die zusätzlich zur DSGVO laufen.

Wenn ihr in einer regulierten Branche arbeitet und keine Datenschutzbeauftragte habt, organisiert das vor dem Spec-Start — nicht erst, wenn Apple oder Google die App rejected.

DSGVO-Checkliste für die Konzeption

Sieben Punkte, die in der Spec-Phase geklärt sein müssen:

• Hosting-Region ist entschieden, alle Komponenten laufen entweder in der EU oder mit dokumentiertem Schrems-II-tragfähigem Pfad.
• Jedes geplante SDK hat einen Standard-AVV und ein gepflegtes Privacy-Manifest (Apple).
• Datenmodell minimiert: pro Entität ist klar, welche Felder zwingend personenbezogen sind, welche nicht.
• Lösch-Routinen pro Datensatz-Typ sind definiert.
• Verarbeitungsverzeichnis ist als lebendes Dokument angelegt.
• DPIA-Pflicht ist geprüft; falls notwendig, läuft sie parallel zum Build.
• Datenschutzerklärung ist im Konzept skizziert — nicht erst am Submission-Tag.

Mehr als zwei offen? Dann ist der Build-Start verfrüht. Schreib uns die Eckdaten über das Kontaktformular, wir gehen den Stand mit dir durch und sagen ehrlich, ob die Spec tragfähig ist oder ob ein Vor-Sprint nötig ist. Antwort in 24 Stunden.

Was nach dem Launch in DSGVO-Sicht weiterläuft, steht im Sub-Guide DSGVO-Wartungspflichten für Apps. Mehr Kontext: Wie läuft eine App-Entwicklung ab? für die Phasen-Logik, in der diese Entscheidungen fallen.