Datenschutz & Datensicherheit
Ob und wohin Daten technisch übertragen werden, lässt sich nicht allein aus einer Datenschutzerklärung oder Systembeschreibung ableiten. Reale Datenflüsse entstehen durch Frontends, APIs, SDKs, Hintergrundjobs, Cloud-Dienste und administrative Exporte. Eine technische Rekonstruktion verbindet Konfiguration, Netzwerk- und Anwendungsnachweise mit dem konkreten Systemstand.
Kurzantwort
Untersucht werden Sender, Empfänger, Endpunkt, Protokoll, Datenkategorien, Auslöser und zeitlicher Bezug einer Übermittlung. Dabei wird strikt zwischen technisch nachgewiesenem Datenfluss und rechtlicher Bewertung der Zulässigkeit unterschieden.
Vom Prüfgegenstand zur dokumentierten technischen Schlussfolgerung
1. Dokumentierte und reale Datenflüsse gegenüberstellen
Architektur- und Datenschutzdokumentation kann erwartete Datenflüsse beschreiben. Für den technischen Befund wird zusätzlich geprüft, welche Verbindungen und Requests im untersuchten System tatsächlich auftreten.
Abweichungen können durch neue SDKs, Feature Flags, alte Endpunkte oder dynamische Konfiguration entstehen. Sie werden zunächst als technische Differenz dokumentiert, ohne ihre rechtliche Bedeutung vorwegzunehmen.
2. Schnittstellen und Empfänger eindeutig identifizieren
Hostnamen, URLs, API-Gateways, DNS-Auflösung, Zertifikate und Cloud-Ressourcen können helfen, technische Empfänger zu identifizieren. Bei CDNs, Proxys oder Multi-Tenant-Diensten ist die tatsächliche Infrastruktur jedoch nicht immer direkt aus dem sichtbaren Endpunkt ableitbar.
Die Untersuchung unterscheidet daher zwischen adressiertem Dienst, beobachtetem Netzwerkziel und organisatorischem Empfänger. Nur die technisch belegte Ebene wird als Befund formuliert.
3. Payloads und Datenkategorien untersuchen
Request-Bodies, Query-Parameter, Header, Eventdaten oder Telemetrie können personenbezogene oder anderweitig relevante Informationen enthalten. Bei verschlüsseltem Transport kann eine Untersuchung auf Anwendungs-, Proxy- oder Serverseite erforderlich sein, sofern dies zulässig und im Prüfauftrag vorgesehen ist.
Es wird dokumentiert, welche Felder tatsächlich beobachtet wurden und welche nur aus Schema oder Dokumentation erwartet werden. Hashes, pseudonyme Kennungen und Tokens werden nicht pauschal als anonym behandelt, sondern technisch nach ihrer Verknüpfbarkeit und Funktion beschrieben.
4. Auslöser und zeitlichen Kontext rekonstruieren
Viele Übermittlungen erfolgen nur unter bestimmten Bedingungen: Einwilligungsstatus, Nutzeraktion, Hintergrundjob, Fehlerfall oder Administratorzugriff. Reproduzierbare Tests müssen diese Auslöser und den jeweiligen Systemzustand dokumentieren.
Bei historischen Fragestellungen können aktuelle Tests nur eingeschränkt auf frühere Versionen übertragen werden. Alte App-Builds, Konfigurationsstände, Logs oder Deployments können erforderlich sein, um den damaligen Datenfluss zu rekonstruieren.
5. API-Risiken und technische Schutzmaßnahmen einordnen
Authentisierung, Autorisierung, Datenfilterung und Endpoint-Inventar beeinflussen, welche Daten über Schnittstellen zugänglich oder übertragbar sind. OWASP API Security nennt unter anderem objektbezogene Autorisierung und unsicheren API-Konsum als relevante Risikofelder.
Die Begutachtung prüft solche Mechanismen nur soweit sie zur Fragestellung gehören. Ein Sicherheitsrisiko ist nicht automatisch gleichbedeutend mit einer nachgewiesenen unzulässigen Datenübermittlung.
6. Technischen Befund von Transferrecht trennen
Die DSGVO enthält unter anderem Vorgaben zu Datenminimierung und Übermittlungen in Drittländer. Die technische Untersuchung kann feststellen, welche Daten wohin übertragen werden und welche Schutzmechanismen beobachtet wurden.
Ob eine konkrete Übermittlung rechtlich zulässig ist, welche Rechtsgrundlage trägt oder welche Garantien erforderlich sind, bleibt eine rechtliche Bewertung. Der technische Bericht liefert dafür belastbare Tatsachengrundlagen, ersetzt sie aber nicht.
Bei Cloud- und SaaS-Diensten kann die sichtbare API-Adresse von den tatsächlich beteiligten Unterdiensten abweichen. DNS, CDN, Queueing, Object Storage und Telemetrie können zusätzliche technische Verarbeitungspfade erzeugen. Solche Pfade werden nur dann in den Befund aufgenommen, wenn sie durch Konfiguration, Logs oder reproduzierbare Beobachtung ausreichend belegt sind.
Bei verschlüsselten Verbindungen sollte außerdem dokumentiert werden, an welcher Stelle Payload-Inhalte untersucht wurden. Ein Browser- oder App-seitiger Mitschnitt, Serverlogs und Proxy-Telemetrie besitzen unterschiedliche Sicht auf verschlüsselte und transformierte Daten. Diese Perspektive beeinflusst, welche Felder tatsächlich nachgewiesen werden können.
Für wiederkehrende Hintergrundübermittlungen können Scheduler, Queue-Logs oder Cloud-Event-Historien zusätzliche Evidenz liefern. Sie zeigen häufig zuverlässiger als ein einzelner manueller Test, ob ein Datenfluss periodisch, ereignisgesteuert oder nur in Ausnahmefällen ausgelöst wird. Die Begutachtung dokumentiert dabei, ob Logs vollständig, sampling-basiert oder rotationsbedingt lückenhaft sind.
Beweist ein Netzwerk-Request bereits eine personenbezogene Datenübermittlung?
Nicht zwingend. Zunächst ist zu untersuchen, welche Nutzdaten, Kennungen und Metadaten der Request tatsächlich enthält.
Auch scheinbar technische Identifikatoren können je nach Systemkontext verknüpfbar sein; ihre rechtliche Einordnung wird davon getrennt behandelt.
Der technische Befund sollte deshalb konkrete Felder und Übertragungswege dokumentieren statt pauschale Kategorien zu behaupten.
Ist die Untersuchung für diesen Themenbereich nachvollziehbar abgegrenzt?
- Sind alle für die Fragestellung relevanten Schnittstellen und externen Dienste inventarisiert?
- Sind beobachtete Endpunkte und Systemstände reproduzierbar dokumentiert?
- Sind tatsächlich übertragene Felder von nur dokumentierten oder erwarteten Feldern getrennt?
- Sind Auslöser wie Consent-Status, Nutzeraktion oder Hintergrundprozess erfasst?
- Sind Authentisierung, Autorisierung und Datenfilterung soweit relevant technisch geprüft?
- Ist bei historischen Aussagen der damalige Software- und Konfigurationsstand berücksichtigt?
- Bleiben technische Feststellung und rechtliche Transferbewertung ausdrücklich getrennt?
Konstruiertes Beispiel
Eine mobile App bindet ein Analyse-SDK ein. Im aktuellen Test sendet es nur eine pseudonyme Gerätekennung, während eine ältere Konfigurationsdatei zusätzliche Profilfelder vorsieht. Der technische Bericht trennt beobachteten aktuellen Datenfluss, dokumentierte historische Möglichkeit und offene Rechtsbewertung.
Das Beispiel ist konstruiert und beschreibt kein reales Mandat.
Quellen und fachliche Grundlage
- Amtliche Rechtsquelle DSGVO, insbesondere Artikel 44 zu Übermittlungen personenbezogener Daten in Drittländer oder an internationale Organisationen. Quelle öffnen.
- Technische Sicherheitsreferenz OWASP API Security Top 10 2023 zu typischen API-Sicherheitsrisiken. Quelle öffnen.
- NIST-Rahmenwerk NIST Privacy Framework als freiwilliger Rahmen für Privacy Risk Management. Quelle öffnen.
- Eigene Methodik Quellen und Methodik der Wissensplattform. Quelle öffnen.
Weiterführende Beiträge
- Datenflüsse technisch rekonstruieren
- Technische und organisatorische Maßnahmen prüfen
- Alle Beiträge in diesem Themenbereich
Eigene Fachliteratur und Veröffentlichungen
Die folgenden eigenen Arbeiten dienen der fachlichen Vertiefung und methodischen Einordnung. Sie ersetzen keine erforderlichen Primär-, Norm-, Hersteller- oder sonstigen unabhängigen Fachquellen. Unveröffentlichte Manuskripte, Entwürfe und Lehrunterlagen werden hier bewusst nicht als öffentliche Quellen ausgewiesen.
Technische Untersuchung zum Themenbereich Datenschutz & Datensicherheit
Die konkrete Aussagekraft hängt vom Untersuchungsgegenstand, der verfügbaren Evidenz und der dokumentierten Prüfmethode ab.
IT-Compliance