ISO/IEC 27701:2025-Umstellungsplan für ein GDPR-PIMS

Die Frage des Leitungsorgans, die eine Lücke bei Datenschutznachweisen offenlegt
Anya, CISO eines schnell wachsenden FinTech-Unternehmens, blickte auf die Tagesordnung der Sitzung des Leitungsorgans. Zwischen Umsatzprognosen und Marktexpansion stand der Punkt, der sie seit einer Woche beschäftigte: GDPR-Einhaltung und Bereitschaft für ISO/IEC 27701:2025.
Das Unternehmen hatte ein GDPR-Programm. Es gab einen DPO, Datenschutzhinweise, Auftragsverarbeitungsverträge, eine DSFA-Vorlage und einen Prozess für Betroffenenanfragen. Der Vertrieb hatte Unternehmenskunden bereits mitgeteilt, dass das Unternehmen auf ein ISO/IEC 27701:2025 Privacy Information Management System (PIMS) hinarbeite. Das Produktteam bereitete eine KI-gestützte Analysefunktion vor, die Benutzerverhalten von Kunden, Support-Tickets, Abrechnungsmetadaten und Kontoaktivitäten verarbeiten sollte. Ein wichtiger EU-Kunde hatte Nachweise angefordert, dass Verpflichtungen als Verantwortlicher und als Auftragsverarbeiter getrennt gesteuert werden.
Die unbequeme Wahrheit war nicht, dass Datenschutzdokumentation fehlte. Das Problem waren Nachweise.
Das Verzeichnis der Verarbeitungstätigkeiten zeigte nicht durchgängig Rechtsgrundlage, Aufbewahrung, Abhängigkeiten von Unterauftragsverarbeitern, internationale Übermittlungen oder ob das Unternehmen für den jeweiligen Verarbeitungszweck als Verantwortlicher oder Auftragsverarbeiter handelte. Lieferantenprüfungen konzentrierten sich auf Sicherheit, aber nicht ausreichend auf Datenschutzweisungen, Löschung, Unterstützung bei Datenschutzverletzungen, Auditrechte und an Unterauftragsverarbeiter weiterzugebende Verpflichtungen. Engineering führte Sicherheitsprüfungen durch, doch Datenschutz durch Technikgestaltung wurde nicht immer ausgelöst, wenn eine Funktion den Zweck der Verarbeitung änderte. Das interne Audit prüfte GDPR auf hoher Ebene, konnte eine Verpflichtung jedoch nicht immer bis zum Verantwortlichen, zur Kontrolle, zum Register, zum Test und zur Entscheidung aus der Managementbewertung zurückverfolgen.
Genau das ist die eigentliche Herausforderung bei der Umstellung auf ISO/IEC 27701:2025. Es ist nicht nur ein Zertifizierungsprojekt. Es ist ein Reifegradtest: Kann Ihre Organisation Datenschutz als gesteuertes System betreiben und nicht nur als Ordner mit Rechtsdokumenten?
Für GDPR-getriebene Organisationen besteht die Antwort darin, das ISO/IEC 27001:2022-Informationssicherheitsmanagementsystem zu einem Datenschutzmanagementsystem zu erweitern, das PIMS-Geltungsbereich, Verzeichnis der Verarbeitungstätigkeiten, Datenschutz-Risikobeurteilung, DSFAs, Lieferanten-Governance, Umgang mit Datenschutzverletzungen, Kontrollzuordnung, internes Audit und kontinuierliche Verbesserung integriert.
Warum fragmentierte GDPR-Einhaltung unter Auditdruck scheitert
Viele Organisationen behandeln Datenschutz-Compliance als getrennten Arbeitsstrang neben der Informationssicherheit. Die Rechtsabteilung verwaltet Verträge. IT verwaltet Verschlüsselung. Die Beschaffung verwaltet Lieferanten. Der DPO beantwortet Auskunftsersuchen betroffener Personen. Produktteams bringen Funktionen auf den Markt. Die Sicherheitsfunktion bearbeitet Vorfälle. Jede Funktion kann sinnvolle Arbeit leisten, doch ohne ein einheitliches Betriebsmodell werden Datenschutznachweise fragmentiert.
Dies führt zu vier wiederkehrenden Problemen.
Erstens duplizieren Teams Aufwand. Risikobeurteilungen für Sicherheit und Datenschutz können unterschiedliche Methoden, unterschiedliche Bewertungen und unterschiedliche Verantwortliche verwenden.
Zweitens entstehen Lücken in Drittparteienservices, Cloud-Konfigurationen, Analysepipelines, Support-Werkzeugen und neuen Entwicklungsprojekten, weil niemand eine vollständige Sicht auf Datenflüsse personenbezogener Daten hat.
Drittens werden Nachweise für Leitungsorgan und Kunden schwierig. Eine Sammlung unverbundener Richtlinien belegt nicht, dass Datenschutzverpflichtungen umgesetzt, überwacht und verbessert werden.
Viertens konvergieren moderne regulatorische Erwartungen. GDPR erwartet Rechenschaftspflicht und Nachweise. NIS2 erwartet Governance, Risikomanagement, Vorfallbearbeitung, Zugriffskontrolle, Asset-Management und Sicherheit der Lieferkette. DORA erwartet von Finanzunternehmen, IKT-Risiken, Vorfälle, Resilienztests, Drittparteienverträge und Exit-Strategien zu steuern. Ein isoliertes Datenschutzprogramm kann all dies nicht effizient unterstützen.
Der belastbarere Ansatz besteht darin, die ISO/IEC 27701:2025-Umstellung auf dem ISO/IEC 27001:2022-ISMS aufzubauen. ISO/IEC 27001:2022 liefert die Managementsystemstruktur für Kontext, interessierte Parteien, Geltungsbereich, Risikobeurteilung, Risikobehandlung, Ziele, operative Planung, internes Audit, Managementbewertung, Korrekturmaßnahmen und kontinuierliche Verbesserung. ISO/IEC 27002:2022 liefert die Kontrollgrundlage für rechtliche Verpflichtungen, Asset-Inventar, Lieferantenbeziehungen, Cloud-Services, Zugriffskontrolle, Protokollierung, Überwachung, Löschung, Maskierung sowie Datenschutz und Schutz personenbezogener Daten.
Die Umstellung muss fünf Fragen beantworten:
- Was ist der PIMS-Geltungsbereich, einschließlich Rollen als Verantwortlicher, Auftragsverarbeiter, gemeinsam Verantwortlicher und Unterauftragsverarbeiter?
- Welche Verarbeitungstätigkeiten, Datenkategorien, Zwecke, Rechtsgrundlagen, Empfänger, Übermittlungen und Aufbewahrungsregeln liegen im Geltungsbereich?
- Welche Datenschutzrisiken erfordern DSFA, Behandlung, Genehmigung und Restrisikoakzeptanz?
- Welche Richtlinien, Kontrollen, Verträge, technischen Schutzmaßnahmen und Aufzeichnungen belegen die GDPR-Rechenschaftspflicht?
- Wie bestätigen internes Audit und Managementbewertung, dass das PIMS wirksam betrieben und verbessert wird?
Phase 1: PIMS-Geltungsbereich freigeben, bevor Richtlinien überarbeitet werden
Ein belastbarer ISO/IEC 27701:2025-Umstellungsplan beginnt nicht mit der Überarbeitung jeder Datenschutzrichtlinie. Er beginnt mit Governance und Geltungsbereich.
Ihr bestehender ISMS-Geltungsbereich ist der Ausgangspunkt, der PIMS-Geltungsbereich muss jedoch die Verarbeitung personenbezogener Daten, Geschäftsbereiche, Services, Systeme, Regionen, Cloud-Umgebungen, Lieferanten und Datenschutzrollen ausdrücklich identifizieren. Das Leitungsorgan oder die oberste Leitung muss verstehen, warum die Umstellung relevant ist, insbesondere dort, wo Kunden, Aufsichtsbehörden oder branchenspezifische Verpflichtungen wie DORA von nachweisbarem Datenschutz und nachweisbarer Resilienz abhängen.
Clarysecs Richtlinie zum Privacy Information Management System [PIMS-Richtlinie] macht die Freigabe des Geltungsbereichs verbindlich:
[Beide] Die oberste Leitung MUSS den PIMS-Geltungsbereich in REG01 vor der erstmaligen PIMS-Umsetzung und innerhalb von 30 Tagen nach jeder wesentlichen Änderung freigeben.
Für Umstellungsprogramme, die die Klauselnummerierung aus der Clarysec-Richtlinienbibliothek verwenden, ist dies die zentrale Erwartung in Klausel 4.1.1. Sie ist wichtig, weil ein nur impliziter Datenschutz-Geltungsbereich eine der häufigsten Auditschwächen ist. Wenn sich Produktlinie, Rechtsraum, Verarbeitungsrolle, Lieferant, Cloud-Region oder Geschäftsprozess wesentlich ändern, darf der PIMS-Geltungsbereich nicht der Auslegung überlassen bleiben.
Dieselbe Richtlinie überführt die Umstellung außerdem in ein gesteuertes Programm:
[Beide] Der Privacy Lead / PIMS-Manager MUSS den PIMS-Umsetzungsplan vor dem PIMS-Rollout oder einer wesentlichen PIMS-Änderung in REG12 dokumentieren.
REG12 ist kein administrativer Mehraufwand. Es ist das Steuerungsartefakt der Umstellung. Es sollte zeigen, was sich ändert, warum es relevant ist, wer verantwortlich ist, welche Nachweise erforderlich sind, welche Risiken offen sind und wann die Bereitschaft geprüft wird.
Phase 2: ein registergeführtes Umstellungsinventar aufbauen
Für GDPR-Datenschutzmanagementsysteme sollte der erste praktische Liefergegenstand ein Nachweisinventar sein, keine Richtlinienüberarbeitung. Clarysec verwendet einen registergeführten Ansatz, weil Register Datenschutzabsichten in auditierbare Nachweise überführen.
Der PIMS-Geltungsbereich in REG01 ist mit Verarbeitungstätigkeiten in REG02, Kontrollanwendbarkeit in REG03, Datenschutzrisiko- und DSFA-Screening in REG04 sowie Umsetzungsplanung in REG12 verbunden.
Die Richtlinie zu Datenschutz und Privatsphäre - SME [SME-Datenschutzrichtlinie] legt die Basislinie fest:
Der Datenschutzkoordinator muss ein Register aller Verarbeitungstätigkeiten für personenbezogene Daten pflegen, einschließlich Datenkategorien, Zweck, Rechtsgrundlage und Aufbewahrungsfristen.
Für größere Umgebungen erhöht die Richtlinie zu Datenschutz und Privatsphäre [P17 – Richtlinie zu Datenschutz und Privatsphäre] die Governance-Erwartung:
Die Organisation muss ein formales Datenschutz-Governance-Rahmenwerk unterhalten, das zur Durchsetzung dieser Richtlinie in das Informationssicherheitsmanagementsystem (ISMS) integriert ist.
Diese Integration ist das Umstellungsprinzip. Ein Verzeichnis der Verarbeitungstätigkeiten ohne Risikobehandlung ist eine Tabellenkalkulation. Eine DSFA ohne Kontrollverantwortung ist ein Rechtsvermerk. Ein Auftragsverarbeitungsvertrag mit einem Lieferanten ohne Überwachung liegt in der Vertragsablage. Die ISO/IEC 27701:2025-Umstellung sollte diese Artefakte in einem gesteuerten PIMS zusammenführen.
| Umstellungselement | Zu erhebende Nachweise | Clarysec-Artefakt |
|---|---|---|
| PIMS-Geltungsbereich | Geschäftsbereiche, Systeme, Regionen, Verarbeitungsrollen, Ausschlüsse, Abhängigkeiten | REG01 PIMS-Geltungsbereich |
| Verarbeitungstätigkeiten | Zweck, Rechtsgrundlage, Datenkategorien, betroffene Personen, Aufbewahrung, Empfänger, Übermittlungen | REG02 Verzeichnis der Verarbeitungstätigkeiten |
| Kontrollanwendbarkeit | Einbezogene Kontrollen, ausgeschlossene Kontrollen, Umsetzungsstatus, Begründung | REG03 PIMS-Kontrollanwendbarkeit |
| DSFA-Auslöser | Risikoreiche Verarbeitung, neue Zwecke, besondere Kategorien personenbezogener Daten, Überwachung, automatisierte Entscheidungen | REG04 Datenschutzrisiko- und DSFA-Screening |
| Umstellungsplan | Verantwortliche, Meilensteine, Auditplan, Eingaben für die Managementbewertung, Abhilfemaßnahmen | REG12 PIMS-Umsetzungsplan |
Dieses Inventar unterstützt außerdem ein Ist-Profil (Current Profile) und ein Soll-Profil (Target Profile) im Stil des NIST Cybersecurity Framework 2.0. Das Current Profile dokumentiert bestehende Datenschutzprozesse, Kontrollen und Nachweise. Das Target Profile definiert das angestrebte, an ISO/IEC 27701:2025 ausgerichtete PIMS. Die Lücke zwischen beiden wird zum Umstellungs-Backlog.
Phase 3: GDPR-Rechenschaftspflicht in das PIMS abbilden
GDPR-Rechenschaftspflicht ist das Rückgrat von Datenschutznachweisen. GDPR gilt für Verarbeitung im Kontext einer EU-Niederlassung und kann auch für Verantwortliche oder Auftragsverarbeiter außerhalb der EU gelten, die Personen in der EU Waren oder Dienstleistungen anbieten oder deren Verhalten beobachten. GDPR definiert personenbezogene Daten weit, einschließlich direkter und indirekter Identifikatoren. GDPR unterscheidet Verantwortliche von Auftragsverarbeitern und definiert eine Verletzung des Schutzes personenbezogener Daten als Verletzung der Sicherheit, die zur unbeabsichtigten oder unrechtmäßigen Vernichtung, zum Verlust, zur Veränderung, zur unbefugten Offenlegung von oder zum unbefugten Zugang zu personenbezogenen Daten führt.
Für die Umstellungsplanung ist entscheidend, dass GDPR nicht dadurch erfüllt wird, dass man sagt: „Wir haben Sicherheitskontrollen.“ Article 5 verlangt rechtmäßige, faire und transparente Verarbeitung, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität und Vertraulichkeit sowie nachweisbare Rechenschaftspflicht. Article 6 verlangt eine Rechtsgrundlage. Article 9 fügt strengere Bedingungen für besondere Kategorien personenbezogener Daten hinzu. Article 25 verlangt Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen. Article 28 verlangt Auftragsverarbeiter-Governance. Article 32 verlangt Sicherheit der Verarbeitung.
Clarysecs Richtlinie zur rechtlichen und regulatorischen Einhaltung - SME [SME-Richtlinie zur rechtlichen und regulatorischen Einhaltung] bietet kleineren Organisationen einen einfachen Ausgangspunkt:
Der General Manager (GM) muss ein einfaches, strukturiertes Einhaltungsregister führen, das Folgendes auflistet:
Die Enterprise-Richtlinie zur rechtlichen und regulatorischen Einhaltung [P37 Richtlinie zur rechtlichen und regulatorischen Einhaltung] ist expliziter:
Alle gesetzlichen und regulatorischen Verpflichtungen müssen bestimmten Richtlinien, Kontrollen und Verantwortlichen innerhalb des Informationssicherheitsmanagementsystems (ISMS) zugeordnet werden.
Dieser Satz ist der Unterschied zwischen informeller GDPR-Einhaltung und auditbereitem Datenschutzmanagement. Jede wesentliche GDPR-Verpflichtung sollte einer Richtlinie, einer Kontrolle, einem Verantwortlichen, einem Registerfeld und einer Nachweisquelle zugeordnet sein.
| Bereich der GDPR-Verpflichtung | PIMS-Umstellungsnachweis | Operativ Verantwortlicher |
|---|---|---|
| Rechtsgrundlage und Zweckbindung | REG02-Verarbeitungsaufzeichnung mit Zweck, Rechtsgrundlage, Rolle und Überprüfungsdatum | Privacy Lead und Prozessverantwortlicher |
| Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen | Checkliste für Änderungsannahme, DSFA-Screening, Architekturprüfung, Genehmigungsaufzeichnung | Product Owner und Sicherheitsarchitekt |
| Auftragsverarbeiter-Governance | Auftragsverarbeitungsvertrag, Lieferantenrisikobeurteilung, Liste der Unterauftragsverarbeiter, Auditrechte, Klausel zur Unterstützung bei Datenschutzverletzungen | Beschaffung und Recht |
| Rechte betroffener Personen | Anfrageprotokoll, Aufzeichnung zur Identitätsprüfung, Nachweis der Erfüllung, Ausnahmeentscheidungen | Datenschutzbetrieb |
| Umgang mit Verletzungen des Schutzes personenbezogener Daten | Vorfallsaufzeichnung, Schweregradbewertung, Meldeentscheidung, gewonnene Erkenntnisse | Incident Manager und DPO |
| Aufbewahrung und Löschung | Aufbewahrungsplan, Löschungsnachweis, Ausnahmegenehmigung | Dateneigentümer und IT-Betrieb |
Nachweise für Verantwortliche und Auftragsverarbeiter müssen getrennt werden. Ein Verantwortlicher muss Rechtsgrundlage, Transparenz, Bearbeitung von Rechten, Zweckentscheidungen und Aufbewahrung nachweisen. Ein Auftragsverarbeiter muss Verarbeitung nach dokumentierter Weisung, Governance der Unterauftragsverarbeiter, Unterstützung des Verantwortlichen, Sicherheitsmaßnahmen, Unterstützung bei Meldungen von Datenschutzverletzungen sowie Rückgabe oder Löschung am Ende der Leistungserbringung nachweisen. Wenn die Organisation in beiden Rollen handelt, reicht ein generisches Nachweismodell nicht aus.
Phase 4: die SoA als Brücke für Datenschutzkontrollen nutzen
Ein häufiger Umstellungsfehler besteht darin, eine eigenständige PIMS-Kontrolltabelle zu erstellen, während die ISMS-Erklärung zur Anwendbarkeit (Statement of Applicability, SoA) unverändert bleibt. Dadurch entstehen zwei konkurrierende Kontrolluniversen.
ISO/IEC 27001:2022 verlangt, dass Entscheidungen zur Risikobehandlung in der Erklärung zur Anwendbarkeit abgebildet werden. Clarysecs Risikomanagement-Richtlinie [Risikomanagement-Richtlinie] legt fest:
Eine Statement of Applicability (SoA) muss alle Behandlungsentscheidungen widerspiegeln und aktualisiert werden, wenn die Kontrollabdeckung geändert wird.
Für die ISO/IEC 27701:2025-Umstellung wird die SoA zur Brücke zwischen ISMS und PIMS. Wenn eine DSFA oder Datenschutz-Risikobehandlung Verschlüsselung, Datenmaskierung, Löschkontrollen, Einwilligungsmechanismen, Due-Diligence-Prüfungen für Auftragsverarbeiter, Zugriffsbeschränkungen oder Überwachung des DSAR-Workflows ergänzt, müssen SoA und REG03 diese Entscheidung widerspiegeln.
Der Zenith Blueprint: 30-Schritte-Fahrplan für Auditoren [Zenith Blueprint] verstärkt dies in Schritt 6:
✓ Zusätzliche Kontrollen: Gibt es Kontrollen außerhalb von Annex A, die Sie aufnehmen könnten? ISO 27001
erlaubt die Aufnahme weiterer Kontrollen in die SoA. Beispielsweise möchten Sie möglicherweise
die Einhaltung von NIST CSF oder spezifische Datenschutzkontrollen aus ISO 27701 aufnehmen.
Zwingen Sie Datenschutzverpflichtungen nicht in Kontrollen, zu denen sie nicht passen. Ergänzen Sie bei Bedarf datenschutzspezifische Kontrollen, steuern Sie diese jedoch über dasselbe Modell für Risikobehandlung, Verantwortlichkeit, Umsetzungsstatus, Nachweise und Audit.
Die ISO/IEC 27002:2022-Kontrollen, die die Umstellung verankern
In Zenith Controls: Der Cross-Compliance-Leitfaden [Zenith Controls] sind zwei ISO/IEC 27002:2022-Kontrollen zentral für die ISO/IEC 27701:2025-Umstellung: 5.31 Gesetzliche, regulatorische und vertragliche Anforderungen sowie 5.34 Datenschutz und Schutz personenbezogener Daten.
Control 5.31 ist die Drehscheibe für Compliance. Sie unterstützt Identifizierung, Dokumentation, Verantwortlichkeit und Überprüfung gesetzlicher, regulatorischer, satzungsmäßiger und vertraglicher Anforderungen. Sie verbindet sich unmittelbar mit GDPR-Rechenschaftspflicht, NIS2-Governance, DORA-IKT-Risikoverpflichtungen, Kundendatenschutzklauseln und Verpflichtungen zur Verarbeitung in der Cloud.
Control 5.34 ist der operative Datenschutzanker. Zenith Controls erklärt die Abhängigkeit klar:
Ein Inventar von Informations-Assets (5.9) sollte Bestände personenbezogener Daten enthalten (Kundendatenbanken, HR-Dateien). Dies stützt 5.34, indem sichergestellt wird, dass die Organisation weiß, welche personenbezogenen Daten sie besitzt und wo sie sich befinden; das ist der erste Schritt zu ihrem Schutz.
Die Kontrollzuordnung sollte als praktische Design-Checkliste verwendet werden.
| ISO/IEC 27002:2022-Kontrolle | Relevanz für die Umstellung auf ein GDPR-PIMS |
|---|---|
| 5.9 Inventar von Informationen und anderen zugehörigen Assets | Identifiziert Repositories personenbezogener Daten, Systeme, Verantwortliche und Datenflüsse |
| 5.12 Klassifizierung von Informationen | Kennzeichnet personenbezogene Daten und besondere Kategorien personenbezogener Daten, damit stärkere Kontrollen greifen |
| 5.14 Informationsübertragung | Kontrolliert interne und externe Übermittlung personenbezogener Daten |
| 5.15 Zugriffskontrolle | Erzwingt Need-to-know-Zugriff auf personenbezogene Daten |
| 5.16 Identitätsmanagement | Stellt sicher, dass Identitäten mit Zugriff auf personenbezogene Daten gesteuert und nachvollziehbar sind |
| 5.19 Informationssicherheit in Lieferantenbeziehungen | Unterstützt Datenschutz bei Lieferanten, Zusicherung durch Auftragsverarbeiter und Überwachung von Drittparteien |
| 5.20 Berücksichtigung von Informationssicherheit in Lieferantenvereinbarungen | Verankert Sicherheits- und Datenschutzanforderungen in Verträgen |
| 5.21 Management der Informationssicherheit in der IKT-Lieferkette | Unterstützt die Governance von Unterauftragsverarbeitern und IKT-Abhängigkeiten |
| 5.23 Informationssicherheit bei der Nutzung von Cloud-Services | Stellt sicher, dass Cloud-Anbieter Datenschutz-, Standort-, Lösch- und Vertragserwartungen erfüllen |
| 5.31 Gesetzliche, regulatorische und vertragliche Anforderungen | Ordnet GDPR-, DORA-, NIS2-, Kunden- und Vertragsverpflichtungen zu |
| 5.33 Schutz von Aufzeichnungen | Unterstützt Aufbewahrung, Integrität und Schutz von Nachweisaufzeichnungen |
| 5.34 Datenschutz und Schutz personenbezogener Daten | Verankert Datenschutzkontrollen über den gesamten Lebenszyklus personenbezogener Daten |
| 5.35 Unabhängige Überprüfung der Informationssicherheit | Unterstützt internes Audit und externe Vertrauensbildung |
| 5.36 Einhaltung von Richtlinien, Regeln und Standards für Informationssicherheit | Prüft, ob Datenschutzkontrollen befolgt werden |
| 5.8 Informationssicherheit im Projektmanagement | Verankert Datenschutz und Sicherheit in der Projekt-Governance |
| 8.10 Informationslöschung | Unterstützt Speicherbegrenzung und Löschzusagen |
| 8.11 Datenmaskierung | Schützt personenbezogene Daten in Nicht-Produktivumgebungen und Analyseanwendungsfällen |
| 8.15 Protokollierung | Liefert Nachweise für Zugriffe und Aktivitäten mit personenbezogenen Daten |
| 8.16 Überwachungsaktivitäten | Erkennt verdächtige Aktivitäten und unterstützt die Untersuchung von Vorfällen |
| 8.32 Änderungsmanagement | Stellt sicher, dass Datenschutzfolgen vor Produktivänderungen geprüft werden |
An diesem Punkt wird Datenschutz operativ. Fragen Sie für jede risikoreiche Verarbeitungstätigkeit: Welche Assets enthalten die personenbezogenen Daten, wie sind sie klassifiziert, wer kann darauf zugreifen, wohin werden sie übermittelt, welche Cloud-Services verarbeiten sie, welche Aufbewahrungsregel gilt, welche Überwachung erkennt Missbrauch und welche Nachweise belegen, dass diese Kontrollen funktionieren?
Beispiel-Workflow: Onboarding einer KI-gestützten Analysefunktion
Zurück zu Anyas FinTech. Das Produktteam möchte eine KI-gestützte Analysefunktion einführen, die Benutzerkennungen, Kontoaktivitäten, Support-Metadaten, Abrechnungsmetadaten und Verhaltenssignale verarbeitet. Einige Unternehmenskunden könnten die Ergebnisse für Beschäftigtenüberwachung verwenden, was das Datenschutzrisiko erhöht.
Ein PIMS-Umstellungs-Workflow sollte die Einführung als kontrolliertes Datenschutzereignis behandeln.
Schritt 1: REG02 für Verarbeitungsrollen und Zwecke aktualisieren
Der Prozessverantwortliche erstellt oder aktualisiert die Verarbeitungsaufzeichnung. Pflichtfelder umfassen Zweck, Datenkategorien, Kategorien betroffener Personen, Rechtsgrundlage oder Weisung des Auftragsverarbeiters, Aufbewahrungsfrist, Systeme, Lieferanten, Empfänger, Übermittlungen und Rollenkontext.
Wenn das Unternehmen für Kundenanalysen Auftragsverarbeiter ist, muss REG02 die Verarbeitung nach Kundenweisungen ausweisen. Wenn es aggregierte Daten außerdem zur Verbesserung des eigenen Produkts nutzt, kann dieser separate Zweck das Unternehmen für die Sekundärverarbeitung zum Verantwortlichen machen. Die Aufzeichnung darf die Rollen nicht vermischen.
Schritt 2: REG04-Screening abschließen
Clarysecs Richtlinie zur Datenschutz-Risikobeurteilung und DSFA [Richtlinie zur Datenschutz-Risikobeurteilung und DSFA] verlangt:
[Beide] Der Prozessverantwortliche / Business Owner MUSS das Basis-REG04-Screening für alle aktiven REG02-Verarbeitungstätigkeiten im Geltungsbereich innerhalb von 30 Geschäftstagen nach Freigabe oder Erweiterung des PIMS-Geltungsbereichs abschließen.
Das Screening sollte Überwachung, Profiling, besondere Kategorien, schutzbedürftige Personen, neue Technologie, Verarbeitung in großem Umfang, grenzüberschreitende Datenübermittlungen oder geänderte Zwecke identifizieren. Wenn Schwellenwerte erreicht werden, wird eine DSFA ausgelöst.
Schritt 3: DSFA durchführen und Behandlung festlegen
Die P17 – Richtlinie zu Datenschutz und Privatsphäre verlangt:
Alle wesentlichen Änderungen an Systemen oder Prozessen, die personenbezogene Daten betreffen, erfordern eine dokumentierte Datenschutz-Folgenabschätzung (DPIA), die vom Datenschutzbeauftragten (DPO) geprüft wird.
In der Clarysec-Bibliothek ist dies mit Klausel 5.6 verknüpft. Die DSFA sollte Risiken wie übermäßige Erhebung, unklaren Zweck, Re-Identifizierung, unbefugten Administratorzugriff beim Kunden, unklare Aufbewahrung und Exponierung durch Unterauftragsverarbeiter bewerten. Behandlungen können feldbezogene Minimierung, Pseudonymisierung, kundenseitige Konfigurationskontrollen, Aufbewahrungs-Standardeinstellungen, stärkere Audit-Protokollierung, Aktualisierungen von Auftragsverarbeitungsverträgen, Produkthinweise und Beschränkungen für Modelltraining umfassen.
Schritt 4: REG03 und SoA aktualisieren
Die PIMS-Richtlinie verlangt:
[Beide] Der Privacy Lead / PIMS-Manager MUSS REG03 mit einbezogenen Kontrollen, ausgeschlossenen Kontrollen, Umsetzungsstatus und Begründung jährlich sowie innerhalb von 30 Tagen nach jeder Änderung der Datenschutz-Risikobehandlung pflegen.
Wenn die DSFA Maskierung für Nicht-Produktivanalysen, Protokollierung für Administratorzugriffe, Löschkontrollen, Lieferantenklauseln oder kundenseitige Konfigurationsschutzmaßnahmen ergänzt, müssen REG03 und die SoA aktualisiert werden.
Schritt 5: Datenschutz durch Technikgestaltung nachweisen
Die SME-Datenschutzrichtlinie fasst den Grundsatz klar zusammen:
Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen muss in allen neuen Systemen und Services durchgesetzt werden.
Nachweise sollten DSFA, Architekturprüfung, Entscheidung zur Datenminimierung, Zugriffsmodell, Protokollierungskonfiguration, Aufbewahrungseinstellung, Testergebnisse, Release-Freigabe und Überprüfung nach der Produktivsetzung umfassen. Damit wird die Funktionseinführung zu wiederverwendbaren PIMS-Nachweisen.
Datenschutz-Governance bei Lieferanten in einer DORA- und NIS2-Welt
Datenschutz-Governance bei Lieferanten ist der Punkt, an dem viele Umstellungen scheitern. GDPR Article 28 verlangt von Verantwortlichen, nur Auftragsverarbeiter einzusetzen, die ausreichende Garantien bieten, und Auftragsverarbeiterpflichten in schriftlichen Verträgen festzulegen. DORA Articles 28 to 30 verlangen von Finanzunternehmen, IKT-Drittparteienrisiken zu steuern, Register vertraglicher Vereinbarungen zu führen, gebotene Sorgfalt durchzuführen, Auditrechte und Exit-Bedingungen aufzunehmen, Unterbeauftragungen zu steuern und kritische oder wichtige Funktionen zu adressieren. NIS2 Article 21 verlangt Sicherheitsmaßnahmen für die Lieferkette, einschließlich Berücksichtigung von Schwachstellen bei Lieferanten, Cybersicherheitspraktiken und Verfahren für sichere Entwicklung.
ISO/IEC 27002:2022 Control 5.19, Informationssicherheit in Lieferantenbeziehungen, ist der operative Anker. Zenith Controls ordnet diesen Bereich Lieferantenvereinbarungen, IKT-Lieferkettensicherheit, Informationsübertragung, Compliance-Überwachung, zulässiger Nutzung, GDPR-Auftragsverarbeiterpflichten, NIS2-Cybersicherheit der Lieferkette, DORA-IKT-Drittparteienrisiko, NIST-Lieferanten-Governance und COBIT-Lieferantenmanagement zu.
| Lieferantenkategorie | Erforderliche Datenschutznachweise |
|---|---|
| Auftragsverarbeiter, der personenbezogene Kundendaten verarbeitet | Auftragsverarbeitungsvertrag, Weisungen, technische und organisatorische Maßnahmen, Liste der Unterauftragsverarbeiter, Unterstützung bei Meldungen von Datenschutzverletzungen, Auditrechte |
| Unterauftragsverarbeiter in der SaaS-Lieferkette | Weiterzugebende Verpflichtungen, Standort, Übermittlungsinstrument, Löschzusage, Änderungsbenachrichtigung |
| Cloud-Hosting-Anbieter | Regionsauswahl, Verschlüsselung, Zugriffskontrollen, Unterstützung bei Vorfällen, Bedingungen für Löschung und Rückgabe |
| Anbieter von Support-Werkzeugen | Zugriffsbeschränkung, Schwärzung von Tickets, Aufbewahrung, Protokollierung, Vertraulichkeit des Support-Personals |
| Analyse- oder KI-Anbieter | Zweckbindung, Beschränkung des Modelltrainings, Pseudonymisierung, Opt-out oder Konfigurationskontrollen |
Für DORA-regulierte Finanzunternehmen müssen diese Nachweise mit IKT-Drittparteienregistern und Bewertungen kritischer oder wichtiger Funktionen verbunden sein. Für NIS2-pflichtige Einrichtungen unterstützen dieselben Lieferantenaufzeichnungen das Management von Lieferkettenrisiken. Für NIST CSF 2.0 ist Lieferanten-Governance der GOVERN Function zugeordnet, insbesondere Ergebnissen zum Lieferkettenrisikomanagement. Für COBIT 2019 ist Lieferanten-Governance Zielen wie APO10 Managed Vendors und DSS-bezogenen operativen Kontrollen für Lieferanten zugeordnet.
Vorfalls- und Datenschutzverletzungsbereitschaft muss integriert werden
Datenschutz-Umstellungspläne konzentrieren sich häufig zu stark auf Dokumentation und zu wenig auf den Umgang mit Datenschutzverletzungen. Das ist gefährlich, weil GDPR, NIS2 und DORA alle disziplinierte Vorfallprozesse erwarten, auch wenn Schwellenwerte und Meldefristen unterschiedlich sind.
GDPR verlangt die Bewertung, ob ein Sicherheitsereignis eine Verletzung des Schutzes personenbezogener Daten verursacht hat und ob eine Meldung an die Aufsichtsbehörde oder betroffene Personen erforderlich ist. NIS2 etabliert gestufte Meldungen für erhebliche Vorfälle, einschließlich Frühwarnung innerhalb von 24 Stunden, Meldung innerhalb von 72 Stunden und Abschlussbericht innerhalb eines Monats. DORA verlangt von Finanzunternehmen, IKT-bezogene Vorfälle zu erkennen, zu steuern, zu klassifizieren, aufzuzeichnen, zu melden, darauf zu reagieren und daraus zu lernen, mit gestufter Meldung für schwerwiegende Vorfälle.
| Vorfallsnachweis | GDPR-Zweck | NIS2- oder DORA-Zweck |
|---|---|---|
| Aufzeichnung der Vorfallklassifizierung | Bestimmt, ob eine Verletzung des Schutzes personenbezogener Daten eingetreten ist | Bestimmt die Klassifizierung als erheblicher oder schwerwiegender IKT-Vorfall |
| Bewertung der Datenauswirkungen | Identifiziert betroffene Personen und Risiken für Rechte und Freiheiten | Unterstützt Schweregrad- und Auswirkungsberichterstattung |
| Zeitachsenprotokoll | Belegt Zeitpunkt der Kenntniserlangung, Eskalation, Entscheidungen und Meldefristen | Unterstützt gestufte Meldung und Kommunikation mit Aufsichtsbehörden |
| Ursachenanalyse | Unterstützt Mängelbehebung und Rechenschaftspflicht | Unterstützt Abschlussberichterstattung und Verbesserung der Resilienz |
| Gewonnene Erkenntnisse | Aktualisiert DSFAs, Kontrollen, Schulungen und Lieferantenaufsicht | Fließt in Tests, Audit und Managementbewertung ein |
NIST CSF 2.0 unterstützt diesen Zyklus durch Detect-, Respond-, Recover- und Govern-Ergebnisse. Das Umstellungsteam sollte sicherstellen, dass Entscheidungen zu Datenschutzverletzungen in den Workflow für Sicherheitsvorfälle eingebettet sind und nicht als abgekoppelter rechtlicher Nachtrag behandelt werden.
Ein Fahrplan, viele Compliance-Ergebnisse
Die ISO/IEC 27701:2025-Umstellung wird wertvoller, wenn sie doppelte Compliance-Arbeit reduziert. Zenith Blueprint, Schritt 14, empfiehlt die Querverknüpfung von GDPR, NIS2 und DORA, damit Organisationen zeigen können, dass Risikobehandlung und Kontrollen mehrere Verpflichtungen erfüllen:
Für jede Verordnung können Sie, sofern anwendbar, eine einfache Zuordnungstabelle erstellen (z. B.
als Anhang in einem Bericht), die die wichtigsten Sicherheitsanforderungen der Verordnung und die
entsprechenden Kontrollen/Richtlinien in Ihrem ISMS auflistet.
Für die Datenschutz-Umstellungsplanung sollte die Zuordnung praxisnah und nachweisorientiert sein.
| Rahmenwerk | Was Auditoren oder Assessoren erwarten | PIMS-Umstellungsreaktion |
|---|---|---|
| GDPR | Rechenschaftspflicht, Rechtsgrundlage, DSFAs, Auftragsverarbeiter-Governance, Umgang mit Datenschutzverletzungen, Unterstützung von Rechten | REG02, REG04, DSFA-Aufzeichnungen, DPA-Register, Entscheidungsprotokolle zu Datenschutzverletzungen, DSAR-Nachweise |
| NIS2 | Risikoanalyse, Vorfallbearbeitung, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, Zugriffskontrolle, Asset-Management | ISMS-Risikoregister, Lieferantenstufen, Vorfall-Workflow, Berechtigungsüberprüfungen, Asset-Inventar |
| DORA | IKT-Risikomanagementrahmen, Vorfallmeldungen, Resilienztests, IKT-Drittparteienrisiko, Vertragsklauseln | IKT-Abhängigkeitsregister, Zuordnung kritischer Lieferanten, Vorfallsberichte, Testnachweise, Exit-Pläne |
| NIST CSF 2.0 | Governance, rechtliche und Datenschutzverpflichtungen, Risikoprofile, Lieferantenrisiko, Ergebnisse zu Reaktion und Wiederherstellung | Current und Target Profiles, Compliance-Zuordnung, Lieferantenüberwachung, Nachweise zu Reaktion und Wiederherstellung |
| COBIT 2019 | Governance des Datenschutzprogramms, Compliance-Überwachung, Lieferantenvereinbarungen, operative Datenschutzkontrollen | Berichterstattung an das Leitungsorgan, Einhaltungsregister, an APO und DSS ausgerichtete Nachweise, Feststellungen aus internen Audits |
In Zenith Controls unterstützt ISO/IEC 27002:2022 Control 5.31 die rechtliche und regulatorische Nachvollziehbarkeit über GDPR-Rechenschaftspflicht, DORA-Compliance-Verpflichtungen, NIS2-Governance-Erwartungen, NIST CSF 2.0 GV.OC-03 und externe Compliance-Überwachung nach COBIT hinweg. Control 5.34 unterstützt GDPR Articles 25 und 32, Schutz personenbezogener Daten über den Lebenszyklus, Erwartungen an die Verarbeitung personenbezogener Daten in der Cloud und datenschutzbewusste Sicherheitskontrollen.
Das Ergebnis ist kein vereinfachendes Modell „eine Kontrolle entspricht einem Gesetz“. Es ist ein belastbares Nachweismodell, bei dem ein gut gestaltetes Kontrollset mehrere Assurance-Anforderungen unterstützt.
Wie Auditoren die Umstellung prüfen werden
Ein belastbarer Umstellungsplan antizipiert Auditverfahren.
Ein Auditor für ISO-Managementsysteme beginnt mit Geltungsbereich, interessierten Parteien, rechtlichen Anforderungen, Risiken, Zielen, operativen Kontrollen, internen Audits, Managementbewertungen, Nichtkonformitäten und Verbesserung. Er wird prüfen, ob der PIMS-Geltungsbereich freigegeben ist, ob Datenschutzverpflichtungen im Einhaltungsregister enthalten sind, ob Kontrollen in der SoA begründet sind und ob Umsetzungsnachweise zum erklärten Geltungsbereich passen.
Ein Datenschutzauditor wird Stichproben aus Verarbeitungsaufzeichnungen, DSFAs, DSARs, Entscheidungen zu Datenschutzverletzungen, Auftragsverarbeiterverträgen, Aufbewahrungskontrollen und Projekt-Onboarding ziehen. Er wird Richtlinienabsichten nicht akzeptieren, wenn operative Nachweise fehlen.
Ein an NIST ausgerichteter Assessor wird auf Governance, gesetzliche und vertragliche Verpflichtungen, Zielprofile, Lieferantenrisiken, Überwachung, Reaktion und Wiederherstellungsnachweise achten.
Ein COBIT 2019-Auditor wird sich auf Aufsicht durch das Leitungsorgan, Compliance-Berichterstattung, Lieferanten-Governance, Rollen und Verantwortlichkeiten sowie darauf konzentrieren, ob Datenschutzrisiken über den Informationslebenszyklus hinweg gesteuert werden.
Clarysecs PIMS-Richtlinie zu Überwachung, Audit und Verbesserung [PIMS-Richtlinie zu Überwachung, Audit und Verbesserung] macht das Auditprogramm verbindlich:
[Alle] Der interne Audit- / Compliance-Prüfer MUSS jährlich vor dem ersten geplanten PIMS-Auditzyklus ein risikobasiertes internes PIMS-Auditprogramm in REG12 vorbereiten.
Die Richtlinie zur Audit- und Compliance-Überwachung [Richtlinie zur Audit- und Compliance-Überwachung] wendet dieselbe Disziplin auf ISMS-Ebene an:
Ein risikobasierter Auditplan muss jährlich entwickelt und freigegeben werden, unter Berücksichtigung von:
Für kleinere Organisationen hält die Richtlinie zur Audit- und Compliance-Überwachung - SME [SME-Richtlinie zur Audit- und Compliance-Überwachung] die Auditplanung fokussiert:
Der Plan muss wesentliche Systeme und Richtlinien identifizieren, die überprüft werden sollen, mit Schwerpunkt auf:
Während der Umstellung sollte das erste interne Audit nicht alles prüfen. Es sollte die höchsten Umstellungsrisiken prüfen: unvollständige Verarbeitungsaufzeichnungen, fehlende DSFA-Auslöser, schwache Datenschutzklauseln bei Lieferanten, ungeprüfte Entscheidungen zu Datenschutzverletzungen, unklare Rollen als Verantwortlicher und Auftragsverarbeiter sowie Abweichungen zur SoA.
Ein praxisnaher 90-Tage-Fahrplan für die ISO/IEC 27701:2025-Umstellung
Ein realistischer Fahrplan sollte kurz genug für die Umsetzung und strukturiert genug für die Nachweiserzeugung sein.
| Zeitraum | Umstellungsziel | Zentrale Ergebnisse |
|---|---|---|
| Tage 1 bis 15 | Geltungsbereich und Governance etablieren | REG01-Freigabe, Sponsor, Rollenübersicht, Aktualisierung des Einhaltungsregisters, REG12-Umstellungsplan |
| Tage 16 bis 35 | Basislinie für Datenschutznachweise aufbauen | REG02-Bereinigung, Datenkategorien, Zwecke, Rechtsgrundlagen, Aufbewahrung, Systeme, Lieferanten, Übermittlungen |
| Tage 36 bis 55 | Datenschutzrisiko- und DSFA-Screening durchführen | REG04-Screening, DSFA-Auslöser, Entscheidungen zur Risikobehandlung, Restrisiko-Genehmigungen |
| Tage 56 bis 70 | Kontrollen, Verträge und Schutzmaßnahmen aktualisieren | REG03-Aktualisierung, SoA-Aktualisierung, DPA-Mängelbehebung, Zugriff, Löschung, Maskierung, Protokollierung, Cloud-Kontrollen |
| Tage 71 bis 85 | Nachweise durch internes Audit testen | Stichproben-Audit eines Verantwortlichenprozesses, eines Auftragsverarbeiterservices, eines Lieferanten, einer DSFA, eines DSAR und eines Szenarios zu Datenschutzverletzungen |
| Tage 86 bis 90 | Managementbewertung durchführen und Bereitschaft entscheiden | Überprüfungsmaßnahmen, Lieferantenprobleme, Vorfälle, Audit-Feststellungen, Datenschutzziele, Entscheidung über externe Bewertung |
Das 90-Tage-Ziel bedeutet nicht, dass jeder Mängelbehebungspunkt abgeschlossen sein wird. Es bedeutet, dass die Leitung über einen freigegebenen Geltungsbereich, eine glaubwürdige Nachweisbasislinie, priorisierte Risikobehandlung, fokussierte Auditergebnisse und eine Managemententscheidung zur Bereitschaft verfügen sollte.
Die Umstellung nachweisorientiert gestalten
Organisationen, die mit der ISO/IEC 27701:2025-Umstellung erfolgreich sind, sind nicht diejenigen mit der längsten Datenschutzrichtlinie. Es sind diejenigen, die nachweisen können, wie Datenschutzverpflichtungen vom Gesetz in den Geltungsbereich, vom Geltungsbereich in Verarbeitungsaufzeichnungen, von Verarbeitungsaufzeichnungen in die Risikobeurteilung, von der Risikobeurteilung in Kontrollen, von Kontrollen in Nachweise und von Nachweisen in Verbesserung übergehen.
Clarysec hilft Teams, diese Umstellung praktikabel zu gestalten. Unser PIMS-Richtlinienset, GDPR-Zuordnungen, Nachweisregister für Verantwortliche und Auftragsverarbeiter, DSFA-Workflows, Vorlagen für Datenschutz-Governance bei Lieferanten, Materialien zum Umgang mit Datenschutzverletzungen, Tagesordnungen für Managementbewertungen, Zenith Blueprint und Zenith Controls geben CISOs, DPOs, Compliance-Managern, Auditoren und Geschäftsverantwortlichen einen strukturierten Weg von Datenschutzabsicht zu auditbereitem Betrieb.
Wenn Ihre Organisation sich auf ISO/IEC 27701:2025 vorbereitet, beginnen Sie diese Woche mit drei Maßnahmen: Geben Sie den PIMS-Umstellungsgeltungsbereich in REG01 frei, befüllen Sie REG02 für Ihren risikoreichsten Service und führen Sie das erste REG04-Screening durch. Nutzen Sie anschließend Clarysec, um diesen Nachweissatz in einen vollständigen, an GDPR ausgerichteten PIMS-Umstellungsfahrplan zu überführen, bereit für Kunden, Auditoren, Aufsichtsbehörden und das Leitungsorgan.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


