Datenschutz-Risikobeurteilung für ISO 27701 und GDPR

Die Besprechung am Montagmorgen kam Maria, CISO eines schnell wachsenden Healthtech-Unternehmens, vertraut vor.

Der CEO wollte ein einfaches Dashboard, das die GDPR-Risikoexposition zeigt, bevor das Unternehmen seine KI-gestützte Plattform für Patientenanalysen einführt. Der neue Datenschutzverantwortliche David hatte ein Verzeichnis von Verarbeitungstätigkeiten (RoPA) mit 50 Tabellenblättern. Engineering hatte die Cloud-Umgebung abgesichert. Das Produktteam war bereit für die Freigabe. Der Lieferant beschrieb seine Kette von Unterauftragsverarbeitern als „Enterprise-tauglich“.

Doch eine Frage brachte den Raum zum Stillstand.

„Wie hoch ist unser tatsächliches Risiko, und können wir Unternehmenskunden nachweisen, dass wir es unter Kontrolle haben?“

Das RoPA zeigte, was das Unternehmen verarbeitet. Das Sicherheitsrisikoregister zeigte Infrastrukturrisiken. Einige DPIAs lagen in separaten Dokumenten. Lieferantenprüfungen befanden sich in Beschaffungsordnern. Niemand konnte eine durchgängige, nachvollziehbare Entscheidungskette von der Verarbeitungstätigkeit über das Datenschutzrisiko, die DPIA-Entscheidung, den Risikobehandlungsplan, die Kontrollzuordnung, die Genehmigung des Restrisikos bis zum Überprüfungsdatum vorlegen.

Genau diese Lücke begegnet vielen Organisationen auf dem Weg zu ISO/IEC 27701:2025 und GDPR-Rechenschaftspflicht. Sie verfügen über Datenschutzhinweise, Lieferantenfragebögen, RoPA-Einträge, Datenflussübersichten, DPIA-Vorlagen und ISO/IEC 27001:2022-Kontrollen. Was häufig fehlt, ist die operative Ebene, die diese Elemente miteinander verbindet.

Ein ausgereiftes Datenschutz-Informationsmanagementsystem (PIMS) behandelt die Datenschutz-Risikobeurteilung nicht als juristisches Nebendokument. Es behandelt sie als wiederholbaren Entscheidungs-Workflow: Verarbeitung identifizieren, Risiko prüfen, entscheiden, ob eine DPIA erforderlich ist, Kontrollen auswählen, Verantwortliche zuweisen, Restrisiko genehmigen, Auslöser überwachen und Nachweise aufbewahren.

Hier unterstützen die Richtlinienpakete von Clarysec, Zenith Blueprint und Zenith Controls Teams dabei, von isolierten Tabellen zu einem belastbaren System für Datenschutzrisiken zu gelangen.

Datenschutz-Risikobeurteilung ist die fehlende operative Ebene

GDPR-Rechenschaftspflicht wird häufig auf „Dokumentation haben“ reduziert. Dokumentation ist wichtig, aber Article 5(2) geht weiter. Der Verantwortliche ist für die Einhaltung der in Article 5(1) genannten Grundsätze verantwortlich und muss diese nachweisen können, einschließlich Rechtmäßigkeit, Verarbeitung nach Treu und Glauben, Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität und Vertraulichkeit.

Dafür reicht ein RoPA nicht aus. Die Organisation muss erklären können, warum eine Verarbeitungstätigkeit zulässig ist, welche Risiken sie für betroffene Personen erzeugt, welche Kontrollen diese Risiken mindern, wer die Entscheidung verantwortet und wann sie überprüft werden muss.

ISO/IEC 27701:2025 verstärkt diese Erwartung, indem Datenschutz-Governance in ein gesteuertes PIMS eingebettet wird. In der Praxis muss die Datenschutz-Risikobeurteilung sechs operative Objekte verbinden:

1. Das Verzeichnis der PII-Verarbeitung oder RoPA.
2. Dokumentation zu Rechtsgrundlage und Zweck.
3. Datenschutzrisiko-Screening und DPIA-Entscheidung.
4. Risikobehandlung und Auswahl von Kontrollen.
5. Governance für Lieferanten, Auftragsverarbeiter und Unterauftragsverarbeiter.
6. Im ISMS und PIMS aufbewahrte Nachweise.

Clarysec macht diese Verbindung explizit. In der Enterprise-Richtlinie zur Datenschutz-Risikobeurteilung und DPIA wird der Auslöser vor den Beginn der Verarbeitung gelegt:

[Beide] Der Prozessverantwortliche / Fachverantwortliche MUSS das Datenschutzrisiko-Screening in REG04 einleiten, bevor eine neue oder wesentlich geänderte PII-Verarbeitung beginnt, die in REG02 erfasst ist.

Dieselbe vorgelagerte Disziplin findet sich in der Enterprise-Richtlinie zum Verzeichnis der PII-Verarbeitung und zur Rechtsgrundlage:

[Beide] Der Prozessverantwortliche / Fachverantwortliche MUSS das Datenschutzrisiko- und DPIA-Screening in REG04 einleiten, bevor eine neue oder wesentlich geänderte PII-Verarbeitung fortgeführt wird.

Dies verhindert ein häufiges Fehlermuster: Das Produkt wird eingeführt, das RoPA später aktualisiert, die DPIA-Frage kommt zu spät, und das Risikoregister erhält nie das Datenschutzszenario.

Für Verantwortliche unterstützt dies die Disziplin zur Rechtsgrundlage nach GDPR Article 6, Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen nach Article 25, Sicherheit der Verarbeitung nach Article 32 sowie Rechenschaftspflicht nach Article 5. Für Auftragsverarbeiter unterstützt es dokumentierte Weisungen, Vertrauensbildung bei Kunden, Vertragsgrenzen und Transparenz zu Unterauftragsverarbeitern.

Mit der tatsächlichen Verarbeitung beginnen, nicht mit einer leeren Vorlage

Eine Datenschutz-Risikobeurteilung scheitert, wenn sie mit einem leeren Formular und ohne operativen Kontext beginnt. Die erste Frage sollte nicht lauten: „Brauchen wir eine DPIA?“ Sie sollte lauten: „Welche Verarbeitung ändert sich tatsächlich?“

Für eine SaaS-, Fintech- oder Healthtech-Organisation kann die Änderung Folgendes betreffen:

• Eine neue Datenkategorie, beispielsweise Nutzungsdaten zum Verhalten, Gesundheitsdaten, biometrische Signale oder Zahlungsmetadaten.
• Einen neuen Zweck, beispielsweise Betrugsbewertung, Patientenanalysen, KI-gestützten Support, Abwanderungsprognosen oder Personalisierung.
• Einen neuen Empfänger, Auftragsverarbeiter oder Unterauftragsverarbeiter.
• Einen neuen Support-Workflow oder einen neuen grenzüberschreitenden Zugriffspfad.
• Eine neue Aufbewahrungsfrist.
• Ein neues Modell, einen neuen Algorithmus oder eine automatisierte Empfehlung.
• Eine neue Gruppe betroffener Personen, beispielsweise Minderjährige, Beschäftigte, Patienten oder finanziell schutzbedürftige Personen.

Die Definitionen der GDPR sind weit gefasst. Personenbezogene Daten umfassen Kennungen, Online-Kennungen, Standortdaten und Faktoren mit Bezug zur Identität. Verarbeitung umfasst Erhebung, Speicherung, Abruf, Nutzung, Offenlegung, Einschränkung, Löschung und Vernichtung. Eine Verletzung des Schutzes personenbezogener Daten umfasst unbeabsichtigte oder unrechtmäßige Vernichtung, Verlust, Veränderung, unbefugte Offenlegung oder unbefugten Zugriff.

Das bedeutet: Ein Workflow für Datenschutzrisiken muss mehr erfassen als die Frage, ob die Datenbank verschlüsselt ist. Er muss erfassen, warum die Verarbeitung existiert, ob der Zweck vereinbar ist, ob die Rechtsgrundlage gültig ist, ob besondere Kategorien personenbezogener Daten betroffen sind, ob betroffene Personen die Verarbeitung verstehen können und ob die Schutzmaßnahmen verhältnismäßig sind.

Für kleinere Teams bietet die KMU-Richtlinie zu Datenschutz und Privatsphäre den Ausgangspunkt in Klausel 5.2.1:

Der Datenschutzkoordinator muss ein Register aller Verarbeitungstätigkeiten personenbezogener Daten führen, einschließlich Datenkategorien, Zweck, Rechtsgrundlage und Aufbewahrungsfristen.

Dieses Register ist keine Papierübung. Es ist das Eingabemodell für die Datenschutz-Risikobeurteilung. Ohne Datenkategorien, Zweck, Rechtsgrundlage und Aufbewahrungsfristen kann die Bewertung Zweckbindung, Datenminimierung, Speicherbegrenzung, Transparenz oder Verarbeitung nach Treu und Glauben nicht zuverlässig beurteilen.

Dieselbe KMU-Richtlinie macht die Risikoprüfung in Klausel 7.1.1 außerdem zu einer wiederkehrenden Verpflichtung:

Der Datenschutzkoordinator muss Datenschutzrisiken jährlich und bei wesentlichen Systemänderungen bewerten.

Für Unternehmen ist die Governance-Frequenz strenger. Die Enterprise-Richtlinie zu Datenschutz und Privatsphäre legt fest:

Datenschutz-Risikoregister sind im ISMS zu führen und mindestens vierteljährlich durch den Datenschutzbeauftragten (DPO) und den CISO zu überprüfen.

An dieser Stelle wird die Integration von ISO/IEC 27701:2025 und ISO/IEC 27001:2022 praktisch. Datenschutzrisiken werden nicht in Rechtsordnern verborgen. Sie werden gemeinsam mit Sicherheitsrisiken, Lieferantenrisiken, Vorfällen, Audit-Feststellungen, Risikobehandlungsplänen und Managementberichten überprüft.

Der Clarysec-Workflow von REG02 zu REG04

Der wirksamste Prozess zur Datenschutz-Risikobeurteilung ist einfach genug für Fachverantwortliche und belastbar genug für Auditoren. Das Clarysec-Modell nutzt REG02 als Verzeichnis der PII-Verarbeitung und REG04 als Datensatz für Datenschutz-Risikobeurteilung und DPIA.

Die Richtlinie zur Datenschutz-Risikobeurteilung und DPIA definiert die Mindestnachweise, die vor dem Abschluss von REG04 erforderlich sind:

[Beide] Der Datenschutzverantwortliche / PIMS-Manager MUSS sicherstellen, dass jede REG04-Bewertung vor dem Abschluss Risikoeinstufung, Behandlungsentscheidung, Verantwortlichen, Fälligkeitstermin, Restrisiko, Genehmigungsstatus und Überprüfungsdatum dokumentiert.

Dieser Satz ist das operative Rückgrat. Eine Datenschutz-Risikobeurteilung ist nicht abgeschlossen, weil jemand „geringes Risiko“ in ein Kommentarfeld geschrieben hat. Sie ist abgeschlossen, wenn der Datensatz Einstufung, Behandlungsentscheidung, Verantwortlichen, Fälligkeitstermin, Restrisiko, Genehmigungsstatus und Überprüfungsdatum enthält.

Für KMU wird dieselbe Disziplin skaliert angewendet. Die KMU-Risikomanagement-Richtlinie legt fest:

Jeder Risikoeintrag muss enthalten: Beschreibung, Eintrittswahrscheinlichkeit, Auswirkung, Wert, Verantwortlichen und Risikobehandlungsplan.

Das Prinzip ist Verhältnismäßigkeit, nicht Informalität. Kleinere Organisationen können ein einfacheres Register verwenden, aber jedes Risiko benötigt weiterhin Beschreibung, Wert, Verantwortlichen und Risikobehandlungsplan.

Die ISO/IEC 27001:2022-Risiko-Engine für Datenschutz nutzen

Datenschutzrisiken sollten nicht außerhalb der Risikomanagementmethode der Organisation geführt werden. ISO/IEC 27001:2022 stellt bereits die Managementsystem-Engine bereit: Kontext, interessierte Parteien, Geltungsbereich, Führung, Risikobeurteilung, Behandlung, operative Steuerung, dokumentierte Information, Leistungsbewertung und kontinuierliche Verbesserung.

Die Klauseln 4.1 bis 4.4 verlangen, dass die Organisation interne und externe Themen, Anforderungen interessierter Parteien, den ISMS-Geltungsbereich und die ISMS-Prozesse versteht. Für Datenschutz umfassen interessierte Parteien Kunden, betroffene Personen, Beschäftigte, Regulierungsbehörden, Auftragsverarbeiter, Unterauftragsverarbeiter, Aufsichtsbehörden, gegebenenfalls Finanzaufsichtsbehörden und vertragliche Kunden.

Klausel 6.1.2 verlangt einen Prozess zur Informationssicherheitsrisikobeurteilung. Klausel 6.1.3 verlangt Informationssicherheitsrisikobehandlung, einschließlich Auswahl von Kontrollen, Erstellung einer Anwendbarkeitserklärung, Formulierung eines Risikobehandlungsplans und Einholung der Genehmigung des Plans und der Restrisiken durch den Risikoverantwortlichen. Die Klauseln 8.2 und 8.3 verlangen, dass Informationssicherheitsrisikobeurteilungen und -behandlungen in geplanten Abständen oder bei wesentlichen Änderungen durchgeführt und die Ergebnisse als dokumentierte Information aufbewahrt werden.

Die Enterprise-Risikomanagement-Richtlinie von Clarysec ist in Klausel 5.1 an dieser Struktur ausgerichtet:

Ein formaler Risikomanagementprozess ist gemäß ISO/IEC 27005 und ISO 31000 aufrechtzuerhalten und umfasst Risikoidentifizierung, Analyse, Bewertung, Behandlung, Überwachung und Kommunikation.

Für Datenschutz müssen die Risikokriterien die Auswirkungen auf betroffene Personen einbeziehen, nicht nur geschäftliche Auswirkungen. Ein geringer finanzieller Verlust kann dennoch eine hohe datenschutzbezogene Auswirkung haben, wenn die Verarbeitung besondere Kategorien personenbezogener Daten, schutzbedürftige Personen, Profiling, Intransparenz, unrechtmäßige Aufbewahrung, die fehlende Möglichkeit zur Ausübung von Rechten oder immaterielle Schäden betrifft.

Clarysecs Zenith Blueprint: 30-Schritte-Roadmap für Auditoren erläutert dies in der Risikomanagementphase, Schritt 10:

Bei der Definition von Auswirkungen ist es sinnvoll, die Stufen auf Ihre spezifische Unternehmensgröße zu beziehen. Beispiel: „Wesentliche finanzielle Auswirkung = Verlust > $100k“ (an Ihren Kontext anpassen). Berücksichtigen Sie außerdem regulatorische Auswirkungen: Beispielsweise kann eine Datenschutzverletzung personenbezogener Daten aufgrund von GDPR-Bußgeldern und Meldepflichten automatisch „Wesentlich“ oder „Schwerwiegend“ sein, selbst wenn der direkte finanzielle Verlust unklar ist.

Diese Orientierung ist besonders wichtig für KI-Analysen, Gesundheitsdaten, Finanzprofiling, Beschäftigtenüberwachung und Kundenbewertung. Der Schaden kann rechtlich, reputationsbezogen, diskriminierend, operativ, vertraglich oder persönlich sein.

Ein praktisches Beispiel: KI-gestützte Patientenanalysen

Zurück zu Maria und David. Ihre Healthtech-Plattform wird besondere Kategorien von Gesundheitsdaten nach GDPR Article 9 verarbeiten. Sie nutzt Patientenhistorie, Termindaten, klinische Notizen und Modellergebnisse, um Risikoerkenntnisse zu erzeugen.

Mit Zenith Blueprint beginnen sie bei Schritt 9: Identifizierung von Assets, Bedrohungen und Schwachstellen:

Erfassen Sie für jedes Asset zentrale Angaben: Name/Beschreibung, Verantwortlicher, Standort und Klassifizierung (Sensitivität). Ein Asset könnte beispielsweise „Kundendatenbank – Eigentümer IT-Abteilung – gehostet auf AWS – enthält personenbezogene und finanzielle Daten (hohe Sensitivität)“ sein.

Derselbe Schritt ergänzt die Datenschutzperspektive:

Stellen Sie sicher, dass Assets mit personenbezogenen Daten gekennzeichnet sind (für GDPR- Relevanz) und kritische Service-Assets vermerkt werden (für eine mögliche NIS2-Anwendbarkeit, wenn Sie in einem regulierten Sektor tätig sind).

Marias Team identifiziert die KI-Patientenanalyseplattform, Patientendatenbank, das Data Warehouse, die Modelltrainingspipeline, das Klinik-Dashboard, Cloud-Speicher, den Identitätsanbieter, Audit-Protokolle, die Support-Ticket-Plattform und ein Drittanbieter-Analysewerkzeug. Jedes Asset erhält einen Verantwortlichen, Standort, eine Klassifizierung und einen PII-Bezug.

Anschließend definieren sie Risikoszenarien. Eines ist der unbefugte Zugriff auf Gesundheitsakten. Ein anderes ist die unbeabsichtigte Offenlegung über Analyseexporte. Ein drittes ist KI-Modellbias aufgrund verzerrter Trainingsdaten, der zu unfairer oder diskriminierender Risikobewertung von Patienten führt.

Schritt 11 von Zenith Blueprint erklärt die Rolle des Risikoregisters:

Das Risikoregister ist typischerweise eine Tabelle (unsere Vorlage „Risk Register and SoA Builder.xlsx“ enthält hierfür ein eigenes Arbeitsblatt). Es dient als zentrales Verzeichnis der Risiken.

Ein Datenschutz-Risikoeintrag für das Szenario des KI-Modellbias kann so aussehen:

Dieser Eintrag leistet, was die alte Tabelle nicht konnte. Er verbindet eine Verarbeitungstätigkeit mit einem Asset, einer Bedrohung, einer Schwachstelle, einem Risiko für betroffene Personen, einem Verantwortlichen, einem Wert, einem Risikobehandlungsplan und einer Nachweiskette.

Da die Verarbeitung ein hohes Risiko aufweist und besondere Kategorien personenbezogener Daten betrifft, ist die DPIA kein separater nachgelagerter Gedanke. Sie wird zur vertieften Bewertungsstufe für ein Risiko, das bereits im System erfasst ist. Die Enterprise-Richtlinie zu Datenschutz und Privatsphäre legt fest:

Alle wesentlichen Änderungen an Systemen oder Prozessen, die personenbezogene Informationen (PII) betreffen, erfordern eine dokumentierte Datenschutz-Folgenabschätzung (DPIA), die durch den Datenschutzbeauftragten (DPO) zu prüfen ist.

Für ein hohes Restrisiko des Verantwortlichen ergänzt die Richtlinie zur Datenschutz-Risikobeurteilung und DPIA:

[Verantwortlicher] Die oberste Leitung MUSS die Akzeptanz hoher Restrisiken im Datenschutz in REG04 genehmigen, bevor eine Hochrisiko-Verarbeitung durch den Verantwortlichen beginnt oder fortgesetzt wird.

Die Einführungsentscheidung ist nun nachvollziehbar: Was hat sich geändert, was wurde bewertet, welche Risiken wurden identifiziert, welche Kontrollen wurden ausgewählt, wer ist für die Behandlung verantwortlich, wer hat das Restrisiko genehmigt und wann wird die Entscheidung überprüft.

Von Risiken zu Kontrollen mit Zenith Controls

Datenschutz-Risikobeurteilung ist nur dann wirksam, wenn sie zu Kontrollentscheidungen führt. Clarysecs Zenith Controls: Cross-Compliance-Leitfaden ist der Cross-Compliance-Leitfaden, der ISO/IEC 27001:2022- und ISO/IEC 27002:2022-Kontrollen Anforderungen aus weiteren Rahmenwerken zuordnet. Es handelt sich nicht um einen separaten Kontrollsatz. Er hilft Teams zu verstehen, wie Kontrollnachweise mehrere Verpflichtungen unterstützen.

Für die Datenschutz-Risikobeurteilung hebt Zenith Controls drei zentrale ISO/IEC 27002:2022-Kontrollen hervor:

Kontrolle 5.34 unterstützt außerdem GDPR Article 25 und Article 32, NIS2 Article 21-Maßnahmen zum Cybersicherheitsrisikomanagement, DORA-Erwartungen an das Management von IKT-Risiken sowie NIST CSF 2.0-Ergebnisse wie GV.OC-03 für gesetzliche, regulatorische, vertragliche, datenschutzbezogene und bürgerrechtliche Verpflichtungen sowie PR.DS-01 zum Schutz ruhender Daten.

Schritt 13 von Zenith Blueprint verbindet diese Entscheidungen mit der Anwendbarkeitserklärung:

Verknüpfen Sie Vorschriften: Wenn bestimmte Kontrollen speziell zur Einhaltung von GDPR, NIS2 oder DORA umgesetzt werden, können Sie dies entweder im Risikoregister (als Teil der Begründung der Risikoauswirkung) oder in den SoA-Notizen festhalten.

So wird aus einer Datenschutzfeststellung eine ISMS- und PIMS-Kontrollentscheidung, nicht nur ein rechtlicher Kommentar.

Lieferanten- und Auftragsverarbeiterrisiken müssen vor der Genehmigung bewertet werden

Viele Datenschutzfehler beginnen in der Lieferanten-Governance. Ein Auftragsverarbeiter fügt einen neuen Unterauftragsverarbeiter hinzu. Ein Support-Anbieter erhält Produktionszugriff. Eine Analyseplattform speichert Ereignisdaten in einer neuen Region. Die Beschaffung unterzeichnet den Vertrag, bevor der Datenschutz das Risiko sieht.

Die Enterprise-Richtlinie zum Datenschutzmanagement für Auftragsverarbeiter, Unterauftragsverarbeiter und Drittparteien von Clarysec verhindert dies, indem sie Lieferantenprüfung, REG04 und das Drittparteienregister miteinander verbindet:

[Beide] Der Datenschutzverantwortliche / PIMS-Manager MUSS das Datenschutzrisiko- und DPIA-Screening in REG04 für Hochrisiko-Beziehungen mit Auftragsverarbeitern und wesentliche datenschutzbezogene Änderungen bei Drittparteien vor der Genehmigung auslösen; die REG04-Referenz ist in REG08 zu erfassen.

Für KMU legt die Richtlinie zur Lieferanten- und Drittparteiensicherheit die Anforderung zur Prüfung vor der Beauftragung fest:

Vor der Beauftragung muss jeder Lieferant auf potenzielle Risiken geprüft werden. Diese Prüfung muss umfassen:

Die operative Botschaft ist eindeutig. Lieferantenrisiken werden vor der Genehmigung bewertet, nicht nach der Unterschrift.

Dies unterstützt auch NIS2 und DORA. NIS2 Article 21 verlangt Sicherheit der Lieferkette als Teil der Maßnahmen zum Cybersicherheitsrisikomanagement. DORA Articles 28 to 30 verlangen von Finanzunternehmen, IKT-Drittparteienrisiken zu steuern, vorvertragliche Bewertungen durchzuführen, vertragliche Schutzmaßnahmen aufrechtzuerhalten, Unterbeauftragungsrisiken zu verstehen, Abhängigkeiten zu überwachen und Ausstiege für kritische oder wichtige Funktionen zu planen.

Wenn ein Lieferant PII berührt oder datenschutzkritische Verarbeitung unterstützt, sollte der Datenschutz-Risikodatensatz den Lieferanten, die Verarbeitungsrolle, den Datenstandort, die Abhängigkeit von Unterauftragsverarbeitern, vertragliche Schutzmaßnahmen, Verpflichtungen bei Vorfällen, Aufbewahrungsregeln, den Überwachungsansatz und den Exit-Plan enthalten.

Ein Workflow, viele Ergebnisse für die Einhaltung

Der Vorteil eines integrierten PIMS-Workflows besteht darin, dass dieselben Nachweise mehrere Rahmenwerke unterstützen, ohne Arbeit zu duplizieren.

NIST CSF 2.0 ist besonders nützlich für die Kommunikation mit Führungskräften. Seine GOVERN-Funktion umfasst organisatorischen Kontext, Risikomanagementstrategie, Richtlinie, Rollen, Aufsicht und Lieferkettenrisiko. Seine Organisationsprofile helfen, Ist- und Zielergebnisse in einen priorisierten Maßnahmenplan zu übersetzen, beispielsweise ein Risikoregister oder einen Maßnahmen- und Meilensteinplan.

Für Organisationen, die NIS2, DORA oder branchenspezifischen Regeln unterliegen, unterstützen Nachweise zu Datenschutzrisiken außerdem Cybersicherheits-Governance, Lieferantenaufsicht, Vorfallsbereitschaft und Resilienzberichterstattung.

Datenschutz-Risikobehandlung ist mehr als Verschlüsselung

Verschlüsselung ist wichtig, kann aber keine ungültige Rechtsgrundlage, übermäßige Erhebung, nicht offengelegtes Profiling, unfaire Verarbeitung, unrechtmäßige Aufbewahrung oder einen Auftragsverarbeiter beheben, der außerhalb von Weisungen handelt.

Die KMU-Richtlinie zu Datenschutz und Privatsphäre legt fest:

Kontrollen müssen umgesetzt werden, um identifizierte Risiken zu reduzieren, einschließlich Verschlüsselung, Anonymisierung, sicherer Entsorgung und Zugriffsbeschränkungen.

Das sind starke Beispiele, aber die Behandlung muss zum Szenario passen. Ein Risikobehandlungsplan für Datenschutzrisiken kann die Eingrenzung des Verarbeitungszwecks, die Entfernung unnötiger Datenkategorien, Aggregation oder Pseudonymisierung von Daten, Aktualisierung von Datenschutzhinweisen, Änderung der Rechtsgrundlage, soweit angemessen, Begrenzung der Aufbewahrung, Beschränkung von Zugriffen, Ergänzung von Protokollierung, Aktualisierung von Verträgen, Abschluss einer DPIA, Verschiebung der Produktivsetzung oder Ablehnung einer weiterhin unzulässigen Verarbeitung umfassen.

Die Enterprise-Risikomanagement-Richtlinie verstärkt die Behandlungsplanung für Risiken oberhalb der Toleranz:

Für alle Risiken, die oberhalb des Toleranzniveaus eingestuft sind, muss ein zugehöriger Risikobehandlungsplan bestehen, der Folgendes festlegt:

In der Praxis bedeutet dies: Ein hohes Datenschutzrisiko kann nicht durch Schweigen akzeptiert werden. Es muss behandelt, soweit angemessen übertragen, vermieden oder durch den richtigen rechenschaftspflichtigen Verantwortlichen formal akzeptiert werden.

Überprüfungsauslöser halten die Bewertung aktuell

Eine Datenschutz-Risikobeurteilung, die nie erneut geprüft wird, wird zu veralteten Nachweisen. ISO/IEC 27001:2022 Klauseln 8.2 und 8.3 verlangen Risikobeurteilung und -behandlung in geplanten Abständen oder bei wesentlichen Änderungen. GDPR-Rechenschaftspflicht erwartet aktuelle Entscheidungen. ISO/IEC 27701:2025 hängt von Überwachung und kontinuierlicher Verbesserung ab.

Eine REG04-Bewertung sollte erneut geöffnet werden, wenn sich der Zweck ändert, neue Datenkategorien hinzukommen, besondere Kategorien personenbezogener Daten betroffen werden, sich die Rechtsgrundlage ändert, ein Auftragsverarbeiter oder Unterauftragsverarbeiter wechselt, die Speicherung in eine neue Region verlagert wird, Aufbewahrungsfristen geändert werden, sich die Profiling-Logik ändert, eine Datenschutzverletzung oder ein Beinahe-Vorfall eintritt, Kundenverträge geändert werden oder eine neue NIS2-, DORA- oder branchenspezifische Verpflichtung gilt.

Vorfallsprozesse sollten in den Workflow für Datenschutzrisiken zurückwirken. NIS2 Article 23 legt eine gestufte Meldung erheblicher Vorfälle fest. DORA Articles 17 to 20 verlangen Aufzeichnung, Klassifizierung, Eskalation, Kommunikation, Ursachenanalyse und Verbesserung bei IKT-bezogenen Vorfällen. Auch GDPR-Pflichten bei Verletzungen des Schutzes personenbezogener Daten können ausgelöst werden. Wenn ein Vorfall schwache Zugriffskontrollen, übermäßige Aufbewahrung, unklare Lieferantenbenachrichtigung oder unzureichende Kundenweisungen offenlegt, muss REG04 aktualisiert werden.

Was Auditoren erwarten werden

Ein belastbarer Workflow für Datenschutzrisiken sollte mehreren Prüfungsperspektiven standhalten.

Die Enterprise-Richtlinie zu Datenschutz und Privatsphäre verlangt außerdem interne Audittätigkeiten:

Ein internes Audit zur Einhaltung des Datenschutzes ist jährlich oder bei wesentlichen organisatorischen oder regulatorischen Änderungen durchzuführen. Der Auditumfang muss umfassen:

Dadurch entsteht ein Management-Feedbackkreislauf. Sind REG02-Datensätze vollständig? Erfolgen REG04-Screenings rechtzeitig? Werden DPIAs durchgeführt, wenn sie erforderlich sind? Sind hohe Restrisiken genehmigt? Werden Lieferantenänderungen erfasst? Werden Risikobehandlungspläne abgeschlossen? Stimmen Datenschutzhinweise mit der tatsächlichen Verarbeitung überein?

Checkliste für Ihr nächstes Meeting zu Datenschutzänderungen

Verwenden Sie diese Checkliste, bevor eine neue Verarbeitungstätigkeit, Produktfunktion, ein Lieferant, Modell oder Support-Workflow produktiv gesetzt wird.

Diese Checkliste ersetzt keine Richtlinie. Sie ist ein praktisches Mittel, um Richtlinien in Produkt-, Beschaffungs-, Engineering-, Compliance-, Rechts- und Leitungsgremien-Meetings operativ umzusetzen.

Datenschutz-Rechenschaftspflicht in ein funktionierendes System überführen

ISO/IEC 27701:2025 und GDPR-Rechenschaftspflicht verlangen mehr als Dokumente. Sie verlangen ein funktionierendes System, das Verarbeitungsaufzeichnungen, Rechtsgrundlage, Datenschutzrisiko, DPIA-Entscheidungen, Lieferanten, Kontrollen, Verantwortliche, Genehmigungen und Nachweise verbindet.

Beginnen Sie mit der Risikomanagementphase des Zenith Blueprint, insbesondere mit den Schritten 9 bis 13. Nutzen Sie den Risk Register and SoA Builder, um Assets, Bedrohungen, Schwachstellen, Datenschutzrisiken, Behandlungsentscheidungen und Kontrollreferenzen zu verbinden. Verwenden Sie anschließend Zenith Controls, um PII-Schutz, Asset-Inventar und Lieferantensicherheit den Assurance-Erwartungen von GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 und COBIT 19 zuzuordnen.

Richten Sie die operativen Richtlinien aus, die den Workflow durchsetzbar machen: Richtlinie zur Datenschutz-Risikobeurteilung und DPIA, Richtlinie zum Verzeichnis der PII-Verarbeitung und zur Rechtsgrundlage, Richtlinie zum Datenschutzmanagement für Auftragsverarbeiter, Unterauftragsverarbeiter und Drittparteien, Risikomanagement-Richtlinie und Richtlinie zu Datenschutz und Privatsphäre. Kleinere Teams können außerdem die KMU-Richtlinien von Clarysec nutzen, während größere Organisationen Governance über Enterprise-Richtlinien strukturieren können.

Wenn Ihr Team neue Verarbeitungen einführt, Lieferanten ändert, sich auf ISO/IEC 27701:2025 vorbereitet oder GDPR-Rechenschaftsnachweise wiederholbar machen möchte, beginnen Sie mit einer laufenden Verarbeitungstätigkeit. Öffnen Sie REG02, führen Sie das REG04-Screening durch, ordnen Sie die Risiken Kontrollen zu, weisen Sie Verantwortliche für die Behandlung zu und überprüfen Sie das Restrisiko mit dem richtigen Entscheidungsträger.

Dieser einzelne Workflow ist der Punkt, an dem Datenschutz-Governance operativ wird.