Datenschutz-Folgenabschätzung und Privacy by Design als CISO-Aufgabe

Problem in der Praxis

In vielen Organisationen wird die DSFA als nachgelagertes Dokument behandelt, das kurz vor dem Go-Live erstellt wird. Technik und Verträge stehen dann bereits fest, und die Folgenabschätzung begründet nur noch getroffene Entscheidungen.

Privacy by Design teilt dieses Schicksal: Systeme werden mit maximaler Datensammlung und offenen Defaults ausgeliefert und Datenschutz nachträglich aufgesetzt. Spätestens bei Aufsichtsanfrage, Vorfall oder Kundenprüfung fehlt dann die Spur, warum ein Verfahren als unkritisch eingestuft wurde und welche Maßnahmen folgten.

CISO-Einordnung

DSFA und Privacy by Design sind die datenschutzrechtliche Ausprägung von zwei Dingen, die ein CISO ohnehin steuert: Risikobewertung und sichere Gestaltung.

Die DSFA ist ein Risikoverfahren. Sie ist nach Art. 35 erforderlich, wenn eine Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat. Typische Auslöser sind neue Technologien, systematische umfangreiche Überwachung sowie umfangreiche Verarbeitung sensibler Daten (besondere Kategorien nach Art. 9); Aufsichtsbehörden veröffentlichen ergänzend Muss-Listen. Maßgeblich ist die Blickrichtung: Die DSFA bewertet das Risiko aus Sicht der betroffenen Person, nicht aus Unternehmenssicht.

Privacy by Design (Art. 25) ist das Datenschutz-Pendant zu Secure-by-Design: datenschutzfreundliche Gestaltung und Voreinstellungen als Anforderung an Architektur und Produktentwicklung statt als nachgelagerte Kontrolle. Beide Pflichten verzahnen sich mit Art. 32, der geeignete technische und organisatorische Maßnahmen nach dem Stand der Technik verlangt. Hier docken ISO/IEC 27001 und IT-Grundschutz als Quelle konkreter Controls an; Art. 5 Abs. 2 (Rechenschaftspflicht) macht beides nachweispflichtig.

Umsetzungsperspektive

DSFA und Privacy by Design sollten in die bestehende Steuerung eingehängt werden statt parallele Strukturen zu bilden. Ein praktikabler DSFA-Ablauf orientiert sich am Inhalt aus Art. 35: systematische Beschreibung der Verarbeitung, Bewertung von Notwendigkeit und Verhältnismäßigkeit, Bewertung der Risiken für die Rechte und Freiheiten betroffener Personen sowie geplante Abhilfemaßnahmen. Der Datenschutzbeauftragte ist einzubeziehen; verbleibt danach ein hohes Risiko, ist nach Art. 36 die Aufsichtsbehörde vorab zu konsultieren.

Als Einstiegslogik bewährt sich eine zweistufige Prüfung: erst eine schlanke Schwellwertbetrachtung, ob die DSFA-Pflicht überhaupt ausgelöst ist, dann die vollständige DSFA bei hohem Risiko. Privacy by Design wird am wirksamsten über feste Prüfpunkte im Entwicklungsprozess umgesetzt; das Verzeichnis von Verarbeitungstätigkeiten (Art. 30) liefert die nötigen Inventardaten. Art. 35 sieht eine Überprüfung bei veränderten Risiken vor: Eine DSFA ist kein einmaliges Dokument, sondern ein fortzuschreibender Nachweis.

Typische Fehler

1. Die DSFA wird erst nach Architektur- und Vertragsentscheidung erstellt und dient nur noch der Rechtfertigung.
2. Das Risiko wird aus Unternehmenssicht statt aus Sicht der betroffenen Personen bewertet.
3. Privacy by Design wird als Konfigurations- oder Einwilligungsthema missverstanden statt als Gestaltungsanforderung.
4. Voreinstellungen sind datenoffen statt datensparsam, obwohl Art. 25 datenschutzfreundliche Defaults verlangt.
5. DSFA-Ergebnisse werden nicht mit den TOMs aus Art. 32 verknüpft und nie fortgeschrieben.

Risiken und Trade-offs

Eine zu formalistische DSFA erzeugt Dokumentationslast ohne Steuerungswert; eine zu oberflächliche übersieht reale Risiken für betroffene Personen und hält einer Aufsichtsprüfung nicht stand. Die angemessene Tiefe orientiert sich am tatsächlichen Risiko.

Privacy by Design steht oft im Spannungsfeld mit Produktanforderungen: datensparsame Voreinstellungen können Funktionen oder Analysen einschränken. Diese Abwägung ist eine Management-Entscheidung und sollte dokumentiert werden, nicht stillschweigend zugunsten der Datensammlung getroffen. Früh integrierte Prüfpunkte kosten Zeit, sind aber günstiger als nachgelagerte Korrekturen oder Bußgeldrisiken.

Entscheidungspunkte

• Ab welchem Schwellwert löst ein Verfahren eine DSFA aus, und wer trifft diese Einstufung?
• Wie wird die Risikoperspektive der betroffenen Person verbindlich in die Bewertung integriert?
• An welchen Stellen im Entwicklungs- und Beschaffungsprozess werden Privacy-by-Design-Anforderungen verpflichtend geprüft?
• Wie sind DSFA-Ergebnisse mit den TOMs aus Art. 32 und den ISMS-Controls verknüpft, und wann wird eine DSFA fortgeschrieben?

Praktische Empfehlungen

1. Verankern Sie eine schlanke Schwellwertprüfung als festen Schritt vor jedem neuen oder geänderten Verfahren.
2. Behandeln Sie die DSFA als Risikoverfahren im ISMS-Regelkreis, nicht als juristisches Einzeldokument.
3. Integrieren Sie Privacy by Design in den vorhandenen Secure-by-Design- und Freigabeprozess.
4. Setzen Sie datensparsame Voreinstellungen als Standard und begründen Sie jede Abweichung als Management-Entscheidung.
5. Verknüpfen Sie jede DSFA-Maßnahme mit Owner, TOM-Bezug nach Art. 32 und Prüfdatum und beziehen Sie den Datenschutzbeauftragten früh ein (Eskalationspfad Art. 36).

Relevante Normreferenzen

• DSGVO (Verordnung (EU) 2016/679): Art. 35 (DSFA), Art. 36 (vorherige Konsultation), Art. 25 (Technikgestaltung und Voreinstellungen), Art. 32 (Sicherheit der Verarbeitung), Art. 5 (Grundsätze, Rechenschaftspflicht), Art. 30 (Verzeichnis von Verarbeitungstätigkeiten). EU-Recht, frei zitierbar; verbindlich ist der amtliche Volltext.
• ISO/IEC 27001 und ISO/IEC 27002: Referenz für die TOMs, die das "Wie" zu Art. 32 liefern (reference-only, keine Control-Listen).
• ISO/IEC 27701 (Privacy Information Management): Referenz als Nachweisinstrument im Rahmen der Rechenschaftspflicht (reference-only); ersetzt keine rechtliche DSGVO-Konformität.
• NIST Privacy Framework und NIST SP 800-53 (Familie PT): governance-seitige Ergänzung ohne unmittelbare Rechtsbindung.