Kurzantwort: Ende September 2026 haben Unbekannte einen Softwareanbieter für Pensionskassen angegriffen. Seither melden immer mehr Kassen, dass Daten ihrer Versicherten abgeflossen sein könnten. Angegriffen wurden nicht die Systeme der Kassen. Die Daten lagen beim Lieferanten.

Der Fall wirft eine Frage auf, die sich jede Organisation stellen sollte. In der Praxis werden Lieferanten oft nur mit einem Fragebogen, einem Zertifikat und einem Auftragsbearbeitungsvertrag geprüft. Ob die Daten beim Lieferanten tatsächlich geschützt sind, bleibt dabei offen. Das Datenschutzgesetz (DSG) verlangt mehr. Wer Daten auslagert, muss sich vergewissern, dass der Lieferant die Datensicherheit gewährleisten kann.

Dieser Beitrag fasst zusammen, was bis zum 18. Oktober 2026 bekannt ist. Er zeigt, was der Fall Xplain dazu bereits gelehrt hat und wo Checklisten aufhören. Zum Schluss beschreibt er eine Lieferantenprüfung, die in die Tiefe geht. Die Ursachen des Angriffs klären die laufenden Ermittlungen. Dieser Beitrag beurteilt keine der beteiligten Firmen oder Kassen. Er nimmt den Fall zum Anlass für eine allgemeine Frage.

Laut der Mitteilung des Anbieters haben sich Unbekannte mit Schadsoftware Zugang zu einem Teil seiner IT-Infrastruktur verschafft. Die betroffene Umgebung wurde sofort vom Netz getrennt. Der Anbieter zog externe Spezialisten bei und erstattete Strafanzeige. Seit dem 2. Oktober 2026 sind seine Dienste wieder voll verfügbar. Am 8. Oktober bestätigte der Bund einen Datenabfluss beim Softwarelieferanten der Pensionskasse des Bundes Publica. Die Bundesanwaltschaft ermittelt.

Laut NZZ könnten die Daten von über 100'000 Versicherten und Rentenbeziehenden bei Cyberkriminellen sein. Bestätigt ist diese Zahl nicht.

Im schlimmsten Fall betrifft der Abfluss laut PKZH Name, Geburtsdatum, AHV-Nummer und Kontaktdaten. Dazu kommen Zivilstand, Angaben zu Partnern, IBAN sowie versicherter Lohn und Sparguthaben. Vorsorgegelder und Renten sind laut den Kassen sicher. Die Kantonspolizeien Zürich und Bern warnen aber vor Anrufen falscher Anlageberater, die solche Daten nutzen könnten.

Pensionskassen verwalten ihre Versicherten meist mit spezialisierter Software. Daten gelangen typischerweise auf drei Wegen zu einem Softwarehersteller. Erstens betreibt der Hersteller die Software für die Kasse auf eigenen Systemen. Zweitens braucht er realistische Daten für Tests und Migrationen. Drittens erhält er bei Fehlermeldungen oft echte Datensätze, um den Fehler nachzustellen.

Der Sicherheitsexperte Marc Ruef nennt gegenüber SRF den Betrieb beim Hersteller sowie Tests und Wartung als typische Wege. Anonymisierte oder pseudonymisierte Testdaten wären eine Alternative. Ruef äussert sich dabei allgemein über die Branche: «Daten zu anonymisieren und zu pseudonymisieren, ist sehr aufwändig und auch fehleranfällig.» Manchmal entscheide man sich «für die Wirtschaftlichkeit anstatt für die Sicherheit». Bei der Wahl eines Lieferanten stehe Cybersecurity nach seiner Erfahrung oft nicht weit oben auf der Liste.

Bei der PKZH ist der Weg bekannt. Sie plante den Wechsel auf das System dieses Anbieters auf Anfang 2027. Um zu prüfen, ob die Daten vollständig und korrekt übernommen werden, gab sie dem Anbieter realistische Testdaten. Ihr produktives System lief noch auf einer anderen Software. Für den Test lagen Versichertendaten beim Lieferanten.

Allgemein gilt: Wo eine Kopie der Daten liegt, entscheidet mit darüber, wen ein Angriff bei einem Lieferanten trifft. Dazu kommt ein Klumpenrisiko für die ganze Branche. Ein spezialisierter Anbieter bedient viele Kassen, und ein einziger Angriff trifft sie gleichzeitig. Eine Kasse, die nur ihre eigenen Systeme absichert, sieht dieses Risiko nicht.

Im Mai 2023 traf ein Ransomware-Angriff die Softwarefirma Xplain. Ransomware ist Schadsoftware, die Daten verschlüsselt und oft vorher kopiert. Xplain entwickelte Software unter anderem für das Bundesamt für Polizei (fedpol). Auf den Systemen von Xplain lagen auch Personendaten der Bundesverwaltung.

Der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte (EDÖB) untersuchte den Fall. Seine Schlussberichte vom 25. April 2024 halten unter anderem fest:

• Fedpol hatte nicht klar geregelt, ob und unter welchen Bedingungen bei Wartung und Support Personendaten an Xplain gehen dürfen.
• Xplain bewahrte Personendaten nach der Fehlerbehebung weiter auf, statt sie zu löschen.
• Fedpol prüfte Xplain nicht regelmässig, etwa mit Audits. Als Grund nannte das Amt fehlende personelle und finanzielle Ressourcen.
• Der EDÖB hielt fest, der Auftraggeber sei verpflichtet, den Auftragsbearbeiter «sorgfältig auszuwählen, zu instruieren und soweit nötig zu überwachen».

Die Empfehlungen an fedpol sind konkret. Zuerst ist zu klären, ob Personendaten die eigenen Systeme überhaupt verlassen müssen. Wenn ja, sind Datenminimierung und Datensicherheit konsequent umzusetzen. Bei der nächsten Entscheidung über die Zusammenarbeit ist zu kontrollieren, ob ein zertifiziertes Informationssicherheits-Managementsystem (ISMS) besteht. Die Einhaltung ist regelmässig zu kontrollieren, durch interne oder externe Prüfungen oder eingeforderte Nachweise.

Öffentlich bekannt sind keine Hinweise, dass beim betroffenen Anbieter vergleichbare Mängel bestanden. Die Ursachen des Angriffs klären die laufenden Ermittlungen. Der Fall Xplain dient hier nur als Beispiel für die Fragen, die sich stellen, wenn Daten für Tests, Migrationen oder Support zum Hersteller gehen. Der EDÖB beurteilte den Fall Xplain noch nach altem Recht. Er hielt fest, dass das geltende DSG zu keinem anderen Ergebnis führen würde.

Art. 9 Abs. 2 DSG ist knapp formuliert: «Der Verantwortliche muss sich insbesondere vergewissern, dass der Auftragsbearbeiter in der Lage ist, die Datensicherheit zu gewährleisten.» Sich vergewissern heisst, sich selbst ein Bild zu machen. Ein unterschriebener Vertrag ist dafür eine Voraussetzung, aber kein Beleg.

Weitere Pflichten ergänzen das. Verantwortliche und Auftragsbearbeiter gewährleisten «eine dem Risiko angemessene Datensicherheit» (Art. 8 DSG). Schutzbedarf, Risiko und Massnahmen sind «über die gesamte Bearbeitungsdauer hinweg zu überprüfen» (Art. 1 Abs. 5 DSV). Personendaten werden vernichtet oder anonymisiert, sobald sie für den Zweck nicht mehr erforderlich sind (Art. 6 Abs. 4 DSG). Für Testdaten heisst das: Nach dem Test werden sie gelöscht. Erleidet der Auftragsbearbeiter eine Verletzung der Datensicherheit, meldet er sie dem Verantwortlichen «so rasch als möglich» (Art. 24 Abs. 3 DSG).

Das DSG gilt für private Vorsorgeeinrichtungen und für Einrichtungen des Bundes wie Publica. Kassen von Kantonen und Gemeinden unterstehen teils kantonalem Datenschutzrecht. Die Frage, ob man den eigenen Lieferanten wirklich kennt, stellt sich dort genauso. Die folgende Gegenüberstellung zeigt den Unterschied zwischen Checkliste und Prüfung.

Die linke Spalte füllt ein Lieferant in einer Stunde aus. Die rechte verlangt Nachweise, Gespräche und technische Tests. Ob die Daten geschützt sind, zeigt erst die rechte Spalte.

Eine tiefe Prüfung muss nicht jeden Lieferanten gleich behandeln. Sie beginnt bei jenen, die echte Versichertendaten auf eigenen Systemen halten. Wir empfehlen ein Vorgehen in fünf Schritten.

1. Datenflüsse kartieren. Welche Daten liegen bei welchem Lieferanten, auch als Kopie für Tests, Migrationen oder Fehleranalysen? Der produktive Datenfluss ist meist dokumentiert, die Kopien oft nicht.
2. Echtdaten ausserhalb der Produktion vermeiden. Für Tests und Migrationen genügen oft synthetische oder pseudonymisierte Daten. Pseudonymisiert heisst: Namen und AHV-Nummern werden durch Kennzeichen ersetzt, und der Schlüssel bleibt bei der Kasse. Sind Echtdaten unvermeidbar, gelten ein minimaler Ausschnitt, eine feste Löschfrist und eine schriftliche Löschbestätigung.
3. Nachweise statt Selbstauskunft. Verlangen Sie den Geltungsbereich des Zertifikats, die Zusammenfassung des letzten Penetrationstests und den Stand der offenen Befunde. Ein Zertifikat ohne Geltungsbereich sagt wenig.
4. Technisch prüfen lassen. Vereinbaren Sie das Recht, die Umgebung des Lieferanten durch unabhängige Fachleute prüfen zu lassen. Ein Penetrationstest simuliert einen Angriff auf Portal, Schnittstellen und Fernzugänge. Ein Schwachstellenscan sucht automatisiert und regelmässig nach bekannten Lücken. Ein Security Architecture Review prüft den Aufbau: Wo liegen Test- und Migrationsumgebungen, wie sind sie getrennt, und wer hat Zugriff?
5. Vertrag und Ernstfall regeln. In den Vertrag gehören eine Meldefrist bei Vorfällen, Prüfrechte und Löschpflichten. Dazu kommen die Genehmigung von Unterauftragsbearbeitern und ein Plan für den Ausstieg. Üben Sie einmal, was geschieht, wenn der Lieferant einen Angriff meldet.

Technische Prüfungen bei einem Lieferanten brauchen immer dessen Zustimmung und klare Regeln. Wer das Prüfrecht erst nach einem Vorfall verlangt, verhandelt aus einer schwachen Position. Der Aufwand richtet sich nach dem Risiko. Beim Lieferanten der Kernsoftware mit allen Versichertendaten rechtfertigt es regelmässige technische Prüfungen. Für einen Lieferanten ohne Zugang zu Personendaten genügt ein Fragebogen.

Angreifer: persönlicher Betrug in grosser Zahl

Gestohlene Pensionskassen-Daten sind für Betrüger besonders wertvoll. Sie verbinden Name, Arbeitgeber, Lohn und Sparguthaben. Mit generativer KI lassen sich daraus in Minuten persönliche Nachrichten in fehlerfreiem Deutsch, Französisch oder Italienisch erstellen. Auch Anrufe mit künstlich erzeugter Stimme werden einfacher. Ein Datenabfluss beim Lieferanten wird so zum Betrugsrisiko für die Versicherten der Kasse.

Lieferanten: KI im Support, in der Entwicklung und bei Migrationen

Auch Softwarelieferanten setzen KI ein. Supportteams lassen Tickets zusammenfassen. Entwicklerinnen und Entwickler arbeiten mit KI-Assistenten, die Code schreiben und Testumgebungen bedienen. Bei Migrationen helfen Sprachmodelle, Datenfelder zuzuordnen. Jeder dieser Einsätze kann Versichertendaten berühren. Das gilt für die ganze Branche und ist kein Hinweis auf den aktuellen Fall.

Ältere Lieferanten-Fragebogen fragen danach meist nicht. Nach Art. 9 Abs. 3 DSG darf der Auftragsbearbeiter die Bearbeitung nur mit vorgängiger Genehmigung des Verantwortlichen einem Dritten übertragen. Ein KI-Dienst, der Versichertendaten verarbeitet, ist in der Regel ein solcher Dritter. Fragen Sie deshalb: Welche KI-Dienste nutzt der Lieferant, mit welchen Daten und unter welchem Vertrag? Wird KI-generierter Code vor dem Einsatz geprüft?

Dieselbe Frage stellt sich im eigenen Haus. Wer nicht weiss, wo intern KI mit Versichertendaten arbeitet, kann es beim Lieferanten kaum beurteilen. Ein AI Governance Check erfasst die eingesetzten KI-Anwendungen, auch in eingekaufter Software, und ordnet ihre Risiken ein.

Der Angriff auf den Softwareanbieter ist noch nicht aufgearbeitet, seine Ursachen sind öffentlich nicht bekannt. Unabhängig davon gilt allgemein: Daten sind nur so gut geschützt wie jeder Ort, an dem eine Kopie von ihnen liegt. Eine Lieferanten-Checkliste zeigt, was ein Lieferant zusichert. Ob die Zusicherung hält, zeigen erst Nachweise und technische Prüfungen.

SIDD unterstützt Organisationen mit sensiblen Personendaten bei diesem Schritt. Ein Penetrationstest zeigt, wo Portale, Schnittstellen und Fernzugänge verwundbar sind. Regelmässige Schwachstellenscans helfen, bekannte Lücken zu finden, bevor Angreifer sie nutzen. Ein Security Architecture Review prüft, wie Daten zwischen Ihnen und Ihren Lieferanten fliessen und wo Test- und Migrationsumgebungen liegen. Der AI Governance Check zeigt, wo KI mit Ihren Daten arbeitet. Prüfungen bei einem Lieferanten stimmen wir immer mit diesem ab. Eine erste Einordnung besprechen wir gerne über das Kontaktformular.

Quellen

Alle Quellen abgerufen am 18. Oktober 2026.

• Der Bundesrat: Cyberangriff auf Softwarelieferant von Publica: Datenabfluss bestätigt, Medienmitteilung vom 8. Oktober 2026
• Mitteilung des betroffenen Softwareanbieters zum Cyberangriff
• Pensionskasse Stadt Zürich: Mitteilung zum Cyberangriff auf ihren Softwareanbieter, Stand 15. Oktober 2026
• SRF: Wie konnten heikle Daten bei externer Softwarefirma landen?, 10. Oktober 2026
• Netzwoche: Bundespensionskasse Publica meldet Datenabfluss, 8. Oktober 2026, mit Nachträgen bis 15. Oktober 2026
• IPE: Swiss pension funds investigate potential data breach after cyber attack, 9. Oktober 2026
• Inside IT: Cyberangriff auf Pensionskassen-Lieferant zieht Kreise, 14. Oktober 2026
• NZZ: Immer mehr betroffene Pensionskassen (Bezahlschranke)
• EDÖB: Schlussbericht und Empfehlungen in Sachen fedpol aufgrund Ransomware-Vorfall, 25. April 2024
• EDÖB: Schlussbericht und Empfehlungen in Sachen Xplain AG aufgrund Ransomware-Vorfall, 25. April 2024
• Bundesgesetz über den Datenschutz (DSG, SR 235.1), Fedlex, Stand 7. Juli 2025
• Verordnung über den Datenschutz (DSV, SR 235.11), Fedlex, Stand 1. Dezember 2025

Stand der Informationen: 18. Oktober 2026. Die Abklärungen der Kassen und die Ermittlungen laufen, einzelne Angaben können sich noch ändern. Dieser Beitrag ist eine allgemeine Information und keine Rechtsberatung.