RoPA und Datenflussabbildung für GDPR, NIS2 und DORA

Es ist 09:10 Uhr an einem Dienstag. CISO, DPO, Beschaffungsleitung und Betriebsleitung sitzen in derselben Videokonferenz, sehen aber nicht dieselben Nachweise.

Der DPO verfügt über ein Verzeichnis von Verarbeitungstätigkeiten, kurz RoPA, das Kunden-Onboarding, Gehaltsabrechnung, Support-Tickets und Marketing-Analysen auflistet. Der CISO hat ein Cloud-Asset-Inventar. Die Beschaffung hat Lieferantenverträge. Der Betrieb hat eine Tabelle zur Betriebskontinuität. Die Finanzabteilung hat das DORA-Informationsregister. Niemand kann die grundlegendste verknüpfte Frage der Aufsichtsbehörde beantworten:

Wenn dieser Payment-Onboarding-Dienst ausfällt, welche Systeme, Lieferanten, Datenkategorien, Unterauftragsverarbeiter, grenzüberschreitenden Datenübermittlungen und kritischen Geschäftsfunktionen sind betroffen?

Diese Frage ist der eigentliche Compliance-Test für 2026.

GDPR verlangt weiterhin nachvollziehbare Aufzeichnungen nach Article 30. NIS2 hat Cybersicherheit für wesentliche und wichtige Einrichtungen zu einer Frage der Rechenschaftspflicht des Leitungsorgans gemacht. DORA verlangt von Finanzunternehmen Nachweise zu IKT-Abhängigkeiten, kritischen oder wichtigen Funktionen, IKT-Drittparteienvereinbarungen, Vorfallklassifizierung und Resilienztests. ISO/IEC 27001:2022 stellt die Managementsystemstruktur bereit, um all dies zusammenzuführen – aber nur, wenn RoPA und Datenflussabbildung als lebende Governance-Nachweise behandelt werden und nicht als Tabellen des Datenschutzteams.

Bei Clarysec sehen wir dasselbe Muster in schnell wachsenden SaaS-, Fintech-, Cloud-, MSP- und B2B-Technologieunternehmen. Sie haben ausreichend Dokumentation, um einen Fragebogen zu beantworten, aber nicht genügend verknüpfte Nachweise, um eine aufsichtsbehördliche Überprüfung, einen Cybervorfall, einen Lieferantenausfall oder ein internes Audit zu bestehen. Das Problem ist selten ein Mangel an Informationen. Es ist ein Mangel an Verknüpfung.

Die Lösung besteht darin, RoPA und Datenflussabbildung zur gemeinsamen Nachweisebene für Datenschutz, Cyberresilienz, Lieferantenmanagement, Cloud-Governance und Betriebskontinuität zu machen.

Warum RoPA und Datenflussabbildung 2026 zu einem Governance-Thema wurden

RoPA wurde früher als Datenschutzartefakt betrachtet. Datenflussabbildungen wurden häufig im Rahmen einer DPIA, Cloud-Migration oder Sicherheitsarchitekturprüfung erstellt und anschließend nicht mehr gepflegt. Dieser Ansatz funktioniert nicht mehr.

GDPR gilt breit für die Verarbeitung personenbezogener Daten im Kontext einer Niederlassung in der EU sowie für viele Verantwortliche oder Auftragsverarbeiter außerhalb der EU, die Personen in der EU Waren oder Dienstleistungen anbieten oder deren Verhalten beobachten. Personenbezogene Daten umfassen Informationen, die sich auf eine identifizierte oder identifizierbare Person beziehen. Verarbeitung umfasst Erhebung, Speicherung, Nutzung, Offenlegung, Einschränkung, Löschung und Vernichtung. Ein Verantwortlicher legt Zwecke und Mittel fest, während ein Auftragsverarbeiter im Auftrag eines Verantwortlichen handelt.

Ein RoPA ist daher nicht nur eine Liste von Datenbanken. Es ist eine Aufzeichnung von Geschäftszwecken, Datenkategorien, Rollen, Empfängern, Aufbewahrungsfristen, Schutzmaßnahmen und internationalen Abhängigkeiten.

NIS2 ergänzt eine Service-Resilienz-Perspektive. Sie bringt viele mittlere und größere Organisationen in hochkritischen und anderen kritischen Sektoren in den Geltungsbereich, darunter digitale Infrastruktur, Cloud-Computing-Dienste, Rechenzentrumsdienste, Content Delivery Networks, Vertrauensdiensteanbieter, Anbieter öffentlicher elektronischer Kommunikationsdienste, Managed Service Provider und Managed Security Service Provider. Annex I umfasst außerdem Banken und Finanzmarktinfrastrukturen. Einige Einrichtungen können unabhängig von ihrer Größe erfasst sein, darunter bestimmte DNS-, TLD-, Vertrauensdienste- und öffentliche Kommunikationsanbieter sowie Einrichtungen, deren Störung die öffentliche Sicherheit, die öffentliche Gesundheit, systemische Risiken oder kritische gesellschaftliche und wirtschaftliche Tätigkeiten erheblich beeinträchtigen könnte.

NIS2 Article 21 verlangt verhältnismäßige technische, operative und organisatorische Maßnahmen für Netz- und Informationssysteme, die für den Betrieb oder die Leistungserbringung genutzt werden. Die Mindestbereiche umfassen Risikoanalyse, Sicherheitsrichtlinien, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Betriebskontinuität, Sicherheit der Lieferkette, sichere Entwicklung, Wirksamkeitsbewertung, Cyberhygiene, Kryptografie, Personalsicherheit, Zugriffskontrolle, Asset-Management und Authentifizierung.

Für eine NIS2-Einrichtung ist ein RoPA ohne Sicht auf Dienstabhängigkeiten unvollständig. Ein erheblicher Vorfall muss hinsichtlich Dienstauswirkungen, Betriebsunterbrechung, betroffener Empfänger, Lieferanten und grenzüberschreitender Auswirkungen verstanden werden.

DORA schärft denselben Punkt für Finanzunternehmen. DORA gilt seit dem 17. Januar 2025 und legt einheitliche Anforderungen an das Management von IKT-Risiken, die Meldung schwerwiegender IKT-bezogener Vorfälle, Tests der digitalen operationalen Resilienz, den Austausch von Informationen über Cyberbedrohungen und Schwachstellen, IKT-Drittparteienrisiken sowie vertragliche Vereinbarungen mit IKT-Drittdienstleistern fest. DORA definiert IKT-Dienstleistungen breit als digitale Dienste und Datendienste, die fortlaufend über IKT-Systeme bereitgestellt werden. Eine kritische oder wichtige Funktion ist eine Funktion, deren Störung die finanzielle Leistungsfähigkeit, die Dienstkontinuität oder Compliance-Verpflichtungen wesentlich beeinträchtigen würde.

Für Finanzunternehmen, die auch nach der nationalen Umsetzung von NIS2 erfasst sind, wird DORA als sektorspezifischer Rechtsakt der Union für gleichwertige Anforderungen an IKT-Risiken, Vorfallmeldungen, Tests, Informationsaustausch und Drittparteienrisiken behandelt. In der Praxis kann ein Fintech nicht einen Nachweissatz für Datenschutz, einen zweiten für DORA und einen dritten für NIS2 aufbauen. Es benötigt eine einheitliche, abhängigkeitsbewusste Ebene für Data Governance.

Diese Ebene besteht aus RoPA plus Datenflussabbildung.

ISO/IEC 27001:2022 ist das Rückgrat

ISO/IEC 27001:2022 ist für diese Art von Integration ausgelegt. Die Norm etabliert ein skalierbares Informationssicherheits-Managementsystem, kurz ISMS, das darauf ausgerichtet ist, Vertraulichkeit, Integrität und Verfügbarkeit durch Risikomanagement zu wahren. Die Norm soll in organisatorische Prozesse integriert und an Bedarf, Größe und Struktur der Organisation skaliert werden.

Der Ausgangspunkt ist nicht das Diagrammwerkzeug. Es ist der Geltungsbereich.

ISO/IEC 27001:2022-Klauseln 4.1 bis 4.4 verlangen, dass die Organisation Kontext, interessierte Parteien, ISMS-Geltungsbereich und zusammenwirkende Prozesse definiert. Der Geltungsbereich muss gesetzliche, regulatorische und vertragliche Verpflichtungen sowie Schnittstellen und Abhängigkeiten zwischen internen Tätigkeiten und von anderen Organisationen durchgeführten Tätigkeiten berücksichtigen. Für RoPA und Datenflussabbildung bedeutet dies, dass der ISMS-Geltungsbereich ausgelagerte Cloud-Plattformen, Zahlungsdienstleister, Identitätsanbieter, Support-Werkzeuge, Managed-Security-Anbieter und geschäftskritische SaaS-Integrationen ausdrücklich erfassen sollte.

Klauseln 5.1 bis 5.3 machen die Leitung verantwortlich für Richtlinien, Ressourcen, Rollenzuweisung und Berichterstattung. Dies entspricht der Richtung von NIS2 Article 20, der verlangt, dass Leitungsorgane Cybersicherheits-Risikomanagementmaßnahmen genehmigen, deren Umsetzung überwachen und an Schulungen teilnehmen. Es steht außerdem im Einklang mit DORA Article 5, der dem Leitungsorgan die letztendliche Verantwortung für IKT-Risiken und die Aufsicht über Richtlinien, Resilienzstrategie, Kontinuitätspläne, Auditpläne, IKT-Drittparteienservices und Meldekanäle für schwerwiegende Vorfälle zuweist.

Klauseln 6.1.1 bis 6.1.3 liefern den Planungsmechanismus: Risiken für Vertraulichkeit, Integrität und Verfügbarkeit identifizieren, Risikoverantwortliche zuweisen, Auswirkungen und Eintrittswahrscheinlichkeit analysieren, Behandlungsoptionen auswählen, Kontrollen mit Annex A abgleichen, die Erklärung zur Anwendbarkeit erstellen und die Genehmigung des Risikoverantwortlichen einholen.

An dieser Stelle wird RoPA operativ. Jede Verarbeitungstätigkeit und jeder Datenfluss sollte mit Risiken, Kontrollen, Lieferanten, Assets und kritischen Diensten verknüpft werden. Geschieht dies nicht, bleibt RoPA ein Datenschutzinventar, das Incident Response, Resilienztests oder Entscheidungen zu Lieferantenrisiken nicht unterstützen kann.

Clarysecs Zenith Blueprint: 30-Schritte-Roadmap für Auditoren macht dies in der Phase Risikomanagement, Schritt 9, Identifizierung von Assets, Bedrohungen und Schwachstellen, praktisch umsetzbar:

Erfassen Sie für jedes Asset wesentliche Angaben: Name/Beschreibung, Verantwortlicher, Standort und Klassifizierung (Sensitivität). Ein Asset könnte beispielsweise „Kundendatenbank – verantwortlich: IT-Abteilung – gehostet auf AWS – enthält personenbezogene und Finanzdaten (hohe Sensitivität)“ sein.

Derselbe Schritt 9 ergänzt die zentrale Erkenntnis zur Compliance: Assets mit personenbezogenen Daten sollten für GDPR-Relevanz gekennzeichnet werden, und Assets für kritische Dienste sollten auf eine mögliche NIS2-Anwendbarkeit hingewiesen werden, sofern die Organisation in einem regulierten Sektor tätig ist. Das ist die Brücke zwischen RoPA, Asset-Inventar und Abbildung kritischer Dienstabhängigkeiten.

Was ein auditreifes RoPA enthalten muss

Ein belastbares RoPA muss nicht kompliziert sein, aber es muss verknüpft sein.

GDPR Article 5 verlangt, dass personenbezogene Daten rechtmäßig, nach Treu und Glauben und transparent verarbeitet, für festgelegte und legitime Zwecke erhoben, auf das notwendige Maß beschränkt, sachlich richtig gehalten, nur so lange wie erforderlich aufbewahrt und durch angemessene technische und organisatorische Maßnahmen geschützt werden. Article 5(2) verlangt, dass der Verantwortliche für die Einhaltung verantwortlich ist und diese nachweisen kann.

Article 6 verlangt eine Rechtsgrundlage, etwa Einwilligung, Vertragserforderlichkeit, rechtliche Verpflichtung, lebenswichtige Interessen, Aufgabe im öffentlichen Interesse oder berechtigte Interessen. Erfolgt die Verarbeitung zu einem neuen Zweck, muss die Vereinbarkeit anhand des ursprünglichen und des neuen Zwecks, des Erhebungskontexts, der Sensitivität, der Folgen für betroffene Personen und von Schutzmaßnahmen wie Verschlüsselung oder Pseudonymisierung bewertet werden. Article 9 ergänzt strengere Regeln für besondere Kategorien personenbezogener Daten, einschließlich Gesundheitsdaten, biometrischer Daten zur eindeutigen Identifizierung und anderer sensibler Kategorien.

Clarysecs Richtlinienset für KMU überführt dies in eine operative Anforderung. Die Richtlinie zu Datenschutz und Privatsphäre - KMU legt fest:

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

Dies stammt aus dem Abschnitt Governance-Anforderungen, Klausel 5.2.1. Für größere Organisationen weist Clarysecs Richtlinie zu Datenschutz und Privatsphäre die Verantwortung direkt zu:

Führt das Verzeichnis von Verarbeitungstätigkeiten (RoPA) gemäß GDPR Article 30.

Diese Formulierung stammt aus Rollen und Verantwortlichkeiten, Klausel 4.2.2. Die praktische Aussage ist einfach: Die Verantwortung für das RoPA muss zugewiesen sein. Es darf keine verwaiste Compliance-Tabelle sein.

Ein RoPA, das für 2026 geeignet ist, sollte die folgenden Felder enthalten.

Die letzten Zeilen führen RoPA aus der Datenschutzdokumentation in den Bereich der Nachweise zur Cyberresilienz. Ohne Systeme, Lieferanten, Standorte, Kritikalität und Kontrollen kann ein RoPA zwar eine enge Article 30-Checkliste erfüllen, scheitert aber, sobald ein Vorfall, Ausfall oder eine aufsichtsbehördliche Überprüfung eine Auswirkungsanalyse verlangt.

Datenflussabbildung verbindet Datenschutz, Cloud und kritische Dienste

Wenn RoPA beantwortet, „welche Verarbeitung besteht und warum“, beantwortet eine Datenflussabbildung, „wohin Daten fließen, wer sie berührt, wodurch sie geschützt werden und was ausfällt, wenn der Fluss stoppt“.

Clarysecs Richtlinie zur Datenmaskierung und Pseudonymisierung - KMU formuliert die Anforderung eindeutig:

Eine Datenflussabbildung muss erstellt werden.

Dies stammt aus Governance-Anforderungen, Klausel 5.1.1.1. Die Enterprise-Version, Richtlinie zur Datenmaskierung und Pseudonymisierung, erweitert die Erwartung in Klausel 5.2.1:

Führen Sie ein aktuelles Inventar der Systeme und Datenflüsse, die sensible Daten betreffen.

Klausel 5.2.2 ergänzt:

Bilden Sie ab, wo und wie Daten über Umgebungen hinweg transformiert, weitergegeben oder abgerufen werden.

Auditoren und Aufsichtsbehörden suchen keine künstlerischen Diagramme. Sie wollen Transformationen, Zugriffspfade, Weitergaben, Umgebungen und Schutzmaßnahmen verstehen.

Im Zenith Blueprint, Phase „Kontrollen in der Praxis“, Schritt 22, Organisatorische Maßnahmen 5.1 bis 5.18, erläutert die Leitlinie zur Informationsübertragung, dass Organisationen zulässige Übertragungsmethoden definieren, sie an der Klassifizierung ausrichten und sicherstellen müssen, dass die Parteien ihre Rollen und Verpflichtungen verstehen. Beispiele sind verschlüsselte E-Mail, sichere Portale, SFTP, APIs und physische Übergabe mit Verschlüsselung. Außerdem wird darauf hingewiesen, dass personenbezogene Daten, die grenzüberschreitend übermittelt werden, Datenschutz- und rechtlichen Verpflichtungen entsprechen müssen – nicht nur internen Präferenzen.

Derselbe Schritt verbindet Informationsübertragung mit Klassifizierung und Kennzeichnung, Verhinderung von Datenabfluss, Lieferantenbeziehungen und Kryptografie. Daraus entsteht ein praktikables Modell für die Datenflussabbildung:

1. Identifizieren Sie das Quellsystem, z. B. CRM, Zahlungsplattform, HRIS oder Support-Desk.
2. Identifizieren Sie die Datenkategorie, einschließlich personenbezogener Daten, Finanzdaten, Mitarbeiterdaten, besonderer Kategorien personenbezogener Daten oder Zugangsdaten.
3. Identifizieren Sie die Übertragungsmethode, z. B. API, SFTP, E-Mail, sicheres Portal, manueller Export oder Backup-Replikation.
4. Identifizieren Sie das Ziel, einschließlich internem System, Cloud-Dienst, Lieferant, Unterauftragsverarbeiter, Data Warehouse oder Archiv.
5. Identifizieren Sie den Schutz, z. B. Verschlüsselung, Pseudonymisierung, Zugriffskontrolle, Protokollierung, DLP oder vertragliche Beschränkung.
6. Identifizieren Sie die Abhängigkeit, einschließlich der Frage, ob der Datenfluss eine kritische Geschäftsfunktion, eine kritische oder wichtige Funktion, einen wesentlichen Dienst oder eine Vorfallmeldepflicht unterstützt.

Drei Maßnahmen aus ISO/IEC 27001:2022 Annex A sind hier besonders wichtig. ISO/IEC 27002:2022 stellt die Umsetzungsleitlinien für diese Maßnahmen bereit:

Clarysecs Zenith Controls: Der Cross-Compliance-Leitfaden identifiziert 5.9, 5.14 und 5.34 als themenbezogene Maßnahmen für diese Governance-Ebene. Behandeln Sie sie als Ankerkontrollen und verbinden Sie sie anschließend über Ihre Erklärung zur Anwendbarkeit mit Lieferanten-, Cloud-, Vorfall-, Kontinuitäts-, Protokollierungs-, Zugriffs- und Kryptografiekontrollen.

Warum NIS2 und DORA mehr benötigen als ein Datenschutzregister

Ein häufiger Fehler besteht darin, ein RoPA aufzubauen, das unter GDPR formal korrekt ist, aber für NIS2 oder DORA unbrauchbar bleibt. Der Unterschied liegt in der Servicekritikalität.

NIS2 Article 23 verlangt, dass wesentliche und wichtige Einrichtungen erhebliche Vorfälle unverzüglich melden. Das Meldeverfahren umfasst eine Frühwarnung innerhalb von 24 Stunden, eine Vorfallmeldung innerhalb von 72 Stunden und einen Abschlussbericht innerhalb eines Monats. Erhebliche Vorfälle werden anhand schwerwiegender Betriebsunterbrechungen, finanzieller Verluste oder materieller oder immaterieller Schäden für andere natürliche oder juristische Personen bewertet. Diese Bewertung hängt davon ab, zu wissen, welche Dienste, Empfänger, Länder, Systeme und Lieferanten betroffen sind.

DORA Article 17 verlangt von Finanzunternehmen, einen Prozess für das Management IKT-bezogener Vorfälle zu definieren und umzusetzen, der Vorfälle erkennt, steuert und meldet, Vorfälle und erhebliche Cyberbedrohungen aufzeichnet, Ursachen identifiziert, Frühwarnindikatoren festlegt, Vorfälle nach Schweregrad und Kritikalität betroffener Dienste klassifiziert, Rollen zuweist sowie Kommunikations- und Eskalationsverfahren schafft. Article 18 verlangt eine Klassifizierung anhand betroffener Kunden oder Gegenparteien und Transaktionen, Dauer und Ausfallzeit, geografischer Ausbreitung, Datenverlust mit Auswirkungen auf Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit, Kritikalität betroffener Dienste und wirtschaftlicher Auswirkungen.

Sie können einen Vorfall nicht schnell klassifizieren, wenn Sie den Datenfluss und die Abhängigkeitskette nicht kennen.

Clarysecs Richtlinie zur Betriebskontinuität und Disaster Recovery - KMU verweist auf das Nachweisfeld, das Organisationen benötigen:

priorisierte Dienste und Systeme (kritische Geschäftsfunktionen)

Dies stammt aus Governance-Anforderungen, Klausel 5.2.1.2. Die Enterprise-Richtlinie zur Betriebskontinuität und Disaster Recovery ergänzt die Abhängigkeitsdimension in Klausel 5.2.4:

Kritische Abhängigkeiten (Systeme, Lieferanten, Personal)

Für DORA-regulierte Organisationen muss dies mit kritischen oder wichtigen Funktionen, IKT-Dienstleistungen, vertraglichen Vereinbarungen und Exit-Strategien abgestimmt sein. DORA Article 28 verlangt, dass IKT-Drittparteienrisiken als Teil des IKT-Risikomanagementrahmens gesteuert werden. Er schreibt ein Register der vertraglichen Vereinbarungen für IKT-Dienstleistungen vor, verlangt vorvertragliche Due Diligence und die Bewertung von Kritikalität, Konzentrationsrisiko, Eignung und Interessenkonflikten sowie Exit-Strategien für IKT-Dienstleistungen, die kritische oder wichtige Funktionen unterstützen.

DORA Article 30 legt Mindestinhalte von IKT-Verträgen fest, darunter Leistungsbeschreibungen, Bedingungen für Unterbeauftragung, Datenverarbeitungs- und Speicherorte, Datenschutz, Zugriff, Wiederherstellung und Rückgabe von Daten, Service Levels, Unterstützung bei Vorfällen, Zusammenarbeit mit Behörden, Kündigungsrechte, Auditrechte sowie Übergangs- oder Exit-Regelungen.

Ein RoPA, das Lieferanten, Standorte, Übertragungsmethoden, Kritikalität und Exit-Abhängigkeiten nicht identifiziert, unterstützt keine DORA-Nachweise.

Lieferanten-, Cloud- und Unterauftragsverarbeiter-Mapping ist die Stelle, an der Nachweise häufig brechen

In realen Audits treten RoPA-Schwächen häufig als Lieferantenschwächen zutage. Die Verarbeitungstätigkeit lautet „Kundensupport“. Die Datenflussabbildung lautet „Support-Plattform“. Aber niemand kann Hosting-Region, KI-Transkriptions-Add-on, Analyse-Unterauftragsverarbeiter, Aufbewahrung von Ticket-Anhängen, Modell für Administrationszugriff oder Exit-Verfahren benennen.

Clarysecs KMU-Lieferantenrichtlinie schafft die operativen Mindestnachweise. Die Richtlinie zur Lieferanten- und Drittparteiensicherheit - KMU legt fest:

Ein Lieferantenregister muss vom administrativen Kontakt oder Beschaffungskontakt geführt und aktualisiert werden. Es muss Folgendes enthalten:

Dies stammt aus Governance-Anforderungen, Klausel 5.4. Die Cloud-Richtlinie ergänzt eine separate Inventaranforderung. Die Richtlinie zur Nutzung von Cloud-Diensten - KMU legt fest:

Ein Register für Cloud-Dienste muss vom IT-Dienstleister oder General Manager geführt werden. Es muss Folgendes erfassen:

Dies stammt aus Governance-Anforderungen, Klausel 5.3. Für Risiken aus Lieferantenabhängigkeiten auf Unternehmensebene ist Clarysecs Richtlinie zum Management von Risiken aus Lieferantenabhängigkeiten ausdrücklicher:

Lieferantenabhängigkeitsregister: Das VMO muss ein aktuelles Register aller kritischen Lieferanten führen, einschließlich Angaben wie bereitgestellte Dienste/Produkte, ob es sich um eine Single-Source-Beziehung handelt, verfügbare alternative Lieferanten oder Ersetzbarkeit, aktuelle Vertragsbedingungen sowie eine Bewertung der Auswirkungen, falls der Lieferant ausfallen oder kompromittiert werden sollte. Das Register muss Lieferanten mit hoher Abhängigkeit eindeutig kennzeichnen (z. B. solche, für die keine schnelle Alternative besteht).

Diese Anforderung aus den Umsetzungsanforderungen, Klausel 6.1, verbindet RoPA exakt mit Lieferkettensicherheit nach NIS2 und IKT-Drittparteienrisiken nach DORA.

Der Zenith Blueprint, Phase „Kontrollen in der Praxis“, Schritt 23, Organisatorische Maßnahmen 5.19 bis 5.37, empfiehlt, eine vollständige Lieferantenliste zu erstellen, Lieferanten anhand ihres Zugriffs auf Systeme, Daten oder operative Kontrolle zu klassifizieren, Sicherheitserwartungen in Verträge aufzunehmen, Unterauftragnehmer zu prüfen, Auslöser für Lieferantenänderungen festzulegen und einen Bewertungsprozess für Cloud-Dienste aufzubauen, der Datenstandort, Zugriffsmodell, Protokollierung und Verschlüsselung abdeckt.

Das ermöglicht einem CISO, während eines Vorfalls zu beantworten: „Welcher kritische Dienst nutzt diesen Lieferanten, welche Daten wurden offengelegt, welche Kunden müssen benachrichtigt werden, welche Aufsichtsbehörde benötigt möglicherweise eine Meldung und welcher alternative Lieferant oder Exit-Pfad besteht?“

Ein Praxisbeispiel: Kunden-Onboarding in einem Fintech

Betrachten wir ein Fintech, das Onboarding für digitale Wallets anbietet. Kunden laden Ausweisdokumente hoch, biometrische Liveness-Prüfungen werden von einem Anbieter durchgeführt, Ergebnisse werden in einer Cloud-Datenbank gespeichert, und der Kundensupport kann den Verifikationsstatus in einem Ticketsystem einsehen.

Der Onboarding-Dienst kann unter DORA eine kritische oder wichtige Funktion sein, weil eine Störung die Dienstkontinuität und regulatorische Verpflichtungen wesentlich beeinträchtigt. Wenn das Unternehmen in einem NIS2-Sektor tätig ist oder relevante IKT-Dienstleistungen bereitstellt, kann er außerdem Teil der Nachweise für kritische Dienste sein.

Eine brauchbare Abbildung beginnt mit einem verknüpften Datensatz.

Ergänzen Sie nun die Nachvollziehbarkeit der Risikobehandlung nach ISO/IEC 27001:2022.

Im Zenith Blueprint, Phase Risikomanagement, Schritt 13, Risikobehandlungsplanung und Erklärung zur Anwendbarkeit, beschreibt Clarysec die SoA als Brückendokument, das Risikobeurteilung und Risikobehandlung mit tatsächlichen Kontrollen verknüpft. Es wird empfohlen, Kontrollen Risiken zuzuordnen und in Risikoregister oder SoA-Hinweisen, wo relevant, auf Vorschriften wie GDPR, NIS2 oder DORA zu verweisen.

Für das Onboarding-Beispiel könnte das Risikoszenario lauten: „Ausfall oder Kompromittierung des Identitätsprüfungsanbieters unterbricht das Onboarding und legt biometrische Identitätsdaten offen.“ Die Behandlungskontrollen könnten Lieferanten-Due-Diligence, vertragliche Vorfallbenachrichtigung, Verschlüsselung, Zugriffskontrolle, Protokollierung, Backup und Wiederherstellung, Datenminimierung, Pseudonymisierung, Überwachung, Exit-Planung und Incident-Response-Playbooks umfassen.

Der SoA-Hinweis kann festhalten, dass das Kontrollset die Rechenschaftspflicht nach GDPR, Lieferketten- und Vorfallsbereitschaft nach NIS2 Article 21 sowie IKT-Drittparteienrisiken und Resilienz kritischer Funktionen nach DORA unterstützt.

Das ist es, was Auditoren erwarten: Nachvollziehbarkeit.

Cross-Compliance-Mapping: Eine Nachweisebene, mehrere Fragen

RoPA und Datenflussabbildung sind keine getrennten Compliance-Silos. Sie unterstützen einen gemeinsamen Fragenkatalog über GDPR, NIS2, DORA, ISO/IEC 27001:2022, NIST CSF 2.0 und COBIT 2019 hinweg.

NIST CSF 2.0 ist als Ordnungsebene nützlich. Seine CSF-Profile unterstützen Ist- und Zielzustandsanalysen anhand von Eingaben wie Richtlinien, Risikoprioritäten, Business-Impact-Registern, Anforderungen, Standards, Praktiken, Werkzeugen und Arbeitsrollen. Die GOVERN-Funktion umfasst gesetzliche, regulatorische, vertragliche, Datenschutz- und Bürgerrechtsverpflichtungen, Risikoziele, Rechenschaftspflicht der Leitung, Rollen, Richtlinien, Aufsicht und Leistungsüberprüfung. Die Ergebnisse zur Lieferkette verlangen, dass Lieferanten bekannt und nach Kritikalität priorisiert sind, vertragliche Cybersicherheitsanforderungen integriert werden, vor Beziehungsaufnahme Due Diligence erfolgt, Lieferantenrisiken erfasst und überwacht werden und Lieferanten in Incident Response und Wiederherstellungsplanung einbezogen sind.

Das passt sauber zu einem Clarysec-Betriebsmodell für RoPA. RoPA liefert den Datenschutzkontext. Das Asset-Inventar liefert den technischen Kontext. Lieferanten- und Cloud-Register liefern den Drittparteienkontext. Die BIA liefert den Kritikalitätskontext. Die SoA liefert den Kontrollkontext.

Eine einzelne Maßnahme aus ISO/IEC 27001:2022 Annex A kann außerdem mehrere Rahmenwerke unterstützen. Maßnahme 5.14, Informationsübertragung, ist ein gutes Beispiel.

Das ist der Wert von Zenith Controls als Cross-Compliance-Kompass. Es hilft Organisationen zu erklären, warum eine einzelne Kontrollpraxis mehrere regulatorische und auditbezogene Erwartungen unterstützt.

Wie unterschiedliche Auditoren dieselbe Abbildung prüfen

Ein ausgereiftes RoPA und eine ausgereifte Datenflussabbildung können mehrere Auditoren zufriedenstellen, aber jeder wird anders vorgehen.

Ein Auditor für ISO/IEC 27001:2022 beginnt mit Geltungsbereich, interessierten Parteien, Risiken, dokumentierten Informationen und Kontrollauswahl. Er wird fragen, ob gesetzliche und vertragliche Anforderungen identifiziert wurden, ob personenbezogene Daten und kritische Dienste im ISMS-Geltungsbereich liegen, ob Assets Verantwortliche und Klassifizierungen haben, ob die Risikobeurteilung Vertraulichkeit, Integrität und Verfügbarkeit berücksichtigt hat und ob die SoA die anwendbaren Kontrollen begründet.

Ein GDPR-Auditor oder eine Datenschutzaufsichtsbehörde beginnt mit Rechenschaftspflicht. Geprüft wird, ob das RoPA die tatsächliche Verarbeitung abbildet, ob Zwecke und Rechtsgrundlagen dokumentiert sind, ob besondere Kategorien personenbezogener Daten identifiziert wurden, ob Aufbewahrungsfristen angewendet werden, ob Empfänger und Auftragsverarbeiter korrekt sind und ob angemessene Schutzmaßnahmen für Übermittlungen und Sicherheit bestehen.

Ein NIS2-fokussierter Auditor betrachtet Dienstauswirkungen. Er wird fragen, wie die Organisation kritische oder wichtige Dienste bestimmt, wie das Management die Risikomaßnahmen genehmigt und überwacht, wie Lieferantenschwachstellen und Risiken von Dienstleistern berücksichtigt werden, wie Kontinuität und Verfahren zum Umgang mit Informationssicherheitsvorfällen verbunden sind und ob die Organisation 24-Stunden-, 72-Stunden- und Abschlussmeldefristen mit verlässlichen Nachweisen unterstützen kann.

Ein DORA-Auditor betrachtet IKT-Risikogovernance und kritische oder wichtige Funktionen. Er wird prüfen, ob das Leitungsorgan den IKT-Risikomanagementrahmen und die Resilienzstrategie genehmigt hat, ob IKT-Drittparteienvereinbarungen registriert sind, ob Kritikalität und Konzentrationsrisiko bewertet werden, ob Verträge die erforderlichen Bedingungen enthalten, ob Tests Systeme abdecken, die kritische oder wichtige Funktionen unterstützen, und ob Vorfälle anhand betroffener Kunden, Transaktionen, Ausfallzeit, Geografie, Datenverlust, Servicekritikalität und wirtschaftlicher Auswirkungen klassifiziert werden.

Ein NIST CSF 2.0-Assessor nutzt häufig Profile. Er vergleicht Ist- und Zielergebnisse über GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND und RECOVER hinweg. RoPA und Datenflussabbildungen werden zu Eingaben für das Management rechtlicher Verpflichtungen, Asset-Inventare, Lieferantenrisiko, Datenschutz, Überwachung, Vorfallkommunikation und Wiederherstellungsplanung.

Ein COBIT 2019- oder ISACA-orientierter Auditor fokussiert auf Governance, Verantwortlichkeit und Prozessfähigkeit. Er wird prüfen, ob Informationsflüsse verantwortet sind, ob Entscheidungsrechte klar sind, ob die Risikobereitschaft angewendet wird, ob Kontrollen überwacht werden, ob Ausnahmen eskaliert werden und ob Nachweise verlässlich genug für Management-Assurance sind.

Häufige Fehlermuster

Die häufigsten Fehler bei RoPA und Datenflussabbildung sind vorhersehbar.

Erstens listet das RoPA Verarbeitungstätigkeiten, aber keine Systeme. Dadurch ist es unmöglich, Rechenschaftspflicht nach GDPR mit Schwachstellenmanagement, Berechtigungsüberprüfung, Backup, Protokollierung oder Incident Response zu verbinden.

Zweitens enden Datenflussabbildungen beim ersten Lieferanten. Sie zeigen keine Unterauftragsverarbeiter, Cloud-Regionen, Support-Zugriffe, Analysewerkzeuge, Überwachungsplattformen oder Backup-Standorte.

Drittens identifizieren Business-Continuity-Pläne Systeme, aber keine personenbezogenen Daten. Während eines Ausfalls versteht die Organisation die Wiederherstellungspriorität, aber nicht die Datenschutzfolgen.

Viertens erfassen Lieferantenregister Vertragsverantwortliche, aber nicht Kritikalität, Ersetzbarkeit, Datenkategorien, Pflichten zur Vorfallbenachrichtigung oder Exit-Optionen.

Fünftens ist die SoA als Zertifizierungsdokument geschrieben und nicht als Kontrollbrücke. Sie sagt, dass Kontrollen anwendbar sind, erklärt aber nicht, welches Nachweisproblem nach GDPR, NIS2 oder DORA die jeweilige Kontrolle löst.

Schließlich ist die Verantwortlichkeit fragmentiert. Der DPO verantwortet RoPA, IT verantwortet Assets, Beschaffung verantwortet Lieferanten, der Betrieb verantwortet BIA, die Finanzabteilung verantwortet DORA-Register, und niemand verantwortet die integrierte Abhängigkeitsabbildung.

Clarysecs Ansatz behebt dies, indem Nachweisobjekte Richtlinienverantwortlichen zugewiesen und anschließend die Schritte des Zenith Blueprint genutzt werden, um Assets, Risiken, Kontrollen und SoA-Nachvollziehbarkeit zu verbinden.

Ein 30-Tage-Umsetzungsplan

Sie müssen nicht alles auf einmal lösen. Beginnen Sie mit den Diensten, die am wichtigsten sind.

Woche 1: Wählen Sie drei kritische oder risikobehaftete Verarbeitungstätigkeiten aus. Gute Kandidaten sind Kunden-Onboarding, Zahlungsabwicklung, HR-Administration für Mitarbeitende, Support-Ticketing oder Sicherheitsüberwachung. Validieren Sie für jede Tätigkeit den RoPA-Eintrag gegen tatsächliche Systeme, Datenkategorien, Zwecke, Rechtsgrundlagen und Aufbewahrungsregeln.

Woche 2: Erstellen Sie Datenflussabbildungen für diese Tätigkeiten. Identifizieren Sie Quelle, Ziel, Übertragungsmethode, Umgebung, Lieferant, Unterauftragsverarbeiter, Datenstandort, Zugriffspfad, Transformation und Aufbewahrungspunkt. Nutzen Sie die Anforderung aus Clarysecs Richtlinie zur Datenmaskierung und Pseudonymisierung, Inventare von Systemen und Datenflüssen zu führen, die sensible Daten betreffen.

Woche 3: Verknüpfen Sie jeden Datenfluss mit Assets, Lieferanten, Cloud-Diensten und kritischen Geschäftsfunktionen. Nutzen Sie Zenith Blueprint Schritt 9 für Asset-Verantwortung und Klassifizierung. Nutzen Sie die Anforderungen aus Lieferanten- und Cloud-Registerrichtlinien, um Drittparteiennachweise zu erfassen. Nutzen Sie die Richtlinie zur Betriebskontinuität, um priorisierte Dienste und kritische Abhängigkeiten zu identifizieren.

Woche 4: Ergänzen Sie Risiko- und Kontrollnachvollziehbarkeit. Erstellen oder aktualisieren Sie für jeden Datenfluss Risikoszenarien. Ordnen Sie Kontrollen in der SoA mithilfe von Zenith Blueprint Schritt 13 zu. Ergänzen Sie, wo anwendbar, Hinweise zur Rechenschaftspflicht nach GDPR Article 30, zu Risikomaßnahmen nach NIS2 Article 21 und zu Nachweisen für IKT-Abhängigkeiten nach DORA.

Führen Sie anschließend eine Tabletop-Übung durch: „Lieferantenausfall plus Datenexposition in einem kritischen Dienst“. Testen Sie, ob Ihre Nachweise Vorfallklassifizierung, Meldeentscheidungen, Kundenkommunikation, Kommunikation mit Aufsichtsbehörden und Priorisierung der Wiederherstellung unterstützen.

Nach 30 Tagen verfügen Sie über ein wiederholbares Modell für den Rest der Organisation.

Der Clarysec-Ansatz: RoPA in lebende Resilienznachweise überführen

RoPA und Datenflussabbildung sind nicht länger nur Datenschutzadministration. Sie sind das verbindende Element zwischen Rechenschaftspflicht nach GDPR, Governance kritischer Dienste nach NIS2 und Nachweisen zu IKT-Abhängigkeiten nach DORA.

Die Organisationen, die 2026 am besten abschneiden werden, sind nicht diejenigen mit den meisten Dokumenten. Es sind diejenigen, die einen Geschäftsservice auf seine Verarbeitungstätigkeiten, Datenflüsse, Systeme, Lieferanten, Cloud-Regionen, Verträge, Kontrollen, Risiken, Vorfallschwellen und Wiederherstellungspläne zurückführen können.

Clarysec hilft Teams, diese Nachvollziehbarkeit ohne unnötige Bürokratie aufzubauen. Unsere Richtliniensuite weist Verantwortlichkeiten und Nachweisanforderungen zu. Der Zenith Blueprint bietet die Umsetzungsroadmap, einschließlich Asset-Identifizierung, Umsetzung von Lieferanten- und Cloud-Kontrollen sowie SoA-Nachvollziehbarkeit. Zenith Controls bietet den Cross-Compliance-Kompass zur Zuordnung von Maßnahmen aus ISO/IEC 27001:2022 Annex A zu Erwartungen an Datenschutz, Resilienz, Lieferanten, Cloud und Audits.

Ihr nächster Schritt ist einfach: Wählen Sie einen kritischen Dienst, einen RoPA-Eintrag und einen lieferantengestützten Datenfluss. Bilden Sie ihn Ende-zu-Ende ab. Wenn Sie Daten, Abhängigkeit, Kontrolle und Vorfallauswirkung nicht auf einer Seite erklären können, ist Ihre Nachweisebene nicht bereit für 2026.

Clarysec kann Ihnen helfen, sie bereit zu machen. Entdecken Sie den Zenith Blueprint, stärken Sie Ihre Governance mit der Richtlinie zu Datenschutz und Privatsphäre und der Richtlinie zum Management von Risiken aus Lieferantenabhängigkeiten, und nutzen Sie Zenith Controls, um fragmentierte Compliance-Nachweise in ein einheitliches, auditreifes Betriebsmodell zu überführen.