Anwendbarkeit von ISO 27701-Kontrollen nach GDPR-Rollen

Es ist 08:40 Uhr an einem Dienstag, und Maria, CISO eines schnell wachsenden HealthTech-SaaS-Unternehmens, blickt auf vier Kunden-E-Mails, die nahezu identisch aussehen, aber sehr unterschiedliche Anforderungen auslösen.

Ein Unternehmenskunde fordert Nachweise, dass das Unternehmen als GDPR-Auftragsverarbeiter nach Article 28 handeln kann. Ein zweiter fragt, ob die Plattform für Telemetrie und Produktanalysen auch Verantwortlicher ist. Ein dritter fordert die aktuelle Liste der Unterauftragsverarbeiter und den Nachweis, dass Klauseln aus Auftragsverarbeitungsverträgen weitergegeben werden. Ein vierter, ein FinTech-Kunde in Vorbereitung auf DORA-Lieferantenprüfungen, fragt, ob dieselben Datenschutzkontrollen auch auf operative Resilienz, Vorfallmeldung und IKT-Drittparteienrisiko abgebildet sind.

Marias Unternehmen handelt nicht nachlässig. Es verfügt über ein an ISO/IEC 27001:2022 ausgerichtetes ISMS, Datenschutzrichtlinien, ein Verarbeitungsregister, MFA, Verschlüsselung, Berechtigungsprüfungen und Schulungen zu Datenschutz durch Technikgestaltung. Die Anfrage legt jedoch die schwierigere Frage offen, die Auditoren und Kunden tatsächlich prüfen:

Kann das Unternehmen nachweisen, dass die richtigen ISO 27701-PIMS-Kontrollen für die richtige GDPR-Rolle, die richtige Verarbeitungstätigkeit sowie die richtigen Verantwortlichen, Nachweise und Begründungen gelten?

Genau daran scheitern viele Datenschutzprogramme. Sie behandeln ISO 27701 als Checkliste, obwohl Zertifizierungsstellen, Kundenauditoren und Datenschutzbeauftragte eine begründete Entscheidung zur Anwendbarkeit von Kontrollen erwarten. Die Antwort lautet nicht: „Wir haben Datenschutzkontrollen.“ Die Antwort lautet: „Für diese Verarbeitungstätigkeit sind wir Verantwortlicher, Auftragsverarbeiter, gemeinsamer Verantwortlicher oder Unterauftragsverarbeiter, und aus diesen Gründen gelten diese Kontrollen – oder gelten nicht.“

Warum die Anwendbarkeit von ISO 27701-Kontrollen die fehlende PIMS-Ebene ist

GDPR-Rollen beruhen auf Entscheidungsbefugnis. Ein Verantwortlicher legt die Zwecke und Mittel der Verarbeitung fest. Ein Auftragsverarbeiter handelt im Auftrag eines Verantwortlichen. Gemeinsam Verantwortliche legen Zwecke und Mittel gemeinsam fest. Ein Unterauftragsverarbeiter wird von einem Auftragsverarbeiter beauftragt, personenbezogene Daten weiter nachgelagert zu verarbeiten.

In realen SaaS-Umgebungen bleiben diese Rollen selten sauber auf Unternehmensebene getrennt. Marias Organisation ist Auftragsverarbeiter, wenn sie Wellnessdaten von Kunden hostet, Verantwortlicher für die Gehaltsabrechnung von Beschäftigten und Marketingkontakte, je nach Zweck und Vertragsbedingungen möglicherweise Verantwortlicher für Produkttelemetrie und gemeinsamer Verantwortlicher in einer Co-Branding-Kampagne. Wenn ein größerer Managed-Service-Provider ihre Plattform weiterverkauft, kann das Unternehmen in dieser Kette außerdem Unterauftragsverarbeiter werden.

Die Anwendbarkeit von ISO 27701-Kontrollen ist die Disziplin, die verhindert, dass diese Rollen in unpräzise Aussagen zerfallen. Sie fragt:

• Welche Verarbeitungstätigkeit liegt im Geltungsbereich?
• Welche GDPR-Rolle übernimmt die Organisation für diese Tätigkeit?
• Welche PIMS-Kontrollen gelten aufgrund dieser Rolle?
• Welche Kontrollen sind ausgeschlossen, und warum?
• Welche Nachweise belegen die Umsetzung?
• Welche gesetzliche, vertragliche, risiko- oder geltungsbereichsbezogene Anforderung hat die Entscheidung ausgelöst?

Clarysecs Richtlinie zum Datenschutz-Informationsmanagementsystem macht die Rollenklassifizierung zum Ausgangspunkt:

„[Beide] Die prozessverantwortliche bzw. fachlich verantwortliche Person MUSS die PIMS-Rolle der Organisation für jede Verarbeitungstätigkeit mit personenbezogenen Daten in REG02 klassifizieren, bevor die Verarbeitungstätigkeit beginnt.“

Aus Abschnitt „PIMS-Rollenbestimmung“, Richtlinienklausel 4.2.1.

Dieselbe Richtlinie verknüpft diese Rollenentscheidung mit der Anwendbarkeit von Kontrollen:

„[Beide] Die Datenschutzverantwortliche bzw. PIMS-verantwortliche Person MUSS REG03 mit einbezogenen Kontrollen, ausgeschlossenen Kontrollen, Umsetzungsstatus und Begründung jährlich sowie innerhalb von 30 Tagen nach jeder Änderung der Datenschutz-Risikobehandlung pflegen.“

Aus Abschnitt „Datenschutzrichtlinie, Ziele und Anwendbarkeit von Kontrollen“, Richtlinienklausel 4.3.3.

REG02 beantwortet, welche Verarbeitung besteht und welche Rolle gilt. REG03 beantwortet, welche Kontrollen gelten, was ausgeschlossen ist, welche Nachweise vorhanden sind und warum die Entscheidung belastbar ist.

Das PIMS auf der SoA-Logik von ISO/IEC 27001:2022 aufbauen

Ein rollenbasiertes PIMS funktioniert am besten, wenn es auf einem reifen ISMS aufsetzt. ISO/IEC 27001:2022 verlangt bereits die Definition des Geltungsbereichs, die Analyse interessierter Parteien, Risikobeurteilung, Risikobehandlung, Auswahl von Kontrollen und eine Anwendbarkeitserklärung. ISO 27701 erweitert diese Managementsystem-Logik auf den Datenschutz.

Clarysecs Informationssicherheitsleitlinie legt fest:

„Das ISMS muss definierte Grenzen des Geltungsbereichs, eine Methodik zur Risikobeurteilung, messbare Ziele und dokumentierte Kontrollen enthalten, die in der Anwendbarkeitserklärung (SoA) begründet sind.“

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

Die Risikomanagement-Richtlinie stärkt dieselbe Nachweisdisziplin:

„Eine Anwendbarkeitserklärung (SoA) muss alle Risikobehandlungsentscheidungen widerspiegeln und aktualisiert werden, wenn die Kontrollabdeckung geändert wird.“

Aus Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.4.

Für den Datenschutz wird REG03 zum PIMS-Register zur Anwendbarkeit von Kontrollen, das die SoA-Disziplin abbildet. Es ersetzt die ISO/IEC 27001:2022-SoA nicht. Es erweitert sie um GDPR-rollenspezifische Datenschutzentscheidungen für Verantwortliche, Auftragsverarbeiter, gemeinsam Verantwortliche und Unterauftragsverarbeiter.

Die Richtlinie zum Verarbeitungsinventar personenbezogener Daten und zur Rechtsgrundlage macht diese Verknüpfung ausdrücklich:

„[Beide] Die Datenschutzverantwortliche bzw. PIMS-verantwortliche Person MUSS anwendbare REG02-Verarbeitungstätigkeiten vor der Prüfung der Zertifizierungsbereitschaft mit REG03-Datensätzen zur Anwendbarkeit von Kontrollen verknüpfen.“

Aus Abschnitt „Betrieb des Verarbeitungsinventars“, Richtlinienklausel 7.1.5.

Ein Auditor sollte eine Verarbeitungstätigkeit in REG02 auswählen, die GDPR-Rolle identifizieren, anwendbare Kontrollen in REG03 nachvollziehen, die relevanten ISO/IEC 27001:2022-Kontrollen in der SoA prüfen und Nachweise wie einen Auftragsverarbeitungsvertrag, einen Datensatz zur Rechtsgrundlage, eine Berechtigungsprüfung, eine Genehmigung eines Unterauftragsverarbeiters, ein Vorfallverfahren oder ein Löschprotokoll einsehen können.

Das rollenbasierte Modell zur Anwendbarkeit von Kontrollen

Der schnellste Weg, ISO 27701 nutzbar zu machen, besteht darin, die Anwendbarkeit auf Ebene der Verarbeitungstätigkeit und nicht auf Unternehmensebene zu entscheiden.

Ein SaaS-Anbieter sollte vermeiden zu sagen: „Wir sind Auftragsverarbeiter.“ Er sollte sagen: „Für von Kunden hochgeladene Benutzerdatensätze in der Produktionsplattform sind wir Auftragsverarbeiter. Für die Gehaltsabrechnung sind wir Verantwortlicher. Für Produktanalysen hängt unsere Rolle davon ab, ob die Analysen ausschließlich zur Erbringung vertraglich vereinbarter Leistungen oder für unsere eigenen Zwecke verwendet werden. Für den Ticketsystem-Anbieter, der Kundendaten unterstützt, ist der Anbieter ein Unterauftragsverarbeiter.“

Diese rollenbasierte Sicht entspricht der GDPR-Rechenschaftspflicht. Verantwortliche müssen die Einhaltung von Grundsätzen wie Rechtmäßigkeit, Fairness, Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität, Vertraulichkeit und Rechenschaftspflicht nachweisen. Auftragsverarbeiter dürfen nur auf dokumentierte Weisung verarbeiten, müssen angemessene Sicherheit umsetzen, Verantwortliche unterstützen, Unterauftragsverarbeiter steuern und Rückgabe oder Löschung unterstützen.

Die gefährliche Abkürzung besteht darin, anzunehmen, jede Datenschutzkontrolle gelte überall. Ein Auftragsverarbeiter legt in der Regel nicht die Rechtsgrundlage für Endbenutzerdaten von Kunden fest, muss aber nachweisen, dass er nur gemäß Kundenweisung verarbeitet. Ein Verantwortlicher benötigt für interne HR-Verarbeitung möglicherweise keine Kundengenehmigung für Unterauftragsverarbeiter, muss aber für den Anbieter der Gehaltsabrechnung eine Due Diligence des Auftragsverarbeiters durchführen.

Vor Vertragsfreigabe oder Beginn der Verarbeitung klassifizieren

Die häufigste Feststellung zur PIMS-Bereitschaft ist eine verspätete Rollenklassifizierung. Der Vertrag ist unterzeichnet, die Plattform ist produktiv, Lieferanten sind integriert, und niemand hat entschieden, ob die Organisation für jeden Datenfluss Verantwortlicher, Auftragsverarbeiter, gemeinsamer Verantwortlicher oder Unterauftragsverarbeiter ist.

Diese Verzögerung erzeugt nachgelagerte Probleme. Der falsche Auftragsverarbeitungsvertrag wird verwendet. Unterauftragsverarbeiter werden nicht offengelegt. DSFAs werden versäumt. Aufbewahrung ist unklar. Der Kundensupport weiß nicht, welche Meldefrist für Verletzungen des Schutzes personenbezogener Daten gilt. Die Beschaffung behandelt einen datenschutzrelevanten Lieferanten als „nur ein Tool“.

Die Richtlinie zum Management von Auftragsverarbeitern, Unterauftragsverarbeitern und Drittparteien im Datenschutz adressiert den Zeitpunkt unmittelbar:

„[Beide] Die Datenschutzverantwortliche bzw. PIMS-verantwortliche Person MUSS jede datenschutzbezogene Drittparteienbeziehung in REG08 als Verantwortlicher, gemeinsamer Verantwortlicher, Auftragsverarbeiter, Unterauftragsverarbeiter oder sonstige Drittparteienbeziehung klassifizieren, bevor der Vertrag freigegeben wird oder bevor die Verarbeitung personenbezogener Daten beginnt, je nachdem, was zuerst eintritt.“

Aus Abschnitt „Identifizierung und Klassifizierung von Beziehungen“, Richtlinienklausel 4.1.3.

Die REG08-Klassifizierung von Lieferanten- und Drittparteienbeziehungen speist REG03. Wenn ein Lieferant Auftragsverarbeiter ist, umfassen die anwendbaren Kontrollen Vertragsbedingungen des Auftragsverarbeitungsvertrags, Vertraulichkeit, Sicherheitsmaßnahmen, Auditrechte, Unterstützung bei Betroffenenanfragen, Unterstützung bei Verletzungen des Schutzes personenbezogener Daten, Rückgabe oder Löschung sowie Kontrollen für Unterauftragsverarbeiter. Wenn ein Lieferant ein eigenständiger Verantwortlicher ist, verschiebt sich der Fokus auf Rechtsgrundlage, Governance für Offenlegungen, Übermittlungen, Transparenz und Rechenschaftspflicht.

Für kleinere Organisationen verlangt die Richtlinie zur Lieferanten- und Drittparteiensicherheit für KMU, dass Teams Folgendes berücksichtigen:

„Regulatorische Exponierung (z. B. GDPR-Auftragsverarbeiterrolle, Verpflichtungen des Finanzsektors unter DORA)“

Aus Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.2.4.

Sie legt außerdem eine klare Anforderung vor der Weitergabe fest:

„Auftragsverarbeitungsvertragsklauseln oder gleichwertige vertragliche Bedingungen müssen vereinbart sein, bevor personenbezogene oder sensitive Daten weitergegeben werden.“

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

Das ist der Unterschied zwischen vorhandenen Lieferantenverträgen und auditierbarer Governance für Datenschutzrollen.

Kontrollen auf Rolle, Risiko, Recht und Vertrag abbilden

Der Zenith Blueprint, Risikomanagementphase, Schritt 13: Planung der Risikobehandlung und Anwendbarkeitserklärung, erläutert die Kernlogik der Anwendbarkeit. Kontrollen sind aufgrund von Risikobehandlungsentscheidungen, gesetzlichen oder vertraglichen Anforderungen, Relevanz für den Geltungsbereich und organisatorischem Kontext anwendbar. Ausschlüsse benötigen klare Gründe, und anwendbare Kontrollen sollten auf ein Risiko oder eine Anforderung zurückführbar sein.

In Schritt 13 stellt Zenith Blueprint fest:

„Stellen Sie die Abstimmung mit Ihrem Risikoregister sicher: Jede risikomindernde Kontrolle, die Sie im Risikobehandlungsplan dokumentiert haben, sollte einer Annex A-Kontrolle entsprechen, die als ‚Anwendbar‘ gekennzeichnet ist. Umgekehrt sollte für jede als anwendbar gekennzeichnete Kontrolle entweder ein Risiko oder eine Anforderung bestehen, die sie begründet.“

Für ISO 27701 gilt dieselbe Methode für Datenschutzkontrollen. Eine Kontrolle kann anwendbar sein, weil:

1. GDPR sie für die Rolle der Organisation verlangt.
2. Ein Kundenvertrag, ein Auftragsverarbeitungsvertrag oder eine Vereinbarung über gemeinsame Verantwortlichkeit sie verlangt.
3. Eine Datenschutz-Risikobehandlung sie verlangt.
4. Die Verarbeitung besondere Kategorien, Daten von Kindern, groß angelegte Überwachung, sensitives Profiling oder personenbezogene Daten mit hoher Tragweite umfasst.
5. Lieferanten-, Cloud-, Unterauftragsverarbeiter- oder grenzüberschreitende Übermittlungsrisiken die Kontrolle erforderlich machen.
6. Die Kontrolle den Geltungsbereich der Zertifizierung, die Auditbereitschaft oder freigegebene Datenschutzziele unterstützt.

Die Richtlinie zur rechtlichen und regulatorischen Compliance stärkt diese Abbildungsdisziplin:

„Wenn eine Vorschrift über mehrere Bereiche hinweg gilt (z. B. GDPR für Aufbewahrung, Sicherheit und Datenschutz), muss dies im Compliance-Register und in Schulungsmaterialien klar abgebildet werden.“

Aus Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.2.2.

Dieselbe Richtlinie zur rechtlichen und regulatorischen Compliance ist für die Integration in Unternehmens-ISMS eindeutig:

„Alle gesetzlichen und regulatorischen Verpflichtungen müssen bestimmten Richtlinien, Kontrollen und Verantwortlichen innerhalb des Informationssicherheits-Managementsystems (ISMS) zugeordnet werden.“

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

REG03 darf daher niemals eine losgelöste Datenschutz-Tabelle sein. Es sollte Verarbeitungstätigkeiten, rechtliche Verpflichtungen, Risikobehandlungen, Verträge, ISO/IEC 27001:2022-Kontrollen und Nachweisverantwortliche verbinden.

Praxisbeispiel: ein SaaS-Support-Prozess

Betrachten wir einen Support-Prozess in Marias SaaS-Plattform. Kunden reichen Tickets ein, die Namen, E-Mail-Adressen, Konto-Kennungen, Screenshots und gelegentlich sensitiven geschäftlichen Kontext enthalten können. Supportmitarbeitende greifen auf begrenzte Datensätze zu. Ein Cloud-Ticketing-Anbieter hostet die Daten und setzt eigene Unterauftragsverarbeiter ein.

Schritt 1: Tätigkeit in REG02 erfassen

Die Datenschutzverantwortliche erfasst:

• Tätigkeitsname: Bearbeitung von Kundensupport-Tickets
• Kategorien personenbezogener Daten: Benutzerkennungen, Kontaktdaten, Screenshots, Konto-Metadaten
• Betroffene Personen: Kundenadministratoren und Endbenutzer
• Zweck: Support und Fehlerbehebung bei Services
• Rolle: Auftragsverarbeiter für von Kunden bereitgestellte personenbezogene Daten von Endbenutzern, Verantwortlicher für die Verwaltung direkter Geschäftskontakte, wenn diese für Kontokommunikation verwendet werden
• Aufbewahrung: definierte Aufbewahrungsfrist für Support und Audit
• Empfänger: internes Supportpersonal, Ticketing-Anbieter, genehmigte Unterauftragsverarbeiter
• Sicherheitsklassifizierung: Vertraulich, personenbezogene Daten

Die Richtlinie zu Datenschutz und Privatsphäre für KMU unterstützt diese Grundlage:

„Die Datenschutzkoordinatorin bzw. der Datenschutzkoordinator muss ein Register aller Verarbeitungstätigkeiten für personenbezogene Daten führen, einschließlich Datenkategorien, Zweck, Rechtsgrundlage und Aufbewahrungsfristen.“

Aus Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.2.1.

Schritt 2: Lieferant in REG08 klassifizieren

Wenn Marias Unternehmen Auftragsverarbeiter für Kundendaten ist, ist der Ticketing-Anbieter für diese Kundendaten typischerweise Unterauftragsverarbeiter. REG08 sollte Beziehungstyp, Vertragsstatus, Datenkategorien, Datenstandorte, nachgelagerte Unterauftragsverarbeiter und Vertrauensnachweise erfassen.

Schritt 3: Anwendbarkeit in REG03 dokumentieren

Die unternehmensweite Richtlinie zu Datenschutz und Privatsphäre ergänzt einen Auslöser für hohes Risiko:

„Bedrohungsmodellierung und Datenschutz-Folgenabschätzungen (DSFAs) sind für Verarbeitungssysteme mit hohem Risiko verpflichtend.“

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

Die Richtlinie zu Datenschutz und Privatsphäre für KMU verankert die Gestaltungserwartung:

„Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen muss in allen neuen Systemen und Services durchgesetzt werden.“

Aus Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.1.

Schritt 4: Mit ISO/IEC 27001:2022-Kontrollen abstimmen

Wenn die Supportplattform im ISMS-Geltungsbereich liegt, sollte die SoA unterstützende ISO/IEC 27002:2022-Kontrollen wie Lieferantenbeziehungen, Lieferantenvereinbarungen, IKT-Lieferkettenmanagement, Zugriffskontrolle, Identitätsmanagement, Informationsübertragung, Cloud-Services, Vorfallmanagement, Protokollierung und Überwachung, Änderungsmanagement, rechtliche Compliance und Datenschutz enthalten.

Zenith Blueprint, Risikomanagementphase, Schritt 14: Richtlinien zur Risikobehandlung und regulatorische Querverweise, empfiehlt, GDPR, NIS2 und DORA mit Richtlinien und Kontrollen querzuverweisen, insbesondere für Schutz personenbezogener Daten, Vorfallreaktion, Zugriffskontrolle, Aufrechterhaltung des Geschäftsbetriebs und IKT-Drittparteienrisiko.

Das Ergebnis sind wiederverwendbare Nachweise, keine getrennten Tabellen für GDPR, DORA, NIS2 und Zertifizierung.

Was Zenith Controls zur PIMS-Anwendbarkeit beiträgt

Zenith Controls ist Clarysecs frameworkübergreifender Compliance-Leitfaden zum Verständnis der Beziehungen zwischen ISO/IEC 27001:2022- und ISO/IEC 27002:2022-Kontrollen, Auditmethoden und anderen Rahmenwerken. Es ist kein separater Kontrollsatz. Für dieses Thema sind die zentralen ISO/IEC 27002:2022-Kontrollen:

• 5.34 Datenschutz und Schutz personenbezogener Daten
• 5.19 Informationssicherheit in Lieferantenbeziehungen
• 5.20 Behandlung der Informationssicherheit in Lieferantenvereinbarungen
• 5.21 Management der Informationssicherheit in der IKT-Lieferkette
• 5.22 Überwachung, Überprüfung und Änderungsmanagement von Lieferantendiensten

Für 5.34 klassifiziert Zenith Controls die Kontrolle als präventiv, ordnet sie Vertraulichkeit, Integrität und Verfügbarkeit zu, richtet sie an Identify und Protect aus und verbindet sie mit Fähigkeiten zum Informationsschutz sowie zu Recht und Compliance.

Die GDPR-Zuordnung lautet:

„Die Umsetzung von 5.34 ist ein direkter Nachweis für die Fähigkeit einer Organisation, die Anforderungen der GDPR-Rechenschaftspflicht zu erfüllen.“

Aus Zenith Controls, Datenschutz und Schutz personenbezogener Daten, GDPR-Querverweis.

Dieser Satz ist relevant, weil er 5.34 von einer allgemeinen Datenschutzaussage in Auditnachweis überführt. Er sollte durch Inventare personenbezogener Daten, Klassifizierung, Zugriffskontrolle, Maskierung, sichere Übertragung, Cloud-Governance, DSFAs, Datenschutzhinweise, Verfahren für Betroffenenanfragen und Behandlung von Verletzungen des Schutzes personenbezogener Daten gestützt werden.

Zenith Controls verbindet Datenschutz und Schutz personenbezogener Daten außerdem mit verwandten Standards wie ISO/IEC 27018 für die Verarbeitung personenbezogener Daten in Public-Cloud-Umgebungen, ISO/IEC 29100 für Datenschutzgrundsätze und ISO/IEC 29151 für Praktiken zum Schutz personenbezogener Daten. Die Datenschutz-Governance für Lieferanten wird durch die ISO/IEC 27036-Familie für Lieferantenbeziehungen und Sicherheit der IKT-Lieferkette sowie ISO/IEC 27017 für geteilte Verantwortlichkeiten in der Cloud unterstützt.

Lieferanten- und Unterauftragsverarbeiter-Nachweise sind der Punkt, an dem Rollen zusammenlaufen

Verpflichtungen von Verantwortlichen und Auftragsverarbeitern treffen häufig an der Lieferantengrenze aufeinander.

Wenn Marias Unternehmen Verantwortlicher ist, erwartet GDPR, dass es Auftragsverarbeiter einsetzt, die hinreichende Garantien bieten. Wenn es Auftragsverarbeiter ist, erwarten Kunden, dass es Unterauftragsverarbeiter steuert, Verpflichtungen weitergibt und Vertrauensnachweise bereitstellt. Wenn es Unterauftragsverarbeiter ist, erbt es Verpflichtungen über die Kette.

Damit werden die ISO/IEC 27002:2022-Kontrollen 5.19 und 5.20 zentral für die Anwendbarkeit von ISO 27701-Kontrollen.

Für 5.19 betont Zenith Controls die Sicherheit von Lieferantenbeziehungen über Governance-, Ökosystem- und Schutzbereiche hinweg. Dies ist direkt mit 5.20 Lieferantenvereinbarungen, 5.21 IKT-Lieferkettensicherheit, 5.14 Informationsübertragung, 5.36 Einhaltung von Richtlinien, Regeln und Standards für Informationssicherheit sowie 5.10 Zulässige Nutzung von Informationen und anderen zugehörigen Assets verbunden.

Für 5.20 betont Zenith Controls die vertragliche Formalisierung. Lieferantenvereinbarungen sollten Vertraulichkeit, Meldung von Verletzungen des Schutzes personenbezogener Daten, Auditrechte, Genehmigung von Unterauftragnehmern, sichere Übertragung, Datenrückgabe oder -vernichtung, Compliance-Verpflichtungen und Überwachung definieren.

Zenith Blueprint, Phase „Controls in Action“, Schritt 23: Organisatorische Maßnahmen, gibt eine praktische Anweisung für Unterauftragsverarbeiter:

„Ermitteln Sie für jeden kritischen Lieferanten, ob er Unterauftragnehmer (Unterauftragsverarbeiter) einsetzt, die auf Ihre Daten oder Systeme zugreifen können. Dokumentieren Sie, wie Ihre Anforderungen an die Informationssicherheit an diese Parteien weitergegeben werden, entweder über die Vertragsbedingungen Ihres Lieferanten oder über Ihre eigenen direkten Klauseln.“

Auditoren bleiben nicht bei „Haben Sie einen Auftragsverarbeitungsvertrag?“ stehen. Sie fragen, ob Lieferanten Auftragsverarbeiter, Unterauftragsverarbeiter, unabhängige Verantwortliche oder gemeinsam Verantwortliche sind, ob Genehmigungen für Unterauftragsverarbeiter dokumentiert sind, ob Verpflichtungen weitergegeben werden, ob Meldefristen für Verletzungen des Schutzes personenbezogener Daten klar sind, ob Überwachung stattfindet und ob Nachweise zur Löschung oder Rückgabe eingeholt werden können.

Übergreifende Compliance ohne doppelte Kontrollsysteme

Die Anwendbarkeit von ISO 27701-Kontrollen wird wertvoller, wenn sie Vertrauensgespräche zu GDPR, NIS2, DORA, NIST CSF 2.0 und COBIT 2019 aus derselben Nachweisbasis unterstützt.

GDPR treibt rollenbasierte Datenschutzpflichten: Rechenschaftspflicht des Verantwortlichen, Pflichten des Auftragsverarbeiters, Rechtsgrundlage, Betroffenenrechte, Sicherheit, Governance für Verletzungen des Schutzes personenbezogener Daten und Verträge.

NIS2 ergänzt Cybersicherheitsrisikomanagement, Vorfallbehandlung, Aufrechterhaltung des Geschäftsbetriebs, Lieferkettensicherheit, sichere Entwicklung, Schwachstellenbehandlung, Zugriffskontrolle, Kryptografie, MFA und Schulung für wesentliche und wichtige Einrichtungen.

DORA gilt ab dem 17. Januar 2025 für Finanzunternehmen im Geltungsbereich und verlangt Management von IKT-Risiken, Vorfallmeldung, Resilienztests und Management von IKT-Drittparteienrisiken. SaaS- und IKT-Anbieter, die Finanzunternehmen bedienen, werden häufig aufgefordert, Datenschutz-, Sicherheits-, Resilienz-, Auditrecht- und Exit-Nachweise in einem gemeinsamen Vertrauenspaket bereitzustellen.

NIST CSF 2.0 stellt über die GOVERN Function eine Governance-Ebene bereit, einschließlich gesetzlicher, regulatorischer, vertraglicher und datenschutzbezogener Verpflichtungen, Rollen, Risikobereitschaft, Richtlinienaufsicht und Lieferketten-Governance.

COBIT 2019 ergänzt Governance- und Managementpraktiken. Für Datenschutz ordnet Zenith Controls 5.34 COBIT DSS06.02, DSS06.08 und APO13.01 zu. Für Lieferanten unterstützen 5.19 und 5.20 Praktiken zu Lieferantenrisiko und Lieferantenvereinbarungen.

Der strategische Punkt ist einfach: REG03 sollte mehr sein als ein ISO 27701-Artefakt. Es sollte eine wiederverwendbare Karte zur Anwendbarkeit von Kontrollen für Kundenaudits, regulatorische Prüfungen und Vertrauensbildung auf Ebene des Leitungsorgans sein.

Wie Auditoren die Anwendbarkeit von ISO 27701-Kontrollen prüfen

Unterschiedliche Auditoren beginnen aus unterschiedlichen Blickwinkeln, laufen aber meist auf denselben Nachweispfad hinaus.

Ein ISO-Managementsystemauditor beginnt mit Geltungsbereich, interessierten Parteien, Verpflichtungen, Risikobeurteilung, SoA-Abstimmung, internem Audit, Managementbewertung und kontinuierlicher Verbesserung. Er prüft, ob REG02, REG03 und die ISO/IEC 27001:2022-SoA übereinstimmen.

Ein GDPR-fokussierter Auditor oder Datenschutzbeauftragter testet die Rollenlogik. Er zieht Stichproben von Tätigkeiten, prüft Rechtsgrundlage, Datenschutzhinweise, Auftragsverarbeitungsverträge, Unterauftragsverarbeiter, DSFAs, Bearbeitung von Betroffenenanfragen, Aufbewahrung und Entscheidungen zu Verletzungen des Schutzes personenbezogener Daten.

Ein NIST-orientierter Prüfer sucht nach Governance-Ergebnissen, Risikokategorisierung, Dateninventaren, Zugriffskontrollen, Schutz ruhender Daten und Daten während der Übertragung, Überwachung, Vorfallreaktion, Lieferantenrisiko und Verbesserungsplänen.

Ein COBIT 2019- oder ISACA-Auditor betrachtet Governance-Verantwortung, Prozessfähigkeit, Kontrolldesign und operative Wirksamkeit. Er prüft, ob Datenschutzkontrollen in Beschaffung, Änderungsmanagement, Vorfallmanagement und Lieferantenüberwachung eingebettet sind.

Für 5.34 beschreibt Zenith Controls, dass Auditoren Datenschutzrichtlinien, Dateninventare, DSFAs, Schulungsprotokolle, technische Schutzmaßnahmen, Stichproben zu Betroffenenanfragen, Datenschutzvorfälle und Nachweise zu Datenschutz durch Technikgestaltung prüfen. Für 5.19 und 5.20 fordern Auditoren Lieferanteninventare, Risikoklassifizierungen, Due-Diligence-Aufzeichnungen, Verträge, Bedingungen zu Verletzungen des Schutzes personenbezogener Daten, Auditrechte, Genehmigungen von Unterauftragnehmern, Exit-Nachweise und den Nachweis, dass Lieferantenberichte überprüft werden.

Die Unterscheidung ist entscheidend. Auditbereitschaft bedeutet nicht: „Wir haben eine Klausel.“ Auditbereitschaft bedeutet: „Wir haben die Klausel genutzt, sie überwacht, Nachweise geprüft und gehandelt, als sich das Risiko geändert hat.“

Häufige Fehler bei der Anwendbarkeit für Verantwortliche und Auftragsverarbeiter

Clarysec sieht regelmäßig fünf vermeidbare Fehler.

Erstens klassifizieren Organisationen das gesamte Unternehmen als eine einzige GDPR-Rolle. Das funktioniert nicht für SaaS, FinTech, HR-Tech, HealthTech, Managed Services oder Cloud-Anbieter mit gemischten Datenflüssen.

Zweitens behandeln sie ISO 27701-Kontrollen ohne Rollenbegründung als universell anwendbar. Das führt zu aufgeblähten Nachweisanforderungen und schwachen Ausschlüssen.

Drittens schließen sie Kontrollen aus, ohne zu dokumentieren, warum. In der ISO/IEC 27001:2022-SoA-Logik und der PIMS-Anwendbarkeitslogik müssen Ausschlüsse bewusst, begründet und durch Geltungsbereich, Rolle, Risiko oder rechtliche Analyse gestützt sein.

Viertens vergessen sie Unterauftragsverarbeiter. Die Vertrauenskette eines Auftragsverarbeiters ist nur so stark wie seine nachgelagerte Kette. Register der Unterauftragsverarbeiter, Genehmigungsmechanismen, weiterzugebende Klauseln und Löschungsnachweise sind wesentlich.

Fünftens verknüpfen sie Datenschutzkontrollen nicht mit dem Sicherheitsbetrieb. Datenschutz durch Technikgestaltung ist nicht nur eine DSFA-Vorlage. Er sollte Zugriffskontrollen, Protokollierung, sichere Entwicklung, Cloud-Konfiguration, Lieferanten-Due-Diligence, Automatisierung der Aufbewahrung und Vorfallreaktion beeinflussen.

Clarysec-bereite Checkliste für die REG03-Anwendbarkeit von Kontrollen

Nutzen Sie diese Checkliste vor ISO 27701-Bereitschaftsprüfungen, GDPR-Vertrauensprüfungen durch Kunden oder DORA-getriebenen Lieferantenbewertungen:

• REG02 für jede Verarbeitungstätigkeit mit personenbezogenen Daten erstellen oder aktualisieren.
• Die PIMS-Rolle für jede Tätigkeit klassifizieren, bevor die Verarbeitung beginnt.
• Jede Drittparteienbeziehung in REG08 vor Vertragsfreigabe oder Verarbeitung personenbezogener Daten klassifizieren.
• Verpflichtungen auf Basis der Rolle identifizieren: Verantwortlicher, Auftragsverarbeiter, gemeinsamer Verantwortlicher oder Unterauftragsverarbeiter.
• Anwendbare PIMS-Kontrollen in REG03 mit verantwortlicher Person, Umsetzungsstatus und Nachweisen erfassen.
• Ausgeschlossene Kontrollen mit klarer Begründung dokumentieren.
• REG03-Entscheidungen mit Risiken, rechtlichen Verpflichtungen, Verträgen oder Begründungen zum Geltungsbereich verknüpfen.
• REG03 mit der ISO/IEC 27001:2022-SoA abstimmen, wenn Sicherheitskontrollen Datenschutz unterstützen.
• Datenschutzkontrollen ISO/IEC 27002:2022 5.34 zuordnen, wenn Schutz personenbezogener Daten erforderlich ist.
• Anforderungen an Lieferanten und Unterauftragsverarbeiter 5.19, 5.20, 5.21 und 5.22 zuordnen.
• Relevante Verweise für übergreifende Compliance zu GDPR, NIS2, DORA, NIST CSF 2.0 und COBIT 2019 ergänzen.
• Den Nachweispfad mit einer internen Audit-Stichprobe vor der Prüfung der Zertifizierungsbereitschaft testen.
• Genehmigung der obersten Leitung einholen, wenn sich PIMS-Geltungsbereich oder Anwendbarkeit von Kontrollen ändern.

Die Richtlinie zum Datenschutz-Informationsmanagementsystem schließt diesen Governance-Kreislauf:

„[Beide] Die oberste Leitung MUSS Änderungen am PIMS-Geltungsbereich und an der Anwendbarkeit von Kontrollen in REG01 und REG03 genehmigen, bevor Änderungen am Geltungsbereich der Zertifizierung eingereicht werden.“

Aus Abschnitt „PIMS-Governance“, Richtlinienklausel 6.1.3.

Das ist die Art von Governance-Nachweisen, denen Auditoren vertrauen.

GDPR-Rollenentscheidungen in belastbare Nachweise überführen

Die Anwendbarkeit von ISO 27701-Kontrollen ist der Punkt, an dem GDPR-Rollentheorie operative Realität wird. Ein Verantwortlicher benötigt Nachweise für Rechtsgrundlage, Transparenz, Aufbewahrung, DSFAs, Bearbeitung von Rechten und Aufsicht über Auftragsverarbeiter. Ein Auftragsverarbeiter benötigt Nachweise für dokumentierte Weisungen, Vertraulichkeit, Sicherheit, Unterstützung, Unterauftragsverarbeiter, Unterstützung bei Verletzungen des Schutzes personenbezogener Daten und Löschung. Ein gemeinsamer Verantwortlicher benötigt eine transparente Verantwortlichkeitsvereinbarung. Ein Unterauftragsverarbeiter benötigt weiterzugebende Verpflichtungen und Unterstützung bei der Vertrauensbildung.

Clarysec unterstützt Organisationen beim Aufbau dieser Nachweisebene durch:

• REG02-Verarbeitungsinventar und Struktur zur Rechtsgrundlage.
• REG03-Datensätze zur Anwendbarkeit von PIMS-Kontrollen.
• REG08-Klassifizierung datenschutzbezogener Drittparteienbeziehungen.
• Abstimmung mit der ISO/IEC 27001:2022-SoA.
• Richtlinienklauseln, die Verantwortliche, Zeitpunkte und Genehmigungsanforderungen zuweisen.
• Abbildung übergreifender Compliance über Zenith Controls.
• Umsetzungsreihenfolge über Zenith Blueprint.

Wenn Ihre Organisation sich auf ISO 27701-PIMS-Bereitschaft, GDPR-Vertrauensprüfungen durch Kunden, DORA-Lieferantenprüfungen oder an NIS2 ausgerichtete Sicherheitsgovernance vorbereitet, beginnen Sie mit einer risikoreichen Verarbeitungstätigkeit. Klassifizieren Sie die Rolle. Ordnen Sie die anwendbaren Kontrollen zu. Verknüpfen Sie die Nachweise. Wiederholen Sie den Prozess, bis Ihr Datenschutzprogramm nicht nur auf dem Papier konform, sondern im Audit erklärbar ist.

Laden Sie die Clarysec-PIMS-Richtliniensuite herunter, erkunden Sie Zenith Blueprint, oder buchen Sie eine Clarysec-Bereitschaftsbewertung, um Entscheidungen zu Verantwortlichen, Auftragsverarbeitern, gemeinsam Verantwortlichen und Unterauftragsverarbeitern in ein zertifizierungsfähiges Datenschutz-Nachweisregister zu überführen.