Data breach at your supplier: why the responsibility stays with you

At the end of September, attackers hit PK Softech AG, a software supplier to several large Swiss pension funds. None of these funds was hacked itself. Even so, it is their members who are now receiving letters, and their names that are in the headlines.
This is not only a pension fund problem. Almost every organisation hands personal data to service providers for payroll, software, hosting or a project. This article explains what Swiss law requires when a supplier is breached, and what you can prepare.
What happened in the PK Softech attack?
On 29 September 2026, malware that encrypted data was planted at PK Softech. On 8 October the federal government confirmed that data had been stolen, according to PK Softech from its own IT infrastructure rather than its customers' systems. The Office of the Attorney General is investigating.
Publica, the Migros pension fund, Pensionskasse Post and the two Bernese funds are checking whether they are affected. In the worst case, the data includes names, dates of birth, AHV numbers, addresses, and salary and pension details. The funds say pensions themselves are not at risk.
How does your data end up with a supplier in the first place?
There are three routes, and many organisations overlook the third.
- Operations: the provider runs the software for you on its own servers.
- Maintenance and support: to fix a fault, the vendor needs to see the system, often with real data in it.
- Projects: a copy of the data is handed over for a migration or a test.
The pension fund of the City of Zurich shows the third route. On 16 October it confirmed that its members' data had been stolen, even though it does not use PK Softech's system yet. The data had been sent over to prepare a switch planned for early 2027. That is an ordinary part of any project, which is exactly why such copies are missing from so many overviews of where data sits.
Who is responsible when the supplier is hacked?
The Swiss Federal Act on Data Protection (FADP, in German DSG) distinguishes the controller, who decides why and how data is processed, from the processor, who handles the data on the controller's behalf. Under Art. 8, both must ensure data security appropriate to the risk.
Responsibility does not move with the contract, though. Art. 9(2) requires the controller to make sure the processor is able to guarantee data security. The provider may only bring in a third party with your prior approval (Art. 9(3)). Cantonal and municipal bodies are usually covered by cantonal data protection law, which sets out similar duties.
Who has to report what after a breach at a service provider?
- The provider reports to you any breach of data security as soon as possible (Art. 24(3)).
- You report to the FDPIC, the federal data protection commissioner, as soon as possible if the breach is likely to result in a high risk to the people concerned (Art. 24(1)).
- You inform the people affected if this is needed to protect them or if the FDPIC asks you to (Art. 24(4)).
So the decision on whether the risk is high is yours, often made with incomplete information. Three weeks after the attack, PK Softech still could not say which customers were affected.
Why is the breach only the beginning?
Stolen personal data makes the next attack more convincing. An email or call from your supposed pension fund that knows your AHV number and insured salary looks genuine.
That is why the affected funds are explicitly warning members about unusual messages and calls. These follow-up attacks land on your employees and your customers, not on the supplier.
What can you do now?
- Record which providers hold which personal data. Include project copies, test data and support access.
- Hand over anonymised data for tests, and have copies deleted when the project ends. The FADP already requires data to be destroyed or anonymised once it is no longer needed (Art. 6(4)).
- Check your contracts. Agree the notification deadline, your right to review the provider's security, and approval for subcontractors.
- Decide in advance who reports. Agree who judges the risk internally and who files the report with the FDPIC.
- Prepare your team for the follow-up messages. People who know that targeted emails and calls follow a breach are better at spotting them.
You can practise that last point before it matters. Korix uses realistic phishing simulations to test whether your team recognises and reports a convincing message, even one that contains real details.
This article is not legal advice.