Data protection law requires a number of measures. Some of these become necessary during ongoing operations, such as a data breach notification or a response to a request for information. However, this may require some preparation, which is why companies – at least larger ones – need to proactively address these issues. Other measures must be taken in advance, regardless of an individual event.
Data protection law therefore requires “implementation,” i.e., certain measures to avoid the risk of a data breach, in the interest of the data subjects as well as the company and its employees and management bodies.
How to implement this depends very much on the individual case. Very small companies can get by with a privacy policy, large companies have to do a lot more.
You will therefore find instructions for implementation here:
We provide guides and checklists for the implementation of the nDSG, for SMEs (under Swiss law) and for larger companies (also with a view to the GDPR).
Not only large companies have to implement the new data protection law, but also SMEs. There are only marginal exceptions for SMEs in the nDSG – most of the requirements also apply to them. However, the expectations for the standard of implementation are different.
We have therefore prepared a checklist for SMEs. It is designed for simpler circumstances and private companies (not for public bodies). It does not claim to be complete and does not constitute legal advice.
In the case of larger or internationally active companies, it can often be assumed that the GDPR will be implemented, insofar as this is possible. Accordingly, such companies ask themselves less which requirements of the new DPA and more where differences exist between the GDPR and the nDSG. For this purpose, we provide a guide:
You can also find documents under Downloads.
Do I fall under the GDPR? The GDPR (General Data Protection Regulation) applies in the territory of the EU and the rest of the EEA. However, it may also apply to companies in Switzerland – under certain conditions. If you are not sure whether this also applies to you, you can use our Do self test.
How should I proceed with the implementation? The implementation of the revised DPA can, but need not, be costly. Depending on the size of the company, the complexity of its processes and the scope and sensitivity of its data and processing, the effort required varies considerably. In extreme cases, a data protection statement on the website is sufficient. In most cases, however, a number of additional points need to be taken into account. The following list is accordingly not exhaustive, but not everything is mandatory either. The todos therefore also contain points of note and considerations that a company should make.
This section contains some general information on data protection law. It can also be skipped – it is not necessary for understanding the further explanations.
Data protection law is the set of legal norms that regulate the handling of personal data and the related rights and obligations.
First of all, a distinction can be made between formal and substantive data protection law: Formal data protection law is the data protection laws of the Confederation, the cantons and the municipalities with the corresponding implementing provisions. The substantive data protection laws are these and all other provisions that regulate personal data. They are scattered in various enactments, e.g. in social security law, financial market law, energy law, telecommunications law, etc. Frequent subjects of regulation are secrecy provisions (e.g. Art. 33 ATSG, Art. 86 BVG, Art. 47 BankG, Art. 69 FINIG, Art. 321 StGB, Art. 43 FMG etc.) and, in the case of federal bodies, legal bases for the processing of personal data and their disclosure (e.g. Art. 84 f. KVG, Art. 4 BÜPF, Art. 112a DBG etc.).
A distinction can also be made between data protection law in the narrower and broader sense. Data protection law in the narrower sense specifically regulates the handling of personal data, while data protection law in the broader sense regulates the handling of certain data that can be or usually is personal (such as secrecy provisions).
Finally, data protection law can be understood as part of data law. Data law includes all provisions that regulate the handling of data, even if they are not personal (“data” understood as information that undergoes some embodiment, even if only as a sound – the law captures information only when it is embodied, it cannot capture the pure information).
Within data protection law, a distinction can then be made between levels – this could be described as an onion model. At the core are the material requirements for handling personal data, above all the processing principles. In addition, there is a further layer of obligations of the data controller that do not directly relate to the handling of personal data, but are intended to safeguard it. These include, for example, the obligation to maintain a processing directory, to conduct a data protection impact assessment or to report a security breach. A third layer is formed by data subject rights, which are intended to enable the data subject to influence data processing. The fourth layer consists of the FDPIC’s supervisory powers and sanctions.
In Switzerland:
In Europe:
The law on the protection of secrets protects secrets. These include the professional secrets of, for example, doctors, psychologists, lawyers, bank employees, employees of financial institutions, etc. Professional secrets may also apply under cantonal law, and also under professional and ethical law. Related to professional secrecy is also official secrecy.
In addition, there are trade secrets, which are protected, for example, by criminal law and the law on fair trading.
However, there is no general law on the protection of secrets. There are basic structures, in particular similarities in the concept of a secret and the facts of disclosure. However, there are nuances depending on the secret. For example, the intent to keep a secret, which determines the scope of protection for most secrets, may differ depending on the type of secret.
Yes, many, and more and more. Both areas are converging to a certain extent. This is mainly due to the fact that both areas have become much more important in the course of digitization and are being discussed in correspondingly greater detail. These in-depth analyses increasingly bring to light commonalities, such as the importance of the expectations of the protected persons, i.e., the data subjects and the secrecy masters.
In addition, there is greater control of data protection law through criminal sanctions. This strengthens criminal data protection law, and especially in situations where data is disclosed to third parties. It is no coincidence that the revDSG provides for penalties precisely in such situations, e.g., order processing, disclosure abroad, and disclosure of secret personal data (although not exclusively in these cases). This sanctioning of disclosure brings data protection law closer to secrecy law, even though there remain fundamental differences between the two.
Personal data is any information that relates to an identified or identifiable individual (although today’s DPA also covers information that relates to a legal entity, unlike the GDPR and also the revDSG).
A person is identifiable if his or her identity is clear from the data record itself (e.g., “on Tuesday, Ms. Müller ate with Mr. Peters at Restaurant X”). The question of when and by whom a person is identifiable gives rise to much more discussion. In any case, this is the case when someone who has access to a datum can assign it to a person because he or she has the necessary additional information (“Employee 123452” is a personal datum for the HR department, but not necessarily for an outsider.
The main point of discussion is whether identifiability is only to be assumed if someone with access to the date can infer a person (“relative approach”) or already if any third party could do so (“absolute approach”). In Switzerland, according to the Logistep ruling of the Federal Supreme Court the relative approach. In Europe, according to the Breyer decision of the ECJ same, but the requirements for determinability are set quite low.
Also discussed is whether identification requires knowledge of a name or other common identifier, or whether it is sufficient that a person – even if unknown – can be distinguished from all others (“Singularization”). European authorities seem to be increasingly turn to the concept of singularization, ultimately for purely protective considerations and therefore as a matter of policy rather than law.
No personal data is data that has been anonymized.
The FADP and – with certain amendments – also the revDSG consider certain types of personal data to be particularly sensitive. These data are given special protection in certain respects. For example, under the current FADP, explicit information must already be provided when such data is obtained. And the disclosure of particularly sensitive personal data to third parties must be justified, i.e. in principle it is considered to be infringing. There are further consequences of classifying personal data as requiring special protection – if such data is processed on the basis of consent, this can only be given explicitly; if the processing is extensive, a data protection impact assessment must be carried out; and if such data is processed for non-personal purposes, e.g. statistics, special requirements apply. In the case of federal bodies, the processing of data requiring special protection also requires a legal basis in a law in the formal sense, unless an exception applies.
Personal data that is particularly worthy of protection includes data about religious, ideological, political or trade union views or activities (e.g., payments to a religious community, information about attendance at a trade union event), health, privacy (e.g., sexual orientation), race (e.g., information about ethnicity), biometric data (e.g., a facial scan for access), and data about social assistance measures or administrative or criminal prosecutions and sanctions.
However, the fact that certain categories of data are generally classified as requiring special protection contradicts the risk-based approach, which refers to the concrete rather than an abstract risk. It would also not be practicable to consider all data with remotely or potentially particularly protected content as requiring special protection. A photo of someone wearing glasses is therefore not considered a health datum, and a regionally assignable name is not considered a datum about ethnicity.
The starting point is the concept of personal data. Information is personal if it relates to a specific or identifiable person. A data item is “anonymous” if it has no personal reference because it was never personal or because the personal reference no longer exists. “Anonymized” is a data item that had a reference to a person, but for which the reference to a person was deliberately removed.
This means that the requirements for anonymization are not higher than, conversely, the requirements for personal reference.
If a date has been anonymized, it is no longer a personal date. Data protection law therefore no longer applies to this date. Under data protection law, the processing of this date is therefore no longer restricted.
It also follows that anonymization has the same effect under data protection law as deletion. For if data protection law does not apply to anonymous data, it cannot demand its deletion either.
Pseudonymization means that the reference to a person in a personal data is indirect – it exists, but the reference to a person does not result from the data itself (i.e. not “Ms. Meyerhans”), but only from additional information (i.e. “employee 68796”, where a separate table assigns the number 68796 to Ms. Meyerhans).
Pseudonymization is achieved when this assignment is kept separate from the pseudonymized data itself, i.e., more precisely, when the office, person or department that works with the pseudonymized data does not have access to the corresponding assignment. A certain degree of organizational and informational separation is therefore required.
Pseudonymization is first of all a security measure. It does not mean that the person responsible who has carried out pseudonymization in his organization no longer processes personal data – the date is pseudonymized, not anonymized. However, it increases the protection of the data in question. It can therefore lead to compliance with the principle of data security, but also to the fact that an overriding interest in the processing can rather be affirmed.
In the case of disclosure of a pseudonymous datum, the relative approach must be remembered when determining the reference to a person. Whether a data item is personal is determined from the perspective of the person who has access to this data item or is responsible for its processing. This has the following effect: If person A discloses a pseudonymized datum that has a personal reference for him to person B, who cannot associate this datum with a person (because he lacks the association that person A has but does not disclose to person B), this does not constitute disclosure of a personal datum. Person A is not subject to data protection law for this disclosure, and neither is Person B for its handling of the pseudonymous, but for it anonymous, data. This must be the case – if person B were subject to data protection law, the absolute rather than the relative approach would apply.
This means, for example, that a doctor in Switzerland can send a blood sample that has only been individualized by a barcode to a laboratory in the USA without the restrictions on foreign disclosure applying. However, if he receives the evaluation result back, this constitutes data acquisition for him.
Of course, security measures must still be taken, including an agreement with the recipient that the recipient will only process the data received for the intended purpose and will treat it confidentially.
The Federal Supreme Court was in Logistep judgment stricter – in such a case, data protection law applies not only to the recipient, but also to the transmitting entity, for which the transmitted data has no personal reference. We consider this ruling to be inconclusive and inapplicable on this point.
“Processing” is an extremely broad term. Any handling of personal data is processing, even its anonymization or deletion. At most, it is open whether the mere viewing of a personal data constitutes processing.
Data protection law recognizes different roles depending on the influence on a particular data processing. Determining the roles of the parties involved is always the starting point for an examination under data protection law.
The “responsible party” is the company (usually a company; it can also be an individual) that decisively determines the data processing. This is determined by two criteria: The controller initiates the data processing, i.e. he sets the reason that it takes place in its concrete form in the first place, and thus also what purpose it serves. And he determines the essential framework conditions of the processing, i.e. which data are processed by which persons and for how long, and to whom they are disclosed if necessary.
A data controller is, for example, a company for processing the personal data of its employees, or a company for its own direct marketing, but also a federal body to which a statutory task is assigned.
A controller remains responsible even if it outsources data processing to a service provider. It may even be the case that he neither has nor knows the processed data himself – even then a company may be responsible, provided that it decisively determines the data processing of a third party.
Several companies can share the role of a controller – in this case they are “jointly responsible persons”. This is the case when they jointly determine the purposes of a processing operation and also its essential framework conditions. However, the exact criteria are difficult to define. This is due, on the one hand, to the lack of clear statements by the European authorities and, on the other hand, to three rulings by the ECJ, in which joint responsibility was assumed on a case-by-case basis, although it is difficult to identify a common thread.
However, one can essentially distinguish two constellations of shared responsibility:
Joint responsibility often exists when several companies use the same system for similar processing and therefore jointly engage a service provider. Particularly in a group relationship, this is obvious in the case of jointly used group services, e.g. joint management of employee data or a joint CRM database.
Shared responsibility may also exist when a controller processes data and discloses it to another controller, doing so in its own interest and knowing for what purposes and how it will use that data.
In practice, joint responsibilities are increasingly assumed when several companies work together in partnership and both have a significant influence on the processing.
Swiss data protection law does not explicitly require that jointly responsible parties conclude a contract, unlike the GDPR requires in most cases. Therefore, an unnoticed joint responsibility does not necessarily constitute a breach. However, it makes sense that when processing operations of several companies are intermingled, a regulation is made as to who fulfills which obligations under data protection law, e.g., who informs data subjects about the processing, who ensures the security of jointly used IT systems, and who deals with inquiries from data subjects.
By the way, such regulations are not only useful in the case of jointly responsible persons, but often also when several responsible persons work together independently.
An order processor is a company (or person) that processes data but does not determine the specific processing. This applies in particular – but not only – to IT service providers. For example, a hosting service provider is an order processor, as is a cloud provider or the operator of a SaaS solution. The narrower the purpose of the SaaS solution, the more influence the operator has on the type of data processing. However, it does so generically through the system design and not in relation to concrete, individual data; the user of the solution determines this. Therefore, the SaaS provider remains an order processor.
However, not all service providers are also order processors. Some service providers process personal data for the fulfillment of the order, but determine largely freely. An example is a law firm that conducts proceedings for a client. It is a contractor, but it determines itself which data it needs for this purpose. Rule of thumb: A service provider is a commissioned processor if the object of the service is primarily the processing of personal data. He is a controller if his service is of a different nature and he processes personal data only as a secondary consequence of this service.
Examples can be found, among others, in a List of the Bavarian State Office for Data Protection.
You will find further notes on order processing under the corresponding heading.
The revised DSG and the regulation (FDPO) enter into force on September 1, 2023. The Federal Council still barely in August 2022 the revDSG and the revised VDSG – new “DSV” – with a one-year informal transition period to September 1, 2023 in force.
Yes, because it makes data protection law more formalistic to a certain extent, because it tightens data protection law in general, and because it introduces new sanctions.
However, this is not the only reason why it is important. The expectations of customers, investors, authorities, partners and the public are also changing – while data protection was not a big issue for stakeholders for a long time, outside regulated industries, it is now gaining a lot of attention.
Companies can therefore not avoid dealing with data protection and an appropriate implementation of the new requirements.
Our contributions to the revision can be found here.
Yes. The revised DPA provides for measures and processes that many companies do not have or have only inadequately. Unregulated larger companies that operate only or predominantly in Switzerland are particularly challenged. Where the GDPR has already been implemented – to the extent that this is possible at all – implementation is easier, but certain work will also be required here.
Notes on implementation can be found here.
You can our contributions to the revision read. You can also read our Subscribe to newsletter.
Helpful information can also be found in the Federal Council’s message on the draft of the revDSG, e.g. here or here. And a comprehensive account you will find by David Rosenthal.
“GDPR” stands for “General Data Protection Regulation”. This is a regulation that governs the handling of personal data and is applicable throughout the EU and the rest of the EEA, including Liechtenstein, Iceland and Norway.
The GDPR is mostly stricter than the Swiss GDPR, and partly very detail-oriented and formalistic.
It may also be applicable to companies in Switzerland. Whether this also applies to you, you can find out here.
Yes and no. It is clear that data protection law was hardly enforced for a long time. This was even more true in Switzerland than in Europe. Tightening up made perfect sense.
On the other hand, the GDPR has major flaws. In parts, it is unworldly, and in many points it is formalistic. However, this is not only due to the GDPR, but also to its interpretation by data protection supervisory authorities, which often tend to interpret the GDPR very strictly. This harms the acceptance of data protection law. It is also not justified because there are various fundamental rights that need to be weighed. The protection of data subjects is not an absolute concern. There is also, for example, economic freedom. Unfortunately, this is often forgotten.
This is often a difficult question to answer. It is likely that certain processing operations fall under the GDPR if you can answer yes to any of the following questions:
If you answer yes to any question, you should check the applicability of the GDPR more closely. If not, it is unlikely that you are covered by the GDPR.
But: Switzerland has its own rules that can lead to applicability of the GDPR (in the “IPRG”). If you process personal data of persons residing in the EEA territory, these persons can usually sue before a Swiss court and demand that their claims be judged according to the law in their home country. The court would then not consider the above questions, but only ask whether you could expect to process personal data in the EEA. If so, it would apply the plaintiff’s home law, and that may be the GDPR. So if you employ cross-border workers, they could make a request for information, and if you don’t answer it to the GDPR standard, those cross-border workers could sue you in Switzerland at your place of business and have claims assessed under the GDPR. However, we are only aware of one case so far where a lawsuit was filed in Switzerland on the basis of the GDPR (unsuccessfully).
Incidentally, there are cases in which the GDPR must or should be complied with, even if a company is not itself covered by the GDPR. This applies in particular to group companies, if the group wants to comply with the GDPR as a general standard, and IT service providers, whose customers in turn must comply with the GDPR and therefore demand the same from their service provider.
Compliance with the GDPR can also be part of a company’s positioning, as part of sustainability (as “corporate digital responsibility”) and trustworthy dealings with end customers.
The GDPR provides for the role of the “data protection officer” (often abbreviated as DPO after the English “data protection officer”) to monitor compliance with the GDPR and to support the controller or processor. The revDSG takes up this idea and recognizes the “data protection advisor” (DPO).
DPOs and DPOs are intended to be independent entities within the organization of the Company. As employees, they are subject to the instructions of the company, but not with regard to their function as DPO and DPO. The company may therefore not dictate to them which processing operations they review or how they assess compliance with data protection law.
To ensure that their independence is not compromised, they must not have roles or tasks where they themselves would decide on data processing. They may therefore be based in Legal Services or Compliance, or form a separate unit, or even work in IT, but not as heads of such functions, including as heads of Marketing.
In addition, the DPO and DPO are contact persons for data subjects and authorities. Their contact details must therefore be published, e.g. in a privacy statement.
The GDPR provides for the role of the “data protection officer” (often abbreviated as DPO after the English “data protection officer”) to monitor compliance with the GDPR and to support the controller or processor. The revDSG takes up this idea and recognizes the “data protection advisor” (DPO).
DPOs and DPOs are intended to be independent entities within the organization of the Company. As employees, they are subject to the instructions of the company, but not with regard to their function as DPO and DPO. The company may therefore not dictate to them which processing operations they review or how they assess compliance with data protection law.
To ensure that their independence is not compromised, they must not have roles or tasks where they themselves would decide on data processing. They may therefore be based in Legal Services or Compliance, or form a separate unit, or even work in IT, but not as heads of such functions, including as heads of Marketing.
In addition, the DPO and DPO are contact persons for data subjects and authorities. Their contact details must therefore be published, e.g. in a privacy statement.
A machining directory is an inventory of the various machining activities.
Controllers must record their processing activities in accordance with the revDSG as well as the DSGVO, in each case indicating
Order processors must also maintain a processing directory, but with fewer content requirements.
Processing directories must be kept up to date, which usually requires internal specifications or processes.
Every responsible person and every order processor must keep a processing directory.
However, there is the “SME exception”. The revDSG requires the Federal Council to create an exception for companies with fewer than 250 employees, subject to high risk. The draft VDSG therefore provides that data controllers and order processors do not have to keep a processing directory, provided that
In the case of these risks, the corresponding processing operations – but only these – must be recorded in a directory.
Federal bodies – including, for example, pension funds and organizations under private law that fulfill a federal task – must maintain a processing directory. They must also report it to the FDPIC and for this purpose must provide a Open user account. However, one can also send the directory to the FDPIC in this way. The directories of the federal bodies are published.
Data protection law generally follows a risk-based approach. This means that the controller and the order processor must align their measures for compliance with data protection law with the risks for the data subjects – the higher these risks, the higher the requirements for protecting the data subjects, e.g., through stronger security measures.
More generally, this requires companies to assess the risks of their data processing operations, and they must proactively ensure compliance with data protection law (this is what the principle of “privacy by design” means).
If they determine that certain data processing operations are likely to be particularly risky, they must conduct a data protection impact assessment (DPIA). This applies under the revDSG as well as under the GDPR.
A DSFA is therefore nothing more than this – a risk assessment. The risks must be assessed as they present themselves ex ante, the so-called gross risks. Risk-reducing measures must then be taken into account, and in the end the remaining risk, the net risk. All of this must be documented, and if a DPO or data protection advisor has been appointed, they must be involved.
If, exceptionally, it becomes apparent that the net risks are still high, this must be reported to the competent data protection authority. In Switzerland, this is the FDPIC. However, such a notification obligation does not apply if an independent data protection advisor has been appointed and was involved in the DSFA.
According to both the FADP – and the revDSG – and the GDPR, certain principles must be observed for any processing of personal data. These are the principles of transparency, purpose limitation, proportionality, data accuracy and data security. However, data security is no longer a processing principle under the revDSG, or at least not a typical one, after the provision on personality infringement no longer refers to data security. In addition, there is the principle of good faith.
The relationship between the principles is not very clear. The principle of good faith is rather a catch-all principle. The three interrelated principles of transparency, purpose limitation and proportionality are decisive:
The point of reference for processing in each case is its purpose. Proportionality is measured against this purpose, because processing that is suitable and necessary for the purpose of the processing is proportionate in the broader sense. The purpose limitation also refers – obviously – to the purpose.
The responsible party is free to set this purpose within the framework of the broader legal system. He is not limited in this by the FADP – the economic freedom applies, subject to the violation of a behavioral norm, e.g. from criminal law (the FDPIC sometimes forgets this when he is of the opinion that a data processing should not be – then he summarily calls it disproportionate, without taking into account that the controller may have set the purpose broadly).
The controller therefore sets the purpose, and does so through transparency: the processing purpose is the purpose that the controller communicates or that is obvious (i.e., recognizable from the circumstances). The bottom line, then, is that the controller sets the purpose, must abide by it, and may process data only as necessary for the purpose. This in itself is the core of substantive data protection law.
If one wishes, further rules can be seen as processing principles, such as the prohibition on disclosing personal data requiring special protection and, today, personality profiles to third parties or the prohibition on processing personal data against the expressed will of the person concerned. The fundamental freedom to process published data can also be described as a processing principle.
Transparency ultimately means that the data subject at least has the possibility to know a data processing and its purpose. This may require information, but it is sufficient if the processing is evident from the circumstances, i.e. obvious. Surprisingly, the revised FADP no longer explicitly mentions this principle, but it still applies.
However, what must be transparent in concrete terms, i.e. which circumstances of processing – e.g. also disclosure to third parties – is open; this can only be answered in individual cases. Transparency can then be supplemented by a separate duty to provide information (see there).
Purpose limitation is in itself an outgrowth of the transparency principle. It requires that data be processed only as necessary for the (transparent) purpose. Misappropriation is therefore prohibited, at least without the new purpose being transparent in its turn and in time. However, there are subordinate secondary purposes that do not yet meet the threshold of misappropriation. The revised DPA clarifies this by stating purposes that are compatible with the original purpose in addition to the original purpose.
The FADP, like the revDSG, does not recognize any fundamental prohibition of data processing, unlike the GDPR. Therefore, data processing does not have to be justified in principle. This also applies to the processing of personal data requiring special protection, today to the processing of personality profiles and, according to the revDSG, to profiling, even high-risk profiling. It is therefore wrong for the FDPIC to want to permit processing of particularly sensitive personal data only with consent. However, if a processing principle is violated, the corresponding processing is only permitted if this violation is justified.
One does not have to and cannot justify a processing, but only a violation of a processing principle. The FADP, as well as the revised FADP, provides for three grounds for justification:
In itself, nothing new. The principle of privacy by design only means that compliance with data protection law must be ensured proactively, i.e., already when processing is planned. As a result, an application must be able, for example, to delete data or assign access rights on a role-based basis.
The GDPR and the revDSG now explicitly provide for this principle. Under the revDSG, however, it has only one effect: if a controller violates data protection law, it cannot justify this with constraints (e.g., the excessive effort required to rewrite an application to make it deletable), provided it could have countered this constraint with timely planning. After all, a transitional regulation applies to existing processing under certain conditions.
Not necessarily according to the current DPA. At present, information is only required if processing is not self-evident or if particularly sensitive personal data or personality profiles are obtained (and of course if a special legal regulation such as Art. 3 VVG requires information about data processing).
According to the revDSG and the DSGVO, this is different. Here, there is basically a duty to inform about all data processing, unless an exception is applicable.
There are exceptions to the general duty to inform. The following exceptions are relevant, according to the revDSG:
The GDPR largely leaves the regulation of exceptions to the Member States, which is why the applicable local law must be consulted.
The revDSG requires information on the following:
The GDPR is somewhat stricter – additional information must be provided on the following points:
According to the GDPR, not all countries have to be named for this, but only countries outside the EEA.
Additional information requirements may apply depending on the circumstances:
Data protection law does not specify exactly how information must be provided. Data protection declarations are common, but information can also be included in GTCs, provided it is clear what is part of the contract and what is (data protection) information, even if this is often not sensible.
One can also inform in the context of a consent form, or by a notice on a website that collects data, or by a separate letter, etc. It is also possible to provide information verbally, e.g. in a telephone announcement.
The only decisive factor is that the person concerned must be able to take note of and understand the information in good time.
It is also possible to get information from someone else. This is often necessary. For example, if a bank customer discloses information about an authorized representative or a beneficial owner of assets, often only he or she – and not the bank – can inform. In this case, the bank can agree with the customer that the latter informs the other persons. In fact, the customer must do so, because he or she is also responsible for disclosing this data to the bank.
It depends on the business and especially on the interaction with data subjects. Companies usually try not to have too many privacy statements because they all need to be managed and updated. The following is common:
In addition, further privacy statements may be useful, depending on the case, especially if certain processing is not without sensitivity, but only affects a smaller, delimited group of people. Here, the relevant information is often better covered in a specialized, smaller privacy statement instead of an extensive general privacy statement.
No. A privacy policy is not part of the contract, but information. Consent to the data protection declaration is not necessary and should also be avoided. Otherwise, there is a risk that the data processing is based on consent – if it is revoked, the corresponding processing could therefore become inadmissible.
It is also not mandatory that the data subject confirms having read the privacy statement. It is sufficient if the data controller can prove that the data subject was able to take note of the privacy policy in a reasonable manner.
This has not been fully clarified. In Switzerland, the general practice is that information can be provided on the Internet because the person concerned can reasonably be expected to visit an Internet site. Finally, federal laws are also binding in the version published on the Internet – so even the legislator assumes that the Internet will be used. The fact that this does not apply to everyone is clear, but not a counterargument; there are always groups of people who cannot use a certain format (e.g. the visually impaired).
However, this is only possible if it is or should be clear to the persons concerned, that a controller processes personal data from them, e.g. because they have a contract with the controller – otherwise they do not know that they can consult information on data protection on the controller’s website. In the case of unrecognizable processing, the location of the privacy statement(s) should therefore be actively indicated, e.g., on the Internet (e.g., on a notice, in an e‑mail signature, in an invoice, etc.).
In Switzerland, it is generally assumed that a simple reference to the privacy policy is sufficient, with an indication of the link. A QR code or certain minimum processing details are not required. It is sufficient, for example, to state “Information on our handling of personal data can be found at www.xyz.ch”.
With the GDPR, the practice is stricter. Here, at least certain basic information is required where reference is made to the privacy policy on the Internet.
Data protection law requires the data controller to comply with various obligations. Nevertheless, it assumes that data subjects have a great deal of responsibility in the processing of their data. To this end, data protection law provides them with a number of instruments with which they can influence this processing – these are the data subject rights.
Data subjects first have the right to be informed about the processing of their data, because if they do not know about this processing, they cannot exercise any other rights.
The most important right of data subjects, apart from the right to information, is the right of access. This allows them to request further information from the data controller about the processing of their data. Under the revDSG and the GDPR, they can also request a machine-readable copy of certain data – the idea is that this will make it easier for them to switch between providers, even though this is unlikely to prove effective.
Subsequently, the data subjects can influence this processing. They can object to it in part or in full (although the revDSG and the GDPR differ greatly here), and they can also demand that inaccurate data be corrected.
Finally, they can revoke consents, and they can complain to the competent authority.
According to the GDPR, data subjects must be informed about these rights. According to the revDSG, this is not mandatory, but it is common.
You will find information on this under “Terms”.
It depends:
Yes and no. The revDSG as well as the GDPR (and the current GDPR) privilege order processing, but in different respects. The GDPR requires a legal basis for any processing because any processing is generally prohibited. “Privileging” in this context means, above all, that disclosure to the order processor does not require a separate legal basis. This is different under the DPA and the revDSG – processing is permitted provided it complies with the processing principles. In this respect, the privilege is less important. In the case of particularly sensitive personal data, however, it means that disclosure to the processor is permissible without a justification.
This privilege follows from the fact that the order processor is, to a certain extent, the extended arm of the controller and is counted as part of his sphere under data protection law. However, this requires that the controller and the processor conclude a contract that meets certain requirements.
Order processors often have an interest in using certain data from their customers, the data controllers, for their own purposes – for example, because they are using a form of machine learning and want to use order data as training data, or because they want to store order data for their own retention purposes (even though retention rules will rarely apply to order data).
It is not uncommon to allow contract processors to do some processing for their own purposes, often without a more detailed legal analysis. Strictly speaking, however, some questions arise. The order processor is a controller in such a constellation. To the appropriate extent, therefore, the privilege does not apply, and disclosure to the order processor as a controller may be subject to transparency requirements, as the case may be. If the GDPR applies, this disclosure also requires a legal basis, which must be checked and also stated in a data protection declaration. Further processing by the order processor – now as the controller – also requires a legal basis and information that the order processor must take care of, which can be demanding in practical implementation.
In contrast, there is no use of order data if the order processor uses data about contact persons of the responsible party for its own contract management, CRM or invoicing. Here, the responsible party is a data controller. One can therefore ask whether the standard contractual clauses for data controllers (i.e., Module 1 today) should not always be used for a data processor in a country without an adequate level of protection, although this is rarely implemented in practice.
Data protection law approaches the issue of data security from different starting points:
Data protection law does not specify the level of protection to be achieved. It only states that this must be appropriate to the risks for the data subjects. The current VDSG and, similarly, the draft of the revised VDSG at least specify that the type and circumstances of the data processing, the risks for data subjects, the state of the art and mplementation costs must be taken into account. Depending on the industry, however, special requirements may apply, and likewise for public bodies.
One can concretize the requirements for data security by asking about specific risks, or more precisely, about typical threat scenarios. The security measures must counter these scenarios. This in turn results in so-called protection goals. They are not a comprehensive representation of data security, but as a typical orientation they help in the examination and evaluation of security measures.
The draft of the revised VDSG provides for the following protection goals:
You can also look at data security differently, more from the result and less from the risks. Data security should ensure three points in particular:
After the English “Confidentiality, Integrity” and “Availabilty” is therefore also spoken of “CIA”.
Data protection law describes security measures as “technical and organizational measures”, often abbreviated as “TOMs”.
Technical measures are measures that are implemented technically, e.g. password protection or transport encryption. Organizational measures start with people, e.g. through a dual control principle, clean desk instructions, contracts, controls or training. Technical measures tend to be stronger.
Which security measures are required in each case is a question of the circumstances, e.g. the system of data processing, the risks and the measures that are factually in question. The GDPR does not exhaustively list the following measures, some of which are, however, protection goals rather than measures:
The FDPIC, in its somewhat dated Guide to technical and organizational measures Examples listed (which may or may not be required depending on circumstances).
Specific security measures are also specified in industry-specific regulations, e.g., for the credit card industry in the Payment Card Industry Data Security Standard (PCI DSS), for banks and securities firms in the Circular on Operational Risks, in the guidelines of the Bankers Association for Data Leakage Prevention and the recommendations for Business Continuity Management, and for the federal government in the forthcoming Information Security Act.
The current DSG understands the principle of data security more broadly and sees it accordingly violated by any unauthorized processing. The revDSG and the GDPR are narrower: the data security principle only concerns actual security.
A security breach is defined accordingly, in the revDSG as well as in the DSGVO. It consists in each case in the fact that
A security breach does not include unauthorized processing by the responsible party, e.g., failure to delete or unauthorized change of purpose.
The current FADP does not provide for an explicit obligation to report security breaches to the FDPIC or the data subjects. In exceptional cases, however, such an obligation may arise from general principles.
However, the GDPR recognizes notification obligations, and the revDSG also introduces such obligations.
Reporting obligations can also arise from industry-specific regulations. However, these are based less on the violation of the protection of personal data than on incidents that are relevant in the industry in question. One example is the obligation to report incidents relevant to supervision to FINMA pursuant to Art. 29 FINMASA.
Under the revDSG, data controllers must notify the FDPIC of a security breach if it is “likely to result in a high risk” to data subjects. This is where the revDSG differs from the GDPR – under the GDPR, all security breaches that lead to a risk must be reported.
You can also report security breaches to the FDPIC voluntarily. As a rule, this is not advisable.
According to the revDSG, the controller must inform the data subjects about a security breach – with regard to their data – if it is necessary to protect the data subject. This may be the case, for example, if access data to an account has been stolen and the data subject may use the same access data elsewhere or may only be able to block the affected account himself.
Also to report security breaches when requested by the FDPIC (but not necessarily as he requests).
In principle, no. Legal entities within a group are treated in the same way as unrelated companies. Disclosure between group companies is therefore not privileged.
However, certain facilitations do exist:
If personal data is disclosed to third parties – i.e. other responsible parties – the disclosing company loses the right to invoke its own overriding interests against a request for information. The same applies to the corresponding exception to the duty to inform. According to the revised Data Protection Act, however, this consequence does not apply in each case if the receiving responsible party belongs to the same group as the disclosing responsible party.
The risk of intra-group disclosure may be lower. Accordingly, disclosure may be more justified (and under the GDPR, the chance of legitimizing disclosure with a legitimate interest increases).
Factually, of course, there may be further relief:
With unified management, data protection law can be implemented more easily or more efficiently overall.
Intra-Group framework agreements facilitate disclosure.
A DPO or data protection advisor may be designated for several Group companies under certain conditions.
However, there are also factual complications and risks:
The risk of a lack of demarcation between the companies increases, e.g. unnoticed joint responsibilities, unnoticed commissioned processing or unnoticed transfers abroad.
A corporate headquarters can attempt to impose the GDPR as a standard on the entire group – even for Switzerland – in an undifferentiated manner.
Employees may work for several Group companies. This makes it difficult to delineate responsibilities, which can make it considerably more difficult to respond to a request for information, for example.
Unnoticed labor hire may occur.
It may result in monetary benefits between Group companies not being offset correctly, which may lead to negative tax consequences.
Since data protection law largely lacks a corporate group privilege, corporate groups do not regulate their data flows any differently than unaffiliated companies, e.g., through order processing agreements or the conclusion of the standard contractual clauses.
However, these contracts can be standardized, e.g., through a group-wide framework agreement. These contracts are often referred to as “Intra-Group Data Transfer Agreement” (“IGDTA”) or – if they are somewhat broader – as “Intragroup Data Protection Agreement (“IDPA”).
This refers to group-wide framework agreements regulating internal data flows. They often regulate the following points:
As far as we know, not freely available on the Internet. However, we usually work with templates that can be adapted to the specific case.
You will find various Links to data protection law.
You can also find further information at rosenthal.ch and a self-test at the Vischer Privacy Score.