Swift CSP und CSCF: was das Programm verlangt, wie attestiert wird und was sich mit v2027 ändert

Problem in der Praxis

Das CSCF wird oft als jährliche Formalie behandelt, die der Zahlungsverkehr mit einem Dienstleister abarbeitet. Swift sieht das ausdrücklich anders: Die Kontrollen sind weder abschließend noch eine einmalige Übung, sondern sollen in das laufende Sicherheits- und Risikomanagement eingebettet werden. Wer erst im Herbst mit der Attestierung beginnt, stellt zudem oft fest, dass Scope, Architekturtyp oder Dienstleisternachweise nicht geklärt sind.

CISO-Einordnung

• Aufbau: drei Ziele (eigene Umgebung sichern, Zugriffe kennen und begrenzen, erkennen und reagieren), darunter sieben Prinzipien und 32 Kontrollen (CSCF v2027, S. 4 und 9).
• Pflicht und Empfehlung: Pflichtkontrollen bilden die Basis für alle Nutzer auf ihrer Swift-Infrastruktur; Empfehlungskontrollen sind gute Praxis und können in späteren Fassungen verpflichtend werden. Neue Pflichtkontrollen führt Swift nach eigener Beschreibung in der Regel zuerst als Empfehlung ein, mit mindestens zwei Zyklen Vorlauf (S. 4 und 27).
• Zyklus: Eine neue Fassung erscheint in der Regel im Juli; attestiert wird gegen sie ab Juli des Folgejahres, jeweils bis Jahresende (S. 4 bis 5). Daraus folgt (Auslegung): Wer 2026 attestiert, attestiert gegen die Vorgängerfassung v2026; v2027 ist die Fassung für die Attestierung 2027.
• Gemeinschaft: Änderungen werden über eine CSCF Working Group mit der Nutzergemeinschaft abgestimmt; die Ergebnisse gehen auch an die Swift-Aufsicht (S. 5).
• Rolle des CISO: Swift nennt den CISO ausdrücklich als die Funktion, die das Sicherheitsprogramm priorisiert und die Unterstützung der Leitung einholt (S. 10).
• Nicht im Korpus: Die Customer Security Controls Policy, in der Attestierungs- und Berichtswege geregelt sind, und das Independent Assessment Framework liegen diesem Track nicht vor. Aussagen über Bewertungspflichten, Fristen und Folgen fehlender Attestierung sind deshalb dort nachzulesen.

Umsetzungsperspektive

• Verantwortung festlegen: Der CISO steuert, der Zahlungsverkehr und der Betrieb liefern zu.
• Architekturtyp und Scope früh im Jahr klären (siehe swift-002).
• Fassungswechsel planen: Die im Juli erscheinende Fassung gilt für die Attestierung des Folgejahres; Änderungen lassen sich ein Jahr im Voraus einplanen.
• Empfehlungskontrollen als Vorschau auf künftige Pflichten lesen.
• Einsichtsfreigaben an Gegenparteien bewusst steuern.

Typische Fehler

1. Die Attestierung wird als Einmalformular verstanden und nicht in das Sicherheitsprogramm eingebunden.
2. Es wird gegen die falsche Fassung geplant, weil Veröffentlichungs- und Attestierungsjahr verwechselt werden.
3. Empfehlungskontrollen werden ignoriert, bis sie verpflichtend werden.
4. Der Architekturtyp wird zu eng gewählt.
5. Niemand weiß, welche Gegenparteien die Attestierung einsehen können.

Risiken und Trade-offs

Eine knappe, rein formale Attestierung spart Aufwand, schwächt aber die eigene Position gegenüber Gegenparteien, die die Attestierung einsehen, und lässt die eigentlichen Betrugsrisiken bestehen. Eine weite Einbettung in das Sicherheitsprogramm kostet Koordination, nutzt aber bestehende Richtlinien und Kontrollen mit.

Entscheidungspunkte

• Wer verantwortet die Attestierung, und wer zeichnet sie intern ab?
• Gegen welche Fassung wird in diesem Jahr attestiert, und was ändert sich im nächsten?
• Welche Empfehlungskontrollen setzen wir schon jetzt um?
• Welchen Gegenparteien geben wir Einsicht?

Praktische Empfehlungen

1. Verankern Sie das CSCF im Sicherheitsprogramm, nicht nur im Zahlungsverkehr.
2. Lesen Sie jede Juli-Fassung als Planungsgrundlage für das Folgejahr.
3. Behandeln Sie Empfehlungskontrollen als Vorlauf künftiger Pflichten.
4. Klären Sie Scope und Architekturtyp vor dem Sommer.
5. Beschaffen Sie Policy und Bewertungsrahmen von Swift, bevor Sie Nachweise planen.

Relevante Normreferenzen

• Swift, Customer Security Controls Framework v2027, Detailed Description (10.07.2026), Executive Summary, Framework Objectives and Principles, Security Controls Structure.
• Swift Customer Security Controls Policy und Independent Assessment Framework (im Korpus nicht verfügbar).