Data pro­tec­tion law requi­res a num­ber of mea­su­res. Some of the­se beco­me neces­sa­ry during ongo­ing ope­ra­ti­ons, such as a data breach noti­fi­ca­ti­on or a respon­se to a request for infor­ma­ti­on. Howe­ver, this may requi­re some pre­pa­ra­ti­on, which is why com­pa­nies – at least lar­ger ones – need to proac­tively address the­se issues. Other mea­su­res must be taken in advan­ce, regard­less of an indi­vi­du­al event. 

Data pro­tec­tion law the­r­e­fo­re requi­res “imple­men­ta­ti­on,” i.e., cer­tain mea­su­res to avo­id the risk of a data breach, in the inte­rest of the data sub­jects as well as the com­pa­ny and its employees and manage­ment bodies. 

How to imple­ment this depends very much on the indi­vi­du­al case. Very small com­pa­nies can get by with a pri­va­cy poli­cy, lar­ge com­pa­nies have to do a lot more. 

You will the­r­e­fo­re find ins­truc­tions for imple­men­ta­ti­on here:

Table of Contents 

Check­lists and guides

We pro­vi­de gui­des and check­lists for the imple­men­ta­ti­on of the nDSG, for SMEs (under Swiss law) and for lar­ger com­pa­nies (also with a view to the GDPR).

Not only lar­ge com­pa­nies have to imple­ment the new data pro­tec­tion law, but also SMEs. The­re are only mar­gi­nal excep­ti­ons for SMEs in the nDSG – most of the requi­re­ments also app­ly to them. Howe­ver, the expec­ta­ti­ons for the stan­dard of imple­men­ta­ti­on are different.

We have the­r­e­fo­re pre­pared a check­list for SMEs. It is desi­gned for simp­ler cir­cum­stances and pri­va­te com­pa­nies (not for public bodies). It does not cla­im to be com­ple­te and does not con­sti­tu­te legal advice.

In the case of lar­ger or inter­na­tio­nal­ly acti­ve com­pa­nies, it can often be assu­med that the GDPR will be imple­men­ted, inso­far as this is pos­si­ble. Accor­din­gly, such com­pa­nies ask them­sel­ves less which requi­re­ments of the new DPA and more whe­re dif­fe­ren­ces exist bet­ween the GDPR and the nDSG. For this pur­po­se, we pro­vi­de a guide:

You can also find docu­ments under Down­loads.

Appli­ca­bi­li­ty of the GDPR?

Do I fall under the GDPR? The GDPR (Gene­ral Data Pro­tec­tion Regu­la­ti­on) applies in the ter­ri­to­ry of the EU and the rest of the EEA. Howe­ver, it may also app­ly to com­pa­nies in Switz­er­land – under cer­tain con­di­ti­ons. If you are not sure whe­ther this also applies to you, you can use our Do self test.


How should I pro­ce­ed with the imple­men­ta­ti­on? The imple­men­ta­ti­on of the revi­sed DPA can, but need not, be cost­ly. Depen­ding on the size of the com­pa­ny, the com­ple­xi­ty of its pro­ce­s­ses and the scope and sen­si­ti­vi­ty of its data and pro­ce­s­sing, the effort requi­red varies con­sider­a­b­ly. In extre­me cases, a data pro­tec­tion state­ment on the web­site is suf­fi­ci­ent. In most cases, howe­ver, a num­ber of addi­tio­nal points need to be taken into account. The fol­lo­wing list is accor­din­gly not exhaus­ti­ve, but not ever­ything is man­da­to­ry eit­her. The todos the­r­e­fo­re also con­tain points of note and con­side­ra­ti­ons that a com­pa­ny should make. 

Fur­ther information 

Gene­ral infor­ma­ti­on on data pro­tec­tion law

This sec­tion con­ta­ins some gene­ral infor­ma­ti­on on data pro­tec­tion law. It can also be skip­ped – it is not neces­sa­ry for under­stan­ding the fur­ther explanations.

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 sec­re­cy 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 fede­ral bodies, legal bases for the pro­ce­s­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 sec­re­cy 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). 

Within 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­ce­s­sing prin­ci­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 include, for exam­p­le, the obli­ga­ti­on to main­tain a pro­ce­s­sing direc­to­ry, to con­duct a data pro­tec­tion impact assess­ment or to report a secu­ri­ty breach. A third lay­er is for­med by data sub­ject rights, which are inten­ded to enable the data sub­ject to influence data pro­ce­s­sing. The fourth lay­er con­sists of the FDPIC’s super­vi­so­ry powers and sanctions.

In Switz­er­land:

  • Curr­ent­ly, pri­ma­ri­ly in the Fede­ral Data Pro­tec­tion Act (FDPA) and in the Ordi­nan­ce to the FADP (FDPO). This applies to pri­va­te com­pa­nies and to fede­ral bodies. For public bodies of the can­tons and muni­ci­pa­li­ties, the can­to­nal data pro­tec­tion laws are appli­ca­ble (see Links).
  • Data pro­tec­tion law is being revi­sed. The revi­sed DPA (revFD­PA) is available in a final ver­si­on. The VDSG is also being revi­sed, but is curr­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, sec­re­cy 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­r­ers, pen­si­on funds, etc. 

In Euro­pe:

  • Here applies 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­r­e­fo­re con­ti­n­ue 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 include the pro­fes­sio­nal secrets of, for exam­p­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 sec­re­cy is also offi­ci­al secrecy. 

In addi­ti­on, the­re are trade secrets, which are pro­tec­ted, for exam­p­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 exam­p­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 ext­ent. This is main­ly due to the fact that both are­as have beco­me much more important in the cour­se of digi­tizati­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­sing­ly bring to light com­mo­n­a­li­ties, such as the importance of the expec­ta­ti­ons of the pro­tec­ted per­sons, i.e., the data sub­jects and the sec­re­cy 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­thens cri­mi­nal data pro­tec­tion law, and espe­ci­al­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­cis­e­ly in such situa­tions, e.g., order pro­ce­s­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­ning of dis­clo­sure brings data pro­tec­tion law clo­ser to sec­re­cy law, even though the­re remain fun­da­men­tal dif­fe­ren­ces bet­ween the two.

Basic terms

Per­so­nal data is any infor­ma­ti­on that rela­tes to an iden­ti­fi­ed 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 someone who has access to a datum can assign it to a per­son becau­se he or she has the neces­sa­ry addi­tio­nal infor­ma­ti­on (“Employee 123452” is a per­so­nal datum for the HR depart­ment, but not neces­s­a­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 someone with access to the date can infer a per­son (“rela­ti­ve approach”) or alre­a­dy if any third par­ty could do so (“abso­lu­te approach”). In Switz­er­land, accor­ding to the Logi­step ruling of the Fede­ral Supre­me Court the rela­ti­ve approach. In Euro­pe, accor­ding to the Brey­er decis­i­on of the ECJ same, but the requi­re­ments for deter­mina­bi­li­ty are set quite 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­gu­is­hed from all others (“Sin­gu­la­rizati­on”). Euro­pean aut­ho­ri­ties seem to be incre­a­sing­ly turn to the con­cept of sin­gu­la­rizati­on, ulti­m­ate­ly for purely pro­tec­ti­ve con­side­ra­ti­ons and the­r­e­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­sider 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 exam­p­le, under the cur­rent FADP, expli­cit infor­ma­ti­on must alre­a­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­fi­ed, i.e. in prin­ci­ple it is con­side­red to be inf­rin­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­ce­s­sed on the basis of con­sent, this can only be given expli­ci­t­ly; if the pro­ce­s­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­ce­s­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 fede­ral bodies, the pro­ce­s­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 wort­hy of pro­tec­tion inclu­des data about reli­gious, ideo­lo­gi­cal, poli­ti­cal or trade uni­on views or acti­vi­ties (e.g., payments to a reli­gious com­mu­ni­ty, infor­ma­ti­on about atten­dance at a trade 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­fi­ed 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­sider 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 someone wea­ring glas­ses is the­r­e­fo­re not con­side­red a health datum, and a regio­nal­ly assi­gnable name is not con­side­red a datum about ethnicity.

No. At least not accor­ding to Swiss law – this has been cla­ri­fi­ed by the still valid Logi­step decis­i­on of the Fede­ral Supre­me Court. Nevert­hel­ess, the­re is a ten­den­cy to con­sider IP addres­ses and other uni­que iden­ti­fiers, such as a coo­kie ID, as per­so­nal data wit­hout any actu­al justi­fi­ca­ti­on. The FDPIC has also alre­a­dy expres­sed its­elf in this direc­tion. And in Euro­pe, this ten­den­cy is clear; here, IP addres­ses are gene­ral­ly regard­ed as per­so­nal data. What does “pro­ce­s­sing” mean? What is a “respon­si­ble par­ty”? What are “joint­ly respon­si­ble par­ties”? Do joint­ly respon­si­ble par­ties have to sign a con­tract? What is an order processor?

The start­ing 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 data item 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 no lon­ger exists. “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­bera­te­ly removed.

This means that the requi­re­ments for anony­mizati­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­r­e­fo­re no lon­ger applies to this date. Under data pro­tec­tion law, the pro­ce­s­sing of this date is the­r­e­fo­re no lon­ger restricted.

It also fol­lows that anony­mizati­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­mizati­on means that the refe­rence to a per­son in a per­so­nal data is indi­rect – it exists, 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­mizati­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­cis­e­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­nizatio­nal and infor­ma­tio­nal sepa­ra­ti­on is the­r­e­fo­re required.

Pseud­ony­mizati­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­mizati­on in his orga­nizati­on no lon­ger pro­ce­s­ses per­so­nal data – the date is pseud­ony­mi­zed, not anony­mi­zed. Howe­ver, it increa­ses the pro­tec­tion of the data in que­sti­on. It can the­r­e­fo­re lead to com­pli­ance with the prin­ci­ple of data secu­ri­ty, but also to the fact that an over­ri­ding inte­rest in the pro­ce­s­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 deter­mi­ned 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­ce­s­sing. This has the fol­lo­wing effect: If per­son A dis­c­lo­ses a pseud­ony­mi­zed datum that has a per­so­nal refe­rence 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 neither 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 exam­p­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 wit­hout the rest­ric­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 Fede­ral Supre­me Court was in Logi­step judgment stric­ter – in such a case, data pro­tec­tion law applies 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­sider this ruling to be incon­clu­si­ve and inap­pli­ca­ble on this point.

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

Data pro­tec­tion law reco­gnizes dif­fe­rent roles depen­ding on the influence on a par­ti­cu­lar data pro­ce­s­sing. Deter­mi­ning the roles of the par­ties invol­ved is always the start­ing 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­ce­s­sing. This is deter­mi­ned by two cri­te­ria: The con­trol­ler initia­tes the data pro­ce­s­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­ce­s­sing, i.e. which data are pro­ce­s­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 exam­p­le, a com­pa­ny for pro­ce­s­sing the per­so­nal data of its employees, or a com­pa­ny for its own direct mar­ke­ting, but also a fede­ral 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­ce­s­sing to a ser­vice pro­vi­der. It may even be the case that he neither has nor knows the pro­ce­s­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­ce­s­sing of a third party.

Seve­ral 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­ce­s­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­gu­ish two con­stel­la­ti­ons of shared responsibility:

Joint respon­si­bi­li­ty often exists when seve­ral com­pa­nies use the same system for simi­lar pro­ce­s­sing and the­r­e­fo­re joint­ly enga­ge a ser­vice pro­vi­der. Par­ti­cu­lar­ly in a group rela­ti­on­ship, 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­ce­s­ses data and dis­c­lo­ses it to ano­ther 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­sing­ly assu­med when seve­ral com­pa­nies work tog­e­ther in part­ner­ship and both have a signi­fi­cant influence on the processing.

Swiss data pro­tec­tion law does not expli­ci­t­ly requi­re that joint­ly respon­si­ble par­ties con­clude a con­tract, unli­ke the GDPR requi­res in most cases. The­r­e­fo­re, an unno­ti­ced joint respon­si­bi­li­ty does not neces­s­a­ri­ly con­sti­tu­te a breach. Howe­ver, it makes sen­se that when pro­ce­s­sing ope­ra­ti­ons of seve­ral com­pa­nies are inter­mingled, 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­ce­s­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 useful in the case of joint­ly respon­si­ble per­sons, but often also when seve­ral 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­ce­s­ses data but does not deter­mi­ne the spe­ci­fic pro­ce­s­sing. This applies in par­ti­cu­lar – but not only – to IT ser­vice pro­vi­ders. For exam­p­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 influence the ope­ra­tor has on the type of data pro­ce­s­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­r­e­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 exam­p­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­ce­s­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­ce­s­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.

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

On the revi­si­on of data pro­tec­tion law

The revi­sed DSG and the regu­la­ti­on (FDPO) enter into force on Sep­tem­ber 1, 2023. The Fede­ral Coun­cil still bare­ly in August 2022 the revDSG and the revi­sed VDSG – new “DSV” – with a one-year infor­mal tran­si­ti­on peri­od to Sep­tem­ber 1, 2023 in force.

Yes, becau­se it makes data pro­tec­tion law more for­ma­li­stic to a cer­tain ext­ent, 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 cus­to­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 stake­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­r­e­fo­re not avo­id deal­ing 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­ce­s­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 alre­a­dy been imple­men­ted – to the ext­ent 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 Fede­ral 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.

About the GDPR

GDPR” stands for “Gene­ral Data Pro­tec­tion Regu­la­ti­on”. This is a regu­la­ti­on that governs the hand­ling of per­so­nal data and is appli­ca­ble throug­hout the EU and the rest of the EEA, inclu­ding Liech­ten­stein, Ice­land and Norway. 

The GDPR is most­ly stric­ter than the Swiss GDPR, and part­ly very detail-ori­en­ted and formalistic. 

It may also be appli­ca­ble to com­pa­nies in Switz­er­land. Whe­ther this also applies to you, you can find out here.

Yes and no. It is clear that data pro­tec­tion law was hard­ly enforced 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­tance of data pro­tec­tion law. It is also not justi­fi­ed 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 exam­p­le, eco­no­mic free­dom. Unfort­u­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­ce­s­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­ther 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 cus­to­mers (natu­ral per­sons) in the EEA as cus­to­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­mut­ers are not end cus­to­mers – employees living abroad who work for Switz­er­land are the­r­e­fo­re hard­ly suf­fi­ci­ent for the appli­ca­ti­on of the GDPR.
  • Do you have end cus­to­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 track­ing through a web­site or app, inclu­ding coll­ec­ting data from indi­vi­du­als in the EEA?
  • Do you other­wi­se coll­ect 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 appli­ca­bi­li­ty of the GDPR more clo­se­ly. If not, it is unli­kely that you are cover­ed by the GDPR.

But: Switz­er­land has its own rules that can lead to appli­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 accor­ding to the law in their home coun­try. The court would then not con­sider 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 request 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­cessful­ly).

Inci­den­tal­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 cover­ed by the GDPR. This applies 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 cus­to­mers in turn must com­ply with the GDPR and the­r­e­fo­re demand the same from their ser­vice provider.

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

Orga­nizati­on of data protection

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­ance with the GDPR and to sup­port the con­trol­ler or pro­ces­sor. The revDSG takes up this idea and reco­gnizes the “data pro­tec­tion advi­sor” (DPO). 

DPOs and DPOs are inten­ded to be inde­pen­dent enti­ties within the orga­nizati­on of the Com­pa­ny. As employees, they are sub­ject to the ins­truc­tions of the com­pa­ny, but not with regard to their func­tion as DPO and DPO. The com­pa­ny may the­r­e­fo­re not dic­ta­te to them which pro­ce­s­sing ope­ra­ti­ons they review or how they assess com­pli­ance 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­ce­s­sing. They may the­r­e­fo­re be based in Legal Ser­vices or Com­pli­ance, 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 cont­act per­sons for data sub­jects and aut­ho­ri­ties. Their cont­act details must the­r­e­fo­re be published, e.g. in a pri­va­cy statement.

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­ance with the GDPR and to sup­port the con­trol­ler or pro­ces­sor. The revDSG takes up this idea and reco­gnizes the “data pro­tec­tion advi­sor” (DPO). 

DPOs and DPOs are inten­ded to be inde­pen­dent enti­ties within the orga­nizati­on of the Com­pa­ny. As employees, they are sub­ject to the ins­truc­tions of the com­pa­ny, but not with regard to their func­tion as DPO and DPO. The com­pa­ny may the­r­e­fo­re not dic­ta­te to them which pro­ce­s­sing ope­ra­ti­ons they review or how they assess com­pli­ance 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­ce­s­sing. They may the­r­e­fo­re be based in Legal Ser­vices or Com­pli­ance, 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 cont­act per­sons for data sub­jects and aut­ho­ri­ties. Their cont­act details must the­r­e­fo­re be published, e.g. in a pri­va­cy statement.

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

Con­trol­lers must record their pro­ce­s­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 accor­ding to the GDPR: of the EU repre­sen­ta­ti­ve and the DPO, if any
  • the pro­ce­s­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 appli­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 appli­ca­ble, the appli­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­ce­s­sing direc­to­ry, but with fewer con­tent requirements.

Pro­ce­s­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­ce­s­sing directory.

Howe­ver, the­re is the “SME excep­ti­on”. The revDSG requi­res the Fede­ral 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­r­e­fo­re pro­vi­des that data con­trol­lers and order pro­ces­sors do not have to keep a pro­ce­s­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­ce­s­sed, and
  • no high-risk pro­fil­ing is performed. 

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

Fede­ral bodies – inclu­ding, for exam­p­le, pen­si­on funds and orga­nizati­ons under pri­va­te law that ful­fill a fede­ral task – must main­tain a pro­ce­s­sing direc­to­ry. They must also report it to the FDPIC and for this pur­po­se must pro­vi­de a Open user account. Howe­ver, one can also send the direc­to­ry to the FDPIC in this way. The direc­to­ries of the fede­ral bodies are published.

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 ali­gn their mea­su­res for com­pli­ance 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 pro­tec­ting 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­ce­s­sing ope­ra­ti­ons, and they must proac­tively ensu­re com­pli­ance with data pro­tec­tion law (this is what the prin­ci­ple of “pri­va­cy by design” means). 

If they deter­mi­ne that cer­tain data pro­ce­s­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 applies under the revDSG as well as under the GDPR. 

A DSFA is the­r­e­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.

What prin­ci­ples app­ly to the pro­ce­s­sing of per­so­nal data?

Accor­ding to both the FADP – and the revDSG – and the GDPR, cer­tain prin­ci­ples must be obser­ved for any pro­ce­s­sing of per­so­nal data. The­se are the prin­ci­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­ce­s­sing prin­ci­ple under the revDSG, or at least not a typi­cal one, after the pro­vi­si­on on per­so­na­li­ty inf­rin­ge­ment no lon­ger refers to data secu­ri­ty. In addi­ti­on, the­re is the prin­ci­ple of good faith.

The rela­ti­on­ship bet­ween the prin­ci­ples is not very clear. The prin­ci­ple of good faith is rather a catch-all prin­ci­ple. The three inter­re­la­ted prin­ci­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­ce­s­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­ce­s­sing that is sui­ta­ble and neces­sa­ry for the pur­po­se of the pro­ce­s­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 within the frame­work of the broa­der legal system. He is not limi­t­ed in this by the FADP – the eco­no­mic free­dom applies, sub­ject to the vio­la­ti­on of a beha­vi­oral 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­ce­s­sing should not be – then he sum­ma­ri­ly calls it dis­pro­por­tio­na­te, wit­hout taking into account that the con­trol­ler may have set the pur­po­se broadly).

The con­trol­ler the­r­e­fo­re sets the pur­po­se, and does so through trans­pa­ren­cy: the pro­ce­s­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­gnizable from the cir­cum­stances). The bot­tom line, then, is that the con­trol­ler sets the pur­po­se, must abide by it, and may pro­cess data only as neces­sa­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­ce­s­sing prin­ci­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­ce­s­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­ce­s­sing principle.

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

Howe­ver, what must be trans­pa­rent in con­cre­te terms, i.e. which cir­cum­stances of pro­ce­s­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­growth of the trans­pa­ren­cy prin­ci­ple. It requi­res that data be pro­ce­s­sed only as neces­sa­ry for the (trans­pa­rent) pur­po­se. Mis­ap­pro­pria­ti­on is the­r­e­fo­re pro­hi­bi­ted, at least wit­hout 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 mis­ap­pro­pria­ti­on. The revi­sed DPA cla­ri­fi­es 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­gnize any fun­da­men­tal pro­hi­bi­ti­on of data pro­ce­s­sing, unli­ke the GDPR. The­r­e­fo­re, data pro­ce­s­sing does not have to be justi­fi­ed in prin­ci­ple. This also applies to the pro­ce­s­sing of per­so­nal data requi­ring spe­cial pro­tec­tion, today to the pro­ce­s­sing of per­so­na­li­ty pro­files and, accor­ding to the revDSG, to pro­fil­ing, even high-risk pro­fil­ing. It is the­r­e­fo­re wrong for the FDPIC to want to per­mit pro­ce­s­sing of par­ti­cu­lar­ly sen­si­ti­ve per­so­nal data only with con­sent. Howe­ver, if a pro­ce­s­sing prin­ci­ple is vio­la­ted, the cor­re­spon­ding pro­ce­s­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­ce­s­sing, but only a vio­la­ti­on of a pro­ce­s­sing prin­ci­ple. 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­ce­s­sing con­tra­ry to a prin­ci­ple. 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 vol­un­t­a­ri­ly. This rai­ses the que­sti­on under which cir­cum­stances con­sent is vol­un­t­a­ry if it has been made a con­di­ti­on of, for exam­p­le, the con­clu­si­on of a con­tract (“pro­hi­bi­ti­on of tying”).
  • Law: Pro­ce­s­sing that the law spe­ci­fi­es 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­ce­s­sing in que­sti­on out­weigh the con­flic­ting inte­rests of the data sub­ject, the cor­re­spon­ding pro­ce­s­sing is per­mit­ted. In each case, all inte­rests in pro­ce­s­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 prin­ci­ple of pri­va­cy by design only means that com­pli­ance with data pro­tec­tion law must be ensu­red proac­tively, i.e., alre­a­dy when pro­ce­s­sing is plan­ned. As a result, an appli­ca­ti­on must be able, for exam­p­le, to dele­te data or assign access rights on a role-based basis. 

The GDPR and the revDSG now expli­ci­t­ly pro­vi­de for this prin­ci­ple. 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 exce­s­si­ve effort requi­red to rewri­te an appli­ca­ti­on to make it dele­ta­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 applies to exi­sting pro­ce­s­sing under cer­tain conditions.

How must infor­ma­ti­on about data acqui­si­ti­ons be provided?

Not neces­s­a­ri­ly accor­ding to the cur­rent DPA. At pre­sent, infor­ma­ti­on is only requi­red if pro­ce­s­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). 

Accor­ding 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­ce­s­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, accor­ding to the revDSG:

  • inso­far as the data sub­ject has alre­a­dy been suf­fi­ci­ent­ly infor­med (e.g. by someone else),
  • inso­far as pro­ce­s­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 employment rela­ti­on­ship). Even fede­ral bodies are the­r­e­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­ce­s­sing, e.g. in the case of inter­nal investigations, 
  • to the ext­ent 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 fede­ral 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, inquiry 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 appli­ca­ble local law must be consulted.

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

  • Name and cont­act details of the per­son respon­si­ble for the pro­ce­s­sing in question
  • if a data pro­tec­tion advi­sor has been appoin­ted: his cont­act 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 someone else: the natu­re of the data processed
  • if data are trans­fer­red: the­se reci­pi­en­ts or the cate­go­ries of reci­pi­en­ts (also within 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 count­ries or regi­ons con­cer­ned, and, if appli­ca­ble, the con­clu­si­on of SCCs or the appli­ca­ti­on of an excep­ti­on to the pro­hi­bi­ti­on of dis­clo­sure in count­ries wit­hout 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 cont­act details
  • if an EU repre­sen­ta­ti­ve has been appoin­ted: his cont­act details
  • the legal basis of the pro­ce­s­sing (e.g. the legi­ti­ma­te inte­rests pur­sued thereby)
  • the dura­ti­on of the sto­rage or pro­ce­s­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, rest­ric­tion, objec­tion, data por­ta­bi­li­ty, revo­ca­ti­on of con­sent, com­plaint to an authority.

Accor­ding to the GDPR, not all count­ries have to be named for this, but only count­ries out­side the EEA.

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

  • Accor­ding to the prin­ci­ple 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 decis­i­on, fur­ther infor­ma­ti­on, but not neces­s­a­ri­ly in a pri­va­cy state­ment, but when the decis­i­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 coll­ects 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 someone else. This is often neces­sa­ry. For exam­p­le, if a bank cus­to­mer dis­c­lo­ses infor­ma­ti­on about an aut­ho­ri­zed repre­sen­ta­ti­ve or a bene­fi­ci­al owner of assets, often only he or she – and not the bank – can inform. In this case, the bank can agree with the cus­to­mer that the lat­ter informs the other per­sons. In fact, the cus­to­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­ci­al­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­ce­s­sing ope­ra­ti­ons as pos­si­ble (as long as it remains com­pre­hen­si­ble), e.g., hand­ling end-cus­to­mer data, cus­to­mer and sup­plier cont­act data, mar­ke­ting, and ancil­la­ry pur­po­ses such as sta­tis­tics, admi­ni­stra­ti­on, com­pli­ance, law enforce­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 useful, depen­ding on the case, espe­ci­al­ly if cer­tain pro­ce­s­sing is not wit­hout sen­si­ti­vi­ty, but only affects a smal­ler, deli­mi­t­ed group of peo­p­le. Here, the rele­vant infor­ma­ti­on is often bet­ter cover­ed in a spe­cia­li­zed, smal­ler pri­va­cy state­ment instead 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 neces­sa­ry and should also be avo­ided. Other­wi­se, the­re is a risk that the data pro­ce­s­sing is based on con­sent – if it is revo­ked, the cor­re­spon­ding pro­ce­s­sing could the­r­e­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­sonable manner.

This has not been ful­ly cla­ri­fi­ed. 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, fede­ral 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 peo­p­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­ce­s­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­gnizable pro­ce­s­sing, the loca­ti­on of the pri­va­cy statement(s) should the­r­e­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­ce­s­sing details are not requi­red. It is suf­fi­ci­ent, for exam­p­le, to sta­te “Infor­ma­ti­on on our hand­ling of per­so­nal data can be found at”. 

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.

What rights do data sub­jects have?

Data pro­tec­tion law requi­res the data con­trol­ler to com­ply with various obli­ga­ti­ons. Nevert­hel­ess, it assu­mes that data sub­jects have a gre­at deal of respon­si­bi­li­ty in the pro­ce­s­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 influence this pro­ce­s­sing – the­se are the data sub­ject rights.

Data sub­jects first have the right to be infor­med about the pro­ce­s­sing of their data, becau­se if they do not know about this pro­ce­s­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 request fur­ther infor­ma­ti­on from the data con­trol­ler about the pro­ce­s­sing of their data. Under the revDSG and the GDPR, they can also request a machi­ne-rea­da­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 influence this pro­ce­s­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­plain to the com­pe­tent authority. 

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

What applies to order processing?

You will find infor­ma­ti­on 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­ce­s­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­ce­s­sed by employees of the ser­vice pro­vi­der on the infras­truc­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 neither 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­r­e­fo­re, no order pro­ce­s­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­ce­s­sing, but in dif­fe­rent respects. The GDPR requi­res a legal basis for any pro­ce­s­sing becau­se any pro­ce­s­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­ce­s­sing is per­mit­ted pro­vi­ded it com­plies with the pro­ce­s­sing prin­ci­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 wit­hout a justification.

This pri­vi­le­ge fol­lows from the fact that the order pro­ces­sor is, to a cer­tain ext­ent, 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­clude a con­tract that meets cer­tain requirements.

Order pro­ces­sors often have an inte­rest in using cer­tain data from their cus­to­mers, the data con­trol­lers, for their own pur­po­ses – for exam­p­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­ce­s­sing for their own pur­po­ses, often wit­hout 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 ext­ent, the­r­e­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 applies, 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­ce­s­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 cont­act 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­r­e­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 wit­hout an ade­qua­te level of pro­tec­tion, alt­hough this is rare­ly imple­men­ted in practice.

What gives in data security?

Data pro­tec­tion law approa­ches the issue of data secu­ri­ty from dif­fe­rent start­ing 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­r­e­fo­re assess the risks for data sub­jects and pro­vi­de for appro­pria­te measures.
  • If neces­sa­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­ce­s­sing of per­so­nal data.
  • A breach of data secu­ri­ty may lead to fur­ther brea­ches (for exam­p­le, con­sent will only ever legi­ti­mi­ze pro­ce­s­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­on­ship 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­r­e­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 – accor­ding 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­ce­s­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­stances of the data pro­ce­s­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­cre­ti­ze the requi­re­ments for data secu­ri­ty by asking about spe­ci­fic risks, or more pre­cis­e­ly, about typi­cal thre­at sce­na­ri­os. The secu­ri­ty mea­su­res must coun­ter the­se sce­na­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­den­tia­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­den­tia­li­ty, Inte­gri­ty” and “Avai­la­bil­ty” is the­r­e­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­nizatio­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­nizatio­nal mea­su­res start with peo­p­le, e.g. through a dual con­trol prin­ci­ple, clean desk ins­truc­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­stances, e.g. the system of data pro­ce­s­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­mizati­on and encryption;
  • Abili­ty to ensu­re the con­fi­den­tia­li­ty, inte­gri­ty, avai­la­bi­li­ty and resi­li­ence of the systems and ser­vices rela­ted to the pro­ce­s­sing on an ongo­ing basis;
  • Abili­ty to quick­ly resto­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 peri­odi­cal­ly revie­w­ing, asses­sing and eva­lua­ting the effec­ti­ve­ness of tech­ni­cal and orga­nizatio­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­nizatio­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­fi­ed in indu­stry-spe­ci­fic regu­la­ti­ons, e.g., for the cre­dit card indu­stry in the Payment Card Indu­stry Data Secu­ri­ty Stan­dard (PCI DSS), for banks and secu­ri­ties firms in the Cir­cular on Ope­ra­tio­nal Risks, in the gui­de­lines 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 fede­ral govern­ment in the for­th­co­ming Infor­ma­ti­on Secu­ri­ty Act.

The cur­rent DSG under­stands the prin­ci­ple of data secu­ri­ty more broad­ly and sees it accor­din­gly vio­la­ted by any unaut­ho­ri­zed pro­ce­s­sing. The revDSG and the GDPR are nar­rower: the data secu­ri­ty prin­ci­ple only con­cerns actu­al security. 

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

  • a breach of secu­ri­ty occurs, i.e. a fail­ure of a tech­ni­cal or an orga­nizatio­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 unlawful­ly lost, dele­ted, destroy­ed or alte­red, or dis­c­lo­sed or made acce­s­si­ble to unaut­ho­ri­zed persons.

A secu­ri­ty breach does not include unaut­ho­ri­zed pro­ce­s­sing by the respon­si­ble par­ty, e.g., fail­ure 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­gnizes noti­fi­ca­ti­on obli­ga­ti­ons, and the revDSG also intro­du­ces such obligations.

Report­ing 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 exam­p­le is the obli­ga­ti­on to report inci­dents rele­vant to super­vi­si­on to FINMA pur­su­ant to Art. 29 FINMASA. 

Under the revDSG, data con­trol­lers must noti­fy the FDPIC of a secu­ri­ty breach 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 vol­un­t­a­ri­ly. As a rule, this is not advisable.

Accor­ding to the revDSG, the con­trol­ler must inform the data sub­jects about a secu­ri­ty breach – with regard to their data – if it is neces­sa­ry to pro­tect the data sub­ject. This may be the case, for exam­p­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 neces­s­a­ri­ly as he requests).

How do cor­po­ra­ti­ons regu­la­te their inter­nal data traffic?

In prin­ci­ple, no. Legal enti­ties within 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­r­e­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 request for infor­ma­ti­on. The same applies to the cor­re­spon­ding excep­ti­on to the duty to inform. Accor­ding 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 par­ty.
The risk of intra-group dis­clo­sure may be lower. Accor­din­gly, dis­clo­sure may be more justi­fi­ed (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­fi­ed manage­ment, data pro­tec­tion law can be imple­men­ted more easi­ly or more effi­ci­ent­ly over­all.
Intra-Group frame­work agree­ments faci­li­ta­te dis­clo­sure.
A DPO or data pro­tec­tion advi­sor may be desi­gna­ted for seve­ral 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 increa­ses, e.g. unno­ti­ced joint respon­si­bi­li­ties, unno­ti­ced com­mis­sio­ned pro­ce­s­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 man­ner.
Employees may work for seve­ral Group com­pa­nies. This makes it dif­fi­cult to delinea­te respon­si­bi­li­ties, which can make it con­sider­a­b­ly more dif­fi­cult to respond to a request for infor­ma­ti­on, for exam­p­le.
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­ce­s­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­den­tia­li­ty, com­pli­ance 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; 
  • Appli­ca­ti­on of the stan­dard con­trac­tu­al clau­ses in the case of intra-group trans­fers to count­ries wit­hout an ade­qua­te level of protection; 
  • Regu­la­ti­on of con­tract pro­ce­s­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­on­ships (e.g. con­tract pro­ce­s­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 available on the Inter­net. Howe­ver, we usual­ly work with tem­pla­tes that can be adapt­ed to the spe­ci­fic case.

Notes & Links

You will find various Links to data pro­tec­tion law

You can also find fur­ther infor­ma­ti­on at and a self-test at the Vischer Pri­va­cy Score.