Short answer: At the end of September 2026, unknown attackers breached a software provider for pension funds. Since then, more and more funds have reported that their members’ data may have been taken. The funds’ own systems were not the target. The data sat with the vendor.

The case raises a question that every organisation should ask itself. In practice, vendors are often assessed only with a questionnaire, a certificate and a data processing agreement. Whether the data is actually protected at the vendor remains open. The Swiss Federal Act on Data Protection (FADP) requires more. Anyone who outsources data must satisfy themselves that the vendor is able to guarantee data security.

This article summarises what is known as of 18 October 2026. It shows what the Xplain case already taught and where checklists stop. Finally, it describes a vendor review that goes deeper. The causes of the attack are for the ongoing investigations to establish. This article does not assess any of the companies or pension funds involved. It takes the case as an occasion for a general question.

According to the provider’s statement, unknown parties used malware to gain access to part of its IT infrastructure. The affected environment was disconnected immediately. The company brought in external specialists and filed a criminal complaint. Its services have been fully available again since 2 October 2026. On 8 October, the Swiss government confirmed a data leak at the software supplier of Publica, the federal pension fund. The Office of the Attorney General of Switzerland has opened an investigation.

According to the NZZ, the data of more than 100,000 insured members and pensioners could now be in the hands of cybercriminals. This figure has not been confirmed.

In the worst case, according to PKZH, the leak covers name, date of birth, AHV number (the Swiss social security number) and contact details. Marital status, information on partners, IBAN, insured salary and savings balance come on top. The funds say pension assets and pensions are safe. The cantonal police of Zurich and Bern, however, warn of calls from fake investment advisers who could use such data.

Pension funds usually manage their members with specialised software. Data typically reaches a software vendor in three ways. First, the vendor runs the software for the fund on its own systems. Second, it needs realistic data for tests and migrations. Third, it often receives real records with bug reports so that it can reproduce the error.

Security expert Marc Ruef told SRF that operation by the vendor, as well as testing and maintenance, are typical routes. Anonymised or pseudonymised test data would be an alternative. Ruef speaks generally about the sector: “anonymising and pseudonymising data is very laborious and also error-prone” (translated from German). Sometimes, he says, cost efficiency wins over security. In his experience, cybersecurity often does not rank very high on the list when a vendor is chosen.

In PKZH’s case, the route is known. The fund planned to move to this provider’s system at the beginning of 2027. To check whether the data would transfer completely and correctly, it gave the vendor realistic test data. Its production system was still running on different software. For the test, member data was held by the vendor.

As a general rule, where a copy of the data sits helps determine who is hit by an attack on a vendor. On top of that, there is a concentration risk for the whole sector. One specialised vendor serves many funds, and a single attack hits them all at once. A fund that secures only its own systems does not see this risk.

In May 2023, a ransomware attack hit the software company Xplain. Ransomware is malicious software that encrypts data and often copies it first. Xplain developed software for, among others, the Federal Office of Police (fedpol). Personal data of the federal administration was also stored on Xplain’s systems.

The Federal Data Protection and Information Commissioner (FDPIC) investigated the case. Among other things, its final reports of 25 April 2024 found the following:

• fedpol had not clearly defined whether, and under which conditions, personal data could go to Xplain during maintenance and support.
• Xplain kept personal data after fixing errors instead of deleting it.
• fedpol did not check Xplain regularly, for example through audits. The office cited a lack of staff and financial resources.
• The FDPIC stated that the client is obliged to select the processor carefully, to instruct it and to monitor it where necessary.

The recommendations to fedpol are specific. First, clarify whether personal data needs to leave your own systems at all. If it does, apply data minimisation and data security consistently. At the next decision on the collaboration, check whether a certified information security management system (ISMS) is in place. Monitor compliance regularly, through internal or external audits or by requiring evidence.

There are no public indications of comparable shortcomings at the affected provider. The causes of the attack are for the ongoing investigations to establish. The Xplain case serves here only as an example of the questions that arise when data goes to a vendor for testing, migration or support. The FDPIC assessed the Xplain case under the old law. It stated that the current FADP would not lead to a different result.

Art. 9 para. 2 FADP is brief: “The controller must satisfy itself in particular that the processor is able to guarantee data security.” Satisfying yourself means forming your own view. A signed contract is a prerequisite for that, but not proof.

Further duties complement this. Controllers and processors must guarantee “a level of data security appropriate to the risk” (Art. 8 FADP). The need for protection, the risk and the measures “shall be reviewed throughout the period of processing” (Art. 1 para. 5 of the Ordinance on Data Protection, DPO). Personal data “shall be destroyed or anonymised as soon as they are no longer required for the purpose of processing” (Art. 6 para. 4 FADP). For test data, this means deleting it after the test. If the processor suffers a data security breach, it notifies the controller “as quickly as possible” (Art. 24 para. 3 FADP).

The FADP applies to private pension funds and to federal institutions such as Publica. Cantonal and municipal funds are partly subject to cantonal data protection law. The question of whether you really know your vendor arises there just the same. The following comparison shows the difference between a checklist and a review.

A vendor can fill in the left column in an hour. The right column requires evidence, conversations and technical tests. Only the right column shows whether the data is protected.

An in-depth review does not have to treat every vendor the same. It starts with those that hold real member data on their own systems. We recommend a five-step approach.

1. Map the data flows. Which data sits with which vendor, including copies for tests, migrations or error analysis? The production data flow is usually documented. The copies often are not.
2. Avoid real data outside production. Synthetic or pseudonymised data is often sufficient for tests and migrations. Pseudonymised means that names and AHV numbers are replaced by codes, and the key stays with the fund. Where real data cannot be avoided, use a minimal extract, a fixed deletion deadline and written confirmation of deletion.
3. Evidence instead of self-declaration. Ask for the scope of the certificate, the summary of the last penetration test and the status of open findings. A certificate without a scope says little.
4. Have it tested technically. Agree on the right to have the vendor’s environment reviewed by independent specialists. A penetration test simulates an attack on the portal, interfaces and remote access. A vulnerability scan searches automatically and regularly for known weaknesses. A Security Architecture Review examines the design: where are test and migration environments, how are they separated, and who has access?
5. Settle the contract and the emergency. The contract should include a notification deadline for incidents, audit rights and deletion duties. Add the approval of sub-processors and an exit plan. Rehearse once what happens when the vendor reports an attack.

Technical reviews at a vendor always require the vendor’s consent and clear rules. Anyone who asks for audit rights only after an incident negotiates from a weak position. The effort should follow the risk. For the vendor of the core software holding all member data, the risk justifies regular technical reviews. For a vendor without access to personal data, a questionnaire is enough.

Attackers: personalised fraud at scale

Stolen pension fund data is especially valuable to fraudsters. It combines name, employer, salary and savings. With generative AI, it takes minutes to turn this into personal messages in flawless German, French or Italian. Calls with synthetic voices are also getting easier. A data leak at the vendor thus becomes a fraud risk for the fund’s members.

Vendors: AI in support, development and migrations

Software vendors use AI too. Support teams have tickets summarised. Developers work with AI assistants that write code and operate test environments. In migrations, language models help to map data fields. Each of these uses can touch member data. This applies to the whole sector and is no indication about the current case.

Older vendor questionnaires rarely ask about this. Under Art. 9 para. 3 FADP, “the processor may only assign processing to a third party with prior approval from the controller”. An AI service that processes member data is usually such a third party. So ask: which AI services does the vendor use, with which data and under which contract? Is AI-generated code reviewed before it goes live?

The same question arises in-house. If you do not know where AI works with member data internally, you can hardly assess it at the vendor. An AI Governance Check records the AI applications in use, including in purchased software, and assesses their risks.

The attack on the software provider has not yet been fully investigated, and its causes are not publicly known. Regardless of this, a general rule applies: data is only as well protected as every place where a copy of it is stored. A vendor checklist shows what a vendor promises. Evidence and technical reviews show whether the promise holds.

SIDD supports organisations that handle sensitive personal data with this step. A penetration test shows where portals, interfaces and remote access are vulnerable. Regular vulnerability scans help to find known weaknesses before attackers exploit them. A Security Architecture Review examines how data flows between you and your vendors and where test and migration environments sit. The AI Governance Check shows where AI works with your data. We always coordinate reviews at a vendor with that vendor. We are happy to discuss an initial assessment via the contact form.

Sources

All sources accessed on 18 October 2026.

• Federal Council: Cyber attack on Publica software supplier: data leak confirmed, press release of 8 October 2026
• Statement of the affected software provider on the cyberattack (in German)
• Pensionskasse Stadt Zürich: statement on the cyberattack on its software provider, as of 15 October 2026 (in German)
• SRF: Wie konnten heikle Daten bei externer Softwarefirma landen?, 10 October 2026 (in German)
• Netzwoche: Bundespensionskasse Publica meldet Datenabfluss, 8 October 2026, updated until 15 October 2026 (in German)
• IPE: Swiss pension funds investigate potential data breach after cyber attack, 9 October 2026
• Inside IT: Cyberangriff auf Pensionskassen-Lieferant zieht Kreise, 14 October 2026 (in German)
• NZZ: Immer mehr betroffene Pensionskassen (paywall, in German)
• FDPIC: Final report and recommendations regarding fedpol following a ransomware incident, 25 April 2024 (in German)
• FDPIC: Final report and recommendations regarding Xplain AG following a ransomware incident, 25 April 2024 (in German)
• Federal Act on Data Protection (FADP, SR 235.1), Fedlex, status as of 7 July 2025 (English translation, not legally binding)
• Ordinance on Data Protection (DPO, SR 235.11), Fedlex, status as of 1 December 2025 (English translation, not legally binding)

Information as of 18 October 2026. The funds’ investigations and the criminal investigation are ongoing, and individual details may still change. This article is general information and not legal advice.