Pri­va­cy FAQ

To make it easier to get star­ted in the com­plex field of data pro­tec­tion law, we have com­pi­led a list of com­mon que­sti­ons and tried to ans­wer them in an easy-to-under­stand way. 

It goes without say­ing that the fol­lo­wing list is not exhaus­ti­ve. The selec­tion of que­sti­ons and our ans­wers do not con­sti­tu­te legal advice. They are out­side the scope of a man­da­te, and we give No war­ran­ty and also assu­me no lia­bi­li­ty. In par­ti­cu­lar, we can­not gua­ran­tee that a data pro­tec­tion aut­ho­ri­ty or a court will not take a dif­fe­rent view – on the contrary.

The list is Work in Pro­gress. Cur­rent Sta­tus: 25.07.2022.

We also pro­vi­de Notes on the imple­men­ta­ti­on of the revi­sed DPA avail­ab­le. You can also find fur­ther details in our link collection.

FAQ over­view

Gene­ral questions

Data pro­tec­tion law is the set of legal norms that regu­la­te the hand­ling of per­so­nal data and the rela­ted rights and obligations.

First of all, a distinc­tion can be made bet­ween for­mal and sub­stan­ti­ve data pro­tec­tion law: For­mal data pro­tec­tion law is the data pro­tec­tion laws of the Con­fe­de­ra­ti­on, the can­tons and the muni­ci­pa­li­ties with the cor­re­spon­ding imple­men­ting pro­vi­si­ons. The sub­stan­ti­ve data pro­tec­tion laws are the­se and all other pro­vi­si­ons that regu­la­te per­so­nal data. They are scat­te­red in various enact­ments, e.g. in social secu­ri­ty law, finan­cial mar­ket law, ener­gy law, tele­com­mu­ni­ca­ti­ons law, etc. Fre­quent sub­jects of regu­la­ti­on are secrecy pro­vi­si­ons (e.g. Art. 33 ATSG, Art. 86 BVG, Art. 47 BankG, Art. 69 FINIG, Art. 321 StGB, Art. 43 FMG etc.) and, in the case of federal bodies, legal bases for the pro­ces­sing of per­so­nal data and their dis­clo­sure (e.g. Art. 84 f. KVG, Art. 4 BÜPF, Art. 112a DBG etc.).

A distinc­tion can also be made bet­ween data pro­tec­tion law in the nar­rower and broa­der sen­se. Data pro­tec­tion law in the nar­rower sen­se spe­ci­fi­cal­ly regu­la­tes the hand­ling of per­so­nal data, while data pro­tec­tion law in the broa­der sen­se regu­la­tes the hand­ling of cer­tain data that can be or usual­ly is per­so­nal (such as secrecy provisions).

Final­ly, data pro­tec­tion law can be under­s­tood as part of data law. Data law inclu­des all pro­vi­si­ons that regu­la­te the hand­ling of data, even if they are not per­so­nal (“data” under­s­tood as infor­ma­ti­on that under­goes some embo­di­ment, even if only as a sound – the law cap­tures infor­ma­ti­on only when it is embo­di­ed, it can­not cap­tu­re the pure information). 

Wit­hin data pro­tec­tion law, a distinc­tion can then be made bet­ween levels – this could be descri­bed as an oni­on model. At the core are the mate­ri­al requi­re­ments for hand­ling per­so­nal data, abo­ve all the pro­ces­sing princi­ples. In addi­ti­on, the­re is a fur­ther lay­er of obli­ga­ti­ons of the data con­trol­ler that do not direct­ly rela­te to the hand­ling of per­so­nal data, but are inten­ded to safe­guard it. The­se inclu­de, for examp­le, the obli­ga­ti­on to main­tain a pro­ces­sing direc­to­ry, to con­duct a data pro­tec­tion impact assess­ment or to report a secu­ri­ty bre­ach. A third lay­er is for­med by data sub­ject rights, which are inten­ded to enab­le the data sub­ject to influ­ence data pro­ces­sing. The fourth lay­er con­sists of the FDPIC’s super­vi­so­ry powers and sanctions. 

In Switz­er­land:

  • Cur­r­ent­ly, pri­ma­ri­ly in the Federal Data Pro­tec­tion Act (FDPA) and in the Ordi­nan­ce to the FADP (FDPO). This app­lies to pri­va­te com­pa­nies and to federal bodies. For public bodies of the can­tons and muni­ci­pa­li­ties, the can­to­nal data pro­tec­tion laws are app­li­ca­ble (see Links).
  • Data pro­tec­tion law is being revi­sed. The revi­sed DPA (revFDPA) is avail­ab­le in a final ver­si­on. The VDSG is also being revi­sed, but is cur­r­ent­ly only known in a non-final draft (draft FDPO).
  • Depen­ding on the area and acti­vi­ty, spe­cial regu­la­ti­ons app­ly that govern a par­ti­cu­lar indu­stry or acti­vi­ty, e.g. the law against unfair com­pe­ti­ti­on, finan­cial mar­ket law, social secu­ri­ty law, etc. Data pro­tec­tion regu­la­ti­ons are often found here as well. In addi­ti­on, secrecy pro­vi­si­ons may app­ly, e.g. for banks, other finan­cial insti­tu­ti­ons, doc­tors, tele­com­mu­ni­ca­ti­ons ser­vice pro­vi­ders, health insu­rers, pen­si­on funds, etc. 

In Euro­pe:

  • Here app­lies abo­ve all the GDPR.
  • Even though the GDPR com­pre­hen­si­ve­ly regu­la­tes data pro­tec­tion law per se, the mem­ber sta­tes retain a cer­tain amount of lee­way. The EEA mem­ber sta­tes the­re­fo­re con­ti­nue to have their own data pro­tec­tion laws with which they fill gaps in the GDPR (see Links).
  • Depen­ding on the area, spe­cial regu­la­ti­ons also app­ly here, e.g. in the area of e‑commerce or for coo­kies and other tech­no­lo­gies on the Inter­net and apps.

The law on the pro­tec­tion of secrets pro­tects secrets. The­se inclu­de the pro­fes­sio­nal secrets of, for examp­le, doc­tors, psy­cho­lo­gists, lawy­ers, bank employees, employees of finan­cial insti­tu­ti­ons, etc. Pro­fes­sio­nal secrets may also app­ly under can­to­nal law, and also under pro­fes­sio­nal and ethi­cal law. Rela­ted to pro­fes­sio­nal secrecy is also offi­cial secrecy. 

In addi­ti­on, the­re are tra­de secrets, which are pro­tec­ted, for examp­le, by cri­mi­nal law and the law on fair trading. 

Howe­ver, the­re is no gene­ral law on the pro­tec­tion of secrets. The­re are basic struc­tures, in par­ti­cu­lar simi­la­ri­ties in the con­cept of a secret and the facts of dis­clo­sure. Howe­ver, the­re are nuan­ces depen­ding on the secret. For examp­le, the intent to keep a secret, which deter­mi­nes the scope of pro­tec­tion for most secrets, may dif­fer depen­ding on the type of secret. 

Yes, many, and more and more. Both are­as are con­ver­ging to a cer­tain extent. This is main­ly due to the fact that both are­as have beco­me much more important in the cour­se of digi­tiz­a­ti­on and are being dis­cus­sed in cor­re­spon­din­gly grea­ter detail. The­se in-depth ana­ly­ses incre­a­singly bring to light com­mo­na­li­ties, such as the import­ance of the expec­ta­ti­ons of the pro­tec­ted per­sons, i.e., the data sub­jects and the secrecy masters. 

In addi­ti­on, the­re is grea­ter con­trol of data pro­tec­tion law through cri­mi­nal sanc­tions. This streng­t­hens cri­mi­nal data pro­tec­tion law, and espe­cial­ly in situa­tions whe­re data is dis­c­lo­sed to third par­ties. It is no coin­ci­dence that the revDSG pro­vi­des for pen­al­ties pre­cise­ly in such situa­tions, e.g., order pro­ces­sing, dis­clo­sure abroad, and dis­clo­sure of secret per­so­nal data (alt­hough not exclu­si­ve­ly in the­se cases). This sanc­tio­n­ing of dis­clo­sure brings data pro­tec­tion law clo­ser to secrecy law, even though the­re remain fun­da­men­tal dif­fe­ren­ces bet­ween the two.

On the revi­si­on of the DPA

On Sep­tem­ber 1, 2023. In August 2022, the Federal Coun­cil still bare­ly put the revDSG and the revi­sed VDSG – now “DSV” – into for­ce on Sep­tem­ber 1, 2023 with an infor­mal tran­si­ti­on peri­od of one year.

Yes, becau­se it makes data pro­tec­tion law more for­ma­li­stic to a cer­tain extent, becau­se it tigh­tens data pro­tec­tion law in gene­ral, and becau­se it intro­du­ces new sanctions.

Howe­ver, this is not the only rea­son why it is important. The expec­ta­ti­ons of custo­mers, inve­stors, aut­ho­ri­ties, part­ners and the public are also chan­ging – while data pro­tec­tion was not a big issue for sta­ke­hol­ders for a long time, out­side regu­la­ted indu­stries, it is now gai­ning a lot of attention.

Com­pa­nies can the­re­fo­re not avoid dealing with data pro­tec­tion and an appro­pria­te imple­men­ta­ti­on of the new requirements.

Our con­tri­bu­ti­ons to the revi­si­on can be found here.

Yes. The revi­sed DPA pro­vi­des for mea­su­res and pro­ces­ses that many com­pa­nies do not have or have only ina­de­qua­te­ly. Unre­gu­la­ted lar­ger com­pa­nies that ope­ra­te only or pre­do­mi­nant­ly in Switz­er­land are par­ti­cu­lar­ly chal­len­ged. Whe­re the GDPR has alrea­dy been imple­men­ted – to the extent that this is pos­si­ble at all – imple­men­ta­ti­on is easier, but cer­tain work will also be requi­red here.

Notes on imple­men­ta­ti­on can be found here.

You can our con­tri­bu­ti­ons to the revi­si­on read. You can also read our Sub­scri­be to news­let­ter

Hel­pful infor­ma­ti­on can also be found in the Federal Council’s mes­sa­ge on the draft of the revDSG, e.g. here or here. And a com­pre­hen­si­ve account you will find by David Rosen­thal.

on the GDPR

The GDPR is the EU and EEA Gene­ral Data Pro­tec­tion Regu­la­ti­on (the EEA inclu­des the mem­ber sta­tes of the EU and addi­tio­nal­ly Nor­way, Ice­land and the Princi­pa­li­ty of Liech­ten­stein). The GDPR ente­red into for­ce on 27 April 2016 and has been app­li­ca­ble sin­ce 25 May 2018.

The GDPR con­tains strict and part­ly unworld­ly pro­vi­si­ons. The­re are signi­fi­cant dif­fe­ren­ces to Swiss law, inclu­ding the revDSG. For examp­le, every pro­ces­sing (accord­ing to the GDPR: “pro­ces­sing”) of per­so­nal data (accord­ing to the GDPR: “per­so­nal data”) requi­res its own legal basis. This leads to the need to search for the appro­pria­te legal basis for many pro­ces­sing ope­ra­ti­ons, even inno­cuous ones. And par­ti­cu­lar­ly time-con­su­ming: The GDPR requi­res com­pa­nies to com­pre­hen­si­ve­ly docu­ment the law­ful­ness of their data pro­ces­sing. If the app­li­ca­ble rules are com­plied with but appro­pria­te docu­men­ta­ti­on is mis­sing, this absence alo­ne con­sti­tu­tes a vio­la­ti­on of the GDPR that can be sanc­tion­ed. This is the other big issue with the GDPR: Vio­la­ti­ons can be sub­ject to hea­vy fines, and unli­ke in Switz­er­land, not only indi­vi­du­al vio­la­ti­ons and not only in case of intent.

The GDPR is a regu­la­ti­on, not a direc­ti­ve. It the­re­fo­re did not have to be trans­po­sed into mem­ber sta­te law. Becau­se a cer­tain degree of federa­lism still exists in the EU, the GDPR lea­ves the mem­ber sta­tes room for their own addi­tio­nal regu­la­ti­ons in the area of data pro­tec­tion. This app­lies in par­ti­cu­lar to the area of employ­ment, but also, for examp­le, the excep­ti­ons to the rights of data sub­jects are to be deter­mi­ned by the sta­tes. The­re­fo­re, in addi­ti­on to the GDPR, mem­ber sta­te regu­la­ti­ons must also be obser­ved. Data pro­tec­tion laws, e.g., the BDSG in Ger­ma­ny, the DSG in Liech­ten­stein, the DSG in Austria, or the Loi Infor­ma­tique et Liber­tés in France.

Yes and no. It is clear that data pro­tec­tion law was hard­ly enfor­ced for a long time. This was even more true in Switz­er­land than in Euro­pe. Tigh­tening up made per­fect sense. 

On the other hand, the GDPR has major flaws. In parts, it is unworld­ly, and in many points it is for­ma­li­stic. Howe­ver, this is not only due to the GDPR, but also to its inter­pre­ta­ti­on by data pro­tec­tion super­vi­so­ry aut­ho­ri­ties, which often tend to inter­pret the GDPR very strict­ly. This harms the accep­t­ance of data pro­tec­tion law. It is also not justi­fied becau­se the­re are various fun­da­men­tal rights that need to be weig­hed. The pro­tec­tion of data sub­jects is not an abso­lu­te con­cern. The­re is also, for examp­le, eco­no­mic free­dom. Unfor­tu­n­a­te­ly, this is often forgotten.

This is often a dif­fi­cult que­sti­on to ans­wer. It is likely that cer­tain pro­ces­sing ope­ra­ti­ons fall under the GDPR if you can ans­wer yes to any of the fol­lo­wing questions:

  • Do you have a sub­si­dia­ry in the EEA?
  • Do you have ano­t­her branch office in the EEA, e.g. a sub­si­dia­ry, a branch office, a rep office, a repre­sen­ta­ti­ve office? Home office employees are hard­ly enough for this.
  • Are you doing anything to attract end custo­mers (natu­ral per­sons) in the EEA as custo­mers, e.g. through direct mar­ke­ting or through an appro­pria­te­ly desi­gned web­site? Howe­ver, cross-bor­der com­mu­ters are not end custo­mers – employees living abroad who work for Switz­er­land are the­re­fo­re hard­ly suf­fi­ci­ent for the app­li­ca­ti­on of the GDPR.
  • Do you have end custo­mers (natu­ral per­sons) in the EEA – not just iso­la­ted, ran­dom ones, but a rele­vant number?
  • Do you enga­ge in any form of tracking through a web­site or app, inclu­ding collec­ting data from indi­vi­du­als in the EEA?
  • Do you other­wi­se collect infor­ma­ti­on about the beha­vi­or of natu­ral per­sons in the EEA over a peri­od of time, e.g., through a tacho­graph or home office monitoring?

If you ans­wer yes to any que­sti­on, you should check the app­li­ca­bi­li­ty of the GDPR more clo­se­ly. If not, it is unli­kely that you are cove­r­ed by the GDPR.

But: Switz­er­land has its own rules that can lead to app­li­ca­bi­li­ty of the GDPR (in the “IPRG”). If you pro­cess per­so­nal data of per­sons resi­ding in the EEA ter­ri­to­ry, the­se per­sons can usual­ly sue befo­re a Swiss court and demand that their claims be jud­ged accord­ing to the law in their home coun­try. The court would then not con­si­der the abo­ve que­sti­ons, but only ask whe­ther you could expect to pro­cess per­so­nal data in the EEA. If so, it would app­ly the plaintiff’s home law, and that may be the GDPR. So if you employ cross-bor­der workers, they could make a requ­est for infor­ma­ti­on, and if you don’t ans­wer it to the GDPR stan­dard, tho­se cross-bor­der workers could sue you in Switz­er­land at your place of busi­ness and have claims asses­sed under the GDPR. Howe­ver, we are only awa­re of one case so far whe­re a lawsu­it was filed in Switz­er­land on the basis of the GDPR (unsuc­cess­ful­ly).

Inci­dent­al­ly, the­re are cases in which the GDPR must or should be com­plied with, even if a com­pa­ny is not its­elf cove­r­ed by the GDPR. This app­lies in par­ti­cu­lar to group com­pa­nies, if the group wants to com­ply with the GDPR as a gene­ral stan­dard, and IT ser­vice pro­vi­ders, who­se custo­mers in turn must com­ply with the GDPR and the­re­fo­re demand the same from their ser­vice provider.

Com­pli­an­ce with the GDPR can also be part of a company’s posi­tio­ning, as part of sustaina­bi­li­ty (as “cor­po­ra­te digi­tal respon­si­bi­li­ty”) and trust­worthy dealings with end customers.

Terms

Per­so­nal data is any infor­ma­ti­on that rela­tes to an iden­ti­fied or iden­ti­fia­ble indi­vi­du­al (alt­hough today’s DPA also covers infor­ma­ti­on that rela­tes to a legal enti­ty, unli­ke the GDPR and also the revDSG).

A per­son is iden­ti­fia­ble if his or her iden­ti­ty is clear from the data record its­elf (e.g., “on Tues­day, Ms. Mül­ler ate with Mr. Peters at Restau­rant X”). The que­sti­on of when and by whom a per­son is iden­ti­fia­ble gives rise to much more dis­cus­sion. In any case, this is the case when someo­ne who has access to a datum can assign it to a per­son becau­se he or she has the necessa­ry addi­tio­nal infor­ma­ti­on (“Employee 123452” is a per­so­nal datum for the HR depart­ment, but not necessa­ri­ly for an outsider.

The main point of dis­cus­sion is whe­ther iden­ti­fia­bi­li­ty is only to be assu­med if someo­ne with access to the date can infer a per­son (“rela­ti­ve approach”) or alrea­dy if any third par­ty could do so (“abso­lu­te approach”). In Switz­er­land, accord­ing to the Logi­step ruling of the Federal Supre­me Court the rela­ti­ve approach. In Euro­pe, accord­ing to the Brey­er deci­si­on of the ECJ same, but the requi­re­ments for deter­mina­bi­li­ty are set qui­te low.

Also dis­cus­sed is whe­ther iden­ti­fi­ca­ti­on requi­res know­ledge of a name or other com­mon iden­ti­fier, or whe­ther it is suf­fi­ci­ent that a per­son – even if unknown – can be distin­guis­hed from all others (“Sin­gu­la­riz­a­ti­on”). Euro­pean aut­ho­ri­ties seem to be incre­a­singly turn to the con­cept of sin­gu­la­riz­a­ti­on, ulti­mate­ly for pure­ly pro­tec­ti­ve con­si­de­ra­ti­ons and the­re­fo­re as a mat­ter of poli­cy rather than law.

No per­so­nal data is data that has been anonymized.

The FADP and – with cer­tain amend­ments – also the revDSG con­si­der cer­tain types of per­so­nal data to be par­ti­cu­lar­ly sen­si­ti­ve. The­se data are given spe­cial pro­tec­tion in cer­tain respects. For examp­le, under the cur­rent FADP, expli­cit infor­ma­ti­on must alrea­dy be pro­vi­ded when such data is obtai­ned. And the dis­clo­sure of par­ti­cu­lar­ly sen­si­ti­ve per­so­nal data to third par­ties must be justi­fied, i.e. in princip­le it is con­si­de­red to be infrin­ging. The­re are fur­ther con­se­quen­ces of clas­si­fy­ing per­so­nal data as requi­ring spe­cial pro­tec­tion – if such data is pro­ces­sed on the basis of con­sent, this can only be given expli­ci­tly; if the pro­ces­sing is exten­si­ve, a data pro­tec­tion impact assess­ment must be car­ri­ed out; and if such data is pro­ces­sed for non-per­so­nal pur­po­ses, e.g. sta­tis­tics, spe­cial requi­re­ments app­ly. In the case of federal bodies, the pro­ces­sing of data requi­ring spe­cial pro­tec­tion also requi­res a legal basis in a law in the for­mal sen­se, unless an excep­ti­on applies.

Per­so­nal data that is par­ti­cu­lar­ly worthy of pro­tec­tion inclu­des data about reli­gious, ideo­lo­gi­cal, poli­ti­cal or tra­de uni­on views or acti­vi­ties (e.g., pay­ments to a reli­gious com­mu­ni­ty, infor­ma­ti­on about atten­dance at a tra­de uni­on event), health, pri­va­cy (e.g., sexu­al ori­en­ta­ti­on), race (e.g., infor­ma­ti­on about eth­ni­ci­ty), bio­me­tric data (e.g., a facial scan for access), and data about social assi­stance mea­su­res or admi­ni­stra­ti­ve or cri­mi­nal pro­se­cu­ti­ons and sanctions.

Howe­ver, the fact that cer­tain cate­go­ries of data are gene­ral­ly clas­si­fied as requi­ring spe­cial pro­tec­tion con­tra­dicts the risk-based approach, which refers to the con­cre­te rather than an abstract risk. It would also not be prac­ti­ca­ble to con­si­der all data with remo­te­ly or poten­ti­al­ly par­ti­cu­lar­ly pro­tec­ted con­tent as requi­ring spe­cial pro­tec­tion. A pho­to of someo­ne wea­ring glas­ses is the­re­fo­re not con­si­de­red a health datum, and a regio­nal­ly assi­gnab­le name is not con­si­de­red a datum about ethnicity.

No. At any rate, not accord­ing to Swiss law – that is what the still-app­li­ca­ble Logi­step deci­si­on of the Federal Supre­me Court cla­ri­fied. Nevertheless, the­re is a ten­den­cy to con­si­der IP addres­ses and other uni­que iden­ti­fiers, such as a coo­kie ID, as per­so­nal data without any actu­al justi­fi­ca­ti­on. The FDPIC has also alrea­dy moved in this direc­tion. voi­ced. And in Euro­pe this ten­den­cy is clear, here IP addres­ses are basi­cal­ly con­si­de­red as per­so­nal data.

Pro­ces­sing” is an extre­me­ly broad term. Any hand­ling of per­so­nal data is pro­ces­sing, even its anony­miz­a­ti­on or dele­ti­on. At most, it is open whe­ther the mere viewing of a per­so­nal data con­sti­tu­tes processing.

What is a “respon­si­ble person”?

Data pro­tec­tion law reco­gni­zes dif­fe­rent roles depen­ding on the influ­ence on a par­ti­cu­lar data pro­ces­sing. Deter­mi­ning the roles of the par­ties invol­ved is always the star­ting point for an exami­na­ti­on under data pro­tec­tion law.

The “respon­si­ble par­ty” is the com­pa­ny (usual­ly a com­pa­ny; it can also be an indi­vi­du­al) that decisi­ve­ly deter­mi­nes the data pro­ces­sing. This is deter­mi­ned by two cri­te­ria: The con­trol­ler initia­tes the data pro­ces­sing, i.e. he sets the rea­son that it takes place in its con­cre­te form in the first place, and thus also what pur­po­se it ser­ves. And he deter­mi­nes the essen­ti­al frame­work con­di­ti­ons of the pro­ces­sing, i.e. which data are pro­ces­sed by which per­sons and for how long, and to whom they are dis­c­lo­sed if necessary.

A data con­trol­ler is, for examp­le, a com­pa­ny for pro­ces­sing the per­so­nal data of its employees, or a com­pa­ny for its own direct mar­ke­ting, but also a federal body to which a sta­tu­to­ry task is assigned.

A con­trol­ler remains respon­si­ble even if it out­sour­ces data pro­ces­sing to a ser­vice pro­vi­der. It may even be the case that he neit­her has nor knows the pro­ces­sed data hims­elf – even then a com­pa­ny may be respon­si­ble, pro­vi­ded that it decisi­ve­ly deter­mi­nes the data pro­ces­sing of a third party.

Several com­pa­nies can share the role of a con­trol­ler – in this case they are “joint­ly respon­si­ble per­sons”. This is the case when they joint­ly deter­mi­ne the pur­po­ses of a pro­ces­sing ope­ra­ti­on and also its essen­ti­al frame­work con­di­ti­ons. Howe­ver, the exact cri­te­ria are dif­fi­cult to defi­ne. This is due, on the one hand, to the lack of clear state­ments by the Euro­pean aut­ho­ri­ties and, on the other hand, to three rulings by the ECJ, in which joint respon­si­bi­li­ty was assu­med on a case-by-case basis, alt­hough it is dif­fi­cult to iden­ti­fy a com­mon thread.

Howe­ver, one can essen­ti­al­ly distin­guish two con­stel­la­ti­ons of shared responsibility:

Joint respon­si­bi­li­ty often exists when several com­pa­nies use the same system for simi­lar pro­ces­sing and the­re­fo­re joint­ly enga­ge a ser­vice pro­vi­der. Par­ti­cu­lar­ly in a group rela­ti­ons­hip, this is obvious in the case of joint­ly used group ser­vices, e.g. joint manage­ment of employee data or a joint CRM database.

Shared respon­si­bi­li­ty may also exist when a con­trol­ler pro­ces­ses data and dis­c­lo­ses it to ano­t­her con­trol­ler, doing so in its own inte­rest and kno­wing for what pur­po­ses and how it will use that data.

In prac­ti­ce, joint respon­si­bi­li­ties are incre­a­singly assu­med when several com­pa­nies work tog­e­ther in part­nership and both have a signi­fi­cant influ­ence on the processing.

Swiss data pro­tec­tion law does not expli­ci­tly requi­re that joint­ly respon­si­ble par­ties con­clu­de a con­tract, unli­ke the GDPR requi­res in most cases. The­re­fo­re, an unno­ti­ced joint respon­si­bi­li­ty does not necessa­ri­ly con­sti­tu­te a bre­ach. Howe­ver, it makes sen­se that when pro­ces­sing ope­ra­ti­ons of several com­pa­nies are inter­min­gled, a regu­la­ti­on is made as to who ful­fills which obli­ga­ti­ons under data pro­tec­tion law, e.g., who informs data sub­jects about the pro­ces­sing, who ensu­res the secu­ri­ty of joint­ly used IT systems, and who deals with inqui­ries from data subjects.

By the way, such regu­la­ti­ons are not only use­ful in the case of joint­ly respon­si­ble per­sons, but often also when several respon­si­ble per­sons work tog­e­ther independently.

An order pro­ces­sor is a com­pa­ny (or per­son) that pro­ces­ses data but does not deter­mi­ne the spe­ci­fic pro­ces­sing. This app­lies in par­ti­cu­lar – but not only – to IT ser­vice pro­vi­ders. For examp­le, a hosting ser­vice pro­vi­der is an order pro­ces­sor, as is a cloud pro­vi­der or the ope­ra­tor of a SaaS solu­ti­on. The nar­rower the pur­po­se of the SaaS solu­ti­on, the more influ­ence the ope­ra­tor has on the type of data pro­ces­sing. Howe­ver, it does so gene­ri­cal­ly through the system design and not in rela­ti­on to con­cre­te, indi­vi­du­al data; the user of the solu­ti­on deter­mi­nes this. The­re­fo­re, the SaaS pro­vi­der remains an order processor.

Howe­ver, not all ser­vice pro­vi­ders are also order pro­ces­sors. Some ser­vice pro­vi­ders pro­cess per­so­nal data for the ful­fill­ment of the order, but deter­mi­ne lar­ge­ly free­ly. An examp­le is a law firm that con­ducts pro­ce­e­dings for a cli­ent. It is a con­trac­tor, but it deter­mi­nes its­elf which data it needs for this pur­po­se. Rule of thumb: A ser­vice pro­vi­der is a com­mis­sio­ned pro­ces­sor if the object of the ser­vice is pri­ma­ri­ly the pro­ces­sing of per­so­nal data. He is a con­trol­ler if his ser­vice is of a dif­fe­rent natu­re and he pro­ces­ses per­so­nal data only as a secon­da­ry con­se­quence of this service.

Examp­les can be found, among others, in a List of the Bava­ri­an Sta­te Office for Data Pro­tec­tion and in a Essay by David Rosen­thal.

You will find fur­ther notes on order pro­ces­sing under the cor­re­spon­ding heading.

Anony­miz­a­ti­on and pseudonymization

The star­ting point is the con­cept of per­so­nal data. Infor­ma­ti­on is per­so­nal if it rela­tes to a spe­ci­fic or iden­ti­fia­ble per­son. A date is “anony­mous” if it has no per­so­nal refe­rence becau­se it was never per­so­nal or becau­se the per­so­nal refe­rence was later drop­ped. “Anony­mi­zed” is a data item that had a refe­rence to a per­son, but for which the refe­rence to a per­son was deli­ber­ate­ly removed. 

This means that the requi­re­ments for anony­miz­a­ti­on are not hig­her than, con­ver­se­ly, the requi­re­ments for per­so­nal reference. 

If a date has been anony­mi­zed, it is no lon­ger a per­so­nal date. Data pro­tec­tion law the­re­fo­re no lon­ger app­lies to this date. Under data pro­tec­tion law, the pro­ces­sing of this date is the­re­fo­re no lon­ger restricted. 

It also fol­lows that anony­miz­a­ti­on has the same effect under data pro­tec­tion law as dele­ti­on. For if data pro­tec­tion law does not app­ly to anony­mous data, it can­not demand its dele­ti­on either.

Pseud­ony­miz­a­ti­on means that the refe­rence to a per­son in a per­so­nal data is indi­rect – it is pre­sent, but the refe­rence to a per­son does not result from the data its­elf (i.e. not “Ms. Mey­er­hans”), but only from addi­tio­nal infor­ma­ti­on (i.e. “employee 68796”, whe­re a sepa­ra­te table assigns the num­ber 68796 to Ms. Meyerhans). 

Pseud­ony­miz­a­ti­on is achie­ved when this assign­ment is kept sepa­ra­te from the pseud­ony­mi­zed data its­elf, i.e., more pre­cise­ly, when the office, per­son or depart­ment that works with the pseud­ony­mi­zed data does not have access to the cor­re­spon­ding assign­ment. A cer­tain degree of orga­niz­a­tio­nal and infor­ma­tio­nal sepa­ra­ti­on is the­re­fo­re required.

Pseud­ony­miz­a­ti­on is first of all a secu­ri­ty mea­su­re. It does not mean that the per­son respon­si­ble who has car­ri­ed out pseud­ony­miz­a­ti­on in his orga­niz­a­ti­on no lon­ger pro­ces­ses per­so­nal data – the date is pseud­ony­mi­zed, not anony­mi­zed. Howe­ver, it incre­a­ses the pro­tec­tion of the data in que­sti­on. It can the­re­fo­re lead to com­pli­an­ce with the princip­le of data secu­ri­ty, but also to the fact that an over­ri­ding inte­rest in the pro­ces­sing can rather be affirmed. 

In the case of dis­clo­sure of a pseud­ony­mous datum, the rela­ti­ve approach must be remem­be­red when deter­mi­ning the refe­rence to a per­son. Whe­ther a data item is per­so­nal is deci­ded from the per­spec­ti­ve of the per­son who has access to this data item or is respon­si­ble for its pro­ces­sing. This has the fol­lo­wing effect: If per­son A dis­c­lo­ses a pseud­ony­mi­zed datum that has per­so­nal rele­van­ce for him to per­son B, who can­not asso­cia­te this datum with a per­son (becau­se he lacks the asso­cia­ti­on that per­son A has but does not dis­c­lo­se to per­son B), this does not con­sti­tu­te dis­clo­sure of a per­so­nal datum. Per­son A is not sub­ject to data pro­tec­tion law for this dis­clo­sure, and neit­her is Per­son B for its hand­ling of the pseud­ony­mous, but for it anony­mous, data. This must be the case – if per­son B were sub­ject to data pro­tec­tion law, the abso­lu­te rather than the rela­ti­ve approach would apply.

This means, for examp­le, that a doc­tor in Switz­er­land can send a blood sam­ple that has only been indi­vi­dua­li­zed by a bar­code to a labo­ra­to­ry in the USA without the restric­tions on for­eign dis­clo­sure app­ly­ing. Howe­ver, if he recei­ves the eva­lua­ti­on result back, this con­sti­tu­tes data acqui­si­ti­on for him. 

Of cour­se, secu­ri­ty mea­su­res must still be taken, inclu­ding an agree­ment with the reci­pi­ent that the reci­pi­ent will only pro­cess the data recei­ved for the inten­ded pur­po­se and will tre­at it confidentially.

The Federal Supre­me Court was in Logi­step judgment stric­ter – in such a case, data pro­tec­tion law app­lies not only to the reci­pi­ent, but also to the trans­mit­ting enti­ty, for which the trans­mit­ted data has no per­so­nal refe­rence. We con­si­der this ruling to be incon­clu­si­ve and inap­p­li­ca­ble on this point.

Princi­ples of data processing

Accord­ing to both the FADP – and the revDSG – and the GDPR, cer­tain princi­ples must be obser­ved for any pro­ces­sing of per­so­nal data. The­se are the princi­ples of trans­pa­ren­cy, pur­po­se limi­ta­ti­on, pro­por­tio­na­li­ty, data accu­ra­cy and data secu­ri­ty. Howe­ver, data secu­ri­ty is no lon­ger a pro­ces­sing princip­le under the revDSG, or at least not a typi­cal one, after the pro­vi­si­on on per­so­na­li­ty infrin­ge­ment no lon­ger refers to data secu­ri­ty. In addi­ti­on, the­re is the princip­le of good faith.

The rela­ti­ons­hip bet­ween the princi­ples is not very clear. The princip­le of good faith is rather a catch-all princip­le. The three inter­re­la­ted princi­ples of trans­pa­ren­cy, pur­po­se limi­ta­ti­on and pro­por­tio­na­li­ty are decisive:

The point of refe­rence for pro­ces­sing in each case is its pur­po­se. Pro­por­tio­na­li­ty is mea­su­red against this pur­po­se, becau­se pro­ces­sing that is sui­ta­ble and necessa­ry for the pur­po­se of the pro­ces­sing is pro­por­tio­na­te in the broa­der sen­se. The pur­po­se limi­ta­ti­on also refers – obvious­ly – to the purpose.

The respon­si­ble par­ty is free to set this pur­po­se wit­hin the frame­work of the broa­der legal system. He is not limi­ted in this by the FADP – the eco­no­mic free­dom app­lies, sub­ject to the vio­la­ti­on of a beha­vio­ral norm, e.g. from cri­mi­nal law (the FDPIC some­ti­mes for­gets this when he is of the opi­ni­on that a data pro­ces­sing should not be – then he sum­ma­ri­ly calls it dis­pro­por­tio­na­te, without taking into account that the con­trol­ler may have set the pur­po­se broadly).

The con­trol­ler the­re­fo­re sets the pur­po­se, and does so through trans­pa­ren­cy: the pro­ces­sing pur­po­se is the pur­po­se that the con­trol­ler com­mu­ni­ca­tes or that is obvious (i.e., reco­gniz­ab­le from the cir­cum­stan­ces). The bot­tom line, then, is that the con­trol­ler sets the pur­po­se, must abi­de by it, and may pro­cess data only as necessa­ry for the pur­po­se. This in its­elf is the core of sub­stan­ti­ve data pro­tec­tion law.

If one wis­hes, fur­ther rules can be seen as pro­ces­sing princi­ples, such as the pro­hi­bi­ti­on on dis­clo­sing per­so­nal data requi­ring spe­cial pro­tec­tion and, today, per­so­na­li­ty pro­files to third par­ties or the pro­hi­bi­ti­on on pro­ces­sing per­so­nal data against the expres­sed will of the per­son con­cer­ned. The fun­da­men­tal free­dom to pro­cess published data can also be descri­bed as a pro­ces­sing principle.

Trans­pa­ren­cy ulti­mate­ly means that the data sub­ject at least has the pos­si­bi­li­ty to know a data pro­ces­sing and its pur­po­se. This may requi­re infor­ma­ti­on, but it is suf­fi­ci­ent if the pro­ces­sing is evi­dent from the cir­cum­stan­ces, i.e. obvious. Sur­pri­sin­gly, the revi­sed FADP no lon­ger expli­ci­tly men­ti­ons this princip­le, but it still applies.

Howe­ver, what must be trans­pa­rent in con­cre­te terms, i.e. which cir­cum­stan­ces of pro­ces­sing – e.g. also dis­clo­sure to third par­ties – is open; this can only be ans­we­red in indi­vi­du­al cases. Trans­pa­ren­cy can then be sup­ple­men­ted by a sepa­ra­te duty to pro­vi­de infor­ma­ti­on (see there).

Pur­po­se limi­ta­ti­on is in its­elf an out­gro­wth of the trans­pa­ren­cy princip­le. It requi­res that data be pro­ces­sed only as necessa­ry for the (trans­pa­rent) pur­po­se. Misap­pro­pria­ti­on is the­re­fo­re pro­hi­bi­ted, at least without the new pur­po­se being trans­pa­rent in its turn and in time. Howe­ver, the­re are sub­or­di­na­te secon­da­ry pur­po­ses that do not yet meet the thres­hold of misap­pro­pria­ti­on. The revi­sed DPA cla­ri­fies this by sta­ting pur­po­ses that are com­pa­ti­ble with the ori­gi­nal pur­po­se in addi­ti­on to the ori­gi­nal purpose.

The FADP, like the revDSG, does not reco­gni­ze any fun­da­men­tal pro­hi­bi­ti­on of data pro­ces­sing, unli­ke the GDPR. The­re­fo­re, data pro­ces­sing does not have to be justi­fied in princip­le. This also app­lies to the pro­ces­sing of per­so­nal data requi­ring spe­cial pro­tec­tion, today to the pro­ces­sing of per­so­na­li­ty pro­files and, accord­ing to the revDSG, to pro­filing, even high-risk pro­filing. It is the­re­fo­re wrong for the FDPIC to want to per­mit pro­ces­sing of par­ti­cu­lar­ly sen­si­ti­ve per­so­nal data only with con­sent. Howe­ver, if a pro­ces­sing princip­le is vio­la­ted, the cor­re­spon­ding pro­ces­sing is only per­mit­ted if this vio­la­ti­on is justified.

One does not have to and can­not justi­fy a pro­ces­sing, but only a vio­la­ti­on of a pro­ces­sing princip­le. The FADP, as well as the revi­sed FADP, pro­vi­des for three grounds for justification: 

  • Con­sent: Data sub­jects can con­sent to pro­ces­sing con­tra­ry to a princip­le. Howe­ver, con­sent is only effec­ti­ve if the data sub­ject is suf­fi­ci­ent­ly infor­med and if his con­sent was given volun­ta­ri­ly. This rai­ses the que­sti­on under which cir­cum­stan­ces con­sent is volun­ta­ry if it has been made a con­di­ti­on of, for examp­le, the con­clu­si­on of a con­tract (“pro­hi­bi­ti­on of tying”).
  • Law: Pro­ces­sing that the law spe­ci­fies or exempts is also per­mit­ted under data pro­tec­tion law. 
  • Over­ri­ding inte­rests: If the inte­rests in the pro­ces­sing in que­sti­on out­weigh the con­flic­ting inte­rests of the data sub­ject, the cor­re­spon­ding pro­ces­sing is per­mit­ted. In each case, all inte­rests in pro­ces­sing must be taken into account, inclu­ding com­mer­cial inte­rests and tho­se of the data sub­ject. The­se may also be public interests.

In its­elf, not­hing new. The princip­le of pri­va­cy by design only means that com­pli­an­ce with data pro­tec­tion law must be ensu­red proac­tively, i.e., alrea­dy when pro­ces­sing is plan­ned. As a result, an app­li­ca­ti­on must be able, for examp­le, to dele­te data or assign access rights on a role-based basis. 

The GDPR and the revDSG now expli­ci­tly pro­vi­de for this princip­le. Under the revDSG, howe­ver, it has only one effect: if a con­trol­ler vio­la­tes data pro­tec­tion law, it can­not justi­fy this with cons­traints (e.g., the exces­si­ve effort requi­red to rewri­te an app­li­ca­ti­on to make it del­eta­ble), pro­vi­ded it could have coun­te­red this cons­traint with time­ly plan­ning. After all, a tran­si­tio­nal regu­la­ti­on app­lies to exi­sting pro­ces­sing under cer­tain conditions.

Orga­niz­a­ti­on of data protection

The term gover­nan­ce or data gover­nan­ce is not uni­ver­sal­ly defi­ned. It can be under­s­tood as a con­cept of data manage­ment by which a com­pa­ny tries not to let data out of its con­trol during its enti­re lifecycle.

Howe­ver, we under­stand them here as the tota­li­ty of rules that are not direct­ly aimed at com­pli­an­ce with sub­stan­ti­ve data pro­tec­tion law, but rather con­cern the orga­niz­a­tio­nal and pro­ce­du­ral obli­ga­ti­ons of the con­trol­ler and, in some cases, the order processor.

This is whe­re the DPA or the revi­sed DPA and the GDPR dif­fer. Howe­ver, both pro­vi­de for cer­tain obli­ga­ti­ons of the con­trol­ler and, in part, of the order pro­ces­sor, which have the goal of ensu­ring com­pli­an­ce with data pro­tec­tion law at an orga­niz­a­tio­nal level. The­se inclu­de the fol­lo­wing obligations: 

  • Orga­niz­a­tio­nal obli­ga­ti­ons, alt­hough the GDPR is stric­ter here as well. Under cer­tain cir­cum­stan­ces, data con­trol­lers or order pro­ces­sors must appoint a data pro­tec­tion offi­cer (DPO). The revDSG pro­vi­des for an inde­pen­dent “data pro­tec­tion advi­sor”, who­se appoint­ment, howe­ver, remains in voluntary.
  • docu­men­ta­ti­on obli­ga­ti­ons, wher­eby the GDPR is much stric­ter here than the revDSG. The draft regu­la­ti­on pro­vi­des for fur­ther cor­re­spon­ding obli­ga­ti­ons, but without a legal basis. Howe­ver, under both the revDSG and the GDPR, data con­trol­lers and order pro­ces­sors must main­tain a pro­ces­sing directory.
  • Pro­ce­du­ral obli­ga­ti­ons – here, too, the GDPR is stric­ter. It indi­rect­ly requi­res that the con­trol­ler and the order pro­ces­sor issue inst­ruc­tions on how to hand­le per­so­nal data. This also makes sen­se under the revDSG, but is not a sepa­ra­te obli­ga­ti­on. Howe­ver, under both the GDPR and the revDSG, the­re is an obli­ga­ti­on to con­duct a data pro­tec­tion impact assess­ment for pro­ces­sing ope­ra­ti­ons that are likely to be par­ti­cu­lar­ly ris­ky, i.e., a struc­tu­red and docu­men­ted assess­ment of the risks for data sub­jects. The­re is also an obli­ga­ti­on to noti­fy the com­pe­tent aut­ho­ri­ty or the data sub­ject of cer­tain data secu­ri­ty breaches.

The GDPR pro­vi­des for the role of the “data pro­tec­tion offi­cer” (often abbre­via­ted as DPO after the Eng­lish “data pro­tec­tion offi­cer”) to moni­tor com­pli­an­ce with the GDPR and to sup­port the con­trol­ler or pro­ces­sor. The revDSG takes up this idea and reco­gni­zes the “data pro­tec­tion advi­sor” (DPO). 

DPOs and DPOs are inten­ded to be inde­pen­dent enti­ties wit­hin the orga­niz­a­ti­on of the Com­pa­ny. As employees, they are sub­ject to the inst­ruc­tions of the com­pa­ny, but not with regard to their func­tion as DPO and DPO. The com­pa­ny may the­re­fo­re not dic­ta­te to them which pro­ces­sing ope­ra­ti­ons they review or how they assess com­pli­an­ce with data pro­tec­tion law. 

To ensu­re that their inde­pen­dence is not com­pro­mi­sed, they must not have roles or tasks whe­re they them­sel­ves would deci­de on data pro­ces­sing. They may the­re­fo­re be based in Legal Ser­vices or Com­pli­an­ce, or form a sepa­ra­te unit, or even work in IT, but not as heads of such func­tions, inclu­ding as heads of Marketing. 

In addi­ti­on, the DPO and DPO are con­ta­ct per­sons for data sub­jects and aut­ho­ri­ties. Their con­ta­ct details must the­re­fo­re be published, e.g. in a pri­va­cy statement.

The GDPR pro­vi­des that a DPO must be appoin­ted under cer­tain cir­cum­stan­ces. This app­lies to pri­va­te com­pa­nies in the fol­lo­wing cases:

  • the core acti­vi­ty con­sists of pro­ces­sing ope­ra­ti­ons that requi­re exten­si­ve regu­lar and syste­ma­tic moni­to­ring of data sub­jects, or
  • the core acti­vi­ty con­sists of exten­si­ve pro­ces­sing of per­so­nal data requi­ring spe­cial pro­tec­tion or data on cri­mi­nal con­vic­tions and cri­mi­nal offen­ses. Howe­ver, the pro­ces­sing of employee data is not sufficient.

Mem­ber Sta­tes some­ti­mes pro­vi­de for stric­ter requi­re­ments, e.g. Germany. 

Com­pa­nies can also appoint a DPO volun­ta­ri­ly. In this case, howe­ver, they must com­ply with all the requi­re­ments for the DPO.

The revDSG does not requi­re the appoint­ment of a DPO – it is always volun­ta­ry. Whoever appoints a DPO, howe­ver, has cer­tain – prac­ti­cal­ly litt­le rele­vant – faci­li­ta­ti­ons in data pro­tec­tion impact assess­ments. Howe­ver, a volun­ta­ry appoint­ment may be expec­ted by custo­mers, data sub­jects or super­vi­so­ry authorities.

A machi­ning direc­to­ry is an inven­to­ry of the various machi­ning activities.

Con­trol­lers must record their pro­ces­sing acti­vi­ties in accordance with the revDSG as well as the DSGVO, in each case indicating

  • the iden­ti­ty of the per­son or per­sons responsible
  • only accord­ing to the GDPR: of the EU repre­sen­ta­ti­ve and the DPO, if any
  • the pro­ces­sing purposes
  • the cate­go­ries of per­sons concerned
  • the cate­go­ries of per­so­nal data processed
  • the cate­go­ries of recipients
  • if pos­si­ble, the reten­ti­on peri­od or the cor­re­spon­ding criteria
  • if pos­si­ble, the app­li­ca­ble safe­ty mea­su­res (TOMs)
  • in the case of a for­eign dis­clo­sure of the sta­tes (revDSG: all; DSGVO: only sta­tes out­side the EEA and, if app­li­ca­ble, the app­li­ca­ble safe­guards to secu­re the for­eign trans­fer (CH: all; DSGVO only in a spe­ci­fic case).

Order pro­ces­sors must also main­tain a pro­ces­sing direc­to­ry, but with fewer con­tent requirements.

Pro­ces­sing direc­to­ries must be kept up to date, which usual­ly requi­res inter­nal spe­ci­fi­ca­ti­ons or processes.

Every respon­si­ble per­son and every order pro­ces­sor must keep a pro­ces­sing directory.

Howe­ver, the­re is the “SME excep­ti­on”. The revDSG requi­res the Federal Coun­cil to crea­te an excep­ti­on for com­pa­nies with fewer than 250 employees, sub­ject to high risk. The draft VDSG the­re­fo­re pro­vi­des that data con­trol­lers and order pro­ces­sors do not have to keep a pro­ces­sing direc­to­ry, pro­vi­ded that 

  • they employ fewer than 250 employees at the begin­ning of a year, and
  • per­so­nal data requi­ring spe­cial pro­tec­tion is not exten­si­ve­ly pro­ces­sed, and
  • no high-risk pro­filing is performed. 

In the case of the­se risks, the cor­re­spon­ding pro­ces­sing ope­ra­ti­ons – but only the­se – must be recor­ded in a directory.

Data pro­tec­tion law gene­ral­ly fol­lows a risk-based approach. This means that the con­trol­ler and the order pro­ces­sor must align their mea­su­res for com­pli­an­ce with data pro­tec­tion law with the risks for the data sub­jects – the hig­her the­se risks, the hig­her the requi­re­ments for the pro­tec­tion of the data sub­jects, e.g., through stron­ger secu­ri­ty measures. 

More gene­ral­ly, this requi­res com­pa­nies to assess the risks of their data pro­ces­sing ope­ra­ti­ons, and they must proac­tively ensu­re com­pli­an­ce with data pro­tec­tion law (this is what the princip­le of “pri­va­cy by design” means). 

If they deter­mi­ne that cer­tain data pro­ces­sing ope­ra­ti­ons are likely to be par­ti­cu­lar­ly ris­ky, they must con­duct a data pro­tec­tion impact assess­ment (DPIA). This app­lies under the revDSG as well as under the GDPR. 

A DSFA is the­re­fo­re not­hing more than this – a risk assess­ment. The risks must be asses­sed as they pre­sent them­sel­ves ex ante, the so-cal­led gross risks. Risk-redu­cing mea­su­res must then be taken into account, and in the end the remai­ning risk, the net risk. All of this must be docu­men­ted, and if a DPO or data pro­tec­tion advi­sor has been appoin­ted, they must be involved. 

If, excep­tio­nal­ly, it beco­mes appa­rent that the net risks are still high, this must be repor­ted to the com­pe­tent data pro­tec­tion aut­ho­ri­ty. In Switz­er­land, this is the FDPIC. Howe­ver, such a noti­fi­ca­ti­on obli­ga­ti­on does not app­ly if an inde­pen­dent data pro­tec­tion advi­sor has been appoin­ted and was invol­ved in the DSFA.

Infor­ma­ti­on

Not necessa­ri­ly accord­ing to the cur­rent DPA. At pre­sent, infor­ma­ti­on is only requi­red if pro­ces­sing is not self-evi­dent or if par­ti­cu­lar­ly sen­si­ti­ve per­so­nal data or per­so­na­li­ty pro­files are obtai­ned (and of cour­se if a spe­cial legal regu­la­ti­on such as Art. 3 VVG requi­res infor­ma­ti­on about data processing). 

Accord­ing to the revDSG and the DSGVO, this is dif­fe­rent. Here, the­re is basi­cal­ly a duty to inform about all data pro­ces­sing, unless an excep­ti­on is applicable.

The­re are excep­ti­ons to the gene­ral duty to inform. The fol­lo­wing excep­ti­ons are rele­vant, accord­ing to the revDSG:

  • inso­far as the data sub­ject has alrea­dy been suf­fi­ci­ent­ly infor­med (e.g. by someo­ne else),
  • inso­far as pro­ces­sing is requi­red by law (e.g. in the case of obli­ga­ti­ons under the Anti-Money Laun­de­ring Act or the obli­ga­ti­on to pro­cess cer­tain per­so­nal data in the employ­ment rela­ti­ons­hip). Even federal bodies are the­re­fo­re usual­ly not requi­red to inform, but often do so anyway,
  • inso­far as the infor­ma­ti­on is not pos­si­ble or would be dis­pro­por­tio­na­te­ly costly, 
  • inso­far as over­ri­ding inte­rests of third par­ties con­flict with the pro­vi­si­on of information,
  • inso­far as and as long as the infor­ma­ti­on would fru­stra­te the pur­po­se of the pro­ces­sing, e.g. in the case of inter­nal investigations, 
  • to the extent requi­red by the over­ri­ding inte­rests of a com­pa­ny, but only if per­so­nal data is not dis­c­lo­sed to third par­ties out­side the Group,
  • in the case of federal bodies, if the infor­ma­ti­on con­flicts with over­ri­ding public inte­rests or if the infor­ma­ti­on would jeo­par­di­ze an inve­sti­ga­ti­on, inqui­ry or proceedings.

The GDPR lar­ge­ly lea­ves the regu­la­ti­on of excep­ti­ons to the Mem­ber Sta­tes, which is why the app­li­ca­ble local law must be consulted.

The revDSG requi­res infor­ma­ti­on on the following: 

  • Name and con­ta­ct details of the per­son respon­si­ble for the pro­ces­sing in question
  • if a data pro­tec­tion advi­sor has been appoin­ted: his con­ta­ct details
  • the pur­po­ses of the data processing
  • if the data do not ori­gi­na­te from the data sub­ject but from someo­ne else: the natu­re of the data processed
  • if data are trans­fer­red: the­se reci­pi­ents or the cate­go­ries of reci­pi­ents (also wit­hin the group and also in the case of trans­fer to order processors)
  • if data is trans­fer­red abroad (also via (sub)contractors: the coun­tries or regi­ons con­cer­ned, and, if app­li­ca­ble, the con­clu­si­on of SCCs or the app­li­ca­ti­on of an excep­ti­on to the pro­hi­bi­ti­on of dis­clo­sure in coun­tries without ade­qua­te protection

The GDPR is some­what stric­ter – addi­tio­nal infor­ma­ti­on must be pro­vi­ded on the fol­lo­wing points: 

  • if a DPO has been appoin­ted: his con­ta­ct details
  • if an EU repre­sen­ta­ti­ve has been appoin­ted: his con­ta­ct details
  • the legal basis of the pro­ces­sing (e.g. the legi­ti­ma­te inte­rests pur­sued thereby)
  • the dura­ti­on of the sto­rage or pro­ces­sing or the cri­te­ria for deter­mi­ning the duration
  • whe­ther the data sub­ject has a duty to dis­c­lo­se his or her data
  • Rights of the data sub­jects: Infor­ma­ti­on, cor­rec­tion or dele­ti­on, restric­tion, objec­tion, data por­ta­bi­li­ty, revo­ca­ti­on of con­sent, com­p­laint to an authority.

Accord­ing to the GDPR, not all coun­tries have to be named for this, but only coun­tries out­side the EEA.

Addi­tio­nal infor­ma­ti­on requi­re­ments may app­ly depen­ding on the circumstances: 

  • Accord­ing to the princip­le of trans­pa­ren­cy, ever­ything that the per­son con­cer­ned real­ly needs to know, i.e. what would be sur­pri­sing but rele­vant, and 
  • in the case of an auto­ma­ted indi­vi­du­al deci­si­on, fur­ther infor­ma­ti­on, but not necessa­ri­ly in a pri­va­cy state­ment, but when the deci­si­on in que­sti­on is made.

Data pro­tec­tion law does not spe­ci­fy exact­ly how infor­ma­ti­on must be pro­vi­ded. Data pro­tec­tion decla­ra­ti­ons are com­mon, but infor­ma­ti­on can also be inclu­ded in GTCs, pro­vi­ded it is clear what is part of the con­tract and what is (data pro­tec­tion) infor­ma­ti­on, even if this is often not sensible.

One can also inform in the con­text of a con­sent form, or by a noti­ce on a web­site that collects data, or by a sepa­ra­te let­ter, etc. It is also pos­si­ble to pro­vi­de infor­ma­ti­on ver­bal­ly, e.g. in a tele­pho­ne announcement.

The only decisi­ve fac­tor is that the per­son con­cer­ned must be able to take note of and under­stand the infor­ma­ti­on in good time.

It is also pos­si­ble to get infor­ma­ti­on from someo­ne else. This is often necessa­ry. For examp­le, if a bank custo­mer dis­c­lo­ses infor­ma­ti­on about an aut­ho­ri­zed repre­sen­ta­ti­ve or a bene­fi­cial owner of assets, often only he or she – and not the bank – can inform. In this case, the bank can agree with the custo­mer that the lat­ter informs the other per­sons. In fact, the custo­mer must do so, becau­se he or she is also respon­si­ble for dis­clo­sing this data to the bank.

It depends on the busi­ness and espe­cial­ly on the inter­ac­tion with data sub­jects. Com­pa­nies usual­ly try not to have too many pri­va­cy state­ments becau­se they all need to be mana­ged and updated. The fol­lo­wing is common: 

  • A gene­ral pri­va­cy state­ment that covers as many of the pro­ces­sing ope­ra­ti­ons as pos­si­ble (as long as it remains com­pre­hen­si­ble), e.g., hand­ling end-custo­mer data, custo­mer and sup­plier con­ta­ct data, mar­ke­ting, and ancil­la­ry pur­po­ses such as sta­tis­tics, admi­ni­stra­ti­on, com­pli­an­ce, law enfor­ce­ment, cor­po­ra­te tran­sac­tions, etc.
  • A pri­va­cy poli­cy for coo­kies and gene­ral­ly the hand­ling of data via web­sites and apps 
  • a pri­va­cy poli­cy for its own employees
  • a pri­va­cy poli­cy for applicants

In addi­ti­on, fur­ther pri­va­cy state­ments may be use­ful, depen­ding on the case, espe­cial­ly if cer­tain pro­ces­sing is not without sen­si­ti­vi­ty, but only affects a smal­ler, deli­mi­ted group of peop­le. Here, the rele­vant infor­ma­ti­on is often bet­ter cove­r­ed in a spe­cia­li­zed, smal­ler pri­va­cy state­ment ins­tead of an exten­si­ve gene­ral pri­va­cy statement.

No. A pri­va­cy poli­cy is not part of the con­tract, but infor­ma­ti­on. Con­sent to the data pro­tec­tion decla­ra­ti­on is not necessa­ry and should also be avoided. Other­wi­se, the­re is a risk that the data pro­ces­sing is based on con­sent – if it is revo­ked, the cor­re­spon­ding pro­ces­sing could the­re­fo­re beco­me inadmissible. 

It is also not man­da­to­ry that the data sub­ject con­firms having read the pri­va­cy state­ment. It is suf­fi­ci­ent if the data con­trol­ler can pro­ve that the data sub­ject was able to take note of the pri­va­cy poli­cy in a rea­son­ab­le manner.

This has not been ful­ly cla­ri­fied. In Switz­er­land, the gene­ral prac­ti­ce is that infor­ma­ti­on can be pro­vi­ded on the Inter­net becau­se the per­son con­cer­ned can rea­son­ab­ly be expec­ted to visit an Inter­net site. Final­ly, federal laws are also bin­ding in the ver­si­on published on the Inter­net – so even the legis­la­tor assu­mes that the Inter­net will be used. The fact that this does not app­ly to ever­yo­ne is clear, but not a coun­ter­ar­gu­ment; the­re are always groups of peop­le who can­not use a cer­tain for­mat (e.g. the visual­ly impaired). 

Howe­ver, this is only pos­si­ble if it is or should be clear to the per­sons con­cer­ned, that a con­trol­ler pro­ces­ses per­so­nal data from them, e.g. becau­se they have a con­tract with the con­trol­ler – other­wi­se they do not know that they can con­sult infor­ma­ti­on on data pro­tec­tion on the controller’s web­site. In the case of unre­co­gniz­ab­le pro­ces­sing, the loca­ti­on of the pri­va­cy statement(s) should the­re­fo­re be actively indi­ca­ted, e.g., on the Inter­net (e.g., on a noti­ce, in an e‑mail signa­tu­re, in an invoice, etc.). 

In Switz­er­land, it is gene­ral­ly assu­med that a simp­le refe­rence to the pri­va­cy poli­cy is suf­fi­ci­ent, with an indi­ca­ti­on of the link. A QR code or cer­tain mini­mum pro­ces­sing details are not requi­red. It is suf­fi­ci­ent, for examp­le, to sta­te “Infor­ma­ti­on about our hand­ling of per­so­nal data can be found at www.xyz.ch”. 

With the GDPR, the prac­ti­ce is stric­ter. Here, at least cer­tain basic infor­ma­ti­on is requi­red whe­re refe­rence is made to the pri­va­cy poli­cy on the Internet.

Yes, for examp­le here: 

The­re are also nume­rous pri­va­cy state­ment gene­ra­tors avail­ab­le on the Inter­net, some with good qua­li­ty. Note the licen­se infor­ma­ti­on that may be pro­vi­ded, which does not necessa­ri­ly look par­ti­cu­lar­ly professional. 

Pat­terns and tem­pla­tes are also avail­ab­le from us.

Rights of data subjects

Data pro­tec­tion law requi­res the data con­trol­ler to com­ply with various obli­ga­ti­ons. Nevertheless, it assu­mes that data sub­jects have a gre­at deal of respon­si­bi­li­ty in the pro­ces­sing of their data. To this end, data pro­tec­tion law pro­vi­des them with a num­ber of instru­ments with which they can influ­ence this pro­ces­sing – the­se are the data sub­ject rights.

Data sub­jects first have the right to be infor­med about the pro­ces­sing of their data, becau­se if they do not know about this pro­ces­sing, they can­not exer­cise any other rights. 

The most important right of data sub­jects, apart from the right to infor­ma­ti­on, is the right of access. This allo­ws them to requ­est fur­ther infor­ma­ti­on from the data con­trol­ler about the pro­ces­sing of their data. Under the revDSG and DSGVO, they can also requ­est a machi­ne-read­a­ble copy of cer­tain data – the idea is that this will make it easier for them to switch bet­ween pro­vi­ders, even though this is unli­kely to pro­ve effective.

Sub­se­quent­ly, the data sub­jects can influ­ence this pro­ces­sing. They can object to it in part or in full (alt­hough the revDSG and the GDPR dif­fer great­ly here), and they can also demand that inac­cu­ra­te data be corrected. 

Final­ly, they can revo­ke cons­ents, and they can com­p­lain to the com­pe­tent authority. 

Accord­ing to the GDPR, data sub­jects must be infor­med about the­se rights. Accord­ing to the revDSG, this is not man­da­to­ry, but it is common.

[…]

Order pro­ces­sing

You will find a note on this under “Terms”.

It depends: 

  • As a rule, the exter­nal ser­vice com­pa­ny is an order pro­ces­sor if data pro­ces­sing is the sub­ject of the agreed ser­vices, e.g. in the case of a SaaS provider. 
  • If data does not lea­ve the sphe­re of con­trol of the data con­trol­ler, not even through exter­nal data access rights, but can only be view­ed or pro­ces­sed by employees of the ser­vice pro­vi­der on the infra­st­ruc­tu­re of the data con­trol­ler and under the latter’s con­trol and aut­ho­ri­ty, the ser­vice pro­vi­der is not a con­tract pro­ces­sor, and neit­her are the employees con­cer­ned. In terms of labor and social secu­ri­ty law, they are gene­ral­ly not employees of the con­trol­ler. But under data pro­tec­tion law, they are to be trea­ted as employees becau­se they are sub­or­di­na­ted in the same way as employees. The­re­fo­re, no order pro­ces­sing agree­ment is requi­red here. Howe­ver, a con­trac­tu­al arran­ge­ment with the ser­vice pro­vi­der and cer­tain obli­ga­ti­ons on the part of the employees used are still necessary.

Yes and no. The revDSG as well as the GDPR (and the cur­rent GDPR) pri­vi­le­ge order pro­ces­sing, but in dif­fe­rent respects. The GDPR requi­res a legal basis for any pro­ces­sing becau­se any pro­ces­sing is gene­ral­ly pro­hi­bi­ted. “Pri­vi­le­ging” in this con­text means, abo­ve all, that dis­clo­sure to the order pro­ces­sor does not requi­re a sepa­ra­te legal basis. This is dif­fe­rent under the DPA and the revDSG – pro­ces­sing is per­mit­ted pro­vi­ded it com­plies with the pro­ces­sing princi­ples. In this respect, the pri­vi­le­ge is less important. In the case of par­ti­cu­lar­ly sen­si­ti­ve per­so­nal data, howe­ver, it means that dis­clo­sure to the pro­ces­sor is per­mis­si­ble without a justification.

This pri­vi­le­ge fol­lows from the fact that the order pro­ces­sor is, to a cer­tain extent, the exten­ded arm of the con­trol­ler and is coun­ted as part of his sphe­re under data pro­tec­tion law. Howe­ver, this requi­res that the con­trol­ler and the pro­ces­sor con­clu­de a con­tract that meets cer­tain requirements.

Yes. The cur­rent DPA alrea­dy pro­vi­des for out­sour­cing data pro­ces­sing to con­tract pro­ces­sors only if the con­trol­ler ensu­res that the data is not pro­ces­sed by the con­tract pro­ces­sor in any other way than the cli­ent would be per­mit­ted to do, and that data secu­ri­ty remains gua­ran­te­ed. This requi­res a cor­re­spon­ding agree­ment. It is usual­ly cal­led an “order pro­ces­sing agree­ment” or “ADV” or “AVV” or “Data Pro­ces­sing Agree­ment” or “DPA”.

The revi­sed DPA also requi­res such an agree­ment, wher­eby it addi­tio­nal­ly requi­res that the invol­ve­ment of a sub­con­trac­ted pro­ces­sor is only per­mit­ted with the con­sent of the con­trol­ler. The GDPR fol­lows the same con­cept, but impo­ses much more exten­si­ve and detail­ed requi­re­ments on the con­tent of sub­con­trac­ting agree­ments. For this pur­po­se, the­re are e.g. here and here Notes.

Yes, various tem­pla­tes can be found on the Inter­net. Howe­ver, they are usual­ly tailo­red to the GDPR. Such tem­pla­tes can also be used for Switz­er­land, but they requi­re at least cer­tain adap­t­ati­ons. For less sen­si­ti­ve pro­ces­sing that is not sub­ject to the GDPR, high­ly sim­pli­fied vari­ants can be used. 

As a rule, we work with tem­pla­tes that first requ­est all the infor­ma­ti­on requi­red to spe­ci­fy the ADV (which cate­go­ries of data and data sub­jects, sub­ject of the pro­ces­sing, etc.) and, if necessa­ry, also the spe­ci­fi­ca­ti­ons of the SCC. The actu­al pro­vi­si­ons are then recor­ded – this makes it easier to use in indi­vi­du­al cases.

Order pro­ces­sors often have an inte­rest in using cer­tain data from their custo­mers, the data con­trol­lers, for their own pur­po­ses – for examp­le, becau­se they are using a form of machi­ne lear­ning and want to use order data as trai­ning data, or becau­se they want to store order data for their own reten­ti­on pur­po­ses (even though reten­ti­on rules will rare­ly app­ly to order data).

It is not uncom­mon to allow con­tract pro­ces­sors to do some pro­ces­sing for their own pur­po­ses, often without a more detail­ed legal ana­ly­sis. Strict­ly spea­king, howe­ver, some que­sti­ons ari­se. The order pro­ces­sor is a con­trol­ler in such a con­stel­la­ti­on. To the appro­pria­te extent, the­re­fo­re, the pri­vi­le­ge does not app­ly, and dis­clo­sure to the order pro­ces­sor as a con­trol­ler may be sub­ject to trans­pa­ren­cy requi­re­ments, as the case may be. If the GDPR app­lies, this dis­clo­sure also requi­res a legal basis, which must be checked and also sta­ted in a data pro­tec­tion decla­ra­ti­on. Fur­ther pro­ces­sing by the order pro­ces­sor – now as the con­trol­ler – also requi­res a legal basis and infor­ma­ti­on that the order pro­ces­sor must take care of, which can be deman­ding in prac­ti­cal implementation.

In con­trast, the­re is no use of order data if the order pro­ces­sor uses data about con­ta­ct per­sons of the respon­si­ble par­ty for its own con­tract manage­ment, CRM or invoi­cing. Here, the respon­si­ble par­ty is a data con­trol­ler. One can the­re­fo­re ask whe­ther the stan­dard con­trac­tu­al clau­ses for data con­trol­lers (i.e., Modu­le 1 today) should not always be used for a data pro­ces­sor in a coun­try without an ade­qua­te level of pro­tec­tion, alt­hough this is rare­ly imple­men­ted in practice. 

Dis­clo­sure abroad

A dis­clo­sure abroad is initi­al­ly a dis­clo­sure. This pre­sup­po­ses that a per­son or body gains access to or know­ledge of per­so­nal data. The­re­fo­re, dis­clo­sure is not 

  • a trip by a per­son to a for­eign coun­try, even if he or she car­ri­es per­so­nal data with him or her or can access per­so­nal data from abroad, if he or she alrea­dy had access to it pri­or to the start of the trip; 
  • the use of a data cen­ter abroad, which belongs to the com­pa­ny domestically;
  • dis­clo­sure wit­hin a legal enti­ty, e.g. bet­ween the head office to a branch office – this is the View of the Euro­pean Data Pro­tec­tion Board.

In this case, howe­ver, cer­tain pro­tec­ti­ve mea­su­res must be taken. If data is pro­tec­ted by secrecy, the­se mea­su­res may even be mandatory.

This dis­clo­sure must be made abroad, i.e. the per­son gai­ning know­ledge of data or access must be loca­ted abroad. 

Data pro­tec­tion law aims to ensu­re a cer­tain level of pro­tec­tion for data sub­jects. It can­not the­re­fo­re per­mit the dis­clo­sure of per­so­nal data to other coun­tries without restric­tion. In princip­le, data pro­tec­tion law – the FADP as well as the GDPR – the­re­fo­re pro­hi­bits dis­clo­sure abroad unless the­re is at least an ade­qua­te level of pro­tec­tion in the coun­try concerned.

Under the cur­rent FADP, the FDPIC has the task of main­tai­ning a list of coun­tries that are pre­su­med to have an ade­qua­te level of pro­tec­tion (cf. at the FDPIC). Cur­r­ent­ly (23.07.2022) the fol­lo­wing sta­tes are listed: 

  • all EEA sta­tes, i.e. the EU mem­ber sta­tes and Ice­land, Nor­way and the Princi­pa­li­ty of Liech­ten­stein (in each case, the GDPR app­lies primarily);
  • Andor­ra
  • Argen­ti­na
  • Faroe Islands
  • Guern­sey
  • Isle of Man
  • Isra­el
  • Jer­sey
  • Cana­da (with restrictions)
  • Mona­co
  • New Zea­land
  • Uru­gu­ay
  • United King­dom (no lon­ger an EEA sta­te sin­ce Brexit)

Howe­ver, in the opi­ni­on of the FDPIC, this does not app­ly without restric­tion: Unli­ke the cur­rent DPA, Ger­man data pro­tec­tion law does not pro­tect legal enti­ties as data sub­jects. In this respect, the­re is a dis­pa­ri­ty with Swiss law, which is why the (FDPIC) assu­mes the absence of ade­qua­te data pro­tec­tion with regard to data of legal enti­ties. From this per­spec­ti­ve, even a trans­fer to Ger­ma­ny would only be per­mis­si­ble with the con­clu­si­on of the – appro­pria­te­ly adap­ted – stan­dard con­trac­tu­al clau­ses. This view is poor­ly sup­por­ted by the law, and in our obser­va­ti­on it is hard­ly lived in practice.

Under the revi­sed VDSG, the Federal Coun­cil will main­tain the list of sta­tes with ade­quacy as an annex to the revi­sed VDSG. 

Yes, under cer­tain circumstances.

On the one hand, the­re are legal excep­ti­ons to the pro­hi­bi­ti­on of data dis­clo­sure in coun­tries without an ade­qua­te level of protection: 

  • the data sub­ject has con­sen­ted in the indi­vi­du­al case (accord­ing to the revDSG: explicitly)
  • the pro­ces­sing is direct­ly rela­ted to the con­clu­si­on or exe­cu­ti­on of a con­tract and it con­cerns per­so­nal data of the con­trac­ting party;
  • the dis­clo­sure is indis­pensable in indi­vi­du­al cases for the pro­tec­tion of an over­ri­ding public inte­rest or for the estab­lish­ment, exer­cise or enfor­ce­ment of legal claims befo­re a court (accord­ing to the revDSG: or befo­re an authority);
  • dis­clo­sure is necessa­ry in an indi­vi­du­al case to pro­tect the life or phy­si­cal inte­gri­ty of the data subject;
  • the data sub­ject has made the data gene­ral­ly acces­si­ble and has not express­ly pro­hi­bi­ted processing.

Also per­mis­si­ble is dis­clo­sure based on a con­tract that ensu­res an ade­qua­te level of pro­tec­tion, e.g., the EU stan­dard con­trac­tu­al clauses.

It is also per­mis­si­ble on the basis of so-cal­led Bin­ding Cor­po­ra­te Rules (BCR).

In princip­le, yes – pro­vi­ded that the rele­vant con­tract ensu­res ade­qua­te protection. 

A distinc­tion can be made bet­ween two clas­ses of contracts: 

  • Con­tracts reco­gni­zed by the FDPIC as basi­cal­ly suf­fi­ci­ent, in par­ti­cu­lar the stan­dard con­trac­tu­al clau­ses. Under the cur­rent DPA, the use of such con­tracts must be noti­fied to the FDPIC in gene­ral terms. Under the revDSG, this obli­ga­ti­on does not apply.
  • Trea­ties that the FDPIC has not reco­gni­zed. They can also legi­ti­mi­ze dis­clo­sure to a sta­te without an ade­qua­te level of pro­tec­tion if they pro­vi­de suf­fi­ci­ent pro­tec­tion. Howe­ver, they must be sub­mit­ted to the FDPIC in advance.

The EU Stan­dard Con­trac­tu­al Clau­ses (“SCC”) are a set of con­tracts that set out obli­ga­ti­ons of the dis­clo­sing enti­ty, the exporter, and the recei­ving enti­ty, the importer, as well as rights of data sub­jects (they have par­ti­al third par­ty pro­tec­tion). They are here limi­ted to ger­man and eng­lish to find.

In princip­le, this con­trac­tu­al frame­work can pro­vi­de suf­fi­ci­ent pro­tec­tion and thus legi­ti­mi­ze the dis­clo­sure. The FDPIC has reco­gni­zed this for Switz­er­land. Howe­ver, it requi­res cer­tain adjust­ments. In addi­ti­on, a risk assess­ment must be car­ri­ed out befo­re the use of the stan­dard con­trac­tu­al clau­ses as the basis for dis­clo­sure to a coun­try without an ade­qua­te level of protection.

FAQ about the SCC by David Rosen­thal can be found at Vischer.

No. In princip­le, no. But:

  • It is per­mis­si­ble to tigh­ten them up, i.e. to inclu­de addi­tio­nal pro­vi­si­ons that pro­vi­de grea­ter pro­tec­tion for tho­se affec­ted, even if this is more theoretical. 
  • One may use it as part of a broa­der set of agree­ments, such as an inter­com­pa­ny master data trans­fer agreement. 
  • Man must adapt them in the few places whe­re the SCC them­sel­ves pro­vi­de for adap­t­ati­on or con­cretiz­a­ti­on in indi­vi­du­al cases.
  • Man may adapt them whe­re the SCC pro­vi­de for optio­nal clauses. 
  • Man must com­ple­te them with infor­ma­ti­on in the annexes. 

If the SCC are used for an export from Switz­er­land, the FDPIC requi­res fur­ther adjustments.

The FDPIC has reco­gni­zed the cur­rent SCC, but only on the con­di­ti­on that they are adap­ted to Switz­er­land. Details can be found here.

The ECJ has ruled in the so-cal­led Schrems II judgment ruled, among other things, that the SCCs may in princip­le be suf­fi­ci­ent to pro­vi­de an ade­qua­te level of pro­tec­tion. Howe­ver, this is sub­ject to the pro­vi­so that they are enfor­ce­ab­le and that a legal system does not app­ly in the reci­pi­ent sta­te that per­mits access by aut­ho­ri­ties in vio­la­ti­on of cer­tain fun­da­men­tal rights requi­re­ments (e.g., without suf­fi­ci­ent legal basis, without suf­fi­ci­ent spe­ci­fi­ca­ti­on, or without suf­fi­ci­ent legal protection). 

The par­ties to the announ­ce­ment must the­re­fo­re check whe­ther such a pro­ble­ma­tic legal system app­lies. To do this, they must exami­ne the local legal system. This exami­na­ti­on is usual­ly refer­red to as a “Trans­fer Impact Assess­ment” (TIA).

The TIA may find that dis­clo­sure is per­mis­si­ble based on the SCC, but may also find that addi­tio­nal safe­guards must be pro­vi­ded in addi­ti­on to the SCC.

How to con­duct a TIA and when to take pro­tec­ti­ve mea­su­res is cur­r­ent­ly one of the most dis­cus­sed topics in all of data pro­tec­tion law.

Intra-group data traffic

In princip­le, no. Legal enti­ties wit­hin a group are trea­ted in the same way as unre­la­ted com­pa­nies. Dis­clo­sure bet­ween group com­pa­nies is the­re­fo­re not privileged. 

Howe­ver, cer­tain faci­li­ta­ti­ons do exist: 

  • If per­so­nal data is dis­c­lo­sed to third par­ties – i.e. other respon­si­ble par­ties – the dis­clo­sing com­pa­ny loses the right to invo­ke its own over­ri­ding inte­rests against a requ­est for infor­ma­ti­on. The same app­lies to the cor­re­spon­ding excep­ti­on to the duty to inform. Accord­ing to the revi­sed Data Pro­tec­tion Act, howe­ver, this con­se­quence does not app­ly in each case if the recei­ving respon­si­ble par­ty belongs to the same group as the dis­clo­sing respon­si­ble party. 
  • The risk of intra-group dis­clo­sure may be lower. Accord­in­gly, dis­clo­sure may be more justi­fied (and under the GDPR, the chan­ce of legi­ti­mi­zing dis­clo­sure with a legi­ti­ma­te inte­rest increases). 

Fac­tual­ly, of cour­se, the­re may be fur­ther relief: 

  • With uni­fied manage­ment, data pro­tec­tion law can be imple­men­ted more easi­ly or more effi­ci­ent­ly overall. 
  • Intra-Group frame­work agree­ments faci­li­ta­te disclosure. 
  • A DPO or data pro­tec­tion advi­sor may be desi­gna­ted for several Group com­pa­nies under cer­tain conditions. 

Howe­ver, the­re are also fac­tu­al com­pli­ca­ti­ons and risks:

  • The risk of a lack of demar­ca­ti­on bet­ween the com­pa­nies incre­a­ses, e.g. unno­ti­ced joint respon­si­bi­li­ties, unno­ti­ced com­mis­sio­ned pro­ces­sing or unno­ti­ced trans­fers abroad. 
  • A cor­po­ra­te head­quar­ters can attempt to impo­se the GDPR as a stan­dard on the enti­re group – even for Switz­er­land – in an undif­fe­ren­tia­ted manner.
  • Employees may work for several Group com­pa­nies. This makes it dif­fi­cult to deli­ne­a­te respon­si­bi­li­ties, which can make it con­si­der­ab­ly more dif­fi­cult to respond to a requ­est for infor­ma­ti­on, for example. 
  • Unno­ti­ced labor hire may occur. 
  • It may result in mone­ta­ry bene­fits bet­ween Group com­pa­nies not being off­set cor­rect­ly, which may lead to nega­ti­ve tax consequences.

Sin­ce data pro­tec­tion law lar­ge­ly lacks a cor­po­ra­te group pri­vi­le­ge, cor­po­ra­te groups do not regu­la­te their data flows any dif­fer­ent­ly than unaffi­lia­ted com­pa­nies, e.g., through order pro­ces­sing agree­ments or the con­clu­si­on of the stan­dard con­trac­tu­al clauses. 

Howe­ver, the­se con­tracts can be stan­dar­di­zed, e.g., through a group-wide frame­work agree­ment. The­se con­tracts are often refer­red to as “Intra-Group Data Trans­fer Agree­ment” (“IGDTA”) or – if they are some­what broa­der – as “Intra­group Data Pro­tec­tion Agree­ment (“IDPA”). 

This refers to group-wide frame­work agree­ments regu­la­ting inter­nal data flows. They often regu­la­te the fol­lo­wing points: 

  • Scope of the con­tract, inclu­ding the ent­ry of new Group com­pa­nies or the exit, e.g. in the event of a sale; 
  • gene­ral data pro­tec­tion mea­su­res, e.g. con­fi­dentia­li­ty, com­pli­an­ce with pur­po­se limi­ta­ti­on, ensu­ring an appro­pria­te level of secu­ri­ty, or mutu­al sup­port in the event of requests from data sub­jects and authorities; 
  • Ser­vices pro­vi­ded by a cen­tral unit, e.g. the hol­ding company;
  • Manage­ment of the con­tract by a cen­tral office, inclu­ding joi­ning and lea­ving and con­tract adjustments; 
  • App­li­ca­ti­on of the stan­dard con­trac­tu­al clau­ses in the case of intra-group trans­fers to coun­tries without an ade­qua­te level of protection; 
  • Regu­la­ti­on of con­tract pro­ces­sing by uni­form con­trac­tu­al provisions;
  • Regu­la­te com­mon respon­si­bi­li­ties through uni­form con­tract provisions;
  • the manage­ment of indi­vi­du­al con­trac­tu­al rela­ti­ons­hips (e.g. con­tract pro­ces­sing), for which the model pro­vi­si­ons pro­vi­ded for in the IDPA apply;
  • Appoint­ment of Group com­pa­nies as EU, UK or CH representatives; 
  • addi­tio­nal pro­vi­si­ons requi­red under the indi­vi­du­al natio­nal laws.

As far as we know, not free­ly avail­ab­le on the Inter­net. Howe­ver, we usual­ly work with tem­pla­tes that can be adap­ted to the spe­ci­fic case.

Data secu­ri­ty

Data pro­tec­tion law approa­ches the issue of data secu­ri­ty from dif­fe­rent star­ting points: 

  • In gene­ral, data pro­tec­tion law requi­res both the con­trol­ler and the pro­ces­sor to ensu­re an appro­pria­te level of pro­tec­tion. Com­pa­nies must the­re­fo­re assess the risks for data sub­jects and pro­vi­de for appro­pria­te measures.
  • If necessa­ry, secu­ri­ty mea­su­res must be eva­lua­ted as part of a data pro­tec­tion impact assessment.
  • Ensu­ring data secu­ri­ty is a legi­ti­ma­te pur­po­se that may justi­fy pro­ces­sing of per­so­nal data.
  • A bre­ach of data secu­ri­ty may lead to fur­ther brea­ches (for examp­le, con­sent will only ever legi­ti­mi­ze pro­ces­sing on the tacit con­di­ti­on that data secu­ri­ty is maintained).
  • Respon­si­ble par­ties must agree in their rela­ti­ons­hip with the order pro­ces­sor that the lat­ter will main­tain appro­pria­te pro­tec­ti­ve mea­su­res during order processing.
  • Con­trol­lers must the­re­fo­re check order pro­ces­sors and their secu­ri­ty mea­su­res in advan­ce (“ven­dor assess­ment”). The GDPR also requi­res that such audits be docu­men­ted. The revDSG does not requi­re this, but if audits are car­ri­ed out, this should be docu­men­ted independently. 
  • Data secu­ri­ty brea­ches must – accord­ing to the GDPR – be docu­men­ted, and the revDSG as well as the GDPR requi­re the con­trol­ler to noti­fy brea­ches to the com­pe­tent aut­ho­ri­ty or also affec­ted per­sons under cer­tain circumstances.
  • Order pro­ces­sors must report secu­ri­ty brea­ches to the respon­si­ble party. 
  • Safe­ty mea­su­res must be men­tio­ned or refe­ren­ced in the pro­ces­sing directory. 

Data pro­tec­tion law does not spe­ci­fy the level of pro­tec­tion to be achie­ved. It only sta­tes that this must be appro­pria­te to the risks for the data sub­jects. The cur­rent VDSG and, simi­lar­ly, the draft of the revi­sed VDSG at least spe­ci­fy that the type and cir­cum­stan­ces of the data pro­ces­sing, the risks for data sub­jects, the sta­te of the art and mple­men­ta­ti­on costs must be taken into account. Depen­ding on the indu­stry, howe­ver, spe­cial requi­re­ments may app­ly, and like­wi­se for public bodies.

One can con­creti­ze the requi­re­ments for data secu­ri­ty by asking about spe­ci­fic risks, or more pre­cise­ly, about typi­cal thre­at sce­n­a­ri­os. The secu­ri­ty mea­su­res must coun­ter the­se sce­n­a­ri­os. This in turn results in so-cal­led pro­tec­tion goals. They are not a com­pre­hen­si­ve repre­sen­ta­ti­on of data secu­ri­ty, but as a typi­cal ori­en­ta­ti­on they help in the exami­na­ti­on and eva­lua­ti­on of secu­ri­ty measures. 

The draft of the revi­sed VDSG pro­vi­des for the fol­lo­wing pro­tec­tion goals: 

  • Access con­trol: Con­trol of access rights to data
  • Access con­trol: Con­trol of access to faci­li­ties and systems
  • Data car­ri­er con­trol: Con­trol of the dis­po­sal of data carriers
  • Memo­ry con­trol: con­trol of stored data
  • User con­trol: con­trol over remo­te access
  • Trans­port con­trol: con­trol during data transmission
  • Input con­trol: con­trol over the input and modi­fi­ca­ti­on of data
  • Dis­clo­sure con­trol: con­trol over the dis­clo­sure of data
  • Detec­tion and reco­very: Detect and con­trol incidents. 

You can also look at data secu­ri­ty dif­fer­ent­ly, more from the result and less from the risks. Data secu­ri­ty should ensu­re three points in particular: 

  • the con­fi­dentia­li­ty of data, 
  • the inte­gri­ty of data and
  • the avai­la­bi­li­ty of data. 

After the Eng­lish “Con­fi­dentia­li­ty, Inte­gri­ty” and “Avai­la­bil­ty” is the­re­fo­re also spo­ken of “CIA”.

Data pro­tec­tion law descri­bes secu­ri­ty mea­su­res as “tech­ni­cal and orga­niz­a­tio­nal mea­su­res”, often abbre­via­ted as “TOMs”. 

Tech­ni­cal mea­su­res are mea­su­res that are imple­men­ted tech­ni­cal­ly, e.g. pass­word pro­tec­tion or trans­port encryp­ti­on. Orga­niz­a­tio­nal mea­su­res start with peop­le, e.g. through a dual con­trol princip­le, clean desk inst­ruc­tions, con­tracts, con­trols or trai­ning. Tech­ni­cal mea­su­res tend to be stronger.


Which secu­ri­ty mea­su­res are requi­red in each case is a que­sti­on of the cir­cum­stan­ces, e.g. the system of data pro­ces­sing, the risks and the mea­su­res that are fac­tual­ly in que­sti­on. The GDPR does not exhaus­tively list the fol­lo­wing mea­su­res, some of which are, howe­ver, pro­tec­tion goals rather than measures:

  • Pseud­ony­miz­a­ti­on and encryption;
  • Abi­li­ty to ensu­re the con­fi­dentia­li­ty, inte­gri­ty, avai­la­bi­li­ty and resi­li­en­ce of the systems and ser­vices rela­ted to the pro­ces­sing on an ongo­ing basis;
  • Abi­li­ty to quick­ly res­to­re avai­la­bi­li­ty of and access to per­so­nal data in the event of a phy­si­cal or tech­ni­cal incident
  • Pro­ce­du­res for perio­di­cal­ly reviewing, asses­sing and eva­lua­ting the effec­ti­ve­ness of tech­ni­cal and orga­niz­a­tio­nal mea­su­res to ensu­re the secu­ri­ty of processing.

The FDPIC, in its some­what dated Gui­de to tech­ni­cal and orga­niz­a­tio­nal mea­su­res Examp­les listed (which may or may not be requi­red depen­ding on circumstances).

Spe­ci­fic secu­ri­ty mea­su­res are also spe­ci­fied in indu­stry-spe­ci­fic regu­la­ti­ons, e.g., for the credit card indu­stry in the Pay­ment Card Indu­stry Data Secu­ri­ty Stan­dard (PCI DSS), for banks and secu­ri­ties firms in the Cir­cu­lar on Ope­ra­tio­nal Risks, in the gui­de­li­nes of the Ban­kers Asso­cia­ti­on for Data Leaka­ge Pre­ven­ti­on and the recom­men­da­ti­ons for Busi­ness Con­ti­nui­ty Manage­ment, and for the federal government in the forth­co­m­ing Infor­ma­ti­on Secu­ri­ty Act.

The cur­rent DSG under­stands the princip­le of data secu­ri­ty more broad­ly and sees it accord­in­gly vio­la­ted by any unaut­ho­ri­zed pro­ces­sing. The revDSG and the GDPR are nar­rower: the data secu­ri­ty princip­le only con­cerns actu­al security. 

A secu­ri­ty bre­ach is defi­ned accord­in­gly, in the revDSG as well as in the DSGVO. It con­sists in each case in the fact that 

  • a bre­ach of secu­ri­ty occurs, i.e. a fail­u­re of a tech­ni­cal or an orga­niz­a­tio­nal measure,
  • which, second­ly, has a spe­ci­fic con­se­quence, name­ly leads to per­so­nal data being unin­ten­tio­nal­ly or unlaw­ful­ly lost, dele­ted, destroy­ed or alte­red, or dis­c­lo­sed or made acces­si­ble to unaut­ho­ri­zed persons.

A secu­ri­ty bre­ach does not inclu­de unaut­ho­ri­zed pro­ces­sing by the respon­si­ble par­ty, e.g., fail­u­re to dele­te or unaut­ho­ri­zed chan­ge of purpose. 

The cur­rent FADP does not pro­vi­de for an expli­cit obli­ga­ti­on to report secu­ri­ty brea­ches to the FDPIC or the data sub­jects. In excep­tio­nal cases, howe­ver, such an obli­ga­ti­on may ari­se from gene­ral principles. 

Howe­ver, the GDPR reco­gni­zes noti­fi­ca­ti­on obli­ga­ti­ons, and the revDSG also intro­du­ces such obligations.

Reporting obli­ga­ti­ons can also ari­se from indu­stry-spe­ci­fic regu­la­ti­ons. Howe­ver, the­se are based less on the vio­la­ti­on of the pro­tec­tion of per­so­nal data than on inci­dents that are rele­vant in the indu­stry in que­sti­on. One examp­le is the obli­ga­ti­on to report inci­dents rele­vant to super­vi­si­on to FINMA pur­suant to Art. 29 FINMASA. 

Under the revDSG, data con­trol­lers must noti­fy the FDPIC of a secu­ri­ty bre­ach if it is “likely to result in a high risk” to data sub­jects. This is whe­re the revDSG dif­fers from the GDPR – under the GDPR, all secu­ri­ty brea­ches that lead to a risk must be reported.

You can also report secu­ri­ty brea­ches to the FDPIC volun­ta­ri­ly. As a rule, this is not advisable.

Accord­ing to the revDSG, the con­trol­ler must inform the data sub­jects about a secu­ri­ty bre­ach – with regard to their data – if it is necessa­ry to pro­tect the data sub­ject. This may be the case, for examp­le, if access data to an account has been sto­len and the data sub­ject may use the same access data else­whe­re or may only be able to block the affec­ted account himself. 

Also to report secu­ri­ty brea­ches when reque­sted by the FDPIC (but not necessa­ri­ly as he requests).