n8n und DSGVO: Hosting, Datenflüsse und Verträge prüfen

Stand: Juli 2026. Dieser Artikel ist keine Rechtsberatung — er zeigt dir, welche Fragen du klären musst und wo die offiziellen Quellen liegen. Für die verbindliche Bewertung deines Einzelfalls brauchst du Datenschutzbeauftragte oder eine spezialisierte Kanzlei.

Das Problem: „Ist n8n DSGVO-konform?” ist die falsche Frage

Die Frage kommt in fast jedem Automatisierungsprojekt, meist kurz bevor der erste Workflow produktiv gehen soll: „Dürfen wir das überhaupt — DSGVO-mäßig?” Und die ehrliche Antwort ist unbequem: Kein Tool der Welt ist „DSGVO-konform”. Konform oder nicht konform ist immer eine konkrete Verarbeitung personenbezogener Daten — also die Kombination aus Tool, Hosting, angebundenen Diensten, Verträgen und Dokumentation. Ein selbst gehostetes n8n kann ein Datenschutzproblem sein, wenn der erste Node Kundendaten ungeprüft an eine US-KI-API schickt. Und n8n Cloud kann sauber laufen, wenn Verträge und Datenflüsse stimmen.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in kleinen und mittleren Unternehmen, die n8n einsetzen oder einführen wollen und wissen müssen, was dafür datenschutzrechtlich zu klären ist. Er gehört zu unserer Übersicht über Automatisierungstools und Integrationen.

Was du hier bekommst: die vier Ebenen, auf denen die DSGVO-Bewertung tatsächlich entschieden wird — Hosting, Datenflüsse, Drittanbieter, Dokumentation — plus eine Risikomatrix mit Gegenmaßnahmen und eine Prüf-Checkliste. Was du hier nicht bekommst: eine pauschale Freigabe. Die kann dir seriös niemand geben.

Begriffe kurz geklärt

Damit die Diskussion mit Datenschutzbeauftragten und Dienstleistern nicht an Vokabeln scheitert:

• Personenbezogene Daten (Art. 4 Nr. 1 DSGVO): Alle Informationen, die sich auf eine identifizierte oder identifizierbare Person beziehen — Namen, E-Mail-Adressen, Kundennummern, IP-Adressen. In der Praxis: Fast jeder Business-Workflow verarbeitet welche.
• Verantwortlicher (Controller): Wer über Zwecke und Mittel der Verarbeitung entscheidet. Das bist bei deinen Workflows du — nicht n8n, nicht dein Hoster.
• Auftragsverarbeiter (Processor): Wer personenbezogene Daten in deinem Auftrag verarbeitet. n8n Cloud ist für deine Workflow-Daten Auftragsverarbeiter; laut n8n-Dokumentation tritt das Unternehmen für die Cloud sowohl als Controller (für eigene Zwecke wie Accountverwaltung) als auch als Processor (für deine Inhalte) auf.
• AV-Vertrag (Auftragsverarbeitungsvertrag, engl. DPA): Der nach Art. 28 DSGVO verpflichtende Vertrag zwischen dir und jedem Auftragsverarbeiter. n8n stellt dafür auf seiner Legal-Seite einen vorunterzeichneten DPA bereit.
• Drittlandtransfer (Art. 44 ff. DSGVO): Übermittlung personenbezogener Daten in Länder außerhalb der EU/des EWR — braucht eine zusätzliche Grundlage, etwa einen Angemessenheitsbeschluss oder Standardvertragsklauseln (SCC).
• Execution-Daten: n8n speichert standardmäßig Ausführungsdaten deiner Workflows — inklusive der Daten, die durch die Nodes geflossen sind. Datenschutzrechtlich ist das eine eigene Speicherung mit eigener Löschfrage.

Abgrenzung: Es geht hier um n8n als Workflow-Plattform. Sobald deine Workflows KI-Modelle anbinden (etwa über die LLM-Nodes), kommen zusätzlich die Anforderungen an KI-Systeme ins Spiel — dazu unten mehr, mit den Orientierungshilfen der Datenschutzkonferenz als Referenz.

Ist n8n DSGVO-konform?

Die präzise Antwort in drei Teilen:

Erstens: n8n lässt sich DSGVO-konform betreiben. Es gibt keinen strukturellen Grund, der das verhindert. n8n bietet für die Cloud-Variante einen AV-Vertrag mit Signaturprozess an und führt eine separate, öffentliche Subprozessoren-Liste. Für Self-Hosting liefert die Software die nötigen Stellschrauben — inklusive der Möglichkeit, die Telemetrie per Umgebungsvariable (N8N_DIAGNOSTICS_ENABLED=false) komplett abzuschalten.

Zweitens: Kein Setup ist automatisch konform. Die DSGVO bewertet deine Verarbeitung, nicht die Software. Nach Art. 5 Abs. 2 DSGVO musst du als Verantwortlicher die Einhaltung der Grundsätze — Rechtmäßigkeit, Zweckbindung, Datenminimierung — nachweisen können. Das heißt konkret: Rechtsgrundlage je Verarbeitung, Verträge mit allen Auftragsverarbeitern, Dokumentation der Datenflüsse. Nichts davon erledigt ein Tool für dich.

Drittens: Die Bewertung hat vier Ebenen, und auf jeder kannst du sie gewinnen oder verlieren:

1. Hosting: Wo laufen n8n und seine Datenbank — n8n Cloud, eigener Server in der EU, irgendein VPS?
2. Datenflüsse: Welche personenbezogenen Daten fließen durch welche Workflows, und was bleibt in den Execution-Logs liegen?
3. Drittanbieter: Welche Dienste binden deine Nodes an, wo sitzen die, und bestehen AV-Verträge?
4. Dokumentation: Kannst du das alles nachweisen — Verarbeitungsverzeichnis, Löschkonzept, ggf. Datenschutz-Folgenabschätzung?

Der Rest des Artikels geht diese Ebenen der Reihe nach durch.

Welche Daten verarbeitet ein n8n-Workflow?

Das ist die Ebene, die in der Praxis am häufigsten unterschätzt wird — weil sie unsichtbar ist, bis man hinschaut. Ein n8n-Workflow verarbeitet drei Datenkategorien:

1. Nutzdaten (die eigentlichen Workflow-Inhalte). Alles, was durch die Nodes fließt: das Formular-Payload aus dem Webhook, die Kontaktdaten aus dem CRM, der E-Mail-Text, das PDF aus dem Ordner. Sobald darin Namen, Adressen, Kundennummern oder auch nur geschäftliche E-Mail-Adressen stecken, verarbeitest du personenbezogene Daten — und brauchst dafür eine Rechtsgrundlage nach Art. 6 DSGVO.

2. Execution-Daten. n8n protokolliert Workflow-Ausführungen, und je nach Einstellung bleiben dabei die kompletten Durchlaufdaten gespeichert — also auch die personenbezogenen Inhalte aus Punkt 1, dauerhaft und durchsuchbar. Aus meiner Projektpraxis ist das der klassische blinde Fleck: Der Workflow selbst ist sauber gebaut, aber in den Execution-Logs liegen sechs Monate Kundendaten, von denen niemand weiß und für die es keine Löschregel gibt. Kläre deshalb immer: Welche Executions werden gespeichert, wie lange, und wer kann sie einsehen?

3. Credentials und Metadaten. Die Zugangsdaten zu deinen angebundenen Systemen speichert n8n verschlüsselt — sie sind trotzdem Teil deiner Sicherheitsbetrachtung nach Art. 32 DSGVO, denn wer die n8n-Instanz kompromittiert, hat potenziell Zugriff auf alle verbundenen Systeme. Dazu kommt die Telemetrie: Laut n8n-Dokumentation erhebt die Cloud-Variante Nutzungs- und Diagnosedaten (unter anderem Workflow-Strukturen und UI-Interaktionen, ausdrücklich ohne Credential-Werte); im Self-Hosting werden anonymisierte Diagnosedaten gesendet, die sich per Umgebungsvariable deaktivieren lassen.

Praktische Konsequenz: Mach für jeden produktiven Workflow eine Mini-Datenflussanalyse — eine Tabelle mit Trigger, Datenkategorien, beteiligten Nodes, Ziel und Speicherdauer reicht. Ohne diese Übersicht ist jede Konformitätsaussage geraten.

Welche Drittanbieter sind beteiligt?

Ein n8n-Workflow ist selten eine Zweierbeziehung. Die typische Beteiligtenkette sieht so aus:

• n8n selbst — bei der Cloud-Variante als Auftragsverarbeiter, mit eigener Subprozessoren-Liste (etwa für die zugrunde liegende Infrastruktur). Beim Self-Hosting fällt n8n als Verarbeiter deiner Nutzdaten weitgehend weg.
• Dein Hoster — beim Self-Hosting wird stattdessen der Infrastrukturanbieter (Hetzner, IONOS, AWS, …) zum Auftragsverarbeiter, mit dem du einen AV-Vertrag brauchst.
• Jeder per Node angebundene Dienst, der personenbezogene Daten für dich verarbeitet: das CRM, der Newsletter-Dienst, der Cloud-Speicher, die Buchhaltung. Für jeden gilt: AV-Vertrag prüfen, Sitz und Serverstandort klären.
• KI-APIs als Sonderfall. Bindest du LLM-Anbieter an, gelten alle genannten Punkte plus die KI-spezifischen: Das BSI empfiehlt in seinem Management-Leitfaden zu generativer KI unter anderem, die Zugriffe des KI-Systems auf andere Systeme einzuschränken, ein Berechtigungskonzept zu erstellen, KI-Ausgaben vor der Weitergabe an Backendsysteme zu validieren und Datenschutzbeauftragte von Beginn an einzubinden. Es weist außerdem darauf hin, dass die Nutzung europäischer KI-Anbieter rechtlich vereinfachend wirken kann.

Für jeden Anbieter außerhalb der EU/des EWR kommt die Transferfrage nach Art. 44 ff. DSGVO dazu: Gibt es einen Angemessenheitsbeschluss, gelten Standardvertragsklauseln, und sind sie tatsächlich Vertragsbestandteil? Das ist keine Formalie — es ist regelmäßig der Punkt, an dem ein „schnell mal automatisiert”-Workflow zur offenen Flanke wird.

Meine Faustregel aus Projekten: Die DSGVO-Komplexität eines Workflows wächst nicht mit der Zahl der Nodes, sondern mit der Zahl der unterschiedlichen Anbieter dahinter. Drei Nodes gegen das eigene, selbst gehostete ERP sind unkritischer als ein einzelner Node gegen eine US-KI-API ohne AV-Vertrag.

Was ändert Self-Hosting?

Self-Hosting ist das stärkste einzelne Werkzeug in dieser Liste — aber kein Freifahrtschein. Was sich konkret ändert:

Was besser wird:

• Datenhoheit: Nutz- und Execution-Daten bleiben auf deiner Infrastruktur. n8n als Auftragsverarbeiter für deine Workflow-Inhalte entfällt, die Kette wird kürzer.
• Standortwahl: Du bestimmst den Serverstandort — ein EU-Rechenzentrum nimmt die Drittlandfrage für die n8n-Ebene vom Tisch.
• Telemetrie-Kontrolle: Diagnose- und Versionsdaten lassen sich laut n8n-Dokumentation per Umgebungsvariablen vollständig abschalten.
• Löschkonzept umsetzbar: Aufbewahrung der Execution-Daten, Datenbank-Backups, Zugriffskontrolle — alles liegt in deiner Hand und lässt sich exakt an dein Löschkonzept anpassen.

Was gleich bleibt:

• Die angebundenen Drittdienste. Ein selbst gehostetes n8n, das Kundendaten an einen Dienst ohne AV-Vertrag schickt, ist genauso ein Problem wie vorher.
• Rechtsgrundlagen, Informationspflichten (Art. 13/14 DSGVO), Betroffenenrechte, Verarbeitungsverzeichnis — die Verantwortlichen-Pflichten hängen nicht am Hosting.

Was schwerer wird:

• Du übernimmst den kompletten Betrieb: Updates, Härtung, Zugriffskontrolle, Backups, Monitoring. Art. 32 DSGVO verlangt dem Risiko angemessene technische und organisatorische Maßnahmen — beim Self-Hosting bist du dafür allein zuständig. Eine vergessene, ungepatcht aus dem Internet erreichbare n8n-Instanz ist ein größeres Datenschutzrisiko als jede Cloud-Frage.

Ehrlich eingeordnet: Für Unternehmen mit sensiblen Daten und vorhandener IT-Kompetenz ist Self-Hosting in der EU meist die sauberste Lösung. Für ein Drei-Personen-Team ohne Server-Erfahrung kann n8n Cloud mit unterschriebenem DPA die sicherere Wahl sein — ein professionell betriebener Dienst mit Vertrag schlägt einen vernachlässigten Eigenbetrieb. Die Abwägung im Detail findest du in unserem Vergleich der Hosting-Optionen; entscheidend ist, dass du sie bewusst triffst und begründen kannst.

Welche Dokumentation ist nötig?

Die DSGVO ist ein Nachweisrecht: Nach Art. 5 Abs. 2 musst du die Einhaltung der Grundsätze nachweisen können. Für n8n-Workflows heißt das mindestens:

1. Verzeichnis von Verarbeitungstätigkeiten (Art. 30 DSGVO): Jede produktive Automatisierung, die personenbezogene Daten verarbeitet, gehört hinein — mit Zweck, Datenkategorien, Betroffenen, Empfängern, Löschfristen und Beschreibung der Schutzmaßnahmen. Praktischer Tipp: Nimm die Datenfluss-Tabelle aus dem Workflow-Bau als Grundlage, dann ist das Verzeichnis ein Nebenprodukt statt einer Extraaufgabe.
2. AV-Verträge: Mit n8n (Cloud) beziehungsweise dem Hoster (Self-Hosting) und mit jedem angebundenen Dienst, der Auftragsverarbeiter ist. Ablage zentral, mit Datum und Version.
3. Löschkonzept: Aufbewahrungsfristen für Execution-Daten, Regeln für Backups, Zuständigkeit für die Umsetzung. „Wir löschen nie” ist keine zulässige Antwort auf die Speicherbegrenzung aus Art. 5 DSGVO.
4. Rechtsgrundlagen-Notiz je Workflow: Ein Satz reicht oft — „Verarbeitung zur Vertragserfüllung (Art. 6 Abs. 1 lit. b)” oder „berechtigtes Interesse mit Abwägung vom …”. Wichtig ist, dass er vor dem Go-live existiert.
5. Datenschutz-Folgenabschätzung (Art. 35 DSGVO) bei hohem Risiko: Die Datenschutzkonferenz stellt in ihrer Orientierungshilfe zu KI-Systemen (Version 1.0, Juni 2025) klar, dass eine DSFA durchzuführen ist, wenn die Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat — bei KI-gestützten Workflows über Kundendaten solltest du diese Prüfung ernsthaft durchführen und das Ergebnis dokumentieren. Dieselbe Orientierungshilfe betont „data protection by design”: Datenschutz gehört in die Designphase des Systems, nicht in die Nachbesserung.
6. Betroffenenrechte-Prozess: Wenn jemand Auskunft (Art. 15) oder Löschung (Art. 17) verlangt — findest du dessen Daten auch in den Execution-Logs und den angebundenen Systemen? Der Prozess muss das abdecken.

Umsetzung: In fünf Schritten zum prüfbaren Setup

So gehe ich in Projekten vor, wenn n8n datenschutzfest aufgesetzt werden soll:

1. Inventur: Alle bestehenden und geplanten Workflows listen. Je Workflow: Trigger, Datenkategorien, angebundene Dienste, Speicherorte. Eine Stunde konzentrierte Arbeit, die alles Weitere trägt.
2. Hosting-Entscheidung treffen und begründen: Cloud mit DPA oder Self-Hosting in der EU — anhand von Datensensibilität, IT-Kompetenz und Betriebskapazität. Die Begründung schriftlich festhalten.
3. Vertragslage schließen: DPA mit n8n bzw. AV-Vertrag mit dem Hoster abschließen, AV-Verträge aller angebundenen Dienste einsammeln, Drittlandtransfers identifizieren und absichern. Dienste ohne AV-Vertrag: ersetzen oder aus dem Datenfluss nehmen.
4. Technisch härten: Zugriff auf die n8n-Instanz beschränken (SSO/2FA, keine offene Registrierung), Execution-Datenaufbewahrung konfigurieren, Telemetrie im Self-Hosting deaktivieren, Credentials nach Least-Privilege-Prinzip anlegen — also API-Schlüssel mit minimalen Rechten statt Admin-Zugängen, wie es auch das BSI für KI-Integrationen empfiehlt.
5. Dokumentieren und Regeltermin setzen: Verarbeitungsverzeichnis aktualisieren, Löschkonzept aktivieren, und — der am häufigsten fehlende Schritt — einen festen Review-Rhythmus etablieren. Workflows ändern sich; die Dokumentation muss mitziehen.

Wenn du dabei Unterstützung willst: In unserer KI- und Automatisierungsberatung machen wir genau diese Bestandsaufnahme, und in unseren Schulungen lernt dein Team, Workflows von Anfang an datenschutzbewusst zu bauen.

Risikomatrix: typische n8n-Datenschutzrisiken und Gegenmaßnahmen

Diese Matrix ist mein Arbeitswerkzeug für den Erstcheck — die Einstufungen sind Praxiseinschätzungen für ein typisches KMU-Setup, kein Ersatz für deine eigene Risikoanalyse:

Risiko	Eintritt	Auswirkung	Gegenmaßnahme
Personenbezogene Daten in Execution-Logs ohne Löschregel	Hoch	Mittel	Aufbewahrung der Execution-Daten begrenzen, Löschkonzept dokumentieren, sensible Workflows ohne Datenpersistenz konfigurieren
Node an Drittdienst ohne AV-Vertrag	Hoch	Hoch	Anbieter-Inventur je Workflow; DPA einsammeln oder Dienst ersetzen, bevor der Workflow produktiv geht
Kundendaten fließen ungeprüft an KI-API (ggf. Drittland)	Mittel	Hoch	Datenminimierung vor dem LLM-Node (Felder filtern/pseudonymisieren), EU-Anbieter oder EU-Region prüfen, Transfergrundlage klären
Offen erreichbare oder ungepatchte Self-Hosting-Instanz	Mittel	Hoch	Zugriff per VPN/SSO beschränken, Update-Routine festlegen, Verantwortlichen benennen
Credentials mit Vollzugriff statt Least Privilege	Hoch	Mittel	API-Schlüssel mit minimalen Scopes, getrennte Credentials je Workflow, regelmäßige Rechte-Reviews
Workflow ohne Rechtsgrundlage/Eintrag im Verarbeitungsverzeichnis	Hoch	Mittel	Go-live-Checkliste mit Pflichtfeld Rechtsgrundlage; Verzeichnis-Eintrag als Teil der Workflow-Abnahme
Betroffenenanfrage (Auskunft/Löschung) läuft an Logs vorbei	Mittel	Mittel	Betroffenenrechte-Prozess um n8n-Executions und angebundene Systeme erweitern und einmal testen
Schatten-Workflows einzelner Mitarbeitender	Mittel	Mittel	Zentrale Instanz mit Nutzerverwaltung statt Wildwuchs; klare Leitlinie, wer Workflows mit Personendaten bauen darf

Lies die Matrix als Priorisierung: Die Kombination „hoher Eintritt + hohe Auswirkung” — fehlende AV-Verträge bei angebundenen Diensten — gehört zuerst auf den Tisch, noch vor der Hosting-Grundsatzdebatte.

Risiken und Grenzen

Ein paar ehrliche Einschränkungen, damit dieser Leitfaden nicht mehr verspricht, als er halten kann:

• Keine Konformitätszusage möglich. Ob dein Setup den Anforderungen genügt, hängt an Details, die nur eine Einzelfallprüfung klären kann — Datenkategorien, Rechtsgrundlagen, Vertragsinhalte. Dieser Artikel strukturiert die Prüfung, er ersetzt sie nicht.
• Rechtslage in Bewegung. Aufsichtsbehörden konkretisieren die Anforderungen an KI-gestützte Verarbeitung laufend — die DSK-Orientierungshilfe zu KI-Systemen stammt von Juni 2025, weitere Konkretisierungen sind absehbar. Prüfe bei rechtlich sensiblen Workflows die aktuellen Veröffentlichungen der Datenschutzkonferenz und deiner Landesaufsichtsbehörde. Stand dieses Artikels: Juli 2026.
• Anbieterangaben können sich ändern. Hosting-Details, Subprozessoren und Telemetrie-Verhalten von n8n sind Anbieterangaben — verlass dich nicht auf Blogartikel (auch nicht auf diesen), sondern prüfe DPA, Subprozessoren-Liste und Trust Center von n8n zum Zeitpunkt deines Vertragsschlusses.
• Dokumentation ist Arbeit, die bleibt. Der laufende Aufwand — Verzeichnis pflegen, neue Workflows prüfen, Verträge aktuell halten — wird gern unterschätzt. Plane ihn ein, sonst veraltet dein sauberes Setup innerhalb weniger Monate.

Checkliste: n8n-DSGVO-Erstcheck

Zum Abhaken, bevor (oder spätestens nachdem) der erste Workflow mit Personendaten produktiv läuft:

• Inventur: Alle Workflows mit Datenkategorien, Diensten und Speicherorten gelistet
• Hosting: Entscheidung Cloud vs. Self-Hosting getroffen und schriftlich begründet
• DPA n8n/Hoster: AV-Vertrag mit n8n (Cloud) bzw. dem Infrastrukturanbieter (Self-Hosting) abgeschlossen
• Drittdienste: AV-Verträge aller angebundenen Anbieter liegen vor; Drittlandtransfers identifiziert und abgesichert
• KI-Nodes: Datenminimierung vor LLM-Aufrufen umgesetzt; Anbieter-Standort und Vertragslage geprüft
• Execution-Daten: Aufbewahrungsdauer konfiguriert, Löschkonzept dokumentiert
• Zugriff: Instanz nicht offen erreichbar, 2FA/SSO aktiv, Credentials nach Least Privilege
• Telemetrie: Im Self-Hosting bewusst entschieden (und ggf. per Umgebungsvariable deaktiviert)
• Verzeichnis: Workflows im Verzeichnis von Verarbeitungstätigkeiten erfasst, Rechtsgrundlage je Workflow notiert
• DSFA: Schwellenprüfung nach Art. 35 DSGVO durchgeführt und Ergebnis dokumentiert
• Betroffenenrechte: Auskunfts- und Löschprozess deckt n8n-Logs und angebundene Systeme ab
• Review: Fester Termin für die regelmäßige Überprüfung steht im Kalender

Wenn du bei mehr als zwei Punkten ins Stocken kommst, ist das kein Grund zur Panik — aber ein guter Grund, das Setup einmal systematisch prüfen zu lassen. Im kostenlosen Erstgespräch schauen wir gemeinsam auf deine Workflows und sagen dir ehrlich, wo es klemmt und was zuerst dran ist.