Damit der Rahmen klar ist: Dieser Artikel ist keine Rechtsberatung und kann keine sein. Er ist allgemeine Orientierung aus der Entwicklungspraxis. Ob eine Verarbeitung in deinem Fall zulässig ist und was in deiner Datenschutzerklärung stehen muss, beurteilen Anwältin oder Anwalt bzw. dein Datenschutzbeauftragter, nicht dieser Text.
In Apps für Praxen, Kanzleien oder Handwerksbetriebe landen schnell schutzbedürftige Daten: Terminwünsche, Gesundheitsangaben, Mandatsdetails, Auftragsfotos. Beherrschbar ist das, weil vieles früh entschieden wird – und früh ist es günstig.
Datensparsamkeit ist eine Design-Entscheidung
Die wirksamste Maßnahme kostet nichts: Bei Daten, die du nicht erhebst, gibt es nichts zu schützen und nichts zu löschen.
Deshalb gehen wir im Konzept jedes Formular Feld für Feld durch: Wofür brauchen wir dieses Feld? Wie lange? Und was passiert, wenn es fehlt? Oft lautet die Antwort „nichts“. Typische Ergebnisse: Telefonnummer optional statt Pflicht, Kundennummer statt Klarname, Standort grob statt exakt, Fotos ohne Metadaten.
Jedes Feld weniger ist ein Risiko weniger – derselbe Reflex wie beim MVP-Schnitt, siehe „Weniger App, mehr Erfolg“. Und die radikalste Variante lohnt eine ernsthafte Prüfung, bevor ein Server gesetzt wird: Bleiben Daten ausschließlich auf dem Gerät, fällt ein ganzer Block an Fragen weg.
Server-Standort und Auftragsverarbeitung
Sobald ein Server im Spiel ist, wird der Anbieter Teil deiner Verarbeitung. Drei Punkte gehören geklärt:
- Region beim Anlegen wählen. Manche Dienste legen die Region beim Erstellen des Projekts fest und lassen sie danach nicht mehr ändern – dann hilft nur ein Umzug. Auch gilt eine gewählte Region nicht automatisch für jeden Dienstbestandteil.
- Auftragsverarbeitungsvertrag (AVV). Frag den Anbieter aktiv danach, samt Liste der Unterauftragnehmer und Angaben zu Lösch- und Backup-Fristen – das ist die Faktenbasis, die dein Anwalt oder Datenschutzbeauftragter für die Bewertung braucht.
- Verarbeitung außerhalb der EU. Ob das für dich in Frage kommt, bewerten Anwalt oder Datenschutzbeauftragter. Was wir liefern, ist Transparenz: welcher Dienst verarbeitet welche Daten wo.
Der Knackpunkt: Tracking- und Analytics-SDKs
Aus unserer Erfahrung liegt der heikle Teil selten in der Kernfunktion, sondern in dem, was nebenbei mitläuft. Ein einziges eingebundenes SDK kann beim App-Start Geräte-Kennungen, IP-Adresse und Nutzungsereignisse an einen Dienst senden, ohne dass im Interface etwas davon sichtbar ist. Ob und ab welchem Moment eine Bibliothek Daten überträgt, steht in ihrer Dokumentation – das gehört vor dem Einbau gelesen, nicht danach.
Solche Werkzeuge sind nicht per se falsch, nur manchmal mehr, als ein Projekt braucht. Und es geht ohne: Unsere eigene Website läuft bewusst ohne Tracking und ohne Cookie-Banner, nachprüfbar im Netzwerk-Tab deines Browsers.
Für Apps heißt das:
- Erst gar nichts einbauen. Apple stellt in App Store Connect Analytics zu Downloads, Nutzung und Absturzrate bereit, Google Play App-Statistiken und die Android-Vitals – letztere kommen aus dem System und brauchen kein zusätzliches SDK (Stand 2026). Für viele Betreiber reicht das.
- Eigene Zählung ohne Personenbezug. Ein serverseitiger Zähler pro Ereignis zeigt, welche Funktion genutzt wird – ohne Kennung, ohne Profil.
- Wenn es doch ein SDK sein soll, heißt Einwilligung technisch: erst nach der Zustimmung initialisieren, nicht beim Start laden und hinterher „abschalten“. Ein Ablehnen, das genauso leicht erreichbar ist wie ein Zustimmen, kostet keinen Mehraufwand. Für App-übergreifendes Tracking verlangt Apple zusätzlich die ausdrückliche Erlaubnis über die App-Tracking-Transparency-APIs (Stand 2026).
Welche Einwilligung dein Fall braucht, klärt dein Anwalt oder Datenschutzbeauftragter. Wir bauen den Schalter, der wirklich schaltet.
Berechtigungen sparsam und im richtigen Moment
An den Berechtigungsdialogen entscheidet sich, ob eine App vertrauenswürdig wirkt. Bewährt hat sich: nur anfragen, was eine Funktion wirklich braucht – im Moment des Bedarfs statt als Begrüßungssalve beim ersten Start. Apple verlangt für die Systemdialoge ohnehin Begründungstexte, die den Verwendungszweck klar und vollständig beschreiben (Stand 2026). Praktisch: Kamera erst beim Foto-Upload, Standort „während der Nutzung“ statt „immer“. Und die App sollte benutzbar bleiben, wenn jemand ablehnt.
Verschlüsselung: unterwegs und auf dem Gerät
- Transport: TLS für jede Verbindung; abgeschaltete Zertifikatsprüfungen aus der Debug-Phase gehören vor dem Release raus.
- Auf dem Gerät: Zugangstoken in Keychain (iOS) bzw. Keystore (Android), nicht in einfache Einstellungsdateien. Liegen sensible Inhalte lokal, wird die Datenbank verschlüsselt.
- Logs und Crash-Reports: Hier rutschen personenbezogene Inhalte leicht durch – lieber Kennungen loggen als Inhalte.
- Serverseitig: Zugriffsregeln pro Rolle statt „die App darf alles“ – sonst genügt ein manipulierter Client.
Löschen und Auskunft technisch vorsehen
Nutzerrechte sind ein Feature, keine Absichtserklärung. Zwei Pfade gehören von Anfang an dazu.
Auskunft und Export: alle Daten zu einer Person zusammenziehen – als Funktion oder mindestens als dokumentiertes Skript.
Löschung über alle Orte: nicht nur den Haupt-Datensatz, auch Verknüpfungen, Dateien im Storage, Push-Token, Suchindizes, Logs und Backups. Daran scheitern nachträgliche Umbauten, wenn das Datenmodell die Kaskade nicht vorsah. Welche Aufbewahrungsfristen gelten, sagt dein Anwalt oder Datenschutzbeauftragter; wir setzen sie automatisiert durch.
Dazu eine Store-Anforderung, die direkt am Datenmodell hängt: Erlaubt deine App das Anlegen von Konten, verlangt Apple eine Kontolöschung in der App. Google Play verlangt zusätzlich einen Web-Link, über den Nutzer die Löschung von Konto und zugehörigen Daten anfordern können – gedacht für alle, die die App längst deinstalliert haben (Stand 2026). Nachträglich wird das teurer als beim Entwurf des Datenmodells.
Pflichtangaben im Store
Beide Stores verlangen einen erreichbaren Link auf eine Datenschutzerklärung – im Store-Eintrag und zusätzlich aus der App heraus; bei Google Play ausdrücklich auch für Apps, die keine personenbezogenen Daten verarbeiten (Stand 2026). Dazu fragen beide strukturiert ab, welche Datenarten die App erhebt und wozu: bei Apple über die App-Datenschutz-Angaben, bei Google Play über das Data-Safety-Formular (Stand 2026). Apple bezieht dabei ausdrücklich die Daten mit ein, die eingebundene Bibliotheken Dritter erheben – auch deshalb ist die SDK-Liste kein Nebenthema. Den Text der Erklärung schreibt dein Anwalt oder Datenschutzbeauftragter – wir liefern die Faktenbasis. Ob ein Angebot das erwähnt, ist ein gutes Vergleichskriterium › Woran du ein seriöses App-Angebot erkennst.
Testdaten statt Echtdaten in der Entwicklung
Eine Frage, die sich lohnt: Womit wird eigentlich entwickelt und getestet? Produktionsdaten auf Entwicklerrechnern, in Testumgebungen oder in Screenshots an Tickets erzeugen Kopien, an die später niemand mehr denkt. Praktikabel ist: generierte Testdaten über Seed-Skripte, getrennte Umgebungen mit eigenen Zugängen, Fehlerberichte ohne Echtdaten. Wo Echtdaten unvermeidbar sind – etwa bei einer Migration –, einmalig, dokumentiert, mit Löschung danach und in Absprache mit deinem Datenschutzbeauftragten.
Was in ein Projekt gehört
- Datenfeld-Liste im Konzept: jedes Feld mit Zweck und Aufbewahrungsdauer – gut vorzubereiten mit „So bereitest du dein App-Projekt vor“.
- Region und AVV vor der ersten Zeile Code, Löschung und Export als gebaute Funktion.
- Danach weiterpflegen: Store-Anforderungen und SDK-Versionen ändern sich – das gehört in die laufende Wartung und Pflege, nicht nur in die Abnahme.
Fazit
Datenschutz in Apps ist kein Kapitel am Projektende, sondern eine Handvoll früher Entscheidungen: weniger Felder, geklärte Region, keine unnötigen SDKs, Löschpfade ab Tag eins. Die rechtliche Bewertung bleibt bei Anwalt oder Datenschutzbeauftragtem – die technische Seite bringen wir mit.
Im kostenlosen Erstgespräch gehen wir gern durch, welche Daten deine App wirklich braucht – und welche du dir sparen kannst. Antwort werktags innerhalb von 24 Stunden.