DSGVO-Datenmapping-Diagramm: personenbezogene Datenflüsse über alle Systeme hinweg abbilden

Frag ein Datenschutzteam, wo personenbezogene Daten liegen, und du bekommst eine Tabelle. Frag das Engineering, und du bekommst ein Architekturdiagramm, in dem personenbezogene Daten gar nicht vorkommen. Beides ist unvollständig: Die Tabelle kann nicht zeigen, wie Daten fließen, und das Architekturdiagramm sagt nicht, was fließt oder warum.

Ein DSGVO-Datenmapping-Diagramm ist der Ort, an dem beides zusammenkommt. Dieser Guide zeigt, was eine Data Map erfassen muss, eine Methode, um sie aufzubauen, und eine ausgearbeitete Map für ein typisches SaaS-Produkt. Er ist keine Rechtsberatung; über Rechtsgrundlagen, Übermittlungsmechanismen und Speicherfristen entscheiden die Datenschutzverantwortlichen oder die Rechtsberatung in deinem Unternehmen.

Data Map und Verzeichnis von Verarbeitungstätigkeiten

Artikel 30 der DSGVO verpflichtet jeden Verantwortlichen, ein Verzeichnis von Verarbeitungstätigkeiten zu führen, das Folgendes enthält:

• den Namen und die Kontaktdaten des Verantwortlichen und gegebenenfalls seines Vertreters und Datenschutzbeauftragten;
• die Zwecke der Verarbeitung;
• die Kategorien betroffener Personen und personenbezogener Daten;
• die Kategorien von Empfängern, einschließlich Empfängern in Drittländern;
• Übermittlungen in Drittländer und, für manche, die Dokumentation geeigneter Garantien;
• wenn möglich, die Fristen für die Löschung;
• wenn möglich, eine allgemeine Beschreibung der Sicherheitsmaßnahmen.

Auftragsverarbeiter führen ein ähnliches Verzeichnis über die Verarbeitung, die sie für jeden Verantwortlichen durchführen. Artikel 30 Absatz 5 nimmt Organisationen mit weniger als 250 Beschäftigten aus, aber nur, wenn die Verarbeitung voraussichtlich kein Risiko für die Rechte der betroffenen Personen birgt, nur gelegentlich erfolgt und weder besondere Kategorien von Daten noch Daten über strafrechtliche Verurteilungen umfasst. Ein SaaS-Unternehmen, das jeden Tag Kundendaten verarbeitet, fällt selten darunter. Der EU-Gesetzgeber hat über eine Anhebung dieser Schwelle beraten, also prüf den aktuellen Text, bevor du dich darauf verlässt.

Das Verzeichnis ist eine Tabelle. Die Data Map ist der Weg, herauszufinden, was in diese Tabelle gehört, und später zu prüfen, ob es noch stimmt.

Was du für jeden Fluss erfassen solltest

Eine Methode, die funktioniert

1. Inventarisiere die Systeme. Fang mit dem an, was du auflisten kannst: Cloud-Konten, Datenbanken, SaaS-Tools aus dem Single Sign-on und aus den Lieferantenzahlungen der Finanzabteilung. Dort tauchen Schatten-Tools auf.
2. Folge jeweils einer User Journey. Registrierung, Abrechnung, tägliche Produktnutzung, ein Support-Ticket, eine Marketing-E-Mail. Zeichne, wo die Daten hineinkommen, wo sie gespeichert werden und wohin sie als Nächstes gehen.
3. Frag die System-Owner. Für jedes System: welche Felder, wofür, wer sie erhält und wie lange sie bleiben.
4. Markiere Auftragsverarbeiter und Übermittlungen. Notiere, wo jeder Anbieter Daten verarbeitet, ob ein Auftragsverarbeitungsvertrag vorliegt und welche Garantie eine Übermittlung außerhalb des EWR abdeckt.
5. Ergänze Speicherdauer und Löschung. Ein Speicher ohne Speicherfrist ist ein Befund.
6. Prüf die Map mit dem Datenschutzteam und leite das Verzeichnis nach Artikel 30 aus ihr ab.

Übermittlungen außerhalb des EWR

Kapitel V der DSGVO, also die Artikel 44 bis 49, erlaubt Übermittlungen in Drittländer nur auf bestimmten Grundlagen. Die üblichen für ein SaaS-Unternehmen:

• Ein Angemessenheitsbeschluss. Die Europäische Kommission listet die Länder auf, deren Schutzniveau sie als angemessen ansieht. Für die USA gilt der Beschluss vom Juli 2023 für Unternehmen, die am EU-US Data Privacy Framework (DPF) teilnehmen. Das Gericht der EU hat ihn im September 2025 bestätigt, und im Oktober 2025 wurde dagegen Rechtsmittel beim Gerichtshof eingelegt; prüf also seinen Status, bevor du dich darauf verlässt.
• Standardvertragsklauseln. Die Standardvertragsklauseln (SCC) der Kommission von 2021 sind die übliche vertragliche Garantie, wenn kein Angemessenheitsbeschluss greift.
• Weitere Garantien und Ausnahmen, etwa verbindliche interne Datenschutzvorschriften oder eine ausdrückliche Einwilligung, für engere Fälle.

In der Map ist eine Übermittlung eine Kante, die deine Region verlässt, beschriftet mit Ziel und Garantie.

Das ausgearbeitete Beispiel: ein B2B-SaaS-Produkt

Das Produkt läuft in einer EU-Cloud-Region: eine Web-App, eine PostgreSQL-Datenbank und ein Analytics-Data-Warehouse. Fünf Anbieter erhalten personenbezogene Daten: E-Mail-Versand und Zahlungen im EWR sowie Produktanalyse, ein Support-Desk und ein CRM in den USA.

So liest du es:

• Eingang. Nutzer der Kunden legen Konten an, zahlen, nutzen das Produkt und schreiben dem Support. Jeder Fluss aus der Web-App ist mit den Datenkategorien beschriftet, die er transportiert.
• Eigene Systeme, EU-Region. Die App-Datenbank hält Konto- und Workspace-Daten. Das Warehouse erhält Nutzungsereignisse mit pseudonymen IDs, nicht mit Namen.
• Auftragsverarbeiter im EWR. Der E-Mail-Versand erhält Namen, E-Mail-Adressen und Nachrichteninhalte, der Zahlungsdienst Rechnungskontakte und Rechnungen. Eine Übermittlung findet nicht statt.
• Auftragsverarbeiter in den USA. Jede Kante in diesen Rahmen ist eine Übermittlung und trägt ihre Garantie: DPF für Anbieter, die unter dem Framework zertifiziert sind, SCC für den einen, der es nicht ist.
• Die Legende erklärt die Beschriftungen und listet Beispiel-Speicherfristen pro Speicher.

Zeichenkonventionen, die helfen

• Beschrifte Kanten mit Datenkategorien, nicht mit Technologien. „Name, E-Mail, Ticketinhalt“ hilft bei der Prüfung; „REST API“ nicht.
• Zieh eine Grenze um deine eigenen Systeme und setz die Auftragsverarbeiter außerhalb davon, nach Region gruppiert.
• Markiere jede Übermittlung mit Ziel und Garantie.
• Heb besondere Kategorien von Daten hervor, mit einer einheitlichen Farbe, und schreib in die Legende, was sie bedeutet.
• Schreib die Speicherfrist an jeden Speicher. Sie fehlt in Verarbeitungsverzeichnissen am häufigsten.
• Halte Zwecke und Rechtsgrundlagen im Verzeichnis fest, neben dem Diagramm. Das Diagramm zeigt das Wo; das Verzeichnis nennt das Warum.

Aktuell halten

Eine Data Map ist an dem Tag veraltet, an dem jemand einen neuen Anbieter hinzufügt. Kopple Aktualisierungen an die Ereignisse, die sie verändern: das Onboarding neuer Anbieter, neue Features, die neue Daten erheben, und Datenschutz-Folgenabschätzungen. Nach Artikel 35 muss ein Verantwortlicher eine Verarbeitung, die voraussichtlich ein hohes Risiko zur Folge hat, vor ihrem Beginn abschätzen, und die Map ist der natürliche Ausgangspunkt dafür. Prüf die ganze Map einmal im Jahr und bewahr die vorherige Version auf. Architekturdiagramme, die nicht veralten beschreibt genau dafür einen Workflow, und das Live-Diagramm im Datenschutz-Wiki einzubetten hält alle auf derselben Version.

Wie die Map bei Betroffenenanfragen hilft

Ein Auskunfts- oder Löschersuchen muss jeden Ort abdecken, an dem die Daten einer Person liegen: die App-Datenbank, das Warehouse, Backups und jeden Auftragsverarbeiter. Mit einer aktuellen Map ist die Antwort eine Checkliste statt einer Suche. Auftragsverarbeiter sind vertraglich verpflichtet, bei solchen Anfragen zu unterstützen, und die Map sagt dir, welche du fragen musst.

Eine Sicherheitssicht auf dieselben Flüsse findest du unter Datenflussdiagramme für die Bedrohungsmodellierung.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge eine Person aus dem C4-Modell-Pack für den Kundennutzer hinzu.
3. Füge einen Rahmen aus dem Basis-Pack für deine Systeme in der EU-Region hinzu, mit einem Container aus dem C4-Modell-Pack für die Web-App, Postgres aus dem Daten-Pack für die App-Datenbank und einem Datenlager aus dem Daten-Pack für die Analyse.
4. Füge zwei weitere Rahmen aus dem Basis-Pack für die Auftragsverarbeiter hinzu, einen für den EWR und einen für die USA, mit je einem Externes System-Node aus dem C4-Modell-Pack pro Anbieterrolle.
5. Beschrifte jede Kante mit den Datenkategorien, die sie transportiert, und ergänze an jeder Kante in den USA-Rahmen die Garantie.
6. Füge einen Markdown-Block aus dem Basis-Pack mit der Legende und den Speicherfristen hinzu.

Das Beispiel nutzt 13 Diagramm-Nodes und bleibt damit im Free-Plan. Der Anwendungsfall DSGVO-Datenmapping zeigt weitere Möglichkeiten, eine Map anzulegen.

FAQ

Schreibt die DSGVO eine Data Map vor? Die DSGVO verlangt in Artikel 30 das Verzeichnis von Verarbeitungstätigkeiten, kein Diagramm. Die meisten Teams stellen aber fest, dass sie ohne vorheriges Mapping der Flüsse kein korrektes Verzeichnis aufbauen oder pflegen können.

Wem sollte die Data Map gehören? Dem Datenschutzteam gehören das Verzeichnis und die Entscheidungen darin, dem Engineering die Systeme. Gib dem Diagramm auf jeder Seite eine verantwortliche Person und prüft es gemeinsam.

Sollte die Map einzelne Datenbanktabellen zeigen? Nein. Zeig Speicher und die Datenkategorien darin. Details auf Tabellenebene gehören in einen Datenkatalog.

Wie zeige ich einen Anbieter, der sowohl Auftragsverarbeiter als auch Verantwortlicher ist? Zeichne ihn einmal und beschrifte seine Rolle pro Fluss. Manche Anbieter, etwa Zahlungsdienstleister, handeln für Teile ihrer Verarbeitung als Verantwortliche; ihre Verträge sagen, für welche.

Kann das Diagramm das Verzeichnis nach Artikel 30 ersetzen? Nein. Das Verzeichnis muss bestimmte Angaben schriftlich enthalten, darunter Zwecke und Sicherheitsmaßnahmen. Nutze das Diagramm, um das Verzeichnis aufzubauen und zu prüfen.

Kostenlos starten — ein Seat, keine Kreditkarte.