Eine Blockchain kann nachvollziehbare Zustände, Nachweise oder Freigaben über mehrere Beteiligte hinweg dokumentieren. Für viele Unternehmen klingt das attraktiv: Ein Zertifikat soll prüfbar bleiben, ein Lieferkettenereignis nachvollziehbar sein oder mehrere Partner sollen dieselbe Datenbasis nutzen. Sobald dabei Kundendaten, Mitarbeiterdaten, Nutzerkennungen oder Daten aus einem Kundenkonto berührt werden, wird aus der Technikentscheidung aber auch eine Datenschutzentscheidung.
Der Europäische Datenschutzausschuss (EDPB) hat im Juli 2026 seine Leitlinien zur Verarbeitung personenbezogener Daten mit Blockchain-Technologien finalisiert. Sie schaffen keine Sonderregeln neben der DSGVO. Sie machen vielmehr deutlich, dass gerade Unveränderlichkeit, Verteilung und Governance einer Blockchain früh geprüft werden müssen. Dieser Beitrag hilft deutschen KMU, SaaS-Teams und Agenturen bei der Einordnung. Er ersetzt keine individuelle Rechtsberatung.
Blockchain ist kein Freifahrtschein für Kundendaten
Eine Blockchain ist zunächst eine technische Infrastruktur. Sie kann Teil einer Verarbeitung sein, ohne selbst automatisch der Verarbeitungsvorgang zu sein. Für die DSGVO ist entscheidend, was das Unternehmen tatsächlich tut: Welche Daten werden erhoben, zu welchem Zweck, wer kann sie sehen, welche Systeme erhalten sie und wie lange bleiben sie nutzbar? Diese Fragen gelten auch dann, wenn die Anwendung nur einen Hash, eine Wallet-Adresse oder eine Transaktionsreferenz speichert.
Der EDPB empfiehlt deshalb eine Prüfung vor der Implementierung. Teams sollten nicht mit dem Argument beginnen, eine Blockchain sei modern oder manipulationssicher. Besser ist die Frage: Welches Problem lässt sich ohne die Technik nicht angemessen lösen? Für eine interne Freigabehistorie, einen Lieferantennachweis oder die Validierung eines digitalen Zertifikats kann eine zentrale Datenbank, ein signiertes Dokument oder ein Berechtigungssystem ausreichend sein. Wenn eine Alternative den Zweck mit weniger Risiken erreicht, gehört das in die Architekturentscheidung.
Diese Reihenfolge spart spätere Umbauten. Wer erst nach einem Pilotprojekt merkt, dass der eingesetzte Dienst personenbezogene Identifikatoren dauerhaft an mehrere Knoten verteilt, muss Rollen, Verträge und Betroffenenrechte unter Zeitdruck klären. Eine kurze Vorprüfung ist günstiger als ein nachträglicher Versuch, eine unveränderliche Datenstruktur passend zu machen.
Auch Hashes, Schlüssel und Metadaten können personenbezogen sein
Ein häufiger Denkfehler lautet: “Wir speichern keine Namen, also sind wir aus der DSGVO heraus.” Das kann stimmen, muss aber nicht. Öffentliche Schlüssel, Wallet-Adressen, pseudonyme Kennungen, Zeitstempel oder Transaktionsdaten können einer Person zuordenbar sein, wenn das Unternehmen oder andere Beteiligte über realistische Zusatzinformationen verfügen. Auch ein Hash hebt den Personenbezug nicht automatisch auf. Entscheidend ist der konkrete Kontext und ob eine Identifizierung mit Mitteln, die vernünftigerweise eingesetzt werden können, möglich bleibt.
Praktisch bedeutet das: Erstellen Sie ein Dateninventar, bevor die erste Transaktion geschrieben wird. Trennen Sie Nutzerdaten, Vertrags- oder Rechnungsdaten, technische Kennungen, Schlüsselmaterial, Ereignisdaten, Kommunikationsmetadaten und off-chain gespeicherte Zuordnungstabellen. Notieren Sie bei jedem Feld, warum es nötig ist, wer es erzeugt, wer es lesen kann und ob es auf die Kette, neben die Kette oder gar nicht in das Vorhaben gehört.
Direkt identifizierende Klartextdaten wie Name, E-Mail-Adresse, Lieferadresse, Ausweisnummer oder Supportnachricht gehören in der Regel nicht in eine Blockchain-Transaktion. Das ist auch für Produkt- und Website-Teams relevant: Ein Formular, ein Kundenkonto oder eine Partner-Schnittstelle darf nicht unbemerkt Daten an einen unveränderlichen Prozess übergeben. Der Beitrag Web Scraping für KI: Datenquellen und Datenschutz sauber dokumentieren zeigt ein verwandtes Prinzip: Nicht die Menge der Daten schafft Qualität, sondern die nachvollziehbare Herkunft, Zweckbindung und Minimierung.
On-chain und off-chain bewusst trennen
Die wichtigste Architekturentscheidung lautet oft: Was muss auf der Blockchain stehen und was kann außerhalb bleiben? Der EDPB rät grundsätzlich davon ab, personenbezogene Daten auf der Blockchain zu speichern. Für viele Anwendungsfälle genügt es, off-chain einen Datensatz kontrolliert zu führen und auf der Blockchain nur einen Nachweis über Integrität, Reihenfolge oder eine Berechtigung abzulegen. Ob das datenschutzrechtlich genügt, hängt von der konkreten Ausgestaltung ab. Es ist aber meist leichter, Berichtigung, Löschung und Zugriffskontrolle für den off-chain gespeicherten Datensatz umzusetzen.
Ein brauchbares Beispiel ist ein Weiterbildungszertifikat. Die Personendaten, der Kursnachweis und eine Kontaktmöglichkeit liegen in einem geschützten Fachsystem. Auf der Blockchain wird nicht der vollständige Nachweis, sondern eine Referenz oder ein Prüfwert geführt. Das Team dokumentiert, wer die Referenz erzeugt, welche Zuordnungstabelle existiert und wie deren Zugriff, Aufbewahrung und Löschung funktionieren. So lässt sich die Echtheit prüfen, ohne eine vollständige Personenakte dauerhaft zu verteilen.
Verschlüsselung kann ein Baustein sein, ist aber kein pauschaler Löschknopf. Schlüsselmanagement, Laufzeit von Algorithmen, Zugriff auf Kopien und die Möglichkeit einer Re-Identifizierung gehören zur Bewertung dazu. Ebenso wichtig sind Datenminimierung und Privacy by Design: Nur die Daten, die für einen klaren Zweck notwendig sind, dürfen in die Architektur. Für die Dokumentation von Diensten, Empfängern und Datenflüssen auf der Website kann der Datenschutz Generator unterstützen, nachdem das fachliche Dateninventar belastbar ist.
Öffentlich, permissioned oder privat: Governance vor dem Launch klären
Eine öffentliche, erlaubnisfreie Blockchain bringt andere Risiken mit als ein Netzwerk, in dem bekannte Organisationen Knoten betreiben. Bei einem öffentlichen Modell können Daten und Metadaten weit verteilt sein; Knoten außerhalb des Europäischen Wirtschaftsraums machen die Transferfrage wahrscheinlicher. In einem permissioned Netzwerk ist der Zugang begrenzt, doch auch dort müssen Rechte, Rollen, technische Zugänge und Verträge sauber feststehen.
“Dezentral” ersetzt keine Verantwortlichkeit. Wer Zwecke und wesentliche Mittel festlegt, kann Verantwortlicher sein; mehrere Beteiligte können je nach tatsächlicher Einflussnahme gemeinsam verantwortlich sein. Ein Infrastrukturpartner verarbeitet nicht automatisch nur im Auftrag. Das lässt sich nicht über eine Überschrift im Vertrag lösen, sondern muss sich an den tatsächlichen Entscheidungs- und Datenflüssen messen lassen. Für ein Konsortium können deshalb eine klar geregelte Governance, Zuständigkeiten für Änderungen, Sicherheitsvorfälle und Ansprechpartner für Betroffene wichtiger sein als die Wahl einer bestimmten Programmiersprache.
Erstellen Sie vor dem Start eine Rollenkarte: Betreiber der Anwendung, Knotenbetreiber, Cloud- oder Hostinganbieter, Integrationspartner, Kundenunternehmen, Support, Sicherheitsdienstleister und mögliche Empfänger außerhalb des EWR. Ergänzen Sie, wer Zugriffe erteilt, wer Protokolländerungen beschließt, wer Auskünfte beantwortet und wer bei einem Vorfall handelt. Der Business Paket ist passend, wenn Datenschutztexte, Consent und weitere Website-Pflichten gemeinsam mit diesen Prozessen abgestimmt werden sollen.
Löschung, Berichtigung und Aufbewahrung nicht auf später verschieben
Die Unveränderlichkeit einer Blockchain passt nicht automatisch zu einem Datenbestand, der berichtigt oder nach Ablauf einer Aufbewahrungsfrist gelöscht werden muss. Die EDPB-Leitlinien betonen, dass technische Unmöglichkeit keine Begründung für eine Nichtbeachtung der DSGVO ist. Teams brauchen daher vorab ein Konzept für Berichtigung, Löschung, Einschränkung, Auskunft und Widerspruch, soweit diese Rechte im konkreten Fall greifen.
Ein off-chain Datenmodell kann dabei helfen, zukünftige Identifizierung wirksam zu verhindern. Ob das im einzelnen Fall ausreicht, hängt von Datenart, Architektur und verbleibenden Verknüpfungsmöglichkeiten ab. Es ist keine Abkürzung, mit der sich jedes Problem lösen lässt. Dokumentieren Sie deshalb die geplante Aufbewahrungsdauer und den Auslöser für die Löschung: Vertragsende, Ablauf einer Nachweisfrist, Widerruf, Deaktivierung eines Kontos oder Abschluss eines Supportfalls. Prüfen Sie auch Backups, Knotenreplikate, Schlüsselmaterial und Logdaten.
Für Website-Betreiber gehört ein erreichbarer Prozess dazu. Der Beitrag Auskunftsanfragen über die Website: Prozesse, die im Ernstfall tragen bietet eine praktische Ergänzung. Kunden sollten nicht zwischen Support, Wallet-Provider und Projektpartnern suchen müssen. Ein zentraler Kontaktweg, eindeutige Verantwortlichkeiten und ein dokumentierter Prüfablauf sind oft wertvoller als ein besonders technischer Hinweis in der Datenschutzerklärung.
Rechtsgrundlage, Transfers und DSFA als zusammenhängende Prüfung
Auch bei einer Blockchain braucht jede konkrete Verarbeitung eine passende Rechtsgrundlage. Vertragserfüllung, rechtliche Verpflichtung, berechtigtes Interesse oder Einwilligung sind keine austauschbaren Etiketten. Wenn eine Einwilligung die Grundlage sein soll, muss sie freiwillig, informiert, spezifisch und widerrufbar sein. Das ist bei dauerhaft verteilten Daten besonders anspruchsvoll. Entscheiden Sie daher nicht aus Bequemlichkeit für Consent, sondern prüfen Sie Zweck, Erforderlichkeit und Folgen eines Widerrufs.
Bei Knoten oder Dienstleistern außerhalb des EWR sind die Regeln zu internationalen Datenübermittlungen mitzudenken. Eine bloße technische Verteilung macht den Empfänger nicht unsichtbar. Halten Sie fest, in welchen Ländern Knoten betrieben werden, welche Daten und Metadaten dorthin gelangen und welche Übermittlungsgrundlage oder Schutzmaßnahmen vorgesehen sind. Für ein öffentliches Netzwerk kann die Antwort sein, das Modell neu zu bewerten, wenn Transfers und Betroffenenrechte nicht angemessen kontrollierbar sind.
Eine Datenschutz-Folgenabschätzung (DSFA) ist erforderlich, wenn die Verarbeitung voraussichtlich ein hohes Risiko für Rechte und Freiheiten natürlicher Personen erzeugt. Blockchain-spezifische Risiken können dieses Bild beeinflussen, etwa durch die Verteilung von Daten, die Kombination von Kennungen, sensible Verwendungszwecke oder fehlende wirksame Interventionsmöglichkeiten. Die DSFA sollte nicht nur den Datensatz auf der Kette beschreiben. Auch Transaktionsübermittlung, Schlüsselverwaltung, Kommunikationsmetadaten, off-chain Referenzen und Governance gehören hinein.
Website, Tracking und Transparenz sauber abgrenzen
Eine Blockchain-Anwendung hat oft eine Website, ein Webportal oder eine dApp. Dort entstehen eigene Datenflüsse: Kontaktformulare, Kundenkonto, Fehlerprotokolle, Analyse, Marketingpixel, eingebettete Wallet-Dienste oder Support-Tools. Diese Verarbeitung ist nicht automatisch durch die Blockchain-Begründung gedeckt. Beschreiben Sie in der Datenschutzerklärung verständlich, welche Daten für die Anwendung erforderlich sind und welche zusätzlichen Dienste eingesetzt werden.
Für nicht notwendige Analyse- oder Marketingdienste sollte der Consent Manager Einwilligungen getrennt und nachvollziehbar steuern. Ein korrektes Cookie-Banner macht die Architektur jedoch nicht DSGVO-konform. Umgekehrt ersetzt eine gute Blockchain-Governance keine transparente Information über Tracking. Gerade diese Trennung verhindert, dass technische Begriffe wie Wallet oder Hash als Sammelbegriff für völlig unterschiedliche Datenverarbeitungen dienen.
Checkliste: Blockchain und DSGVO vor dem Projektstart
- Zweck der Blockchain festhalten und technische Alternativen dokumentiert vergleichen.
- Alle Daten, Kennungen, Schlüssel, Metadaten und off-chain Zuordnungen inventarisieren.
- Direkt identifizierende Daten aus Transaktionen und unveränderlichen Speichern heraushalten.
- Private, permissioned und öffentliche Architektur nach notwendiger Zugänglichkeit bewerten.
- Rollen, Knotenbetreiber, Entscheidungsrechte und Ansprechpartner in einer Governance festlegen.
- Aufbewahrung, Löschung, Berichtigung und den Zugang für Betroffene praktisch testen.
- Rechtsgrundlagen je Verarbeitung bestimmen und Transfers außerhalb des EWR einordnen.
- DSFA-Kriterien prüfen und Risiken des gesamten Datenflusses bewerten.
- Schlüsselmanagement, Incident-Prozess und Änderung von Protokoll oder Software dokumentieren.
- Website-Informationen, Datenschutzerklärung, Consent und Supportprozess mit der Technik abgleichen.
Fazit: Datenschutz entscheidet sich vor der ersten Transaktion
Blockchain und DSGVO schließen sich nicht grundsätzlich aus. Sie verlangen aber eine Architektur, die Datenminimierung, Kontrolle und Betroffenenrechte nicht als nachträgliche Ergänzung behandelt. Wer Zweck, Daten, Rollen, Zugriffe, Transfers und Löschkonzept vor dem Launch prüft, erkennt früh, ob eine permissioned Lösung, ein off-chain Modell oder eine andere Technologie besser passt.
Starten Sie mit einem konkreten Anwendungsfall und einer Datenflusskarte statt mit einer Plattformentscheidung. Wenn das Team erklären kann, welche Information wo liegt, wer darüber entscheidet und wie Rechte wirksam ausgeübt werden, wird aus einem technischen Pilotprojekt ein belastbar vorbereitetes Vorhaben.
