Swiss Data Pro­tec­tion Legis­la­ti­on in a Nutshell

14.12.2023 / David Vasella

This note sets out the key pro­vi­si­ons of the revi­sed Swiss Data Pro­tec­tion Act, which ente­red into force on 1 Sep­tem­ber 2023, along with the revi­sed Data Pro­tec­tion Ordi­nan­ce. The note does not include a com­pa­ri­son with the for­mer ver­si­on of the Act and does not address spe­ci­fic use cases. It inclu­des refe­ren­ces to the GDPR to pro­vi­de con­text on Swiss law requirements.

  • Gene­ral information

    Appli­ca­ble provisions

    As with most count­ries, Switz­er­land regu­la­tes the pro­ce­s­sing of per­so­nal data by gene­ral legis­la­ti­on and pro­vi­des for stric­ter or dif­fe­rent rules in sec­tor-spe­ci­fic regu­la­ti­on. Data pro­ce­s­sing is gover­ned pri­ma­ri­ly by

    • the Fede­ral Data Pro­tec­tion Act (FDPA), and
    • its ordi­nan­ces in their cur­rent form, inclu­ding the Ordi­nan­ce to the Fede­ral Act on Data Pro­tec­tion (FDPO). The FDPO con­ta­ins more detail­ed pro­vi­si­ons about trans­fers abroad and rules about the sub­ject access right. A less rele­vant ordi­nan­ce is the Ordi­nan­ce on Data Pro­tec­tion Cer­ti­fi­ca­ti­on.
      In addi­ti­on, a num­ber of pro­vi­si­ons in other laws rest­rict or per­mit pro­ce­s­sing per­so­nal data, in par­ti­cu­lar in the public sec­tor (for exam­p­le man­da­to­ry health insu­rance or home­land secu­ri­ty) and in regu­la­ted mar­kets (for exam­p­le tele­com­mu­ni­ca­ti­on or ban­king and finan­ce). The­se laws include:
    • the Tele­com­mu­ni­ca­ti­on Act, which regu­la­tes the use of coo­kies and other data stored on user devices and rest­ricts the use and dis­clo­sure of tele­com­mu­ni­ca­ti­on data by tele­com­mu­ni­ca­ti­ons ser­vice pro­vi­ders (inclu­ding pro­vi­ders of over-the-top (OTT) ser­vices), and requi­res them to take mea­su­res to pre­vent unso­li­ci­ted e‑mail marketing;
    • the Fede­ral Act on the Sur­veil­lan­ce of Post and Tele­com­mu­ni­ca­ti­ons (FSPTA), which inclu­des reten­ti­on and coope­ra­ti­on obli­ga­ti­ons for pro­vi­ders of OTT ser­vices and may requi­re them to iden­ti­fy their users;
    • the Code of Obli­ga­ti­ons, which rest­ricts the pro­ce­s­sing of employee data;
    • the Unfair Com­pe­ti­ti­on Act, which governs unso­li­ci­ted e‑mail adver­ti­se­ment and other forms of elec­tro­nic com­mer­cial com­mu­ni­ca­ti­ons (but not ban­ner ads and other ads dis­play­ed for exam­p­le in a con­tent feed in an app);
    • a num­ber of pro­vi­si­ons that pro­tect con­fi­den­tia­li­ty, for exam­p­le the Fede­ral Act on Ban­king and Savings Banks, which rest­ricts dis­clo­sing cli­ent-iden­ti­fy­ing data by banks, the Fede­ral Act on Finan­cial Insti­tu­ti­ons with simi­lar sec­re­cy pro­vi­si­ons for regu­la­ted insti­tu­ti­ons, or the Cri­mi­nal Code, which rest­ricts dis­clo­sing busi­ness secrets (which may or may not include per­so­nal data) to reci­pi­en­ts abroad.
      Switz­er­land is not a mem­ber of the Euro­pean Uni­on or the Euro­pean Eco­no­mic Area and has not imple­men­ted the for­mer EU Data Pro­tec­tion Direc­ti­ve or the Gene­ral Data Pro­tec­tion Regu­la­ti­on (GDPR). Howe­ver, the Euro­pean Com­mis­si­on has found Switzerland’s data pro­tec­tion legis­la­ti­on to pro­vi­de an ade­qua­te level of data pro­tec­tion. Switzerland’s ade­qua­cy fin­ding is curr­ent­ly under review, and the Com­mis­si­on is expec­ted to con­firm ade­qua­cy in the cour­se of 2024.

    Revi­si­on of the FDPA and the FDPO

    Switz­er­land has gone through a leng­thy pro­cess of revi­sing the FDPA, and the revi­sed FDPA, tog­e­ther with the revi­sed FDPO, has ente­red into force on 1 Sep­tem­ber 2023. The key objec­ti­ve was alig­ning Swiss law with the revi­sed Coun­cil of Europe’s Con­ven­ti­on 108 and with the GDPR, also in view of the pen­ding ade­qua­cy fin­ding men­tio­ned abo­ve.
    Key points of the revi­sed FDPA can be sum­ma­ri­zed as follows:

    • Swiss data pro­tec­tion law con­ti­nues to be based on the basic pre­mi­se that data pro­ce­s­sing is lawful so long as it is in kee­ping with gene­ral prin­ci­ples. In other words, whe­re data is pro­ce­s­sed in a fair, trans­pa­rent and pro­por­tio­nal man­ner for a spe­ci­fic pur­po­se, it is pre­su­med to be lawful.
    • If pro­ce­s­sing vio­la­tes a pro­ce­s­sing prin­ci­ple (and in some though limi­t­ed other cases), the con­trol­ler must eit­her act on the basis of con­sent or estab­lish pre­vai­ling public or pri­va­te inte­rest as a justi­fi­ca­ti­on. As a result of this approach, many pro­ce­s­sing acti­vi­ties (inclu­ding pro­fil­ing for mar­ke­ting pur­po­ses based on event data) do not requi­re con­sent under Swiss law whe­re con­sent would be requi­red under the GDPR.
    • Cer­tain but not all brea­ches of the FDPA are lia­ble to a fine. Fines would be impo­sed on the indi­vi­du­als respon­si­ble for the breach, not on the con­trol­ler or pro­ces­sor. This rai­ses a num­ber of issues, for exam­p­le with regard to the indi­vi­du­als at risk, to insu­ra­bi­li­ty of fines and to lia­bi­li­ty and indem­ni­ty in contracts.
    • Many pro­vi­si­ons of the FDPA remain vague, part­ly becau­se data pro­tec­tion law is gene­ral­ly open to a balan­ce of inte­rest and part­ly due to the leng­thy deba­te in Par­lia­ment and the num­e­rous chan­ges intro­du­ced along this process.

With respect to the ter­ri­to­ri­al appli­ca­ti­on of the FDPA (cf. artic­le 3), slight­ly dif­fe­rent cri­te­ria app­ly depen­ding on the natu­re of the pro­vi­si­on in question:

  • Most of the key pro­vi­si­ons are con­side­red to be pri­va­te law in natu­re, for exam­p­le the pro­ce­s­sing prin­ci­ples (cf. no 38 et seq.) or data sub­ject rights. The appli­ca­ti­on of the­se pro­vi­si­ons is gover­ned by the Fede­ral Pri­va­te Inter­na­tio­nal Law Act (PILA) (cf. artic­le 3(2) FDPA), pro­vi­ded a cla­im is brought befo­re a Swiss court. Under artic­le 139 PILA, data sub­jects have the right to opt for the laws at their ordi­na­ry resi­dence or for the law appli­ca­ble to the con­trol­ler or pro­ces­sor held in breach. Howe­ver, whe­re a data sub­ject with their resi­dence in the EEA opts for the GDPR to app­ly to the dis­pu­te, then Swiss courts would likely rely on artic­le 3 GDPR to deter­mi­ne whe­ther the GDPR inde­ed is to app­ly – this is a deba­ted issue, however.
  • Some pro­vi­si­ons are con­side­red to be public law, for exam­p­le the obli­ga­ti­on to pro­vi­de infor­ma­ti­on to data sub­ject, the obli­ga­ti­on to car­ry out a data pro­tec­tion impact assess­ment, breach noti­fi­ca­ti­on obli­ga­ti­ons or the right for the Swiss data pro­tec­tion aut­ho­ri­ty to car­ry out an inve­sti­ga­ti­on. The appli­ca­ti­on of the­se pro­vi­si­ons is deter­mi­ned in accordance with the prin­ci­ple of ter­ri­to­ri­a­li­ty (artic­le 3(1) FDPA). As a rule, a public-law obli­ga­ti­on is sub­ject to the FDPA if the facts giving rise to that obli­ga­ti­on have occur­red ful­ly or par­ti­al­ly in Switz­er­land. For exam­p­le, whe­re a Swiss-based user acce­s­ses and views infor­ma­ti­on that is kept on a ser­ver abroad, the infor­ma­ti­on obli­ga­ti­ons flowing from this ope­ra­ti­on will be sub­ject to Swiss law. The same applies to con­trol­lers loca­ted abroad who pro­cess per­so­nal data rela­ting to indi­vi­du­als in Switz­er­land, whe­re it is fore­seeable that a suf­fi­ci­ent num­ber of Swiss indi­vi­du­als will be affected.
  • Cer­tain brea­ches are lia­ble to a fine. Under the gene­ral prin­ci­ples of Swiss inter­na­tio­nal cri­mi­nal law, the­se are sub­ject to Swiss law if the breach has been com­mit­ted in Switz­er­land (“Hand­lungs­ort”) or has an effect in Switz­er­land (“Erfolgs­ort”) (cf. artic­le 3(2) FDPA and artic­les 3 and 8 of the Cri­mi­nal Code).
    For prac­ti­cal pur­po­ses com­pa­nies should assu­me that they will be sub­ject to the FDPA whe­re they pro­cess per­so­nal data (i) rela­ting to data sub­jects with their ordi­na­ry resi­dence in Switz­er­land, and (ii) through a Swiss estab­lish­ment. In our expe­ri­ence, most com­pa­nies pro­ce­ed on the assump­ti­on that they are under an obli­ga­ti­on to com­ply with Swiss data pro­tec­tion law whe­re they have a rele­vant Swiss end cus­to­mer base and will fre­quent­ly fore­go a more detail­ed ana­ly­sis, con­side­ring that GDPR com­pli­ance implies com­pli­ance with most obli­ga­ti­ons under Swiss data pro­tec­tion laws.

No accoun­ta­bi­li­ty principle

Dif­fe­rent from the GDPR, the­re is no accoun­ta­bi­li­ty prin­ci­ple under the FDPA. A con­trol­ler or pro­ces­sor that fails to keep records of their pro­ce­s­sing acti­vi­ties, rele­vant events and com­pli­ance mea­su­res may be unable to demon­stra­te com­pli­ance in case of a com­plaint or an inve­sti­ga­ti­on but is not per se in breach of the FDPA.
Howe­ver, the­re are some obli­ga­ti­ons of accoun­ta­bi­li­ty, for exam­p­le the obli­ga­ti­on to keep records of data pro­tec­tion impact assess­ments for two years from clo­sure of the pro­ject, or to keep logs and main­tain pro­ce­s­sing regu­la­ti­ons in cer­tain high-risk scenarios.

Data Pro­tec­tion Advisor

The FDPA has no con­cept of a DPO as defi­ned in the GDPR, but con­trol­lers may opt to appoint a “Data Pro­tec­tion Advi­sor” (“Daten¬schutzberater”) under artic­le 10 FDPA. Appoin­ting a Data Pro­tec­tion Advi­sor is optio­nal, inclu­ding for con­trol­lers who­se core pro­ce­s­sing acti­vi­ties con­sist of high-risk pro­ce­s­sing (but it is man­da­to­ry for orga­nizati­ons acting as fede­ral bodies, inclu­ding pri­va­te enti­ties that per­form public tasks). Whe­re a Data Pro­tec­tion Advi­sor is appoin­ted, they should be inde­pen­dent and have the resour­ces requi­red for them to actively moni­tor com­pli­ance within the orga­nizati­on (artic­le 23 FDPO).
Appoin­ting a Data Pro­tec­tion Advi­sor has only one direct effect under the FDPA: The obli­ga­ti­on to con­sult with the Swiss data pro­tec­tion aut­ho­ri­ty (the Fede­ral Data Pro­tec­tion and Infor­ma­ti­on Com­mis­sio­ner, FDPIC) if a data pro­tec­tion impact assess­ment con­firms high resi­du­al risk no lon­ger applies. In prac­ti­ce, howe­ver, this is of limi­t­ed value, con­side­ring that most impact assess­ments will con­firm lower-than-high risk.
The FDPA does not requi­re Data Pro­tec­tion Advi­sors to be indi­vi­du­als or based in Switz­er­land. DPOs appoin­ted under the GDPR may act as Data Pro­tec­tion Advi­sors as well, pro­vi­ded they meet the requirements.

Swiss Repre­sen­ta­ti­ve

Obli­ga­ti­on to appoint

Like with artic­le 27 GDPR, con­trol­lers loca­ted abroad may be under an obli­ga­ti­on to appoint a “repre­sen­ta­ti­ve” under artic­le 14 FDPA (CH Repre­sen­ta­ti­ve) and publishes its name and address.
Con­trol­ler must appoint a CH Repre­sen­ta­ti­ve whe­re all of the fol­lo­wing con­di­ti­ons are met for their processing:

  • The pro­ce­s­sing is car­ri­ed out by a con­trol­ler loca­ted out­side of Switzerland;
  • the data pro­ce­s­sed rela­tes to indi­vi­du­als loca­ted in Switzerland;
  • it is rela­ted to the offe­ring of goods or ser­vices in Switz­er­land or to moni­to­ring the beha­viour of per­sons in Switzerland;
  • it is “exten­si­ve” (“umfang­reich”) and occurs regu­lar­ly (“regel­mä­ssig”);
  • it invol­ves a high risk for the data sub­jects.
    The­re is no gui­dance so far on the cri­te­ria of “exten­si­ve” and “regu­lar”.
    With regard to high risk, the FDPA does not defi­ne high risk gene­ral­ly but refers to high risk in the defi­ni­ti­on of “pro­fil­ing with high risk” and the obli­ga­ti­on to con­duct a data pro­tec­tion impact assess­ment. Based on the assump­ti­on that “high risk” is a con­si­stent noti­on throug­hout the FDPA, high risk depends on the natu­re, scope, cir­cum­stances and pur­po­se of the pro­ce­s­sing and may include (artic­le 22(2) FDPA):
  • high-risk pro­fil­ing” (artic­le 5(g) FDPA);
  • exten­si­ve pro­ce­s­sing of sen­si­ti­ve data; and
  • syste­ma­tic moni­to­ring of exten­si­ve public are­as.
    Examp­les may include pro­fil­ing that are based on a wide array of event data, for exam­p­le data about inter­ac­tions with posts and news in an online feed over time, in par­ti­cu­lar whe­re data from diver­se sources is com­bi­ned (for exam­p­le off­line and online event data.
    Whe­re a con­trol­ler estab­lished out­side Switz­er­land enga­ges in such pro­ce­s­sing, the­re will the­r­e­fo­re be a de-fac­to pre­sump­ti­on that a CH Repre­sen­ta­ti­ve is to be appoin­ted. Howe­ver, if the­se acti­vi­ties inde­ed car­ry high risk is to be asses­sed in a data pro­tec­tion impact assess­ment. Should the assess­ment con­firm that the (net, miti­ga­ted) risk is low, then the­re is no obli­ga­ti­on to appoint a CH Repre­sen­ta­ti­ve.
    CH Repre­sen­ta­ti­ves must be estab­lished in Switz­er­land and may include legal enti­ties, for exam­p­le a law firm.

Duties of the representative

Under artic­le 15 FDPA, the CH Repre­sen­ta­ti­on must

  • keep a regi­ster of the controller’s pro­ce­s­sing activities,
  • on request, pro­vi­de the regi­ster to the FDPIC;
  • on request, pro­vi­de the data sub­ject with infor­ma­ti­on on how to exer­cise their rights.

Records of pro­ce­s­sing activities

Con­trol­lers and pro­ces­sors are requi­red to coll­ect and main­tain records of pro­ce­s­sing acti­vi­ties (artic­le 12(1) FDPA). The infor­ma­ti­on requi­red to be inclu­ded in the­se records are the same as under artic­le 30(1) and (2) GDPR, except that no infor­ma­ti­on is requi­red about the CH Repre­sen­ta­ti­ve and a Data Pro­tec­tion Advi­sor (if appoin­ted).
An excep­ti­on from the obli­ga­ti­on to main­tain records of pro­ce­s­sing acti­vi­ties applies to com­pa­nies with less than 250 mem­bers of staff (on a head­count, not on an FTE-basis), pro­vi­ded the­re is no lar­ge-sca­le pro­ce­s­sing of sen­si­ti­ve data and no high-risk pro­fil­ing (artic­le 24 FDPO).

Data pro­tec­tion impact assessments

Like artic­le 35 GDPR, artic­le 22(1) FDPA requi­res con­trol­lers to car­ry out a data pro­tec­tion impact assess­ment (DPIA) whe­re pro­ce­s­sing “may” lead to a high risk. The fac­tors to be con­side­red when asses­sing poten­ti­al high risk are the same as under the GDPR.
Like the GDPR, the FDPA sets out par­ti­cu­lar types of pro­ce­s­sing that typi­cal­ly – though not inva­ria­bly – requi­re a DPIA (artic­le 22(2) FDPA):
syste­ma­tic and exten­si­ve eva­lua­ti­on of per­so­nal aspects, based on auto­ma­ted pro­ce­s­sing, on which decis­i­ons are based that pro­du­ce legal effects or have a simi­lar, signi­fi­cant effect Yes Yes, in case of high-risk pro­fil­ing, even if no decis­i­ons are based on that pro­fil­ing
lar­ge-sca­le pro­ce­s­sing of spe­cial cate­go­ries of data Yes Yes
syste­ma­tic moni­to­ring of a publicly acce­s­si­ble area on a lar­ge sca­le Yes Yes
The DPIA must include, as a mini­mum, a descrip­ti­on of the pro­ce­s­sing, an eva­lua­ti­on of the risks and the inten­ded miti­ga­ting mea­su­res (artic­le 22(3) FDPA. Dif­fe­rent from the GDPR, howe­ver, the­re is no obli­ga­ti­on to seek the views of data sub­jects on the inten­ded pro­ce­s­sing (cf. artic­le 35(9) GDPR). Becau­se the requi­re­ments for DPI­As under the FDPA as to form and con­tent are less strict than under the GDPR, no addi­tio­nal DPIA is requi­red under the FDPA whe­re the pro­ce­s­sing at sta­ke has been asses­sed in a DPIA under the GDPR.
Whe­re a DPIA con­firms that the pro­ce­s­sing asses­sed car­ri­es high risk that the con­trol­ler is unable or not wil­ling to miti­ga­te fur­ther, which is rare in prac­ti­ce, the FDPIC must be noti­fi­ed of the result at any time pri­or to the pro­ce­s­sing, except whe­re the con­trol­ler has appoin­ted a Data Pro­tec­tion Advi­sor and/or the DPIA has been car­ri­ed out vol­un­t­a­ri­ly, i.e., wit­hout obli­ga­ti­on (artic­le 23 FDPA).
The FDPIC has up to three months to noti­fy the con­trol­ler of any objec­tions against the pro­ce­s­sing as plan­ned by the con­trol­ler, and he may open an inve­sti­ga­ti­on during or after this time (artic­le 23 FDPA). The con­trol­ler is not bound to wait for con­fir­ma­ti­on by the FDPIC or expiry of the dead­line but should assess the risk that the FDPIC may open an inve­sti­ga­ti­on.
DPI­As must be kept on record for at least two years from the date when the pro­ce­s­sing acti­vi­ty has ended (artic­le 14 FDPO).

Data breach notification

Simi­lar to the GDPR, a “data secu­ri­ty breach” means a secu­ri­ty breach – i.e., a breach of con­fi­den­tia­li­ty, inte­gri­ty or avai­la­bi­li­ty – that leads to an unin­ten­tio­nal or unlawful loss, dele­ti­on, des­truc­tion or modi­fi­ca­ti­on of per­so­nal data or to per­so­nal data being dis­c­lo­sed or made acce­s­si­ble to unaut­ho­ri­zed persons.

Noti­fi­ca­ti­on by the pro­ces­sor to the controller

Pro­ces­sors must noti­fy the con­trol­ler “as soon as pos­si­ble” of data brea­ches (artic­le 24(3) FDPA). While this obli­ga­ti­on is not a man­da­to­ry part of pro­ce­s­sing agree­ments, it is usual­ly sta­ted in such agree­ments, fre­quent­ly spe­ci­fy­ing mini­mum noti­fi­ca­ti­on con­tent and timing requirements.

Noti­fi­ca­ti­on by the con­trol­ler to the FDPIC

The con­trol­ler must noti­fy the FDPIC whe­re a data breach “is pro­ba­ble to result in a high risk” for the data sub­ject (artic­le 24(1) FDPA). The FDPA pro­vi­des no defi­ni­ti­on of high risk, but again assum­ing that “high risk” is a con­si­stent noti­on throug­hout the FDPA, the seve­ri­ty of the risk depends on the natu­re, scope, cir­cum­stances and pur­po­se of the pro­ce­s­sing (artic­le 22(2) FDPA). Howe­ver, so far the­re is no gui­dance on the inter­pre­ta­ti­on of high risk in the con­text of data brea­ches. It is likely that the prac­ti­ce will refer to the EDPB’s gui­de­lines on data breach noti­fi­ca­ti­ons, or on the ENISA recom­men­da­ti­ons.
The noti­fi­ca­ti­on to the FDPIC must made as soon as rea­son­ab­ly pos­si­ble on beco­ming awa­re of the breach, pro­vi­ded that the time allo­wed befo­re the noti­fi­ca­ti­on depends on the seve­ri­ty of the risk. It must include, as a mini­mum, the fol­lo­wing infor­ma­ti­on (artic­le 24(2) FDPA):

Natu­re of the breach Yes, inclu­ding whe­re pos­si­ble, the cate­go­ries and appro­xi­ma­te num­ber of sub­jects con­cer­ned and cate­go­ries and appro­xi­ma­te num­ber of per­so­nal data records con­cer­ned Yes, wit­hout the addi­tio­nal infor­ma­ti­on
The name and cont­act details of the DPO or other cont­act point Yes No
Likely con­se­quen­ces of the breach Yes Yes
Mea­su­res taken or inten­ded to miti­ga­te the breach Yes Yes
The noti­fi­ca­ti­on can be sub­mit­ted through the offi­ci­al online form, but the­re is no obli­ga­ti­on – noti­fi­ca­ti­on can also be done by e‑mail. Con­trol­lers making a noti­fi­ca­ti­on should be awa­re that the FDPIC is sub­ject to the Free­dom of Infor­ma­ti­on Act and may be requi­red to release breach noti­fi­ca­ti­ons to media out­lets or other third par­ties.
On rece­ipt of noti­fi­ca­ti­on, the FDPIC may open an inve­sti­ga­ti­on. Howe­ver, the infor­ma­ti­on pro­vi­ded to the FDPIC under artic­le 24 FDPA may not be used in cri­mi­nal pro­ce­e­dings against the con­trol­ler wit­hout the controller’s con­sent (artic­le 24(6) FDPA).

Com­mu­ni­ca­ti­on by the con­trol­ler to the data subjects

Inde­pendent­ly of a noti­fi­ca­ti­on to the FDPIC, the con­trol­ler must com­mu­ni­ca­te the breach to the data sub­jects indi­vi­du­al­ly, wit­hout undue delay, if this is “neces­sa­ry for the pro­tec­tion of the data sub­jects”, in par­ti­cu­lar whe­re sub­jects should take miti­ga­ting mea­su­res (for exam­p­le chan­ge log­in cre­den­ti­als) or on order by the FDPIC (artic­le 24(4) FDPA. The con­trol­ler must pro­vi­de the infor­ma­ti­on that is requi­red for the sub­jects to under­stand the breach and its likely effects for them and to take appro­pria­te mea­su­res.
The con­trol­ler may rest­rict, post­po­ne, or wai­ve the com­mu­ni­ca­ti­on to the sub­jects (artic­le 24(5) FDPA):

  • on grounds that this mea­su­re is requi­red by pre­vai­ling inte­rests of third par­ties or under a sta­tu­to­ry duty of secrecy;
  • whe­re infor­ma­ti­on is impos­si­ble or would requi­re dis­pro­por­tio­na­te efforts (for exam­p­le if cont­act details of the sub­jects are unknown, or if a lar­ge num­ber of sub­jects would need to be infor­med indi­vi­du­al­ly and the costs is dis­pro­por­tio­na­te in rela­ti­on to the gain in information);
  • if the infor­ma­ti­on of the data sub­ject is ensu­red by a public announcement.

Kee­ping logs

As noted abo­ve, con­trol­lers and pro­ces­sors must take appro­pria­te secu­ri­ty mea­su­res in rela­ti­on of per­so­nal­ly iden­ti­fia­ble data (artic­le 8 FDPA). On this basis, artic­le 4 FDPO enti­ties con­trol­lers as well as pro­ces­sors to keep logs whe­re they enga­ge in lar­ge-sca­le pro­ce­s­sing of sen­si­ti­ve per­so­nal data or high­risk pro­fil­ing. Stric­ter obli­ga­ti­ons app­ly to fede­ral aut­ho­ri­ties.
Whe­re the obli­ga­ti­on applies, the con­trol­ler or pro­ces­sor must keep logs, at a mini­mum, of the sto­rage, modi­fi­ca­ti­on, rea­ding, dis­clo­sure, dele­ti­on, and des­truc­tion of data. The­se logs must include infor­ma­ti­on about the iden­ti­ty of the per­son who car­ri­ed out the pro­ce­s­sing; the type of pro­ce­s­sing; date and time of the pro­ce­s­sing; and if data is dis­c­lo­sed, the iden­ti­ty of data reci­pi-ents. Logs must be kept for one year.

Pro­ce­s­sing regulations

In some cases, con­trol­lers are requi­red to keep “pro­ce­s­sing regu­la­ti­ons”. As with the log­kee­ping obli­ga­ti­on, this obli­ga­ti­on applies only whe­re the con­trol­ler or pro­ces­sor enga­ges in lar­ge-sca­le pro­ce­s­sing of sen­si­ti­ve per­so­nal data or high-risk pro­fil­ing.
Pro­ce­s­sing regu­la­ti­ons are sepa­ra­te from the records of pro­ce­s­sing acti­vi­ties – they are simi­lar to an manu­al that sets out the inter­nal orga­nizati­on; the data pro­ce­s­sing pro­ce­du­res for sto­ring, cor­rec­ting, dis­clo­sing, retai­ning, archi­ving, pseud­ony­mi­zing, anony­mi­zing, dele­ting or destroy­ing per­so­nal data, inclu­ding how data mini­mizati­on is ensu­red; the pro­ce­du­re how the access and data por­ta­bi­li­ty rights are ensu­red; and the tech­ni­cal and orga­nizatio­nal secu­ri­ty mea­su­res inclu­ding infor­ma­ti­on about the con­fi­gu­ra­ti­on of IT resources.

Pro­ce­s­sing principles

As men­tio­ned abo­ve, con­trol­lers and – for most prin­ci­ples – also pro­ces­sors must com­ply with the pro­ce­s­sing prin­ci­ples. Fail­ure to com­ply means that the pro­ce­s­sing inf­rin­ges on the per­so­na­li­ty rights of the data sub­jects and is unlawful unless it is justi­fi­ed by con­sent and/or a pre­vai­ling inte­rest.
The FDPA sets out the fol­lo­wing pro­ce­s­sing prin­ci­ples (artic­le 6 – 8 and FDPA):

Lawful­ness: Per­so­nal data must be pro­ce­s­sed lawful­ly, which does not mean that all pro­ce­s­sing must be based on legal grounds, but that pro­ce­s­sing must not be incon­si­stent with any other laws (i.e., other than the FDPA) that pro­tect the data sub­jects’ per­so­na­li­ty rights);
good faith: pro­ce­s­sing must be car­ri­ed out in good faith (fair­ness). The fair­ness prin­ci­ple is some­what vague but may be used as a gene­ric justi­fi­ca­ti­on when­ever a court or aut­ho­ri­ty feels that a par­ti­cu­lar type if pro­ce­s­sing is unac­cep­ta­ble;
trans­pa­ren­cy: the key para­me­ters of the pro­ce­s­sing prin­ci­ples inclu­ding the pro­ce­s­sing purpose(s) must eit­her be trans­pa­rent (i.e., eit­her be obvious in the cir­cum­stances or men­tio­ned express­ly);
pur­po­se limi­ta­ti­on: data may only be coll­ec­ted for a spe­ci­fic pur­po­se and may only be pro­ce­s­sed in a way that is com­pa­ti­ble with the pur­po­se;
pro­por­tio­na­li­ty: pro­ce­s­sing must be pro­por­tio­na­te to the pur­po­se (data mini­mizati­on) and must be “destroy­ed or anony­mi­zed” as soon as it is no lon­ger nee­ded with regard to the pur­po­se of the pro­ce­s­sing;
cor­rect­ness: con­trol­lers and pro­ces­sors must take rea­sonable mea­su­res to ascer­tain that the data is accu­ra­te and cor­rec­ted or “dele­ted or destroy­ed“;
pri­va­cy by design and secu­ri­ty: con­trol­lers must set up tech­ni­cal and orga­nizatio­nal mea­su­res in order to meet the data pro­tec­tion requi­re­ments (pri­va­cy by design) and, in par­ti­cu­lar, to ensu­re a level of data secu­ri­ty appro­pria­te to the risks (data secu­ri­ty);
pri­va­cy by default: con­trol­lers must set pre-defi­ned set­tings such that the pro­ce­s­sing is limi­t­ed to the requi­red mini­mum (pri­va­cy by default);
right to object: data must not be pro­ce­s­sed against the express wis­hes of the data sub­jects (which is the Swiss vari­ant of the data sub­jects’ right to object to pro­ce­s­sing);
dis­clo­sure rest­ric­tions: sen­si­ti­ve data must not be dis­c­lo­sed to third par­ties (i.e., other con­trol­lers).
A breach of the pro­ce­s­sing prin­ci­ples is unlawful unless justi­fi­ed but is gene­ral­ly not sub­ject to a fine.
As an excep­ti­on, a breach of mini­mum secu­ri­ty requi­re­ments may be lia­ble to a fine. The FDPA con­ta­ins no such mini­mum requi­re­ments, but the FDPO inclu­des pro­vi­si­ons that may be con­side­red to be mini­mum requi­re­ments, such as kee­ping logs for high-risk pro­ce­s­sing (artic­les 1 et seq.).
As men­tio­ned abo­ve, pro­ce­s­sing in breach of one or seve­ral pro­ce­s­sing prin­ci­ples is unlawful only to the ext­ent it is not justi­fi­ed. The fol­lo­wing grounds may justi­fy such pro­ce­s­sing (artic­le 31(1) FDPA):
(a) Con­sent (artic­les 31(1) and 6(6) and (7) FDPA): Con­sent is regu­la­ted less strict­ly than under the GDPR. The key requi­re­ments for con­sent are the following:

Infor­med con­sent”: the sub­ject must be infor­med of the key ele­ments of the pro­ce­s­sing;
“free­ly given con­sent”: con­sent is inva­lid if it is not free­ly given. Accor­ding to case law, con­sent may be inva­lid if the con­trol­ler makes it a con­di­ti­on to access goods or ser­vices arbi­tra­ri­ly, wit­hout objec­ti­ve rea­sons;
“Expli­cit” con­sent: Con­sent must be expli­cit for the pro­ce­s­sing of sen­si­ti­ve per­so­nal data and for high-risk pro­fil­ing, pro­vi­ded the­se pro­ce­s­sing ope­ra­ti­ons requi­re con­sent;
capa­ci­ty for jud­ge­ment: con­sent is inva­lid if given by anyo­ne wit­hout capa­ci­ty of judgment. The­re is no mini­mum age for child­ren, and the requi­red age depends on the risks and com­ple­xi­ty of the pro­ce­s­sing at sta­ke.
Becau­se the FDPA has no accoun­ta­bi­li­ty prin­ci­ple, it is not a breach if con­sent is not docu­men­ted, but the con­trol­ler has an obvious inte­rest in kee­ping tra­ci­b­le records of con­sent.
Whe­re con­sent is inva­lid or with­drawn, the con­trol­ler may con­ti­n­ue to rely on pre­vai­ling inte­rest to justi­fy the pro­ce­s­sing (pro­vi­ded that an express with­dra­wal of con­sent may be con­strued as an objec­tion, which tends to rai­se the bar for pre­vai­ling inte­rest).
(b) Pre­vai­ling inte­rest (artic­le 31(1) FDPA):
Con­sent is not neces­sa­ry whe­re pro­ce­s­sing in breach of a prin­ci­ple is requi­red to safe­guard pre­vai­ling inte­rests. Poten­ti­al­ly pre­vai­ling inte­rests include any inte­rest that is not against the law, inclu­ding public inte­rest and purely com­mer­cial inte­rests of pri­va­te actors. The­se inte­rests must pre­vail over the con­tra­ry inte­rest of the data sub­ject. The FDPA does not requi­re a for­mal “legi­ti­ma­te inte­rest assess­ment” (“LIA”), but the con­trol­ler should docu­ment the balan­ce of inte­rest in all but obvious cases.
Examp­les of poten­ti­al­ly pre­vai­ling inte­rest include:
Anony­mizati­on of per­so­nal data for sta­tis­ti­cal uses;
data reten­ti­on bey­ond the peri­od requi­red for the pro­ce­s­sing pur­po­ses becau­se data is kept in a back­up;
kee­ping per­so­nal data despi­te an objec­tion for docu­men­ta­ti­on or evi­den­tia­ry purposes.


The FDPA regu­la­tes both pro­fil­ing and indi­vi­du­al decis­i­on-making. With regard to pro­fil­ing, the appli­ca­ble pro­vi­si­ons are dif­fe­rent and in parts slight­ly stric­ter than the GDPR.
“Pro­fil­ing” means any auto­ma­ted pro­ce­s­sing with the pur­po­se of ana­ly­sing or pre­dic­ting per­so­nal aspects or the beha­viour of a sub­ject (artic­le 5(f) FDPA). It remains to be seen if pro­fil­ing requi­res full auto­ma­ti­on or inclu­des pro­fil­ing with some, but not decisi­ve human inter­ac­tion. In any event howe­ver, pro­fil­ing does not requi­re the raw data used for the pro­fil­ing ope­ra­ti­on to be coll­ec­ted or other­wi­se pro­ce­s­sed auto­ma­ti­cal­ly as long as the pro­fil­ing ope­ra­ti­on its­elf is auto­ma­ted. Examp­les of pro­fil­ing include auto­ma­ted eva­lua­ti­on of buy­ing habits in order to deter­mi­ne pre­mi­ums and incen­ti­ves, cal­cu­la­ting an acti­vi­ty index based on step count data from an app, the ana­ly­sis of web­site or app beha­viour in order to pre­sent tar­ge­ted online adver­ti­sing, or auto­ma­ti­cal­ly sel­ec­ting news based on user loca­ti­on.
Pro­fil­ing as such trig­gers no express obli­ga­ti­ons for con­trol­lers (unless they act as a fede­ral body). Howe­ver, the­re may be an obli­ga­ti­on under the trans­pa­ren­cy prin­ci­ple to inform the data sub­jects about pro­fil­ing, and con­trol­lers fre­quent­ly choo­se to include a refe­rence to pro­fil­ing in their pri­va­cy notices.

High-risk pro­fil­ing”

High-risk pro­fil­ing” has been intro­du­ced in the FDPA as a poli­ti­cal com­pro­mi­se. It is any form of pro­fil­ing that, based on a com­bi­na­ti­on of data, leads to an “assess­ment of essen­ti­al aspects of the per­so­na­li­ty” of an indi­vi­du­al (artic­le 5(h) FDPA). This defi­ni­ti­on is based on the con­cept of “per­so­na­li­ty pro­files” in the cur­rent FDPA. Examp­les of “per­so­na­li­ty pro­files” include end cus­to­mer pro­files based on buy­ing habits, a com­pre­hen­si­ve CV, results of a per­so­na­li­ty test or KYC data. When­ever pro­fil­ing leads to such a pro­fi­le, it is likely con­side­red to be “high risk”. It is open, howe­ver, if only pro­fil­ing is high-risk that out­puts such a per­so­na­li­ty pro­fi­le, or also pro­fil­ing whe­re the input (source) data amounts to a per­so­na­li­ty pro­fi­le.
Whe­re a con­trol­ler enga­ges in high-risk profiling,

  • the con­trol­ler must car­ry out a data pro­tec­tion impact assessment;
  • the con­trol­ler may have to appoint a CH Representative;
  • is likely under an obli­ga­ti­on to inform the data sub­jects about the high-risk pro­fil­ing, under the trans­pa­ren­cy principle;
  • con­sent must be expli­cit, pro­vi­ded con­sent is requi­red as a justification.

Auto­ma­ted indi­vi­du­al decision-making

Auto­ma­ted indi­vi­du­al decis­i­on-making means decis­i­ons that:

  • are made auto­ma­ti­cal­ly, wit­hout meaningful human intervention,
  • requi­re some level of judgment (exclu­ding simp­le if/then decis­i­ons), and
  • have an adver­se legal effect on the sub­ject or other­wi­se has a signi­fi­cant nega­ti­ve effect on the sub­ject (artic­le 21(1) FDPA). We expect that the inter­pre­ta­ti­on under the FDPA will fol­low the con­cept of auto­ma­ted decis­i­on-making under the GDPR.
    Con­si­stent with the Swiss approach of a pre­sump­ti­on of the lawful­ness of data pro­ce­s­sing, auto­ma­ted decis­i­on-making is regu­la­ted but does not requi­re legal grounds to be per­mit­ted. Howe­ver, the con­trol­ler must gene­ral­ly inform the sub­jects of auto­ma­ted decis­i­on-making. In addi­ti­on, the con­trol­ler must allow the sub­ject, on request, to sta­te their posi­ti­on and request that the decis­i­on be review­ed by a human (artic­le 21(2) FDPA).
    The infor­ma­ti­on and escala­ti­on obli­ga­ti­ons set out abo­ve do not app­ly howe­ver (artic­le 21(3) FDPA) where:
  • the decis­i­on is direct­ly con­nec­ted with the con­clu­si­on or per­for­mance of a con­tract bet­ween the con­trol­ler and the sub­ject, and the request of the sub­ject is satis­fied, or
  • the data expli­ci­t­ly con­sen­ted to the decis­i­on being taken in an auto­ma­ted man­ner.
    Con­trol­lers should gene­ral­ly include infor­ma­ti­on about auto­ma­ted decis­i­on-making (if appli­ca­ble) in their pri­va­cy noti­ce and, in addi­ti­on, will inform the sub­jects about the auto­ma­ti­on of the decis­i­on-making and the escala­ti­on rights when they noti­fy the decis­i­on to the sub­ject. The FDPA does not express­ly requi­re this second infor­ma­ti­on in each case, but we con­sider it likely that a gene­ric infor­ma­ti­on in the pri­va­cy noti­ce alo­ne will not be sufficient.

Gene­ral comments

In addi­ti­on to the gene­ral trans­pa­ren­cy prin­ci­ple, and simi­lar to artic­les 13 and 14 GDPR, the FDPA sets out a gene­ral obli­ga­ti­on to pro­vi­de cer­tain infor­ma­ti­on to the data sub­jects (artic­le 19 FDPA). This obli­ga­ti­on applies to all cate­go­ries of data, sub­ject to excep­ti­ons, not only to the coll­ec­tion of sen­si­ti­ve data.
For con­trol­lers estab­lished out­side of Switz­er­land, the obli­ga­ti­on to inform applies whe­re the coll­ec­tion of data has suf­fi­ci­ent ties to Switz­er­land, for exam­p­le whe­re the coll­ec­tion is rela­ted to an offer to indi­vi­du­als in Switz­er­land or is car­ri­ed out using a ser­ver in Switz­er­land.
A breach of the obli­ga­ti­on to inform may be lia­ble to a fine.

Mini­mum information

Con­trol­lers must pro­vi­de the fol­lo­wing infor­ma­ti­on as a minimum:

  • Name and details of the controller
  • Name and details of the representative
  • Cate­go­ries of data
  • Pro­ce­s­sing purposes
  • Reci­pi­en­ts or cate­go­ries of recipients
  • inten­ti­on to trans­fer data to a third coun­try or inter­na­tio­nal orga­nizati­on, inclu­ding the reci­pi­ent countries
  • appro­pria­te safe­guards or excep­ti­ons appli­ca­ble
    Pri­va­cy noti­ces that are con­si­stent with the GDPR satis­fy most requi­re­ments of the FDPA, except that:
  • the FDPA requi­res con­trol­lers to name the count­ries in the event of a trans­fer to a third coun­try (inclu­ding for trans­fers by pro­ces­sors and subpro­ces­sors). In prac­ti­ce, many con­trol­lers will indi­ca­te a regi­on (such as “the EEA” or “glo­bal­ly”) instead of naming all count­ries indi­vi­du­al­ly, but it remains to be seen if courts or the FDPIC will accept this simplification;
  • refe­ren­ces to the GDPR are often repla­ced by a refe­rence to “appli­ca­ble law” or simi­lar lan­guage in order to avo­id the per­cep­ti­on that the con­trol­ler is neces­s­a­ri­ly sub­ject to the GDPR.
    Note that addi­tio­nal infor­ma­ti­on obli­ga­ti­ons may ari­se in the circumstances:
  • addi­tio­nal infor­ma­ti­on obli­ga­ti­on may ari­se under the gene­ral trans­pa­ren­cy prin­ci­ple, depen­ding on the circumstances;
  • artic­le 19(1) FDPA requi­res the con­trol­ler to pro­vi­de the infor­ma­ti­on set out abo­ve, but gene­ral­ly “all infor­ma­ti­on which is requi­red in order for the data sub­ject to assert his rights and ensu­re trans­pa­rent pro­ce­s­sing”. It remains to be seen if courts or aut­ho­ri­ties requi­re addi­tio­nal infor­ma­ti­on under this clause.

Form and time constraints

The infor­ma­ti­on obli­ga­ti­on is trig­ge­red by the “coll­ec­tion” (“Beschaf­fung”) of data. “Coll­ec­tion” requi­res a pre­me­di­ta­ted action aimed at obtai­ning data. Whe­re per­so­nal data is obtai­ned unin­ten­tio­nal­ly, it is not coll­ec­ted. Howe­ver, using exi­sting data – “coll­ec­ted” or not – for a new pur­po­se will always be con­side­red to con­sti­tu­te coll­ec­tion, and will trig­ger an obli­ga­ti­on to inform.
The mini­mum infor­ma­ti­on must be pro­vi­ded to the data subjects:

  • befo­re or at the time of coll­ec­tion, if is coll­ec­ted from the data sub­ject (artic­le 19(1) FDPA);
  • one month after coll­ec­tion or, if ear­lier, when data is dis­c­lo­sed to a third par­ty (exclu­ding a pro­ces­sor), whe­re data is not coll­ec­ted from the sub­ject (artic­le 19(5) FDPA).
    The FDPA does not requi­re a par­ti­cu­lar form for the mini­mum infor­ma­ti­on. Infor­ma­ti­on may be pro­vi­ded in any form inclu­ding oral­ly, and may also be pre­sen­ted on a web­site, provided:
  • that the data is coll­ec­ted online or through ano­ther elec­tro­nic chan­nel, or
  • whe­re data is coll­ec­ted off­line, that the sub­ject is direc­ted to the rele­vant web­site whe­re the infor­ma­ti­on is easi­ly acce­s­si­ble. It is open if prin­ted mat­ters refer­ring to a web­site must include cer­tain infor­ma­ti­on (“base infor­ma­ti­on”), but the­re is a risk that a court or aut­ho­ri­ty would requi­re indi­ca­ting at least the iden­ti­ty of the con­trol­ler, the pro­ce­s­sing pur­po­ses and dis­clo­sures to third parties.

Excep­ti­ons from the obli­ga­ti­on to inform

The­re is no obli­ga­ti­on to inform in the fol­lo­wing sce­na­ri­os (artic­le 20 FDPA):

  • If, and to the ext­ent that, the sub­ject alre­a­dy has the rele­vant information;
  • the pro­ce­s­sing is neces­sa­ry to com­ply with Swiss law (for exam­p­le to com­ply with KYC obli­ga­ti­ons, cer­tain obli­ga­ti­ons under labor law or reten­ti­on obligations);
  • dis­clo­sing infor­ma­ti­on would be in breach of a sta­tu­to­ry obli­ga­ti­on of secrecy;
  • whe­re data is not coll­ec­ted from the data sub­ject, it is not pos­si­ble to give the infor­ma­ti­on, or it would requi­re dis­pro­por­tio­na­te efforts.
    In the­se cases, the con­trol­ler is reli­e­ved from the obli­ga­ti­on to inform, and the FDPA does not requi­re the con­trol­ler to take miti­ga­ting mea­su­res such as posting the infor­ma­ti­on on a web­site.
    In addi­ti­on, con­trol­lers may rest­rict, defer or wai­ve the infor­ma­ti­on where:
  • It is requi­red to pro­tect the over­ri­ding inte­rests of third parties;
  • pro­vi­ding infor­ma­ti­on would pre­vent the pro­ce­s­sing from ful­fil­ling its purpose;
  • it is requi­red for the controller’s over­ri­ding inte­rests, pro­vi­ded the con­trol­ler does not dis­c­lo­se the data to third par­ties (which exclu­des pro­ces­sors and affi­lia­ted companies).

Controller/processor rela­ti­on­ships

Whe­re a con­trol­ler intends to use a pro­ces­sor, the FDPA requi­res both par­ties to enter into a data pro­ce­s­sing agree­ment (artic­le 9(1) FDPA). The data pro­ce­s­sing agree­ment (DPA) may be ente­red into in any form, inclu­ding oral­ly, but should be con­clu­ded in text form. The mini­mum con­tent is ligh­ter than under the GDPR. DPAs must requi­re the pro­ces­sor, as a mini­mum, to

  • pro­cess data only as neces­sa­ry for the processor’s ser­vices in accordance with the controller’s instructions,
  • obtain controller’s aut­ho­rizati­on befo­re using a subpro­ces­sor, and
  • ensu­re appro­pria­te data secu­ri­ty.
    In addi­ti­on, the pro­ces­sor must noti­fy the con­trol­ler of a data secu­ri­ty breach as soon as pos­si­ble (artic­le 24(3) FDPA), which will usual­ly be resta­ted or spe­ci­fi­ed in the DPA.
    In gene­ral, DPAs draf­ted in accordance with artic­le 28 GDPR satis­fy the requi­re­ments under artic­le 9 FDPA. However,
  • DPAs are gene­ral­ly modi­fi­ed to remo­ve refe­ren­ces to the GDPR or replace them with a refe­rence to “Appli­ca­ble Data Pro­tec­tion Law” whe­re the con­trol­ler and the pro­ces­sor may not be sub­ject to the GDPR;
  • in addi­ti­on, pro­ces­sors are direct­ly respon­si­ble to com­ply with the pro­ce­s­sing prin­ci­ples and may the­r­e­fo­re ask for an under­ta­king that the con­trol­ler ensu­res com­pli­ance of the pro­ce­s­sing with the FDPA and holds the pro­ces­sor harm­less in case of a breach cau­sed by the controller.

Joint con­trol­ler arrangements

As men­tio­ned abo­ve, joint con­trol­lers have no express obli­ga­ti­on to enter into a joint con­trol­ler arran­ge­ment or to inform the sub­jects about the allo­ca­ti­on of respon­si­bi­li­ty bet­ween them. Howe­ver, an obli­ga­ti­on to agree on the allo­ca­ti­on of respon­si­bi­li­ties may, depen­ding on the cir­cum­stances, be deri­ved from the pri­va­cy by design and data secu­ri­ty prin­ci­ples. Joint con­trol­ler arran­ge­ments in accordance with the GDPR will satis­fy this requi­re­ment.
All joint con­trol­lers must likely be indi­ca­ted in pri­va­cy noti­ces, and in the respon­se to sub­ject access requests.

Con­trol­ler-to-con­trol­ler transfers

In the event of a con­trol­ler-to-con­trol­ler trans­fer, the dis­clo­sing con­trol­ler must com­ply with the pro­ce­s­sing prin­ci­ples and with cross-bor­der trans­fer rest­ric­tions. Out­side the­se requi­re­ments, the­re are no mini­mum requi­re­ments for con­trol­ler-to-con­trol­ler arran­ge­ments, but par­ties will often enter into a con­trol­ler-to-con­trol­ler agree­ment.
It should be noted, howe­ver, that under artic­le 62 FDPA, dis­clo­sing secret per­so­nal data of which know­ledge has been gai­ned while exer­cis­ing a pro­fes­si­on that requi­res such know­ledge (or acting on behalf of a per­son bound by a con­fi­den­tia­li­ty obli­ga­ti­on) is lia­ble to a fine of up to CHF 250,000. The­re is a dis­cus­sion in Switz­er­land if any dis­clo­sure that is not neces­sa­ry for a con­tract with the data sub­ject may be in breach of this pro­vi­si­on, or only dis­clo­sures in breach of the FDPA.

The FDPA regu­la­tes data trans­fers abroad (inclu­ding dis­clo­sure by giving access) in artic­les 16 et seq. Trans­fers abroad are per­mit­ted as follows:

  • to reci­pi­en­ts in count­ries whe­re the Fede­ral Coun­cil has issued an ade­qua­cy fin­ding (artic­le 16(1) FDPA). The­se fin­dings will be bin­ding on export­ing com­pa­nies. The list of ade­qua­te count­ries is an annex to the FDPO, and inclu­des all EEA mem­ber sta­tes as well as some other countries;
  • whe­re the import­ing coun­try does not pro­vi­de ade­qua­te pro­tec­tion, the trans­fer is per­mit­ted based on BCR or if the par­ties enter into a data trans­fer agree­ment that is based on stan­dard data pro­tec­tion clau­ses (inclu­ding the EU Stan­dard Con­trac­tu­al Clau­ses, usual­ly slight­ly modi­fi­ed to account for Swiss law) or, in case of an ad hoc agree­ment, that has been noti­fi­ed to the FDPIC pri­or to the transfer;
  • whe­re data is to be trans­fer­red to a reci­pi­ent in a coun­try wit­hout ade­qua­te pro­tec­tion out­side of a data trans­fer, such a trans­fer is per­mit­ted if it is based on BCR; based on expli­cit con­sent; direct­ly con­nec­ted with the con­clu­si­on or the per­for­mance of a con­tract bet­ween the con­trol­ler and the data sub­ject or bet­ween con­trol­ler and ano­ther par­ty in the inte­rest of the data sub­ject; neces­sa­ry in order to safe­guard an over­ri­ding public inte­rest or for the estab­lish­ment, exer­cise or enforce­ment of legal claims befo­re a court or ano­ther com­pe­tent for­eign aut­ho­ri­ty; neces­sa­ry to pro­tect the life or phy­si­cal inte­gri­ty of the sub­ject or a third par­ty, if con­sent is not an opti­on; the sub­ject has made the data gene­ral­ly acce­s­si­ble and has not express­ly pro­hi­bi­ted its pro­ce­s­sing; or the data ori­gi­na­tes from a regi­ster pro­vi­ded for by law which is acce­s­si­ble to the public or per­sons with a legi­ti­ma­te inte­rest, pro­vi­ded the con­di­ti­ons for con­sul­ta­ti­on are met.
    Upon request, the export­ing par­ty must inform the FDPIC of dis­clo­sures of data under some of the excep­ti­ons set out abo­ve (artic­le 17(2) FDPA).
    Note that as of today the­re is no Swiss-US Data Pri­va­cy Frame­work (DPF) in place (the suc­ces­sor to the Pri­va­cy Shield), but we expect that the Swiss DPF will beco­me appli­ca­ble by end of Q1 2024.

Gene­ral comments

Under the FDPA, by and lar­ge sub­jects have the same rights as under the GDPR, but the moda­li­ties for using the­se rights and the controller’s obli­ga­ti­ons to com­ply with the­se rights dif­fer to an ext­ent. The dif­fe­ren­ces can be sum­ma­ri­zed as follows:

  • Right to be infor­med: see below;
  • Access: Data sub­jects have a right to be infor­med, on request, about the pro­ce­s­sing of data rela­ting to them and recei­ve a copy of their data and infor­ma­ti­on about the processing;
  • Rec­ti­fi­ca­ti­on: The right to have data updated or other­wi­se rec­ti­fi­ed is simi­lar under artic­le 32 FDPA and under the GDPR. Howe­ver, under the FDPA, the­re is no rec­ti­fi­ca­ti­on right whe­re data is pro­ce­s­sed or archi­ved in the public inte­rest (artic­le 32(1) FDPA, and whe­re the accu­ra­cy or inac­cu­ra­cy of data can­not be deter­mi­ned, the sub­ject may request the com­pe­tent court to order a note indi­ca­ting the objec­tion be added to the data (artic­le 32(3) FDPA;
  • Objec­tion: Data sub­jects may object to the fur­ther pro­ce­s­sing of data rela­ting to them at any time (artic­le 30(2)(b) FDPA). In the event of an objec­tion, fur­ther pro­ce­s­sing is only per­mit­ted if it is justi­fi­ed by a pre­vai­ling pri­va­te or public inte­rest. To the ext­ent it is not, pro­ce­s­sing must be rest­ric­ted, or data must be deleted;
  • Rest­ric­tion of pro­ce­s­sing: The­re is no express right to rest­rict fur­ther pro­ce­s­sing of data. Howe­ver, whe­re data is kept in an archi­ve or back­up system (for exam­p­le if a sub­ject has objec­ted to the fur­ther pro­ce­s­sing but the con­trol­ler has a pre­vai­ling inte­rest in kee­ping a copy of the data), the con­trol­ler must take appro­pria­te mea­su­res to pre­vent pro­ce­s­sing for other pur­po­ses. In prac­ti­ce, this requi­re­ment has simi­lar effects as the right to rest­rict pro­ce­s­sing under artic­les 4(3) and 18 GDPR;
  • Dele­ti­on: Con­trol­lers must dele­te per­so­nal data as soon as it is no lon­ger requi­red for a lawful pur­po­se, sub­ject to reten­ti­on obli­ga­ti­ons. This may be the result of an objec­tion to the fur­ther pro­ce­s­sing of data as men­tio­ned abo­ve. Con­trol­lers under an obli­ga­ti­on to dele­te must, at their opti­on, dele­te, destroy or anony­mi­ze the data (cf. artic­le 32(4) FDPA). “Dele­ti­on” means dele­ting per­so­nal data in a man­ner that pre­vents resto­ring them under nor­mal cir­cum­stances, whe­re­as “des­truc­tion” means the irrever­si­ble des­truc­tion of the data car­ri­er, for exam­p­le shred­ding paper or dema­gne­tiz­ing a hard dri­ve. Despi­te unclear wor­ding, the FDPA gene­ral­ly does not requi­re des­truc­tion. Moreo­ver, anony­mizati­on is a via­ble alter­na­ti­ve for dele­ti­on, regard­less of the pur­po­se of anony­mizati­on (even though this view is debated);
  • Data por­ta­bi­li­ty: Data sub­jects have a right to obtain cer­tain per­so­nal data in a stan­dard elec­tro­nic for­mat or have data trans­fer­red to ano­ther controller;
  • Auto­ma­ted indi­vi­du­al decis­i­on-making: The­re is not a requi­re­ment to estab­lish legal grounds, but the con­trol­ler must inform the sub­jects and accept escala­ti­on rights.

Access right

Simi­lar to the GDPR, data sub­jects have the right to access their data. Sub­ject access requests (SARs) may be made in wri­ting or any other form, unless the revFDPO will have for­mal requi­re­ments, and must gene­ral­ly include pro­of of iden­ti­ty. The cur­rent, accept­ed prac­ti­ce is to requi­re a copy of an ID docu­ment as pro­of, and we expect this prac­ti­ce will con­ti­n­ue under the FDPA.
On request, con­trol­ler must pro­vi­de the fol­lo­wing to sub­jects making a SAR:

  • Name and details of the controller(s)
  • Pro­ce­s­sing purposes
  • Cate­go­ries of data, if not coll­ec­ted from the subject
  • Reci­pi­en­ts or cate­go­ries of recipients
  • Whe­re appli­ca­ble, ade­qua­te safe­guards for trans­fers abroad or exemp­ti­ons applicable
  • Reten­ti­on time or criteria
  • Infor­ma­ti­on about the source of data, to the ext­ent available
  • Auto­ma­ted indi­vi­du­al decis­i­on-making
    In addi­ti­on, con­trol­lers must pro­vi­de a copy of the per­so­nal­ly iden­ti­fia­ble data pro­ce­s­sed.
    The requi­red infor­ma­ti­on must be given free of char­ge, except that con­trol­lers may char­ge a fee of up to CHF 300 whe­re SARs respon­ding to SARs leads to dis­pro­por­tio­na­te efforts (artic­le 19 FDPO). Under the FDPA, access must be pro­vi­ded within 30 days from rece­ipt of the SAR (or pro­of of iden­ti­ty, whi­che­ver is later), but the con­trol­ler may extend this peri­od by pro­vi­ding noti­ce to the sub­ject within the 30 days (artic­le 18 FDPO). No rest­ric­tions app­ly as to the grounds of exten­si­on, pro­vi­ded they are rea­sonable.
    The fol­lo­wing excep­ti­ons from the access rights app­ly (artic­le 26 FDPA; we only list the excep­ti­ons that poten­ti­al­ly app­ly for pri­va­te com­pa­nies not acting as fede­ral bodies):
  • Refu­sing, rest­ric­ting or defer­ring access is neces­sa­ry to pro­tect pre­vai­ling inte­rests of a third party;
  • the SAR is mani­fest­ly unfoun­ded, in par­ti­cu­lar whe­re its pur­po­se is con­tra­ry to data pro­tec­tion or obvious­ly frivolous;
  • refu­sing, rest­ric­ting or defer­ring access is requi­red for the controller’s over­ri­ding inte­rests, pro­vi­ded the con­trol­ler does not dis­c­lo­se the data to third par­ties (which exclu­des pro­ces­sors and affi­lia­ted com­pa­nies).
    Whe­re the con­trol­ler reli­es on such an excep­ti­on, it must indi­ca­te its rea­sons (artic­le 26(4) FDPA). In prac­ti­ce, courts requi­re a fair­ly detail­ed expl­ana­ti­on.
    In addi­ti­on to the grounds men­tio­ned abo­ve, the media may refu­se or rest­rict access whe­re per­so­nal data is used exclu­si­ve­ly for publi­ca­ti­on in the edi­ted sec­tion of a peri­odi­cal­ly published medi­um as neces­sa­ry to pro­tect sources, draft publi­ca­ti­ons or the free for­ma­ti­on of the public opi­ni­on, and jour­na­lists may refu­se, rest­rict or defer access to per­so­nal data used exclu­si­ve­ly as a per­so­nal work instru­ment. Howe­ver, depen­ding on the cir­cum­stances and the level of their edi­to­ri­al work, plat­form pro­vi­ders may not be con­side­red to be part of the “media”.

Data por­ta­bi­li­ty

Under artic­le 28 FDPA, data sub­jects may request a copy of per­so­nal data in a stan­dard elec­tro­nic for­mat (for exam­p­le an Excel file) or may have data trans­fer­red to ano­ther con­trol­ler.
The por­ta­bi­li­ty right applies only to data (artic­le 20 FDPO) that:

  • is pro­ce­s­sed in an auto­ma­ted man­ner; and
  • has been pro­vi­ded vol­un­t­a­ri­ly by the data sub­ject or is obser­ved from the data subject’s beha­viour, exclu­ding deri­ved data such as affi­ni­ty clu­sters or AI or machi­ne-lear­ning pat­terns.
    The con­trol­ler may refu­se, rest­rict or defer por­ta­bi­li­ty in the fol­lo­wing sce­na­ri­os (artic­le 29(1) FDPA; the same sce­na­ri­os that rest­rict the right of access):
  • The mea­su­re is neces­sa­ry to pro­tect pre­vai­ling inte­rests of a third party;
  • the request is mani­fest­ly unfoun­ded, in par­ti­cu­lar whe­re its pur­po­se is con­tra­ry to data pro­tec­tion or obvious­ly frivolous;
  • the mea­su­re is requi­red for the controller’s over­ri­ding inte­rests, pro­vi­ded the con­trol­ler does not dis­c­lo­se the data to third par­ties (which exclu­des pro­ces­sors and affi­lia­ted com­pa­nies).
    Again, whe­re the con­trol­ler reli­es on such an excep­ti­on, it must indi­ca­te its rea­sons (artic­le 29(2) FDPA).

Civil lia­bi­li­ty

A breach of the FDPA may lead to civil claims against the con­trol­ler and/or the pro­ces­sor in breach, inclu­ding cea­se and desist claims and claims for com­pen­sa­ti­on of mone­ta­ry dama­ges. Howe­ver, it would be on the clai­mant to estab­lish and quan­ti­fy the eco­no­mic loss suf­fe­r­ed as a result of the breach, which is usual­ly a chall­enge in prac­ti­ce. Data sub­jects can also enforce their rights of infor­ma­ti­on, cor­rec­tion and opt-out and may request that a court decis­i­on be published.

Inve­sti­ga­ti­on and orders by the FDPIC

Under the FDPA, the FDPIC may initia­te (ex offi­cio or upon noti­fi­ca­ti­on by a sub­ject or other par­ty) an inve­sti­ga­ti­on against con­trol­lers and pro­ces­sors if the­re are suf­fi­ci­ent indi­ca­ti­ons that pro­ce­s­sing could vio­la­te the FDPA (artic­le 49(1) FDPA. Con­trol­lers and pro­ces­sors must pro­vi­de the FDPIC with all infor­ma­ti­on and make available all docu­ments that are neces­sa­ry for the inve­sti­ga­ti­on (artic­le 49(3) and 50(1) FDPA).
If the FDPIC con­clu­des that the FDPA is vio­la­ted, the FDPIC may order that the pro­ce­s­sing is ful­ly or par­ti­al­ly adju­sted, sus­pen­ded or ter­mi­na­ted and that the per­so­nal data is ful­ly or par­ti­al­ly dele­ted or destroy­ed (artic­le 51(1) FDPA). The FDPIC may also defer or pro­hi­bit dis­clo­sure abroad and may order that the con­trol­ler and/or pro­ces­sor, as applicable,

  • informs the FDPIC about cross-bor­der transfers;
  • take the mea­su­res requi­red under the data pro­tec­tion by design and by default and the data secu­ri­ty principles;
  • inform the data sub­jects about the processing;
  • per­form a DPIA and, if appli­ca­ble, con­sult the FDPIC;
  • inform the FDPIC and/or, as appli­ca­ble, the data sub­jects of a data secu­ri­ty breach;
  • pro­vi­de access to the data subject;
  • desi­gna­te a CH Repre­sen­ta­ti­ve (cf. seq. 17 et seq.).
    The FDPIC may also inform the public of his fin­dings and his decis­i­ons in cases of gene­ral inte­rest (artic­le 57(2) FDPA), which may lead to nega­ti­ve publi­ci­ty. Moreo­ver, as noted abo­ve the FDPIC is sub­ject to the Free­dom of Infor­ma­ti­on Act and may be requi­red to release infor­ma­ti­on to the public or the media, on request.


Dif­fe­rent from the GDPR, the FDPA gene­ral­ly does not pro­vi­de for fines on legal enti­ties (but see below). Howe­ver, cer­tain brea­ches may lead to fines of up to CHF 250,000 being impo­sed on the indi­vi­du­als respon­si­ble for a breach, inclu­ding, if appli­ca­ble, on direc­tors and offi­cers and employees with inde­pen­dent decis­i­on-making power (artic­le 29 of the Cri­mi­nal Code), pro­vi­ded the­se brea­ches have been com­mit­ted wilful­ly (cf. artic­le 12 Cri­mi­nal Code) and on con­di­ti­on that a sub­ject makes a com­plaint. The­se brea­ches include (artic­les FDPA):

  • fail­ure to pro­vi­de the requi­red infor­ma­ti­on to the data subjects;
  • fail­ure to com­ply with the access right;
  • fail­ure to coope­ra­te with a FDPIC inve­sti­ga­ti­on or to pro­vi­de truthful infor­ma­ti­on to the FDPIC, or to com­ply with an order by the FDPIC;
  • pro­vi­ding infor­ma­ti­on to a reci­pi­ent abroad in vio­la­ti­on of trans­fer restrictions;
  • dis­clo­sing per­so­nal data to a data pro­ces­sor in vio­la­ti­on of a con­fi­den­tia­li­ty obli­ga­ti­on, or wit­hout ensu­ring ade­qua­te secu­ri­ty mea­su­res on the part of the processor;
  • do not take the mini­mum secu­ri­ty mea­su­res that may be set out in the revFDPO;
  • fail­ure to com­ply with the obli­ga­ti­on of cer­tain pro­fes­sio­nals to keep non-public data con­fi­den­ti­al if the sub­ject con­fi­den­tia­li­ty (regard­less of whe­ther the data is sen­si­ti­ve or not).
    In the event of such a breach, a fine of up to CHF 50,000 may be impo­sed on the con­trol­ler or pro­ces­sor in breach whe­re the indi­vi­du­als respon­si­ble for the breach can­not be or are not identified.

Gene­ral principles

Under artic­le 328b of the Swiss Code of Obli­ga­ti­ons (CO), employee data must not be pro­ce­s­sed unless pro­ce­s­sing is objec­tively rela­ted to job appli­ca­ti­ons or the employment rela­ti­on­ship. This rest­ricts both the cate­go­ries that an employer may pro­cess lawful­ly, such as when asses­sing poten­ti­al can­di­da­tes and throug­hout the employment rela­ti­on­ship, but also the scope and pur­po­ses of its pro­ce­s­sing.
Artic­le 328b CO most­ly takes up the gene­ral prin­ci­ple of pur­po­se limi­ta­ti­on and data mini­mizati­on. As such, it does not impo­se requi­re­ments that would not fol­low from the FDPA. Howe­ver, courts would likely app­ly slight­ly stric­ter cri­te­ria when asses­sing the lawful­ness of data pro­ce­s­sing within the employment rela­ti­on­ship.
Whe­re an employer intends to use per­so­nal data in a man­ner that is not requi­red for the employment rela­ti­on­ship, for exam­p­le using employee pho­tos on a web­site, the employer will usual­ly rely on con­sent. Employee con­sent remains a valid basis, pro­vi­ded that it is given free­ly, and the infor­ma­ti­on given to the employee is sufficient.

Shared ser­vices within a group

In a typi­cal group sce­na­rio, employee data will be shared with other enti­ties through an HR infor­ma­ti­on manage­ment system (“HRIS”), through shared employee lists and for report­ing pur­po­ses. Group com­pa­nies enga­ging in the­se pro­ce­s­sing pur­po­ses will fre­quent­ly act as joint con­trol­lers, though this requi­res a case-by-case ana­ly­sis. In addi­ti­on, one or seve­ral enti­ties
will act as group-inter­nal ser­vice pro­vi­ders (e.g., to pro­vi­de shared reports, or ope­ra­te an HRIS). This will requi­re one or seve­ral data pro­ce­s­sing agree­ments, in addi­ti­on to any joint con­trol­ler arran­ge­ments or con­trol­ler-to-con­trol­ler agree­ments.
Howe­ver, whe­re the pur­po­se of such shared pro­ce­s­sing is not bey­ond what employees would rea­son­ab­ly expect and is pro­per­ly explai­ned in an employee pri­va­cy noti­ce, it is usual­ly con­side­red to be con­si­stent with the pro­ce­s­sing prin­ci­ples as well as with artic­le 328b CO. Employee con­sent is the­r­e­fo­re usual­ly not a requi­re­ment in the­se scenarios.