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

Die Frage des externen Auditors stand im Raum – scheinbar einfach.

„Können Sie mir das Protokoll der Berechtigungsüberprüfung für den Zugriff Ihres Support-Teams auf Produktions-PII im letzten Quartal zeigen?“

Für Anya, CISO bei Medtelligence, einem schnell wachsenden Health-Tech-SaaS-Anbieter, war dies der entscheidende Moment. Medtelligence handelt als PII-Auftragsverarbeiter für Krankenhäuser und verarbeitet sensitive Patientendaten auf einer Cloud-Plattform. Das Unternehmen verfügte über starke Authentifizierung, definierte Rollen und ein erfahrenes Engineering-Team. Der Auditor fragte jedoch nicht, ob es eine Anmeldeseite gab. Er verlangte den Nachweis, dass der Zugriff auf personenbezogene Daten über die Zeit gesteuert wurde.

Er wollte sehen, wer auf Produktions-PII zugreifen konnte, warum diese Personen Zugriff hatten, wann der Zugriff genehmigt worden war, ob er weiterhin erforderlich war, ob Support-Aktivitäten protokolliert wurden und ob nicht mehr benötigte Berechtigungen entfernt worden waren.

Anya öffnete die IAM-Konsole. Dort fanden sich Support-Ingenieure, Datenbankadministratoren, ein Integrations-Servicekonto, ein Managed Service Provider, zwei Notfallrollen für Break-Glass-Zugriffe sowie ein ehemaliger Auftragnehmer, der weiterhin einer Gruppe angehörte, weil das Offboarding-Ticket geschlossen worden war, bevor die Berechtigung entfernt wurde. HR zeigte, dass die Person das Unternehmen sechs Wochen zuvor verlassen hatte. In der Tabelle zur Berechtigungsüberprüfung stand „ausstehend“. Das SIEM enthielt Protokolle, aber niemand hatte zugeordnet, welche Ereignisse den Zugriff auf PII belegten.

An diesem Punkt wird Datenschutz-Governance konkret.

Nach GDPR müssen personenbezogene Daten mit Integrität und Vertraulichkeit verarbeitet und durch geeignete technische und organisatorische Maßnahmen vor unbefugter oder unrechtmäßiger Verarbeitung sowie vor unbeabsichtigtem Verlust, unbeabsichtigter Zerstörung oder unbeabsichtigter Schädigung geschützt werden. GDPR macht außerdem die Rechenschaftspflicht ausdrücklich: Der Verantwortliche muss die Einhaltung nachweisen können. ISO/IEC 27701:2025 überführt diese Rechenschaftspflicht in ein Privacy Information Management System (PIMS), in dem der Zugriff auf PII kein technischer Nachgedanke mehr ist. Er wird zu einem gesteuerten Lebenszyklus über Rollen, Auftragsverarbeiter, Cloud-Plattformen, Beschäftigte, privilegierte Administratoren, Protokolle, Überprüfungen, Verträge und Nachweise hinweg.

Die Lücke vieler Organisationen besteht nicht darin, dass ihnen Zugriffskontrolle fehlt. Die Lücke besteht darin, dass sie Governance des PII-Zugriffs nicht konsistent über ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 und COBIT 2019 hinweg nachweisen können.

Governance des PII-Zugriffs ist mehr als IAM

Ein klassisches IAM-Programm fragt: „Können die richtigen Benutzer auf die richtigen Systeme zugreifen?“

Ein ausgereiftes ISO/IEC 27701:2025-PIMS stellt anspruchsvollere Fragen:

• Welche Systeme verarbeiten PII?
• Welche Rollen benötigen Zugriff auf welche Kategorien von PII?
• Handelt die Organisation als PII-Verantwortlicher, PII-Auftragsverarbeiter, gemeinsam Verantwortlicher oder Unterauftragsverarbeiter?
• Ist der Zugriff durch Zweck, dokumentierten geschäftlichen Bedarf und das Prinzip der minimalen Berechtigung begrenzt?
• Werden privilegierte Handlungen protokolliert und überprüft?
• Kann die Organisation nachweisen, dass der Zugriff von Auftragsverarbeitern und Unterauftragsverarbeitern vertraglich gesteuert ist?
• Sind Cloud-Support-Pfade, Mandantentrennung, Exporte und administrative Handlungen in den Nachweisen enthalten?
• Werden Zugriffsentscheidungen nach Onboarding, Rollenänderung, Vorfall, Offboarding und wesentlichen Systemänderungen überprüft?

Deshalb bildet Governance für PII-Sicherheit und Zugriffskontrolle eine natürliche Brücke zwischen ISO/IEC 27701:2025 und GDPR. GDPR liefert den rechtlichen Rahmen der Rechenschaftspflicht. ISO/IEC 27701:2025 operationalisiert Datenschutzmanagement für Verantwortliche und Auftragsverarbeiter. ISO/IEC 27001:2022 stellt die Risikomanagement-Engine des ISMS bereit. ISO/IEC 27002:2022 liefert die Kontrollarchitektur, einschließlich Datenschutz und Schutz von PII, Zugriffskontrolle, Zugriffsrechten, Protokollierung, Cloud-Services, Lieferantenbeziehungen, Klassifizierung, Löschung, Maskierung und Kryptografie.

Clarysecs Zenith Blueprint: 30-Schritte-Roadmap für Auditoren ordnet dies der Phase „Controls in Action“ zu. In Schritt 23, der die organisatorischen Maßnahmen 5.19 bis 5.37 abdeckt, beschreibt er ISO/IEC 27002:2022-Maßnahme 5.34, Datenschutz und Schutz von PII, als Vertrauensfrage und nicht nur als Datenfrage:

Personenbezogene Daten sind nicht einfach ein weiterer Datentyp, sondern eine hochgradig sensitive Repräsentation von Vertrauen. Namen, Adressen, Kennungen, Gesundheitsdaten, Finanzdetails – diese Daten erzählen eine Geschichte über reale Menschen.

Derselbe Abschnitt nennt die praktische Grundlage: Datenschutz beginnt mit Datenbewusstsein. Eine Organisation muss wissen, welche PII sie erhebt, wo sie gespeichert ist, warum sie verarbeitet wird und wer darauf zugreifen kann.

Der Compliance-Druck hinter der PII-Zugriffskontrolle

Governance des PII-Zugriffs ist längst kein Thema eines einzelnen Rahmenwerks mehr. Organisationen wie Medtelligence bewegen sich an der Schnittstelle von Datenschutzregulierung, Cybersicherheitsrecht, operationaler Resilienz, Vertrauensbildung bei Kunden und Sicherheitszertifizierung.

GDPR Article 5 verlangt, dass personenbezogene Daten nach Rechtmäßigkeit, Fairness, Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität und Vertraulichkeit verarbeitet werden. Article 5(2) führt die Rechenschaftspflicht ein: Der Verantwortliche ist für die Einhaltung verantwortlich und muss sie nachweisen können. Article 32 verlangt anschließend geeignete technische und organisatorische Maßnahmen für die Sicherheit der Verarbeitung.

NIS2 Article 21 verpflichtet wesentliche und wichtige Einrichtungen, geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen zum Management von Cybersicherheitsrisiken zu ergreifen. Zu den Mindestbereichen gehören Risikoanalyse, Sicherheitsrichtlinien, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Beschaffung und Entwicklung, Wirksamkeitsbewertung, Cyberhygiene und Schulung, Kryptografie, HR-Sicherheit, Zugriffskontrolle, Asset-Management sowie, sofern angemessen, Multi-Faktor-Authentifizierung oder kontinuierliche Authentifizierung und sichere Kommunikation. Article 20 weist außerdem den Leitungsorganen die Verantwortung zu, Maßnahmen zum Management von Cybersicherheitsrisiken zu genehmigen und zu überwachen.

DORA gilt ab dem 17. Januar 2025 für eine breite Gruppe von Finanzunternehmen und schafft ein branchenspezifisches Regime für operationale Resilienz. Es umfasst das Management von IKT-Risiken, die Meldung schwerwiegender IKT-bezogener Vorfälle, das Testen der digitalen operationalen Resilienz, Informationsaustausch, IKT-Drittparteienrisiko und vertragliche Regelungen mit IKT-Drittdienstleistern. Für Finanzunternehmen und IKT-Dienstleister, die sie unterstützen, ist Zugriffskontrolle nicht nur ein Datenschutzthema. Sie ist Teil der operationalen Resilienz.

ISO/IEC 27001:2022 bindet diese Verpflichtungen in ein risikobasiertes Managementsystem ein. Die Klauseln 6.1.1 bis 6.1.3 verlangen von Organisationen, Risiken und Chancen zu adressieren, einen Prozess zur Informationssicherheitsrisikobeurteilung festzulegen, Risiken für Vertraulichkeit, Integrität und Verfügbarkeit zu identifizieren, Risiken zu bewerten, Behandlungsoptionen auszuwählen, Maßnahmen festzulegen, die ausgewählten Maßnahmen mit Anhang A abzugleichen, die Erklärung zur Anwendbarkeit zu dokumentieren, die Genehmigung der Risikoverantwortlichen einzuholen und Restrisiken zu akzeptieren. Die Klauseln 8.2 und 8.3 verlangen Risikobeurteilungen in geplanten Abständen oder nach wesentlichen Änderungen sowie die Umsetzung des Risikobehandlungsplans mit dokumentierten Ergebnissen.

Für PII-Governance bedeutet dies: Zugriffskontrolle ist keine isolierte IAM-Einstellung. Sie ist eine Risikobehandlungsentscheidung. Eine Rolle, die Gehaltsabrechnungen, Patientendaten, Zahlungsdetails, Identitätsdokumente, Standortdaten oder Kunden-Support-Transkripte exportieren kann, muss im Risikoregister begründet, in der Erklärung zur Anwendbarkeit abgebildet, in IAM durchgesetzt, in der Produktion protokolliert, regelmäßig überprüft und entfernt werden, sobald sie nicht mehr erforderlich ist.

Das Clarysec-Kontrollmodell: vom Datenschutzversprechen zum Nachweis

Clarysec behandelt Governance des PII-Zugriffs als Nachweiskette. Die Kette beginnt mit Dateninventar und Rollendefinition, führt über Zugriffsgenehmigung und Durchsetzung und endet mit Überwachung, Überprüfung, Entzug von Zugriffsrechten und auditbereiten Aufzeichnungen.

In Zenith Controls: Leitfaden für rahmenwerksübergreifende Compliance liegt das Thema vor allem bei drei ISO/IEC 27002:2022-Maßnahmen:

Auditoren akzeptieren „wir nutzen IAM“ selten als Nachweis. Sie erwarten, dass IAM-Entscheidungen auf Datenschutzverpflichtungen, Systemverantwortung, Datenklassifizierung, geschäftlichen Bedarf, Risikobehandlung, Frequenz der Berechtigungsüberprüfung, Protokollierungsumfang und Lieferantenverträge zurückgeführt werden können.

Clarysecs Richtlinie zur PII-Sicherheit und Zugriffskontrolle legt die Baseline in PIMS-Sprache fest:

[Both] Der Systemverantwortliche / Anwendungsverantwortliche MUSS den Zugriff auf PII auf genehmigte Rollen und autorisierte Benutzer beschränken, die in REG02 oder REG12 erfasst oder nachvollziehbar sind, bevor der Zugriff aktiviert wird.

Aus Abschnitt „4.2 Baseline für Zugriffskontrolle“, Richtlinienklausel 4.2.1.

Das Tag „[Both]“ bedeutet, dass die Maßnahme gilt, unabhängig davon, ob die Organisation als PII-Verantwortlicher oder als PII-Auftragsverarbeiter handelt. Diese Unterscheidung ist wesentlich. Verantwortliche versäumen häufig, zweckbezogene Zugriffsregeln zu definieren. Auftragsverarbeiter versäumen häufig nachzuweisen, dass der Zugriff auf Kundenweisungen, genehmigte Support-Pfade und vertraglich autorisiertes Personal begrenzt ist.

Dieselbe Richtlinie setzt für sensitive PII oder PII mit hoher Tragweite eine höhere Messlatte:

[Both] Der Systemverantwortliche / Anwendungsverantwortliche MUSS den Benutzerzugriff auf Systeme, die PII mit hoher Tragweite oder sensitive PII verarbeiten, mindestens vierteljährlich überprüfen und das Ergebnis der Überprüfung in REG12 erfassen.

Aus Abschnitt „4.2 Baseline für Zugriffskontrolle“, Richtlinienklausel 4.2.3.

An dieser Stelle wird ein PIMS auditierbar. Die Berechtigungsüberprüfung ist nicht nur eine E-Mail eines Managers. Sie ist ein Datensatz in REG12, verknüpft mit System, Datenkategorie, Rolle, Verantwortlichem, Überprüfungsergebnis und Abhilfemaßnahme.

Richtliniengrundlage: Prinzip der minimalen Berechtigung, geschäftlicher Bedarf und Default-Deny-Prinzip

Wirksame Governance beginnt mit durchsetzbaren Regeln. Bevor Anya dem Auditor ein Protokoll der Berechtigungsüberprüfung zeigen konnte, musste sie nachweisen, dass die Anforderung an Berechtigungsüberprüfungen formell festgelegt war.

Clarysecs SME-Richtlinie zur Zugriffskontrolle legt den Grundsatz fest:

Diese Richtlinie setzt das Prinzip der minimalen Berechtigung durch und verlangt, dass der Zugriff auf das zur Ausführung der beruflichen Aufgaben erforderliche Mindestmaß beschränkt wird.

Aus Abschnitt „Zweck“, Richtlinienklausel 1.3.

Die SME-Richtlinie zu Datenschutz und Privatsphäre verknüpft Zugriff mit geschäftlichem Bedarf:

Benutzerzugriff auf personenbezogene Daten muss auf Rollen mit dokumentiertem geschäftlichem Bedarf beschränkt werden.

Aus Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.2.

Für größere Organisationen formuliert die Enterprise-Richtlinie zu Datenschutz und Privatsphäre die Kontrollerwartung als Systemanforderung:

Alle Systeme müssen standardmäßig Zugriff nach dem Prinzip der minimalen Berechtigung durchsetzen.

Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.3.1.

Die Unterscheidung ist wichtig. Ein kleineres Unternehmen benötigt möglicherweise einen schlanken, aber expliziten Nachweis des geschäftlichen Bedarfs. Ein Unternehmen auf Enterprise-Niveau benötigt Durchsetzung auf Systemebene, regelmäßige Überprüfung, Funktionstrennung, Governance für privilegierten Zugriff und Nachweise, die für Interne Revision, Vertrauensbildung bei Kunden, Anfragen von Aufsichtsbehörden und Untersuchungen von Datenschutzverletzungen aufbewahrt werden.

Der PII-Zugriffslebenszyklus: Genehmigung, Nutzung, Überprüfung, Entzug

Der häufigste Fehler bei PII-Zugriffen ist nicht die Erstgenehmigung. Es ist das Fortbestehen von Zugriffen.

Der Zenith Blueprint erläutert in der Phase „Controls in Action“, Schritt 22, ISO/IEC 27002:2022-Maßnahme 5.18, Zugriffsrechte, wie folgt:

Maßnahme 5.18 stellt sicher, dass Zugriffsrechte nicht nur angemessen gewährt, sondern auch kontrolliert und nachvollziehbar überprüft, angepasst und entzogen werden.

Anschließend beschreibt er vertraute Szenarien: Ein neuer Mitarbeiter erhält Zugriff, wechselt die Rolle und behält alte Berechtigungen; ein ehemaliger Administrator verlässt das Unternehmen, aber ein Token bleibt aktiv; ein Auftragnehmerkonto läuft auf dem Papier ab, aber nicht in IAM. Genau diese Schwächen werden zu GDPR-Sicherheitsvorfällen, wenn PII betroffen ist.

Clarysecs SME-Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen legt eine Basisfrequenz fest:

Eine Überprüfung aller Benutzerkonten und Berechtigungen muss alle sechs Monate durchgeführt werden.

Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.4.1.

Für Enterprise-Umgebungen strafft die Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen den Betriebsrhythmus:

Vierteljährliche Überprüfungen aller Benutzerkonten und zugehörigen Berechtigungen müssen durch IT Security in Zusammenarbeit mit den Abteilungsleitern durchgeführt werden.

Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.5.1.

Ein praktikabler PII-Zugriffslebenszyklus sollte Folgendes umfassen:

1. System und PII-Kategorien klassifizieren.
2. Genehmigte Rollen und dokumentierten geschäftlichen Bedarf definieren.
3. Rollen Verarbeitungszwecken zuordnen.
4. Zugriff vor Aktivierung genehmigen.
5. Prinzip der minimalen Berechtigung, Funktionstrennung und starke Authentifizierung durchsetzen.
6. Authentifizierung, Zugriff, Export, Konfiguration und privilegierte Handlungen protokollieren.
7. Zugriffe nach risikobasierter Frequenz überprüfen.
8. Zugriff bei Rollenänderung, Austritt, Projektabschluss, Vertragsablauf oder Kundenweisung entfernen.
9. Nachweise im PIMS-Register und im Prüfpfad aufbewahren.

Das ist keine Bürokratie. So weist eine Organisation nach, dass PII-Zugriff durch Technikgestaltung, durch datenschutzfreundliche Voreinstellungen und durch Nachweise kontrolliert wird.

Ein praktisches Beispiel: die vierteljährliche PII-Berechtigungsüberprüfung

Anyas Audit war erfolgreich, als sie das Gespräch von Richtlinienaussagen auf Nachweise verlagerte.

Zunächst verwies sie auf die Richtlinie zur PII-Sicherheit und Zugriffskontrolle, Klausel 4.2.3, die eine vierteljährliche Überprüfung des Zugriffs auf PII mit hoher Tragweite oder sensitive PII und die Erfassung des Überprüfungsergebnisses in REG12 verlangte.

Dann führte sie den Auditor durch das vorherige Quartal:

• IT erzeugte eine Liste aller Benutzer, Gruppen, privilegierten Rollen, Servicekonten, Lieferantenkonten, Break-Glass-Rollen und Support-Berechtigungen für die Produktionsdatenbank mit Patientendaten.
• Die Liste wurde an den Anwendungsverantwortlichen, den Head of Customer Success, gesendet, der den operativen Bedarf des Support-Teams verantwortete.
• Der Anwendungsverantwortliche prüfte die Liste zeilenweise gegen aktuelle Rolle, Zuständigkeit im Kundensupport und Verarbeitungszweck.
• Zwei Support-Mitarbeitende, die in andere Teams gewechselt waren, wurden für den Entzug von Zugriffsrechten markiert.
• Im IT-Service-Management-System wurde ein Ticket erstellt, mit der Berechtigungsüberprüfung verknüpft, mit einem SLA versehen und nach dem Entzug geschlossen.
• REG12 wurde mit Überprüfungsdatensatz, Genehmigendem, Ausnahmen, Abhilfeticket, Abschlussnachweis und nächstem Überprüfungsdatum aktualisiert.

Das Ergebnis war eine geschlossene Nachweiskette. Anya sagte nicht nur, dass Medtelligence das Prinzip der minimalen Berechtigung nutzte. Sie zeigte die Richtlinienanforderung, den verantwortlichen Eigentümer, die Zugriffsliste, die Überprüfungsentscheidung, die Korrekturmaßnahme und den abgeschlossenen Entzug von Zugriffsrechten.

Das ist der Unterschied zwischen Zugriffskontrolle und Zugriffsgovernance.

Lieferanten- und Auftragsverarbeiterzugriff: der blinde Fleck in PIMS-Audits

Viele Risiken unbefugten Zugriffs entstehen durch Support, Auslagerung, Integrationspartner, Managed Service Provider und Unterauftragsverarbeiter. Ein Auftragsverarbeiter kann Fernzugriff auf Produktionsdaten von Kunden haben. Ein Cloud-Anbieter kann Support-Zugriffspfade bereitstellen. Ein Unterauftragsverarbeiter kann einen Suchindex mit Kundenkennungen betreiben. Ein Managed Security Service Provider kann auf Protokolle zugreifen, die personenbezogene Daten enthalten.

Nach GDPR müssen Verantwortliche Auftragsverarbeiter einsetzen, die hinreichende Garantien bieten. Nach ISO/IEC 27701:2025 muss Governance für Auftragsverarbeiter und Unterauftragsverarbeiter durch dokumentierte Weisungen, Vertragskontrollen, Sicherstellung und Überwachung operationalisiert werden. ISO/IEC 27002:2022 unterstützt dies durch Kontrollen für Lieferantenbeziehungen, einschließlich 5.19 Informationssicherheit in Lieferantenbeziehungen, 5.20 Berücksichtigung der Informationssicherheit in Lieferantenvereinbarungen und 5.21 Management der Informationssicherheit in der IKT-Lieferkette.

Der Zenith Blueprint, Phase „Controls in Action“, Schritt 23, fasst Nachweisbereiche für Lieferantenvereinbarungen zusammen, darunter:

✓ Verantwortlichkeiten für die Zugriffskontrolle, etwa wer auf Ihre Daten zugreifen darf, wie Zugangsdaten verwaltet werden und welche Überwachung eingerichtet ist;

Dazu gehören außerdem Vertraulichkeitspflichten, technische und organisatorische Maßnahmen, Fristen zur Meldung von Vorfällen, Auditrechte, Kontrollen für Unterauftragsverarbeiter und Kontodeaktivierung bei Vertragsende.

Clarysecs Richtlinie zum Datenschutzmanagement für Auftragsverarbeiter, Unterauftragsverarbeiter und Drittparteien überführt dies in PIMS-Nachweise auf Seiten des Verantwortlichen:

[Controller] Der Privacy Lead / PIMS Manager MUSS vor der Genehmigung verifizieren, dass die Vertragskontrollfelder für Auftragsverarbeiter in REG08 Verarbeitungsumfang, Dauer, Zweck, PII-Kategorien, Kategorien betroffener Personen, Vertraulichkeit, Sicherheit, Autorisierung von Unterauftragsverarbeitern, Unterstützung, Audit oder Sicherstellung, Rückgabe, Löschung und Beendigung abdecken.

Aus Abschnitt „4.3 Vertrags- und dokumentierte Weisungskontrollen“, Richtlinienklausel 4.3.2.

Lieferantenzugriff wird außerdem direkt in Clarysecs SME- und Enterprise-Lieferantenrichtlinien kontrolliert. Die SME-Richtlinie zur Lieferanten- und Drittparteiensicherheit legt fest:

Lieferanten dürfen nur Zugriff auf die minimal erforderlichen Systeme und Daten erhalten, die sie zur Erfüllung ihrer Funktion benötigen.

Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.2.1.

Die Enterprise-Richtlinie zur Lieferanten- und Drittparteiensicherheit ergänzt RBAC, Überprüfung und Prinzip der minimalen Berechtigung:

Lieferantenpersonal muss rollenbasierter Zugriffskontrolle (RBAC), regelmäßigen Berechtigungsüberprüfungen und der Durchsetzung des Prinzips der minimalen Berechtigung unterliegen.

Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.3.1.

Wenn Lieferantenzugriff PII erreichen kann, gehört er in das PIMS. Er sollte in Vertragskontrollen, Zugriffsgenehmigungen, IAM-Gruppen, Protokollierungsumfang, Überprüfungsaufzeichnungen, Offboarding-Aufzeichnungen, Incident-Playbooks und Auditnachweisen erscheinen.

Cloud-PII-Zugriff: geteilte Verantwortung ist keine geteilte Rechenschaftspflicht

Governance des Cloud-PII-Zugriffs ist der Bereich, in dem Organisationen die Verantwortung des Anbieters häufig überschätzen und ihre eigenen Pflichten unterschätzen. Der Cloud-Anbieter kann die Infrastruktur absichern, aber der Kunde steuert weiterhin Identitäten, Rollen, Mandantenkonfiguration, Support-Zugriff, Protokolle, Verschlüsselungseinstellungen, Exportberechtigungen und Vorfallsbereitschaft.

Der Zenith Blueprint, Phase „Controls in Action“, Schritt 23, formuliert dies in seiner Cloud-Service-Leitlinie unmissverständlich:

Cloud-Anbieter sichern die Infrastruktur, aber Sie bleiben rechenschaftspflichtig für Ihre Daten, Ihre Konfigurationen, Ihre Zugriffsrichtlinien und Ihre Vorfallsbereitschaft.

Er warnt außerdem:

In der Cloud ist Sichtbarkeit nur teilweise vorhanden, sofern sie nicht bewusst konstruiert wird. Sie müssen Protokollierung konfigurieren, Verschlüsselung durchsetzen, Identitätsrollen definieren und Aktivitäten über native Werkzeuge oder Drittanbieter-Integrationen überwachen. Das ist keine Infrastrukturaufgabe, sondern eine ISMS-Anforderung.

Clarysecs Richtlinie zur Nutzung von Cloud-Diensten überführt dies in eine Enterprise-Zugriffsanforderung:

Alle Cloud-Services müssen identitätsbasierte Zugriffskontrolle durchsetzen, die am Prinzip der minimalen Berechtigung ausgerichtet ist.

Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.2.1.

Für Organisationen, die in Cloud-Umgebungen als Auftragsverarbeiter handeln, definiert Clarysecs Cloud-PII-Auftragsverarbeiterrichtlinie eine spezifischere PIMS-Überprüfungspflicht:

[Processor] Der Leiter Informationssicherheit MUSS privilegierten Cloud-Zugriff, Support-Zugriff, Zugriff auf Kunden-PII und Protokollierungsabdeckung mindestens vierteljährlich in REG12 überprüfen.

Aus Abschnitt „4.2 Cloud-Konfiguration, Mandantentrennung, Zugriff und Protokollierung“, Richtlinienklausel 4.2.4.

Diese Klausel ist besonders relevant für SaaS-Unternehmen, Cloud-basierte Plattformen, verwaltete Datendienste und B2B-Auftragsverarbeiter.

Governance des Cloud-PII-Zugriffs ist nicht vollständig, solange cloud-native Protokolle, IAM-Richtlinien, Servicekonten, privilegierte Rollen, Kundensupport-Werkzeuge, API-Schlüssel und Datenexportfunktionen nicht gemeinsam überprüft werden.

Protokollierung und Überwachung: das Gedächtnis der PII-Governance

Ein PIMS-Zugriffskontrollprogramm ohne Protokolle ist ein Versprechen ohne Gedächtnis.

Die Richtlinie zur PII-Sicherheit und Zugriffskontrolle verlangt die Festlegung des Protokollierungsumfangs vor Produktionsnutzung oder wesentlicher Änderung:

[Both] Der Systemverantwortliche / Anwendungsverantwortliche MUSS vor Produktionsnutzung oder wesentlicher Änderung den PII-Protokollierungsumfang für Authentifizierungsereignisse, Zugriffsereignisse, privilegierte Handlungen, PII-Exportaktivitäten und wesentliche Konfigurationsänderungen in REG12 festlegen.

Aus Abschnitt „4.6 Protokollierung und Überwachung“, Richtlinienklausel 4.6.1.

Die SME-Richtlinie zur Protokollierung und Überwachung macht den Inhalt von Zugriffsprotokollen ausdrücklich:

Zugriffsprotokolle: Dateizugriff (insbesondere bei sensitiven oder personenbezogenen Daten), Berechtigungsänderungen, Nutzung gemeinsam genutzter Ressourcen

Aus Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.4.3.

Die Enterprise-Richtlinie zur Protokollierung und Überwachung konzentriert sich auf Nutzbarkeit für Audits:

Das ISMS-Prüfpfadregister muss die Verfügbarkeit von Protokolldaten für Audits, Untersuchungen und regulatorische Überprüfungen erfassen.

Aus Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.4.

Dies ist kritisch, weil Datenschutznachweise häufig ereignisbasierte Fragen beantworten müssen:

• Wer hat auf die PII zugegriffen?
• War der Zugriff autorisiert?
• War der Zugriff mit einem Support-Ticket, einer rechtlichen Anfrage, einer operativen Aufgabe oder einer Kundenweisung verknüpft?
• Wurden Daten exportiert, kopiert, verändert oder gelöscht?
• Wurde privilegierter Zugriff genutzt?
• Wurden Berechtigungen vor oder nach dem Zugriff geändert?
• Wies die Aktivität auf einen Sicherheitsvorfall oder eine Verletzung des Schutzes personenbezogener Daten hin?

Protokolle sind nicht nur für das SOC relevant. Sie sind PIMS-Nachweise, Nachweise zur Vertrauensbildung bei Kunden, Nachweise zur Sicherstellung bei Auftragsverarbeitern und Incident-Response-Nachweise.

Cross-Compliance-Mapping: ein Zugriffsmodell, viele Perspektiven

Eine Schwäche in PII-Berechtigungsüberprüfungen ist nie nur eine einzelne Feststellung. Sie kann zu einem GDPR-Rechenschaftsproblem, einer ISO/IEC 27701:2025-PIMS-Schwäche, einer ISO/IEC 27001:2022-Nichtkonformität, einem NIS2-Governance-Versagen, einem DORA-Resilienzproblem, einer Governance-Lücke nach NIST CSF 2.0 oder einem Prozessreifeproblem nach COBIT 2019 werden.

Eine detailliertere Kontrollzuordnung zeigt, wie ein einzelner Prozess zur Governance des PII-Zugriffs mehrere Anforderungen unterstützt:

Der Wert von Zenith Controls liegt darin, dass Teams diese Perspektiven auf dieselben Kontrollnachweise zurückführen können, statt getrennte Compliance-Silos zu pflegen.

Führen Sie einen 45-minütigen PII-Zugriffsnachweis-Sprint durch

Eine hilfreiche Methode zur Prüfung der Bereitschaft besteht darin, ein System mit hoher Tragweite auszuwählen – etwa eine Kundensupport-Plattform, ein HR-System, ein Zahlungsportal, ein Patientenportal, einen Data Lake oder eine SaaS-Produktionsdatenbank – und einen fokussierten Nachweis-Sprint durchzuführen.

Schritt 1: PII-Verarbeitungskontext definieren

In REG12 erfassen:

• Systemname und Verantwortlicher
• PII-Kategorien
• Kategorien betroffener Personen
• Rolle als Verantwortlicher oder Auftragsverarbeiter
• Verarbeitungszweck
• Indikator für PII mit hoher Tragweite oder sensitive PII
• Cloud-, Lieferanten- und Unterauftragsverarbeiterabhängigkeiten

Wenn das System einen Auftragsverarbeiter einbezieht, verifizieren Sie die REG08-Vertragskontrollfelder anhand der Richtlinie zum Datenschutzmanagement für Auftragsverarbeiter, Unterauftragsverarbeiter und Drittparteien. Die Genehmigung sollte Verarbeitungsumfang, Dauer, Zweck, PII-Kategorien, Kategorien betroffener Personen, Vertraulichkeit, Sicherheit, Autorisierung von Unterauftragsverarbeitern, Unterstützung, Audit oder Sicherstellung, Rückgabe, Löschung und Beendigung abdecken.

Schritt 2: Zugriffsliste abrufen

Exportieren Sie alle Benutzer, Gruppen, privilegierten Rollen, Servicekonten, Support-Rollen, Break-Glass-Konten, API-Schlüssel und Lieferantenkonten. Vergleichen Sie jede Berechtigung mit den genehmigten Rollen.

Schritt 3: Prinzip der minimalen Berechtigung und Zweckausrichtung bestätigen

Nutzen Sie die Baseline der Richtlinie zur PII-Sicherheit und Zugriffskontrolle: Zugriff muss auf genehmigte Rollen und autorisierte Benutzer beschränkt sein, die vor Aktivierung in REG02 oder REG12 erfasst oder nachvollziehbar sind. Wenn ein Benutzer nicht auf Rolle, Zweck und Genehmigung zurückgeführt werden kann, lautet die Feststellung nicht „Dokumentation fehlt“. Die Feststellung lautet: „PII-Zugriff ist nicht nachweisbar autorisiert.“

Schritt 4: Protokollierungsumfang verifizieren

Bestätigen Sie, dass Protokolle Authentifizierung, Zugriffsereignisse, privilegierte Handlungen, PII-Exportaktivitäten und wesentliche Konfigurationsänderungen erfassen. Bestätigen Sie anschließend, wo Protokolle gespeichert werden, wie lange sie aufbewahrt werden, wer darauf zugreifen kann und ob sie im ISMS-Prüfpfadregister für Audits, Untersuchungen und regulatorische Überprüfungen erfasst sind.

Schritt 5: Regelkreis schließen

Erfassen Sie für jede Ausnahme den Risikoverantwortlichen, die unmittelbare Eindämmungsmaßnahme, die dauerhafte Abhilfemaßnahme, das Zieldatum, den erforderlichen Nachweis, die Restrisikoentscheidung und ob eine Bewertung der Datenschutzverletzung erforderlich ist.

Diese eine Übung zeigt in der Regel den tatsächlichen Reifegrad der Governance des PII-Zugriffs. Starke Organisationen können schnell antworten. Schwache Organisationen stellen fest, dass Datenschutzrichtlinie, IAM-Konfiguration, Auftragsverarbeiterverträge, Cloud-Protokollierung und Auditnachweise nicht miteinander verbunden sind.

Häufige Audit-Feststellungen in der Governance des PII-Zugriffs

Die meisten Feststellungen sind vorhersehbar. Sie entstehen, wenn Datenschutz, Sicherheit, Recht, IT und Lieferanten jeweils einen Teil der Geschichte kontrollieren, aber niemand den vollständigen PII-Zugriffslebenszyklus verantwortet.

Häufige Feststellungen sind:

• PII-Systeme sind im PIMS-Inventar nicht vollständig aufgeführt.
• Zugriffsrollen sind technisch definiert, aber nicht Verarbeitungszwecken zugeordnet.
• Sensitive PII ist über breite Betriebsgruppen zugänglich.
• Vierteljährliche Überprüfungen erfassen Beschäftigte, aber keine Servicekonten, API-Schlüssel oder Lieferantenbenutzer.
• Cloud-Support-Zugriff ist möglich, wird aber nicht als PII-Zugriff überprüft.
• Protokolle existieren, belegen aber keinen PII-Zugriff, Export und keine privilegierte Aktivität.
• Auftragsverarbeiterverträge enthalten allgemeine Vertraulichkeitsklauseln, aber keine spezifischen Kontrollen zu Zugriffskontrolle, Audit, Unterauftragsverarbeitern, Rückgabe, Löschung oder Beendigung.
• Ehemalige Beschäftigte oder Auftragnehmer behalten Zugriff über gemeinsame Gruppen oder nicht verwaltete Token.
• Data-Warehouse-Zugriff ist breiter als der Zugriff auf die Quellanwendung.
• Break-Glass-Konten bestehen ohne Überprüfung nach Nutzung.
• Kunden-Support-Impersonation wird nicht mit Ticket-Kontext protokolliert.
• Die Erklärung zur Anwendbarkeit enthält Zugriffskontrollen, aber die Nachweise zeigen keine PII-spezifische Umsetzung.

Jede dieser Feststellungen kann je nach Geltungsbereich zu einem GDPR-Rechenschaftsproblem, einem Problem für die Vertrauensbildung bei Kunden, einer NIS2- oder DORA-Governance-Schwäche oder einer ISO/IEC 27001:2022-Nichtkonformität werden.

Wie ein gutes Zielbild aussieht

Ein ausgereiftes Betriebsmodell verlässt sich nicht auf heroische vierteljährliche Bereinigungen. Es verankert Governance des PII-Zugriffs im Regelbetrieb.

Erstens verfügt die Organisation über Datenbewusstsein. Sie weiß, wo PII existiert, warum sie verarbeitet wird, welche PIMS-Rolle gilt und welche Systeme, Lieferanten, Cloud-Services, Protokolle, Backups und Exporte im Geltungsbereich liegen.

Zweitens ist der Zugriff rollenbasiert und zweckgebunden. Berechtigungen werden durch genehmigte Rollen, dokumentierten geschäftlichen Bedarf, Verarbeitungszweck und das Prinzip der minimalen Berechtigung definiert.

Drittens werden Kontrollen technisch durchgesetzt. IAM, RBAC, Privileged Access Management (PAM), MFA, Conditional Access, Mandantenkontrollen, Verschlüsselung und Umgebungstrennung setzen die Richtlinienerwartungen durch.

Viertens ist die Überwachung gezielt eingerichtet. Die Organisation kann Authentifizierung, Zugriff, Export, privilegierte Handlungen, Support-Zugriff und Konfigurationsänderungen mit Auswirkungen auf PII rekonstruieren.

Fünftens sind Überprüfungen risikobasiert und dokumentiert. PII mit hoher Tragweite wird mindestens vierteljährlich überprüft. Lieferanten- und Cloud-Support-Zugriff sind einbezogen. Ausnahmen werden bis zum Abschluss nachverfolgt.

Sechstens sind Nachweise wiederverwendbar. Dieselben Aufzeichnungen unterstützen GDPR-Rechenschaftspflicht, Betrieb des ISO/IEC 27701:2025-PIMS, ISO/IEC 27001:2022-Risikobehandlung, NIS2-Maßnahmen zum Risikomanagement, DORA-Governance für IKT-Risiken, GOVERN-Ergebnisse des NIST CSF 2.0 und Management Assurance nach COBIT 2019.

Das ist der Unterschied zwischen Zugriffskontrolle als Einstellung und Zugriffsgovernance als System.

Machen Sie PII-Zugriff zu auditbereiten Nachweisen

Wenn Ihr nächstes Audit, Ihre nächste Kundenprüfung oder die nächste Anfrage einer Aufsichtsbehörde morgen mit „Zeigen Sie mir, wer auf PII zugreifen kann“ beginnen würde: Würde Ihr Team Nachweise innerhalb von Minuten bereitstellen, oder würde es erst anfangen, Tabellen abzugleichen?

Clarysec kann Ihnen helfen, diese Lücke zu schließen.

Beginnen Sie mit der Richtlinie zur PII-Sicherheit und Zugriffskontrolle, richten Sie Pflichten von Auftragsverarbeitern und Cloud-Anforderungen über die Richtlinie zum Datenschutzmanagement für Auftragsverarbeiter, Unterauftragsverarbeiter und Drittparteien und die Cloud-PII-Auftragsverarbeiterrichtlinie aus, und nutzen Sie anschließend Zenith Blueprint: 30-Schritte-Roadmap für Auditoren, um Maßnahmen in der richtigen Reihenfolge umzusetzen. Verwenden Sie schließlich Zenith Controls: Leitfaden für rahmenwerksübergreifende Compliance, um Nachweise zum PII-Zugriff über ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 und COBIT 2019 hinweg zuzuordnen.

Der schnellste praktische nächste Schritt ist einfach: Wählen Sie ein PII-System mit hoher Tragweite aus, befüllen Sie REG12, exportieren Sie die Zugriffsliste, verifizieren Sie den Protokollierungsumfang und führen Sie eine Überprüfung im Stil der vierteljährlichen Prüfung durch. In einer Sitzung wissen Sie, ob Ihre Governance des PII-Zugriffs auditbereit ist – oder nur richtlinienbereit.