Imple­men­ta­ti­on of the revi­sed DPA

Sta­tus: 17.07.2022

What is it about?

The Swiss Data Pro­tec­tion Act (DPA) is cur­r­ent­ly under revi­si­on. The revi­sed ver­si­on of the DPA (revFDPA) has been avail­ab­le for some time, the asso­cia­ted ordi­nan­ce is still being fina­li­zed (Draft). Howe­ver, both will most likely come into for­ce on Sep­tem­ber 1, 2023.

The revi­sed law is not an imple­men­ta­ti­on of the GDPR, but stron­gly inspi­red by it. It puts the focus on the fol­lo­wing points:

  • Streng­t­he­ning gover­nan­ceData pro­tec­tion com­pli­an­ce is to be streng­t­he­ned by requi­ring com­pa­nies to ful­fill cer­tain obli­ga­ti­ons with regard to their orga­niz­a­ti­on and docu­men­ta­ti­on. This incre­a­ses the effort requi­red of companies.
  • Streng­t­he­ning trans­pa­ren­cy: Data pro­tec­tion law is based to a signi­fi­cant extent on the per­so­nal respon­si­bi­li­ty of data sub­jects They can only exer­cise this respon­si­bi­li­ty if they under­stand how their data is hand­led. The revDSG the­re­fo­re intro­du­ces a gene­ral duty to pro­vi­de infor­ma­ti­on: Unli­ke today (with excep­ti­ons), under the revDSG com­pa­nies must also pro­vi­de infor­ma­ti­on about tri­vi­al data pro­ces­sing. A bre­ach of this duty may even be punis­ha­ble by law. 
  • Streng­t­he­ning the rights of data sub­jectsThe revDSG the­re­fo­re gives the data sub­jects fur­ther rights to obtain addi­tio­nal infor­ma­ti­on about data pro­ces­sing and to influ­ence it. The right to infor­ma­ti­on, i.e. the right to obtain infor­ma­ti­on from a com­pa­ny about the pro­ces­sing of one’s own per­so­nal data, is also important. This right can be exer­cis­ed at any time and for any rea­son. Pro­vi­ding fal­se infor­ma­ti­on can be punis­ha­ble by law. 
  • Streng­t­he­ning enfor­ce­mentThe FDPIC plays an important role in the enfor­ce­ment of data pro­tec­tion law (he is respon­si­ble for moni­to­ring data pro­ces­sing by pri­va­te com­pa­nies and federal bodies). The revDSG gives him exten­ded possibilities.
  • Deter­rence: Deter­rence through pen­al­ties also ser­ves enfor­ce­ment. The cur­rent DPA pro­vi­des for fines only in excep­tio­nal cases, but only up to CHF 10,000 and without prac­ti­cal enfor­ce­ment. Under the new law, cer­tain inten­tio­nal vio­la­ti­ons can be punis­hed by fines of up to CHF 250,000 (for the respon­si­ble per­sons themselves).

Data pro­tec­tion is not only being streng­t­he­ned and tigh­te­ned by the revi­si­on of data pro­tec­tion law. The expec­ta­ti­ons of custo­mers, inve­stors, aut­ho­ri­ties, part­ners and the public are also chan­ging – while data pro­tec­tion was not a big issue for sta­ke­hol­ders for a long time, out­side regu­la­ted indu­stries, it is now gai­ning a lot of attention. 

A cer­tain level of data pri­va­cy com­pli­an­ce has the­re­fo­re also beco­me part of sta­ke­hol­der manage­ment. Com­pa­nies the­re­fo­re can­not avoid dealing with data pri­va­cy and imple­men­ting the new requi­re­ments appropriately. 


You can also find ans­wers to the most fre­quent­ly asked que­sti­ons about data pro­tec­tion law in our con­ti­nuous­ly updated FAQ.

to the FAQ

Imple­men­ta­ti­on of the revi­sed law

The­re is no one-size-fits-all approach. The struc­tu­re and com­ple­xi­ty of the com­pa­nies, the cri­ti­ca­li­ty and scope of the data they pro­cess, the import­ance of data pro­ces­sing for their busi­ness model, and the expec­ta­ti­ons regar­ding the hand­ling of per­so­nal data are all too different.

In the mean­ti­me, howe­ver, empi­ri­cal values have been built up that pro­vi­de a cer­tain best-prac­ti­ce approach to form. In the fol­lo­wing, we brief­ly pre­sent this approach in the sen­se of an aid, espe­cial­ly for SMEs, with refe­ren­ces to the legal frame­work and sug­ge­sti­ons for con­cre­te mea­su­res. Espe­cial­ly for lar­ge com­pa­nies and com­pa­nies in a com­plex or regu­la­ted envi­ron­ment, nume­rous other que­sti­ons will ari­se. But as we all know, even the lon­gest jour­ney begins with the first step. 


You can also down­load the­se inst­ruc­tions as a PDF.


It goes without say­ing that the fol­lo­wing pre­sen­ta­ti­on is neit­her com­ple­te nor sui­ta­ble for all cases – com­pa­nies must deal with data pro­tec­tion and can out­sour­ce much, but not ever­ything. Accord­in­gly, the fol­lo­wing infor­ma­ti­on is not legal advice. They are out­side the scope of a man­da­te, and we do not pro­vi­de any war­ran­ty or assu­me any liability. 

Recom­men­da­ti­ons for action

The imple­men­ta­ti­on of the revi­sed law requi­res a cer­tain amount of plan­ning. But with a sen­se of pro­por­ti­on – exten­si­ve pro­ject plan­ning has not pro­ved very suc­cess­ful, at least not for SMEs. In most cases, the essen­ti­al tasks can be defi­ned qui­te quick­ly. A detail­ed gap ana­ly­sis can be use­ful, but is often more sui­ta­ble for a later point in time. 

Howe­ver, it is important that a pro­ject – even a small one – is sup­por­ted by manage­ment. This requi­res mea­sura­ble suc­cess, and this also argues for not let­ting plan­ning get out of hand.

Howe­ver, the effort requi­red for imple­men­ta­ti­on depends on the com­ple­xi­ty and size of the com­pa­ny, as well as on the requi­re­ments and expec­ta­ti­ons of the sta­ke­hol­ders, i.e., for examp­le, the custo­mers and the public and, in the case of regu­la­ted com­pa­nies, also the regu­la­tor (FINMA, the FOPH, etc.). And the more sen­si­ti­ve the data pro­ces­sed and the grea­ter its weight in the busi­ness model, the hig­her the risks for the com­pa­ny. A refe­rence to Euro­pe also plays a role – all or cer­tain data pro­ces­sing may also have to com­ply with the GDPR. 

In the case of star­tups, a pos­si­ble exit also plays a role – here, the com­pa­ny should not com­ple­te­ly fail due diligence. 

Final­ly, a group of com­pa­nies plays a major role. An SME that is part of a group with a for­eign con­nec­tion may have to imple­ment the GDPR (alt­hough this is rare­ly requi­red or pos­si­ble at 100%), but can ide­al­ly also draw on exi­sting foun­da­ti­ons from the group.


  • Make reflec­tions on the abo­ve points
  • Talk with manage­ment about imple­men­ting the revi­sed data pro­tec­tion law
  • Con­si­der who will mana­ge the pro­ject intern­al­ly and who will be respon­si­ble for it 
  • If necessa­ry, purcha­se mis­sing expertise
  • Plan resour­ces, ask exter­nal pro­vi­ders for quo­tes if necessary
  • Set sche­du­le

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

Data pro­tec­tion instruction

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

  • A poli­cy defi­nes the orga­niz­a­ti­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 hel­ps to com­mu­ni­ca­te the company’s com­mit­ment to appro­pria­te data pro­tec­tion internally.
  • It is fore­see­ab­le that com­pa­nies will be asked more often for a poli­cy by custo­mers and pos­si­b­ly in the event of an acquisition.
  • If a data bre­ach hap­pens, a poli­cy hel­ps 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­re­fo­re con­si­der, 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 avail­ab­le intern­al­ly and what should be purcha­sed. A que­sti­on of orga­niz­a­ti­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 use­ful, espe­cial­ly for com­pa­nies with sen­si­ti­ve data and tho­se with spe­cial custo­mer expectations.

Other poli­ci­es and instructions

Whe­ther fur­ther poli­ci­es, direc­ti­ves or gui­d­ance are requi­red depends on the com­ple­xi­ty of the orga­niz­a­ti­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­ted peri­od of time is avail­ab­le for this. Second, mis­hand­ling secu­ri­ty brea­ches leads to repu­ta­tio­nal risks. Com­pa­nies must the­re­fo­re con­si­der how they can ensu­re that secu­ri­ty brea­ches are dis­co­ve­r­ed quick­ly and taken up or esca­la­ted internally.

Also use­ful can be a gene­ral Inst­ruc­tion its - in the sen­se of the simp­lest and most con­cre­te inst­ruc­tions pos­si­ble – on how to deal with unusu­al situa­tions in gene­ral, e.g., a secu­ri­ty bre­ach, a requ­est for infor­ma­ti­on, or even the use of new software.


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

The revi­sed law requi­res that com­pa­nies keep a regi­ster of their pro­ces­sing acti­vi­ties – a regi­ster in text form (unless the revi­sed ordi­nan­ce spe­ci­fies other­wi­se), e.g. as Excel, in Con­flu­ence, in ano­t­her tool or with spe­cia­li­zed soft­ware. In this direc­to­ry, cer­tain infor­ma­ti­on must be recor­ded for indi­vi­du­al types of pro­ces­sing acti­vi­ties (e.g. “app­li­cant manage­ment”, “sala­ry pay­ments”, “news­let­ter dis­patch”, etc.). 

This app­lies not only to so-cal­led respon­si­ble par­ties, but also to con­tract pro­ces­sors such as IT ser­vice providers.

Howe­ver, com­pa­nies are likely to be exempt from this obli­ga­ti­on if they employ fewer than 250 peop­le. Such com­pa­nies must con­si­der whe­ther they want to keep a pro­ces­sing direc­to­ry volun­ta­ri­ly. The argu­ment in favor is that it is seen as part of good com­pli­an­ce, which pro­vi­des argu­ments in the event of a vio­la­ti­on. Against this is the fact that the ongo­ing main­ten­an­ce of the direc­to­ry can be cost­ly and that, from a prac­ti­cal point of view, it is often of litt­le use to the com­pa­ny if it is not qua­li­ta­tively good and embed­ded in processes.


  • Checking whe­ther the excep­ti­on from the obli­ga­ti­on to keep a pro­ces­sing direc­to­ry applies
  • Deter­mi­na­ti­on of the form in which a pro­ces­sing direc­to­ry is to be kept
  • Defi­ni­ti­on of a tem­pla­te (this can be a simp­le Excel with one row per machi­ning activity).
  • Con­si­de­ra­ti­on of the pro­ce­du­re for the initi­al sur­vey and later the ongo­ing upda­ting of the inventory.
  • Gui­d­ance to the enti­ties con­cer­ned (notes, examp­les of coverage, etc.), if applicable. 
  • Record­ing of machi­ning activities

The cur­rent FADP only requi­res expli­cit infor­ma­ti­on about the pro­ces­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­ces­sing is self-evident.

This chan­ges with the revi­sed law. Ana­lo­gous to the GDPR, the law requi­res infor­ma­ti­on for all pro­ces­sing unless an excep­ti­on app­lies. This even app­lies to self-evi­dent and tri­vi­al pro­ces­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­re­fo­re pro­vi­de infor­ma­ti­on about their pro­ces­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­ces­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­ces­sing, e.g. hand­ling end custo­mer data, custo­mer and sup­plier con­ta­ct data, mar­ke­ting, working with part­ners, etc;
  • a sepa­ra­te coo­kie noti­ce that exp­lains how per­so­nal data is hand­led via the website(s) and, if app­li­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 app­li­cants, pro­vi­ded that a sepa­ra­te pri­va­cy poli­cy is not used here.

Ano­t­her que­sti­on is how data sub­jects (i.e., indi­vi­du­als who­se data is being pro­ces­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 custo­mers (GTC) and in employ­ment 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 custo­mers who­se data was obtai­ned befo­re the new law came into for­ce can and should also be made awa­re of the data pro­tec­tion declaration.

Cons­ents, on the other hand, are not often requi­red under Swiss data pro­tec­tion law. Howe­ver, con­sent must be con­si­de­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, sam­ples are avail­ab­le, which are sui­ta­ble as source mate­ri­al with the necessa­ry adap­t­ati­ons. A detail­ed sam­ple can be found here, and more pat­terns are available
  • Con­si­de­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 necessa­ry, con­si­de­ra­ti­on of adjust­ments to data pro­ces­sing, e.g., repla­cing or dis­con­ti­nuing cer­tain ana­ly­sis tools on websites.

It may also be use­ful to think about other infor­ma­ti­on requi­re­ments, e.g. an imprint for online offers.

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­guis­hes bet­ween dif­fe­rent roles of companies: 
  • Respon­si­ble: This is the com­pa­ny that pro­ces­ses data or has data pro­ces­sed in its own inte­rest and that deter­mi­nes this pro­ces­sing. For examp­le, a com­pa­ny is a con­trol­ler of the pro­ces­sing of the data of its employees and its (end) customers.
  • Order pro­ces­sorAn order pro­ces­sor also pro­ces­ses data, but only as a ser­vice pro­vi­der for a con­trol­ler. An order pro­ces­sor is, for examp­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­ces­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­ces­sing them­sel­ves. One examp­le is a law firm.

Order pro­ces­sing

Becau­se the­se roles dif­fer so much in pro­ces­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 under 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 extent, becau­se he is con­trol­led to a cer­tain extent 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­ons­hip con­trac­tual­ly. For this pur­po­se, they must con­clu­de a so-cal­led order pro­ces­sing agree­ment – rules, for examp­le, on the right of the con­trol­ler to issue inst­ruc­tions, his right to check the data pro­ces­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 mis­sing when pro­ces­sing an order, this may be punis­ha­ble under the revi­sed DPA. The con­trol­ler must the­re­fo­re ensu­re that he has con­clu­ded or will con­clu­de such con­tracts. This is usual­ly the case with pro­vi­ders of stan­dard solu­ti­ons – they inclu­de 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 mis­sing, espe­cial­ly wit­hin a group, if a com­pa­ny ope­ra­tes cen­tral ser­vices such as a CRM system wit­hin the group. Other points may also need to be regu­la­ted wit­hin the group, e.g. the deploy­ment of employees from one com­pa­ny to another.

Shared respon­si­bi­li­ty

In addi­ti­on to order pro­ces­sing, the­re is also joint respon­si­bi­li­ty when several com­pa­nies make joint deci­si­ons about pro­ces­sing. The con­cept is abundant­ly unclear, but wit­hin 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 examp­le. Shared respon­si­bi­li­ty is also not uncom­mon in part­nerships whe­re data is pro­ces­sed for a com­mon product.  Unli­ke the GDPR, the revi­sed law does not expli­ci­tly 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 deli­ne­a­te com­pe­ten­ces and respon­si­bi­li­ties here. It should the­re­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. 

Trans­mis­si­on abroad

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.


  • Com­pi­la­ti­on of exi­sting con­tracts with ser­vice pro­vi­ders or custo­mers, if data is pro­ces­sed in the process
  • Checking the cor­re­spon­ding roles
  • Review of con­tracts for the requi­red mini­mum con­tent under data pro­tec­tion law
  • If necessa­ry, deve­lo­p­ment of a stan­dard agree­ment for con­tract pro­ces­sing, espe­cial­ly by com­pa­nies that have such a strong posi­ti­on that they can use their own con­tracts with ser­vice pro­vi­ders, and with ser­vice pro­vi­ders that have to or want to offer such con­tracts to custo­mers (espe­cial­ly IT ser­vice providers)
  • Con­clu­si­on of appro­pria­te con­tracts with sup­pliers, custo­mers and part­ners, if necessary

Trans­mis­si­on abroad

Data pro­tec­tion law aims to ensu­re pro­tec­tion. It can­not the­re­fo­re per­mit trans­fers to coun­tries without restric­tion if the necessa­ry pro­tec­tion is lacking the­re. Like the GDPR and the cur­rent DPA, the revi­sed DPA the­re­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.

This is the case with all EEA Sta­tes and a few other sta­tes (the FDPIC main­tains a list of such sta­tes, which have Coun­try list). Howe­ver, accord­ing to the FDPIC, fur­ther mea­su­res are requi­red for data on legal enti­ties in such coun­tries as well (which is lar­ge­ly igno­red in practice). 

At other sta­tes such as the USA or India, a trans­fer is only per­mit­ted if the lack of legal pro­tec­tion is com­pen­sa­ted for by the con­clu­si­on of a suf­fi­ci­ent con­tract with the reci­pi­ent. 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 accep­ted this SCC as suf­fi­ci­ent. Howe­ver, it requi­res that they be adap­ted to Swiss law in some respects.

The­re are also excep­ti­ons – under cer­tain cir­cum­stan­ces, 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­re­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­cial­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 necessa­ry provisions.

Schrems II”

The SCCs men­tio­ned, which are to be con­clu­ded with data reci­pi­ents in the USA, for examp­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­ted by the SCC.

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

Hard­ly any other topic is cur­r­ent­ly so dis­puted like this. On the one hand, it is unclear whe­ther the exporter 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 exclu­de 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­son­ab­le 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 this is the case, check whe­ther the SCC up to date are and whe­ther they are necessa­ry adjust­ments to Switz­er­land con­tain (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

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

Data dele­ti­on

In gene­ral, and alrea­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­ces­sing of data, e.g. in the employ­ment rela­ti­ons­hip or vis-à-vis custo­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 employ­ment 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 made anony­mous. Dele­ti­on also has advan­ta­ges – the risks of a secu­ri­ty bre­ach can decre­a­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­stan­ces, this dele­ti­on can some­ti­mes be car­ri­ed out manu­al­ly, e.g. in the case of app­li­cant dos­siers, records of employees who left the com­pa­ny a long time ago, or in the case of for­mer custo­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­ded­ly chal­len­ging, leng­thy and cost­ly task, espe­cial­ly for com­pa­nies who­se com­plex IT has grown organically. 

A rea­son­ab­le midd­le ground – at least to begin 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 app­li­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. 


  • Whe­re out­da­ted data is loca­ted with cer­tain­ty: Start a cleanup (e.g., split fol­ders con­tai­ning old app­li­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 app­li­ca­ti­ons for auto­ma­tic dele­ti­on, as far as pos­si­ble and reasonable

Data secu­ri­ty

The revi­sed law does not tigh­ten the requi­re­ments for data secu­ri­ty in princip­le, 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­re­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­si­derable incre­a­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 bre­ach. They must the­re­fo­re be infor­med and trai­ned, e.g., to be able to reco­gni­ze phis­hing attacks. 


  • 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 extent and cycle