Cloud migration in Swiss banking after the revised FADP

Every Swiss financial institution we speak to has the same two beliefs about cloud migration: that it is now permitted, and that it is now complicated. Both are true, but not for the reasons usually given.

The revised Federal Act on Data Protection did not introduce a data-residency requirement. What it sharpened is accountability: you must be able to demonstrate, on request, where client-identifying data sits, who can reach it, and under what legal basis.

What actually blocks a migration

Three things, in this order.

• Client-identifying data spread across systems nobody mapped. The migration cannot be scoped because the data cannot be located.
• Outsourcing arrangements that predate the current rules. Contracts exist, but not the evidence trail the rules now expect.
• Access paths through third parties. Support vendors with standing production access are the finding that most often stops a programme.

None of these are cloud problems. They are inventory problems that the cloud makes visible.

Does the revised FADP require Swiss data residency?

No. The revised FADP does not mandate that personal data remain in Switzerland. Transfers abroad are permitted where the destination provides adequate protection or where appropriate safeguards are in place. Residency is frequently adopted as an internal policy or a supervisory expectation, which is a different thing from a legal requirement and should be argued on its own merits.

What has to be documented before a migration?

At minimum: a data inventory that identifies client-identifying data by system, a record of processing activities, the legal basis for any cross-border transfer, and a demonstrable access model showing who can reach production data and how that access is granted, reviewed and revoked.

A sequence that works

1. Inventory client-identifying data before choosing a target architecture. The inventory usually changes the architecture.
2. Fix the access model in the current estate first. Migrating a broken access model reproduces it at scale.
3. Migrate one non-critical workload end to end, including the evidence trail. The first migration is a rehearsal for the audit, not for the technology.
4. Only then plan the core.

Institutions that follow this sequence tend to move faster overall, because the supervisory conversation stops being a blocker and becomes a checklist.

What this costs in time

Budget one to three months for the inventory in a mid-sized institution, and expect it to surface at least one access finding that has to be remediated before anything moves. That finding is the value of the exercise, not a delay to it.