Swift CSP im Gesamtbild: Auslagerung, Gegenparteien, Standards-Mapping und Aufsichtsrecht

Problem in der Praxis

Institute, die Swift über einen Dienstleister nutzen, halten das CSCF oft für dessen Sache. Das trifft nicht zu: Die Verantwortung für die Attestierung bleibt beim Nutzer, der Dienstleister liefert nur Nachweise zu. Zugleich wird das CSCF intern mit Aufsichtsanforderungen vermischt, als wäre eine gute Attestierung ein Beleg für die Erfüllung von DORA oder umgekehrt.

CISO-Einordnung

Auslagerung (CSCF v2027, S. 18 bis 19, Kontrolle 2.8):

• Nutzer bleiben für die gesamte Architektur verantwortlich, auch für ausgelagerte Teile.
• Sie müssen die Outsourcing Agents Security Requirements Baseline von Swift heranziehen und sich vom Dritten hinreichend versichern lassen (reasonable comfort), dass das Ausgelagerte mindestens wie intern und nach den CSCF-Kontrollen geschützt ist; der Dritte kann dafür auf sein Compliance-Programm mit Zertifizierungen wie SOC 2 Typ 2, PCI DSS oder NIST zurückgreifen.
• Swift-Dienstleister wie Service Bureaux gelten standardmäßig nicht als Outsourcing-Partner, weil sie eigenen Anbieterprogrammen unterliegen; betreiben sie aufgrund eines eigenen Vertrags Komponenten des Nutzers, gelten sie dafür als Outsourcing-Partner.
• Wer nur Anwendungen eines Outsourcing-Partners nutzt, die über einen Swift-Dienstleister angebunden sind, wählt Architekturtyp A4 und stützt sich für die eigene Attestierung auf die Ergebnisse des Partners (S. 26).

Gegenparteien: Nutzer können anderen Instituten Einsicht in ihre Attestierung gewähren; Swift beschreibt das als Grundlage für risikobasierte Entscheidungen über Geschäftsbeziehungen und hat dafür einen Leitfaden zur Beurteilung des Cyberrisikos von Gegenparteien veröffentlicht (S. 5 und 10).

Standards-Mapping (S. 10 und 128): Swift bildet die Kontrollen auf NIST CSF 1.1 und 2.0, ISO 27002:2022, PCI DSS 4.0, SOC 2 und UCF ab. Ist die Swift-Infrastruktur im Geltungsbereich einer solchen Zertifizierung, zeigt das Mapping, welche Kontrollen sich entsprechen. Ob das für die CSCF-Konformität genügt, muss der Nutzer selbst beurteilen.

Aufsichtsrecht (Auslegung): Das CSCF nennt DORA, NIS-2 oder nationale Aufsichtsanforderungen nicht. Für Institute unter DORA bleibt das IKT-Risikomanagement nach DORA eine eigene Pflicht; das CSCF kann Maßnahmen und Nachweise für den Swift-Teil der IKT-Landschaft beisteuern, ist aber weder Umsetzung noch Nachweis von DORA. Umgekehrt macht eine DORA-konforme Organisation die Swift-Attestierung nicht entbehrlich.

Lücken im Korpus: Customer Security Controls Policy, Independent Assessment Framework, CSP-FAQ und Outsourcing Agents Security Requirements Baseline liegen nicht vor. Wer Bewertungs-, Melde- oder Auslagerungsfragen verbindlich klären muss, braucht diese Dokumente von Swift.

Umsetzungsperspektive

• Für jeden Dienstleister mit Swift-Bezug festlegen, ob er Outsourcing-Partner im Sinne des CSCF ist.
• Vertraglich Nachweise zum CSCF-Schutzniveau und deren Aktualität vereinbaren.
• Die Swift-Umgebung bewusst in den Geltungsbereich bestehender Zertifizierungen aufnehmen, wenn diese als Nachweis dienen sollen.
• Attestierungen wichtiger Gegenparteien in die Bewertung von Geschäftsbeziehungen einbeziehen.
• CSCF-Nachweise im DORA-Register und Auslagerungsmanagement verknüpfen, ohne Gleichwertigkeit zu unterstellen.

Typische Fehler

1. Die Attestierung wird dem Dienstleister überlassen.
2. Ein SOC-2- oder ISO-Zertifikat des Dienstleisters wird ungeprüft als CSCF-Nachweis übernommen.
3. Service Bureaux werden pauschal als Outsourcing-Partner behandelt oder pauschal davon ausgenommen.
4. Die CSCF-Attestierung wird als Nachweis für DORA verwendet.
5. Attestierungen von Gegenparteien werden nie angesehen.

Risiken und Trade-offs

Ausgelagerter Betrieb senkt den eigenen Betriebsaufwand, erhöht aber den Steuerungsaufwand für Nachweise. Die Wiederverwendung von Zertifizierungen spart Prüfaufwand, solange ihr Geltungsbereich und ihre Aktualität passen. Eine strikte Trennung von CSCF und Aufsichtsrecht schafft Klarheit, kostet aber doppelte Dokumentation, wenn die Nachweise nicht verknüpft werden.

Entscheidungspunkte

• Welche Dienstleister sind Outsourcing-Partner im Sinne des CSCF?
• Welche Nachweise verlangen wir von ihnen, und wie aktuell müssen sie sein?
• Welche Gegenparteien prüfen wir anhand ihrer Attestierung?
• Wie verknüpfen wir CSCF-Nachweise mit DORA und Auslagerungsmanagement?

Praktische Empfehlungen

1. Behalten Sie die Verantwortung für die Attestierung im Haus.
2. Vereinbaren Sie mit Outsourcing-Partnern CSCF-bezogene Nachweise vertraglich.
3. Nutzen Sie das Mapping von Swift als Ausgangspunkt, nicht als Beweis.
4. Beziehen Sie die Attestierung von Gegenparteien in Ihre Risikobewertung ein.
5. Beschaffen Sie Policy, Bewertungsrahmen und Auslagerungsbaseline von Swift.

Relevante Normreferenzen

• Swift, Customer Security Controls Framework v2027 (10.07.2026), Outsourcing, Outsourcing agent reliance, Kontrolle 2.8, Integration with Security Governance and Risk Management, Anhang Mapping to Industry Standards.
• Verordnung (EU) 2022/2554 (DORA), siehe Track dora.