Der EDSA hat am 14. April 2026 eine standardisierte Vorlage für Datenschutz-Folgenabschätzungen veröffentlicht. Hier steht, was jeder ihrer sieben Abschnitte verlangt, abgebildet auf Artikel 35 DSGVO, und wo die heutigen DSFAs der meisten Organisationen dahinter zurückbleiben.
Die Vorlage des Europäischen Datenschutzausschusses (EDSA) für Datenschutz-Folgenabschätzungen (DSFA) ist sieben Abschnitte lang, trägt mehr als zwanzig Unterabschnitte und legt hinter fast jede Anforderung eine strukturierte Tabelle mit benannten Spalten. Das begleitend veröffentlichte Erläuterungsdokument, der „Explainer“, umfasst 50 nummerierte Absätze und schliesst mit einem Anhang, der 31 Aufsichtsbehörden auflistet, wobei jede Zeile auf die eigenen DSFA-Leitlinien der jeweiligen Behörde verweist, sofern es welche gibt.
Dieser Anhang ist genau das Problem, auf das die Vorlage zielt: ein einziger Satz von vier Anforderungen in Artikel 35(7), und eine eigene nationale Lesart davon für jede Behörde, die eine veröffentlicht hat.
Die Messlatte hat sich verschoben. Hier steht, um wie viel genau.
Artikel 35(7) DSGVO gilt seit 2018. Er nennt vier Anforderungen an eine DSFA:
Das ist eine Leistungsspezifikation. Sie sagt, was eine DSFA enthalten muss. Sie sagt nichts darüber, wie sie zu strukturieren ist, welches Format zu verwenden ist oder welcher Detailgrad als „systematisch“ gilt. Acht Jahre lang hat jede Organisation diese vier Punkte anders ausgelegt. Die meisten haben sie minimal ausgelegt.
Am 10. März 2026 hat der EDSA eine standardisierte DSFA-Vorlage angenommen. Veröffentlicht wurde sie am 14. April 2026. Die Pressemitteilung sagt, die Vorlage sei „nicht verpflichtend“ (Pressemitteilung im englischen Original, eigene Übersetzung). Dieselbe Pressemitteilung sagt auch: „Alle Datenschutzbehörden werden die notwendigen Schritte einleiten, um diese Vorlage entweder als ihren alleinigen Standard oder als ‚Meta-Vorlage‘ zu übernehmen, an der sich nationale Vorlagen ausrichten werden.“ Lesen Sie diese beiden Sätze zusammen. Die Vorlage ist heute freiwillig. Morgen ist sie der De-facto-Standard.
Zur Vorlage gehört ein Erläuterungsdokument mit 50 Absätzen, das ausbuchstabiert, was jedes Feld bedeutet und wie es auszufüllen ist. Der Explainer nennt das, was die Vorlage verlangt, „ein Minimum an Informationen, das immer dokumentiert werden sollte“ (Explainer im englischen Original, eigene Übersetzung). Er ist als Untergrenze geschrieben.
Was folgt, ist eine genaue Lektüre von Vorlage und Explainer gegen Artikel 35, Abschnitt für Abschnitt: was jeder verlangt und wo bestehende DSFAs brechen werden.
Abschnitt 0 ist der Teil, den die meisten Organisationen schon heute halbwegs gut machen. Identität des Verantwortlichen, Liste der Auftragsverarbeiter, Name der Verarbeitung, Starttermin. Zwei Dinge stechen aber heraus.
Erstens verlangt Unterabschnitt 0.5 ein „DPIA technical sheet“, ein technisches Datenblatt zur DSFA, mit Versionsprotokoll, beteiligtem Team (der Explainer schlägt eine RACI-Matrix vor) und den verwendeten Leitlinien oder Normen. Das sind Projektmetadaten. Sie bedeuten, dass Prüfer nachvollziehen können, wer jede Bewertungsentscheidung getroffen hat und wann.
Zweitens enthält 0.5 eine Checkbox-Liste mit Gründen für die Durchführung der DSFA. Die Liste hat über zehn Kategorien, die aus Artikel 35(3) und den bestehenden DSFA-Leitlinien des EDSA (wp248rev.01) stammen. Sie zwingt das Team zu dokumentieren, warum eine DSFA ausgelöst wurde -- nicht nur, dass sie es wurde.
Hier ist die Lücke zwischen heutiger Praxis und den Erwartungen der Vorlage am grössten. Abschnitt 1 entspricht Artikel 35(7)(a): „eine systematische Beschreibung der geplanten Verarbeitungsvorgänge“.
Die meisten Organisationen erfüllen 35(7)(a) mit einem Absatz. Etwa so: „Wir erheben personenbezogene Daten von Nutzern, um unseren Dienst bereitzustellen.“ Die Vorlage ersetzt diesen Absatz durch sieben strukturierte Anforderungen.
1.1.a -- Verarbeitete personenbezogene Daten. Eine Tabelle mit Spalten für jedes Datenelement, einer Erläuterung von Datentyp und Kategorie der betroffenen Personen und Checkboxen zur Kennzeichnung besonderer Kategorien nach Artikel 9. Keine Liste. Eine Tabelle. Pro Element.
1.1.b -- Zwecke der Verarbeitung. Eine weitere Tabelle, die jeden Zweck den betroffenen personenbezogenen Daten zuordnet, mit einer Spalte für die Begründung. Wenn Sie E-Mail-Adressen für Marketing und für die Kontowiederherstellung verarbeiten, sind das zwei Zeilen mit zwei Begründungen.
1.1.c -- Sekundäre oder vereinbare Nutzungen. Eine eigene Tabelle. Jede Sekundärnutzung bekommt ihre eigene Vereinbarkeitsprüfung. Die meisten DSFAs, die ich gesehen habe, erwähnen Sekundärnutzungen nicht einmal.
1.1.d -- Art, Umfang und Kontext. Drei getrennt dokumentierte Dimensionen. Art: „die Weise, wie personenbezogene Daten gehandhabt werden (beteiligte Vorgänge, eingesetzte Technologien)“ (Vorlage im englischen Original, eigene Übersetzung). Umfang: „Breite und Ausmass (Volumen oder Grössenordnung nach Zahl der betroffenen Personen oder Datenelemente, geografische und organisatorische Reichweite, Häufigkeit oder Dauer)“. Kontext: Umstände, grenzüberschreitende Verarbeitung, internationale Datenübermittlungen. Drei Zeilen. Drei Antworten.
1.2 -- Funktionale Beschreibung. Eine Tabelle, die die Verarbeitung in Phasen oder Stufen zerlegt, jede mit Lebenszyklus-Operationen markiert: Erhebung, Nutzung, Speicherung, Weitergabe und Übermittlung, Löschung und Vernichtung (in der Vorlage: Collection, Use, Storage, Sharing and Transfer, Deletion and Destruction). Die Vorlage ergänzt einen Hinweis: „Idealerweise sollte diese Tabelle durch ein oder mehrere Diagramme ergänzt werden, die Datenflüsse darstellen, oder eine ähnliche Abbildung.“ Der Explainer (Absatz 19) bekräftigt das: „Erläutern Sie den Datenlebenszyklus und die Datenflüsse: Geben Sie einen umfassenden Überblick darüber, wie personenbezogene Daten über ihren gesamten Lebenszyklus hinweg gehandhabt werden, von der Erhebung bis zur Löschung.“
Datenflussdiagramme. Dem Geist nach nicht optional, auch wenn das Wort „idealerweise“ nominell Deckung gibt.
1.3 -- Unterstützende Assets. Ein Inventar der Mittel der Verarbeitung: Hardware, Infrastruktur, Netzwerk, Software, APIs, Modelle, Personal, Standorte, organisatorische Assets. Der Explainer (Absatz 20) nennt es ein Inventar der „wesentlichen unterstützenden Assets“. Das ist ein Asset-Register, zugeschnitten auf den Verarbeitungsvorgang.
Die Lücke: Die meisten Organisationen füllen Artikel 35(7)(a) mit einem Absatz. Die Vorlage füllt ihn mit sieben strukturierten Tabellen plus Datenflussdiagrammen plus einem Asset-Inventar.
Abschnitt 2 entspricht den analytischen Anforderungen von Artikel 35(7)(a) und (b). Er hat drei grosse Unterabschnitte.
2.1 -- Rechtmässigkeit. Eine dreispaltige Tabelle pro Zweck: der Zweck, die Rechtsgrundlage (mit den Optionen aus Artikel 6(1), in der Vorlage wörtlich aufgeführt) und die Begründung. Beim berechtigten Interesse verlangt die Begründungsspalte die Interessenabwägung. Für besondere Kategorien nach Artikel 9 führt eine eigene Untertabelle die Ausnahmen aus Artikel 9(2) wörtlich auf. Kein Freitext. Aus der Liste der Verordnung selbst auswählen. Begründen.
2.2 -- Datenminimierung, Speicherfristen und Datenqualität. Das ist eine sechsspaltige Tabelle: Datenelement, Begründung von Erforderlichkeit/Relevanz, Empfänger, Begründung der Weitergabe, Speicherfrist und Begründung der Speicherfrist. Sechs Spalten. Pro Datenelement. Die meisten DSFAs, die ich geprüft habe, enthalten einen einzigen Satz zur Aufbewahrung: „Daten werden gemäss unserer Aufbewahrungsrichtlinie gespeichert.“ Die Vorlage verlangt die Speicherfrist und ihre Begründung pro Element.
Eine zweite Untertabelle (2.2.b) behandelt die Datenqualität: für jedes Datenelement, welche Qualitätsmetriken, Anforderungen oder Schwellenwerte gelten, und warum.
2.3 -- Compliance-Massnahmen. Das ist der längste Unterabschnitt. Fünf Untertabellen decken ab:
Die Spalte für den Umsetzungsstand hat drei definierte Werte: Planned, Partially implemented und Implemented (geplant, teilweise umgesetzt, umgesetzt). Der Explainer (Absatz 27) legt fest, was „Implemented“ bedeutet: „Die Massnahme existiert, ist ausgerollt und wirkt tatsächlich in der Produktivumgebung, nicht nur auf dem Papier; es gibt Belege dafür, dass die Kontrolle wie vorgesehen funktioniert.“ Nicht nur auf dem Papier. Belege erforderlich.
Abschnitt 3 entspricht Artikel 35(7)(b): „eine Bewertung der Notwendigkeit und Verhältnismässigkeit der Verarbeitungsvorgänge in Bezug auf den Zweck“.
Die meisten DSFAs erledigen die Notwendigkeit in einem Satz: „Wir erheben nur, was notwendig ist.“ Die Vorlage zerlegt das in drei getrennt dokumentierte Analysen.
3.1 -- Auswirkungen der Verarbeitung auf Rechte und Freiheiten, wie sie entworfen ist. Eine vierspaltige Tabelle: Bedrohungen, die von der Verarbeitung in ihrer entworfenen Form ausgehen, wie sie sich materialisieren, Risikoquellen und Auswirkungen auf die Rechte der betroffenen Personen. Hier geht es nicht um Verletzungen oder Unfälle. Hier geht es um die Verarbeitung, die so funktioniert wie beabsichtigt. Der Explainer (Absatz 32) stellt klar: „Erläutern Sie, wie sich die Bedrohungen, die die geplante Verarbeitung (so wie sie entworfen wurde und umgesetzt werden soll) für die Rechte und Freiheiten der betroffenen Personen darstellt, materialisieren können.“ Selbst ein perfekt funktionierendes System kann Risiken für Rechte und Freiheiten erzeugen. Die Vorlage verlangt, diese Risiken ausdrücklich zu dokumentieren.
3.2 -- Prüfung der Notwendigkeit. Der Text der Vorlage: „Bewerten Sie, ob die geplante Verarbeitung wirksam und für die Rechte und Freiheiten der betroffenen Person am wenigsten eingreifend ist. Liefern Sie Belege (zum Beispiel zu den verschiedenen geprüften Alternativen) und eine Begründung.“ Belege und geprüfte Alternativen. Die meisten Organisationen überspringen das vollständig. Die Vorlage macht die Alternativenanalyse zu einer benannten Anforderung.
3.3 -- Prüfung der Verhältnismässigkeit. „Erörtern Sie die Bedeutung der Verarbeitung und ihren möglichen Nutzen für die betroffene Person und für die Allgemeinheit. Führen Sie eine Bewertung durch, die die möglichen Auswirkungen auf die Rechte und Freiheiten der betroffenen Personen mit den Vorteilen aus der Verarbeitung vergleicht, um sicherzustellen, dass die Verarbeitung verhältnismässig und fair ausgewogen ist. Liefern Sie Belege und eine Begründung.“ Das ist eine dokumentierte Abwägung, kein Satz -- eine Abwägung, die auf Belegen steht.
Das ist Abschnitt 4, er entspricht Artikel 35(7)(c): „eine Bewertung der Risiken für die Rechte und Freiheiten der betroffenen Personen“. Es ist der Abschnitt, der die meiste operative Reibung erzeugen wird, weil er eine verbreitete Annahme kippt.
Die meisten Organisationen verwenden eine Ad-hoc-Matrix aus Eintrittswahrscheinlichkeit mal Auswirkung. Ein 3x3- oder 5x5-Raster, farbcodiert, mit undokumentierten Kriterien dafür, was als „hoch“ gilt. Die Vorlage schreibt keine bestimmte Matrix vor. Sie schreibt stattdessen vor, was jede gewählte Methodik dokumentieren muss.
4.1.b -- Methode. Die Vorlage verlangt: „Stufen von Eintrittswahrscheinlichkeit und Schwere und ihre Bedeutung (oft wird eine Skala mit 2 bis 5 Stufen verwendet). Risikometriken. Wie Risiken priorisiert werden. Risikoakzeptanzniveaus.“ Sie wählen die Methode. Aber Sie schreiben sie nieder. Die Methodik selbst wird zu einem prüfbaren Artefakt.
4.1.a -- Auswirkungen nicht vorgesehener Ereignisse. Die Risiken aus Abschnitt 4 sind von denen aus Abschnitt 3 verschieden. Abschnitt 3 deckt Risiken aus der Verarbeitung ab, die wie entworfen funktioniert. Abschnitt 4 deckt Risiken ab, die entstehen, wenn etwas schiefgeht: „Bedrohungen, die zu unrechtmässigem Zugriff, unerwünschter Veränderung und Verschwinden von Daten führen könnten“. Der Explainer (Absatz 35) zieht die Linie scharf: „Die Grundursache ist eine Abweichung vom beabsichtigten, konformen Zustand.“ Die meisten DSFAs werfen Risiken auf Entwurfsebene und operative Risiken in eine einzige Liste. Die Vorlage verlangt, sie zu trennen.
4.1.c -- Bewertung des inhärenten Risikos. Eine sechsspaltige Tabelle: Risiken, Eintrittswahrscheinlichkeit, Schwere, modulierende Faktoren, Risikoniveau und Erörterung der Akzeptierbarkeit. Die Spalte „modulierende Faktoren“ ist für die meisten Organisationen neu. Der Explainer (Absatz 37) definiert sie als „Merkmale, die die Eintrittswahrscheinlichkeit oder Schwere eines Risikos erhöhen oder verringern“. Beispiele: „eine sehr grosse Zahl betroffener Personen oder hohe Datensensibilität, betroffene Personen in einer Abhängigkeits- oder Verletzlichkeitssituation (Kinder, Patienten, Beschäftigte, Migranten) oder hohe Exposition gegenüber externen Angreifern“. Diese Faktoren modulieren den Wert nach oben oder unten, bevor Kontrollen angewendet werden.
Eine Fussnote der Vorlage (Fussnote 8) bricht mit der üblichen Annahme „Eintrittswahrscheinlichkeit mal Auswirkung“: „Ein Risiko im Datenschutz kann als nicht akzeptabel gelten, wenn die mögliche Schwere seiner Auswirkung sehr hoch ist, selbst wenn seine Eintrittswahrscheinlichkeit gering ist.“ Die Schwere allein kann ein Risiko inakzeptabel machen. Wenn Ihre heutige Matrix nur Risiken markiert, bei denen sowohl Eintrittswahrscheinlichkeit als auch Schwere hoch sind, wird das Rahmenwerk der Vorlage andere Ergebnisse liefern.
4.2 -- Massnahmenplan. Nach der Bewertung des inhärenten Risikos drei Untertabellen:
Die Lücke: Die meisten DSFAs listen generische Kontrollen auf („wir verwenden Verschlüsselung und Zugriffskontrolle“), ohne sie mit bestimmten Risiken zu verbinden. Die Vorlage verlangt eine ausdrückliche Nachvollziehbarkeit von Risiko zu Massnahme mit Querverweisen, Wirksamkeitsbegründung und einer Neuberechnung des Restrisikos für jedes Risiko.
Abschnitt 5 entspricht Artikel 35(2), der den Verantwortlichen verpflichtet, den Rat des Datenschutzbeauftragten (DSB) einzuholen.
5.1 -- Rat des DSB. Die Vorlage verlangt: „Geben Sie dessen Stellungnahme, Schlussfolgerungen und Empfehlungen zur geplanten Verarbeitung an.“ Dann: „Erläutern Sie, wie der Rat des DSB umgesetzt wurde.“ Zwei Felder. Die dokumentierte Stellungnahme des DSB. Die dokumentierte Antwort des Verantwortlichen. Die meisten Organisationen behandeln das als Unterschriftenzeile. Die Vorlage macht daraus einen Dialog mit Aktenspur.
5.2 -- Standpunkt der betroffenen Personen. Die Vorlage verlangt zu dokumentieren, ob betroffene Personen oder ihre Vertreter konsultiert wurden, und wenn nicht, warum nicht. Der Text: „Erläutern Sie ihre Beteiligung am DSFA-Prozess, einschliesslich der Gründe, warum ihre Beteiligung nicht als angemessen erachtet wurde oder warum sie nicht möglich war.“ Das Ausbleiben der Konsultation ist selbst eine dokumentierte Entscheidung.
Abschnitt 6 ist kurz, aber operativ bedeutsam. Die Vorlage definiert vier mögliche Ergebnisse:
Der Auslöser für Artikel 36 ist ausdrücklich: Das Ergebnis CONSULTATION gilt, wenn „der Verantwortliche keine ausreichenden Massnahmen finden kann, um die Risiken auf ein akzeptables Niveau zu senken (d. h. die Restrisiken sind weiterhin hoch)“. Das ist eine direkte Operationalisierung von Artikel 36(1): vorherige Konsultation der Aufsichtsbehörde, wenn „die Verarbeitung ein hohes Risiko zur Folge hätte, sofern der Verantwortliche keine Massnahmen zur Eindämmung des Risikos trifft“. Die Vorlage macht daraus eine strukturierte Entscheidung, keine Ermessensfrage, die im Freitext vergraben ist.
Ich habe die Gemeinsame Stellungnahme 4/2026 von EDSA und Europäischem Datenschutzbeauftragten (EDSB) zur Cybersicherheit auf strukturelle Verbindungen zur DSFA-Vorlage hin gelesen. Es gibt keine. Die DSFA-Vorlage zitiert weder Artikel 21 NIS2 noch verweist sie auf irgendein ENISA-Risikorahmenwerk.
Die Verbindung ist thematisch, nicht strukturell. Die Gemeinsame Stellungnahme (Absatz 36) hält fest, es gebe „Gelegenheit, Synergien zu schaffen, sodass die Risikobewertung den Schutz der Rechte und Freiheiten natürlicher Personen integrieren kann“ (Stellungnahme im englischen Original, eigene Übersetzung). Und Absatz 39 macht einen Punkt, der für jeden zählt, der Abschnitt 2.3.e (Sicherheit der Verarbeitung) ausfüllt: „Bestimmte Cybersicherheitskontrollen erzeugen spezifische Datenschutzrisiken. Das kann bei Monitoring und Logging, Deep Packet Inspection oder User Behaviour Analytics der Fall sein.“ Cybersicherheitsmassnahmen können selbst das sein, was ein DSFA-Risiko auslöst. Diese Spannung gehört in die Risikobewertung von Abschnitt 4, aber die Vorlage buchstabiert sie nicht aus.
Ich erwähne das, um ehrlich zu sein über das, was die Vorlage enthält und was nicht. Wer ein einziges Dokument sucht, das die DSGVO-Risikobewertung mit dem NIS2-Risikomanagement vereint: Das ist es nicht. Noch nicht.
Vier Abschnitte werden die grössten Lücken zwischen heutiger Praxis und dem, was die Vorlage erwartet, offenlegen.
Abschnitt 1 (Systematische Beschreibung). Freitextabsätze überleben den Kontakt mit den strukturierten Tabellen der Vorlage nicht. Die Datenzuordnung pro Element, die Zerlegung nach Lebenszyklusphasen und die Anforderung eines Datenflussdiagramms sind für die meisten Organisationen neue Arbeit.
Abschnitt 3 (Notwendigkeit und Verhältnismässigkeit). Die Alternativenanalyse in 3.2 und die Abwägung in 3.3 sind die Stellen, an denen die meisten DSFAs am dünnsten sind. Notwendigkeit zu behaupten ist leicht. Die Alternativen zu dokumentieren, die Sie geprüft und verworfen haben, ist es nicht.
Abschnitt 4.1.c (Bewertung des inhärenten Risikos). Die Spalte mit den modulierenden Faktoren und der Schwere-Vorrang aus Fussnote 8 werden die Werte von Organisationen verändern, die sich auf ein einfaches Raster aus Eintrittswahrscheinlichkeit mal Auswirkung verlassen. Die Anforderung, Risiken auf Entwurfsebene (Abschnitt 3) von operativen Risiken (Abschnitt 4) zu trennen, wird eine Umstrukturierung bestehender Risikoregister erzwingen.
Abschnitt 5.1 (Konsultation des DSB). Eine Unterschrift ist keine dokumentierte Stellungnahme. Die Zwei-Felder-Struktur der Vorlage -- Stellungnahme des DSB, Antwort des Verantwortlichen -- wird Lücken darin offenlegen, wie Organisationen ihre DSB einbinden.
Die Vorlage ist die Untergrenze, nicht die Obergrenze. Aber nach dem, was ich gesehen habe, sind die meisten Organisationen noch nicht einmal an der Untergrenze. Laden Sie die Vorlage herunter. Öffnen Sie Ihre letzte DSFA. Vergleichen Sie Abschnitt für Abschnitt. Die Lücken werden konkret und messbar sein.
Die Massnahmen, die eine DSFA auflistet, müssen irgendwo umgesetzt, belegt und überprüft werden. devguard führt Aufzeichnungen, Nachweise und Review-Zyklen gegen ein Control-Set in einem Workspace: devguard.ch.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.