• Ins­truc­tions
  • Pro­ce­s­sing directory
  • Infor­ma­ti­on
  • Con­tracts
  • For­eign transmission
  • High-risk machi­ning
  • More points

Imple­men­ta­ti­on of the nDSG

In the mean­ti­me, empi­ri­cal values have for­med as to how data pro­tec­tion law is to be imple­men­ted. Espe­ci­al­ly for lar­ge com­pa­nies and com­pa­nies in a com­plex or regu­la­ted envi­ron­ment, num­e­rous other que­sti­ons will ari­se. But as we all know, even the lon­gest jour­ney beg­ins with the first step.

Check­lists for SMEs

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 dif­fe­rent. We have the­r­e­fo­re drawn up 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. 

Imple­men­ta­ti­on for lar­ger companies

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: 


The revi­sed law no lon­ger trusts com­pa­nies to ensu­re data pro­tec­tion wit­hout crea­ting a cer­tain struc­tu­re and orga­nizati­on. It is still much more prin­ci­ple-ori­en­ted than the GDPR, but cer­tain pro­ce­s­ses and frame­work con­di­ti­ons must be documented.

First, a com­pa­ny should set out the prin­ci­ples of its hand­ling of per­so­nal data in a inter­nal gui­de­line (poli­cy) regu­la­ti­ons. This is not man­da­to­ry, but makes sen­se for seve­ral reasons:

  • A poli­cy defi­nes the orga­nizati­on of the com­pa­ny in the area of data pri­va­cy, and in par­ti­cu­lar also the inter­nal per­sons in char­ge and respon­si­bi­li­ties. Thus, a poli­cy is also an ele­ment of cor­rect dele­ga­ti­on and thus reli­ef for the manage­ment bodies.
  • A poli­cy helps to com­mu­ni­ca­te the company’s com­mit­ment to appro­pria­te data pro­tec­tion internally.
  • It is fore­seeable that com­pa­nies will be asked more often for a poli­cy by cus­to­mers and pos­si­bly in the event of an acquisition.
  • If a data breach hap­pens, a poli­cy helps defend it, or at least argue that you did­n’t com­ple­te­ly dis­re­gard data privacy.

As part of the poli­cy, the com­pa­ny should the­r­e­fo­re con­sider, among other things, who should be respon­si­ble for what. This also rai­ses the que­sti­on of what know-how and resour­ces are available intern­al­ly and what should be purcha­sed. A que­sti­on of orga­nizati­on is also the appoint­ment of a Pri­va­cy Advi­sor (this is more or less equi­va­lent to the “DPO” of the GDPR). You don’t have to appoint a data pro­tec­tion advi­sor, but it can be useful, espe­ci­al­ly for com­pa­nies with sen­si­ti­ve data and tho­se with spe­cial cus­to­mer expectations.

Whe­ther fur­ther poli­ci­es, direc­ti­ves or gui­dance are requi­red depends on the com­ple­xi­ty of the orga­nizati­on and its busi­ness model. 

In any case, it makes sen­se to have a poli­cy for Data dele­ti­on. Notes on this can be found below. 

Also the hand­ling of Data secu­ri­ty brea­ches is essen­ti­al. On the one hand, the revDSG intro­du­ces an obli­ga­ti­on to noti­fy secu­ri­ty brea­ches to the FDPIC or the data sub­jects under cer­tain con­di­ti­ons. Only a limi­t­ed peri­od of time is available for this. Second, mis­hand­ling secu­ri­ty brea­ches leads to repu­ta­tio­nal risks. Com­pa­nies must the­r­e­fo­re con­sider how they can ensu­re that secu­ri­ty brea­ches are dis­co­ver­ed quick­ly and taken up or escala­ted internally.

Also useful can be a gene­ral Ins­truc­tion The aim should be to pro­vi­de the simp­lest and most con­cre­te infor­ma­ti­on pos­si­ble on how to deal with unusu­al situa­tions, such as a secu­ri­ty breach, a request for infor­ma­ti­on or the use of new software.

  • Pre­pa­ra­ti­on of a draft poli­cy with the essen­ti­al prin­ci­ples of data pro­tec­tion in the company
  • Coor­di­na­ti­on with inter­nal affec­ted per­sons – whoe­ver is given a task must accept it and be appro­pria­te­ly pre­pared for it (and have the neces­sa­ry resources)
  • Con­side­ra­ti­on of whe­ther addi­tio­nal poli­ci­es or ins­truc­tions are appro­pria­te, e.g., for data dele­ti­on or hand­ling of secu­ri­ty breaches. 
  • If neces­sa­ry, ela­bo­ra­ti­on of fur­ther poli­ci­es or instructions

Pro­ce­s­sing directory

The revi­sed law deli­bera­te­ly refrains from impo­sing a sepa­ra­te, gene­ral duty to docu­ment pro­ce­s­sing ope­ra­ti­ons or the asso­cia­ted decis­i­ons. Howe­ver, the legis­la­tor still pro­vi­des for so-cal­led accoun­ta­bi­li­ty obli­ga­ti­ons in cer­tain are­as. The­se include, for exam­p­le, the obli­ga­ti­on to retain data for the data pro­tec­tion impact assess­ment or log­ging, but abo­ve all the obli­ga­ti­on to keep a pro­ce­s­sing directory.

The pro­ce­s­sing direc­to­ry is a direc­to­ry of the pro­ce­s­sing acti­vi­ties of a com­pa­ny. It is not a cata­log of indi­vi­du­al data (e.g. the names of all cus­to­mers), but a list of the way in which data is pro­ce­s­sed. The law does not defi­ne “pro­ce­s­sing acti­vi­ty”, but it is about data pro­ce­s­sing with a simi­lar pur­po­se and com­pa­ra­ble frame­work. The direc­to­ry should not be too gra­nu­lar, becau­se it should be self-expl­ana­to­ry and pro­vi­de an under­stan­da­ble pic­tu­re of the pro­ce­s­sing acti­vi­ties – this is not achie­ved with hundreds of ent­ries. For an SME, it should rather be 10 – 15 activities.

Respon­si­ble par­ties and order pro­ces­sors must both main­tain a direc­to­ry, but it dif­fers great­ly in con­tent. Respon­si­ble have per machi­ning acti­vi­ty the fol­lo­wing points to record – the­se are the points that descri­be a pro­ce­s­sing ope­ra­ti­on in terms of data pro­tec­tion law and cha­rac­te­ri­ze its risks:

  • Com­pa­ny name and address of the per­son respon­si­ble (i.e. the com­pa­ny, not, for exam­p­le, the per­sons respon­si­ble for fil­ling out the directory)
  • in each case, the pur­po­se of the machi­ning (what is it for, why does it exist at all)
  • Cate­go­ries of data sub­jects (e.g. employees, appli­cants, cont­act per­sons of cus­to­mers, end cus­to­mers, etc.)
  • Cate­go­ries of per­so­nal data pro­ce­s­sed (e.g. master data, tran­sac­tion data, con­tract data, etc.)
  • Cate­go­ries of reci­pi­en­ts (e.g. IT ser­vice pro­vi­ders, group com­pa­nies, aut­ho­ri­ties, part­ners, etc.)
  • The reten­ti­on peri­od or the cri­te­ria for deter­mi­ning the dura­ti­on (pre­fer­a­b­ly by refe­rence to a dele­ti­on con­cept; other­wi­se e.g. “six months from X”, “11 years from X”, “inde­fi­ni­te”, etc.)
  • Descrip­ti­on of the data secu­ri­ty mea­su­res (e.g. by refer­ring to a docu­ment with the rele­vant information);
  • if data is or will be dis­c­lo­sed abroad: a list of the­se count­ries (this also inclu­des count­ries in Euro­pe and all dis­clo­sures, inclu­ding tho­se to ser­vice pro­vi­ders). If a dis­clo­sure is based on the stan­dard con­trac­tu­al clau­ses (or ano­ther data trans­fer con­tract), this should also be mentioned.

Order pro­ces­sor may make things a litt­le easier for them­sel­ves, they only have to keep a list of the per­sons respon­si­ble for whom they pro­cess data on behalf of and descri­be the types of pro­ce­s­sing on behalf of. In addi­ti­on, they must also record the infor­ma­ti­on on data secu­ri­ty and on dis­clo­sure abroad.

As part of the poli­cy, the com­pa­ny should the­r­e­fo­re con­sider, among other things, who should be respon­si­ble for what. This also rai­ses the que­sti­on of what know-how and resour­ces are available intern­al­ly and what should be purcha­sed. A que­sti­on of orga­nizati­on is also the appoint­ment of a Pri­va­cy Advi­sor (this is more or less equi­va­lent to the “DPO” of the GDPR). You don’t have to appoint a data pro­tec­tion advi­sor, but it can be useful, espe­ci­al­ly for com­pa­nies with sen­si­ti­ve data and tho­se with spe­cial cus­to­mer expectations.

The law says litt­le about the form of the direc­to­ry. Howe­ver, it does not have to be signed, nor does it have to be audit-pro­of. The requi­re­ments of the GebüV for the sto­rage of accoun­ting docu­ments do not app­ly eit­her. The fol­lo­wing are the­r­e­fo­re possible 

  • an Excel or Word docu­ment, local­ly or in Share­point or other platform
  • Tools that are often alre­a­dy in use any­way, e.g. Con­fluence or Notion
  • spe­cia­li­zed tools from appro­pria­te providers

More important than the form is the que­sti­on of how the direc­to­ry can be kept up to date. This requi­res an inter­nal pro­cess, which can vary depen­ding on the size and com­ple­xi­ty of the orga­nizati­on. In many cases, it is suf­fi­ci­ent to issue an ins­truc­tion – in a for­mal direc­ti­ve or even in a short hand­out for employees – that a spe­ci­fic per­son is to be infor­med in the event of new or chan­ged pro­ce­s­sing. In lar­ger com­pa­nies, it is more appro­pria­te to make appro­pria­te addi­ti­ons or adjust­ments to exi­sting pro­ce­s­ses – for exam­p­le, it can make sen­se to link the pro­ce­s­sing direc­to­ry to pro­ce­s­ses that have alre­a­dy been defi­ned and to have employees con­sult the direc­to­ry in the event of adjust­ments or new pro­ce­s­ses so that gaps can be iden­ti­fi­ed and clo­sed. Ran­dom checks by data pro­tec­tion aut­ho­ri­ties are also a pos­si­bi­li­ty – howe­ver, the­se are not expli­cit requi­re­ments, but rather que­sti­ons of a func­tio­ning com­pli­ance orga­nizati­on depen­ding on the company.

SMEs are exempt from the obli­ga­ti­on to keep a pro­ce­s­sing direc­to­ry. Howe­ver, this only applies to SMEs with less than 250 employees (as of Janu­ary 1 in each case). Such SMEs may vol­un­t­a­ri­ly keep a regi­ster, but in prin­ci­ple do not have to do so. It may well make sen­se to keep a direc­to­ry vol­un­t­a­ri­ly, pro­vi­ded that the edits are not so tri­vi­al that they are also so clear.

Howe­ver, such SMEs must also keep a regi­ster if they car­ry out par­ti­cu­lar­ly ris­ky pro­ce­s­sing, i.e. if they exten­si­ve­ly pro­cess par­ti­cu­lar­ly sen­si­ti­ve data (e.g. health data) or if they car­ry out “high-risk pro­fil­ing”. In this case, they do not have to record all but the­se sen­si­ti­ve pro­ce­s­sing ope­ra­ti­ons in a directory. 

  • Checking whe­ther the exemp­ti­on for SMEs applies – if so, whe­ther a direc­to­ry should still be kept
  • Deter­mi­ning the for­mat – simp­ler is usual­ly better
  • Ela­bo­ra­ti­on of a tem­p­la­te and, if neces­sa­ry, a short ins­truc­tion for it
  • Deter­mi­na­ti­on of the pro­ce­du­re for the initi­al fil­ling and sub­se­quent updating of the directory.
  • Recor­ding of the direc­to­ry, i.e. the pro­ce­s­sing acti­vi­ties – this usual­ly requi­res the invol­vement of the busi­ness, HR and IT, e.g. in a workshop


The cur­rent FADP only requi­res expli­cit infor­ma­ti­on about the pro­ce­s­sing of per­so­nal data in excep­tio­nal cases (when par­ti­cu­lar­ly sen­si­ti­ve per­so­nal data such as health data or per­so­na­li­ty pro­files are obtai­ned). In most cases, it is suf­fi­ci­ent if pro­ce­s­sing is self-evident.

This chan­ges with the revi­sed law. Ana­log­ous to the GDPR, the law requi­res infor­ma­ti­on for all pro­ce­s­sing unless an excep­ti­on applies. This even applies to self-evi­dent and tri­vi­al pro­ce­s­sing. This does not help anyo­ne, but a vio­la­ti­on of this obli­ga­ti­on can even be punishable. 

Com­pa­nies should the­r­e­fo­re pro­vi­de infor­ma­ti­on about their pro­ce­s­sing, usual­ly in the form of data pri­va­cy state­ments. The­se are noti­ces or docu­ments that com­ment on data pro­ce­s­sing – they are not part of the con­tract and should not gene­ral­ly be part of GTCs.

Which and how many pri­va­cy state­ments are requi­red depends on the busi­ness model. In most cases, howe­ver, it will be some­thing like the following:

  • a gene­ral pri­va­cy poli­cy pro­vi­ded on the web­site that covers most pro­ce­s­sing, e.g. hand­ling end cus­to­mer data, cus­to­mer and sup­plier cont­act data, mar­ke­ting, working with part­ners, etc;
  • a sepa­ra­te coo­kie noti­ce that explains how per­so­nal data is hand­led via the website(s) and, if appli­ca­ble, apps. It can be part of the gene­ral pri­va­cy state­ment, but a sepa­ra­te state­ment is often more in line with expectations;
  • a pri­va­cy poli­cy for employees. It can also com­ment on job appli­cants, pro­vi­ded that a sepa­ra­te pri­va­cy poli­cy is not used here.

Ano­ther que­sti­on is how data sub­jects (i.e., indi­vi­du­als who­se data is being pro­ce­s­sed) are made awa­re of the appro­pria­te pri­va­cy poli­cy. The­re is no one-size-fits-all solu­ti­on for this – the inter­faces with the data sub­jects are decisi­ve. Howe­ver, it makes sen­se to pro­vi­de information

  • in con­tracts, at least in con­tracts with end cus­to­mers (GTC) and in employment con­tracts or regulations,
  • in the foo­ter of the web­site and in apps,
  • in cor­re­spon­dence with data sub­jects, e.g. in an e‑mail signa­tu­re, invoices, order forms, etc. Here, exi­sting cus­to­mers who­se data was obtai­ned befo­re the new law came into force can and should also be made awa­re of the data pro­tec­tion declaration.

Cons­ents are not fre­quent­ly requi­red under Swiss data pro­tec­tion law.

Howe­ver, con­sent must be con­side­red when par­ti­cu­lar­ly sen­si­ti­ve data (e.g., health data) is pas­sed on and in the case of e‑mail marketing.

  • Ela­bo­ra­ti­on of the pri­va­cy state­ments – for this pur­po­se, samples are available, which are sui­ta­ble as source mate­ri­al with the neces­sa­ry adap­t­ati­ons. A detail­ed sam­ple can be found here, and more pat­terns are available
  • Con­side­ra­ti­ons regar­ding refe­ren­ces to data pro­tec­tion state­ments, e.g. in con­tracts and sam­ple correspondence
  • If neces­sa­ry, con­side­ra­ti­on of adjust­ments to data pro­ce­s­sing, e.g., repla­cing or dis­con­ti­nuing cer­tain ana­ly­sis tools on websites.


The revi­sed DPA requi­res the con­clu­si­on of con­tracts in cer­tain cases. This results from the fact that the DPA distin­gu­is­hes bet­ween dif­fe­rent roles of companies.

The “Respon­si­ble” is the com­pa­ny that pro­ce­s­ses data or has data pro­ce­s­sed in its own inte­rest and that deter­mi­nes this pro­ce­s­sing. For exam­p­le, a com­pa­ny is a con­trol­ler of the pro­ce­s­sing of the data of its employees and its (end) customers.

One “Order pro­ces­sor” also pro­ce­s­ses data, but only as a ser­vice pro­vi­der for a con­trol­ler. A con­tract pro­ces­sor is, for exam­p­le, a hosting ser­vice pro­vi­der or the pro­vi­der of a cloud-based soft­ware solu­ti­on: Here, the con­trol­ler deter­mi­nes the type and man­ner of data pro­ce­s­sing. Howe­ver, some ser­vice pro­vi­ders are also con­trol­lers – when they lar­ge­ly deci­de on the type of data pro­ce­s­sing them­sel­ves. One exam­p­le is a law firm.

Becau­se the­se roles dif­fer so much in pro­ce­s­sing, so do the duties under data pro­tec­tion law. The con­trol­ler must com­ply with the full ran­ge of obli­ga­ti­ons of the DPA (which is why he is also cal­led the “con­trol­ler”). An order pro­ces­sor does not have to and can­not do this to the same ext­ent, becau­se he is con­trol­led to a cer­tain ext­ent by the con­trol­ler – he is, so to speak, his exten­ded arm. 

Howe­ver, this also requi­res that the data con­trol­ler and the data pro­ces­sor regu­la­te their rela­ti­on­ship con­trac­tual­ly. For this pur­po­se, they must con­clude a so-cal­led order pro­ce­s­sing agree­ment – rules, for exam­p­le, on the right of the con­trol­ler to issue ins­truc­tions, his right to check the data pro­ce­s­sing, and the obli­ga­ti­on of the order pro­ces­sor to ensu­re data secu­ri­ty and to dele­te data at the end of his order.

If such a con­tract is miss­ing when pro­ce­s­sing an order, this may be punis­ha­ble under the revi­sed DPA. The con­trol­ler must the­r­e­fo­re ensu­re that he has con­clu­ded or will con­clude such con­tracts. This is usual­ly the case with pro­vi­ders of stan­dard solu­ti­ons – they include such con­tracts in their stan­dard con­tracts. With other pro­vi­ders, howe­ver, they may be missing. 

And it is not uncom­mon for such con­tracts to be miss­ing, espe­ci­al­ly within a group, if a com­pa­ny ope­ra­tes cen­tral ser­vices such as a CRM system within the group. Other points may also need to be regu­la­ted within the group, e.g. the deployment of employees from one com­pa­ny to another.

In addi­ti­on to order pro­ce­s­sing, the­re is also joint respon­si­bi­li­ty when seve­ral com­pa­nies make joint decis­i­ons about pro­ce­s­sing. The con­cept is abun­dant­ly unclear, but within a group, joint respon­si­bi­li­ty is com­mon when mul­ti­ple group com­pa­nies use the same solu­ti­on for employee manage­ment or a CRM, for exam­p­le. Shared respon­si­bi­li­ty is also not uncom­mon in part­ner­ships whe­re data is pro­ce­s­sed for a com­mon product. 

Unli­ke the GDPR, the revi­sed law does not expli­ci­t­ly requi­re a sepa­ra­te agree­ment bet­ween the joint­ly respon­si­ble par­ties. Howe­ver, it makes sen­se, becau­se it is often dif­fi­cult to delinea­te com­pe­ten­ces and respon­si­bi­li­ties here. It should the­r­e­fo­re gene­ral­ly be agreed who will inform the data sub­jects, who will deal with requests for infor­ma­ti­on, who will ensu­re data secu­ri­ty, etc.

An important topic at pre­sent is the trans­fer of per­so­nal data abroad. It may also requi­re the con­clu­si­on or review of con­tracts. Sepa­ra­te infor­ma­ti­on on this sub­ject is pro­vi­ded below.

  • Review of con­trac­tu­al rela­ti­on­ships: Whe­re and for what are ser­vice pro­vi­ders invol­ved? Whe­re are the­re forms of coope­ra­ti­on that repre­sent shared responsibility? 
  • This is to be checked in each case within the group from also for exter­nal partners.
  • Review of exi­sting con­tracts: Do they exist? Are they rea­son­ab­ly up-to-date? Do they alre­a­dy con­tain the neces­sa­ry data pro­tec­tion provisions?
  • Adjust­ment or new con­clu­si­on of con­tracts, inso­far as the requi­red data pro­tec­tion pro­vi­si­ons are miss­ing or insufficient
  • If neces­sa­ry, ela­bo­ra­ti­on of own tem­pla­tes for the abo­ve step
  • For ser­vice pro­vi­ders: Checking whe­ther the requi­red gua­ran­tees are met, espe­ci­al­ly whe­ther data secu­ri­ty is known and suf­fi­ci­ent – if neces­sa­ry, a new check is requi­red here.


Data pro­tec­tion law aims to ensu­re pro­tec­tion. It can­not the­r­e­fo­re per­mit trans­fers to count­ries wit­hout rest­ric­tion if the neces­sa­ry pro­tec­tion is lack­ing the­re. Like the GDPR and the cur­rent DPA, the revi­sed DPA the­r­e­fo­re initi­al­ly only per­mits such trans­fers if the reci­pi­ent sta­te gua­ran­tees ade­qua­te data pro­tec­tion. If data is expor­ted ille­gal­ly, this may be punis­ha­ble under the revi­sed FADP.

Ade­qua­te pro­tec­tion exists for all EEA Sta­tes and a few other sta­tes (the FDPIC main­ta­ins a list of such sta­tes, which are Coun­try listwhich is new­ly listed in the ordi­nan­ce as an annex).

Accor­ding to the FDPIC, fur­ther mea­su­res are curr­ent­ly requi­red for data on legal enti­ties in such count­ries as well. In prac­ti­ce, this is lar­ge­ly and right­ly ignored. 

At other sta­tes such as the USA or India lack an ade­qua­te level of pro­tec­tion. Here, a trans­fer is only per­mis­si­ble if the lack of legal pro­tec­tion is com­pen­sa­ted for by the con­clu­si­on of an ade­qua­te con­tract with the recipient.

The­se are almost always the so-cal­led Stan­dard Con­trac­tu­al Clau­ses or “SCC”, which were drawn up by the EU Commission. 

The FDPIC Has accept­ed this SCC as suf­fi­ci­ent. Howe­ver, it requi­res that they be adapt­ed to Swiss law in some respects.

The­re are also excep­ti­ons – under cer­tain cir­cum­stances, the con­clu­si­on of a con­tract can also be wai­ved for such sta­tes. Howe­ver, the­se are rather rare excep­ti­ons that hard­ly play a role in the con­text of the imple­men­ta­ti­on of the revi­sed DPA.

Com­pa­nies should the­r­e­fo­re check whe­ther they dis­c­lo­se data abroad. This will very often be the case – not only when coope­ra­ting with com­pa­nies abroad, but espe­ci­al­ly with IT ser­vice pro­vi­ders. If the­se ser­vice pro­vi­ders are loca­ted in a coun­try that does not gua­ran­tee ade­qua­te data pro­tec­tion, the con­tracts with them must be checked to see whe­ther they con­tain the neces­sa­ry provisions.

The SCCs men­tio­ned, which are to be con­clu­ded with data reci­pi­en­ts in the USA, for exam­p­le, are just that – con­tracts. Unli­ke local law, they do not bind the aut­ho­ri­ties. If they have too far-rea­ching access rights to trans­mit­ted data, this is pro­ble­ma­tic from the per­spec­ti­ve of the DPA, becau­se the­se rights can hard­ly be limi­t­ed by the SCC.

The Euro­pean Court of Justi­ce has the­r­e­fo­re ruled (in the infa­mous “Schrems II” judgment) that an export­er must not blind­ly rely on the SCC. Rather, he must check the local law, and if this con­veys exce­s­si­ve access rights, he must take fur­ther measures.

Hard­ly any other topic is curr­ent­ly so dis­pu­ted like this. On the one hand, it is unclear whe­ther the export­er can rely on the fact that the local aut­ho­ri­ties will have no inte­rest in the data he trans­mits (which will be true in the vast majo­ri­ty of cases). On the other hand, it is unclear how the risk of access can be coun­te­red at all, becau­se even tech­ni­cal mea­su­res can hard­ly exclude such access in most cases.

In prac­ti­ce, com­pa­nies esti­ma­te the risks of access by the aut­ho­ri­ties to be with a form a, and if the pro­ba­bi­li­ty of access is very low, they have no rea­son to belie­ve that access will occur. In this case, they rely on the SCC. This approach is not legal­ly secu­re, but a rea­sonable alter­na­ti­ve is missing.

  • Inven­to­ry whe­re data is trans­fer­red to sta­tes that do not have ade­qua­te protection
  • Exami­na­ti­on of whe­ther the cor­re­spon­ding dis­clo­sure could be wai­ved or whe­ther a ser­vice pro­vi­der could be repla­ced by a CH/EU provider.
  • Veri­fi­ca­ti­on that an agree­ment exists with the reci­pi­ent in the rele­vant unsafe coun­try that inclu­des SCCs
  • If so, check whe­ther the SCC are up to date and whe­ther they con­tain the neces­sa­ry adap­t­ati­ons to Switz­er­land (e.g. in the form of a stan­dar­di­zed adden­dum, a “Swiss Addendum”).
  • Con­clu­si­on of fur­ther con­tracts (SCC), if applicable

High-risk machi­ning

The law gene­ral­ly fol­lows a risk-based approach. This means that the respon­si­ble par­ties have to adjust their com­pli­ance mea­su­res in accordance with their assess­ment of the risks for tho­se affec­ted. In some cases, howe­ver, the law spe­ci­fi­es hig­her requi­re­ments for par­ti­cu­lar risks. 

Par­ti­cu­lar­ly sen­si­ti­ve per­so­nal data is data that The Law refers to as par­ti­cu­lar­ly sen­si­ti­ve in a blan­ket man­ner. The­se are 

  • Data on reli­gious, ideo­lo­gi­cal, poli­ti­cal or trade uni­on views or activities
  • Health data
  • Pri­va­cy data
  • Data on racial or eth­nic affiliation
  • gene­tic data
  • bio­me­tric data used to iden­ti­fy a person
  • Data on admi­ni­stra­ti­ve and cri­mi­nal pro­se­cu­ti­ons or sanctions
  • Data on social assi­stance measures

In the case of such data, the con­trol­ler must ensu­re that dis­clo­sure to third par­ties is justi­fi­ed, e.g. becau­se it is neces­sa­ry for a con­tract or with consent. 

If con­sent is requi­red – which is rather an excep­ti­on – it must also be explicit.

In some cases, cer­tain addi­tio­nal requi­re­ments depend on whe­ther per­so­nal data is pro­ce­s­sed “exten­si­ve­ly”. What this means is open; the legis­la­tor has not drawn a nume­ri­cal limit. Howe­ver, the pro­ce­s­sing must invol­ve an excep­tio­nal­ly lar­ge amount of data, which is also deli­bera­te­ly desi­gned in this way, i.e. the exten­si­ve pro­ce­s­sing must be part of a plan – usual­ly a busi­ness model.

A “high risk pro­fil­ing” is first a Pro­fil­ingi.e., auto­ma­ted data pro­ce­s­sing that is used for ana­ly­sis or fore­ca­sting pur­po­ses. Examp­les include infor­ma­ti­on on cus­to­mer beha­vi­or based on transactions.

One “high risk” brings pro­fil­ing with it when it leads to a per­so­na­li­ty pro­fi­le, i.e. allo­ws an assess­ment of essen­ti­al aspects of the per­so­na­li­ty. It has not been cla­ri­fi­ed when this is the case. To be on the safe side, it should be assu­med that a par­ti­cu­lar­ly broad data base or a par­ti­cu­lar­ly meaningful pro­fil­ing result may pose a high risk. 

If a con­trol­ler pro­ce­s­ses par­ti­cu­lar­ly sen­si­ti­ve data exten­si­ve­ly and if it car­ri­es out high-risk pro­fil­ing, the cor­re­spon­ding data pro­ce­s­sing must be log­ged. If log­ging is inten­tio­nal­ly omit­ted here, cri­mi­nal lia­bi­li­ty is not com­ple­te­ly ruled out (cf. here).

It may be neces­sa­ry to log the sto­rage, modi­fi­ca­ti­on, rea­ding, dis­clo­sure, dele­ti­on and des­truc­tion of data – rea­ding in par­ti­cu­lar poses a prac­ti­cal problem. 

Logs must also be kept sepa­ra­te from the pro­duc­tion system so that they are pro­tec­ted in the event of an attack on that system. They must be kept for at least one year.

Exten­si­ve pro­ce­s­sing of par­ti­cu­lar­ly sen­si­ti­ve per­so­nal data or high-risk pro­fil­ing not only trig­ger a log­ging obli­ga­ti­on. In addi­ti­on, in the­se cases the data con­trol­ler must Editing regu­la­ti­ons lead. Here, too, the­re may be a cer­tain risk of cri­mi­nal lia­bi­li­ty if such regu­la­ti­ons do not exist. 

A pro­ce­s­sing regu­la­ti­on is some­thing dif­fe­rent from the pro­ce­s­sing direc­to­ry. It invol­ves a kind of Manu­alwhich comm­ents on the inter­nal orga­nizati­on and the archi­tec­tu­re and func­tio­ning of the systems, as well as on the pro­ce­s­sing of data along the life­cy­cle, the gua­ran­tee of data sub­jects’ rights and the tech­ni­cal and orga­nizatio­nal secu­ri­ty measures.

It is suf­fi­ci­ent to refer to exi­sting, other docu­ments, as far as they exist.

  • Checking whe­ther per­so­nal data requi­ring spe­cial pro­tec­tion are pro­ce­s­sed (not ran­dom­ly at the mar­gins, but plan­ned) and how they are pro­ce­s­sed and shared
  • Checking whe­ther the­re is exten­si­ve such pro­ce­s­sing, if applicable
  • Checking whe­ther high-risk pro­fil­ing is car­ri­ed out (by the con­trol­ler or by a processor).
  • If yes: Review of fur­ther mea­su­res; if neces­sa­ry, also con­duct a data pro­tec­tion impact assessment.

More points

In addi­ti­on to the points men­tio­ned, the­re are of cour­se other points to con­sider. Wit­hout clai­ming to be exhaus­ti­ve: two of the most important points are cer­tain­ly data dele­ti­on and data security.

In gene­ral, and alre­a­dy under cur­rent data pro­tec­tion law, data may not be retai­ned for lon­ger than the­re is a legi­ti­ma­te pur­po­se for doing so. 

This con­cerns e.g. 

  • Busi­ness pur­po­ses that requi­re the pro­ce­s­sing of data, e.g. in the employment rela­ti­on­ship or vis-à-vis cus­to­mers and suppliers
  • Busi­ness pur­po­ses that are not man­da­to­ry but legi­ti­ma­te, e.g. sto­ring data for mar­ke­ting pur­po­ses, docu­men­ta­ti­on, com­pi­ling sta­tis­tics, etc. 
  • sta­tu­to­ry reten­ti­on obli­ga­ti­ons, which may also requi­re reten­ti­on of per­so­nal data, e.g. for accoun­ting pur­po­ses, in the tax area and in the employment relationship. 

Howe­ver, if the­re are no lon­ger legi­ti­ma­te rea­sons for sto­ring data and the­re is also no lon­ger a legal obli­ga­ti­on to retain it, per­so­nal data must be dele­ted or anony­mi­zed. Dele­ti­on also has advan­ta­ges – the risks of a secu­ri­ty breach can decrea­se, the duty to inform is brea­ched less quick­ly, and requests for infor­ma­ti­on are easier to ans­wer correctly. 

In simp­ler cir­cum­stances, this dele­ti­on can some­ti­mes be car­ri­ed out manu­al­ly, e.g. in the case of appli­cant dos­siers, records of employees who left the com­pa­ny a long time ago, or in the case of for­mer cus­to­mers if the­re is no lon­ger a sta­tu­te of limitations. 

Howe­ver, manu­al dele­ti­on is error-pro­ne and incom­ple­te. Imple­men­ting auto­ma­ted dele­ti­on rou­ti­nes, howe­ver, can be a deci­dedly chal­len­ging, leng­thy and cost­ly task, espe­ci­al­ly for com­pa­nies who­se com­plex IT has grown organically. 

A rea­sonable midd­le ground – at least to start with – is usual­ly a com­bi­na­ti­on of a reten­ti­on and dele­ti­on direc­ti­ve with appro­pria­te con­fi­gu­ra­ti­on of the appli­ca­ti­ons. If a system can­not be con­fi­gu­red to dele­te data at a spe­ci­fic time, archi­ving can pro­vi­de some substitute. 

The revi­sed law does not tigh­ten the requi­re­ments for data secu­ri­ty in prin­ci­ple, except for the obli­ga­ti­on to report cer­tain secu­ri­ty brea­ches. Cri­mi­nal lia­bi­li­ty can­not be ruled out in the event of cer­tain brea­ches, but this is unli­kely at pre­sent. What is get­ting worse, howe­ver, is the thre­at envi­ron­ment. Attacks such as ran­som­wa­re, CFO Frauds, and others are on the rise, and they are often successful. 

It is the­r­e­fo­re impe­ra­ti­ve that com­pa­nies address the secu­ri­ty of their systems. This will often requi­re the use of exter­nal spe­cia­lists. Often, howe­ver, even simp­ler mea­su­res can bring about a con­sidera­ble increa­se in secu­ri­ty, e.g., a check to see whe­ther access rights still cor­re­spond to the cur­rent roles and func­tions and whe­ther access rights of for­mer employees have been revoked. 

Howe­ver, this is not the end of the sto­ry. Expe­ri­ence shows that it is often employees who are the gate­way to a secu­ri­ty breach. They must the­r­e­fo­re be infor­med and trai­ned, e.g., to be able to reco­gnize phis­hing attacks. 

  • Whe­re out­da­ted data is loca­ted with cer­tain­ty: Start a cle­a­nup (e.g., split fol­ders con­tai­ning old appli­cant files).
  • Cla­ri­fi­ca­ti­on of the essen­ti­al reten­ti­on peri­ods (a mix­tu­re of reten­ti­on obli­ga­ti­ons and limi­ta­ti­on peri­ods), ide­al­ly in a dele­ti­on policy
  • Defi­ni­ti­on of rules for manu­al dele­ti­on (also in the dele­ti­on policy)
  • Con­fi­gu­ra­ti­on of appli­ca­ti­ons for auto­ma­tic dele­ti­on, as far as pos­si­ble and reasonable
  • If the secu­ri­ty mea­su­res are not up to date: cor­re­spon­ding check of own systems and interfaces 
  • Trai­ning of the employees to an appro­pria­te ext­ent and cycle