Transfer Impact Assessments für Cloud-Services 2026

Maria, CISO bei InnovatePay, starrte auf Seite 12 des Due-Diligence-Fragebogens.

Ihr Unternehmen, ein schnell wachsender europäischer FinTech-SaaS-Anbieter, stand kurz vor dem Vertragsabschluss mit seinem bisher größten Kunden: einer großen Bank mit strengen Anforderungen an die operationelle Resilienz. Der Fragebogen verlangte nicht nur ein ISO 27001-Zertifikat, eine Zusammenfassung der Penetrationstests oder ein Paket von Sicherheitsrichtlinien. Gefordert wurden ein vollständiges Transfer Impact Assessment für den primären US-basierten Cloud-Anbieter von InnovatePay, eine Aufschlüsselung der Unterauftragsverarbeiter, die anwendbaren Standardvertragsklauseln, die Erklärung zu geografischen Datenübermittlungen sowie der Nachweis, dass ergänzende Maßnahmen ISO/IEC 27001:2022, NIS2 und DORA zugeordnet waren.

Die Rechtsabteilung hatte den Auftragsverarbeitungsvertrag. Der Einkauf hatte das Lieferantenportal. Engineering hatte die Einstellungen der Cloud-Regionen. Security hatte Verschlüsselungsdiagramme. Customer Success hatte in einem Verkaufsgespräch „EU-Hosting“ zugesagt. Niemand konnte unmittelbar nachweisen, ob Support-Zugriff aus Indien im Geltungsbereich lag, ob das Analytics-Add-on einen US-Unterauftragsverarbeiter nutzte oder ob Fehlerprotokolle über einen globalen Monitoring-Anbieter repliziert wurden.

Das ist die Realität des Jahres 2026 für SaaS-Unternehmen, Cloud-Anbieter, FinTech-Lieferanten und Anbieter verwalteter IKT-Dienstleistungen. Ein Transfer Impact Assessment, kurz TIA, ist kein Datenschutzvermerk mehr, der am Ende der Beschaffung erstellt wird. Es ist ein Nachweispaket für mehrere Compliance-Anforderungen, das erläutern muss, wohin personenbezogene Daten fließen, wer darauf zugreifen kann, welcher rechtliche Übermittlungsmechanismus gilt, welche ergänzenden Maßnahmen das Risiko senken und wie die Organisation die Übermittlung über die Zeit überwacht.

Für viele Teams liegt das Problem nicht in fehlendem Einsatz. Es liegt in der Fragmentierung. SCCs liegen in einem Vertragsrepository. Listen der Unterauftragsverarbeiter befinden sich in Lieferantenportalen. Einstellungen zur Datenresidenz stehen in der Cloud-Konsole. Risikoentscheidungen sind in E-Mails verborgen. Verschlüsselungsnachweise liegen in Confluence. Ein belastbares Cloud-bezogenes Transfer Impact Assessment verbindet diese Fragmente zu einer durchgängigen und verteidigungsfähigen Nachweiskette.

Warum Cloud-bezogene TIAs zu einem Risiko auf Ebene des Leitungsorgans geworden sind

Ein Transfer Impact Assessment bewertet, ob personenbezogene Daten, die außerhalb des Europäischen Wirtschaftsraums übermittelt werden, in der Praxis weiterhin angemessen geschützt sind. Die Bewertung muss die Daten, Parteien, Verarbeitungszwecke, Speicherorte, Zugriffsorten, Weiterübermittlungen, den rechtlichen Übermittlungsmechanismus, Risiken des Empfängerlands und ergänzende Maßnahmen identifizieren.

Unter GDPR ist der Ausgangspunkt weit gefasst. Personenbezogene Daten, Verarbeitung, Verantwortlicher, Auftragsverarbeiter, Pseudonymisierung und Verletzung des Schutzes personenbezogener Daten sind breit definiert. Cloud-Telemetrie, Support-Tickets, Authentifizierungsprotokolle, Abrechnungsdatensätze, Benutzerkennungen, IP-Adressen und Produktanalysen können sämtlich in den Geltungsbereich fallen. Die Rechenschaftspflicht nach Article 5 GDPR verlangt von Organisationen den Nachweis der Einhaltung, während die Pflichten für Auftragsverarbeiter nach Article 28 und die Regeln für internationale Übermittlungen in Chapter V davon abhängen, genau zu wissen, welche Daten wohin fließen und wer darauf zugreifen kann.

Das Schrems-II-Urteil hat die praktische Belastung verdeutlicht. Die Unterzeichnung von SCCs reicht für sich allein nicht aus. Organisationen müssen prüfen, ob die Gesetze und Praktiken des Bestimmungslands die im Vertrag zugesagten Schutzmechanismen untergraben könnten, und bei Bedarf ergänzende Maßnahmen anwenden.

Für Cloud-Unternehmen wird das schnell komplex. Ein SaaS-Produkt kann einen Infrastrukturanbieter, eine separate Support-Plattform, einen E-Mail-Dienst, ein Tool zur Fehlerüberwachung, ein CDN, ein Data Warehouse und eine KI-gestützte Analysefunktion nutzen. Jeder Anbieter kann Unterauftragsverarbeiter einsetzen. Jeder Unterauftragsverarbeiter kann einen Speicherort, einen Zugriffsort, einen operativen Supportpfad oder eine Weiterübermittlung einführen.

Deshalb sind ISO/IEC 27001:2022, NIS2, DORA und NIST CSF 2.0 Teil der TIA-Diskussion geworden:

• GDPR fragt, ob ein rechtmäßiger Übermittlungsmechanismus, angemessene Auftragsverarbeiterbedingungen, Kontrolle über Unterauftragsverarbeiter und wirksame ergänzende Maßnahmen bestehen.
• ISO/IEC 27001:2022 fragt, ob das Übermittlungsrisiko identifiziert, behandelt, kontrolliert, überwacht und in die Anwendbarkeitserklärung aufgenommen wurde.
• NIS2 fragt, ob wesentliche und wichtige Einrichtungen Cybersicherheitsrisiken von Lieferanten und Dienstleistern unter Aufsicht des Leitungsorgans steuern.
• DORA verlangt von Finanzunternehmen den Nachweis von IKT-Drittparteien-Governance, Vertragsklauseln, Transparenz bei Unterbeauftragung, Standorttransparenz, Konzentrationsrisiko und Exit-Bereitschaft.
• NIST CSF 2.0 hilft, diese Anforderungen in Ergebnisse zu Governance, Lieferantenrisiko, Schutz, Reaktion und Wiederherstellung zu übersetzen.

Die praktische Schlussfolgerung ist einfach: Ein TIA gehört in das ISMS, nicht daneben.

Das ISMS als zentrale Stelle für Compliance nutzen

TIAs, GDPR, DORA und NIS2 in getrennten Tabellen zu verwalten, erzeugt doppelte Arbeit und Audit-Lücken. Der skalierbarere Ansatz besteht darin, ISO/IEC 27001:2022 als Managementsystem zu nutzen, das Verpflichtungen, Risiken, Kontrollen und Nachweise miteinander verbindet.

ISO/IEC 27001:2022 verlangt von Organisationen, ihren Kontext, Anforderungen interessierter Parteien sowie Schnittstellen und Abhängigkeiten zu anderen Organisationen zu verstehen. Außerdem fordert die Norm eine wiederholbare Informationssicherheitsrisikobeurteilung, einen Risikobehandlungsprozess, eine Anwendbarkeitserklärung und Nachweise, dass ausgewählte Kontrollen wie vorgesehen wirksam sind.

Diese Struktur passt exakt zu einem TIA. Das Risiko „personenbezogene Daten aus der EU können über einen Cloud-Anbieter oder Unterauftragsverarbeiter ohne wirksame Schutzmaßnahmen aus einem Drittland abgerufen werden“ gehört in das Risikoregister. Die Behandlung gehört in den Risikobehandlungsplan. Die ausgewählten Kontrollen gehören in die SoA. Die unterstützenden Artefakte gehören in einen Nachweisindex.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap beschreibt diese Beziehung in der Phase Risikomanagement, Schritt 13:

Die SoA ist faktisch ein Brückendokument: Sie verknüpft Ihre Risikobeurteilung und Risikobehandlung mit den tatsächlich vorhandenen Kontrollen. Durch ihre Fertigstellung prüfen Sie zugleich, ob Kontrollen übersehen wurden.

Dieser Satz ist zentral für TIA-Bereitschaft. Das TIA ist nicht die Kontrolle. Es ist die Bewertung, die erklärt, warum Kontrollen erforderlich sind und wie sie das verbleibende Übermittlungsrisiko reduzieren. Die SoA ist die Brücke, die das Risiko mit Cloud-Governance, Lieferantenverträgen, Kryptografie, Zugriffskontrolle, Überwachung, Incident Response, Kontinuität und Einhaltung rechtlicher Anforderungen verbindet.

Mit der Übermittlungsübersicht beginnen, nicht mit den SCCs

Viele Organisationen beginnen ein TIA mit der Frage, ob der Vertrag SCCs enthält. Das ist notwendig, aber nicht die erste Frage. SCCs sind nur dann aussagekräftig, wenn die Organisation weiß, welche Übermittlungen sie abdecken.

Ein praxisnahes Cloud-TIA beginnt mit fünf Fragen.

Clarysecs Cloud Usage Policy-sme operationalisiert dies durch die Pflicht zur Führung eines Registers:

Ein Register für Cloud-Services muss vom IT-Dienstleister oder der Geschäftsführung geführt werden. Es muss Folgendes erfassen:

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.

Dieselbe Klauselfamilie enthält eine Standortanforderung, die für TIAs wesentlich ist:

Das Land oder die Region, in der Daten gespeichert werden

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.4.

Für größere Umgebungen verbindet Clarysecs Cloud Usage Policy Cloud-Governance ausdrücklich mit Übermittlungsmechanismen:

Standardvertragsklauseln (SCCs) und Übermittlungsmechanismen nach GDPR überprüfen, sofern anwendbar.

Aus dem Abschnitt „Rollen und Verantwortlichkeiten“, Richtlinienklausel 4.5.2.

Dieselbe Richtlinie ergänzt die regulatorienübergreifende Anforderung:

Grenzüberschreitende Datenübermittlungen müssen GDPR Chapter V und, sofern anwendbar, DORA Article 28 entsprechen.

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

Das verändert die TIA-Diskussion. Die Frage lautet nicht: „Haben wir SCCs?“ Die Frage lautet: „Welcher Cloud-Service, welche personenbezogenen Daten, welches Land, welcher Zugriffspfad, welcher Unterauftragsverarbeiter, welcher Übermittlungsmechanismus, welche ergänzenden Maßnahmen und welches Restrisiko?“

Cloud-TIAs auf Nachweise nach ISO/IEC 27001:2022 abbilden

ISO/IEC 27001:2022 liefert die Struktur, um nachzuweisen, dass ein TIA Teil eines wirksamen Kontrollumfelds ist. Die relevantesten Nachweisbereiche sind Lieferanten-Governance, Cloud-Governance, rechtliche Verpflichtungen, Datenschutz, Kryptografie, Zugriffskontrolle, Überwachung, Incident Response und Kontinuität.

Clarysecs Zenith Controls: The Cross-Compliance Guide ist hier besonders nützlich. In Zenith Controls wird ISO/IEC 27002:2022 Maßnahme 5.23, Informationssicherheit für die Nutzung von Cloud-Services, als präventive Kontrolle behandelt, die Vertraulichkeit, Integrität und Verfügbarkeit über Governance-, Ökosystem- und Schutzdomänen hinweg unterstützt. Sie verknüpft Cloud-Nutzung mit Lieferantenbeziehungen, Endpoint-Sicherheit, Netzwerksicherheit, Informationsübermittlung, Datenmaskierung, Verhinderung von Datenabfluss, Asset-Inventar und sicherem Entwicklungslebenszyklus.

Diese Zuordnung ist wichtig, weil ein TIA selten durch eine einzelne Vertragsklausel gelöst wird. Häufig geht es um Cloud-Administrationszugriff, APIs, die Daten zwischen Regionen bewegen, Support-Konsolen, Protokolle, Storage Buckets, Monitoring-Plattformen und Backup-Standorte.

Zenith Controls ordnet 5.23 außerdem verwandten Standards zu, darunter ISO/IEC 27017 für geteilte Verantwortung in der Cloud und Prüfpfade, ISO/IEC 27018 für den Schutz personenbezogener Daten in der Public Cloud, ISO/IEC 27701 für Anforderungen aus Datenschutz-Erweiterungen, ISO/IEC 27036-4 für Cloud-Service-Überwachung und ISO/IEC 27005 für Cloud-Risikobeurteilung.

Für Lieferantenverträge behandelt Zenith Controls ISO/IEC 27002:2022 Maßnahme 5.20, Berücksichtigung der Informationssicherheit in Lieferantenvereinbarungen. Diese Maßnahme überführt Übermittlungsanforderungen in durchsetzbare Verpflichtungen. Auftragsverarbeiterbedingungen nach GDPR Article 28, Kontrollen für Unterauftragsverarbeiter, Erwartungen an die Lieferkette nach NIS2 und Vertragsbestimmungen nach DORA Article 30 werden dadurch zu Vertragsnachweisen.

Für die kontinuierliche Aufsicht ist ISO/IEC 27002:2022 Maßnahme 5.22, Überwachung, Überprüfung und Änderungsmanagement von Lieferantendiensten, entscheidend. Ein TIA, das beim Onboarding abgeschlossen wurde, kann veralten, wenn ein Anbieter einen Unterauftragsverarbeiter hinzufügt, Supportstandorte ändert, die Protokollierungsarchitektur anpasst oder eine neue Funktion einführt.

Die Schwachstelle Unterauftragsverarbeiter beheben

Der häufigste TIA-Fehler sind nicht fehlende SCCs. Es ist veraltetes Wissen über Unterauftragsverarbeiter.

Cloud-Anbieter und SaaS-Plattformen ändern häufig Service-Regionen, Supportmodelle, Telemetriepipelines, CDNs und Unterauftragnehmer. Wenn ein TIA auf einer Liste von Unterauftragsverarbeitern beruht, die einmal während der Beschaffung heruntergeladen wurde, wird es schnell unzuverlässig.

Clarysecs Third party and supplier security policy adressiert dies durch eine vertragliche Anforderung:

Die Nutzung von Unterauftragnehmern unterliegt der vorherigen schriftlichen Zustimmung

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.5.

Clarysecs Legal and Regulatory Compliance Policy identifiziert die rechtlichen Nachweise, die gepflegt werden müssen:

Offenlegungen zu Unterauftragsverarbeitern und Erklärungen zu geografischen Datenübermittlungen

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

Diese Anforderung ist kurz, macht aber häufig den Unterschied zwischen einem belastbaren und einem unvollständigen TIA aus. Wenn eine Organisation keine Offenlegungen zu Unterauftragsverarbeitern und geografischen Übermittlungserklärungen vorlegen kann, kann sie Weiterübermittlungen nicht zuverlässig erklären.

Der Zenith Blueprint, Phase „Controls in Action“, Schritt 23, ergänzt die operative Erwartung:

Identifizieren Sie für jeden kritischen Lieferanten, ob er Unterauftragnehmer (Unterauftragsverarbeiter) einsetzt, die auf Ihre Daten oder Systeme zugreifen können. Dokumentieren Sie, wie Ihre Informationssicherheitsanforderungen an diese Parteien weitergegeben werden, entweder über die Vertragsbedingungen Ihres Lieferanten oder über eigene direkte Klauseln.

In der Praxis bedeutet dies: Lieferanten mit hohem Risiko müssen eine jährliche Überprüfung der Unterauftragsverarbeiter, einen Änderungsbenachrichtigungsprozess, einen dokumentierten Genehmigungs-Workflow und einen Auslöser für die Risikoneubewertung haben. Für DORA-relevante Services unterstützen dieselben Nachweise auch die Analyse von Unterbeauftragung und Konzentrationsrisiko.

Ergänzende Maßnahmen konkret und nachweisbar machen

Ergänzende Maßnahmen sollten niemals nur als „wir nutzen Verschlüsselung“ dokumentiert werden. Auditoren und Unternehmenskunden werden fragen, was verschlüsselt ist, wo die Verschlüsselung angewendet wird, wer die Schlüssel kontrolliert, ob Personal des Anbieters auf Klartext zugreifen kann, ob Protokolle personenbezogene Daten enthalten und wie privilegierter Zugriff genehmigt wird.

Ein belastbares Paket ergänzender Maßnahmen kombiniert technische, vertragliche, organisatorische und resilienzbezogene Schutzmaßnahmen.

Clarysecs Cryptographic Controls Policy-sme liefert den Anker:

Verschlüsselung muss angewendet werden auf:

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

Für ein TIA muss diese Richtlinienaussage zu einem expliziten Nachweis werden. Die Verschlüsselung muss für personenbezogene Daten beschrieben werden, die zwischen EU-Systemen und Cloud-Services in Drittländern übertragen werden, in Cloud-Speichern ruhen und in Backups enthalten sind. Die Schlüsselinhaberschaft muss definiert sein. Wenn kundenseitig verwaltete Schlüssel verwendet werden, muss das TIA erläutern, ob der Anbieter auf Klartext zugreifen kann, wann Support-Zugriff erlaubt ist und wie administrativer Zugriff protokolliert wird.

Clarysecs Third-Party and Supplier Security Policy-sme stärkt die Standortsicherheit:

Wenn Lieferanten Daten extern speichern müssen, muss das Unternehmen Zusicherungen zu Datenschutz, physischer Sicherheit und geografischem Speicherort einholen (z. B. EU-only Hosting, wenn dies nach GDPR erforderlich ist).

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

Dieselbe SME-Richtlinie unterstützt auch die Vollständigkeit von Verträgen:

Verträge müssen verbindliche Klauseln enthalten zu:

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.

Für TIAs müssen diese verbindlichen Klauseln Vertraulichkeit, Sicherheitsmaßnahmen, Meldung von Verstößen, Unterauftragsverarbeiter, Auditrechte, Datenrückgabe, Löschung, Übermittlungsmechanismen und Standortzusagen abdecken.

Ein auditfähiges TIA-Nachweispaket aufbauen

Nehmen wir an, ein europäischer B2B-SaaS-Anbieter nutzt eine US-basierte Analyseplattform. Die Plattform verarbeitet Nutzungsereignisse von Kunden, Benutzerkennungen, IP-Adressen und Support-Metadaten. Sie bietet EU-Hosting und SCCs an, aber Supportpersonal außerhalb des EWR kann auf Tickets zugreifen, und Fehlerprotokolle können durch einen Unterauftragsverarbeiter in einem Drittland verarbeitet werden.

Ein praxisnahes Nachweispaket lässt sich in sechs Schritten aufbauen.

1. Den Übermittlungsdatensatz erstellen

Beginnen Sie mit dem Register für Cloud-Services, das durch die Cloud Usage Policy-sme verlangt wird. Ergänzen Sie Serviceverantwortlichen, Geschäftszweck, Datenkategorien, betroffene Personen, Rolle, Hosting-Region, Zugriffsländer, Supportstandorte, Unterauftragsverarbeiter, Übermittlungsmechanismus, ergänzende Maßnahmen, Risikobewertung und nächstes Überprüfungsdatum.

Für die Analyseplattform wird erfasst, dass Ereignisse in der EU gehostet werden, Support-Zugriff außerhalb des EWR stattfinden kann und die Fehlerüberwachung eine Weiterübermittlung erzeugt.

2. Vertragliche Nachweise anhängen

Hängen Sie den DPA, SCCs oder andere Nachweise zum Übermittlungsmechanismus, den Sicherheitsnachtrag, Bedingungen zur Meldung von Vorfällen und die Liste der Unterauftragsverarbeiter an. Nutzen Sie Klausel 4.5.2 der Cloud Usage Policy, um die Überprüfung von SCCs und Übermittlungsmechanismen nachzuweisen. Nutzen Sie Klausel 5.3.5 der Third party and supplier security policy, um die Genehmigung oder Zustimmung zu Unterauftragsverarbeitern nachzuweisen.

Wenn Sie sich für einen Anbieter auf das EU-US Data Privacy Framework stützen, dokumentieren Sie Geltungsbereich, Zertifizierungsstatus, Serviceabdeckung und Rückfallmechanismus. Gehen Sie nicht davon aus, dass es jede Weiterübermittlung abdeckt.

3. Das Risikoszenario erstellen

Nehmen Sie das Risiko in das ISMS-Risikoregister auf:

„Personenbezogene Daten aus der EU, die über die Analyseplattform verarbeitet werden, können aus einem Drittland durch Anbieter-Support oder Unterauftragsverarbeiter abgerufen werden und dadurch Risiken für Vertraulichkeit sowie für die Einhaltung rechtlicher und regulatorischer Anforderungen erzeugen.“

Weisen Sie Verantwortlichen, Eintrittswahrscheinlichkeit, Auswirkung, inhärente Bewertung, Behandlungsplan und Restrisikobewertung zu. Verknüpfen Sie das Risiko mit GDPR Chapter V, Kundenzusagen, Cloud- und Lieferantenkontrollen nach ISO/IEC 27001:2022, NIS2 Article 21, sofern anwendbar, sowie DORA Articles 28, 29 und 30 für Kontexte im Finanzsektor.

Clarysecs Risk Management Policy legt die Disziplin der Risikobehandlung fest:

Der Risikobeauftragte muss sicherstellen, dass Behandlungen realistisch, zeitlich begrenzt und ISO/IEC 27001 Annex A-Kontrollen zugeordnet sind.

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

4. Ergänzende Maßnahmen auswählen

Für die Analyseplattform können Maßnahmen EU-Hosting, minimierte Ereignis-Payloads, pseudonyme Kennungen, Verschlüsselung während der Übertragung, Verschlüsselung ruhender Daten, eingeschränkten Support-Zugriff, MFA für Administratoren, Protokollierung privilegierter Zugriffe, DLP-Regeln zur Verhinderung sensitiver Felder in Analyseereignissen, Benachrichtigungspflichten zu Unterauftragsverarbeitern und eine jährliche Nachweisprüfung umfassen.

Ordnen Sie diese Maßnahmen ISO/IEC 27002:2022-Kontrollen zu, etwa 5.14 Informationsübermittlung, 5.15 Zugriffskontrolle, 5.20 Berücksichtigung der Informationssicherheit in Lieferantenvereinbarungen, 5.22 Überwachung, Überprüfung und Änderungsmanagement von Lieferantendiensten, 5.23 Informationssicherheit für die Nutzung von Cloud-Services, 5.31 rechtliche, gesetzliche, regulatorische und vertragliche Anforderungen, 5.34 Datenschutz und Schutz personenbezogener Daten, 8.11 Datenmaskierung, 8.12 Verhinderung von Datenabfluss, 8.16 Überwachungsaktivitäten und 8.24 Nutzung von Kryptografie.

5. Auslöser für Überprüfungen definieren

Ein TIA ist erst vollständig, wenn Auslöser für Überprüfungen definiert sind. Auslöser müssen einen neuen Unterauftragsverarbeiter, ein neues Zugriffsland, eine neue Datenkategorie, eine Änderung des Supportmodells, einen Sicherheitsvorfall, eine Vertragsverlängerung, eine neue kritische Kundenanforderung, eine neue DORA-Klassifizierung oder eine wesentliche Änderung der Cloud-Architektur umfassen.

Hier wird ISO/IEC 27002:2022 Maßnahme 5.22 operativ. Prüfen Sie SOC-Berichte, ISO-Zertifikate, Zusammenfassungen von Penetrationstests, Mitteilungen zu Serviceänderungen, Vorfallshistorie und Aktualisierungen zu Unterauftragsverarbeitern. Verfolgen Sie Ausnahmen bis zum Abschluss.

6. SoA und Nachweisindex aktualisieren

Markieren Sie in der Anwendbarkeitserklärung Cloud-, Lieferanten-, Rechts-, Datenschutz-, Kryptografie-, Zugriffs-, Überwachungs-, Vorfalls- und Kontinuitätskontrollen als anwendbar. Ergänzen Sie SoA-Hinweise wie „unterstützt GDPR Chapter V TIA für Analyseplattform“, „unterstützt DORA-Nachweise zu IKT-Drittparteienverträgen“ oder „unterstützt NIS2-Nachweise zur Sicherheit der Lieferkette“.

Dieser letzte Indexierungsschritt macht aus einer Datenschutzbewertung einen auditfähigen Compliance-Nachweis.

Dieselben Nachweise auf GDPR, DORA, NIS2 und ISO 27001 abbilden

Ein gut aufgebautes TIA-Nachweispaket sollte mehrere Audit-Perspektiven bedienen, ohne doppelte Dokumentation zu erzeugen.

DORA ist besonders wichtig, wenn der Kunde ein Finanzunternehmen ist oder der Service eine IKT-Kette im Finanzsektor unterstützt. DORA gilt seit dem 17. Januar 2025 und legt Anforderungen an IKT-Risikomanagement, Vorfallmeldung, Resilienztests, Informationsaustausch und IKT-Drittparteienrisiko fest. Article 8 verlangt die Identifizierung und Klassifizierung von IKT-Assets, Informations-Assets und Abhängigkeiten. Article 28 verlangt Governance für IKT-Drittparteienrisiken, Informationsregister, gebotene Sorgfalt und Exit-Strategien. Article 29 adressiert IKT-Konzentrations- und Unterbeauftragungsrisiken. Article 30 verlangt schriftliche Verträge mit Servicebeschreibungen, Verarbeitungsorten, Datenschutz, Zugriff, Wiederherstellung, Datenrückgabe, Unterstützung bei Vorfällen, Zusammenarbeit mit Behörden, Kündigungsrechten, Auditrechten und Übergangsregelungen.

NIS2 ergänzt die Rechenschaftspflicht des Managements. Article 20 verlangt, dass Leitungsorgane Maßnahmen zum Management von Cybersicherheitsrisiken genehmigen und überwachen. Article 21 verlangt angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen, einschließlich Risikorichtlinien, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, sichere Beschaffung und Entwicklung, Bewertung der Kontrollwirksamkeit, Cyberhygiene, Kryptografie, HR-Sicherheit, Zugriffskontrolle, Asset-Management und MFA, soweit angemessen.

Die Überschneidung ist klar. Ein TIA, das Unterauftragsverarbeiter, Übermittlungsorte, ergänzende Maßnahmen, Vorfallpflichten und Lieferantenüberwachung identifiziert, ist zugleich Nachweis für Lieferantenresilienz.

Wie Auditoren Ihr TIA prüfen werden

Unterschiedliche Auditoren stellen unterschiedliche Fragen, aber die Nachweise sollten wiederverwendbar sein.

Zenith Controls liefert für diese Bereiche eine praxisnahe Auditmethodik. Bei Cloud-Services suchen Auditoren nach einem Register genehmigter Cloud-Services und nach Nachweisen, dass nicht autorisierte Cloud-Nutzung überwacht wird. Bei Lieferantenvereinbarungen führen Auditoren Vertragsstichproben bei Lieferanten mit hohem Risiko durch und validieren Vertraulichkeit, Datenschutz, Meldefristen bei Verstößen, Auditrechte, Genehmigung von Unterauftragsverarbeitern sowie Datenrückgabe oder Vernichtung. Bei der Lieferantenüberwachung prüfen Auditoren Überprüfungsaufzeichnungen, KPI-Berichte, Lieferantenzertifizierungen, SOC-Berichte, Zusammenfassungen von Penetrationstests, Ausnahmen und Abhilfemaßnahmen.

Die Audit-Lehre ist eindeutig: Nachweise müssen den Betrieb über die Zeit zeigen. Ein einmal unterzeichnetes und nie wieder überprüftes TIA genügt keiner ernsthaften Cloud-, Lieferanten- oder Resilienzprüfung.

NIST CSF 2.0 nutzen, um TIA-Risiken der Leitungsebene zu erklären

Leitungsorgane wollen selten SCC-Module oder Cloud-Supportstandorte im Detail diskutieren. Sie wollen wissen, ob Risiken gesteuert, priorisiert und verbessert werden. NIST CSF 2.0 hilft, das TIA über GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND und RECOVER in Sprache für Führungskräfte zu übersetzen.

Für ein TIA ist die Funktion GOVERN besonders nützlich. Sie umfasst rechtliche, regulatorische und vertragliche Anforderungen, Risikobereitschaft, Rollen, Richtlinien, Aufsicht und Management von Lieferanten-Cybersicherheitsrisiken. Erstellen Sie ein Current Profile, das den heutigen Stand zeigt, etwa ein teilweises Cloud-Register, ein SCC-Repository, eine begrenzte Überprüfung von Unterauftragsverarbeitern und keinen definierten Überprüfungsturnus für TIAs. Definieren Sie anschließend ein Target Profile, etwa ein vollständiges Übermittlungsinventar, risikobewertete Unterauftragsverarbeiter, verifizierte Übermittlungsmechanismen, kundenseitig verwaltete Schlüssel für Hochrisikodaten, vierteljährliche Überprüfungen kritischer Lieferanten, DORA-fähiges Vertragsmapping und getestete Cloud-Exit-Pläne.

Der Lückenplan wird dadurch zu einem praktischen Fahrplan, den das Management finanzieren und nachverfolgen kann.

Die Clarysec-Checkliste für Cloud-TIAs 2026

Nutzen Sie diese Checkliste, um zu prüfen, ob Ihr Transfer Impact Assessment auditfähig ist:

• Führen Sie ein Register für Cloud-Services mit Verantwortlichem, Zweck, Datenkategorien, Standorten, Zugriffsländern und Unterauftragsverarbeitern.
• Identifizieren Sie, ob jeder Service eine Beziehung als Verantwortlicher, Auftragsverarbeiter, Unterauftragsverarbeiter oder unabhängiger Anbieter darstellt.
• Hängen Sie DPA, SCCs oder andere Nachweise zum Übermittlungsmechanismus an den Lieferantendatensatz an.
• Dokumentieren Sie eine Abstützung auf das EU-US Data Privacy Framework nur dort, wo Geltungsbereich und Weiterübermittlungen verifiziert sind.
• Pflegen Sie Offenlegungen zu Unterauftragsverarbeitern und geografische Übermittlungserklärungen.
• Verlangen Sie risikobasiert vorherige schriftliche Zustimmung oder vertragliche Benachrichtigung bei neuen Unterauftragsverarbeitern.
• Ordnen Sie ergänzende Maßnahmen spezifischen technischen Kontrollen zu, nicht allgemeinen Aussagen.
• Weisen Sie Verschlüsselung während der Übertragung, Verschlüsselung ruhender Daten, Verantwortlichkeit für Schlüsselmanagement und Protokollierung privilegierter Zugriffe nach.
• Minimieren, pseudonymisieren oder maskieren Sie personenbezogene Daten nach Möglichkeit vor der Übermittlung.
• Definieren Sie Auslöser für Überprüfungen bei neuen Ländern, neuen Unterauftragsverarbeitern, neuen Datenkategorien, Vorfällen und Vertragsänderungen.
• Verknüpfen Sie jedes TIA-Risiko mit Risikoregister, Behandlungsplan und SoA.
• Prüfen Sie Lieferantennachweise regelmäßig und verfolgen Sie Ausnahmen bis zum Abschluss.
• Nehmen Sie Vorfallmeldungen, Auditrechte, Datenrückgabe, Löschung und Exit-Verpflichtungen in Verträge auf.
• Ordnen Sie Verträge für DORA-relevante Services den Anforderungen an IKT-Drittparteien, Unterbeauftragung, Standorte, Konzentrationsrisiko und Exit-Strategie zu.
• Berichten Sie Entscheidungen zu Hochrisikoübermittlungen im Rahmen der ISMS-Governance an das Management.

Übermittlungsunsicherheit in auditfähige Nachweise überführen

InnovatePay gewann den Bankkunden, weil Maria das TIA nicht länger als kurzfristig benötigtes Rechtsdokument behandelte. Ihr Team erstellte ein Register für Cloud-Services, hängte SCCs und DPAs an, dokumentierte Unterauftragsverarbeiter, ordnete ergänzende Maßnahmen ISO/IEC 27001:2022-Kontrollen zu, aktualisierte das Risikoregister, ergänzte SoA-Hinweise und definierte Überwachungsauslöser. Das Ergebnis war nicht nur eine bessere Antwort auf den Fragebogen. Es war ein wiederholbarer Prozess für Lieferantenrisiken.

Ihre Organisation kann dasselbe tun.

Beginnen Sie mit dem Zenith Blueprint: An Auditor’s 30-Step Roadmap, um Übermittlungsrisiken mit Risikoregister, Behandlungsplan und Anwendbarkeitserklärung zu verbinden. Nutzen Sie Zenith Controls: The Cross-Compliance Guide, um Cloud-, Lieferantenvereinbarungs- und Lieferantenüberwachungskontrollen nach ISO/IEC 27002:2022 auf GDPR, NIS2, DORA, NIST und Auditerwartungen abzubilden. Operationalisieren Sie die Nachweise anschließend über Clarysec-Richtlinien wie Cloud Usage Policy, Third party and supplier security policy, Legal and Regulatory Compliance Policy, Risk Management Policy und, wo angemessen, die SME-Versionen.

Ein Cloud-bezogenes Transfer Impact Assessment sollte kein Vertriebsnotfall sein. Im Jahr 2026 ist es Teil von Cloud-Governance, Lieferantensicherheit, Rechenschaftspflicht im Datenschutz und operationeller Resilienz. Vertrauen gewinnen diejenigen Organisationen, die schnell nachweisen können, wohin Daten fließen, wer sie berührt, wodurch sie geschützt werden und wie das Risiko über die Zeit gesteuert wird.