Auditfähiger Schutz personenbezogener Daten für GDPR, NIS2 und DORA
Die Warnmeldung erreichte Sarahs Posteingang an einem Dienstag um 22 Uhr.
Als CISO eines wachsenden FinTech-SaaS-Unternehmens waren ihr nächtliche Warnmeldungen vertraut. Diese war anders. Ein Junior-Entwickler hatte beim Testen einer neuen Analysefunktion eine Staging-Datenbank über einen öffentlichen Endpunkt erreichbar gemacht. Die Datenbank sollte Testdaten enthalten, war jedoch durch eine kurz zuvor durchgeführte Synchronisierung von Produktion nach Staging mit echten personenbezogenen Kundendaten befüllt worden.
Der Vorfall wurde schnell eingedämmt. Dann folgte die zweite Feststellung. Eine Migrationstabelle mit dem Namen customer_users_final_v7.xlsx war aus demselben Datenbestand kopiert worden. Sie enthielt Namen, E-Mail-Adressen, Rollenberechtigungen, Nutzungsprotokolle, Länderfelder, Support-Notizen und Freitextkommentare, die niemals in einen Testprozess hätten gelangen dürfen. Die Datei war auf ein gemeinsames Laufwerk kopiert, von einem Entwickler heruntergeladen, an ein Ticket angehängt und anschließend vergessen worden.
Um Mitternacht steuerte Sarah keine technische Fehlkonfiguration mehr. Sie steuerte ein Auditproblem.
Das Unternehmen war bereits nach ISO/IEC 27001:2022 zertifiziert. Das Leitungsorgan verlangte belastbare GDPR-Sicherheit vor dem EU-Markteintritt. Kunden aus dem Finanzsektor versendeten DORA-Due-Diligence-Fragebögen. Cloud- und Managed-Service-Beziehungen warfen Fragen zur NIS2-Lieferkette auf. Die Rechtsabteilung konnte die Verpflichtungen erklären. Engineering konnte auf Verschlüsselung verweisen. Das Produktteam hatte Privacy-by-Design-Absichten. Die Anwendbarkeitserklärung (SoA) erwähnte Datenschutz und den Schutz personenbezogener Daten.
Aber niemand konnte in einer durchgängigen, nachvollziehbaren Kette zeigen, welche personenbezogenen Daten vorhanden waren, warum sie verarbeitet wurden, wer darauf zugreifen durfte, wo sie maskiert wurden, welche Lieferanten sie berührten, wie lange sie aufbewahrt wurden und wie ein Vorfall nach GDPR, NIS2 oder DORA einzustufen wäre.
Genau diese Lücke erklärt, warum ISO/IEC 27701:2025 und ISO/IEC 29151:2022 relevant sind. Sie sind nicht bloß Datenschutz-Etiketten. Sie helfen Organisationen, Datenschutzversprechen in auditfähige Kontrollen zum Schutz personenbezogener Daten zu überführen. ISO/IEC 27701:2025 erweitert ein Informationssicherheits-Managementsystem nach ISO/IEC 27001:2022 zu einem Datenschutz-Informationsmanagementsystem. ISO/IEC 29151:2022 ergänzt praktische Leitlinien zum Schutz personenbezogener Daten über deren gesamten Lebenszyklus.
Der Ansatz von Clarysec besteht darin, ein einheitliches, nachweisorientiertes Betriebsmodell für Datenschutz und Informationssicherheit aufzubauen, statt getrennte Compliance-Silos zu betreiben. Dieses Modell kombiniert Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Zenith Controls: The Cross-Compliance Guide Zenith Controls und Clarysec-Richtlinien zu einem durchgängig nachvollziehbaren System für GDPR, ISO/IEC 27001:2022, ISO/IEC 27701:2025, ISO/IEC 29151:2022, NIS2, DORA, an NIST ausgerichtete Kontrollsicherheit und Governance-Erwartungen nach COBIT 2019.
Warum der Schutz personenbezogener Daten heute ein Audit-Thema für das Leitungsorgan ist
Der Schutz personenbezogener Daten wurde früher als Zuständigkeit des Datenschutzteams behandelt. Heute ist er ein Thema für Vertrauen, Resilienz und Regulierung auf Ebene des Leitungsorgans.
GDPR bleibt die Grundlage für den Schutz personenbezogener Daten in Europa und darüber hinaus. Die Verordnung definiert personenbezogene Daten, Verarbeitung, Verantwortliche, Auftragsverarbeiter, Empfänger, Dritte, Einwilligung und Verletzungen des Schutzes personenbezogener Daten in einer Weise, die SaaS-Verträge, Supportprozesse, Analysen, Produkttelemetrie, Lieferantenmanagement und Incident Response beeinflusst. Ihre Grundsätze verlangen Rechtmäßigkeit, Fairness, Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität, Vertraulichkeit und Rechenschaftspflicht. Aus Auditsicht fragt GDPR nicht nur, ob Daten verschlüsselt sind. Gefragt wird, ob die Organisation nachweisen kann, warum Daten vorhanden sind und wie die Einhaltung sichergestellt wird.
NIS2 erhöht die Anforderungen an die Cybersicherheits-Governance für wesentliche und wichtige Einrichtungen. Article 21 verlangt Maßnahmen zum Cybersicherheitsrisikomanagement, einschließlich Risikoanalyse, Informationssicherheitsrichtlinien für Informationssysteme, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sicherer Entwicklung, Schwachstellenbehandlung, Bewertung der Kontrollwirksamkeit, Cyberhygiene, Kryptografie, Personalsicherheit, Zugriffskontrolle, Asset-Management, Authentifizierung und sicherer Kommunikation. Article 23 ergänzt eine gestufte Vorfallmeldung, einschließlich Frühwarnung innerhalb von 24 Stunden, Meldung innerhalb von 72 Stunden und Abschlussbericht innerhalb eines Monats nach der Meldung.
DORA verändert die Diskussion für Finanzunternehmen und ihre IKT-Anbieter. DORA gilt ab dem 17. Januar 2025 und schafft ein harmonisiertes Regelwerk zur digitalen operativen Resilienz, das IKT-Risikomanagement, die Meldung schwerwiegender IKT-bezogener Vorfälle, Resilienztests, IKT-Drittparteienrisiko, vertragliche Anforderungen und die Beaufsichtigung kritischer IKT-Drittdienstleister umfasst. Für viele Finanzunternehmen fungiert DORA als sektorspezifischer Rechtsakt der Union, wenn NIS2-äquivalente Verpflichtungen überlappen. Für SaaS- und IKT-Lieferanten, die Finanzinstitute bedienen, entsteht DORA-Druck häufig über Vertragsklauseln, Kundenaudits, Anforderungen an Exit-Planung, Verpflichtungen zur Vorfallsunterstützung und Resilienztests.
ISO/IEC 27001:2022 stellt das Rückgrat des Managementsystems bereit. Die Norm verlangt Kontext, interessierte Parteien, Geltungsbereich, Führungsverantwortung, Richtlinien, Rollen, Risikobeurteilung, Risikobehandlung, Anwendbarkeitserklärung, interne Audits, Managementbewertung und kontinuierliche Verbesserung. Anhang A enthält Maßnahmen, die unmittelbar für den Schutz personenbezogener Daten relevant sind, darunter 5.34 Datenschutz und Schutz personenbezogener Daten, 5.18 Zugriffsrechte, 8.11 Datenmaskierung, 5.23 Informationssicherheit bei der Nutzung von Cloud-Services, 8.15 Protokollierung, 8.33 Testinformationen, 8.24 Einsatz von Kryptografie und 8.10 Löschung von Informationen.
Die Herausforderung besteht nicht darin, dass Organisationen keine Kontrollen haben. Sie besteht darin, dass Kontrollen fragmentiert sind. Datenschutzaufzeichnungen liegen in der Rechtsabteilung. Berechtigungsüberprüfungen liegen in der IT. Maskierungsskripte liegen im Engineering. Lieferantenverträge liegen in der Beschaffung. Nachweise liegen in Tickets, Screenshots, Tabellen und E-Mails.
ISO/IEC 27701:2025 und ISO/IEC 29151:2022 helfen, diese Nachweise rund um das Datenschutz-Informationsmanagement und Praktiken zum Schutz personenbezogener Daten zu bündeln. Clarysec überführt diese Struktur in ein Betriebsmodell.
Vom ISMS zum PIMS: die integrierte Datenschutz-Kontrollkette
Ein ISMS nach ISO/IEC 27001:2022 beantwortet eine Kernfrage: Wird Informationssicherheit gesteuert, risikobasiert umgesetzt, überwacht und verbessert?
Ein Privacy Information Management System, kurz PIMS, erweitert diese Frage für personenbezogene Daten: Werden Datenschutzverantwortlichkeiten, Verarbeitungstätigkeiten mit personenbezogenen Daten, Datenschutzrisiken, Verpflichtungen von Verantwortlichen und Auftragsverarbeitern, Rechte betroffener Personen und Nachweise zu Datenschutzkontrollen innerhalb desselben Systems gesteuert?
ISO/IEC 27701:2025 erweitert das ISMS um Datenschutz-Governance. ISO/IEC 29151:2022 ergänzt dies durch praktische Leitlinien zum Schutz personenbezogener Daten, einschließlich Beschränkung der Erhebung, Steuerung von Offenlegungen, Anwendung von Maskierung oder Pseudonymisierung, Schutz von Übermittlungen, Zugriffsbeschränkung und Ausrichtung der Kontrollen am Datenschutzrisiko.
| Ebene | Leitfrage | Typische Auditnachweise |
|---|---|---|
| ISO/IEC 27001:2022 | Gibt es ein gesteuertes, risikobasiertes ISMS mit ausgewählten und wirksam betriebenen Kontrollen? | Geltungsbereich, interessierte Parteien, Risikobeurteilung, Behandlungsplan, SoA, Richtlinien, internes Audit, Managementbewertung |
| ISO/IEC 27701:2025 | Werden Datenschutzverantwortlichkeiten, Datenschutzrisiken und Verarbeitungstätigkeiten mit personenbezogenen Daten innerhalb des Managementsystems gesteuert? | Datenschutzrollen, Verzeichnis der Verarbeitungstätigkeiten, Verfahren für Verantwortliche und Auftragsverarbeiter, Bewertungen von Datenschutzrisiken, DSFAs (DPIAs), Prozess für Betroffenenanfragen |
| ISO/IEC 29151:2022 | Sind praktische Maßnahmen zum Schutz personenbezogener Daten über den Datenlebenszyklus umgesetzt? | Klassifizierung personenbezogener Daten, Zugriffsbeschränkungen, Maskierung, Pseudonymisierung, Aufbewahrungskontrollen, Schutzmaßnahmen für Übermittlungen, Vorfallsnachweise |
| GDPR | Kann die Organisation rechtmäßige, faire, transparente, minimierte, sichere und rechenschaftspflichtige Verarbeitung nachweisen? | Aufzeichnungen zu Rechtsgrundlagen, Datenschutzhinweise, DSFAs (DPIAs), Prozess für Datenschutzverletzungen, Auftragsverarbeitungsverträge, Bearbeitung von Betroffenenrechten |
| NIS2 und DORA | Kann die Organisation Cybersicherheits- und Resilienzrisiken einschließlich Vorfällen und Lieferanten steuern? | Aufsicht durch das Management, IKT-Risikomanagementrahmen, Vorfallklassifizierung, Melde-Playbooks, Lieferantenregister, Auditrechte, Kontinuitätstests |
Dieses Schichtenmodell verhindert den häufigsten Fehler bei der Datenschutz-Compliance: personenbezogene Daten wie einen weiteren sensiblen Datentyp zu behandeln. Personenbezogene Daten bringen rechtliche, ethische, operative, vertragliche und reputationsbezogene Verpflichtungen mit sich. Sie benötigen eine Kontrollkette, die mit Transparenz über Daten beginnt und mit Nachweisen endet.
Mit Datenbewusstsein beginnen, nicht mit Verschlüsselungsdiagrammen
Der häufigste Datenschutzfehler, den Clarysec sieht, ist fehlender Kontext. Ein Unternehmen kann personenbezogene Daten nicht schützen, wenn es nicht weiß, welche personenbezogenen Daten vorhanden sind, wo sie liegen, welchem Zweck sie dienen, wie lange sie aufbewahrt werden oder wer auf sie zugreifen kann.
Der Zenith Blueprint beginnt diese Arbeit früh in der Phase Risikomanagement. In Schritt 9, Identifizierung von Assets, Bedrohungen und Schwachstellen, weist er Organisationen an, Informations-Assets zu inventarisieren und personenbezogene Daten ausdrücklich zu kennzeichnen:
„Erfassen Sie für jedes Asset die zentralen Angaben: Name/Beschreibung, Verantwortlicher, Standort und Klassifizierung (Sensitivität). Ein Asset könnte zum Beispiel lauten: ‚Kundendatenbank – verantwortlich: IT-Abteilung – gehostet auf AWS – enthält personenbezogene und Finanzdaten (hohe Sensitivität).‘“
Außerdem heißt es: „Stellen Sie sicher, dass Assets mit personenbezogenen Daten gekennzeichnet werden (wegen GDPR-Relevanz) und kritische Service-Assets vermerkt werden (wegen möglicher NIS2-Anwendbarkeit, wenn Sie in einem regulierten Sektor tätig sind).“
Dies ist die Grundlage für die Einführung von ISO/IEC 27701:2025 und ISO/IEC 29151:2022. Die praktische Abfolge ist einfach:
- Identifizieren Sie Systeme, Datenbestände, Repositories, Protokolle, Berichte, Backups, Support-Werkzeuge, Entwicklungsumgebungen und Lieferanten, die personenbezogene Daten verarbeiten.
- Weisen Sie jedem Asset mit personenbezogenen Daten einen Verantwortlichen zu.
- Klassifizieren Sie personenbezogene Daten nach Sensitivität, Geschäftszweck, Rechtsgrundlage, Verarbeitungsrolle und Aufbewahrungsanforderung.
- Verknüpfen Sie jedes Asset mit personenbezogenen Daten mit Bedrohungen, Schwachstellen, Risikoszenarien und regulatorischen Verpflichtungen.
- Wählen Sie Kontrollen aus, weisen Sie Nachweise zu und überwachen Sie den Betrieb über die Zeit.
Clarysec-Richtlinien machen dies umsetzbar. Die KMU-Richtlinie zu Datenschutz und Privatsphäre Data Protection and Privacy Policy - SME legt fest:
„Der Datenschutzkoordinator muss ein Register aller Verarbeitungstätigkeiten für personenbezogene Daten führen, einschließlich Datenkategorien, Zweck, Rechtsgrundlage und Aufbewahrungsfristen.“
Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.2.1.
Für große Unternehmen etabliert die Richtlinie zu Datenschutz und Privatsphäre Richtlinie zu Datenschutz und Privatsphäre eine verbindliche Minimierungsregel:
„Es dürfen nur Daten erhoben und verarbeitet werden, die für einen konkreten, legitimen Geschäftszweck erforderlich sind.“
Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.2.1.
Diese Klauseln überführen die Rechenschaftspflicht nach GDPR in den täglichen Betrieb. Sie unterstützen außerdem das Datenschutz-Informationsmanagement und den Schutz personenbezogener Daten, weil sie die Organisation verpflichten zu definieren, welche Daten vorhanden sind, warum sie vorhanden sind und ob sie erforderlich sind.
Die drei Maßnahmen, die den Schutz personenbezogener Daten belastbar machen
Drei Maßnahmen aus Anhang A der ISO/IEC 27001:2022 entscheiden häufig darüber, ob der Schutz personenbezogener Daten in einem Audit belastbar ist: 5.34 Datenschutz und Schutz personenbezogener Daten, 8.11 Datenmaskierung und 5.18 Zugriffsrechte.
5.34 Datenschutz und Schutz personenbezogener Daten
Maßnahme 5.34 ist der Governance-Knotenpunkt. In Zenith Controls wird 5.34 als präventive Kontrolle behandelt, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt, mit den Cybersicherheitskonzepten Identify und Protect sowie operativen Fähigkeiten im Informationsschutz und in der Einhaltung gesetzlicher Anforderungen.
Zenith Controls macht die Abhängigkeit deutlich:
„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 hat und wo sie sich befinden; das ist der erste Schritt zu deren Schutz.“
Maßnahme 5.34 hängt von 5.9 Inventar von Informationen und anderen zugehörigen Assets ab, weil personenbezogene Daten nicht geschützt werden können, wenn sie nicht auffindbar sind. Sie ist außerdem mit 5.23 Informationssicherheit bei der Nutzung von Cloud-Services verbunden, weil personenbezogene Daten heute überwiegend in Cloud-Plattformen, SaaS-Werkzeugen, Analyseumgebungen und Managed Services liegen.
Für risikobehaftete Verarbeitung verlangt die unternehmensweite Richtlinie zu Datenschutz und Privatsphäre:
„Threat Modeling und Datenschutz-Folgenabschätzungen (DPIAs) sind für Verarbeitungssysteme mit hohem Risiko verpflichtend.“
Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.3.4.
Diese Klausel ist entscheidend. Sie macht Datenschutz zu einer Design- und Risikomanagementaktivität, nicht zu einer nachgelagerten rechtlichen Prüfung.
8.11 Datenmaskierung
Maßnahme 8.11 ist die direkte Antwort auf Sarahs exponierte Staging-Datenbank. Zenith Controls beschreibt 8.11 als präventive Vertraulichkeitskontrolle im Informationsschutz. Die Maßnahme verknüpft 8.11 mit 5.12 Klassifizierung von Informationen, weil Maskierungsentscheidungen von der Sensitivität abhängen, mit 5.34, weil Maskierung den Datenschutz unterstützt, und mit 8.33 Testinformationen, weil Testumgebungen keine echten personenbezogenen Daten offenlegen sollten.
Die Richtlinie zur Datenmaskierung und Pseudonymisierung Richtlinie zur Datenmaskierung und Pseudonymisierung formuliert die Regel ausdrücklich:
„Echte personenbezogene Daten dürfen nicht in Entwicklungs-, Test- oder Staging-Umgebungen verwendet werden. Stattdessen müssen maskierte oder pseudonymisierte Daten verwendet werden, die aus vorab genehmigten Transformationsvorlagen erzeugt wurden.“
Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.3.
Für KMU ergänzt die KMU-Richtlinie zur Datenmaskierung und Pseudonymisierung Data Masking and Pseudonymization Policy - SME eine wesentliche Sicherheits- und Nachweisanforderung:
„Der Zugriff auf Schlüssel muss verschlüsselt, zugriffskontrolliert und protokolliert sein.“
Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.2.1.3.
Dies ist wichtig, weil Pseudonymisierung das Risiko nur reduziert, wenn Transformationslogik, Schlüssel und Re-Identifizierungspfade kontrolliert werden.
5.18 Zugriffsrechte
Maßnahme 5.18 ist der operative Kern des Prinzips der minimalen Berechtigung. Zenith Controls behandelt sie als präventiv, verknüpft mit Vertraulichkeit, Integrität und Verfügbarkeit, und ordnet sie dem Identitäts- und Zugriffsmanagement zu. 5.18 ist mit 5.15 Zugriffskontrolle, 5.16 Identitätsmanagement und 8.2 privilegierte Zugriffsrechte verbunden.
Die KMU-Richtlinie zur Datenklassifizierung und Kennzeichnung Data Classification and Labeling Policy - SME legt fest:
„Der Zugriff muss auf ausdrücklich autorisierte Benutzer mit Need-to-know beschränkt werden.“
Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.2.1.
Die unternehmensweite Richtlinie zur Datenklassifizierung und Kennzeichnung Richtlinie zur Datenklassifizierung und Kennzeichnung ergänzt die Klassifizierungsbasislinie:
„Alle Informations-Assets müssen zum Zeitpunkt der Erstellung oder des Onboardings eindeutig klassifiziert werden. Fehlt eine ausdrückliche Klassifizierung, müssen Assets bis zur formellen Überprüfung standardmäßig als ‚Vertraulich‘ eingestuft werden.“
Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.4.
Zusammen bilden diese Kontrollen die praktische Kontrollkette zum Schutz personenbezogener Daten: personenbezogene Daten kennen, klassifizieren, Zugriff begrenzen, maskieren, wenn eine vollständige Identität nicht erforderlich ist, Schlüssel schützen, Zugriffe protokollieren und Nachweise aufbewahren.
Nachvollziehbarkeit über die Anwendbarkeitserklärung herstellen
Ein Datenschutz-Managementsystem wird auditfähig, wenn es Nachvollziehbarkeit nachweisen kann. Der Zenith Blueprint, Phase Risikomanagement, Schritt 13, Risikobehandlungsplanung und Anwendbarkeitserklärung, beschreibt die Anwendbarkeitserklärung als Brückendokument:
„Die SoA ist faktisch ein Brückendokument: Sie verbindet Ihre Risikobeurteilung und Risikobehandlung mit den tatsächlich vorhandenen Kontrollen. Mit ihrer Fertigstellung prüfen Sie zugleich, ob Sie Kontrollen übersehen haben.“
Dieses Konzept ist zentral für die Vorbereitung auf ISO/IEC 27701:2025, ISO/IEC 29151:2022, GDPR, NIS2 und DORA. Jede Kontrolle für personenbezogene Daten sollte von der Anforderung zum Risiko, vom Risiko zur Kontrolle, von der Kontrolle zum Verantwortlichen, vom Verantwortlichen zum Nachweis und vom Nachweis zur Überprüfung nachvollziehbar sein.
| Nachvollziehbarkeitselement | Beispiel für personenbezogene Daten im Kundensupport | Erwartete Nachweise |
|---|---|---|
| Asset mit personenbezogenen Daten | Support-Ticketsystem mit Kundennamen, E-Mail-Adressen, Protokollen und Anhängen | Eintrag im Asset-Register, Verantwortlicher, Cloud-Standort, Klassifizierung |
| Verarbeitungszweck | Kundensupport und Servicediagnose | Verzeichnis der Verarbeitungstätigkeiten, Rechtsgrundlage, Aufbewahrungsfrist |
| Risikoszenario | Supportmitarbeiter oder Entwickler greift auf übermäßige Kundendaten zu | Eintrag im Risikoregister, Eintrittswahrscheinlichkeit, Auswirkung, Verantwortlicher |
| Kontrollauswahl | 5.34 Schutz personenbezogener Daten, 5.18 Zugriffsrechte, 8.11 Maskierung, 8.15 Protokollierung, 5.23 Cloud-Governance | SoA, Zugriffsrichtlinie, Maskierungsstandard, Protokollierungskonfiguration |
| Operative Nachweise | rollenbasierter Zugriff, maskierte Exporte, vierteljährliche Berechtigungsüberprüfung, Warnmeldungen bei Massendownloads | Berechtigungsüberprüfungsaufzeichnungen, DLP-Warnmeldungen, Protokolle, Ticketnachweise |
| Regulatorische Zuordnung | Rechenschaftspflicht und Sicherheit nach GDPR, Risikomanagement nach NIS2, IKT-Risiko- und Lieferantenanforderungen nach DORA | Compliance-Matrix, Vorfalls-Playbook, Lieferantenvertragsregister |
| Überprüfungsnachweise | Feststellung aus internem Audit geschlossen, Maßnahme aus Managementbewertung angenommen | Auditbericht, Korrekturmaßnahme, Protokoll der Managementbewertung |
ISO/IEC 27005:2022 unterstützt diesen risikobasierten Ansatz, indem die Norm Anforderungen interessierter Parteien, gemeinsame Risikokriterien, verantwortliche Risikoeigner, wiederholbare Risikobeurteilung, Risikobehandlung, Kontrollauswahl, Ausrichtung der Anwendbarkeitserklärung, Genehmigung von Restrisiken, Überwachung und kontinuierliche Verbesserung betont. Der Schutz personenbezogener Daten sollte ein lebendiger Risikokreislauf sein, keine einmalige GDPR-Dokumentationsübung.
Die riskante Tabelle und die Staging-Datenbank beheben
Sarahs Vorfall kann in ein wiederholbares Kontrollpaket überführt werden, wenn die Abhilfemaßnahmen systematisch gesteuert werden.
| Schritt | Maßnahme | Ergebnis für Clarysec-Nachweise |
|---|---|---|
| 1 | Staging-Datenbank und Tabelle als Assets mit personenbezogenen Daten registrieren | Einträge im Asset-Inventar mit Verantwortlichem, Standort, Klassifizierung, Kategorien personenbezogener Daten, Zweck und Aufbewahrung |
| 2 | Verarbeitungstätigkeit aktualisieren | Registereintrag mit Datenkategorien, Rechtsgrundlage, Zweck und Aufbewahrungsfrist |
| 3 | Dateien und Datenbestände klassifizieren | Standardmäßige Einstufung als Vertraulich oder höher bis zur formellen Überprüfung |
| 4 | Echte personenbezogene Daten aus Nicht-Produktivumgebungen entfernen | Maskierter oder pseudonymisierter Datenbestand, erzeugt aus genehmigten Transformationsvorlagen |
| 5 | Zugriff beschränken und überprüfen | Need-to-know-Berechtigungen, entzogener übermäßiger Zugriff, Aufzeichnung der Berechtigungsüberprüfung |
| 6 | Transformationslogik und Schlüssel schützen | Verschlüsselter, zugriffskontrollierter und protokollierter Schlüsselzugriff |
| 7 | Nachweise zentral erfassen | Asset-Aufzeichnung, Risikoeintrag, Berechtigungsüberprüfung, Löschungsnachweis, Maskierungsgenehmigung und Ticketabschluss |
| 8 | SoA und Risikobehandlungsplan aktualisieren | Risikoszenario verknüpft mit 5.34, 5.18, 8.11, 8.15, 8.10, 5.23 und Lieferantenkontrollen |
| 9 | Entscheiden, ob eine DSFA erforderlich ist | DSFA oder dokumentierte Begründung für Entscheidungen zu Verarbeitung mit hohem Risiko |
| 10 | Lessons Learned dokumentieren | Aktualisierte Schulung, Regeln für sichere Entwicklung, Exportkontrollen, DLP-Überwachung und Vorgaben für Testdaten |
Die KMU-Richtlinie zur Audit- und Compliance-Überwachung Audit and Compliance Monitoring Policy - SME legt fest:
„Alle Nachweise müssen in einem zentralen Auditordner gespeichert werden.“
Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.2.1.
Die Informationssicherheitsleitlinie Informationssicherheitsleitlinie formuliert die umfassendere Auditerwartung ausdrücklich:
„Alle umgesetzten Kontrollen müssen auditierbar sein, durch dokumentierte Verfahren unterstützt werden und durch aufbewahrte Nachweise über ihren Betrieb belegt sein.“
Aus dem Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.6.1.
Diese beiden Klauseln machen den Unterschied zwischen dem Vorhandensein einer Kontrolle und der Fähigkeit aus, sie nachzuweisen.
Cross-Compliance-Zuordnung für einen einheitlichen Kontrollsatz für personenbezogene Daten
Der Schutz personenbezogener Daten lässt sich leichter vertreten, wenn er bereits vor der Prüfung durch den Auditor frameworkübergreifend zugeordnet ist.
| Thema des Schutzes personenbezogener Daten | Relevanz für GDPR | Relevanz für ISO/IEC 27001:2022, ISO/IEC 27701:2025 und ISO/IEC 29151:2022 | Relevanz für NIS2 | Relevanz für DORA | Auditperspektive nach NIST und COBIT 2019 |
|---|---|---|---|---|---|
| Inventar personenbezogener Daten und Verzeichnis der Verarbeitungstätigkeiten | Rechenschaftspflicht, Rechtsgrundlage, Zweckbindung, Speicherbegrenzung | ISMS-Kontext, 5.9 Asset-Inventar, Datenschutz-Informationsmanagement, Schutz personenbezogener Daten | Asset-Management und Risikoanalyse | Bewusstsein für Abhängigkeiten von IKT-Assets und Services | Nachweise der Identify-Funktion und Governance über Informations-Assets |
| Zugriffsrechte und Prinzip der minimalen Berechtigung | Integrität und Vertraulichkeit, rollenbegrenzter Zugriff | 5.15 Zugriffskontrolle, 5.16 Identitätsmanagement, 5.18 Zugriffsrechte, 8.2 privilegierte Zugriffsrechte | Zugriffskontrolle, Personalsicherheit, Authentifizierung | IKT-Risikokontrollen und Aufsicht über privilegierten Zugriff | Durchsetzung von Zugriffen, Verantwortlichkeit, Zuständigkeit und Überwachung |
| Maskierung und Pseudonymisierung | Datenminimierung, Datenschutz durch Technikgestaltung, Sicherheit der Verarbeitung | 5.12 Klassifizierung, 5.34 Schutz personenbezogener Daten, 8.11 Datenmaskierung, 8.33 Testinformationen | Cyberhygiene und sichere Entwicklung | Sichere Tests, Reduzierung von Datenabfluss, operative Resilienz | Prüfung technischer Sicherheitsmaßnahmen und verlässlicher Kontrollbetrieb |
| Vorfallklassifizierung und Berichterstattung | Bewertung und Meldung einer Verletzung des Schutzes personenbezogener Daten | Vorfallsplanung, Ereignisbewertung, Reaktion, Beweissicherung | Frühwarnung innerhalb von 24 Stunden, Meldung innerhalb von 72 Stunden, Abschlussbericht | Klassifizierung und Meldung schwerwiegender IKT-bezogener Vorfälle | Eskalationskriterien, Entscheidungsprotokolle, Ursachenanalyse, Abhilfe |
| Lieferanten- und Cloud-Verarbeitung | Auftragsverarbeiterpflichten, Übermittlungen, Verträge | 5.21 IKT-Lieferkette, 5.23 Cloud-Services, 5.31 rechtliche und vertragliche Anforderungen | Sicherheit der Lieferkette | IKT-Drittparteienrisiko, Auditrechte, Exit und Transition | Drittparteien-Governance, Kontrollsicherheit und Rechenschaftspflicht des Managements |
Genau hier ist Zenith Controls besonders nützlich. Für 5.34 ordnet es den Schutz personenbezogener Daten dem Asset-Inventar, der Datenmaskierung und der Cloud-Governance zu. Für 8.11 ordnet es Maskierung der Klassifizierung, dem Datenschutz und Testinformationen zu. Für 5.18 ordnet es Zugriffsrechte der Zugriffskontrolle, dem Identitätsmanagement und dem privilegierten Zugriff zu. Diese Beziehungen ermöglichen es einem Team, nicht nur zu erklären, dass eine Kontrolle existiert, sondern auch, warum sie existiert und welche benachbarten Kontrollen gemeinsam mit ihr funktionieren müssen.
Wie unterschiedliche Auditoren dieselbe Kontrolle für personenbezogene Daten prüfen
Eine einzelne Kontrolle, etwa 8.11 Datenmaskierung, wird je nach Auditperspektive unterschiedlich geprüft.
| Auditorentyp | Primärer Fokus | Erwartete Nachweise |
|---|---|---|
| Auditor nach ISO/IEC 27001:2022 und ISO/IEC 27701:2025 | Integration von ISMS und PIMS, Risikobehandlung, Genauigkeit der SoA | Risikobeurteilung, SoA-Eintrag, Maskierungsrichtlinie, Änderungsaufzeichnungen, Ergebnisse interner Audits |
| GDPR- oder Datenschutzaufsichtsprüfer | Datenschutz durch Technikgestaltung, Minimierung, Rechenschaftspflicht | Verzeichnis der Verarbeitungstätigkeiten, Rechtsgrundlage, DSFA, Nachweise zur Pseudonymisierung, Aufbewahrungslogik |
| NIS2-Prüfer | Sichere Entwicklung, Vorfallsprävention, Governance | Verfahren für sichere Entwicklung, Entwicklerschulung, Nachweise zur Vorfallsbehebung, Überprüfung der Kontrollwirksamkeit |
| DORA-Kunde oder -Auditor | Operative IKT-Resilienz und Drittparteienrisiko | Nachweise zu Tests kritischer Anwendungen, Lieferantenvertragsklauseln, Verpflichtungen zur Vorfallsunterstützung, Wiederherstellungs- und Exit-Planung |
| NIST-orientierter oder COBIT 2019-Prüfer | Kontrolldesign, Betrieb, Verantwortlichkeit, Überwachung | Kontrollverantwortlicher, Kennzahlen, Nachweisablage, Managementberichte, Korrekturmaßnahmen |
Ein Auditor nach ISO/IEC 27001:2022 beginnt mit der Logik des Managementsystems. Liegen personenbezogene Daten im Geltungsbereich? Sind Anforderungen interessierter Parteien identifiziert? Werden Datenschutzrisiken anhand definierter Kriterien bewertet? Werden Kontrollen durch Risikobehandlung ausgewählt? Ist die SoA korrekt? Decken interne Audits und Managementbewertungen Kontrollen für personenbezogene Daten ab?
Ein Datenschutzprüfer beginnt mit der Rechenschaftspflicht. Welche personenbezogenen Daten werden verarbeitet? Welche Rechtsgrundlage gilt? Werden betroffene Personen informiert? Ist die Verarbeitung auf einen bestimmten Zweck begrenzt? Werden risikobehaftete Tätigkeiten bewertet? Werden Auftragsverarbeiter gesteuert?
Ein NIS2-orientierter Prüfer beginnt mit Governance und Cybersicherheitsrisikomanagement. Genehmigt und überwacht das Management die Maßnahmen? Sind Verfahren zum Umgang mit Informationssicherheitsvorfällen, Kontinuität, Lieferantensicherheit, Zugriffskontrolle, Asset-Management, sichere Entwicklung und Bewertung der Kontrollwirksamkeit integriert?
Ein DORA-Kunde oder -Auditor fragt, ob das IKT-Risikomanagement dokumentiert, vom Leitungsorgan gesteuert, verhältnismäßig und vertraglich abgesichert ist. Wenn personenbezogene Daten in Services verarbeitet werden, die Finanzunternehmen unterstützen, sind Fragen zu Vorfallsunterstützung, Verarbeitungsstandorten, Wiederherstellung, Auditrechten, Service Levels, Beendigung und Exit zu erwarten.
Ein COBIT 2019- oder ISACA-orientierter Prüfer testet die Governance-Ausrichtung. Wer ist für das Risiko im Zusammenhang mit personenbezogenen Daten verantwortlich? Welches Governance-Gremium erhält Berichte? Sind Verantwortlichkeiten zugewiesen? Werden Lieferanten überwacht? Werden Abweichungen nachverfolgt? Werden Kennzahlen für Entscheidungen genutzt? Wird Restrisiko formell akzeptiert?
Ein einziges Nachweismodell kann all diese Perspektiven bedienen, aber nur, wenn das Kontrollsystem von Beginn an auf Nachvollziehbarkeit ausgelegt ist.
Häufige Audit-Feststellungen in Programmen zum Schutz personenbezogener Daten
Organisationen, die die Vorbereitung auf ISO/IEC 27701:2025 oder ISO/IEC 29151:2022 ohne integriertes Werkzeugset angehen, sehen häufig dieselben Feststellungen.
| Feststellung | Warum dies relevant ist | Clarysec-Abhilfe |
|---|---|---|
| Inventar personenbezogener Daten schließt Protokolle, Backups, Analyseexporte oder Support-Anhänge aus | Verborgene personenbezogene Daten können nicht zuverlässig geschützt oder gelöscht werden | Asset-Inventar aus Schritt 9 und Verzeichnis der Verarbeitungstätigkeiten auf alle Speicherorte personenbezogener Daten erweitern |
| Testumgebungen verwenden Produktionsdaten | Echte personenbezogene Daten werden offengelegt, obwohl sie nicht erforderlich sind | Maskierungsrichtlinie und genehmigte Transformationsvorlagen durchsetzen |
| Berechtigungsüberprüfungen sind generisch und fokussieren nicht auf Repositories mit personenbezogenen Daten | Übermäßiger Zugriff bleibt unentdeckt | 5.18 Zugriffsrechte Asset-Verantwortlichen für personenbezogene Daten und periodischen Überprüfungsnachweisen zuordnen |
| Rechtsgrundlage ist dokumentiert, aber nicht mit Systemen oder Aufbewahrung verknüpft | Rechenschaftspflicht nach GDPR kann nicht nachgewiesen werden | Felder für Rechtsgrundlage und Aufbewahrung in Verzeichnis der Verarbeitungstätigkeiten und Asset-Inventar ergänzen |
| Lieferantenverträge enthalten keine Datenstandorte, Vorfallsunterstützung, Auditrechte oder Exit-Regelungen | Lücken in der Lieferantenkontrollsicherheit für DORA, NIS2 und GDPR bleiben bestehen | Lieferanten-Due-Diligence und Verträge an IKT-Drittparteien- und Cloud-Governance ausrichten |
| Vorfalls-Playbooks unterscheiden nicht zwischen Sicherheitsvorfällen und Verletzungen des Schutzes personenbezogener Daten | Meldefristen können versäumt werden | Klassifikationsbäume für Meldeauslöser nach GDPR, NIS2 und DORA aufbauen |
| Nachweise sind über Tickets, Laufwerke, Screenshots und E-Mails verteilt | Auditfähigkeit scheitert auch dort, wo Kontrollen betrieben werden | Zentrale Auditordner und Standards zur Benennung von Nachweisen verwenden |
Diese Feststellungen sind keine Papierprobleme. Sie sind Probleme des Betriebsmodells. ISO/IEC 27701:2025 und ISO/IEC 29151:2022 werden sie nicht beheben, wenn Datenschutz-Governance, Sicherheitskontrollen und Nachweismanagement nicht in normale Arbeitsabläufe eingebettet sind.
Was das Management vor dem nächsten Audit fragen sollte
Bevor eine Organisation die Vorbereitung auf ISO/IEC 27701:2025, die Umsetzung von ISO/IEC 29151:2022 oder eine Kundenbewertung nach GDPR, NIS2 oder DORA angeht, sollte das Management zehn direkte Fragen stellen:
- Haben wir ein vollständiges Verzeichnis der Verarbeitungstätigkeiten mit personenbezogenen Daten, einschließlich Datenkategorien, Zweck, Rechtsgrundlage und Aufbewahrung?
- Sind Assets mit personenbezogenen Daten im Asset-Inventar gekennzeichnet, einschließlich Protokollen, Backups, Exporten, Analysewerkzeugen und Support-Anhängen?
- Werden Datenklassifizierungen bei Erstellung oder Onboarding zugewiesen, wobei nicht geprüfte Assets standardmäßig als Vertraulich eingestuft werden?
- Können wir nachweisen, dass der Zugriff auf personenbezogene Daten auf autorisierte Benutzer mit Need-to-know beschränkt ist?
- Verwenden Entwicklungs-, Test- und Staging-Umgebungen maskierte oder pseudonymisierte Daten anstelle echter personenbezogener Daten?
- Sind Maskierungsvorlagen genehmigt sowie Schlüssel geschützt, zugriffskontrolliert und protokolliert?
- Verknüpft die SoA Risiken im Zusammenhang mit personenbezogenen Daten mit Kontrollen und regulatorischen Verpflichtungen?
- Werden Cloud- und Lieferantenverträge auf Datenstandort, Sicherheit, Vorfallsunterstützung, Auditrechte, Wiederherstellung und Exit geprüft?
- Kann unser Vorfallsprozess Verletzungen des Schutzes personenbezogener Daten nach GDPR, erhebliche Vorfälle nach NIS2 und schwerwiegende IKT-bezogene Vorfälle nach DORA klassifizieren?
- Werden Nachweise zentral gespeichert und so aufbewahrt, dass ein Auditor ihnen folgen kann?
Wenn die Antwort auf eine dieser Fragen unklar ist, ist die Organisation noch nicht auditfähig.
Schutz personenbezogener Daten nachweisbar machen
Sarahs nächtlicher Vorfall hätte zu einem fragmentierten Compliance-Notfall werden können. Stattdessen kann er zum Ausgangspunkt für ein stärkeres Betriebsmodell werden: ein ISMS nach ISO/IEC 27001:2022, das über ISO/IEC 27701:2025 um Datenschutz erweitert, durch Praktiken nach ISO/IEC 29151:2022 gestärkt und auf GDPR, NIS2, DORA, an NIST ausgerichtete Kontrollsicherheit und Governance-Erwartungen nach COBIT 2019 abgebildet wird.
Das ist der eigentliche Wert eines auditfähigen Schutzes personenbezogener Daten. Er hängt nicht davon ab, vor Eintreffen des Auditors die richtige Tabelle zu finden. Er hängt von einem System ab, das bereits weiß, wo personenbezogene Daten liegen, warum sie existieren, wie sie geschützt werden, wer rechenschaftspflichtig ist, welche Lieferanten beteiligt sind und wo die Nachweise abgelegt sind.
Beginnen Sie mit Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, um Ihre Umsetzung zu strukturieren. Nutzen Sie Zenith Controls: The Cross-Compliance Guide Zenith Controls, um den Schutz personenbezogener Daten über ISO/IEC 27001:2022, GDPR, NIS2, DORA, an NIST ausgerichtete Kontrollsicherheit und Governance-Erwartungen nach COBIT 2019 hinweg abzubilden. Operationalisieren Sie die Arbeit mit Clarysec-Richtlinien, darunter die Richtlinie zu Datenschutz und Privatsphäre Richtlinie zu Datenschutz und Privatsphäre, die Richtlinie zur Datenmaskierung und Pseudonymisierung Richtlinie zur Datenmaskierung und Pseudonymisierung, die Richtlinie zur Datenklassifizierung und Kennzeichnung Richtlinie zur Datenklassifizierung und Kennzeichnung, die KMU-Richtlinie zur Audit- und Compliance-Überwachung Audit and Compliance Monitoring Policy - SME und die Informationssicherheitsleitlinie Informationssicherheitsleitlinie.
Wenn Ihr nächstes Kundenaudit, eine GDPR-Überprüfung, ein NIS2-Readiness-Projekt oder eine DORA-Lieferantenbewertung bevorsteht, warten Sie nicht auf eine Datenschutzverletzung, die die Lücken offenlegt. Laden Sie die Clarysec-Toolkits herunter, fordern Sie eine Demo an oder planen Sie eine Bewertung zum Schutz personenbezogener Daten und bauen Sie ein Datenschutzprogramm auf, das nicht nur konform, sondern belastbar ist.
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
