ISO 27701:2025-PIMS-Nachweise für GDPR-Audits

Es ist 08:40 Uhr an einem Donnerstag, und Ava, Compliance Managerin bei FinScale, hat gerade die E-Mail geöffnet, die jedes schnell wachsende B2B-SaaS-Unternehmen früher oder später erhält.

Ein großer deutscher Unternehmenskunde hat einen GDPR-Due-Diligence-Fragebogen mit einer Frist von 48 Stunden gesendet. Er fragt nicht nach einer Datenschutzrichtlinie. Er gibt sich nicht mit einem Zertifikat zufrieden. Er verlangt Nachweise.

Stellen Sie Ihr Verzeichnis der Verarbeitungstätigkeiten für unsere Daten bereit. Legen Sie Nachweise zur Due Diligence beim Onboarding von Unterauftragsverarbeitern vor. Erläutern Sie, wie Sie Ihre Pflichten aus GDPR Article 28 nachweisen. Stellen Sie für jeden Workflow fest, ob Ihre Plattform als PII-Verantwortlicher, Auftragsverarbeiter, gemeinsam Verantwortlicher oder Unterauftragsverarbeiter handelt. Belegen Sie, dass die Rechtsgrundlage für Ihre KI-gestützte Supportfunktion validiert wurde. Zeigen Sie Löschpflichten, Auditrechte, Unterstützung bei Vorfällen und Vertragskontrollen.

Ava weiß, dass FinScale über die notwendigen Bausteine verfügt. Die Rechtsabteilung hat den Auftragsverarbeitungsvertrag. Die Informationssicherheit hat die ISO/IEC 27001:2022-Anwendbarkeitserklärung (SoA). Das Produktteam hat Launch-Checklisten. Der Einkauf hat Lieferantenverträge. Compliance führt ein Verzeichnis der Verarbeitungstätigkeiten, auch wenn einige Einträge veraltet sind. Das Problem besteht nicht darin, dass keine Nachweise existieren. Das Problem besteht darin, dass die Nachweise verstreut sind, Rollenunklarheiten nicht aufgelöst wurden und niemand eine Verarbeitungstätigkeit schnell vom Zweck über Rechtsgrundlage, Risikoentscheidung, Lieferantenkontrolle, Sicherheitskontrolle, Auditaufzeichnung und Managementbewertung nachverfolgen kann.

Das ist die eigentliche Lücke in der Rechenschaftspflicht.

ISO 27701:2025 entfaltet ihre Wirkung, wenn sie genau diese Lücke schließt. Ein Privacy Information Management System, kurz PIMS, ist nicht nur ein Richtlinienordner für eine Datenschutzzertifizierung. Es ist ein Betriebsmodell zur Erzeugung belastbarer Nachweise. Für CISOs, Compliance Manager, Datenschutzverantwortliche, Auditoren und Geschäftsverantwortliche ist das Ziel klar: ein PIMS aufzubauen, das die GDPR-Rechenschaftspflicht für PII-Verantwortliche und Auftragsverarbeiter belegt und zugleich Anforderungen aus ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 und COBIT 2019 unterstützt.

GDPR-Rechenschaftspflicht ist ein Nachweisproblem

GDPR-Rechenschaftspflicht wird häufig als reine Dokumentationsanforderung missverstanden. Sie ist anspruchsvoller.

GDPR Article 5 definiert die Kernprinzipien der Verarbeitung personenbezogener Daten, darunter Rechtmäßigkeit, Fairness, Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität und Vertraulichkeit. Article 5(2) macht den Verantwortlichen dafür verantwortlich, die Einhaltung nachweisen zu können. Article 4 definiert das Vokabular zu personenbezogenen Daten, Verarbeitung, Verantwortlichem, Auftragsverarbeiter, Pseudonymisierung und Verletzung des Schutzes personenbezogener Daten. Article 6 verlangt eine Rechtsgrundlage für jede Verarbeitungstätigkeit des Verantwortlichen. Article 9 ergänzt strengere Bedingungen für besondere Kategorien personenbezogener Daten. Article 28 regelt Pflichten des Auftragsverarbeiters und Vertragsbedingungen.

Diese Pflichten werden nicht allein durch einen öffentlichen Datenschutzhinweis erfüllt. Sie erfordern Nachweise auf Ebene der Verarbeitungstätigkeit.

Ein praxistaugliches ISO 27701:2025-PIMS-Nachweismodell muss folgende Fragen beantworten:

• Welche PII werden verarbeitet?
• Warum werden sie verarbeitet?
• Handelt die Organisation als Verantwortlicher, Auftragsverarbeiter, gemeinsam Verantwortlicher oder Unterauftragsverarbeiter?
• Welche Rechtsgrundlage gilt, wenn die Organisation Verantwortlicher ist?
• Welche dokumentierte Weisung gilt, wenn die Organisation Auftragsverarbeiter ist?
• Welche Systeme, Lieferanten, Unterauftragsverarbeiter und Verarbeitungsorte sind beteiligt?
• Welche Entscheidung aus Datenschutz-Risiko-Screening oder DPIA wurde getroffen?
• Welche Sicherheitskontrollen schützen die PII?
• Welche Nachweise belegen, dass die Kontrolle betrieben wurde?
• Wer hat Restrisiko, Ausnahmen und Korrekturmaßnahmen genehmigt?

Der Ansatz von Clarysec überführt diese Fragen in Richtlinienpflichten, Register und nachvollziehbare Nachweisobjekte. Das Ergebnis ist ein PIMS, das Kunden-Due-Diligence, Prüfungen durch Aufsichtsbehörden, interne Audits, ISO-Audits, DORA-Bewertungen und Überprüfungen durch das Leitungsorgan standhält.

Beginnen Sie mit Rollenklarheit: Verantwortlicher, Auftragsverarbeiter oder beides

Der schnellste Weg, ein PIMS-Audit nicht zu bestehen, besteht darin, jede Verarbeitungstätigkeit gleich zu behandeln.

Nach GDPR bestimmt ein Verantwortlicher die Zwecke und Mittel der Verarbeitung. Ein Auftragsverarbeiter verarbeitet personenbezogene Daten im Auftrag eines Verantwortlichen. Viele SaaS- und Technologieunternehmen tun beides. FinScale ist Auftragsverarbeiter, wenn es Endnutzerdaten von Kunden gemäß Kundenweisungen hostet. FinScale ist Verantwortlicher für personenbezogene Daten von Beschäftigten, Marketing-Leads, Abrechnungskontakten, Bewerbungsdaten und bestimmte Produktanalysen.

Diese Unterscheidung bestimmt die Nachweisanforderungen.

Clarysecs Privacy Information Management System Policy macht die Rollenkategorisierung zu einer operativen Anforderung:

[Both] Der Prozessverantwortliche / Fachbereichsverantwortliche MUSS die PIMS-Rolle der Organisation für jede PII-Verarbeitungstätigkeit in REG02 klassifizieren, bevor die Verarbeitungstätigkeit beginnt.

Diese eine Verpflichtung verändert das Datenschutz-Betriebsmodell. Die rechtliche Prüfung ist kein nachgelagerter Launch-Schritt mehr. Jeder Prozessverantwortliche muss die PIMS-Rolle vor Beginn der Verarbeitung klassifizieren. Diese Klassifizierung bestimmt die nachgelagerte Nachweiskette.

Für Tätigkeiten als Verantwortlicher verlangt Clarysecs PII Processing Inventory and Lawful Basis Policy die Validierung der Rechtsgrundlage:

[Controller] Der Datenschutzverantwortliche / PIMS-Manager MUSS die in REG02 erfasste Rechtsgrundlage validieren, bevor die Verarbeitung durch den Verantwortlichen beginnt und bevor eine Zweckänderung wirksam wird.

Aus dem Abschnitt „Controller purpose and lawful basis records“, Richtlinienklausel 4.2.2.

Für Tätigkeiten als Auftragsverarbeiter verschiebt sich der Nachweisfokus auf dokumentierte Weisungen, Vertragskontrollen, Governance von Unterauftragsverarbeitern, Sicherheitsmaßnahmen, Unterstützungspflichten, Unterstützung bei Vorfällen sowie Rückgabe oder Löschung bei Beendigung. Genau hier wird REG08 kritisch.

Clarysecs Processor, Subprocessor and Third-Party Privacy Management Policy verlangt:

[Controller] Der Datenschutzverantwortliche / 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, Genehmigung von Unterauftragsverarbeitern, Unterstützung, Audit oder Assurance, Rückgabe, Löschung und Beendigung abdecken.

Aus dem Abschnitt „Contract and documented instruction controls“, Richtlinienklausel 4.3.2.

REG02 legt Verarbeitungstätigkeit und Rolle fest. REG04 bewertet Datenschutzrisiken. REG08 validiert Kontrollen für Auftragsverarbeiter, Unterauftragsverarbeiter und Lieferanten. REG12 indiziert die Nachweise. Zusammen bilden sie die PIMS-Nachweiskette.

Die PIMS-Nachweiskette, die Auditoren erwarten

Ein starkes PIMS verlangt von Teams nicht, unverbundene Tabellen zu pflegen. Es definiert Nachweisobjekte, Verantwortliche, Zeitpunkte, Überprüfungszyklen und Prüfpfade.

Clarysecs PIMS Documented Information and Evidence Management Policy legt fest:

[All] Der Datenschutzverantwortliche / PIMS-Manager MUSS vor der erstmaligen Veröffentlichung des PIMS und danach quartalsweise einen PIMS-Index dokumentierter Informationen in REG12 pflegen.

REG12 verhindert, dass das Datenschutzprogramm zu einem Ordner veralteter PDFs wird. Es zeigt dem Auditor, welche Nachweise existieren, wo sie gespeichert sind, wer sie verantwortet, wann sie zuletzt überprüft wurden und welche Verarbeitungstätigkeiten, Risiken, Verpflichtungen oder Kontrollen sie unterstützen.

Diese Nachweiskette passt nahtlos zu den ISO/IEC 27001:2022-Anforderungen an Kontext, interessierte Parteien, Risikoplanung, operative Steuerung, dokumentierte Information, Leistungsbewertung, internes Audit, Managementbewertung und kontinuierliche Verbesserung. Sie verbindet sich außerdem mit ISO/IEC 27002:2022-Kontrollen wie 5.2 Rollen und Verantwortlichkeiten für Informationssicherheit, 5.20 Berücksichtigung der Informationssicherheit in Lieferantenvereinbarungen, 5.21 Management der Informationssicherheit in der IKT-Lieferkette, 5.34 Datenschutz und Schutz von PII sowie 8.10 Löschung von Informationen.

Nachweise für Verantwortliche und Auftragsverarbeiter sind nicht dasselbe

Avas deutscher Kunde fragt nicht nur, ob FinScale Datenschutzrichtlinien hat. Der Kunde möchte den Nachweis, dass FinScale für jeden Datenfluss versteht, welche Rolle es einnimmt.

Wenn FinScale als Verantwortlicher handelt, muss das Unternehmen begründen, warum es Daten verarbeitet. Beispielsweise kann die Lohnabrechnung für Beschäftigte auf Vertragserforderlichkeit und rechtlicher Verpflichtung beruhen. Marketing kann je nach Kontext und Rechtsraum auf Einwilligung oder berechtigten Interessen beruhen. Recruiting kann Aufbewahrungsgrenzen, Transparenz und Zugriffskontrollen erfordern. Der Nachweis ist nicht nur die ausgewählte Rechtsgrundlage. Er umfasst den validierten Datensatz, den Datenschutzhinweis, die Aufbewahrungsregel, das Verfahren für Betroffenenrechte und die Risikoentscheidung.

Wenn FinScale als Auftragsverarbeiter handelt, muss das Unternehmen nachweisen, dass es nach dokumentierten Kundenweisungen handelt. Die Nachweise umfassen den Auftragsverarbeitungsvertrag, Produktkonfiguration, Systemprotokolle, Sicherheitskontrollen, Genehmigungen von Unterauftragsverarbeitern, Unterstützungsverfahren, den Prozess zur Unterstützung bei Verletzungen des Schutzes personenbezogener Daten, Auditrechte sowie Lösch- oder Rückgabenachweise.

Clarysecs P17 Data Protection and Privacy Policy bekräftigt, dass Datenschutz in das ISMS integriert sein muss:

Die Organisation MUSS ein formales Datenschutz-Governance-Rahmenwerk aufrechterhalten, das zur Durchsetzung dieser Richtlinie in das Informationssicherheits-Managementsystem (ISMS) integriert ist.

Aus dem Abschnitt „Governance Requirements“, Richtlinienklausel 5.1.

Die SME-Version, Data Protection and Privacy Policy-sme, hält dieselbe Nachweisdisziplin aufrecht:

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

Sie verlangt außerdem:

Die Rechtsgrundlage (z. B. Einwilligung, Vertrag, rechtliche Verpflichtung) MUSS im Verzeichnis der Verarbeitungstätigkeiten dokumentiert werden.

Für Enterprise-Programme ergänzt die P17 Data Protection and Privacy Policy eine klare Zuständigkeit:

Die Rechtsabteilung MUSS das Register der Rechtsgrundlagen pflegen und aktualisieren.

Praxisbeispiel: Einführung von Produktanalysen

Betrachten wir eine Produktanalysefunktion, die Nutzer-Navigation, Funktionsnutzung, Sitzungsmetadaten, Organisationskennung, Benutzerrolle und Geräteinformationen erfasst. Das Produktteam möchte Nutzungseinblicke. Sales möchte Nutzungskennzahlen. Customer Success möchte Abwanderungssignale. Die Rechtsabteilung fragt, ob FinScale Verantwortlicher oder Auftragsverarbeiter ist. Die Informationssicherheit fragt, ob Protokolle personenbezogene Daten enthalten. Der Einkauf weist darauf hin, dass der Analyseanbieter Unterauftragsverarbeiter einsetzt.

Ein starkes PIMS macht daraus einen wiederholbaren Workflow.

1. REG02 vor Beginn der Verarbeitung erstellen oder aktualisieren

Der Geschäftsverantwortliche erfasst die Tätigkeit in REG02. Der Datensatz sollte Zweck, PII-Kategorien, Kategorien betroffener Personen, Systeme, Aufbewahrungsfrist, Übermittlungen, Sicherheitsmaßnahmen, Rollenkategorisierung sowie Rechtsgrundlage oder dokumentierte Weisung enthalten.

Wenn Analysen für FinScales eigene Produktverbesserungszwecke genutzt werden, kann FinScale für diese Tätigkeit Verantwortlicher sein. Wenn Analysen ausschließlich im Auftrag des Kunden anhand kundenseitig konfigurierter Einstellungen durchgeführt werden, kann FinScale Auftragsverarbeiter sein. In vielen SaaS-Umgebungen können beide Rollen innerhalb einer Funktion bestehen, abhängig von Datenfluss und Zweck.

2. Rechtsgrundlage oder dokumentierte Weisung validieren

Wenn FinScale Verantwortlicher ist, validiert der Datenschutzverantwortliche oder die Rechtsabteilung die Rechtsgrundlage in REG02, bevor die Verarbeitung beginnt. Wenn besondere Kategorien personenbezogener Daten betroffen sind, muss das Team zudem die einschlägige Bedingung nach GDPR Article 9 und zusätzliche Schutzmaßnahmen ermitteln.

Wenn FinScale Auftragsverarbeiter ist, müssen die Nachweise auf die dokumentierte Weisung des Kunden verweisen. Die Frage lautet dann: Wo befindet sich die Weisung, welche Verarbeitung ist erlaubt, und wie weist FinScale nach, dass es die Weisung befolgt hat?

3. Datenschutz-Risiko-Screening in REG04 auslösen

Clarysecs Privacy Risk Assessment and DPIA Policy verlangt:

[Both] Der Prozessverantwortliche / Fachbereichsverantwortliche MUSS ein Datenschutz-Risiko-Screening in REG04 einleiten, bevor eine neue oder wesentlich geänderte, in REG02 erfasste PII-Verarbeitung beginnt.

Aus dem Abschnitt „Privacy risk screening“, Richtlinienklausel 4.1.1.

Das Screening sollte Sensitivität, Umfang, Überwachungsimplikationen, Erwartungen betroffener Personen, Profiling, automatisierte Entscheidungen, grenzüberschreitende Übermittlungen, Lieferantenzugriff, Aufbewahrung und Kontrollwirksamkeit bewerten. Bei erhöhtem Risiko sollte das PIMS eine DPIA auslösen und die Entscheidung dokumentieren.

4. REG08 für Lieferanten und Unterauftragsverarbeiter aktualisieren

Wenn ein Drittanbieter für Analysen PII erhält, aktualisieren Einkauf, Rechtsabteilung und Datenschutzfunktion REG08. Vertragsfelder sollten Umfang, Dauer, Zweck, PII-Kategorien, Vertraulichkeit, Sicherheit, Genehmigung von Unterauftragsverarbeitern, Unterstützung, Audit oder Assurance, Rückgabe, Löschung und Beendigung abdecken.

Die Third-Party and Supplier Security Policy-sme unterstützt diese operative Disziplin durch die Anforderung:

Verifikation von Datenumgangspraktiken oder Datenschutzkonformität, wenn personenbezogene Daten (PII) betroffen sind.

Die P17 Data Protection and Privacy Policy verlangt außerdem:

Einkauf sowie Rechts- und Compliance-Teams MÜSSEN die Einhaltung von Article 28 der GDPR verifizieren und eine jährliche Neubewertung aller Lieferanten mit hohem Risiko verlangen.

5. Nachweise in REG12 indizieren

Abschließend aktualisiert der PIMS-Manager REG12 mit Verknüpfungen zu REG02, Validierung der Rechtsgrundlage, dokumentierter Weisung, REG04-Screening, DPIA falls erforderlich, REG08-Lieferantendatensatz, Auftragsverarbeitungsvertrag, Sicherheitsprüfung, Aufbewahrungsentscheidung, Produktfreigabe und Überwachungsnachweisen.

So wird Privacy by Design zu auditbereiten Nachweisen.

Mit dem Zenith Blueprint Nachvollziehbarkeit aufbauen

Zu wissen, welche Nachweise zu erfassen sind, ist nur die halbe Aufgabe. Schwieriger ist der Aufbau eines Systems, das diese Nachweise zuverlässig erzeugt.

Der Zenith Blueprint: An Auditor’s 30-Step Roadmap verortet dies in der Phase ISMS Foundation & Leadership, Schritt 2: Stakeholder Needs and ISMS Scope. Der Leitfaden zeigt, wie Erwartungen interessierter Parteien zu geplanten Kontrollen werden:

Kunden
(B2B SaaS)
Datenvertraulichkeit, Verfügbarkeit gemäß
SLA, Meldung von Verstößen innerhalb von
24 Stunden
Zugriffskontrollen und Verschlüsselung umsetzen;
Incident Response Plan enthält
Meldeverfahren.

Er enthält außerdem:

Action Item 4.2: Erstellen Sie eine Liste aller wesentlichen interessierten Parteien und notieren Sie deren Anforderungen in Bezug auf Informationssicherheit.

Für ISO 27701:2025 erweitern Sie diesen Aktionspunkt auf Datenschutz. Interessierte Parteien umfassen Kunden, betroffene Personen, Aufsichtsbehörden, Auftragsverarbeiter, Unterauftragsverarbeiter, Beschäftigte, Produktteams, interne Revision, Management, Kunden aus dem Finanzsektor und sektorspezifische Aufsichtsbehörden, soweit NIS2 oder DORA anwendbar sind.

In der Phase Risk Management, Schritt 13: Risk Treatment Planning and Statement of Applicability, empfiehlt der Zenith Blueprint Nachvollziehbarkeit:

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

So entsteht der rote Faden, den Auditoren erwarten: Anforderung, Risiko, Kontrolle, Verantwortlicher, Nachweis, Testergebnis und Verbesserungsmaßnahme.

Wo Zenith Controls in das PIMS-Modell passt

Clarysecs Zenith Controls: The Cross-Compliance Guide hilft Teams, doppelte Compliance-Programme zu vermeiden, indem Kontrollthemen aus ISO/IEC 27001:2022 und ISO/IEC 27002:2022 anderen Standards, Auditerwartungen und Nachweismustern zugeordnet werden.

Für ISO 27701:2025-PIMS-Nachweise sind vier ISO/IEC 27002:2022-Kontrollen besonders wichtig:

• 5.2 Rollen und Verantwortlichkeiten für Informationssicherheit
• 5.20 Berücksichtigung der Informationssicherheit in Lieferantenvereinbarungen
• 5.21 Management der Informationssicherheit in der IKT-Lieferkette
• 5.34 Datenschutz und Schutz von PII

Kontrolle 5.2 unterstützt Rollenklarheit. Ein PIMS benötigt definierte Rechenschaftspflicht für PIMS-Manager, Datenschutzverantwortliche, Prozessverantwortliche, Fachbereichsverantwortliche, Rechtsabteilung, Einkauf, Informationssicherheit, interne Revision und oberste Leitung.

Kontrolle 5.34 unterstützt die zentrale Datenschutzverpflichtung. Der Zenith Blueprint, Phase Controls in Action, Schritt 23, erläutert die Auditerwartung:

Aus Auditsicht steht diese Kontrolle zunehmend im Fokus. Auditoren, Aufsichtsbehörden und Kunden möchten gleichermaßen sehen:

✓ Wo PII gespeichert sind,
✓ welche Rechtsgrundlage ihre Verarbeitung regelt,
✓ wie der Zugriff beschränkt wird,
✓ wie Vorfälle gemeldet werden,
✓ und wie die Organisation Betroffenenrechte erfüllt und Transparenz wahrt.

Der Zenith Blueprint fährt fort:

Kontrolle 5.34 ist nicht nur eine Checkbox. Sie ist eine Erklärung ethischer Verantwortung.

Kontrollen 5.20 und 5.21 verbinden PIMS-Nachweise mit Lieferanten- und IKT-Lieferketten-Governance. Der Zenith Blueprint, Phase Controls in Action, Schritt 23, nennt Themen für Lieferantenvereinbarungen:

Zu den typischen Kernbereichen in Lieferantenvereinbarungen gehören:

✓ Vertraulichkeitspflichten, einschließlich Umfang, Dauer und Beschränkungen der Offenlegung gegenüber Dritten;
✓ Verantwortlichkeiten für die Zugriffskontrolle, etwa wer auf Ihre Daten zugreifen darf, wie Zugangsdaten verwaltet werden und welche Überwachung besteht;
✓ technische und organisatorische Maßnahmen für Datenschutz, Verschlüsselung, sichere Übertragung, Backup und Verfügbarkeitszusagen;
✓ Fristen und Protokolle für die Meldung von Vorfällen, häufig mit definierten Zeitrahmen (z. B. „Benachrichtigung innerhalb von 24 Stunden“);
✓ Auditrechte, einschließlich Häufigkeit, Umfang und Zugang zu relevanten Nachweisen (z. B. Penetrationstestberichte, SoA, Zertifizierungen);
✓ Kontrollen für Unterauftragnehmer, die verlangen, dass Ihr Lieferant gleichwertige Sicherheitsverpflichtungen an seine nachgelagerten Partner weitergibt;
✓ Regelungen zum Vertragsende, etwa Datenrückgabe oder -vernichtung, Asset-Wiederherstellung und Kontodeaktivierung.

Das ist die Brücke zwischen GDPR-Rechenschaftspflicht und ISMS-Nachweisen.

PIMS-Nachweise auf GDPR, NIS2, DORA, NIST und COBIT 2019 abbilden

Datenschutznachweise dienen selten nur einem einzigen Rahmenwerk. Ein gut gestaltetes PIMS-Nachweisobjekt kann mehrere Auditfragen beantworten.

GDPR verankert Datenschutz-Rechenschaftspflicht durch Rechtsgrundlage, Rollenklarheit, Auftragsverarbeiterverträge, Rechte, Behandlung von Verletzungen des Schutzes personenbezogener Daten und nachweisbare Einhaltung.

NIS2 ist relevant für wesentliche und wichtige Einrichtungen, darunter bestimmte Cloud-Anbieter, Managed Service Provider, Managed Security Service Provider, Rechenzentrumsanbieter und Organisationen der digitalen Infrastruktur. NIS2 Article 20 weist Leitungsorganen Verantwortung für Cybersicherheitsgovernance zu. Article 21 verlangt geeignete technische, operative und organisatorische Maßnahmen, einschließlich Risikoanalyse, Incident Handling, Aufrechterhaltung des Geschäftsbetriebs, Lieferkettensicherheit, sicherer Entwicklung, Wirksamkeitsbewertung, Schulung, Kryptografie, HR-Sicherheit, Zugriffskontrolle, Asset-Management sowie MFA oder kontinuierlicher Authentifizierung, sofern angemessen. Article 23 führt Erwartungen an die Meldung erheblicher Vorfälle ein, einschließlich Frühwarnung innerhalb von 24 Stunden und Vorfallmeldung innerhalb von 72 Stunden.

DORA ist relevant für Finanzunternehmen und IKT-Drittdienstleister in Finanzökosystemen. DORA Articles 5 und 6 verlangen IKT-Risikogovernance, Richtlinien, Strategie, Tests und kontinuierliche Verbesserung. Articles 17 bis 19 behandeln Erkennung, Klassifizierung, Eskalation und Meldung von IKT-Vorfällen, Ursachenanalyse und Lessons Learned. Articles 28 bis 30 verlangen eine Strategie für IKT-Drittparteienrisiken, Register, gebotene Sorgfalt, vertragliche Regelungen, Auditrechte, Unterstützung bei Vorfällen, Datenschutz, Exit-Planung und Überprüfung von Konzentrationsrisiken.

NIST CSF 2.0 bietet eine Governance- und Risikosprache über GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND und RECOVER. COBIT 2019 ergänzt Governance-Ziele, Managementpraktiken, Verantwortlichkeit, Kennzahlen, Assurance und Prozessfähigkeit.

Der Compliance-Vorteil ist klar. Eine kontrollierte PIMS-Nachweiskette kann GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0, COBIT 2019 und Kunden-Due-Diligence unterstützen.

Wie Auditoren Ihr PIMS prüfen werden

Ein PIMS-Audit ist keine reine Dokumentenprüfung. Es ist eine Prüfung der Nachvollziehbarkeit von Nachweisen.

Clarysecs P33 Audit and Compliance Monitoring Policy unterstützt das Auditmodell:

Die Organisation MUSS ein Auditregister führen, das Folgendes enthält:

Das SME-Gegenstück, Audit and Compliance Monitoring Policy-sme, ergänzt eine wichtige Anforderung an die Nachweisqualität:

Metadaten (z. B. wer sie erhoben hat, wann und aus welchem System) MÜSSEN dokumentiert werden.

Diese Metadatenanforderung ist klein, aber wirkungsvoll. Screenshots ohne Quelle, Datum, Erheber und Systemkontext sind schwache Nachweise. Kontrollierte Auditnachweise belegen Authentizität, Aktualität und Nachvollziehbarkeit.

Wie gute PIMS-Nachweise aussehen

Angenommen, ein Auditor wählt eine Tätigkeit aus: Analyse von Kundensupport-Tickets.

Eine schwache Antwort lautet: „Wir haben eine Datenschutzrichtlinie und unser Auftragsverarbeitungsvertrag deckt das ab.“

Eine starke PIMS-Antwort lautet:

1. REG02 identifiziert die Tätigkeit, Systeme, PII-Kategorien, betroffene Personen, Zweck, Rollenkategorisierung, Aufbewahrung, Übermittlungen, Sicherheitskontrollen und Verantwortlichen.
2. Die Rollenkategorisierung zeigt, ob die Organisation für bestimmte Teile des Workflows Verantwortlicher, Auftragsverarbeiter oder beides ist.
3. Wenn sie Verantwortlicher ist, wird die Rechtsgrundlage validiert und im Register der Rechtsgrundlagen erfasst.
4. Wenn sie Auftragsverarbeiter ist, werden Kundenweisung und Klausel im Auftragsverarbeitungsvertrag verknüpft.
5. REG04 zeigt das Datenschutz-Risiko-Screening vor Launch oder wesentlicher Änderung.
6. REG08 identifiziert die Ticketing-Plattform, den Anbieter für KI-Zusammenfassungen, Unterauftragsverarbeiter, Vertragskontrollen, Auditrechte, Sicherheitszusicherungen, Löschbedingungen und Unterstützung bei Vorfällen.
7. Nachweise zur Zugriffskontrolle zeigen, dass der Zugriff von Supportpersonal rollenbasiert ist und überprüft wird.
8. Nachweise zur Protokollierung und Überwachung zeigen, dass der Zugriff auf Support-Tickets überwacht wird.
9. Nachweise zur Aufbewahrung und Löschung zeigen, dass Tickets gemäß der genehmigten Aufbewahrungsfrist gelöscht oder anonymisiert werden.
10. REG12 indiziert alle unterstützenden Nachweise mit Verantwortlichem und Überprüfungsdatum.
11. Das Auditregister zeigt, ob die Tätigkeit geprüft wurde, welche Feststellungen erhoben wurden und ob Korrekturmaßnahmen abgeschlossen wurden.

So wird ISO 27701:2025 operativ. Sie schafft eine wiederholbare Kette der Rechenschaftspflicht.

Häufige Fehler bei PIMS-Nachweisen

In SaaS-, Fintech-, Managed-Service- und B2B-Technologieumgebungen treten immer wieder dieselben Lücken auf.

Erstens führen Organisationen ein RoPA oder Verzeichnis der Verarbeitungstätigkeiten, klassifizieren aber die Rollen als Verantwortlicher und Auftragsverarbeiter nicht je Tätigkeit. Dadurch entstehen Unklarheiten bei Rechtsgrundlage, dokumentierten Weisungen und Pflichten zu Unterauftragsverarbeitern.

Zweitens wird die Rechtsgrundlage einmal erfasst und bei Zweckänderungen nicht erneut validiert. GDPR Article 6 verlangt Disziplin bei Zweck und Rechtsgrundlage. Eine Weiterverarbeitung kann eine Vereinbarkeitsprüfung und Schutzmaßnahmen erfordern.

Drittens führen Lieferanteninventare zwar Lieferanten auf, zeigen aber keine Vertragskontrollfelder. Eine Lieferantenliste ist nicht dasselbe wie Auftragsverarbeiter-Governance.

Viertens sind DPIA-Entscheidungen informell. Teams sagen „kein hohes Risiko“, können aber Screening-Kriterien, Genehmiger, Datum oder Nachweise nicht vorlegen.

Fünftens existieren Auditnachweise, sind aber nicht kontrolliert. Screenshots fehlen Metadaten. Richtlinien sind aktuell, Register aber veraltet. Verträge existieren, aber Neubewertungen bei Verlängerung werden versäumt.

Sechstens konzentrieren sich Vorfallsprozesse auf Cybersicherheitsereignisse, klassifizieren Verletzungen des Schutzes personenbezogener Daten aber nicht eindeutig. GDPR-Analysen zu Verletzungen des Schutzes personenbezogener Daten, NIS2-Meldungen erheblicher Vorfälle und DORA-Meldungen von IKT-Vorfällen müssen koordiniert, nicht doppelt geführt werden.

Clarysec adressiert diese Fehler, indem PIMS-Nachweise als kontrolliertes Managementsystem behandelt werden, nicht als kurzfristige Audit-Notmaßnahme.

Checkliste zur ISO 27701:2025-PIMS-Nachweisbereitschaft

Nutzen Sie diese Checkliste für Ihre nächste interne Bereitschaftsprüfung.

• PIMS-Geltungsbereich und interessierte Parteien definieren, einschließlich Kunden, Aufsichtsbehörden, betroffener Personen, Lieferanten, interner Revision und Management.
• PIMS-Rollen und Verantwortlichkeiten zuweisen, einschließlich PIMS-Manager, Datenschutzverantwortlicher, Prozessverantwortlicher, Rechtsabteilung, Einkauf, Informationssicherheit und interne Revision.
• REG02-Einträge für jede PII-Verarbeitungstätigkeit erstellen.
• Rolle als Verantwortlicher, Auftragsverarbeiter, gemeinsam Verantwortlicher oder Unterauftragsverarbeiter für jede Tätigkeit klassifizieren.
• Rechtsgrundlage für die Verarbeitung durch den Verantwortlichen vor Beginn der Verarbeitung und vor Zweckänderung validieren.
• Dokumentierte Weisungen für Tätigkeiten als Auftragsverarbeiter erfassen.
• REG04-Datenschutz-Risiko-Screening vor neuer oder wesentlich geänderter Verarbeitung auslösen.
• Eine DPIA abschließen, wenn das Risiko-Screening ein erhöhtes Datenschutzrisiko anzeigt.
• REG08 für Auftragsverarbeiter, Unterauftragsverarbeiter, IKT-Lieferanten und datenschutzrelevante Lieferanten pflegen.
• Vertragsfelder für Umfang, Dauer, Zweck, PII-Kategorien, Vertraulichkeit, Sicherheit, Unterstützung, Auditrechte, Rückgabe, Löschung und Beendigung verifizieren.
• REG12 als PIMS-Index dokumentierter Informationen pflegen.
• PIMS-Nachweise auf ISO/IEC 27001:2022-Risikobehandlung und SoA-Anmerkungen abbilden.
• GDPR-, NIS2-, DORA-, NIST CSF 2.0- und COBIT 2019-Verpflichtungen bei Relevanz querverweisen.
• Jährliche interne Datenschutzaudits durchführen und das Auditregister aktualisieren.
• Offene Feststellungen, Korrekturmaßnahmen, Risikoentscheidungen und Managementberichterstattung quartalsweise überprüfen.

Die P17 Data Protection and Privacy Policy bekräftigt den Auditzyklus:

Ein internes Datenschutzaudit MUSS jährlich oder bei wesentlichen organisatorischen oder regulatorischen Änderungen durchgeführt werden. Der Audit-Geltungsbereich MUSS Folgendes umfassen:

Die Botschaft ist einfach: Datenschutzkonformität wird überwacht, nicht angenommen.

Bauen Sie Ihr PIMS-Nachweismodell mit Clarysec auf

ISO 27701:2025 ist am wertvollsten, wenn sie in ISO/IEC 27001:2022 integriert und so gestaltet ist, dass Nachweise standardmäßig entstehen. So wird Datenschutz zu einem belastbaren Betriebsmodell statt zu einem Zertifizierungsprojekt.

Wenn ein Kunde Datenschutz-Assurance verlangt, können Sie Nachweise zeigen. Wenn eine Aufsichtsbehörde fragt, warum Sie Daten verarbeitet haben, können Sie Rolle, Zweck, Rechtsgrundlage, Schutzmaßnahmen und Genehmigungen zeigen. Wenn ein Auditor fragt, wie Sie Unterauftragsverarbeiter steuern, können Sie REG08, Vertragskontrollen, Neubewertungen und Auditrechte zeigen. Wenn das Leitungsorgan fragt, ob Datenschutzrisiken unter Kontrolle sind, können Sie Kennzahlen, offene Maßnahmen, Auditergebnisse und Managementbewertung zeigen.

Wenn Ihr PIMS noch richtlinienlastig und nachweisschwach ist, beginnen Sie mit der Kette, der Auditoren folgen werden:

REG02-Verarbeitungsinventar, REG04-Datenschutz-Risiko-Screening, REG08-Governance für Auftragsverarbeiter und Unterauftragsverarbeiter, REG12-Nachweisindex, Register der Rechtsgrundlagen, Auditregister und SoA-Mapping.

Clarysec kann Ihnen helfen, diese Kette operativ umzusetzen durch:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap, insbesondere Schritt 2 für Anforderungen interessierter Parteien, Schritt 13 für Risikobehandlung und SoA-Nachvollziehbarkeit sowie Schritt 23 für Datenschutz-, Lieferanten- und organisatorische Kontrollen.
• Zenith Controls: The Cross-Compliance Guide, mit ISO/IEC 27002:2022-Kontrollen 5.2, 5.20, 5.21 und 5.34 als praktischen Ankern für Datenschutz-Rechenschaftspflicht.
• Clarysecs ISO 27701-PIMS-Richtlinienset, einschließlich Privacy Information Management System Policy, PII Processing Inventory and Lawful Basis Policy, Privacy Risk Assessment and DPIA Policy, Processor, Subprocessor and Third-Party Privacy Management Policy und PIMS Documented Information and Evidence Management Policy.
• Unterstützung für Enterprise und SME durch P17 Data Protection and Privacy Policy, Data Protection and Privacy Policy-sme, Third-Party and Supplier Security Policy-sme, P33 Audit and Compliance Monitoring Policy und Audit and Compliance Monitoring Policy-sme.

Ihre nächste Maßnahme ist einfach: Wählen Sie eine PII-Verarbeitungstätigkeit mit hohem Risiko und durchlaufen Sie die Nachweiskette von REG02 bis REG12. Wenn die Kette bricht, ist das Ihr erstes Verbesserungsprojekt. Wenn sie hält, erweitern Sie das Modell über Ihr Verarbeitungsinventar hinweg.

So wird ISO 27701:2025 zu mehr als einem Zertifikat. Sie wird zum Nachweis der GDPR-Rechenschaftspflicht.