PII-Governance für ISO 27701:2025 und GDPR

Die Anfrage landete mit trügerischer Einfachheit im Posteingang des CISO: „Project Wellness“. Ein schnell wachsendes Fintech wollte vorhandene Kundentransaktionsdaten analysieren, um personalisierte Spartipps, Produktempfehlungen und Erkenntnisse zum Abwanderungsrisiko bereitzustellen. Das Marketing sah Kundenbindung. Das Produktteam sah Innovation. Die Geschäftsleitung sah einen Wettbewerbsvorteil.

Der CISO sah eine Governance-Falle.

Die Transaktionsdaten waren für die Zahlungsabwicklung auf Grundlage eines definierten Zwecks und einer Rechtsgrundlage erhoben worden. Nun wollte der Fachbereich sie für Analysen zur finanziellen Gesundheit, Kampagnenpersonalisierung und prädiktives Scoring wiederverwenden. Zur Beschleunigung der Umsetzung wollte das Team außerdem einen pseudonymisierten Datenbestand an einen Drittanbieter für KI-Analysen übermitteln.

Kein Angreifer befand sich im Netzwerk. Keine Datenbank wurde exfiltriert. Kein Incident-Ticket war rot markiert.

Und doch beginnen genau hier viele Verstöße gegen die Rechenschaftspflicht nach GDPR.

Die Frage ist nicht, ob die Organisation einen Datenschutzhinweis, einen Datenschutzbeauftragten, ein Register der Rechtsgrundlagen oder einen Datenaufbewahrungsplan hat. Die eigentliche Frage ist operativ: Wer gibt neue PII-Erhebungen frei, wer bestätigt die Erforderlichkeit, wer definiert die zulässige interne Nutzung, wer entscheidet, ob eine Sekundärnutzung vereinbar ist, wer autorisiert die Offenlegung gegenüber einem Lieferanten, und wer kann die Entscheidung später nachweisen?

Genau diese Kontrolllücke müssen Umsetzungen eines Datenschutz-Informationsmanagementsystems (PIMS) nach ISO/IEC 27701:2025 schließen. GDPR Article 5 verlangt, dass personenbezogene Daten rechtmäßig, fair und transparent verarbeitet, für festgelegte, eindeutige und legitime Zwecke erhoben, auf das Erforderliche beschränkt, richtig, nur so lange wie erforderlich aufbewahrt, angemessen geschützt und unter Rechenschaftspflicht des Verantwortlichen verarbeitet werden. GDPR Article 6 ergänzt die Rechtsgrundlage und die Vereinbarkeitslogik für die Weiterverarbeitung. Diese Grundsätze werden jedoch erst belastbar, wenn sie in Workflows, Register, Freigaben, Zugriffsregeln, Lieferantenkontrollen, Überwachung und Nachweise übersetzt werden.

Der Ansatz von Clarysec ist einfach: Governance für die Erhebung, Nutzung und Offenlegung von PII wird als kontrolliertes Betriebsmodell behandelt, nicht als juristischer Vermerk. Das Modell liegt im ISMS-Rahmen von ISO/IEC 27001:2022, erweitert diesen um PIMS-Rollen nach ISO/IEC 27701:2025 und wird über Clarysec-Richtlinien, Register, Zenith Blueprint: Fahrplan für Auditoren in 30 Schritten und Zenith Controls: Leitfaden für frameworkübergreifende Compliance nachgewiesen.

Warum PII-Governance trotz vorhandener Datenschutzdokumente scheitert

Die meisten Datenschutzprogramme scheitern nicht daran, dass niemand von GDPR weiß. Sie scheitern, weil Datenschutzentscheidungen in Produkttickets, E-Mails zum Lieferanten-Onboarding, Tabellenexporten, Dashboard-Experimenten und KI-Piloten getroffen werden, ohne einen wiederholbaren Kontrollpunkt zu durchlaufen.

Ein typisches Muster ist vertraut:

1. Ein Team ergänzt ein neues Feld in einem Registrierungsformular, weil es die Segmentierung verbessert.
2. Niemand dokumentiert, warum genau dieses Feld erforderlich ist.
3. Ein anderes Team verwendet die Daten später für einen anderen Zweck weiter.
4. Ein Lieferant erhält einen Export auf Grundlage einer weit gefassten Servicevereinbarung.
5. Das Verarbeitungsinventar wird nach der Produktivsetzung aktualisiert, sofern es überhaupt aktualisiert wird.
6. Im Audit kann die Organisation einen Datenschutzhinweis vorlegen, aber keine Entscheidungsnachweise.

GDPR Articles 4 und 5 definieren Verarbeitung weit. Erhebung, Erfassung, Speicherung, Nutzung, Offenlegung, Löschung und Vernichtung fallen sämtlich darunter. Article 5 macht auch die Rechenschaftspflicht ausdrücklich. Verantwortliche müssen die Einhaltung der Grundsätze nachweisen können.

Damit lautet die Auditfrage nicht nur: „Haben Sie eine Richtlinie?“ Sie lautet: „Zeigen Sie mir, wie dieses konkrete Datenelement freigegeben wurde, warum es erforderlich war, wie es genutzt wurde, wer es erhalten hat und welche Kontrollen Missbrauch verhindert haben.“

Clarysec P17 Richtlinie zu Datenschutz und Privatsphäre definiert die Erwartung an den Lebenszyklus eindeutig:

Sie formalisiert die Verantwortlichkeiten des Unternehmens nach internationalen Standards und regulatorischen Rahmenwerken und stellt sicher, dass personenbezogene Informationen (PII) rechtmäßig, sicher und transparent erhoben, verarbeitet, aufbewahrt, weitergegeben und entsorgt werden.

Für KMU überführt Clarysec Richtlinie zu Datenschutz und Privatsphäre - KMU denselben Grundsatz in eine pragmatische Betriebsregel:

Personenbezogene Daten dürfen nur erhoben werden, wenn dies für einen legitimen, rechtmäßigen oder vertraglichen Zweck erforderlich ist.

Und zur Minimierung:

Es dürfen nur die mindestens erforderlichen personenbezogenen Daten erhoben und aufbewahrt werden.

Diese Aussagen sind nur dann wirksam, wenn sie vor Beginn der Verarbeitung durchgesetzt werden. Andernfalls bleiben sie Datenschutzrhetorik ohne operativen Nachweis.

Das Kontrollziel: unkontrollierte Verarbeitung an drei Gates stoppen

Ein starkes PIMS sollte PII-Entscheidungen an drei Punkten steuern: vor der Erhebung, vor der Nutzung und vor der Offenlegung.

Vor der Erhebung muss die Organisation wissen, was sie erheben will, von wem, über welchen Kanal, zu welchem Zweck, auf welcher Rechtsgrundlage und warum jedes Feld erforderlich ist.

Vor der Nutzung muss die Organisation Regeln für die zulässige interne Nutzung definieren. Support, Customer Success, Marketing, Betrugsprävention, Finanzbereich und Engineering benötigen selten dieselbe Sichtbarkeit oder dieselbe Berechtigung, auf PII einzuwirken.

Vor der Offenlegung muss die Organisation wissen, wer der Empfänger ist, welche Rolle er einnimmt, warum die Offenlegung erforderlich ist, wo die Verarbeitung erfolgt, welche PII-Kategorien weitergegeben werden, wie häufig die Weitergabe erfolgt und welche Befugnis die Weitergabe erlaubt.

Clarysec PII09 Richtlinie zur Erhebung, Nutzung, Offenlegung und Weitergabe von PII ist für diese Governance-Ebene ausgelegt. Sie nutzt PIMS-Rollenkennzeichnung, insbesondere die Rolle des Verantwortlichen, weil Entscheidungen über Erhebung, Nutzung und Offenlegung in der Regel bei der Organisation liegen, die Zwecke und Mittel festlegt.

Für die Begrenzung der Erhebung verlangt die PII09 Richtlinie zur Erhebung, Nutzung, Offenlegung und Weitergabe von PII:

[Verantwortlicher] Der Prozessverantwortliche / Geschäftsinhaber MUSS den Erhebungszweck, die Quelle oder den Kanal, PII-Kategorien, Kategorien betroffener Personen und die minimalen Datenelemente in REG02 erfassen, bevor eine neue Erhebungstätigkeit oder eine wesentliche Änderung der Erhebung beginnt.

Anschließend macht sie die Minimierung prüfbar:

[Verantwortlicher] Der Prozessverantwortliche / Geschäftsinhaber MUSS in REG02 für jedes PII-Datenelement eine Erforderlichkeitsbegründung erfassen, bevor dieses Element erhoben wird.

Die Anforderung „jedes PII-Datenelement“ ist der Unterschied zwischen einem generischen Verarbeitungsinventar und Nachweisen der Rechenschaftspflicht auf Feldebene.

Für die interne Nutzung verlangt dieselbe Richtlinie:

[Verantwortlicher] Der Prozessverantwortliche / Geschäftsinhaber MUSS für jede Verarbeitungstätigkeit freigegebene Regeln zur internen Nutzung in REG02 erfassen, bevor die Nutzung beginnt.

Für die Sekundärnutzung:

[Verantwortlicher] Der Prozessverantwortliche / Geschäftsinhaber MUSS eine Vereinbarkeitsprüfung für Sekundärnutzung in REG02 erfassen, bevor PII für einen Zweck genutzt wird, der für die Verarbeitungstätigkeit noch nicht freigegeben ist.

Und für die externe Offenlegung:

[Verantwortlicher] Der Lieferanten-/Beschaffungsverantwortliche MUSS Empfängeridentität, Empfängerrolle, Offenlegungszweck, PII-Kategorien, Weitergabefrequenz, Verarbeitungsort und maßgebliche Befugnisquelle in REG08 erfassen, bevor eine wiederkehrende externe Weitergabe beginnt.

Diese Klauseln schaffen eine klare Antwort, wenn die Geschäftsleitung fragt, ob der Fachbereich schnell innovieren kann: ja, sofern die Entscheidung einen dokumentierten Governance-Workflow durchläuft und die Kontrollen zur Freigabe passen.

REG02 und REG08: die Clarysec-Kette von Richtlinie zu Kontrolle

In Clarysec-Umsetzungen ist REG02 kein passives Verarbeitungsinventar. Es ist der Entscheidungsnachweis für Erhebungszweck, Rechtsgrundlage, PII-Kategorien, Erforderlichkeit, Regeln zur internen Nutzung, Abstimmung mit der Aufbewahrung und Vereinbarkeit der Sekundärnutzung.

REG08 ist das Kontrollregister für Offenlegung und Weitergabe. Es ist besonders wichtig für Lieferanten, Partner, Konzernunternehmen, Behörden, Unterauftragsverarbeiter, Integrationen und wiederkehrende Exporte.

Zusammen bilden sie eine Kette von der Richtlinie zur Kontrolle, die von Datenschutz-, Sicherheits-, Beschaffungs- und Audit-Teams geprüft werden kann.

Dieses Modell passt natürlich zu ISO/IEC 27001:2022. Die Klauseln 4 bis 10 verlangen, dass die Organisation Kontext, Anforderungen interessierter Parteien, Geltungsbereich, Führungsverantwortung, Risikobeurteilung, Risikobehandlung, operative Steuerung, Leistungsbewertung und Verbesserung versteht. Datenschutzpflichten nach GDPR und ISO/IEC 27701:2025 werden Teil des Managementsystems und bleiben keine separate Datenschutzinsel.

Auch ISO/IEC 27002:2022 unterstützt das Betriebsmodell. Maßnahme 5.31, gesetzliche, behördliche, regulatorische und vertragliche Anforderungen, verankert GDPR und branchenspezifische Verpflichtungen. Maßnahme 5.34, Datenschutz und Schutz von PII, adressiert datenschutzspezifischen Schutz. Maßnahme 5.9, Inventar von Informationen und anderen zugehörigen Assets, unterstützt Datenbewusstsein. Die Maßnahmen 5.12 und 5.13 unterstützen Klassifizierung und Kennzeichnung. Maßnahme 5.14 steuert die Informationsübermittlung. Die Maßnahmen 5.19 bis 5.23 behandeln Lieferantenbeziehungen, Lieferantenvereinbarungen, IKT-Lieferkette, Überwachung von Lieferantendiensten und Cloud-Services. Maßnahme 8.11 unterstützt Datenmaskierung, 8.12 unterstützt Data Loss Prevention (DLP), 8.15 Protokollierung, 8.16 Überwachungstätigkeiten und 8.24 den Einsatz von Kryptografie.

Zenith Blueprint ordnet diese Kontrollen in einen Umsetzungspfad ein. In der Phase „Controls in Action“ behandelt Schritt 23 die organisatorischen Maßnahmen 5.19 bis 5.37, einschließlich Maßnahme 5.34 für Datenschutz und Schutz von PII. Der Blueprint erläutert:

In der heutigen datengetriebenen Welt sind personenbezogene Daten nicht einfach ein weiterer Datentyp, sondern eine hoch sensible Verkörperung von Vertrauen. Namen, Adressen, Kennungen, Gesundheitsdaten, Finanzdetails – diese Daten erzählen eine Geschichte über reale Menschen.

Anschließend definiert er die operative Basis:

Die Grundlage dieser Maßnahme ist Datenbewusstsein. Die Organisation muss wissen, welche PII sie erhebt, wo sie sich befinden, warum sie verarbeitet werden und wer darauf zugreifen kann.

Genau das leisten REG02 und REG08, wenn sie als lebende Governance-Aufzeichnungen geführt werden.

Praxisbeispiel: Project Wellness freigeben, ohne die Kontrolle zu verlieren

Zurück zum Fintech-Szenario. Der Fachbereich möchte Kundentransaktionsdaten analysieren, um personalisierte Empfehlungen zur finanziellen Gesundheit zu erstellen. Marketing möchte die Ergebnisse für Kampagnen nutzen. Das Produktteam möchte Abwanderungs- und Engagement-Scores erstellen. Eine KI-Analyseplattform eines Drittanbieters soll einen Teil des Datenbestands verarbeiten.

So würde Clarysec die Anfrage steuern.

Schritt 1: REG02-Verarbeitungstätigkeit anlegen oder aktualisieren

Der Prozessverantwortliche öffnet REG02 und erfasst die Verarbeitungstätigkeit, bevor die Arbeiten beginnen.

Der entscheidende Punkt ist der Zeitpunkt. REG02 wird aktualisiert, bevor die neue Verarbeitung beginnt, nicht erst, nachdem die Funktion bereits produktiv ist.

Schritt 2: Erforderlichkeitsbegründungen auf Feldebene dokumentieren

Marketing fordert zunächst fünf Jahre vollständige Transaktionshistorie an, einschließlich Händlername, exakter Zeitstempel, Kartenmetadaten und Kundenprofilattribute. Das Governance-Team hinterfragt jedes Feld.

Das ist Datenminimierung als Nachweis, nicht als Absichtserklärung. Der Fachbereich erhält weiterhin nützliche Analysen, aber der Datenbestand wird auf das für den freigegebenen Zweck Erforderliche begrenzt.

Schritt 3: Datenbestand klassifizieren und kennzeichnen

Der Datenbestand wird nach der Clarysec Richtlinie zur Datenklassifizierung und Kennzeichnung klassifiziert. Die KMU-Version verlangt:

Externe Weitergabe muss ausdrücklich autorisiert und protokolliert werden.

Die Enterprise-Richtlinie zur Datenklassifizierung und Kennzeichnung ergänzt eine Schutzmaßnahme für sensitive Informationen:

Darf extern nur unter einer Geheimhaltungsvereinbarung (NDA) oder gleichwertigen vertraglichen Schutzmaßnahmen weitergegeben werden.

In der Praxis darf der Project-Wellness-Datenbestand nicht beiläufig an eine KI-Plattform exportiert werden. Er benötigt einen freigegebenen Offenlegungsdatensatz, vertragliche Schutzmaßnahmen, technische Übermittlungskontrollen und Protokolle.

Zenith Blueprint erläutert in Schritt 22 zu Maßnahme 5.12 Klassifizierung von Informationen, warum dies wichtig ist:

Jede jemals formulierte Informationssicherheitsmaßnahme – Zugriffsbeschränkung, Verschlüsselung, Backup, Überwachung oder Entsorgung – setzt eines voraus: dass die Organisation weiß, was sie schützt.

Ohne Klassifizierung werden Zugriffsbeschränkungen, Verschlüsselung, DLP und Aufbewahrungsregeln zur Schätzung.

Schritt 4: Regeln zur internen Nutzung vor Produktivsetzung definieren

Der Prozessverantwortliche erfasst freigegebene Regeln zur internen Nutzung in REG02. Hier wird schleichende Zweckausweitung häufig gestoppt.

Ein belastbares Regelwerk könnte festlegen:

• Produktmanagement darf aggregierte Kennzahlen zur Empfehlungsleistung nutzen.
• Der Kundensupport darf sehen, ob einem Kunden im Rahmen einer Supportanfrage eine Empfehlung angezeigt wurde.
• Marketing darf Wellness-Scores auf individueller Ebene nicht für Kampagnensegmentierung nutzen, sofern keine Vereinbarkeitsprüfung für Sekundärnutzung abgeschlossen wurde.
• Der Finanzbereich darf nicht auf detaillierte Wellness-Analysen zugreifen, sofern kein gesonderter freigegebener Zweck besteht.
• Entwickler dürfen keine Produktions-PII in Testumgebungen verwenden.
• KI-Modellbewertung muss, soweit möglich, maskierte, pseudonymisierte oder aggregierte Datenbestände verwenden.

Die letzten beiden Regeln knüpfen an ISO/IEC 27002:2022 Maßnahme 8.11, Datenmaskierung, an. Zenith Blueprint, Schritt 19, beschreibt Datenmaskierung als praktisches Verfahren zur Vermeidung unnötiger Exponierung in Testumgebungen, Trainingsdatenbeständen, Analyseplattformen, Drittparteienintegrationen und CI/CD-Testpipelines.

Schritt 5: Vereinbarkeitsprüfung für Sekundärnutzung durchführen

Marketing bittet später darum, Wellness-Scores für gezielte Kampagnen zu verwenden. Das ist ein neuer Zweck. Nach PII09 Richtlinie zur Erhebung, Nutzung, Offenlegung und Weitergabe von PII Klausel 4.3.1 muss der Geschäftsinhaber eine Vereinbarkeitsprüfung in REG02 erfassen, bevor die neue Nutzung beginnt.

Die Prüfung sollte bewerten:

• Ob Marketing zur finanziellen Gesundheit mit dem ursprünglichen Verarbeitungszweck vereinbar ist.
• Was Kunden bei der Erhebung und im Datenschutzhinweis mitgeteilt wurde.
• Ob aus Transaktionen abgeleitete Rückschlüsse sensitiv oder unerwartet sein könnten.
• Ob die neue Nutzung Druck, Ausschluss oder unfaires Profiling erzeugen könnte.
• Ob Schutzmaßnahmen wie Aggregation, Opt-out, Pseudonymisierung oder Segmentierung auf Kontoebene das Risiko reduzieren.
• Ob die Rechtsgrundlage weiterhin gültig ist.
• Ob Aktualisierungen der Transparenzinformationen oder Einwilligungsmechanismen erforderlich sind.

Das Ergebnis kann eine Freigabe, eine Freigabe mit Schutzmaßnahmen oder eine Ablehnung sein. Der Wert liegt darin, dass die Entscheidung dokumentiert wird, bevor die Nutzung beginnt.

Schritt 6: Externe Offenlegung über REG08 freigeben

Wenn der KI-Analyseanbieter Daten erhalten soll, erfasst der Lieferanten- oder Beschaffungsverantwortliche in REG08:

Clarysec Richtlinie zur Lieferanten- und Drittparteiensicherheit - KMU stärkt den minimierten Lieferantenzugriff:

Lieferanten dürfen nur Zugriff auf die Mindestanzahl an Systemen und Daten erhalten, die zur Erfüllung ihrer Funktion erforderlich sind.

Das ist Datenschutzminimierung angewendet auf Lieferantenzugriff und Offenlegung.

Schritt 7: Technische Durchsetzung ergänzen

Governance-Aufzeichnungen müssen durch technische Kontrollen abgesichert werden. Für Project Wellness würde Clarysec typischerweise DLP-Regeln für Exporte, rollenbasierte Zugriffsbeschränkungen, Protokollierung von Zugriffs- und Übermittlungsereignissen, maskierte Datenbestände für die Entwicklung, Verschlüsselung bei Übertragung und Speicherung, Berechtigungsüberprüfungen für Lieferanten, Sicherheits-Due-Diligence für Cloud-Services und regelmäßige Stichproben von REG02 und REG08 gegen das tatsächliche Systemverhalten empfehlen.

So werden Rechenschaftspflicht nach ISO/IEC 27701:2025 und GDPR zu operativen Nachweisen.

Kontrollzuordnung: von der Datenschutzentscheidung zur Sicherheitsdurchsetzung

PII-Governance ist keine isolierte Kontrolle. Sie ist das Zusammenspiel von Datenschutzanforderungen, Sicherheitskontrollen, Lieferanten-Governance und Auditnachweisen.

Zenith Controls behandelt ISO/IEC 27002:2022 Maßnahme 5.34, Datenschutz und Schutz von PII, als präventive Kontrolle zur Unterstützung von Vertraulichkeit, Integrität und Verfügbarkeit, mit den Cybersicherheitskonzepten Identify und Protect sowie operativen Fähigkeiten im Informationsschutz sowie im Bereich Recht und Compliance.

Für 5.34 ordnet Zenith Controls das umgebende Kontrollökosystem zu, einschließlich Inventar, Klassifizierung, Übermittlung, Zugriff, Identität, Cloud, Lieferantensicherheit, Maskierung, Data Loss Prevention, Protokollierung, Überwachung und Kryptografie.

Zur Maskierung stellt Zenith Controls fest:

Datenmaskierung (8.11) ist eine Technik, die häufig zum Schutz von PII in Nicht-Produktivumgebungen oder bei der Weitergabe von Daten verwendet wird. Sie unterstützt 5.34 unmittelbar, indem sie die Exponierung echter personenbezogener Daten reduziert und damit das Datenschutzrisiko senkt.

Zur Data Loss Prevention erläutert der Leitfaden die praktische Grenze:

DLP spielt eine direkte Rolle beim Schutz personenbezogener Daten. Maßnahme 8.12 setzt Grenzen dafür durch, wie auf PII zugegriffen werden kann, wie sie weitergegeben oder bewegt werden können, und stellt sicher, dass personenbezogene Daten nicht über nicht autorisierte Kanäle abfließen können.

Ein Auditor, der Offenlegungs-Governance prüft, kann daher nicht nur REG08 anfordern, sondern auch DLP-Richtlinien, Protokolle blockierter Übermittlungen, Kontrollen für ausgehende E-Mails, Beschränkungen für Cloud-Freigaben, Verschlüsselungsanforderungen, Aufzeichnungen zu Lieferantenzugriffen und Nachweise freigegebener Ausnahmen.

Cross-Compliance-Wert: GDPR, ISO 27701, NIS2, DORA, NIST und COBIT

Governance für Erhebung, Nutzung und Offenlegung von PII ist datenschutzgeführt, ihre Nachweise unterstützen jedoch weitergehende Verpflichtungen zu Cybersicherheit, Resilienz und Governance.

GDPR Articles 2 und 3 definieren einen breiten sachlichen und territorialen Anwendungsbereich, der SaaS-, Fintech- und digitale Dienstleister außerhalb der EU erfassen kann, wenn sie EU-Personen bedienen oder beobachten. Article 5 verlangt Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität, Vertraulichkeit und Rechenschaftspflicht. Article 6 verlangt Rechtsgrundlage und Vereinbarkeitsbewertung für die Weiterverarbeitung. Article 9 ergänzt strengere Bedingungen für besondere Kategorien personenbezogener Daten, relevant bei Profiling, gesundheitsnahen Daten, biometrischem Onboarding oder sensitiven Attributen.

NIS2 Article 21 verlangt von wesentlichen und wichtigen Einrichtungen die Umsetzung verhältnismäßiger technischer, operativer und organisatorischer Risikomanagementmaßnahmen. Die Mindestbereiche umfassen Risikoanalyse, Sicherheitsrichtlinien für Informationssysteme, Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Entwicklung, Kontrollwirksamkeit, Schulung, Kryptografie, Sicherheit im Personalwesen, Zugriffskontrolle, Asset-Management und Authentifizierung.

DORA verlangt von Finanzunternehmen die Aufrechterhaltung eines Rahmenwerks für das Management von IKT-Risiken, Rechenschaftspflicht des Leitungsorgans, Identifizierung von IKT-Assets und Abhängigkeiten, Schutz- und Präventionskontrollen, Erkennung, Reaktion, Wiederherstellung, Backup, Lernen, Vorfallmanagement, Tests und Management von IKT-Drittparteienrisiken. DORA verlangt außerdem Informationsregister für IKT-Serviceverträge, gebotene Sorgfalt, Auditrechte, Sicherheitsanforderungen und Exit-Strategien.

Das NIST Cybersecurity Framework 2.0 bietet eine verbindende Governance-Sprache. Seine GOVERN-Funktion erwartet, dass gesetzliche, regulatorische und vertragliche Anforderungen einschließlich Datenschutzpflichten verstanden und gesteuert werden. Sie umfasst außerdem Risikostrategie, Rollen, Richtlinien, Aufsicht und Lieferantenrisikomanagement.

COBIT 2019-Auditoren suchen nach Governance-Zielen, Entscheidungsrechten, Rechenschaftspflicht, Prozessverantwortung, Leistungsindikatoren und Nachweisen der Sicherstellung. Für PII-Governance bedeutet das, dass Datenschutzanforderungen in die Unternehmensführung eingebettet werden müssen und nicht als Nebenprozess verwaltet werden dürfen.

Wie Auditoren dieselbe Governance-Ebene prüfen

Eine starke PIMS-Umsetzung sollte unterschiedliche Auditstile bestehen.

Ein ISO/IEC 27001:2022- und ISO/IEC 27701:2025-Auditor beginnt mit Geltungsbereich, interessierten Parteien, gesetzlichen und vertraglichen Anforderungen, Risikobeurteilung, Anwendbarkeitserklärung (SoA), operativer Planung und dokumentierten Nachweisen. Er kann Verarbeitungstätigkeiten aus REG02 stichprobenartig prüfen und testen, ob Kontrollen wie 5.34, 5.12, 5.14, 5.19 bis 5.23, 8.11, 8.12, 8.15, 8.16 und 8.24 umgesetzt und überwacht werden.

Ein auf GDPR fokussierter Auditor oder eine Aufsichtsbehörde prüft die Rechenschaftspflicht. Ausgangspunkt kann ein Datenschutzhinweis, eine Beschwerde, eine Betroffenenanfrage oder eine Lieferantenoffenlegung sein; anschließend wird rückwärts nachverfolgt. Warum wurden diese Daten erhoben? Welche Rechtsgrundlage galt? War der Zweck festgelegt? War die spätere Nutzung vereinbar? War der Empfänger autorisiert? Wurden die betroffenen Personen informiert? Wurden die Aufzeichnungen vor Beginn der Verarbeitung aktualisiert?

Eine DORA-Aufsichtsbehörde konzentriert sich, sofern einschlägig, auf IKT-gestützte Geschäftsfunktionen, IKT-Drittanbieter, Vertragsklauseln, Auditrechte, Datenschutz, Vorfallkommunikation, Resilienztests und Exit-Planung. Wenn Kunden-PII mit einem kritischen Analyse- oder Cloud-Anbieter geteilt werden, werden REG08, Lieferanten-Due-Diligence und Vertragskontrollen zu zentralen Nachweisen.

Ein NIST CSF-Assessor rahmt das Thema über Governance-Ergebnisse. Werden gesetzliche und regulatorische Anforderungen gesteuert? Sind Rollen und Verantwortlichkeiten klar? Werden Richtlinien gepflegt und durchgesetzt? Werden Lieferantenrisiken gesteuert? Funktionieren Datenschutz-, Überwachungs- und Reaktionsergebnisse im Betrieb?

Ein COBIT- oder ISACA-orientierter Auditor fragt, ob Entscheidungsrechte definiert sind, ob Geschäftsinhaber Datenschutzrisiken akzeptieren, ob Kontrollleistung gemessen wird, ob Ausnahmen nachverfolgt werden und ob das Management aussagekräftige Berichte erhält.

Häufige Schwachstellen, die Clarysec in Umsetzungen findet

Die erste Schwachstelle besteht darin, das Verarbeitungsinventar als Dokumentationsübung statt als Freigabegate zu behandeln. Wenn REG02 erst nach der Produktivsetzung aktualisiert wird, kann es keine vorherige Governance nachweisen.

Die zweite Schwachstelle ist eine vage Zweckbeschreibung. „Analytics“, „Serviceverbesserung“ oder „Kundenerkenntnisse“ sind selten spezifisch genug, um interne Nutzung oder Sekundärnutzung zu steuern.

Die dritte Schwachstelle ist fehlende Erforderlichkeit auf Feldebene. Datenminimierung lässt sich nicht dadurch nachweisen, dass jedes Feld nützlich sei. Der Fachbereich muss erklären, warum jedes Feld für den freigegebenen Zweck erforderlich ist.

Die vierte Schwachstelle ist unkontrollierte Sekundärnutzung. Daten, die für die Kontoverwaltung erhoben wurden, werden schleichend zu Vertriebsinformationen, dann zu Marketingsegmentierung und anschließend zu KI-Training. Jede Zweckänderung erfordert eine Vereinbarkeitsanalyse und in manchen Fällen eine neue Rechtsgrundlage oder Transparenzaktualisierung.

Die fünfte Schwachstelle ist schwache Offenlegungs-Governance. Lieferantenlisten sind nicht dasselbe wie Offenlegungsdatensätze. REG08 verbindet Empfänger, Rolle, Zweck, PII-Kategorien, Standort, Frequenz und maßgebliche Befugnisquelle in einem Freigabeverlauf.

Die sechste Schwachstelle ist fehlende technische Durchsetzung. Richtlinien können festlegen, dass PII genehmigte Kanäle nicht verlassen dürfen, aber E-Mail, Exporte, gemeinsame Laufwerke und Analysewerkzeuge ermöglichen dies häufig dennoch. Genau hier werden ISO/IEC 27002:2022 Maßnahmen 5.14, 8.12, 8.15, 8.16 und 8.24 wesentlich.

Ein pragmatischer 30-Tage-Startplan

Organisationen müssen nicht alles auf einmal angehen. Beginnen Sie mit einer risikobehafteten Verarbeitungstätigkeit, vorzugsweise einer mit Kundenprofiling, KI-Analysen, sensitiven Attributen, grenzüberschreitender Übermittlung oder einer Drittparteienplattform.

Identifizieren Sie in der ersten Woche die Verarbeitungstätigkeit, den Verantwortlichen, PII-Kategorien, Systeme, Lieferanten und den aktuellen Zweck. Bestätigen Sie, ob die Tätigkeit bereits in REG02 abgebildet ist und ob die Offenlegung in REG08 erfasst ist.

Vervollständigen Sie in der zweiten Woche Erforderlichkeitsbegründungen auf Feldebene. Hinterfragen Sie übermäßige Datenelemente. Bestätigen Sie Klassifizierung und Kennzeichnung. Ermitteln Sie, ob Maskierung, Aggregation oder Pseudonymisierung das Risiko reduzieren können.

Definieren Sie in der dritten Woche Regeln zur internen Nutzung und führen Sie erforderliche Vereinbarkeitsprüfungen für Sekundärnutzung durch. Entscheiden Sie, ob Datenschutzhinweise, Bewertungen der Rechtsgrundlage oder Betroffenenkontrollen aktualisiert werden müssen.

Validieren Sie in der vierten Woche externe Offenlegungsdatensätze, Lieferantenzugriff, vertragliche Schutzmaßnahmen, Auftragsverarbeitungsvertragsbedingungen, Übermittlungskontrollen, Protokollierung, DLP und Löschpflichten. Prüfen Sie anschließend das tatsächliche Systemverhalten stichprobenartig gegen die Freigaben.

Nach 30 Tagen sollte das Management über ein konkretes Nachweispaket verfügen: REG02, REG08, Klassifizierungsaufzeichnungen, Zugriffsmatrizen, DLP- und Protokollierungsnachweise, Lieferanten-Due-Diligence, vertragliche Schutzmaßnahmen, Vereinbarkeitsprüfungen und offene Abhilfemaßnahmen.

Von der Richtlinie zum Nachweis

Governance für Erhebung, Nutzung und Offenlegung von PII ist der Punkt, an dem Datenschutz real wird. Sie ist der Unterschied zwischen der Aussage „wir erfüllen GDPR“ und dem Nachweis, dass jede Entscheidung über Erhebung, Nutzung, Wiederverwendung und Offenlegung kontrolliert wurde, bevor die Verarbeitung stattgefunden hat.

Das Clarysec-Toolkit bietet Datenschutz-, Sicherheits- und Compliance-Teams einen praktischen Weg:

• Nutzen Sie die PII09 Richtlinie zur Erhebung, Nutzung, Offenlegung und Weitergabe von PII, um verpflichtende Freigabegates zu definieren.
• Nutzen Sie die P17 Richtlinie zu Datenschutz und Privatsphäre oder die Richtlinie zu Datenschutz und Privatsphäre - KMU, um rechtmäßige, faire, transparente und minimierte Verarbeitung zu verankern.
• Nutzen Sie die Richtlinie zur Datenklassifizierung und Kennzeichnung und die Richtlinie zur Lieferanten- und Drittparteiensicherheit - KMU, um Klassifizierung, Weitergabe und Lieferantenzugriff zu steuern.
• Folgen Sie Zenith Blueprint: Fahrplan für Auditoren in 30 Schritten, um das Kontrollumfeld in der richtigen Reihenfolge umzusetzen.
• Nutzen Sie Zenith Controls: Leitfaden für frameworkübergreifende Compliance, um zu verstehen, wie ISO/IEC 27002:2022-Maßnahmen wie 5.34, 5.12, 5.14, 8.11 und 8.12 GDPR, NIS2, DORA, NIST und Auditerwartungen unterstützen.

Wenn Ihr nächstes Audit, Ihre nächste Kunden-Due-Diligence-Anfrage oder Ihre nächste Überprüfung durch das Leitungsorgan fragt, wie Sie steuern, welche PII erhoben werden, wie sie genutzt werden und wann sie offengelegt werden, verlassen Sie sich nicht allein auf Richtlinienaussagen.

Beginnen Sie mit einer risikobehafteten Tätigkeit. Erstellen Sie den REG02-Datensatz. Begründen Sie jedes Datenelement. Definieren Sie Regeln zur internen Nutzung. Führen Sie die Vereinbarkeitsprüfung für Sekundärnutzung durch. Erstellen Sie den REG08-Offenlegungsdatensatz. Prüfen Sie anschließend, ob Zugriff, DLP, Maskierung, Protokollierung, Verschlüsselung und Lieferantenkontrollen zur Entscheidung passen.

So werden Rechenschaftspflicht nach ISO/IEC 27701:2025 und GDPR zu Nachweisen.

Entdecken Sie das Clarysec PIMS-Toolkit, beginnen Sie mit der PII09 Richtlinie zur Erhebung, Nutzung, Offenlegung und Weitergabe von PII, und nutzen Sie Zenith Blueprint, um Datenschutz-Governance von Richtlinienabsicht in auditfähige Nachweise zu überführen.