Even with the best possible security, data breaches cannot be completely avoided. However, data breaches are often the result of a vulnerable and outdated security regime or system weaknesses. Prevention through the adoption of appropriate security measures is therefore key to preventing vulnerabilities in systems or insufficient security that can potentially lead to a data breach.
\n\n
\n\n
Data and risk mapping: Only if organisations know what types of data breaches could occur and understand the characteristics of these breaches, can they take the necessary TOMs to reduce the risk of a successful attack or breach.
\n\n
\n\n
The basic prerequisite is first that companies know what types of data and personal data they process, who the data subjects are and their locations, where the data is stored and who should have access to it. This knowledge requires the mapping of all data systems, products and services that process personal data and their classification. Organisations should then assess the risk level to their organisation and to individuals in the case of a data breach, as well as identifying the possible types of attacks and based on that understanding and the level of risk, take the appropriate TOMs to mitigate the consequences in the case of a data breach.
\n\n
\n\n
Implementation of TOMs: Based on the risk level, such TOMs may include a state-of-the-art encryption of the data at rest and a separate back-up of the data to help mitigate the consequences of a successful ransomware attack, or the loss or theft of a device with personal data. In addition to a state-of-the-art encryption, measures such as key management, regular updates of systems, use of strong authentication methods like two-factor authentication, firewalls, etc. may help to mitigate the consequences of data exfiltration. Regular awareness campaigns and training to staff on security aspects, instructions on how to use company devices and information as well as the implementation of technical measures and controls may help to prevent human errors.
\n\n
\n\n
Applicable laws and competent authorities: Organisations should assess which data protection and other laws apply to them in case of an incident and data breach. This should include assessing whether an entity is covered by NIS2. Based on this knowledge, organisations should determine which authorities to notify in case of a NIS2 incident and data breach. This insight will help save valuable time in the event of an incident.
\n\n
\n\n
External resources and insurance coverage: Besides the implementation of robust TOMs, organisations should evaluate in advance what type of external expertise is required in the case of a data breach and ensure that such expertise is available on short notice, which may require the negotiation of frame contracts in advance. Additionally, organisations may consider holding an insurance policy for data breaches.
\n\n
\n\n
Data breach response plan: Finally, organisations should deploy a data breach response plan that sets out procedures, modalities, and responsibilities in the event the organisation experiences a data breach (or a suspected data breach, i.e., a security incident) to respond to a data breach in a timely and efficient manner.
\n\n
\n\n
4.2 Response – Implement a data breach response plan
\n\n
\n\n
4.2.1. Why a data breach response plan?
\n\n
\n\n
Due to the usually very short timelines for reporting a data breach to the data protection authorities and individuals (at least in some countries, including the EU), it is critical that each organisation handling personal data put in place a documented data breach response plan. Implementing such a plan can help organisations in: (a) mitigating the impact on the organisation and affected individuals, and the costs resulting from the data breach; (b) meeting their data security obligations; (c) protecting important business assets, including personal data of their employees and clients and the company’s reputation; (d) dealing with negative media or stakeholder attention; and (e) instilling public confidence and trust in the organisation’s capacity to protect personal data entrusted to the company by properly responding to a data breach.
\n\n
\n\n
The data breach response plan should be aligned with other plans as appropriate, such as existing security incident response, disaster recovery, business continuity, or contingency plans. This approach can ensure effective management with clear responsibilities, avoid duplication, and leverage synergies.
\n\n
\n\n
4.2.2. Content of a data breach response plan
\n\n
\n\n
A data breach response plan should establish the rules and processes on how to handle a data breach in compliance with internal standards and legal and regulatory requirements. It should outline what a data breach is, possibly providing some concrete examples tailored to the specific organisation, allocate the roles and responsibilities for detecting, responding, and documenting a data breach, describe the process for handling a data breach, from detection to notification and risk mitigation, and specify the obligations towards third parties processing the data on their behalf.
\n\n
\n\n
4.2.3. Establishment of an incident response team
\n\n
\n\n
While in small organisations the managing director or owner is often the person who deals with a data breach, usually with external assistance, establishing an incident response team has proven effective in mid-sized and larger organisations. The purpose of such a team is to ensure that in the event of a data breach, the relevant functions are immediately engaged, and data breaches can be promptly addressed, the risks assessed, and any required notifications made in a timely manner.
\n\n
\n\n
\n\n
The composition of the team will depend on the organisation and the nature of the business, but will typically require different skill sets, which can be ensured by involving internal functions and external legal, data forensics, and media management experts. Organisations should assess what type of external expertise will be needed in the event of a data breach in advance, and ensure that this expertise is available on short notice. The organisation should maintain and regularly update a current list of team members, including their roles, responsibilities, and contact details, as well as the contact information of their delegates. Team members should receive regular training including on compliance with the applicable laws and notification requirements and participate in mock exercises. The response team should consist of a core team that includes, at a minimum, the data protection officer and the information security officer, and should be extended to include other functions such as human resources, research and development, or communications, as well as outside legal counsel and forensic analysts, depending on the severity and nature of the incident.
\n\n
\n\n
The incident response team should be responsible for managing the overall data breach, investigating, and reviewing the circumstances of the data breach and the facts of the case, engaging relevant functions and external experts, assessing the level of risk, determining remediation actions, determining the need for internal escalation, and notifying data protection authorities and individuals. The data breach response plan should identify the specific responsibilities of each member of the response team.
\n\n
\n\n
Furthermore, corporate management bodies should oversee, approve and be trained on the cybersecurity measures taken by the organisation, according to the new requirements of the NIS2 Directive.
\n\n
\n\n
4.2.4. Process for responding to a data breach
\n\n
\n\n
The process for responding to a data breach typically includes different steps, starting from the detection of the data breach and reporting to the immediate containment, investigation of the data breach, risk evaluation, internal escalation, notification, and documentation.
\n\n
\n\n\n\n
\n\n
Detection and reporting: Each employee should understand how to recognise a potential data breach and know how to report such a data breach or suspected data breach (security incident) to the incident response team, who will immediately perform a preliminary evaluation and determine whether the incident qualifies as a data breach.
\n\n
\n\n
Containment: Once the source of the data breach has been identified, the data breach should be contained immediately to prevent further exposure of personal data, for example, and depending on the concrete impact, by remediating identified vulnerabilities in systems, recovering records, shutting down the compromised system, restricting access to data, recalling sent emails containing personal data that were inadvertently attached to the email or sent to the wrong recipients, or deleting them from the accounts of the unintended recipients.
\n\n
\n\n
Investigation: The incident response team should investigate and document the facts and circumstances of the data breach, including: the causes of the data breach such as any vulnerabilities in the computer systems; the nature of the data breach (breach of confidentiality, availability, or integrity); the nature, scope, and sensitivity of the personal data involved, as well as the origin of the data; the type, number, and location of data subjects; applicable data protection laws; and notification requirements.
\n\n
\n\n
Risk evaluation: Based on the outcome of the investigation and taking into account the type of personal data compromised, the extent of the data breach, and the type and number of individuals affected by the data breach, the incident response team must assess the level of risk of the data breach to the rights and freedoms of data subjects and the organisation. To assess the level of risk, they must determine the impact that the data breach could have on the rights and freedoms of individuals and the likelihood that this impact will actually occur. The greater the impact and the greater the likelihood, the higher the risk. Essential elements for determining the impact on individuals are the ease of their identification (how easily can an individual be identified from the compromised data?) and the severity (how much harm can be caused by the data breach?). Key elements in determining the likelihood of the identified impact actually occurring are the potential vulnerabilities due to the lack of appropriate TOMs and the ability to exploit those vulnerabilities or the intent of the individuals accessing or possessing the data (was the data exfiltrated by a hacker with malicious intent or sent by an employee to the wrong recipient in the same organisation by mistake?).
\n\n
\n\n
Escalation: The data breach response plan should define the internal escalation process, which should depend on the severity and extent of the breach, the level of risk identified, and the requirement for notification.
\n\n
\n\n
Notification: The incident response team determines, based on all the facts and the risk evaluation, whether the data breach must be notified to local data protection authorities and affected individuals, and if so, when, where, and how. At the same time, the incident response team should address notification of other authorities, such as those responsible for NIS2 incidents, if the organisation is subject to NIS2 and it is a significant incident. The data breach response plan should identify which function is responsible for notifying the authorities and individuals. In general, the notification of a data breach is assigned to the data protection officer. Notification of an incident subject to other laws, such as NIS2, may be assigned to other functions. It is recommended that notifications be coordinated. It is also advantageous if scenarios requiring notification have already been worked through and documented.
\n\n
\n\n
Documentation: Any data breach, whether notified to data protection authorities and/or individuals or not, should be documented, including the facts and circumstances of the breach, its effects, and the corrective actions taken and planned to prevent future similar data breaches, the risk evaluation, and the appropriate justification for the decisions made with respect to the notification to data protection authorities and individuals.
\n\n
\n\n
4.2.5. Considerations in implementing a data breach response plan globally
\n\n
\n\n
Given the large number of countries with data breach notification requirements, globally operating companies are faced with the challenge of finding solutions that are as comprehensive and uniform as possible in order to, on the one hand, deal with data breaches uniformly and efficiently across the organisation and, on the other hand, take into account the specifics of the individual countries.
\n\n
\n\n
When implementing a data breach response plan globally, companies must take into account locally applicable data privacy and security laws, as well as notification requirements and modalities, languages, and cross-border data transfer restrictions, and align the data breach response plan accordingly. Companies should also decide what the internal reporting channel for discovered data breaches should be. Depending on their organisational set-up, they could establish one global reporting channel or separate regional or local reporting channels. Also, organisations must determine where data breaches should be documented (in a centralised system or locally), and whether a global incident response team should be deployed around the world, or regional/local response teams be established.
\n\n
\n\n
4.3 Improvement – Address security gaps to prevent future (similar) data breaches – regularly re-evaluate the data breach response plan to increase effectiveness
\n\n
\n\n
The third phase of the data breach response strategy consists of improvements in two respects: addressing identified vulnerabilities to prevent future similar data breaches; and increasing the effectiveness of the data breach response plan.
\n\n
\n\n
Address any identified security vulnerabilities to prevent future similar data breaches. Once the notification and documentation process is complete, the incident response team should determine and implement appropriate measures to prevent future similar data breaches. Depending on the concrete type of data breach and the root cause, such measures may include, for example, conducting regular security audits and reviewing and updating policies and procedures in light of lessons learned, reviewing and amending contracts with third parties to ensure the appropriate handling of data breaches. Other measures may include, for example, restricting the downloading of personal data to mobile devices without adequate security protection, such as state-of-the-art encryption or the establishment of separate backups of specific data sets, and regular training for the business units concerned.
\n\n
\n\n
Periodically re-evaluate the data breach response plan to increase its effectiveness, taking into account changes in applicable data protection laws, best practices and internal business requirements.
\n\n
\n\n
5 Conclusion
\n\n
\n\n
Data security is one of the essential obligations of any organisation that processes personal data. A breach of the confidentiality, integrity or availability of data can have negative consequences not only for the individuals concerned, but also for the responsible organisation. A data breach can result in notification obligations, significant costs to contain the data breach and repair the damage caused by the breach, as well as loss of stakeholder trust, reputational damage, and business disruption. Investing in data security to prevent data breaches, such as those caused by cyberattacks or human error, and being prepared to respond in the event of a data breach, is therefore essential for any organisation to meet its legal obligations and avoid negative consequences for itself and the individuals affected.
\n\n
\n","datum":"21.07.2023","teasertext":"
Laws around the world impose strict data security obligations on organisations that process personal data, and in some cases require them to report data breaches to data protection authorities and individuals affected by the data breach. This article elaborates on what constitutes a personal data breach and what a data breach prevention and response strategy might look like. In particular, it considers the incident notification requirements under the new EU Directive on measures for a high common level of cybersecurity across the Union (NIS2), effective as of 16 January 2023, which significantly expands the categories of entities within the scope. With such an extension, a wide range of entities that did not fall under the former NIS Directive, will be subject to additional incident notifications.
\n","preview":"","datei":[],"linkextern":""},{"id":173,"title":"Get ready for the new Swiss Data Protection Act","slug":"bereiten-sie-sich-auf-das-neue-schweizer-datenschutzgesetz-vor","link":"/en/news-knowledge/bereiten-sie-sich-auf-das-neue-schweizer-datenschutzgesetz-vor","titel":"Get ready for the new Swiss Data Protection Act","text":"
This webinar on Mondaq, that builds on the previous webinar \"The new Swiss Data Protection Act - What you need to know\", specifically targets the preparatory measures for the implementation of the new law, which will come into force on September 1, 2023.
\n\n
\n\n
Specific topics such as the scope of application of the Federal Data Protection Act (also for companies abroad), the requirements for appointing a representative in Switzerland, the specific requirements for the duty to inform data subjects, the record of processing activities, data security requirements, data breach handling and notification, data protection impact assessment, outsourcing and international data transfer are highlighted and provided with practical implementation tips.
\n\n
\n\n
To download the webinar in PDF format, please click here.
\n\n
\n\n
To view the webinar directly on the Mondaq website, please click here.
\n","datum":"08.06.2023","teasertext":"
This webinar on Mondaq, that builds on the previous webinar \"The new Swiss Data Protection Act - What you need to know\", specifically targets the preparatory measures for the implementation of the new law, which will come into force on September 1, 2023.
\n","preview":"","datei":[],"linkextern":""},{"id":172,"title":"New Swiss Data Protection Act - the most important changes for companies","slug":"neues-schweizer-datenschutzgesetz-die-wichtigsten-neuerungen-fuer-unternehmen","link":"/en/news-knowledge/neues-schweizer-datenschutzgesetz-die-wichtigsten-neuerungen-fuer-unternehmen","titel":"New Swiss Data Protection Act - the most important changes for companies","text":"
To download the article in PDF format, please click here.
The Swiss Parliament passed the revised Data Protection Act (nFADP) on 25 September 2020.2 The nFADP as well as the new Data Protection Ordinance (DPO) and the new Ordinance on Data Protection Certification (DPCO) will enter into force on 1 September 2023.
\n\n
\n\n
The aim of the revision was, on the one hand, to strengthen data protection by improving the transparency of data processing and the control options of data subjects over their data and, at the same time, to increase the sense of responsibility of those responsible.3 Another important goal was to maintain Switzerland's competitiveness and to enable Switzerland to ratify the Council of Europe's revised data protection convention ETS 108, to align with the EU's General Data Protection Regulation (GDPR) and thus to continue to be recognized as a third country with an adequate level of data protection.
\n\n
\n\n
At a Glance
\n\n
\n\n
\n
The basic concept of “permission of data processing subject to prohibition” (i.e. prohibition if the data processing leads to an “unlawful violation of the personality of a person”) remains unchanged. Consent to the processing of personal data is still generally not required, even for profiling and the processing of sensitive personal data. The principles of data processing also remain largely unchanged.
\n
\n\n
\n\n
\n
Legal entities are no longer protected; only natural persons are protected under the nFADP.
\n
\n\n
\n\n
\n
The scope of the nFADP covers actions that have an effect in Switzerland, even if they are initiated abroad.
\n
\n\n
\n\n
\n
The definitions of “controller of the data file”, “personality profile” and “data file” have been deleted; the definitions of “profiling”, “high-risk profiling” and “data security breach” have been introduced. Genetic and biometric data as well as data on ethnic origin, are considered to be sensitive personal data under the nFADP.
\n
\n\n
\n\n
\n
The concepts of “privacy by design” and “privacy by default” are now enshrined in the law, as is already the case in the EU General Data Protection Regulation (GDPR).
\n
\n\n
\n\n
\n
Data security is the responsibility of the controller as well as the processor. A risk-based approach is introduced.
\n
\n\n
\n\n
\n
Data processing by processors remains largely unchanged. Under the nFADP, the processor may only assign the processing to a sub-processor with prior authorisation by the controller.
\n
\n\n
\n\n
\n
The appointment of a data protection advisor remains voluntary. It can be an advantage when it comes to performing a data protection impact assessment.
\n
\n\n
\n\n
\n
Under the nFADP, both the controller and the processor must keep an inventory of their processing activities. This inventory does not have to be declared to the Federal Data Protection and Information Commissioner (FDPIC) (up to now, the controller generally needed to declare data files to the FDPIC).
\n
\n\n
\n\n
\n
Companies based outside Switzerland who process personal data of persons in Switzerland will have to designate a representative in Switzerland.
\n
\n\n
\n\n
\n
The requirements for cross-border disclosure of personal data remain largely unchanged. Under the nFADP, the Federal Council bindingly determines whether the legislation of a state or an international body guarantees an adequate level of protection.
\n
\n\n
\n\n
\n
The duty of information has been extended to the collection of all kinds of personal data (until now it was only applicable to the collection of sensitive personal data and personality profiles) and also includes automated individual decision-making.
\n
\n\n
\n\n
\n
Under the nFADP, the controller must carry out a data protection impact assessment if the intended data processing may lead to a high risk for the data subject.
\n
\n\n
\n\n
\n
In the future, the controller must notify the FDPIC of data security breaches.
\n
\n\n
\n\n
\n
Under the nFADP, data subjects have the right to data portability.
\n
\n\n
\n\n
\n
The powers of the FDPIC are extended. In the future, the FDPIC can order a number of administrative measures.
\n
\n\n
\n\n
\n
The criminal provisions have been significantly tightened, with fines of up to 250 000 Swiss francs for private persons (i.e. not companies!), but only for violations in certain areas, in particular for the breach of obligations to provide access and information and to cooperate, for the violation of duties of diligence with respect to the requirements for cross-border disclosure of personal data, the appointment of a processor and for failure to comply with the minimum data security requirements. Fines are only applicable to violations that result from a wilful act and are in most cases, only imposed upon the filing of a complaint.
The nFADP aims to protect personal privacy and the fundamental rights of natural persons whose personal data is processed. Under the current law, legal entities are also protected. By cancelling the protection of legal entities, the nFADP aligns with the GDPR, that also protects only natural persons.
\n\n
\n\n
The nFADP also regulates the territorial scope. According to art. 3, the law applies to actions that have an effect in Switzerland, even if they are initiated abroad.
Various definitions are now aligned with the GDPR.
\n\n
\n\n
The term \"personal data\" is limited to all information that relates to an identified or identifiable natural person. In future, only natural persons about whom personal data is processed will be considered «data subjects”.
\n\n
\n\n
Concerning the identifiability, the “relative approach” is maintained. According to the Federal Council Dispatch on the Federal Act on the complete revision of the Federal Act on Data Protection and the modification of other federal enactments6, the mere theoretical possibility to identify a person is, as under current law, not sufficient to presume that a person is identifiable. The Federal Council already stipulated in its Dispatch to the FADP of 19887 that no identifiability is given if “the effort necessary to identify a data subject is so great that, according to general life experience, it cannot be expected that any interested person should undertake such effort”. “It must rather be considered what means can be reasonably employed to identify a person and be determined whether the employment of such means is reasonable under the given circumstances, for instance in terms of time and cost. In doing so, the technologies available at the time of processing and their further development must be taken into account. The law does not apply to anonymised data, if a re-identification by third parties is impossible (the data has been completely and irreversibly anonymised) or if a re-identification would only be possible with a great effort that no interested person would undertake. The same applies to pseudonymised data».8
\n\n
\n\n
The definition of “sensitive personal data” has been extended to include “data on ethnic origin”, “genetic data” and “biometric data which uniquely identifies a natural person”. While it is made clear that biometric data must uniquely identify a natural person, the same addition has been deleted for genetic data in the procedure of the resolution of differences.
\n\n
\n\n
The definitions of “controller of the data file”, “personality profile” and “data file” have been deleted. The following new definitions have been introduced:
\n\n
\n\n
\n
“controller”: a private person or federal body that alone or jointly with others decides on the purpose and the means of the processing.
\n
\n\n
\n\n
\n
“processor”: a private person or federal body that processes personal data on behalf of the controller.
\n
\n\n
\n\n
\n
“profiling”: any form of automated processing of personal data consisting in the use of such data to evaluate certain personal aspects relating to a natural person, in particular, to analyse or predict aspects relating to that natural person's performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, whereabouts or movements.
\n
\n\n
\n\n
\n
“high-risk profiling”: profiling which involves a high risk to the personality or fundamental rights of the data subject, by creating a link between data which allows an assessment of substantial aspects of the personality of a natural person.
\n
\n\n
\n\n
\n
“data security breach”: a security breach which leads to an unintentional or unlawful loss, deletion, destruction or modification of personal data or to personal data being disclosed or made accessible to unauthorised persons.
\n
\n\n
\n\n
3. Principles of data processing
\n\n
\n\n
The principles of data processing remain materially largely unchanged.
\n\n
\n\n
\n
Art. 6 para. 4 now explicitly stipulates that personal data must be destroyed or anonymised as soon as it is no longer needed with regard to the purpose of the processing. To comply with this obligation, the controller must determine retention periods in advance.
\n
\n\n
\n\n
\n
The definition of “personality profile” is replaced by “profiling” (see description under “definitions”). The terminology of profiling was the sticking point on which the Councils disagreed until the very end and which was also largely discussed in the media. In the end, the conciliation committee followed the proposal of the Council of States and decided to introduce the definition of “high-risk profiling” (which is comparable to the current concept of the personality profile), with the consequence that if consent is required for this type of profiling, it must be explicit.
\n
\n\n
\n\n
It should be noted that the nFADP does not introduce a consent requirement for high-risk profiling, but only requires that consent, if at all required as a justification under art. 31 nFADP, must be given explicitly. It is worth recalling that the basic concept of both the FADP and the nFADP is different from that of the GDPR. While under the GDPR, a legal ground is always required for the processing of personal data (art. 6 and 9 GDPR), the processing of personal data under the FADP and nFADP is, in principle, permitted as long as the personality of the data subjects is not unlawfully violated. Hence, the \"permission principle subject to prohibition\" continues to apply under the nFADP, while the GDPR applies the \"prohibition principle subject to permission\".
\n\n
\n\n
4. Privacy by Design und Privacy by Default
\n\n
\n\n
The principles of “privacy by design” and “privacy by default”, as known from the GDPR, are now also enshrined in the nFADP. In today's practice, the controller is already required to set up data processing activities in a manner that complies with the data protection regulations and the principles of data processing. The nFADP explicitly regulates that the controller must ensure, through appropriate pre-defined settings, that the processing of personal data is limited to the minimum required by the purpose unless the data subject determines otherwise (privacy by default).
The slightly revised article 8 nFADP stipulates that both the controller and the processor must ensure, through adequate technical and organisational measures, a level of data security that appropriately addresses the risk. This means that a risk-based approach is introduced. “The higher the risk of a data security breach, the higher the requirements for the measures to be taken”.9 Further provisions on minimum data security requirements can be found in Section 1 of the DPO.
\n\n
\n\n
6. Data processing by processors
\n\n
\n\n
Art. 9 nFADP essentially adopts the current article 10a FADP. The rather unfortunate term “third parties” is replaced by “processors”. The processing of personal data may still be assigned by agreement or by legislation to a processor if (a) the data is processed only in a manner permitted for the controller itself, and (b) no statutory or contractual duty of confidentiality prohibits the assignment. The controller must ensure in particular that the processor can guarantee data security. As under the GDPR, the processor may only assign the processing to a sub-processor with the prior authorisation by the controller.
\n\n
\n\n
7. Data protection advisor
\n\n
\n\n
Controllers may, but are not required to, appoint a data protection advisor as a contact point for the data subjects and the relevant authorities responsible for data protection matters in Switzerland. The data protection advisor has the duty to train and advise the controller in matters of data protection and to participate in the enforcement of data protection regulations.
\n\n
\n\n
Contrary to the current FADP, the data protection advisor is not responsible for supervising the company’s internal compliance with data protection regulations, nor for maintaining an inventory of data files.
\n\n
\n\n
Private controllers who appointed a data protection advisor have an advantage when they need to perform a data protection impact assessment according to art. 22 nFADP by reason of their processing activities, provided that they consult their data protection advisor. In this case, they can abstain from consulting the FDPIC.10 The controller must consult the FDPIC before the processing when the data protection impact assessment shows that the processing presents a high risk for the personality or fundamental rights of the data subject, despite the measures envisaged by the controller. The controller may abstain from consulting the FDPIC if the data protection advisor (a) performs his or her function towards the controller in a professionally independent manner and without being bound by instructions, (b) does not perform any activities which are incompatible with his or her tasks as data protection advisor, (c) possesses the necessary professional knowledge, and (d) if the controller publishes the contact details of the data protection advisor and communicates them to the FDPIC.
\n\n
\n\n
8. Inventory of processing activities
\n\n
\n\n
As under the GDPR, controllers and processors must each keep an inventory of their processing activities. The nFADP lists the minimum information that needs to be contained in such inventories. The inventory of processing activities does no longer have to be declared to the FDPIC.
\n\n
\n\n
9. Representative in Switzerland
\n\n
\n\n
Similar to the GDPR, private controllers with their domicile or residence abroad must, under certain circumstances, designate a representative in Switzerland if they process personal data of persons in Switzerland. The representative serves as a contact point for data subjects and the FDPIC. The controller must publish the name and address of the representative. The requirements for designating a representative and the duties of the representative are regulated in art. 14 and 15 nFADP.
\n\n
\n\n
10. Cross-border disclosure of personal data
\n\n
\n\n
Under the current FADP, personal data must not be disclosed cross-border if such disclosure would seriously endanger the personal privacy of the data subjects, in particular, due to the absence of legislation that guarantees adequate protection. The FDPIC maintains a list with a general evaluation of the data protection level in the listed countries. However, this non-binding list does not relieve the data exporter from its responsibility to assess on a case by case basis whether the legislation of the respective country guarantees an adequate level of protection.
\n\n
\n\n
Under the nFADP, the Federal Council bindingly determines whether the legislation of a state or an international body guarantees an adequate level of protection. If this is the case, personal data may be transferred cross-border. If not, data protection must be guaranteed by measures such as (a) an international treaty, (b) data protection clauses between the contracting parties, which were communicated beforehand to the FDPIC, (c) standard data protection clauses previously approved, established or recognised by the FDPIC (such as the EU standard contractual clauses) or (d) binding corporate rules (BCR) previously approved by the FDPIC or by a foreign authority which is responsible for data protection and belongs to a state which guarantees adequate protection (for example the CNIL in France as lead authority). The Federal Council can provide for other adequate safeguards, such as, for example, a follow-up agreement to the Swiss-US Privacy Shield.11
\n\n
\n\n
By derogation from the principles mentioned above, personal data may only be disclosed cross-border if one of the exceptions provided for in art. 17 nFADP applies, such as, for example, the explicit consent of the data subject.
\n\n
\n\n
11. Duty of information when collecting personal data
\n\n
\n\n
The duty of information has been tightened. While the duty of information currently only applies to the collection of sensitive personal data and personality profiles, the controller must, in the future, generally inform the data subjects about the collection of their personal data. The minimum information that must be given in the privacy statement is stipulated in art. 19 nFADP, differentiating between data collected directly from the data subject and data collected indirectly via other sources. This minimum information is less extensive than under the GDPR. However, there is one aspect where the nFADP is stricter than the GDPR: if personal data is disclosed cross-border, the controller must inform the data subject of the state where the recipient is located, no matter whether it is located in a state with an adequate level of data protection or in a third country.
\n\n
\n\n
Exceptions to the duty of information have been concretised. Private controllers may still restrict, defer or waive the provision of information in some instances. Among others, this is possible when the overriding interests of the controller demand it and when the controller does not disclose the personal data to third parties, companies controlled by the same legal entity not being considered as third parties in the sense of this exception.
\n\n
\n\n
Under the nFADP, the controller must, as a general rule, inform the data subject of a decision which is taken exclusively based on automated processing and which has legal effects on the data subject or affects him or her significantly (so-called “automated individual decision”). The data subject can request that a natural person review the automated individual decision. Art. 21 nFADP provides for exceptions to this rule.
\n\n
\n\n
12. Data protection impact assessments
\n\n
\n\n
As under the GDPR, the controller must conduct a data protection impact assessment before the data processing if the intended data processing may lead to a high risk for the data subject’s personality or fundamental rights. The existence of high risk, particularly when using new technologies, depends on the nature, the extent, the circumstances and the purpose of the processing (in particular the processing of sensitive personal data on a broad scale and the systematic surveillance of extensive public areas).
\n\n
\n\n
The data protection impact assessment contains a description of the intended processing, an evaluation of the risks for the data subject’s personality or fundamental rights, as well as the intended measures to protect the data subjects’ personality and fundamental rights. Art. 22 nFADP provides for certain exceptions. If the controller considers performing several similar processing operations, it may establish a joint impact assessment.
\n\n
\n\n
If the data protection impact assessment shows that the intended processing leads to a high risk for the personality or the fundamental rights of the data subject despite the measures envisaged, the controller must consult the FDPIC before the processing. It can abstain from consulting the FDPIC if it has appointed a data protection advisor according to art. 10 nFADP and consulted him or her regarding the processing in question.
\n\n
\n\n
13. Notification of data security breaches
\n\n
\n\n
Like the GDPR, the nFADP introduces a duty of notification of data security breaches, i.e. security breaches that lead to the unintentional or unlawful loss, deletion, destruction or modification of personal data or to personal data being disclosed or made accessible to unauthorised persons.
\n\n
\n\n
The good news is that the provisions regarding the notification obligation are slightly more pragmatic under the nFADP than under the GDPR. The controller must notify the FDPIC as soon as possible of a data security breach that is probable to result in a high risk to the personality or the fundamental rights of the data subject.
\n\n
\n\n
Unlike the GDPR, the nFADP only requires notification to the FDPIC where there is a high risk for the data subject. This is meant to prevent the notification of minor breaches. It remains the responsibility of the controller to determine the impact of the breach and the resulting risk for the data subject.
\n\n
\n\n
Contrary to the GDPR, the nFADP does not stipulate a specific period within which the notification to the FDPIC must be made, but demands that the controller notify the breach as soon as possible after having become aware of it. The controller must act quickly but has a certain margin of discretion. “What is decisive in this context is, among others, the extent of the threat for the data subject. The bigger the threat and the larger the number of data subjects concerned, the quicker the controller must act.”12 Furthermore, the controller only needs to inform the data subject if it is necessary for the protection of the data subject or if the FDPIC requests so. What is decisive in this context is whether the notification can reduce the risk for the personality or the fundamental rights of the data subject. This is, in particular, the case where the data subject can take measures for his or her protection, for example by changing his or her login details or password.13 Under certain circumstances, the controller may restrict the information to the data subject, defer it or refrain from providing information.
\n\n
\n\n
The processor has no duty to notify the FDPIC but must inform the controller as soon as possible of any data security breach.
\n\n
\n\n
Art. 24 nFADP lists the minimum requirements for a notification to the FDPIC.
\n\n
\n\n
14. Rights of the data subject
\n\n
\n\n
Access right: The access right currently regulated in art. 8 FADP is now regulated in art. 25 nFADP. The principle remains unchanged. The controller provides the data subject with the information required to enable him or her to assert his or her rights and to ensure the transparent processing of personal data. It is the same information as the one that must be given based on the duty of information. The minimum information that must be provided in reply to a request for information is listed in the nFADP. A new element is information on the existence of automated individual decision-making. In this case, the data subject must also be informed about the logic on which the decision is based. The data subject can further request that a natural person review the automated individual decision.
\n\n
\n\n
The current limitations to the access right continue to exist. Under the nFADP, the controller may “refuse, restrict or defer the provision of information if the request for information is manifestly unfounded or is obviously of a querulous nature”. According to the Federal Council Dispatch14, this limitation is to be interpreted in a narrow sense. In particular, the controller must choose the most favourable solution for the data subject. It must, to the extent possible, only restrict the provision of information, may defer it if necessary and can only refuse it in absolutely clear and obvious cases.
\n\n
\n\n
Right to data portability: Under the nFADP, the data subject has, under certain circumstances, a right to data portability.15 The data subject may request the transfer of his or her personal data to him or her or, if this does not involve a disproportionate effort, to another controller. As a general rule, the data must be disclosed free of charge and in a standard electronic format. The same limitations as for the access right apply.
\n\n
\n\n
Legal claims: The currently applicable legal claims continue to apply and are listed in art. 32 nFADP. The right to deletion or destruction is now explicitly regulated in the nFADP, although it is already implied in the current law.
\n\n
\n\n
15. Administrative measures and sanctions
\n\n
\n\n
The competences of the FDPIC are extended in art. 51 nFADP. Under the new law, he can not only recommend measures but also order administrative measures. Among these measures are for example measures against data processing that violates the data protection regulations, including the order to destroy personal data or the prohibition to disclose personal data cross-border, as well as the order to perform a data protection impact assessment or to inform the data subject. The FDPIC still cannot issue any fines. This competence remains with the cantons.16
\n\n
\n\n
The criminal provisions have been significantly tightened.17 Under the nFADP, private persons (i.e. not companies, as under the GDPR!) are, on complaint, liable to a fine of up to 250 000 Swiss francs if they violate their duty to provide access or information, or their duties of diligence, namely if they disclose personal data cross-border or assign the data processing to a processor without complying with the requirements, or fail to comply with the minimum data security requirements. Persons who wilfully refuse to cooperate with the FDPIC in the context of an investigation are also liable to a fine.
\n\n
\n\n
Further, a person who violates his or her duty of confidentiality by wilfully disclosing secret personal data of which he or she has gained knowledge while exercising his or her profession which requires knowledge of such data is liable to a fine. This provision introduces a duty of confidentiality for persons (and their auxiliary persons) who are not covered by the obligation of professional secrecy under criminal law18. A breach of professional confidentiality can be sanctioned on a complaint with a fine of up to 250 000 Swiss francs.
\n\n
\n\n
Finally, persons who wilfully fail to comply with a decision issued by the FDPIC or by the appellate authorities under threat of penalty are liable to a fine of up to 250 000 Swiss francs.
\n\n
\n\n
It should be noted that only those who act intentionally are liable to prosecution, whereby contingent intent is sufficient. The addressees of the penal provisions are in principle managers, i.e. persons who have independent decision-making powers.19 The company can only be directly fined if the fine does not exceed 50 000 Swiss francs and the investigation of the culpable manager would require disproportionate investigative measures.20
\n\n
\n\n
Finally, it should be noted that violations of essential duties newly enshrined in the law, such as the keeping of an inventory of processing activities, the notification of data security breaches or the obligation to perform data protection impact assessments, are not liable to a fine.
\n\n
\n\n
Implementation measures
\n\n
\n\n
Companies should carry out a data management analysis and identify their level of compliance with the nFADP as well as any possible gaps and risks. In doing so, they should focus on the following areas:
\n\n
\n\n
\n
governance structure,
\n
data protection standards and processes to comply with the privacy principles and data security,
\n
transparency towards the data subjects,
\n
inventory of processing activities,
\n
data flows within the company and to service providers (taking into consideration the latest developments and the policy paper of the FDPIC21),
\n
processes for performing data protection impact assessments,
\n
notification of data security breaches to the FDPIC and
\n
responding to requests for information (access rights).
\n
\n\n
\n\n
Companies who already introduced a GDPR data protection program will have less need for action than companies who are not subject to the GDPR or who have not yet taken any respective measures.
\n\n
\n\n
Many companies will, in any case, have to introduce concepts such as privacy by design as well as processes that allow the legally compliant deletion or destruction of personal data and support data portability. Many companies will also have to review their privacy statements and, if needed, adapt them or issue new privacy statements to fulfil the requirements of the nFADP. Current inventories of data files will have to be restructured to record data processing activities.
\n\n
\n\n
If you have any questions or need support in this area, please do not hesitate to contact FABIAN PRIVACY LEGAL.
\n\n
\n\n
\n\n
[1] This article is an updated version of the article published in October 2020 by the same author under the same title.
[3] Dispatch on the Federal Act on the total revision of the Federal Act on Data Protection and the amendment of other enactments on data protection (BBl 2017 6943)
[11] On 8 September 2020, the Federal Data Protection and Information Commissioner (FDPIC) determined that the Swiss-US Privacy Shield was no longer adequate for the transfer of personal data from Switzerland to the US. The European Commission and the United States announced in March 2022 an \"agreement in principle\" on the new Transatlantic Data Protection Framework (TADPF), which is intended to facilitate the flow of data between the EU and the US and address the concerns raised by the European Court of Justice in the Schrems II decision in 2020. US President Biden subsequently issued the Executive Order On Enhancing Safeguards for United States Signals Intelligence Activities in October 2022, implementing US commitments under the TADPF. On 13 December 2022, the European Commission published a draft adequacy decision concluding that the EU-US data protection framework provides an adequate level of protection for personal data transferred by EU companies to the US. A final decision by the European Commission is expected around mid-2023.
The new Swiss Data Protection Act (Federal Act on Data Protection - nFADP) will enter into force together with the new Ordinance to the Federal Act on Data Protection (DPO) and the new Ordinance on Data Protection Certification (DPCO) on 1 September 2023. The nFADP introduces new obligations for private persons and federal bodies, improves the rights of data subjects and significantly tightens personal criminal liability for violations of the nFADP. What do companies in Switzerland and abroad need to know to ensure data protection-compliant data processing? This article summarises the most important changes for companies.
\n","preview":"","datei":[],"linkextern":""},{"id":170,"title":"What does data protection have to do with digital transformation? (in German)","slug":"was-hat-datenschutz-mit-digitaler-transformation-zu-tun","link":"/en/news-knowledge/was-hat-datenschutz-mit-digitaler-transformation-zu-tun","titel":"What does data protection have to do with digital transformation? (in German)","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
Was hat Datenschutz mit digitaler Transformation zu tun?
\n\n
Die Digitalisierung erlaubt es, Daten immer besser und schneller zu sammeln und analysieren. Sind Personendaten involviert, muss der Datenschutz eingehalten werden.
\n\n
Am 1. September 2023 tritt das revidierte Datenschutzgesetz (DSG) in Kraft, mit neuen Pflichten und verschärften Sanktionen.
\n\n
\n\n
Eckpunkte des revidierten DSG
\n\n
Besonders schützenswerte Daten umfassen neu genetische und biometrische Daten. Profiling und Profiling mit hohem Risiko, also die automatisierte Bearbeitung von Personendaten, um persönliche Aspekte zu analysieren oder vorherzusagen, wurden eingeführt. Jede Person kann vom Verantwortlichen die Herausgabe ihrer Personendaten, die sie diesem bekanntgegeben hat und automatisiert bearbeitet werden, in einem gängigen elektronischen Format verlangen. Verantwortliche müssen betroffene Personen über die Beschaffung von Personendaten sowie automatisierte Einzelentscheidungen informieren. Datenbearbeitungen müssen ab Planung durch geeignete Massnahmen die Einhaltung der Datenschutzvorschriften gewährleisten (Privacy by Design) und bei hohem Risiko einer Datenschutz-Folgenabschätzung unterzogen werden. Neu muss ein Bearbeitungsverzeichnis geführt werden und die Datensicherheit durch geeignete technische und organisatorische Massnahmen gewährleistet sein. Verletzungen der Datensicherheit müssen je nach Risiko dem EDÖB gemeldet werden.
\n\n
\n\n
Verschärfte Sanktionen
\n\n
Wer vorsätzlich gegen Informations-, Auskunfts oder Sorgfaltspflichten verstösst, namentlich die Datensicherheits-Anforderungen nicht einhält, Personendaten ins Ausland bekanntgibt oder ohne Erfüllung der gesetzlichen Anforderungen Auftragsbearbeiter einsetzt, riskiert eine Busse bis zu 250'000 Franken. Adressat der Busse ist nicht das Unternehmen, sondern die Leitungsperson mit entsprechender Entscheidungs- und Weisungskompetenz.
\n\n
\n\n
Was können Unternehmen tun?
\n\n
Unternehmen sollten frühzeitig ihre Bearbeitungstätigkeiten erfassen, Datenschutzerklärungen prüfen und ggf. anpassen und Prozesse zur Sicherstellung der gesetzeskonformen Umsetzung der Datenschutzanforderungen und Pflichten implementieren.
\n\n
\n","datum":"18.12.2022","teasertext":"
Thanks to the ongoing digitalization, data collection and analysis is becoming increasingly better and faster. In this context, data protection is essential whenever personal data is involved. In an article published in the magazine \"Ausblick 2023\", Daniela Fábián Masoch explains the changes brought about by the entry into force of the revised Swiss data protection act on September 1, 2023 and what companies can do in order to be prepared. Please note that the publication is only available in German.
\n","preview":"","datei":[],"linkextern":""},{"id":174,"title":"The new Swiss Data Protection Act - What you need to know","slug":"das-neue-schweizer-datenschutzgesetz-was-sie-wissen-muessen","link":"/en/news-knowledge/das-neue-schweizer-datenschutzgesetz-was-sie-wissen-muessen","titel":"The new Swiss Data Protection Act - What you need to know","text":"
The revised Federal Act on Data Protection (nFADP) will come into force on September 1, 2023, together with the implementing provisions in the Ordinance to the Federal Act on Data Protection (DPO) and the Ordinance on Data Protection Certifications (DPCO).
\n\n
\n\n
Although the principles of data protection remain essentially the same, a number of new obligations are imposed on companies. These obligations include, for example, an extended duty to inform data subjects, the performance of data protection impact assessments, the record of data processing activities, the implementation of privacy by design and the notification of data security breaches. The penal provisions for natural persons have also been tightened significantly.
\n\n
\n\n
As the nFADP does not provide for any transition periods, companies should now examine the extent to which their internal regulations and processes for data management comply with the new requirements.
\n\n
\n\n
This webniar on Mondaq highlights the new obligations for companies and the consequences of non-compliance. It will highlight the need for action for companies and provide pragmatic implementation approaches. Finally, the most important differences to the GDPR will be highlighted.
\n\n
\n\n
To download the webinar in PDF format, please click here.
\n\n
\n\n
To view the webinar directly on the Mondaq website, please click here.
\n","datum":"07.12.2022","teasertext":"
This webniar on Mondaq highlights the new obligations for companies and the consequences of non-compliance. It will highlight the need for action for companies and provide pragmatic implementation approaches. Finally, the most important differences to the GDPR will be highlighted.
To download the article in PDF format, please click here.
\n\n
\n\n
1 Introduction
\n\n
\n\n
Laws around the world impose strict data security obligations on organisations that process personal data, and in some cases require them to report data breaches to data protection authorities and individuals affected by the data breach. In addition to significant sanctions for failing to take appropriate technical and organisational measures to protect data, and potentially for failing to report a data breach as required by law, organisations may suffer, among other things, loss of stakeholder trust, reputational damage, and disruption of business activities as a result of a data breach, leading to economic losses. In addition, there are significant costs associated with managing a data breach and remediating the damage caused by the breach.
\n\n
\n\n
Investing in data security to prevent data breaches, such as those caused by cyberattacks or employee errors, and being prepared to respond in the event of a data breach is therefore worthwhile not only to comply with the legal obligations, but also to avoid negative consequences for the organisation and its stakeholders.
\n\n
\n\n
This article elaborates on what constitutes a personal data breach and what a data breach prevention and response strategy might look like. It is limited to dealing with data breaches involving personal data and takes the requirements of the General Data Protection Regulation (GDPR) as a starting point, but without limiting itself to the GDPR.
\n\n
\n\n
2 What is a Data Breach and its Potential Consequences?
\n\n
\n\n
A data breach (also called a personal data breach or security breach) occurs when personal data held by an organisation is lost or subjected to unauthorised access, modification, disclosure, or other misuse or interference. The GDPR defines the term personal data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored, or otherwise processed. Privacy laws in other jurisdictions contain similar, though not identical, definitions.
\n\n
\n\n
In its Opinion 03/2014 on data breach notification and its Guidelines on personal data breach notification under Regulation (EU) 2016/679 (WP250rev.01), the Article 29 Data Protection Working Party divided data breaches into three security principles:
\n\n
\n\n
\n
Confidentiality breach – where there is an unauthorised or accidental disclosure of, or access to, personal data.
\n
\n\n
\n\n
\n
Integrity breach – where there is an unauthorised or accidental alteration of personal data.
\n
\n\n
\n\n
\n
Availability breach – where there is an accidental or unauthorised loss of access to, or destruction of, personal data.
\n
\n\n
\n\n
Examples of data breaches include the loss or theft of a data carrier (e.g., notebook, phone, USB stick, paper files) containing unencrypted personal data of customers or employees (breach in confidentiality, and potentially availability if there is no backup for the stolen device); the successful penetration of an organisation’s computer systems containing personal data for the purpose of copying, exfiltrating, and misusing personal data for malicious purposes (breach in confidentiality and possibly integrity); a ransomware attack in which the attacker encrypts data with a malicious code and then demands a ransom from the attacked organisation in exchange for the decryption key (availability breach, and possibly confidentiality breach); the unauthorised downloading of personal data by a terminated employee for further private use (confidentiality breach); the inadvertent disclosure of personal data by an employee to unauthorised persons inside or outside the organisation, e.g., by sending it to an incorrect address or by sending a file that inadvertently contains personal data not intended for the recipients (confidentiality breach).
\n\n
\n\n
A data breach may have various negative effects on individuals and result in physical, material and immaterial damage. It may, for example, cause the affected individual to lose control over his or her personal data or to be restricted in the exercise of his or her personal rights, to suffer financial loss or personal disadvantage, emotional distress, embarrassment or humiliation, or damage to his or her reputation. Possible consequences may also include identity theft or fraud, loss of employment or business opportunities, unwanted marketing or spam, reversal of pseudonymisation, or other significant economic or social disadvantages.
\n\n
\n\n
Organisations can also suffer harm as a result of a data breach. Responding to a data breach and potential subsequent complaints and implementing remedial actions may have financial, legal and resource implications. Data breaches can further result in reputational damage and loss of stakeholder trust.
\n\n
\n\n
According to the Ponemon Institute’s 2021 Cost of a Data Breach Report, the average total cost of a data breach increased by nearly 10% year over year. The amount increased from $3.86 million in 2020 to $4.24 million in 2021, with costs being significantly lower for organisations with more mature security levels. The average total cost was $1.07 million higher for breaches where remote work was a factor in the breach, compared to breaches where remote work was not a factor. The average total cost per record containing personal data was $161. The longer it took to detect the breach, the more expensive it was, with 38% of the costs related to lost business (including business interruption and lost revenue due to system downtime, cost of lost customers and acquiring new customers, loss of reputation, and diminished goodwill). 29% of the costs related to detection and escalation. The remaining cost drivers were post-breach response (27%), and notification (6%). The costliest initial attack vectors were business emails, followed by phishing, malicious insiders, social engineering, and compromised credentials.
\n\n
\n\n
3 Data Breach Notification Requirements
\n\n
\n\n
Many countries around the world have introduced data breach notification regulations. The first laws were enacted in the U.S. at the state level starting in 2002 (California). Other countries have followed, such as the EU Member States and the United Kingdom with the General Data Protection Regulation (GDPR) and the UK Data Protection Regulation (UK GDPR), respectively, as well as other countries around the world, such as Australia, Brazil, China, Colombia, Egypt, Ghana, Israel, Kenya, Mexico, New Zealand, the Philippines, Singapore, South Korea, Switzerland, Taiwan, Thailand and Uruguay.
\n\n
\n\n
Independent of data breach notification requirements, most countries in the world have introduced data security obligations that must be implemented by data controllers and data processors.
\n\n
\n\n
4 Data Breach Response Strategy
\n\n
\n\n
Although security requirements and the conditions and modalities of notification obligations may vary from country to country, any organisation that processes personal data and is subject to security and notification obligations should define and implement a data security and breach management strategy to ensure adequate data security and risk mitigation in the event of an incident and be prepared to deal with any data breaches.
\n\n
\n\n
The data breach response strategy does not need to be stand-alone but can and should be aligned with other internal data management and security strategies, e.g., information security, where possible. It should cover three key factors: prevention; response; and improvement.
\n\n
\n\n
4.1 Prevention – Implement appropriate TOMs
\n\n
\n\n
Even with the best possible security, data breaches cannot be completely avoided. However, data breaches are often the result of a vulnerable and outdated security regime or system weaknesses. Prevention through the adoption of appropriate security measures is therefore key to preventing vulnerabilities in systems or insufficient security that can potentially lead to a data breach.
\n\n
\n\n
Data and risk mapping: Only if organisations know what types of data breaches could occur and understand the characteristics of these breaches, they can take the necessary technical and organisational measures (TOMs) to reduce the risk of a successful attack or breach.
\n\n
\n\n
The basic prerequisite is first that companies know what types of data and personal data they process, who the data subjects are and their locations, where the data is stored and who should have access to it. This knowledge requires the mapping of all data systems, products and services that process personal data and their classification. Organisations should then assess the risk level to their organisation and to individuals in the case of a data breach as well as identify the possible types of attacks and based on that understanding and the level of risk, take the appropriate technical and organisational measures to mitigate the consequences in the case of a data breach.
\n\n
\n\n
Implementation of TOMs: Based on the risk level, such TOMs may include a state-of-the-art encryption of the data at rest and a separate back-up of the data to help mitigate the consequences of a successful ransomware attack or the loss or theft of a device with personal data. In addition to a state-of-the-art encryption, measures such as key management, regular updates of systems, use of strong authentication methods like two factor authentication, firewalls, etc. may help to mitigate the consequences of data exfiltration. Regular awareness campaigns and training to staff on security aspects, instructions on how to use company devices and information as well as the implementation of technical measures and controls may help to prevent human errors.
\n\n
\n\n
External resources and insurance coverage: Besides the implementation of robust TOMs, organisations should evaluate in advance what type of external expertise is required in the case of a data breach and ensure that such expertise is available on short notice, which may require the negotiation of frame contracts in advance. Additionally, organisations may consider holding an insurance policy for data breaches.
\n\n
\n\n
Data breach response plan: Finally, organisations should deploy a data breach response plan that sets out procedures, modalities, and responsibilities in the event the organisation experiences a data breach (or a suspected data breach, i.e., a security incident) to respond to a data breach in a timely and efficient manner.
\n\n
\n\n
4.2 Response – Implement a data breach response plan
\n\n
\n\n
4.2.1. Why a data breach response plan?
\n\n
\n\n
Due to the usually very short timelines for reporting a data breach to the data protection authorities and individuals (at least in some countries, including the EU), it is critical that each organisation handling personal data put in place a documented data breach response plan. Implementing such a plan can help organisations in (a) mitigating the impact on the organisation and affected individuals and the costs resulting from the data breach, (b) meeting their data security obligations, (c) protecting important business assets, including personal data of their employees and clients and the company’s reputation, (d) dealing with negative media or stakeholder attention, and (e) instilling public confidence and trust in the organisation’s capacity to protect personal data entrusted to the company by properly responding to a data breach.
\n\n
\n\n
The data breach response plan should be aligned with other plans as appropriate, such as existing security incident response, disaster recovery, business continuity, or contingency plans. This approach can ensure effective management with clear responsibilities, avoid duplication, and leverage synergies.
\n\n
\n\n
4.2.2. Content of a data breach response plan
\n\n
\n\n
A data breach response plan shall establish the rules and processes on how to handle a data breach in compliance with internal standards and legal and regulatory requirements. It shall outline what a data breach is, possibly providing some concrete examples tailored to the specific organisation, allocate the roles and responsibilities for detecting, responding, and documenting a data breach, describe the process for handling a data breach, from detection to notification and risk mitigation, and specify the obligations towards third parties processing the data on their behalf.
\n\n
\n\n
4.2.3. Establishment of an incident response team
\n\n
\n\n
While in small organisations, the managing director or owner is often the person who deals with a data breach, usually with external assistance, establishing an incident response team has proven effective in mid-sized and larger organisations. The purpose of such a team is to ensure that in the event of a data breach, the relevant functions are immediately engaged, and data breaches can be promptly addressed, risks assessed, and any required notifications made in a timely manner.
\n\n
\n\n
The composition of the team will depend on the organisation and the nature of the business, but will typically require different skill sets, which can be ensured by involving internal functions and external legal, data forensics, and media management experts. Organisations should assess in advance what type of external expertise will be needed in the event of a data breach and ensure that this expertise is available on short notice. The organisation should maintain and regularly update a current list of team members, including their roles, responsibilities, and contact details, as well as the contact information of their delegates. Team members should receive regular training and participate in mock exercises. The response team should consist of a core team that includes, at a minimum, the data protection officer, and the information security officer, and should be extended to include other functions such as human resources, research and development, or communications, as well as outside legal counsel and forensic analysts, depending on the severity and nature of the incident.
\n\n
\n\n
The incident response team shall be responsible for managing the overall data breach, investigating, and reviewing the circumstances of the data breach and the facts of the case, engaging relevant functions and external experts, assessing the level of risk, determining remediation actions, determining the need for internal escalation, and notifying data protection authorities and individuals. The data breach response plan should identify the specific responsibilities of each member of the response team.
\n\n
\n\n
4.2.4. Process for responding to a data breach
\n\n
\n\n
The process for responding to a data breach typically includes different steps, starting from the detection of the data breach and reporting to the immediate containment, investigation of the data breach, risk evaluation, internal escalation, notification, and documentation.
\n\n
\n\n
Detection and reporting: Each employee should understand how to recognise a potential data breach and know how to report such a data breach or suspected data breach (security incident) to the incident response team, that will immediately perform a preliminary evaluation and determine if the incident qualifies as a data breach.
\n\n
\n\n
Containment: Once the source of the data breach has been identified, the data breach should be contained immediately to prevent further exposure of personal data, for example, and depending on the concrete impact, by remediating identified vulnerabilities in systems, recovering records, shutting down the compromised system, restricting access to data, recalling sent emails containing personal data that were inadvertently attached to the email or sent to the wrong recipients, or deleting them from the accounts of the unintended recipients.
\n\n
\n\n
Investigation: The incident response team should investigate and document the facts and circumstances of the data breach, including the causes of the data breach such as any vulnerabilities in the computer systems; the nature of the data breach (breach of confidentiality, availability, or integrity); the nature, scope, and sensitivity of the personal data involved, as well as the origin of the data; the type, number, and location of data subjects; applicable data protection laws; and notification requirements.
\n\n
\n\n
Risk evaluation: Based on the outcome of the investigation and taking into account the type of personal data compromised, the extent of the data breach, and the type and number of individuals affected by the data breach, the incident response team must assess the level of risk of the data breach to the rights and freedoms of data subjects and the organisation. To assess the level of risk, they must determine the impact that the data breach could have on the rights and freedoms of individuals and the likelihood that this impact will actually occur. The greater the impact and the greater the likelihood, the higher the risk. Essential elements for determining the impact on individuals are the ease of their identification (how easily can an individual be identified from the compromised data?) and the severity (how much harm can be caused by the data breach?). Key elements in determining the likelihood of the identified impact actually occurring are the potential vulnerabilities due to the lack of appropriate TOMs and the ability to exploit those vulnerabilities or the intent of the individuals accessing or possessing the data (was the data exfiltrated by a hacker with malicious intent or sent by an employee to the wrong recipient in the same organisation by mistake?).
\n\n
\n\n
Escalation: The data breach response plan should define the internal escalation process, which should depend on the severity and extent of the breach, the level of risk identified, and the requirement for notification.
\n\n
\n\n
Notification: The incident response team determines, based on all the facts and the risk evaluation, whether the data breach must be notified to local data protection authorities and affected individuals, and if so, when, where, and how. The data breach response plan should identify which function is responsible for notifying the authorities and individuals. Generally, this task is assigned to the data protection officer. It is also advantageous if possible scenarios requiring notification have already been worked through and documented.
\n\n
\n\n
Documentation: Any data breach, whether notified to data protection authorities and/or individuals or not, shall be documented, including the facts and circumstances of the breach, its effects, and the corrective actions taken and planned to prevent future similar data breaches, the risk evaluation, and the appropriate justification for the decisions made with respect to the notification to data protection authorities and individuals.
\n\n
\n\n
4.2.4. Considerations in implementing a data breach response plan globally
\n\n
\n\n
Given the large number of countries with data breach notification requirements, globally operating companies are faced with the challenge of finding solutions that are as comprehensive and uniform as possible in order to, on the one hand, deal with data breaches uniformly and efficiently across the organisation and, on the other hand, take into account the specifics of the individual countries.
\n\n
\n\n
When implementing a data breach response plan globally, companies must take into account locally applicable data privacy and security laws, as well as notification requirements and modalities, languages, and cross-border data transfer restrictions, and align the data breach response plan accordingly. Companies should also decide what the internal reporting channel for discovered data breaches should be. Depending on their organisational set-up, they could establish one global reporting channel or separate regional or local reporting channels. Also, organisations must determine where data breaches should be documented (in a centralised system or locally), and whether a global incident response team should be deployed around the world or regional/local response teams should be established.
\n\n
\n\n
4.3 Improvement – Address security gaps to prevent future (similar) data breaches – regularly re-evaluate the data breach response plan to increase effectiveness
\n\n
\n\n
The third phase of the data breach response strategy consists of improvements in two respects: addressing identified vulnerabilities to prevent future similar data breaches; and increasing the effectiveness of the data breach response plan.
\n\n
\n\n
Address any identified security vulnerabilities to prevent future similar data breaches. Once the notification and documentation process is complete, the incident response team should determine and implement appropriate measures to prevent future similar data breaches. Depending on the concrete type of data breach and the root cause, such measures may include, for example, conducting regular security audits and reviewing and updating policies and procedures in light of lessons learned, reviewing and amending contracts with third parties to ensure appropriate handling of data breaches. Other measures may include, for example, restricting the downloading of personal data to mobile devices without adequate security protection, such as state-of-the-art encryption or the establishment of separate backups of specific data sets, and regular training for the business units concerned.
\n\n
\n\n
Periodically re-evaluate the data breach response plan to increase its effectiveness taking into account changes in applicable data protection laws, best practices and internal business requirements.
\n\n
\n\n
5 Conclusion
\n\n
\n\n
Data security is one of the essential obligations of any organisation that processes personal data. A breach of the confidentiality, integrity or availability of data can have negative consequences not only for the individuals concerned, but also for the responsible organisation. A data breach can result in notification obligations, significant costs to contain the data breach and repair the damage caused by the breach, as well as loss of stakeholder trust, reputational damage, and business disruption. Investing in data security to prevent data breaches, such as those caused by cyberattacks or human error, and being prepared to respond in the event of a data breach is therefore essential for any organisation to meet its legal obligations and avoid negative consequences for itself and individuals affected.
\n\n
\n","datum":"13.07.2022","teasertext":"
Laws around the world impose strict data security obligations on organisations that process personal data, and in some cases require them to report data breaches to data protection authorities and individuals affected. Failure to comply with these laws may lead to significant sanctions, loss of stakeholder trust, reputational damage, and disruption of business activities. Investing in data security to prevent data breaches and being prepared to respond in the event of a data breach is therefore worthwhile not only to comply with the legal obligations, but also to avoid negative consequences. This article elaborates on what constitutes a personal data breach and what a data breach prevention and response strategy might look like.
\n","preview":"","datei":[],"linkextern":""},{"id":127,"title":"Keep legally up to date with the ongoing digital development (in German)","slug":"juristisch-a-jour-sein-mit-der-digitalen-entwicklung-fuer-firmen-heute-unerlaesslich","link":"/en/news-knowledge/juristisch-a-jour-sein-mit-der-digitalen-entwicklung-fuer-firmen-heute-unerlaesslich","titel":"Keep legally up to date with the ongoing digital development (in German)","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
Juristisch à jour sein mit der digitalen Entwicklung - für Firmen heute unterlässlich
\n\n
\n\n
Dem Thema Datenschutz kommt in einer zunehmend digitalisierten Welt grosse Bedeutung zu. Die Rechtsprechung passt sich dieser Entwicklung an, mit neuen Regularien und Gesetzen. Daniela Fábián, Gründerin von FABIAN PRIVACY LEGAL, unterstützt Unternehmen dabei, diesen Vorgaben nachzukommen.
\n\n
\n\n
Interview mit Daniela Fábián, Anwältin und Geschäftsführerin FABIAN PRIVACY LEGAL
\n\n
\n\n
Daniela Fábián, welches sind die juristischen Frage- und Problemstellungen, mit denen Ihre Kundinnen und Kunden an Sie herantreten?
\n\n
\n\n
Zu meinen Kunden gehören Konzerne, KMUs und Start-ups. Diese Unternehmen brauchen Unterstützung bei der Umsetzung der datenschutzrechtlichen Anforderungen, die sich aufgrund neuer Gesetze und der sich wandelnden Rechtsprechung ergeben. Ich unterstütze sie in der Risiko- und Bedarfsanalyse und der Entwicklung und Implementierung ihrer Datenschutzstrategie und -programme sowie bei der Beantwortung unterschiedlicher Praxisfragen. Unternehmen, die bereits ein Datenschutzprogramm implementiert haben, suchen uns auf, um sie bei der weltweiten Umsetzung ihrer globalen Datenschutzstrategie oder bei spezifischen Projekten zu unterstützen.
\n\n
\n\n
Was raten Sie Unternehmen in der Schweiz, die dieses Thema bisher noch nicht vertieft behandelt haben?
\n\n
\n\n
Mit dem totalrevidierten DSG kommen neue Pflichten auf Unternehmen zu, wie etwa erweiterte Informations- und Meldepflichten, die Durchführung von Datenschutz-Folgenabschätzungen und die Dokumentation von Bearbeitungstätigkeiten. Unternehmen müssen jetzt handeln. Zunächst sollten sie sich einen Überblick über die Ist-Situation verschaffen. Welche Personendaten bearbeiten wir und zu welchen Zwecken? Sind die betroffenen Personen informiert? Woher stammen die Daten, wo werden sie gespeichert und wer hat Zugriff darauf? Welche internen Prozesse und Regelungen bestehen? Solche und ähnliche Fragen stehen im Zentrum und helfen dabei, Lücken und Risiken zu identifizieren. Darauf basierend lässt sich eine Risikoanalyse vornehmen.
\n\n
\n\n
Um welche Risiken geht es dabei?
\n\n
\n\n
Dies unterscheidet sich je nach Unternehmen und Branche. Zum Beispiel müssen Pharma- und Medtech-Firmen, die mit sensiblen Patientendaten arbeiten, anderen Anforderungen genügen als etwa Logistikunternehmen. Der internationale Datentransfer und die Auslagerung der Datenbearbeitung können ebenfalls zu einem Risiko werden, wenn nicht alle erforderlichen Massnahmen getroffen werden. Schliessich nehmen Cyberattacken zu und ein Zuwiderhandeln gegen das DSG kann Geldbussen sowie Reputationsschäden nach sich ziehen.
\n\n
\n\n
Können Sie ein konkretes Beispiel dafür nennen, wie Firmen Ihr Fachwissen nutzen?
\n\n
\n\n
In der Regel suchen meine Kunden meine praktische Erfahrung bei der Umsetzung pragmatischer Datenschutzmanagementprogramme und -lösungen. Meine Expertise ist etwa auch bei der Entwicklung von Apps, zentralen Datenschutzmanagementsystemen oder digitalen Marketingkampagnen gefragt. Bei solchen Projekten ist es wichtig, alle relevanten Datenschutzanforderungen und -grundsätze bereits in der Konzeptionsphase in die Prozesse und Systeme einzubinden. Auch bei Verträgen mit komplexen Datenflüssen und der Beteiligung mehrerer Parteien besteht oft Unterstützungsbedarf.
\n\n
\n\n
Die digitale Technologie entwickelt sich rasant. Welche Fragen und Anliegen werden Sie und Ihre Kundinnen und Kunden künftig beschäftigen?
\n\n
\n\n
Für Schweizer Unternehmen wird neben der Umsetzung des revidierten DSG der internationale Datenfluss und damit verbunden die Überprüfung der Outsourcing-Strategie eine Priorität bleiben. Im Weiteren wird der Einsatz von künstlicher Intelligenz in vielen Bereichen weiter zunehmen, was immer auch Datenschutzfragen aufwirft sobald Personendaten involviert sind, Profile erstellt oder automatisierte Entscheide erfolgen. Auch das Konzept «Privacy by Design», gemäss dem die Datenbearbeitungsgrundsätze bereits bei der Entwicklung neuer Tools berücksichtigt und technisch umgesetzt werden müssen, wird Unternehmen aller Art zunehmend beschäftigen. Richtig umgesetzt, kann damit das Risiko von Datenschutzverletzungen und Cyberattacken reduziert werden.
\n\n
\n\n
Ihre Anwaltskanzlei ist spezialisiert auf internationales, europäisches und schweizerisches Datenschutzrecht, Governance, Risikomanagement und Programmimplementierung. Wie kam es zu dieser Spezialisierung?
\n\n
\n\n
Datenschutz begleitet mich schon seit meiner Assistenzzeit an der Uni Basel. Später arbeitete ich als In-House-Anwältin bei Novartis, wo ich unter anderem die Verantwortung für den globalen Datenschutz übernahm und für den Konzern das globale Datenschutzprogramm und die «Binding Corporate Rules» entwickelt und weltweit implementiert habe. In dieser Zeit konnte ich mir ein tiefgreifendes Wissen in diesem damals noch neuen Thema aneignen. Mit dieser Erfahrung machte ich mich Ende 2015 mit meiner eigenen Kanzlei selbstständig. Heute begleite ich Unternehmen, viele davon aus dem Pharma- und Life-Sciences-Sektor, von der ersten Analyse über die Risikoeinschätzung bis hin zur Entwicklung und Implementierung von Datenschutzprogrammen. Dazu gehört auch das Training von Mitarbeitenden, um ein durchgehendes Verständnis für die Relevanz des Themas zu kultivieren und Awareness zu schaffen. Um sicherzustellen, dass wir für alle Anliegen, einschliesslich IT-relevanter Themen und anderer Rechtsordnungen, die notwendige Expertise bereitstellen können, arbeiten wir mit Kooperationspartnern in unterschiedlichen Bereichen und in diversen Ländern.
\n","datum":"25.04.2022","teasertext":"
In an interview with the magazine \"Fokus Rechtsguide\", Daniela Fábián Masoch explains what companies should to in order to keep legally up to date with the ongoing digital development and to comply with new data protection laws, such as the revised Swiss Data Protection Act. Please note that the publication is only available in German.
\n","preview":"","datei":[],"linkextern":""},{"id":129,"title":"Privacy by Design as a fundamental requirement for the processing of personal data","slug":"privacy-by-design-as-a-fundamental-requirement-for-the-processing-of-personal-data","link":"/en/news-knowledge/privacy-by-design-as-a-fundamental-requirement-for-the-processing-of-personal-data","titel":"Privacy by Design as a fundamental requirement for the processing of personal data","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
Privacy by design (“PbD”) is a fundamental requirement for privacy-compliant processing of personal data and is, in principle, a well-known approach. Nevertheless, PbD is often not consistently implemented, in some cases leading to significant consequences and costs for organisations. This article describes the concept of PbD and its practical implementation under the application of the European Union (“EU”) General Data Protection Regulation (EU) 2016/679 of 27 April 2016 (“GDPR”).
\n\n
\n\n
1 Introduction
\n\n
\n\n
The ongoing development of new and complex technologies such as artificial intelligence (“AI”), blockchain, or the Internet of Things (“IoT”) and their increasing use, as well as ongoing digitisation and centralisation of data management, are leading to increasingly sophisticated ways of automating the processing of enormous amounts of data, facilitating data flows and availability, profiling consumers, customers, patients, or job applicants, and making automated decisions.
\n\n
\n\n
To reap the benefits of these technologies, digitisation, and new business models in connection with the processing of personal data, those who develop or deploy them must consider and implement applicable data protection principles and requirements through appropriate and adequate technical and organisational measures from the outset, already at the design stage, and continuously monitor, adjust and update them throughout the lifecycle of the system, product, or process.
\n\n
\n\n
With this PbD approach, a company can ensure compliance with legal requirements, meet the expectations of individuals and stakeholders, build trust, make strategic and operational decisions with foresight and efficiently implement business processes. This can include, for example, storing data on servers in the EU or Switzerland instead of in the U.S.A. or purchasing software with integrated data protection principles.
\n\n
\n\n
PbD has become a critical factor in building and maintaining trust, competitiveness and success in the marketplace.
\n\n
\n\n
2 The Concept of PbD
\n\n
\n\n
The concept of PbD is a fundamental requirement for the effective implementation of data protection. In essence, PbD requires that controllers consider data protection principles and requirements both at the design stage of systems, processes, products or services that involve the processing of personal data, and throughout the lifecycle of personal data, and that they provide for appropriate technical and organisational measures (“TOMs”) to implement data protection requirements and protect the rights of data subjects. Controllers must be proactive and anticipate potential privacy intrusions before they occur.
\n\n
\n\n
One of the fundamental elements of PbD is “privacy by default”. This concept requires that the controller implements appropriate TOMs to ensure that, by default, only personal data that is necessary to fulfil the specific purpose is processed. PbD must be implemented in terms of the amount of data collected, the scope of its processing, the duration of its storage, its security, and its accessibility.
\n\n
\n\n
While the concept of PbD has long existed as good practice, it was introduced as a legal obligation for controllers in Art. 25 GDPR, with significant fines for non-compliance. In introducing the PbD concept, the legislator primarily wanted to emphasise that it is not enough to set standards, and that the controller must also implement these standards in an effective and verifiable manner. Other laws have also adopted the concept of PbD, most recently the new Swiss Federal Act on Data Protection (“nFADP”), which is expected to come into force in 2022. However, unlike the GDPR, under the nFADP a breach of the new PbD obligation will have no direct consequences.
\n\n
\n\n
However, neither the GDPR nor the nFADP specify how the controller should implement PbD in practice.
\n\n
\n\n
So far, the introduction of processes and the designation of responsibilities for the systematic and timely assessment of the planned data processing, the technologies and systems used for this purpose and the data protection risks for the data subjects have proven effective. This risk assessment aims to identify the technical and organisational measures required to effectively integrate data protection principles and requirements into the design of the respective products, systems or processes and to protect the privacy of the data subjects. Risks to data subjects include, for example, excessive collection and disclosure of personal data, processing of data for purposes other than the original purpose, unlawful processing, as well as loss, destruction or alteration of data.
\n\n
\n\n
Such a risk assessment, coupled with a compliance assessment, is required for any processing of personal data, including, for example, the implementation of a Customer Relation Management (“CRM”) or HR data management system or the outsourcing of data processing, regardless of the technology used or the sensitivity of the data. While similar, this risk and compliance assessment is not a data protection impact assessment (“DPIA”) as required under Art. 35 GDPR.
\n\n
\n\n
A controller must conduct a DPIA only if the processing is likely to present a high risk to data subjects’ rights and freedoms. A DPIA is a broader assessment that goes beyond a compliance assessment by evaluating the residual risks to data subjects, taking into account the TOMs embedded in the design of the product, system or process. If the residual risk is still considered high, the controller must take further measures to mitigate the risk. If this is not possible, the controller must consult the data protection authority or refrain from processing. A DPIA will be regularly required for digital health solutions where health-related data or other special categories of data are processed. A DPIA will also be regularly required for the use of innovative or combined technologies and extensive profiling.
\n\n
\n\n
3 Implementing PbD In Practice
\n\n
\n\n
3.1 Technical and organisational measures
\n\n
\n\n
The controller must implement TOMs both at the time of determining the means of processing and during the processing itself. The TOMs must be adequate and appropriate to:
\n\n
\n\n
\n
effectively implement data protection principles, such as data minimisation, lawfulness, transparency, confidentiality, purpose limitation, data integrity, storage duration, security, as well as the requirements concerning commissioned data processing and cross-border data transfers;
\n
integrate the necessary safeguards into the processing to meet the requirements of the GDPR; and
\n
protect the rights of data subjects.
\n
\n\n
\n\n
A measure is adequate if it considers state of the art, the cost of implementation, the nature, scope, context and purposes of the processing, and the risks of varying likelihood and severity to natural persons’ rights and freedoms.
\n\n
\n\n
Technical measures may include, for example:
\n\n
\n
robust encryption methods for systems and data;
\n
pseudonymisation or aggregation of the data;
\n
access authorisations and restrictions;
\n
user authentication;
\n
firewalls; and
\n
automated deletion concepts.
\n
\n\n
\n\n
Organisational measures may include, for example:
\n\n
\n
the assignment of responsibilities for the effective implementation of data protection requirements;
\n
the implementation of enforceable policies and procedures for handling and documenting data privacy violations and requests for information from data subjects, risk management, third-party vendor management, data transfer management, and the documentation of processing activities;
\n
the implementation of training and controls; and
\n
the establishment of processes to ensure data protection rights, such as revoking consent or requesting erasure of the data.
\n
\n\n
\n\n
3.2 Data Protection Management System
\n\n
\n\n
One effective way to implement PbD in practice is to build a data management and risk assessment programme with responsibilities and a process to systematically identify, evaluate, address and mitigate potential privacy and security risks associated with the collection and processing of personal data. A Data Protection Management System should include the following elements:
\n\n
\n\n
\n
a documented commitment by the company’s management to establish and enforce high standards of data protection for the company, to integrate data protection into the corporate culture and embed the data protection principles in the design and implementation of corporate policies, data protection management systems, business practices, services and products;
\n
\n\n
\n
the appointment of a data protection officer or advisor and the allocation of responsibilities at all levels of the organisation, including business units and functions, for the effective implementation of data protection requirements;
\n
the establishment of a data protection framework with enforceable data protection policies and guidelines that attach appropriate importance to data protection and regulate the collection, processing, transfer, storage and deletion of data, as well as mechanisms to monitor implementation and compliance with standards and rules;
\n
the application of appropriate processes to ensure that data protection principles and requirements are adequately taken into account and integrated into data processing procedures and that the PbD principle is thus lived;
\n
\n\n
\n
the introduction of records of processing activities (“RoPA”);
\n
risk management with risk assessments, compliance checks and, where appropriate, data protection impact assessments;
\n
third-party management and data transfer governance;
\n
regular and documented awareness campaigns and conducting employee trainings; and
\n
regular and documented monitoring and controls through self-assessments and audits to verify the effective implementation of the data protection management programme and compliance with legal requirements and internal policies and directives.
\n
\n\n
\n\n
3.3 Data protection considerations and design strategies
\n\n
\n\n
Applicable laws
\n\n
The controller must clarify the applicable laws and regulations. In particular, organisations outside the EU must determine whether the GDPR applies to them and their activities. The controller should also check whether industry-specific codes of conduct, certification systems, regulatory decisions or guidelines apply to the planned data processing and take into account ethical considerations.
\n\n
\n\n
Involved parties
\n\n
It is then necessary to identify which parties are involved in the data processing or the development and use of the system, service or product, and their role (e.g., controller or processor). Several parties may be jointly responsible for the data processing. Identifying the data controller, i.e., the party that alone or jointly with others decides the means and purposes of data processing, is essential to determine who is responsible and accountable for compliance with data protection requirements under the GDPR.
\n\n
\n\n
Legal justification
\n\n
For all personal data processing, controllers must rely on one of the legal bases set out in Art. 6 and 9 of the GDPR, most used are: the legitimate interest; performance of a contract; legal obligation; or consent.
\n\n
\n\n
In health or medical apps collecting and processing special categories of patient or consumer data, the processing of this data will regularly require the data subjects explicit consent. In this case, consent must be voluntary and specific to each functionality that serves a distinct purpose. Consent must further be based on prior information. In the case of special categories of data, the use of cookies or location data, the data subject must provide explicit consent through positive action, such as downloading the app and ticking a consent box. Also, controllers must have a procedure in place that allows for easy withdrawal of consent and, on the other hand, ensures that in the event of withdrawal, the data collected will not be further processed.
\n\n
\n\n
Proportionality and data minimisation
\n\n
Personal data must be adequate, relevant, and limited to what is necessary for the purposes for which it is processed. This means that systems, apps and devices that store or process personal data should be set up so that only the data necessary for the individual purpose or the proper functioning of the system, app or device is stored and processed.
\n\n
\n\n
The principle of data minimisation can be achieved in different ways, for example, by reducing the amount of personal data collected and processed or by making it more difficult or impossible to assign the data to an individual.
\n\n
\n\n
Depending on the functionalities of the system, app or product and the purpose of the processing, the controller must therefore assess for each data set to be collected whether this data is indeed necessary to fulfil the purpose or whether the purpose can be fulfilled with less data (reduction of data volume) or pseudonymised/anonymised data (making identification difficult or impossible). A further distinction must be made between mandatory data and voluntary data that can be additionally provided for the use of certain functionalities.
\n\n
\n\n
Another measure that the controller can take to achieve the data minimisation requirement is to prevent the linking of personal data stored in different systems for different purposes.
\n\n
\n\n
Transparency and fair processing
\n\n
Personal data must be processed transparently and fairly. Data subjects should have full transparency and control over the processing of their data and understand what data is being processed, why, by whom, where and for how long, and how they can exercise their data protection rights. The processing of personal data should neither violate applicable laws, nor be unexpected to the data subject.
\n\n
\n\n
The privacy notice should be easily accessible to data subjects at any time, before the collection of personal data and throughout the processing. Users of apps, for example, should be notified before the download of the app. The notice should be easy to understand and, where appropriate, translated in different languages.
\n\n
\n\n
Confidentiality and access to personal data
\n\n
Personal data must be kept strictly confidential and may only be provided or disclosed to individuals on a need-to-know basis to fulfil the legitimate purposes for which the data was collected.
\n\n
\n\n
Special attention is required for centralised data management systems. In this case, the controller should establish data access and restriction policies and limit the access through technical means.
\n\n
\n\n
Purpose limitation
\n\n
Personal data shall only be collected for specified, explicit and legitimate purposes and shall not be further processed in a way incompatible with those purposes.
\n\n
\n\n
The controller should determine the processing purposes and communicate them to the data subjects. The functionalities of the system, app or product should be set up to ensure that personal data is only processed for these purposes. The controller must also determine who should have access to which data for which purposes and implement these regulations through technical measures as well as instructions, training and controls.
\n\n
\n\n
If the personal data is to be processed later for purposes other than those communicated, it should be anonymised, unless there is another legal basis for this secondary use. In any case, data subjects should be informed in advance about the use of their data for any secondary purpose and, unless there is another legal basis, their consent should be obtained.
\n\n
\n\n
Data quality
\n\n
The personal data stored must be accurate and, where necessary, kept up to date, and all reasonable steps must be taken to ensure that inaccurate personal data is erased or rectified without delay.
\n\n
\n\n
The controller must have mechanisms in place to ensure that data is accurate at the time of collection and is not unlawfully altered thereafter. There must be a mechanism to correct or delete inaccurate data.
\n\n
\n\n
Data retention
\n\n
Personal data must be kept in a form that permits the identification of data subjects for no longer than is necessary for the purposes for which the personal data is processed, unless regulatory or legal requirements necessitate a longer or shorter retention period.
\n\n
\n\n
The controller should establish a data retention and deletion policy and determine a retention period for each data set based on the purpose of the processing and, where applicable, legal and regulatory retention periods.
\n\n
\n\n
The controller must also define mechanisms, including automated solutions where appropriate, and responsibilities for the effective deletion of data. If the data cannot be deleted, it must be anonymised or, if this is not possible, pseudonymised.
\n\n
\n\n
Data security
\n\n
Personal data must be processed in a manner that ensures appropriate security of the data, including protection against unauthorised or unlawful processing and accidental loss, destruction or damage, using appropriate TOMs. These measures should include data integrity and confidentiality, availability, resilience and traceability, and ensure a level of security appropriate to the risk to the rights of data subjects.
\n\n
\n\n
Appropriate control access mechanisms and authentication measures should be embedded in the system infrastructure to detect and monitor unauthorised access to data. Personal data should be protected by strong and robust state-of-the-art encryption, both in transit and in storage. Special attention is required when data is stored in the cloud.
\n\n
\n\n
Privacy rights
\n\n
Data subjects have various data protection rights, including the right to information, access, rectification and erasure, restriction of processing, data portability and the right to object to automated individual decision-making. They also have the right to complain to the competent supervisory authority if they feel their rights are being violated or their data is not adequately protected. The controller must define processes to ensure that data can be corrected, deleted or transferred at the data subjects’ legitimate request. For apps in particular, the controller should consider whether users should be able to exercise their rights directly through the app, if necessary, by accessing the data and correcting or deleting it if inaccurate.
\n\n
\n\n
Data processing by third parties and cross-border data transfers
\n\n
Depending on the roles of the contributors in the development, management and use of the system, app or product and the data processed, the controller must establish appropriate contractual obligations to ensure data protection.
\n\n
\n\n
Before sharing any personal data with a processor, the controller must verify that the processor implements appropriate TOMs to ensure compliance with the data protection requirements and data subjects’ privacy rights.
\n\n
\n\n
If personal data is to be transferred to third parties outside the European Economic Area (“EEA”) to a country without a formal adequacy decision by the European Commission, appropriate safeguards, such as EU standard contractual clauses (“SCCs”), must be implemented to legitimise cross-border data transfers, unless an exemption pursuant to Art. 49 GDPR applies, such as the explicit consent of the data subject.
\n\n
\n\n
Before transferring the data, the controller, respectively the data exporter, must check whether the destination country ensures an adequate protection level equivalent to that in the EU. If this is not the case, the data exporter should consider storing and processing the data in the EU or an adequate country. If this is not an option, additional contractual, technical and organisational measures must be taken, such as pseudonymisation or encryption of the data while keeping the encryption key in the EU and separate from the service provider.
\n\n
\n\n
4 Conclusion
\n\n
\n\n
Consistent and sustainable compliance with data protection requires the strategic and conceptual integration of data protection principles in all business practices, the organisational structure, the development of rules, IT systems and products.
\n\n
\n\n
To fully exploit the benefits of new technologies and ensure their effectiveness, it is essential to embed fundamental data protection principles into the design of these solutions, taking into account organisational, process and system-related risks, as well as risks to the rights of data subjects.
\n\n
\n\n
PbD is not only required by the GDPR and partly by laws of other countries outside the EEA. It is a prerequisite for the effective and sustainable implementation of data protection, the basis for the smooth functioning of data protection management, and a critical factor in achieving the necessary trust of employees, customers, patients and consumers, public authorities, business partners and other stakeholders in the use of new technologies and the processing of their personal data.
\n\n
\n","datum":"06.07.2021","teasertext":"
Privacy by Design (\"PbD\") is a fundamental requirement for privacy-compliant processing of personal data and is, in principle, a well-known approach. Nevertheless, PbD is often not consistently implemented, in some cases leading to significant consequences and costs for organizations. This article describes the concept of PbD and its practical implementation under the application of the EU General Data Protection Regulation.
\n","preview":"","datei":[],"linkextern":""},{"id":130,"title":"Revised Swiss Data Protection Act - what do companies have to do? (in German)","slug":"das-revidierte-datenschutzgesetz-handlungsbedarf-fuer-unternehmen","link":"/en/news-knowledge/das-revidierte-datenschutzgesetz-handlungsbedarf-fuer-unternehmen","titel":"Revised Swiss Data Protection Act - what do companies have to do? (in German)","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
Das revidierte Datenschutzgesetz - Handlungsbedarf für Unternehmen?
\n\n
\n\n
Das Schweizer Parlament hat im September 2020 das revidierte Datenschutzgesetz verabschiedet, welches voraussichtlich 2022 in Kraft treten wird. Daniela Fábián Masoch, Rechtsanwältin und Datenschutzexpertin, erklärt, welche Pflichten auf Unternehmen zukommen und wie sich diese vorbereiten können.
\n\n
\n\n
Datenschutz hat in den vergangenen Jahren stark an Bedeutung gewonnen. Konsumenten, Kunden, Patienten und Arbeitnehmer, aber auch Führungskräfte und Behörden sind zunehmend sensibilisiert und haben hohe Erwartungen an den Schutz von Personendaten. Infolgedessen wurden die Datenschutzgesetze weltweit entsprechend verschärft.
\n\n
\n\n
Unter dem revidierten Schweizer Datenschutzgesetz (nDSG) bleibt die Bearbeitung von Personendaten grundsätzlich erlaubt. Unternehmen müssen aber in Zukunft eine ganze Reihe neuer oder erweiterter Vorschriften befolgen.
\n\n
\n\n
Welche neuen Pflichten kommen auf Unternehmen zu?
\n\n
\n\n
Erweiterte Informationspflicht: Künftig müssen Unternehmen betroffene Personen bei der Beschaffung von Personendaten informieren (bisher nur besonders schützenswerte Daten und Persönlichkeitsprofile), wobei das Gesetz Mindestangaben vorschreibt. Konkret bedeutet dies, dass Unternehmen ihre Datenschutzerklärungen überprüfen und ggf. anpassen oder komplett neu erstellen und den betroffenen Personen mitteilen müssen.
\n\n
\n\n
Privacy by Design (PbD): Unternehmen sind künftig verpflichtet, geplante Datenbearbeitungen so auszugestalten, dass die datenschutzrechtlichen Vorschriften und die Grundsätze der Datenbearbeitung eingehalten werden. PbD ist jedoch nicht bloss als neue Verpflichtung zu verstehen, sondern vielmehr als Grundvoraussetzung für einen verantwortungsvollen und effektiven Datenschutz. Eine wirksame Umsetzung der Datenschutzgrundsätze setzt voraus, dass Unternehmen proaktiv handeln und potenzielle Risiken für die Privatsphäre von betroffenen Personen antizipieren.
\n\n
\n\n
Datenschutz-Folgenabschätzung: Unternehmen müssen künftig für Datenbearbeitungen, die ein hohes Risiko für die Persönlichkeit oder die Grundrechte der betroffenen Person mit sich bringen können, eine Datenschutz-Folgenabschätzung durchführen. Sie müssen die Risiken für die betroffene Person vorgängig bewerten und geeignete Massnahmen zum Schutz ihrer Persönlichkeit und Grundrechte ergreifen. Dies kann beispielsweise bei einer umfangreichen Bearbeitung von besonders schützenswerten Daten der Fall sein, aber auch bei der Verwendung neuer Technologien.
\n\n
\n\n
Verzeichnis der Bearbeitungstätigkeiten: Unternehmen sind neu grundsätzlich verpflichtet, ein Verzeichnis ihrer Bearbeitungstätigkeiten zu führen. Ein solches Verzeichnis kann, wenn es sorgfältig geführt und mit zusätzlichen Informationen ergänzt wird, durchaus einen Vorteil haben, nämlich als Grundlage für Konformitätsprüfungen und Datenschutz-Folgenabschätzungen dienen.
\n\n
\n\n
Meldung von Verletzungen der Datensicherheit: Wie bereits unter der EU-Datenschutz-Grundverordnung (DSGVO) müssen Unternehmen in Zukunft Verstösse der Datensicherheit (wie z. B. unberechtigte Datenzugriffe) je nach Risiko dem Eidgenössischen Datenschutz- und Öffentlichkeitsbeauftragten (EDÖB) melden und die betroffenen Personen informieren.
\n\n
\n\n
Welche Sanktionen drohen Unternehmen, wenn sie die gesetzlichen Anforderungen nicht einhalten?
\n\n
\n\n
Im Unterschied zur DSGVO wird grundsätzlich nicht das Unternehmen, sondern die verantwortliche natürliche Person mit Bussgeldern von bis zu CHF 250'000 belegt. Strafbar macht sich insbesondere, wer gegen die Informations- oder Auskunftspflicht verstösst oder die Sorgfaltspflichten verletzt, namentlich die Mindestanforderungen an die Datensicherheit nicht einhält, Personendaten ins Ausland bekanntgibt oder die Datenbearbeitung einem Auftragsbearbeiter überträgt, ohne die gesetzlichen Anforderungen zu erfüllen. Bussen setzen allerdings eine vorsätzliche Handlung voraus und werden in den meisten Fällen nur auf Antrag verhängt.
\n\n
\n\n
Handlungsbedarf für Unternehmen?
\n\n
\n\n
Da das nDSG keine Übergangsfristen vorsieht, sollten Unternehmen frühzeitig prüfen, inwieweit ihre internen Regelungen und Prozesse betreffend Datenmanagement mit den neuen Anforderungen übereinstimmen.
\n\n
\n\n
Insbesondere müssen Konzepte wie Privacy by Design umgesetzt und Prozesse eingeführt werden, die eine gesetzeskonforme Löschung oder Vernichtung der Daten und die Datenportabilität unterstützen sowie die Durchführung von Datenschutz-Folgenabschätzungen und die rechtzeitige Meldung von Datensicherheitsverstössen sicherstellen. Datenschutzerklärungen müssen überprüft und gegebenenfalls an die Anforderungen des nDSG angepasst werden. Verzeichnisse, die derzeit Datensammlungen dokumentieren, müssen neu strukturiert werden, um zukünftig Bearbeitungsaktivitäten zu erfassen.
\n\n
\n","datum":"26.02.2021","teasertext":"
In September 2020, the Swiss Parliament adopted the revised Data Protection Act, that is expected to enter into force in 2022. In an article published in the Bilanz magazine, Daniela Fábián Masoch explains the new obligations for companies and what they can do in order to be prepared. Please note that the publication is only available in German.
\n","preview":"","datei":[],"linkextern":""},{"id":131,"title":"EU personal data transfers 2021: Planning for a year of increased scrutiny","slug":"eu-personal-data-transfers-2021-planning-for-a-year-of-increased-scrutiny","link":"/en/news-knowledge/eu-personal-data-transfers-2021-planning-for-a-year-of-increased-scrutiny","titel":"EU personal data transfers 2021: Planning for a year of increased scrutiny","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
By Dan Goldstein, Co-Founder, Tueoris, LLC and Daniela Fábián Masoch, Founder FABIAN PRIVACY LEGAL
\n\n
\n\n
As 2021 begins, ex-EU transfers of personal data continue to pose a challenge for data privacy professionals. While new Standard Contractual Clauses (“SCCs”) appear promising, the lingering impact of the Schrems II decision along with the European Data Protection Board’s Draft Recommendations on Measures that Supplement Transfer Tools1 (the “EDPB Recommendations”) are likely to leave exporters and importers of European resident personal data spending valuable time focused on data transfer risk mitigation strategies.
\n\n
\n\n
Across Europe, Data Protection Authorities maintain a consistent view that countries with laws or practices that allow government “generalized” access to the content of electronic communications do not provide privacy safeguards essentially equal to those in EU member states. Such laws or practices are viewed as impinging on the effectiveness of safeguards contained in the EU General Data Protection Regulation (“GDPR”). Parties relying on SCCs or Binding Corporate Rules (“BCRs”) for transfers to such countries must identify and implement, on a case-by-case basis, supplementary measures that elevate protections to a level equal to EU law.
\n\n
\n\n
Prior to determining whether such measures will be adequate, parties to a transfer should – in line with the EDPB Recommendations – undertake to ascertain a complete view of the data transfers taking place within the lifecycle of defined processing activities. Upon gaining a holistic view of these data flows, the parties should then conduct Transfer Impact Assessments (“TIAs”) to determine risks the transfers to data importers and sub-processors pose to the data subjects, as well as compliance risks faced by the parties to the transfers. Where those TIAs uncover risks of government access to personal data, supplementary controls will be necessary. However, controls considered adequate by EU authorities may be limited.
\n\n
\n\n
Know Your Data Flows
\n\n
\n\n
The logical starting point for compliant ex-EU personal data transfers is to fully understand where EU personal data is flowing within and outside of your organization. The EDPB acknowledges in its Recommendations that “recording and mapping all transfers can be a complex exercise”, but also stresses that awareness of personal data flows is “necessary to ensure that it is afforded an essentially equivalent level of protection wherever it is processed”.
\n\n
\n\n
Since the GDPR came into effect in 2018, most organizations processing EU resident personal data have spent time and effort to understand the flow of such data, typically by recording the characteristics of processing activities in accordance with GDPR Article 30. However, Article 30 records often fall short in capturing a holistic view of personal data flows across an organization’s third-party ecosystem and the countries in which those parties are located.
\n\n
\n\n
Conducting a thorough and detailed exercise to create visual depictions of data flows (i.e., data mapping) enables the identification of transfers not only to ex-EU importers, but also subsequent third-party transfers throughout the personal data lifecycle .
\n\n
\n\n
To design and implement reasonable security controls, the organization must first understand the nature of the data that must be secured. A successful data mapping initiative will not only map the flow of personal data, but also identify and depict the specific personal data elements involved in the process, facilitating the development of tailored safeguards necessary for each transfer throughout the data lifecycle. These detailed data maps become a highly valuable tool, not only to determine security controls commensurate to the risks to the data subjects, but also to demonstrate appropriate diligence to regulatory authorities should transfers come under scrutiny.
\n\n
\n\n
Transfer Impact Assessments
\n\n
\n\n
Overview
\n\n
\n\n
In line with the EDPB Recommendations, it has become imperative to conduct a TIA prior to transferring EU resident personal data to parties in non-adequate countries2. TIAs must be conducted for prospective transfers of EU data to recipients in non-adequate countries, as well as current, ongoing transfers (and should assess any onward transfers). As such, in addition to conducting TIAs for transfers identified in the data mapping exercise, a TIA should be triggered prior entering into contracts with service providers that will require ex-EU transfers of EU personal data.
\n\n
\n\n
A thorough TIA will consider numerous risk factors, however whether the laws or practices of the country where the importer is located impinge on the effectiveness of the safeguards of the transfer tool being used (e.g., SCCs) is of primary importance to EU authorities. For transfers of EU personal data to the US, the prevailing EU view is that Section 702 of the U.S. Foreign Intelligence Surveillance Act does not adequately safeguard privacy rights under EU law. Thus, transfers being made to US recipient using transfer mechanisms such as SCCs or BCRs must be supplemented with additional measures to limit government access. Notably, even considering what may be viewed as a rather black or white view of Section 702, the EDPB Recommendations do recognize that an organization’s TIAs should consider the context of the specific transfer – an important point, as different activities will carry widely different risks of government access.
\n\n
\n\n
Conducting the TIA
\n\n
\n\n
TIAs must be conducted diligently and be thoroughly documented, as Data Protection Authorities will expect a TIA to be available if a transfer comes under their scrutiny. Developing and implementing a standard and repeatable TIA methodology supports outcomes that meet EU authorities’ expectations.
\n\n
\n\n
A TIA which includes a series of questions with “scored” answers allows the organization to consistently quantify results and create requirements for completed TIAs that fall within various score ranges. For example, a score within a defined low-risk range might allow a transfer to go ahead without further action. A score within a defined medium-risk range might require implementation of supplementary measures to bring the level of protection to an EU level, and review and approval by the Chief Privacy Officer. A score within a defined high-risk range might require review by the Chief Privacy Officer and may lead to a decision to suspend or stop the transfer.
\n\n
\n\n
The EDPB emphasizes that the TIA should primarily focus on the laws of the country to which the transfer will be made, and, specifically, on factors indicating whether government authorities in that country will seek access to the data. In addition to these objective factors, it is useful – in order to obtain an overall risk score indicating appropriate technical, contractual and organizational measures – to consider other aspects of the data and transfer as well (“context”). This context helps to establish relative likelihood of government requests for EU personal data for transfers made for widely disparate purposes. For example, a transfer initiated by a data subject to manage their customer preferences will pose different risks of government access than a transfer of a large volume of personal data of EU resident social media users to a US importer.
\n\n
\n\n
In establishing the TIA risk criteria, consideration should be given to additional factors such as:
\n\n
\n\n
\n
Purpose of the transfer;
\n
Exporting party (category);
\n
Data subject type;
\n
Types of data transferred;
\n
Volume of data transferred;
\n
Manner in which access is provided to the importer (e.g., limited push or unlimited pull);
\n
Frequency of transfers;
\n
Onward transfers (including category of sub-processor and purpose); and
\n
Security controls in transit;
\n
Importer security controls;
\n
History of government access requests to the importer; and
\n
History of government access requests to similarly situated importers.
\n
\n\n
\n\n
While the EDPB does not place much value in evaluation of historical government requests to the importing organization or other similarly situated organizations, these factors should be considered so that the parties conducting the TIA can gain an internal understanding of the actual risks of government requests and develop an appropriate response strategy.
\n\n
\n\n
Remediating Identified Risks
\n\n
\n\n
Upon completing the TIA and ascertaining the risk score, along with defined requirements aligned to the scores, it may be necessary to take steps to remediate risks and, as the EDPB Recommendations state, “bring the level of protection of the data transferred up to the EU standard of essential equivalence”.
\n\n
\n\n
Technical Controls
\n\n
\n\n
Significant attention has been focused on encryption of personal data in transit to, and at rest in, the recipient in the ex-EU country. The EDPB Recommendations specify that in those circumstances where encryption may be appropriate, it will only be considered an effective control if the encryption keys are maintained by the EU-based exporter, other entities in the EEA, or an ex-EU country with an adequacy designation. In other words, if a US-based importer holds the encryption key, the control will likely not be considered effective by EU authorities.
\n\n
\n\n
The Recommendations call out the common scenario3 in which a data importer – in a country in which the government may access the personal data (e.g., the US) – uses EU personal data to provide services to the EU controller (e.g., payroll or other HR-focused services). The EDPB takes the position that if the importer in such a scenario is able to use the data in the clear, even encryption in transit and at rest will not provide an adequate level of protection of the rights of the data subjects, as the government could compel production of the data.
\n\n
\n\n
The logical outcome of strict adherence to this position appears to be a new level of EU data localization. In such instances, exporters and importers may need to evaluate alternatives (e.g., storage and processing of data in the EEA or in an adequate country). If data localization is not an option, the parties may consider a risk-based decision to move forward with the transfer, implementing supplemental organizational and contractual controls4 in order to continue business operations in a manner beneficial to shareholders, employees and other interested parties. Where the risks are deemed to be too high, the parties may need to either suspend or stop further transfers.
\n\n
\n\n
Where appropriate, depending on the context of the transfer, pseudonymization may also present an adequate control. However, in accordance with the EDPB Recommendations, any additional information that would allow the identification of individuals whose personal data is transferred, must be held by the exporter either in the EU or other adequate country (this is a common scenario, for example, in the conduct of clinical trials). In addition, the parties should establish in the TIA that the individuals cannot be identified by public authorities by cross-referencing the pseudonymized personal data with additional information that the authorities may possess.
\n\n
\n\n
Contractual Limitations
\n\n
\n\n
Based on the context of the transfers taking place, contractual provisions may comprise additional controls supporting the compliant transfer of EU personal data. Contractual provisions may include:
\n\n
\n\n
\n
Limitations on the data being transferred, for example, only specified data subjects or data elements;
\n
Requirements for technical measures which must be implemented for the transfers to take place;
\n
A commitment to inform the EU data controller of government requests for personal data and – where commercially feasible and permitted by applicable law – to inform data subjects of such requests; and/or
\n
A binding commitment by the importer to challenge government requests, including efforts to delay response to requests pending resolution of the challenge.
\n
\n\n
\n\n
Contractual limitations should be drafted considering other contractual obligations that may already be in place, for example in SCCs or in an organization’s BCRs.
\n\n
\n\n
Administrative Controls
\n\n
\n\n
Administrative controls represent a further means for organizations importing personal data of EU residents to a non-adequate country to safeguard such personal data – where appropriate – from government access. Controls may include updating internal privacy policies and procedures to include detailed actions in the event of government requests. Such provisions may detail, for example, the process for the intake and response to requests, including review by appropriate internal stakeholders in the EU and in the country from which the government request is made. They may also document the organization’s commitments to inform data subjects of such requests and, where appropriate, to challenge government requests.
\n\n
\n\n
In addition, personnel who may be tasked with the intake, review and disposition of requests should receive training on internal procedures for managing government requests for access to personal data.
\n\n
\n\n
Final Thoughts
\n\n
\n\n
As we enter a new year, the state of ex-EU data transfers remains a moving target. While anticipated new SCCs are promising – particularly the processor-to-processor and processor-to-controller SCCs – they do not mitigate the risk of access to EU personal data by governments in non-EU countries. The EDPB Recommendations provide highly valuable guidance, but ultimately include some conclusions that point to EU data localization. In order to minimize risks associated with data transfers, organizations should (in line with EDPB Recommendations) undertake detailed data mapping exercises for processing activities which include transfers of EU resident personal data and conduct detailed TIAs to identify risks related to the transfers. A consistent approach to mapping and TIAs will not only provide information necessary to implement appropriate data protection controls, but will also demonstrate to EU regulatory authorities that your organization takes compliance with transfer rules seriously, and has taken appropriate measures to safeguard the privacy rights of EU residents.
[2] The EDPB Recommendations state that, “you must assess. . . if there is anything in the law or practice of the third country that may impinge on the effectiveness of the appropriate safeguards of the Article 46 GDPR transfer tool you are relying on, in the context of your specific transfer.”
[4] Such supplemental controls may include, for example, a documented commitment to challenge compelled government disclosure of personal data.
\n","datum":"26.01.2021","teasertext":"
As 2021 begins, ex-EU transfers of personal data continue to pose a challenge for data privacy professionals. The following article explains what organizations can do in order to minimize risks associated with data transfers.
\n","preview":"","datei":[],"linkextern":""},{"id":132,"title":"The EU Commission launches public consultation on revised SCC","slug":"die-europaeische-kommission-veroeffentlicht-entwurf-der-revidierten-standardvertragsklauseln","link":"/en/news-knowledge/die-europaeische-kommission-veroeffentlicht-entwurf-der-revidierten-standardvertragsklauseln","titel":"The EU Commission launches public consultation on revised SCC","text":"
On 12 November 2020, the EU Commission launched public consultation (until 10 December) on revised Standard Contractual Clauses (SCC). Please click here to download the Commission implementing decision and the Annex with the proposed clauses.
\n","datum":"12.11.2020","teasertext":"
On 12 November 2020, the EU Commission launched public consultation (until 10 December) on revised Standard Contractual Clauses (SCC). Please click here to download the Commission implementing decision and the Annex with the proposed clauses.
\n","preview":"","datei":[],"linkextern":""},{"id":133,"title":"The EDPB releases recommendations on cross-border data transfers","slug":"the-edpb-releases-recommendations-on-cross-border-data-transfers","link":"/en/news-knowledge/the-edpb-releases-recommendations-on-cross-border-data-transfers","titel":"The EDPB releases recommendations on cross-border data transfers","text":"
On 11 November 2020, the EDPB released two recommendations regarding cross-border data transfers. Public consultation is running until 30 November 2020.
\n\n
\n\n
\n
Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data (these recommendations provide data exporters with a series of steps to follow, potential sources of information, and some examples of supplementary measures that could be put in place), and
\n
\n\n
\n\n
\n
Recommendations 02/2020 on the European Essential Guarantees for surveillance measures (these recommendations provide elements to examine whether surveillance measures allowing access to personal data by public authorities in a third country can be regarded as a justifiable interference or not).
\n
\n\n
\n\n
To download the recommendations, please click on the following links:
On 11 November 2020, the EDPB released two recommendations regarding cross-border data transfers. Public consultation is running until 30 November 2020.
\n","preview":"","datei":[],"linkextern":""},{"id":153,"title":"Privacy by Design as an opportunity for companies (in German)","slug":"privacy-by-design-as-an-opportunity-for-companies","link":"/en/news-knowledge/privacy-by-design-as-an-opportunity-for-companies","titel":"Privacy by Design as an opportunity for companies (in German)","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
Privacy by Design als Chance für Unternehmen
\n\n
\n\n
Das Schweizer Parlament hat kürzlich das revidierte Datenschutzgesetz verabschiedet. Neu gilt der Grundsatz des sogenannten «Privacy by Design». Die korrekte Umsetzung dieses Prinzips ist die Grundvoraussetzung für einen verantwortungsvollen und effektiven Datenschutz und trägt entscheidend zum Erfolg eines Unternehmens bei. Daniela Fábián, Rechtsanwältin und Datenschutzexpertin, erläutert den Grundsatz und seine praktische Umsetzung.
\n\n
\n\n
Datenschutz hat in den vergangenen Jahren stark an Bedeutung gewonnen. Konsumenten, Kunden, Patienten und Arbeitnehmer sowie Unternehmensführer und Behörden sind zunehmend sensibilisiert und haben höhere Erwartungen an den Schutz von Personendaten. Infolgedessen wurden Datenschutzgesetze weltweit entsprechend verschärft.
\n\n
\n\n
Während viele Unternehmen bis vor Kurzem kaum Ressourcen für den Datenschutz bereitgestellt haben, ist den meisten Unternehmen inzwischen bewusst, dass Datenschutz ein ernst zu nehmendes Thema ist. Grund hierfür sind nicht nur drohende Sanktionen und Reputationsverlust im Falle einer Verletzung der Datenschutzvorschriften, sondern dass Unternehmen verstanden haben, dass sie die Vorteile neuer Technologien wie Blockchain, Machine Learning, Künstliche Intelligenz, Internet of Things oder autonomes Fahren nur dann voll ausschöpfen können, wenn sie gleichzeitig die Erwartungen der betroffenen Personen erfüllen, ihr Vertrauen gewinnen sowie deren Privatsphäre respektieren.
\n\n
\n\n
Verantwortungsvoller und effektiver Datenschutz setzt voraus, dass Unternehmen die grundlegenden Datenschutzgrundsätze wie Datenminimierung und Transparenz sowie technische Sicherheitsmassnahmen wie Pseudonymisierung oder Verschlüsselung bereits bei der Konzeption von digitalen Lösungen und generell in jegliche Datenbearbeitung integrieren. Diesen Ansatz nennt man «Privacy by Design», kurz «PbD».
\n\n
\n\n
Das Schweizer Parlament hat nun diesen Grundsatz unter dem Titel «Datenschutz durch Technik und datenschutzfreundliche Voreinstellungen» im revidierten Datenschutzgesetz verankert.
\n\n
\n\n
Was bedeutet Privacy by Design für Unternehmen?
\n\n
\n\n
PbD ist nicht bloss eine neue Verpflichtung für Verantwortliche. PbD ist vielmehr Grundvoraussetzung für verantwortungsvollen Datenschutz. Um Datenschutzgrundsätze wirksam umzusetzen, müssen Unternehmen proaktiv handeln und potenzielle Risiken für die Privatsphäre von betroffenen Personen antizipieren.
\n\n
\n\n
Unternehmen, die z. B. ein neues Datenmanagementsystem einführen, eine App entwickeln, sensible Daten in einer Cloud speichern, Überwachungssysteme im Unternehmen einführen oder die Bearbeitung von Personendaten an Dritte ins Ausland verlagern wollen, müssen sich schon früh über potenzielle Auswirkungen und Risiken für die betroffenen Personen und deren Daten im Klaren sein.
\n\n
\n\n
Bei der Entwicklung einer App z. B. muss ein Unternehmen bereits in der Designphase prüfen, ob und wenn ja, welche Personendaten für die Nutzung erforderlich sind und wie technisch sichergestellt wird, dass nicht mehr Daten als erforderlich erhoben werden. Wo und wie lange werden die Daten gespeichert, in der App oder auf einem zentralen Server, im In- oder Ausland? Wer soll auf die Daten Zugriff haben und warum? Sind Dienstleister involviert und wenn ja, wie wird sichergestellt, dass auch sie die Datenschutzvorschriften einhalten? Wie wird technisch sichergestellt, dass die Nutzer vor dem Download der App die Datenschutzerklärung sehen und gegebenenfalls in die Datenbearbeitung einwilligen sowie ihre Rechte geltend machen können, dass die Daten nicht für andere Zwecke bearbeitet werden und bei Bedarf gelöscht oder herausgegeben werden können? Welche technischen Massnahmen sind erforderlich, um die Daten vor Cyberrisiken zu schützen?
\n\n
\n\n
Mit diesem Ansatz kann das Unternehmen nicht nur die Einhaltung der gesetzlichen Anforderungen sicherstellen, sondern bereits im Vorfeld strategische und operative Entscheidungen treffen und Geschäftsprozesse effizient umsetzen. Dazu können z. B. die Speicherung von Daten auf Servern in der Schweiz statt in den USA oder der Kauf von Software mit integriertem Datenschutz gehören.
\n\n
\n\n
Wie können Unternehmen Privacy by Design in der Praxis umsetzen?
\n\n
\n\n
Eine wirksame Möglichkeit, PbD in der Praxis umzusetzen, ist ein Datenschutzmanagement- und Risikobewertungsprogramm mit Verantwortlichkeiten und einem Prozess zur systematischen Identifizierung, Bewertung, Behandlung und Minderung potenzieller Datenschutz- und Sicherheitsrisiken im Zusammenhang mit der Datenbearbeitung aufzubauen. Durch systematische Konformitäts- und Risikoprüfungen können Unternehmen notwendige und geeignete Massnahmen bestimmen, um die Einhaltung der Datenschutzgrundsätze sicherzustellen und Risiken für die betroffenen Personen, und damit verbunden für das Unternehmen selbst, zu reduzieren.
\n\n
\n\n
Privacy by Design ist ein entscheidender Faktor für den Aufbau und die Aufrechterhaltung von Vertrauen, Wettbewerbsfähigkeit und Erfolg auf dem Markt. Unternehmen sollten PbD also durchaus als Chance begreifen.
\n\n
\n","datum":"31.10.2020","teasertext":"
The Swiss Parliament recently adopted the revised Data Protection Act, which newly introduces the concept of “privacy by design”. The correct implementation of this concept is the basis for responsible and efficient data protection and a decisive factor for the success of each company. In an article published in the Bilanz (Fokus Business Success) magazine, Daniela Fábián Masoch explains the concept and its practical implementation. Please note that the publication is only available in German.
\n","preview":"","datei":[],"linkextern":""},{"id":128,"title":"The new Swiss Data Protection Act - the most significant changes for companies","slug":"das-neue-schweizer-datenschutzgesetz-die-wichtigsten-neuerungen-fuer-unternehmen","link":"/en/news-knowledge/das-neue-schweizer-datenschutzgesetz-die-wichtigsten-neuerungen-fuer-unternehmen","titel":"The new Swiss Data Protection Act - the most significant changes for companies","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
On 25 September 2020, the Swiss Parliament adopted the revised Federal Act on Data Protection (FADP-new).1 The Federal Council will decide on the entry into force after the 100-day referendum period has expired. This article summarises the most significant changes for companies.2
\n\n
\n\n
At a glance
\n\n
\n\n
\n
The basic concept of “permission of data processing subject to prohibition” (i.e. prohibition if the data processing leads to an “unlawful violation of the personality of a person”) remains unchanged. Consent to the processing of personal data is still generally not required, even for profiling and the processing of sensitive personal data. The principles of data processing also remain largely unchanged.
\n
\n\n
\n\n
\n
Legal entities are no longer protected; only natural persons are protected under the FADP-new.
\n
\n\n
\n\n
\n
The scope of the FADP-new covers actions that have an effect in Switzerland, even if they are initiated abroad.
\n
\n\n
\n\n
\n
The definitions of “controller of the data file”, “personality profile” and “data file” have been deleted; the definitions of “profiling”, “high-risk profiling” and “data security breach” have been introduced. Genetic and biometric data as well as data on ethnic origin, are considered to be sensitive personal data under the FADP-new.
\n
\n\n
\n\n
\n
The concepts of “privacy by design” and “privacy by default” are now enshrined in the law, as is already the case in the EU General Data Protection Regulation (GDPR).
\n
\n\n
\n\n
\n
Data security is the responsibility of the controller as well as the processor. A risk-based approach is introduced.
\n
\n\n
\n\n
\n
Data processing by processors remains largely unchanged. Under the FADP-new, the processor may only assign the processing to a sub-processor with prior authorisation by the controller.
\n
\n\n
\n\n
\n
The appointment of a data protection advisor remains voluntary. It can be an advantage when it comes to performing a data protection impact assessment.
\n
\n\n
\n\n
\n
Under the FADP-new, both the controller and the processor must keep an inventory of their processing activities. This inventory does not have to be declared to the Federal Data Protection and Information Commissioner (FDPIC) (up to now, the controller generally needed to declare data files to the FDPIC).
\n
\n\n
\n\n
\n
Companies based outside Switzerland who process personal data of persons in Switzerland will have to designate a representative in Switzerland.
\n
\n\n
\n\n
\n
The requirements for cross-border disclosure of personal data remain largely unchanged. Under the FADP-new, the Federal Council bindingly determines whether the legislation of a state or an international body guarantees an adequate level of protection.
\n
\n\n
\n\n
\n
The duty of information has been extended to the collection of all kinds of personal data (until now it was only applicable to the collection of sensitive personal data and personality profiles) and also includes automated individual decision-making.
\n
\n\n
\n\n
\n
Under the FADP-new, the controller must carry out a data protection impact assessment if the intended data processing may lead to a high risk for the data subject.
\n
\n\n
\n\n
\n
In the future, the controller must notify the FDPIC of data security breaches.
\n
\n\n
\n\n
\n
Under the FADP-new, data subjects have the right to data portability.
\n
\n\n
\n\n
\n
The powers of the FDPIC are extended. In the future, the FDPIC can order a number of administrative measures.
\n
\n\n
\n\n
\n
The criminal provisions have been significantly tightened, with fines of up to 250 000 Swiss francs for private persons (i.e. not companies!), but only for violations in certain areas, in particular for the breach of obligations to provide access and information and to cooperate, for the violation of duties of diligence with respect to the requirements for cross-border disclosure of personal data, the appointment of a processor and for failure to comply with the minimum data security requirements. Fines are only applicable to violations that result from a wilful act and are in most cases, only imposed upon the filing of a complaint.
The FADP-new aims to protect personal privacy and the fundamental rights of natural persons whose personal data is processed. Under the current law, legal entities are also protected. By cancelling the protection of legal entities, the FADP-new aligns with the GDPR, that also protects only natural persons.
\n\n
\n\n
The FADP-new also regulates the territorial scope. According to art. 3, the law applies to actions that have an effect in Switzerland, even if they are initiated abroad.
Various definitions are now aligned with the GDPR.
\n\n
\n\n
The definition of “personal data” is limited to “all information relating to an identified or identifiable natural person”. The term “data subject” only refers to natural persons whose data is processed.
\n\n
\n\n
Concerning the identifiability, the “relative approach” is maintained. According to the Federal Council Dispatch on the Federal Act on the complete revision of the Federal Act on Data Protection and the modification of other federal enactments5, the mere theoretical possibility to identify a person is, as under current law, not sufficient to presume that a person is identifiable. The Federal Council already stipulated in its Dispatch to the FADP of 19886 that no identifiability is given if “the effort necessary to identify a data subject is so great that, according to general life experience, it cannot be expected that any interested person should undertake such effort”. “It must rather be considered what means can be reasonably employed to identify a person and be determined whether the employment of such means is reasonable under the given circumstances, for instance in terms of time and cost. In doing so, the technologies available at the time of processing and their further development must be taken into account. The law does not apply to anonymised data, if a re-identification by third parties is impossible (the data has been completely and irreversibly anonymised) or if a re-identification would only be possible with a great effort that no interested person would undertake. The same applies to pseudonymised data”.7
\n\n
\n\n
\n
The definition of “sensitive personal data” has been extended to include “data on ethnic origin”, “genetic data” and “biometric data which uniquely identifies a natural person”. While it is made clear that biometric data must uniquely identify a natural person, the same addition has been deleted for genetic data in the procedure of the resolution of differences.
\n
\n\n
\n\n
\n
The definitions of “controller of the data file”, “personality profile” and “data file” have been deleted. The following new definitions have been introduced:\n
\n
“controller”: a private person or federal body that alone or jointly with others decides on the purpose and the means of the processing.
\n
“processor”: a private person or federal body that processes personal data on behalf of the controller.
\n
“profiling”: any form of automated processing of personal data consisting in the use of such data to evaluate certain personal aspects relating to a natural person, in particular, to analyse or predict aspects relating to that natural person's performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, whereabouts or movements.
\n
“high-risk profiling”: profiling which involves a high risk to the personality or fundamental rights of the data subject, by creating a link between data which allows an assessment of substantial aspects of the personality of a natural person.
\n
“data security breach”: a security breach which leads to an unintentional or unlawful loss, deletion, destruction or modification of personal data or to personal data being disclosed or made accessible to unauthorised persons.
\n
\n
\n
\n\n
\n\n
3. Principles of data processing
\n\n
\n\n
The principles of data processing remain materially largely unchanged.
\n\n
\n\n
\n
Art. 6 para. 4 now explicitly stipulates that personal data must be destroyed or anonymised as soon as it is no longer needed with regard to the purpose of the processing. To comply with this obligation, the controller must determine retention periods in advance.
\n
\n\n
\n\n
\n
The definition of “personality profile” is replaced by “profiling” (see description under “definitions”). The terminology of profiling was the sticking point on which the Councils disagreed until the very end and which was also largely discussed in the media. In the end, the conciliation committee followed the proposal of the Council of States and decided to introduce the definition of “high-risk profiling” (which is comparable to the current concept of the personality profile), with the consequence that if consent is required for this type of profiling, it must be explicit. It remains to be seen how companies will assess the risk level of profiling in practice. In any case, this exercise will certainly be a challenge for companies.
\n
\n\n
\n\n
It should be noted that the FADP-new does not introduce a consent requirement for high-risk profiling, but only requires that consent, if at all required as a justification under art. 31 FADP-new must be given explicitly. It is worth recalling that the basic concept of both the FADP and the FADP-new is different from that of the GDPR. While under the GDPR, a legal ground is always required for the processing of personal data (art. 6 and 9 GDPR), the processing of personal data under the FADP and FADP-new is, in principle, permitted as long as the personality of the data subjects is not unlawfully violated. Hence, the \"permission principle subject to prohibition\" continues to apply under the FADP-new, while the GDPR applies the \"prohibition principle subject to permission\".
\n\n
\n\n
4. Privacy by design and privacy by default
\n\n
\n\n
The principles of “privacy by design” and “privacy by default”, as known from the GDPR, are now also enshrined in the FADP-new. In today's practice, the controller is already required to set up data processing activities in a manner that complies with the data protection regulations and the principles of data processing. The FADP-new explicitly regulates that the controller must ensure, through appropriate pre-defined settings, that the processing of personal data is limited to the minimum required by the purpose unless the data subject determines otherwise (privacy by default).
\n\n
\n\n
5. Data security
\n\n
\n\n
The slightly revised article 8 FADP-new stipulates that both the controller and the processor must ensure, through adequate technical and organisational measures, a level of data security that appropriately addresses the risk. This means that a risk-based approach is introduced. “The higher the risk of a data security breach, the higher the requirements for the measures to be taken”.8 The Federal Council will issue provisions on the minimum requirements for data security.
\n\n
\n\n
6. Data processing by processors
\n\n
\n\n
Art. 9 FADP-new essentially adopts the current article 10a FADP. The rather unfortunate term “third parties” is replaced by “processors”. The processing of personal data may still be assigned by agreement or by legislation to a processor if (a) the data is processed only in a manner permitted for the controller itself, and (b) no statutory or contractual duty of confidentiality prohibits the assignment. The controller must ensure in particular that the processor can guarantee data security. As under the GDPR, the processor may only assign the processing to a sub-processor with the prior authorisation by the controller.
\n\n
\n\n
7. Data protection advisor
\n\n
\n\n
Controllers may, but are not required to, appoint a data protection advisor as a contact point for the data subjects and the relevant authorities responsible for data protection matters in Switzerland. The data protection advisor has the duty to train and advise the controller in matters of data protection and to participate in the enforcement of data protection regulations.
\n\n
\n\n
Contrary to the current FADP, the data protection advisor is not responsible for supervising the company’s internal compliance with data protection regulations, nor for maintaining an inventory of data files.
\n\n
\n\n
Private controllers who appointed a data protection advisor have an advantage when they need to perform a data protection impact assessment according to art. 22 FADP-new by reason of their processing activities, provided that they consult their data protection advisor. In this case, they can abstain from consulting the FDPIC.[9] The controller must consult the FDPIC before the processing when the data protection impact assessment shows that the processing presents a high risk for the personality or fundamental rights of the data subject, despite the measures envisaged by the controller. The controller may abstain from consulting the FDPIC if the data protection advisor (a) performs his or her function towards the controller in a professionally independent manner and without being bound by instructions, (b) does not perform any activities which are incompatible with his or her tasks as data protection advisor, (c) possesses the necessary professional knowledge, and (d) if the controller publishes the contact details of the data protection advisor and communicates them to the FDPIC.
\n\n
\n\n
8. Inventory of processing activities
\n\n
\n\n
As under the GDPR, controllers and processors must each keep an inventory of their processing activities. The FADP-new lists the minimum information that needs to be contained in such inventories. The inventory of processing activities does no longer have to be declared to the FDPIC.
\n\n
\n\n
9. Representative in Switzerland
\n\n
\n\n
Similar to the GDPR, private controllers with their domicile or residence abroad must, under certain circumstances, designate a representative in Switzerland if they process personal data of persons in Switzerland. The representative serves as a contact point for data subjects and the FDPIC. The controller must publish the name and address of the representative. The requirements for designating a representative and the duties of the representative are regulated in art. 14 and 15 FADP-new.
\n\n
\n\n
10. Cross-border disclosure of personal data
\n\n
\n\n
Under the current FADP, personal data must not be disclosed cross-border if such disclosure would seriously endanger the personal privacy of the data subjects, in particular, due to the absence of legislation that guarantees adequate protection. The FDPIC maintains a list with a general evaluation of the data protection level in the listed countries. However, this non-binding list does not relieve the data exporter from its responsibility to assess on a case by case basis whether the legislation of the respective country guarantees an adequate level of protection.
\n\n
\n\n
Under the FADP-new, the Federal Council bindingly determines whether the legislation of a state or an international body guarantees an adequate level of protection. If this is the case, personal data may be transferred cross-border. If not, data protection must be guaranteed by measures such as (a) an international treaty, (b) data protection clauses between the contracting parties, which were communicated beforehand to the FDPIC, (c) standard data protection clauses previously approved, established or recognised by the FDPIC (such as the EU standard contractual clauses) or (d) binding corporate rules (BCR) previously approved by the FDPIC or by a foreign authority which is responsible for data protection and belongs to a state which guarantees adequate protection (for example the CNIL in France as lead authority). The Federal Council can provide for other adequate safeguards, such as, for example, a follow-up agreement to the Swiss-US Privacy Shield.10
\n\n
\n\n
By derogation from the principles mentioned above, personal data may only be disclosed cross-border if one of the exceptions provided for in art. 17 FADP-new applies, such as, for example, the explicit consent of the data subject.
\n\n
\n\n
11. Duty of information when collecting personal data
\n\n
\n\n
The duty of information has been tightened. While the duty of information currently only applies to the collection of sensitive personal data and personality profiles, the controller must, in the future, generally inform the data subjects about the collection of their personal data. The minimum information that must be given in the privacy statement is stipulated in art. 19 FADP-new, differentiating between data collected directly from the data subject and data collected indirectly via other sources. This minimum information is less extensive than under the GDPR. However, there is one aspect where the FADP-new is stricter than the GDPR: if personal data is disclosed cross-border, the controller must inform the data subject of the state where the recipient is located.
\n\n
\n\n
Exceptions to the duty of information have been concretised. Private controllers may still restrict, defer or waive the provision of information in some instances. Among others, this is possible when the overriding interests of the controller demand it and when the controller does not disclose the personal data to third parties, companies controlled by the same legal entity not being considered as third parties in the sense of this exception.
\n\n
\n\n
Under the FADP-new, the controller must, as a general rule, inform the data subject of a decision which is taken exclusively based on automated processing and which has legal effects on the data subject or affects him or her significantly (so-called “automated individual decision”). The data subject can request that a natural person review the automated individual decision. Art. 21 FADP-new provides for exceptions to this rule.
\n\n
\n\n
12. Data protection impact assessments
\n\n
\n\n
As under the GDPR, the controller must conduct a data protection impact assessment before the data processing if the intended data processing may lead to a high risk for the data subject’s personality or fundamental rights. The existence of high risk, particularly when using new technologies, depends on the nature, the extent, the circumstances and the purpose of the processing (in particular the processing of sensitive personal data on a broad scale and the systematic surveillance of extensive public areas).
\n\n
\n\n
The data protection impact assessment contains a description of the intended processing, an evaluation of the risks for the data subject’s personality or the fundamental rights, as well as the intended measures to protect the data subjects’ personality and fundamental rights. Art. 22 FADP-new provides for certain exceptions. If the controller considers performing several similar processing operations, it may establish a joint impact assessment.
\n\n
\n\n
If the data protection impact assessment shows that the intended processing leads to a high risk for the personality or the fundamental rights of the data subject despite the measures envisaged, the controller must consult the FDPIC before the processing. It can abstain from consulting the FDPIC if it has appointed a data protection advisor according to art. 10 FADP-new and consulted him or her regarding the processing in question.
\n\n
\n\n
13. Notification of data security breaches
\n\n
\n\n
Like the GDPR, the FADP-new introduces a duty of notification of data security breaches, i.e. security breaches that lead to the unintentional or unlawful loss, deletion, destruction or modification of personal data or to personal data being disclosed or made accessible to unauthorised persons.
\n\n
\n\n
The good news is that the provisions regarding the notification obligation are slightly more pragmatic under the FADP-new than under the GDPR. The controller must notify the FDPIC as soon as possible of a data security breach that is probable to result in a high risk to the personality or the fundamental rights of the data subject.
\n\n
\n\n
Unlike the GDPR, the FADP-new only requires notification to the FDPIC where there is a high risk for the data subject. This is meant to prevent the notification of minor breaches. It remains the responsibility of the controller to determine the impact of the breach and the resulting risk for the data subject.
\n\n
\n\n
Contrary to the GDPR, the FADP-new does not stipulate a specific period within which the notification to the FDPIC must be made, but demands that the controller notify the breach as soon as possible after having become aware of it. The controller must act quickly but has a certain margin of discretion. “What is decisive in this context is, among others, the extent of the threat for the data subject. The bigger the threat and the larger the number of data subjects concerned, the quicker the controller must act.”11 Furthermore, the controller only needs to inform the data subject if it is necessary for the protection of the data subject or if the FDPIC requests so. What is decisive in this context is whether the notification can reduce the risk for the personality or the fundamental rights of the data subject. This is, in particular, the case where the data subject can take measures for his or her protection, for example by changing his or her login details or password.12 Under certain circumstances, the controller may restrict the information to the data subject, defer it or refrain from providing information.
\n\n
\n\n
The processor has no duty to notify the FDPIC but must inform the controller as soon as possible of any data security breach.
\n\n
\n\n
Art. 24 FADP-new lists the minimum requirements for a notification to the FDPIC.
\n\n
\n\n
14. Rights of the data subject
\n\n
\n\n
Access right: The access right currently regulated in art. 8 FADP is now regulated in art. 25 FADP-new. The principle remains unchanged. The controller provides the data subject with the information required to enable him or her to assert his or her rights and to ensure the transparent processing of personal data. It is the same information as the one that must be given based on the duty of information. The minimum information that must be provided in reply to a request for information is listed in the FADP-new. A new element is information on the existence of automated individual decision-making. In this case, the data subject must also be informed about the logic on which the decision is based. The data subject can further request that a natural person review the automated individual decision.
\n\n
\n\n
The current limitations to the access right continue to exist. Under the FADP-new, the controller may “refuse, restrict or defer the provision of information if the request for information is manifestly unfounded or is obviously of a querulous nature”. According to the Federal Council Dispatch13, this limitation is to be interpreted in a narrow sense. In particular, the controller must choose the most favourable solution for the data subject. It must, to the extent possible, only restrict the provision of information, may defer it if necessary and can only refuse it in absolutely clear and obvious cases.
\n\n
\n\n
Right to data portability: Under the FADP-new, the data subject has, under certain circumstances, a right to data portability.14 The data subject may request the transfer of his or her personal data to him or her or, if this does not involve a disproportionate effort, to another controller. As a general rule, the data must be disclosed free of charge and in a standard electronic format. The same limitations as for the access right apply.
\n\n
\n\n
Legal claims: The currently applicable legal claims continue to apply and are listed in art. 32 FADP-new. The right to deletion or destruction is now explicitly regulated in the FADP-new, although it is already implied in the current law.
\n\n
\n\n
15. Administrative measures and sanctions
\n\n
\n\n
The competences of the FDPIC are extended in art. 51 FADP-new. Under the new law, he can not only recommend measures but also order administrative measures. Among these measures are for example measures against data processing that violates the data protection regulations, including the order to destroy personal data or the prohibition to disclose personal data cross-border, as well as the order to perform a data protection impact assessment or to inform the data subject. The FDPIC still cannot issue any fines. This competence remains with the cantons.15
\n\n
\n\n
The criminal provisions have been significantly tightened.16 Under the FADP-new, private persons (i.e. not companies, as under the GDPR!) are, on complaint, liable to a fine of up to 250 000 Swiss francs if they violate their duty to provide access or information, or their duties of diligence, namely if they disclose personal data cross-border or assign the data processing to a processor without complying with the requirements, or fail to comply with the minimum data security requirements. Persons who wilfully refuse to cooperate with the FDPIC in the context of an investigation are also liable to a fine.
\n\n
\n\n
Further, a person who violates his or her duty of confidentiality by wilfully disclosing secret personal data of which he or she has gained knowledge while exercising his or her profession which requires knowledge of such data is liable to a fine. This provision introduces a duty of confidentiality for persons (and their auxiliary persons) who are not covered by the obligation of professional secrecy under criminal law17. A breach of professional confidentiality can be sanctioned on a complaint with a fine of up to 250 000 Swiss francs.
\n\n
\n\n
Finally, persons who wilfully fail to comply with a decision issued by the FDPIC or by the appellate authorities under threat of penalty are liable to a fine of up to 250 000 Swiss francs.
\n\n
\n\n
It should be noted that violations of essential duties newly enshrined in the law, such as the keeping of an inventory of processing activities, the notification of data security breaches or the obligation to perform data protection impact assessments, are not liable to a fine.
\n\n
\n\n
Implementation measures
\n\n
\n\n
Companies should carry out a data management analysis and identify their level of compliance with the FADP-new as well as any possible gaps and risks. In doing so, they should focus on the following areas:
\n\n
\n\n
\n
governance structure,
\n
data protection standards and processes to comply with the privacy principles and data security,
\n
transparency towards the data subjects,
\n
inventory of processing activities,
\n
data flows within the company and to service providers (taking into consideration the latest developments and the policy paper of the FDPIC18),
\n
processes for performing data protection impact assessments,
\n
notification of data security breaches to the FDPIC and
\n
responding to requests for information (access rights).
\n
\n\n
\n\n
Companies who already introduced a GDPR data protection program will have less need for action than companies who are not subject to the GDPR or who have not yet taken any respective measures.
\n\n
\n\n
Many companies will, in any case, have to introduce concepts such as privacy by design as well as processes that allow the legally compliant deletion or destruction of personal data and support data portability. Many companies will also have to review their privacy statements and, if needed, adapt them or issue new privacy statements to fulfil the requirements of the FADP-new. Current inventories of data files will have to be restructured to record data processing activities.
\n\n
\n\n
If you have any questions or need support in this area, please do not hesitate to contact FABIAN PRIVACY LEGAL.
[10] On 8 September 2020, the Federal Data Protection and Information Commissioner (FDPIC) determined that it no longer considers the Swiss-US Privacy Shield adequate for transferring personal data from Switzerland to the USA (see the policy paper of the FDPIC).
On 25 September 2020, the Swiss Parliament adopted the revised Federal Act on Data Protection. The Federal Council will decide on the entry into force after the 100-day referendum period has expired. This article summarizes the most significant changes for companies.
\n","preview":"","datei":[],"linkextern":""},{"id":97,"title":"Das revidierte Schweizer Datenschutzgesetz ist verabschiedet","slug":"the-revised-swiss-data-protection-act-is-adopted","link":"/en/news-knowledge/the-revised-swiss-data-protection-act-is-adopted","blocks":[{"id":123,"title":"PDF Test","slug":"pdf-test","link":"/en/dev/part-data/the-revised-swiss-data-protection-act-is-adopted-blocks/pdf-test"},{"id":124,"title":"PDF Test","slug":"pdf-test","link":"/en/dev/part-data/the-revised-swiss-data-protection-act-is-adopted-blocks/pdf-test"}],"titel":"The revised Swiss Data Protection Act is adopted","preview":"","text":"
On 25 September 2020, the Swiss Parliament adopted the revised Federal Act on Data Protection (FADP-new) (final voting text in French). The federal law is subject to an optional referendum. The Federal Council decides on the entry into force after the 100-day referendum period has expired.
\n\n
\n\n
After disagreeing until the very end on the issue of profiling, the Councils finally agreed on the introduction of the concept of “high-risk profiling”. The consequence of this type of profiling is that consent, if required, must be explicit (see below the relevant legal articles concerning profiling and consent).
\n\n
\n\n
It remains to be seen how companies will assess the risk level of profiling in practice. In any case, this exercise will be a challenge for companies.
\n\n
\n\n
It should be noted that the revised FADP does not introduce a consent requirement for high-risk profiling, but only requires that consent, if at all required as a justification under Art. 31 FADP-new, must be given explicitly. It must be reminded that the basic concept of the FADP and FADP-new is different from that of the GDPR. While under the GDPR, a legal ground is always required for the processing of personal data (Art. 6 and 9 GDPR), the processing of personal data under the FADP and FADP-new is, in principle, permitted as long as the personality of the data subjects is not unlawfully violated. According to the FADP-new, the “permission principle subject to prohibition” continues to apply, while the GDPR applies the “prohibition principle subject to permission”.
\n\n
\n\n
The revised Data Protection Act will in future apply to the processing of personal data of natural persons (today also legal entities). It introduces specific terms such as “controller” and “processor” and extends the term “sensitive personal data” to include “genetic data” and “biometric data that uniquely identifies a natural person”. Concepts, as already known from the GDPR, are now enshrined in the law, such as Privacy by Design, the inventory of processing activities, data protection impact assessments, the general duty to provide information when collecting personal data and the notification of data security breaches. In the future, under certain conditions, controllers located abroad will also have to appoint a representative in Switzerland if they process personal data of persons in Switzerland. The new law tightens the penal provisions with fines of up to 250,000 Swiss francs for private individuals who violate specific provisions, such as the obligation to inform, consult and cooperate with the FDPIC, the provisions on the transfer of personal data abroad and the assignment of processors, as well as non-compliance with minimum data security requirements.
\n\n
\n\n
A detailed summary and analysis of the revised law and its principles will follow.
\n\n
\n\n
Relevant articles in the FADP-new concerning profiling (unofficial translation):
\n\n
\n\n
Art. 5 lit f:
\n\n
Profiling Is any automated processing of personal data consisting in the use of such data to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects relating to the performance of work, economic situation, health, personal preferences, interests, reliability, behaviour, whereabouts or movements of that natural person.
\n\n
\n\n
Art. 5 lit g:
\n\n
High-risk profiling: profiling which involves a high risk to the personality or fundamental rights of the data subject, by creating a link between data which allows an assessment of substantial aspects of the personality of a natural person.
\n\n
\n\n
Art. 6 para 6:
\n\n
If the consent of the data subject is required, this consent is only valid if it is given voluntarily for one or more specific processing operations after adequate information has been provided.
\n\n
\n\n
Art. 6 para. 7:
\n\n
Consent must be given explicitly for: a. the processing of sensitive personal data; b. high risk profiling by a private person; or c. profiling by a federal body.
\n\n
\n\n
Art. 30 Violation of the personality
\n\n
1 Anyone who processes personal data must not unlawfully violate the personality of the data subjects.
\n\n
2 A violation of personality exists in particular if:
\n\n
a. personal data is processed in violation of the principles set out in Articles 6 and 8;
\n\n
b. personal data is processed contrary to the data subject’s express declaration of intent;
\n\n
c. sensitive personal data is disclosed to third parties.
\n\n
3 As a rule, there is no violation of personality if the data subject has made the personal data generally accessible and has not expressly prohibited its processing.
\n\n
\n\n
Art. 31 para 1
\n\n
A violation of privacy is unlawful if it is not justified by the consent of the person concerned, by an overriding private or public interest or by law.
\n","datum":"25.09.2020","teasertext":"
On 25 September 2020, the Swiss Parliament adopted the revised Federal Act on Data Protection (FADP-new). The federal law is subject to an optional referendum. The Federal Council decides on the entry into force after the 100-day referendum period has expired.
\n","datei":[],"linkextern":""},{"id":154,"title":"Swiss Data Protection Authority considers CH-US Privacy Shield no longer adequate","slug":"swiss-data-protection-authority-considers-ch-us-privacy-shield-no-longer-adequate","link":"/en/news-knowledge/swiss-data-protection-authority-considers-ch-us-privacy-shield-no-longer-adequate","titel":"Swiss Data Protection Authority considers CH-US Privacy Shield no longer adequate","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
On 8 September, the Federal Data Protection and Information Commissioner (FDPIC) determined that it no longer considers the CH-US Privacy Shield adequate for transferring personal data from Switzerland to the USA (please see the statement, the policy paper, and the amended list of states with adequate protection here). Such a decision was expected following the EU Court of Justice (CJEU) judgment of mid-July in the case C-311/18 — Data Protection Commissioner v. Facebook Ireland and Maximillian Schrems. See our summary here.
\n\n
\n\n
Based on this determination and within the scope of its competence (Art. 31 para. 1 lit. d FADP and Art. 7 of the Ordinance to the FADP (OFADP)), the FDPIC has removed the USA from the list of states with adequate data protection under certain conditions (Privacy Shield) and classifies the USA from now on as a country with insufficient protection.
\n\n
\n\n
The list of states is a list of countries whose legislation guarantees adequate data protection in the opinion of the FDPIC. However, the list does not release data exporters from their obligation to assess the presumed level of protection if there are indications of data protection risks in a specific case and, if necessary, to take appropriate safeguards within the meaning of Art. 6 para. 2 FADP, or even to refrain from exporting the data. The list distinguishes between countries with \"adequate data protection\" and countries with \"adequate data protection under certain conditions\". The USA has belonged to the second group since the beginning of 2017 with the introduction of the CH-US Privacy Shield.
\n\n
\n\n
With the removal of the USA from the list, the transfer of personal data to the USA now requires the fulfillment of one of the conditions of Art. 6 para. 2 FADP (such as contractual guarantees, binding corporate rules (BCR), or consent). The data exporter remains obliged to carry out a risk assessment in each case and, in particular, to ensure data protection's adequacy in the destination country.
\n\n
\n\n
However, the determination of the FDPIC and the removal of the USA from the list of states does not influence the continued existence of the CH-US Privacy Shield. The framework would have to be formally revoked by the US Department of Commerce. If a company continues to transfer personal data to the USA under the CH-US Privacy Shield without taking additional safeguards under Art. 6 para. 2 FADP, it is in breach of the data protection principles under the FADP. It thus unlawfully violates the personality of the data subjects, unless there is a legal justification, including consent, an overriding private or public interest or law.
\n\n
\n\n
In its policy paper, the FDPIC provides guidance on the measures to be taken by companies that transfer personal data to non-listed countries based on contractual clauses. Data exporters should consider each case with due diligence, and, in particular, verify if the receiving company in a non-listed country is subject to governmental access, and further whether the receiving company is entitled and in a position to provide the cooperation necessary for the enforcement of Swiss data protection principles. If this is not the case, Swiss data exporters must consider technical measures that effectively prevent the authorities in the destination country from accessing the transferred personal data, in particular, through encryption along with the principles of BYOK (bring your own key) and BYOE (bring your own encryption). However, encryption may not be useful for the receiving company's services beyond mere data hosting. If such technical measures are not possible, the FDPIC recommends refraining from transferring personal data to non-listed countries based on contractual clauses.
\n\n
\n\n
Please note that under the current FADP, the FDPIC only has the power to issue recommendations regarding the method of processing, and, in case such recommendations are not followed or rejected, to refer the matter to the Federal Administrative Court for a decision. Under the revised Draft FADP (D-FADP, according to the current state), however, the FDPIC shall obtain extended power to issue an order to the controller directly and prohibit the data transfer abroad if it is contrary to the requirements of the D-FADP or violates provisions relating to the disclosure of personal data abroad. Responsible individuals who deliberately fail to comply with an order issued by the FDPIC may be fined up to 250,000 Swiss francs, provided that the order contains such a threat of punishment.
\n\n
\n\n
Therefore, Swiss companies should continue to monitor developments in this matter and watch out for further guidance of the FDPIC. Companies should also identify and document any cross-border data transfer within their organization and to third parties, and the safeguards used. Transfers relying on the CH-US Privacy Shield should be based on alternative transfer mechanisms. If Standard Contractual Clauses (SCC) are used, companies should conduct assessments in each case, as described above, and take additional contractual, technical, and organizational measures to reach an adequate protection level for the data transferred.
\n","datum":"11.09.2020","teasertext":"
On 8 September 2020, the Federal Data Protection and Information Commissioner (FDPIC) determined that it no longer considers the CH-US Privacy Shield adequate for transferring personal data from Switzerland to the USA, following the EU Court of Justice judgment of mid-July in the Schrems II case. The following article explains the consequences of this decision for Swiss companies transferring personal data to third countries and gives advice on how they should react.
\n","preview":"","datei":[],"linkextern":""},{"id":155,"title":"What needs to be considered when transferring personal data to third countries? (in German)","slug":"was-ist-bei-der-uebermittlung-von-personendaten-ins-ausland-zu-beachten","link":"/en/news-knowledge/was-ist-bei-der-uebermittlung-von-personendaten-ins-ausland-zu-beachten","titel":"What needs to be considered when transferring personal data to third countries? (in German)","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
Was ist bei der Übermittlung von Personendaten ins Ausland zu beachten?
\n\n
\n\n
Der Gerichtshof der Europäischen Union (EuGH) hat in einem kürzlich publizierten Entscheid die Übermittlung von Personendaten in Drittländer erheblich erschwert. Welche Auswirkungen hat dieser Entscheid auf Unternehmen in der Schweiz?
\n\n
\n\n
Die geltende EU Datenschutz-Grundverordnung (DSGVO) und das schweizerische Datenschutzgesetz (DSG) verbieten grundsätzlich die Übermittlung von Personendaten aus dem Europäischen Wirtschaftsraum (EWR) und der Schweiz in Länder, die keinen angemessenen Datenschutz gewährleisten (Drittländer).
\n\n
\n\n
Eine Übermittlung in Drittländer, einschliesslich Fernzugriff, ist nur erlaubt, wenn mindestens eine der gesetzlich vorgesehenen Schutzmassnahmen getroffen wird, wie beispielsweise die Anwendung von EU-Standardvertragsklauseln (SCC) zwischen Datenexporteuren und Datenempfängern oder die Einführung von verbindlichen internen Unternehmensregeln (BCR) für den internen Datenaustausch. Eine Übermittlung ist auch erlaubt, wenn eine Ausnahmeregelung vorliegt, beispielsweise die ausdrückliche Einwilligung der betroffenen Personen.
\n\n
\n\n
Die USA gelten grundsätzlich aus europäischer Sicht als Drittland. Sowohl die EU als auch die Schweiz haben jedoch mit den USA ein Regelwerk erarbeitet, den sogenannten EU-U.S. Privacy Shield und CH-U.S. Privacy Shield. Dieses Regelwerk erlaubt die Übermittlung von Personendaten aus der EU und der Schweiz an US-Unternehmen, die sich dem jeweiligen Privacy Shield unterstellt haben.
\n\n
\n\n
Das Urteil des EuGH in Sachen Schrems II erschwert die grenzüberschreitende Datenübermittlung
\n\n
\n\n
Am 16. Juli 2020 hob der Gerichtshof der Europäischen Union (EuGH) in der Rechtssache C-311/18 - Data Protection Commissioner v. Facebook Ireland and Maximilian Schrems (Schrems II) den EU-U.S. Privacy Shield mit sofortiger Wirkung auf. Der Grund für diese Entscheidung liegt darin, dass das US-Recht aufgrund der weitgehenden Befugnisse der US Geheimdienste gemäss der Einschätzung des EuGH kein Schutzniveau bietet, das dem in der Europäischen Union im Wesentlichen gleichwertig ist.
\n\n
\n\n
Gleichzeitig bestätigte der EuGH die prinzipielle Gültigkeit von SCC. Der EuGH appelliert jedoch an die bereits in den SCC festgeschriebenen Verpflichtungen von Unternehmen, die Personendaten auf der Grundlage von SCC aus der EU in ein Drittland exportieren oder importieren, und betont, dass die reine Unterzeichnung der SCC nicht ausreicht. Die Parteien müssen im Einzelfall prüfen, ob die SCC im Empfängerland eingehalten werden können und die Rechte der betroffenen Personen im Empfängerland ein angemessenes Schutzniveau geniessen, das dem in der Europäischen Union gleichwertig ist.
\n\n
\n\n
Ist dies nicht der Fall, muss der Datenexporteur zusätzliche Schutzmassnahmen ergreifen oder die betreffende Datenübermittlung aussetzen. Schutzmassnahmen können technischer Natur sein, wie beispielsweise die Verschlüsselung der Daten. Zusätzliche vertragliche Absicherungen und organisatorische Massnahmen sind ebenfalls denkbar. Der EuGH legt jedoch nicht fest, welche Art von Schutzmassnahmen ergriffen werden sollen, und lässt somit den Unternehmen einen gewissen Spielraum.
\n\n
\n\n
Was bedeutet dieses Urteil für Unternehmen in der Schweiz?
\n\n
\n\n
Das EuGH-Urteil ist auf die Schweiz nicht direkt anwendbar. Somit bleibt der CH-U.S. Privacy Shield vorerst gültig. Auch vom Eidgenössischen Datenschutz- und Öffentlichkeitsbeauftragten (EDÖB) anerkannte SCC können weiterhin für Datenübermittlungen aus der Schweiz genutzt werden. Der EDÖB hat das Urteil des EuGH zur Kenntnis genommen, hat sich aber noch nicht zur Gültigkeit des CH-U.S. Privacy Shields geäussert. Es ist jedoch zu erwarten, dass die Behörde dem EuGH-Urteil folgen und auch den CH-U.S. Privacy Shield für ungültig erklären wird (wie sie es auch 2015 nach der Ungültigkeitserklärung des Vorgängerabkommens Safe-Harbor getan hat). Für Unternehmen in der Schweiz, die dem DSG unterliegen, besteht somit aufgrund des EuGH-Urteils vorerst kein dringender Handlungsbedarf. Dennoch sollten die internen und externen Datenflüsse jetzt schon ermittelt und Vorbereitungen für einen kurzfristigen Wechsel von Privacy Shield auf SCC getroffen werden. Auf viele Unternehmen in der Schweiz ist jedoch auch die DSGVO anwendbar. Diese Unternehmen sollten jetzt aktiv werden, um Personendaten weiterhin legitim in Drittländer übermitteln zu können und signifikante Bussgelder zu vermeiden.
\n\n
\n\n
Was können Unternehmen tun?
\n\n
\n\n
\n
Unternehmen sollten die Entwicklungen in der EU und in der Schweiz überwachen und insbesondere auf die Herausgabe von Leitlinien und revidieren SCC als auch auf eine allfällige Ungültigkeitserklärung des CH-U.S. Privacy Shields achten.
\n
\n\n
\n\n
\n
Interne und externe grenzüberschreitende Datenübermittlungen sollten ermittelt und dokumentiert werden.
\n
\n\n
\n\n
\n
Für Datenübermittlungen, die auf den EU-U.S. Privacy Shield gestützt sind, sollten SCC mit den Datenempfängern vereinbart werden.
\n
\n\n
\n\n
\n
Für Datenübermittlungen auf der Grundlage von SCC (einschliesslich konzerninterner Datenübermittlungsvereinbarungen) sollten im Rahmen der Due Diligence mit dem Datenempfänger Analysen im Empfängerland durchgeführt und gegebenenfalls zusätzliche vertragliche, organisatorische und technische Massnahmen getroffen werden.
\n
\n\n
\n\n
\n
Schliesslich sollten Unternehmen ihre Datenübermittlungsstrategie überdenken und gegebenenfalls einen Wechsel auf robustere Mechanismen, wie BCR in Betracht ziehen.
\n
\n\n
\n","datum":"04.09.2020","teasertext":"
In an article published in the magazine \"Fokus Rechtsguide\", Daniela Fábián Masoch explains what needs to be considered when transferring personal data to third countries and what are the consequences of the CJEU judgment (Schrems II) for Swiss companies. Please note that the publication is only available in German.
\n","preview":"","datei":[],"linkextern":""},{"id":156,"title":"CJEU judgment on cross-border data transfers from the EU to third countries - what now?","slug":"urteil-des-eugh-zu-grenzueberschreitenden-datenuebermittlungen-aus-der-eu-in-drittlaender-was-nun","link":"/en/news-knowledge/urteil-des-eugh-zu-grenzueberschreitenden-datenuebermittlungen-aus-der-eu-in-drittlaender-was-nun","titel":"CJEU judgment on cross-border data transfers from the EU to third countries - what now?","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
On 16 July 2020, the Court of Justice of the European Union (CJEU) delivered its judgment in Case C-311/18 — Data Protection Commissioner v. Facebook Ireland and Maximillian Schrems (so-called \"Schrems II\"). In this case, M. Schrems requested the Commission to prohibit or suspend the transfer by Facebook Ireland of his personal data to Facebook Inc., established in the US, on the ground that that third country did not ensure an adequate level of protection. This ruling has far-reaching consequences for any transfers of data from the EU to third countries.
\n\n
\n\n
The CJEU’s findings of the decision
\n\n
\n\n
1. Privacy Shield
\n\n
\n\n
The CJEU invalidated, with immediate effect, the European Commission Decision 2016/1250 on the transfer of personal data to the US (Privacy Shield). The rationale for this decision is in essence that US law as evaluated by the CJEU, in particular Section 702 Foreign Intelligence Surveillance Act “FISA” and Executive Order 12333, does not provide a level of protection substantially equivalent to that in the EU (in terms of appropriate safeguards, enforceable rights and effective legal remedies required by the GDPR).
\n\n
\n\n
Please note that the Swiss Data Protection Authority (FDPIC) has taken note of the CJEU ruling. This ruling is not directly applicable to Switzerland and, therefore, to the CH-US Privacy Shield. The FDPIC will examine the judgment in detail and comment on it in due course. While the CH-US Privacy Shield is, at the moment, still valid, it is to be expected that the authority will follow the CJEU ruling and invalidate the CH-US Privacy Shield as well (as it did in 2015 after the invalidation of the Safe Harbor arrangement).
\n\n
\n\n
2. Standard Contractual Clauses (SCC)
\n\n
\n\n
The CJEU confirmed the validity, in principle, of the Commission Decision 2010/87/EC on Standard Contractual Clauses (SCC). However, the CJEU stressed the responsibility of the data exporter and data importer to carry out a case-by-case analysis of the domestic law of the data importer, specifically concerning access by public authorities and judicial redress to determine whether the rights of data subjects in the third country enjoy a level of protection equivalent to that in the Union. Where this is not the case, data exporters must take additional, effective safeguards or suspend the data transfer in question. Such additional safeguards may include technical measures such as encryption of the data in transit and at rest, contractual safeguards, or organizational measures. The CJEU does not, however, specify what kind of additional safeguards should be taken and thus leaves companies in uncertainty. More guidance is expected in the near future.
\n\n
\n\n
The obligations highlighted by the CJEU are not new. They are already included both in the Controller to Processor SCC and in the Controller to Controller SCC. The CJEU calls upon the existing obligations of companies which export, and import, personal data based on SCC from the EU to a third country without adequacy finding by the EU Commission, and stresses that it is not enough to sign the SCC, but that the parties must examine on a case-by-case basis whether the SCC can be complied with in the recipient country.
\n\n
\n\n
The CJEU decision concerns, in principle, the Controller to Processor SCC. However, the same arguments apply to any transfer of personal data from the EU to a third country, including on the basis of Controller to Controller SCC or Binding Corporate Rules (BCR).
\n\n
\n\n
Companies that do not carry out this analysis and possibly transfer personal data based on SCC to a third country, where the data recipient is not able to effectively comply with SCC due to conflicting local legislation, violate the requirements under the GDPR (even if SCC have been signed) and therefore risk hefty fines of up to EUR 20'000'000 or 4% of the annual turnover of the preceding year, whichever is higher. Also, such transfers may be prohibited or suspended by the competent supervisory authorities.
\n\n
\n\n
Relevant clauses in the current SCC
\n\n
\n\n
Controller to Processor SCC of 5 February 2010 (2010/87/EU)
\n\n
\n\n
Clause 4 (a): The data exporter agrees and warrants that the processing, including the transfer itself, of the personal data has been and will continue to be carried out in accordance with the relevant provisions of the applicable data protection law (…) and does not violate the relevant provisions of that State.
\n\n
\n\n
Clause 5: The data importer agrees and warrants:
\n\n
\n\n
(a): to process the personal data only on behalf of the data exporter and in compliance with its instructions and the Clauses; if it cannot provide such compliance for whatever reasons, it agrees to inform promptly the data exporter of its inability to comply, in which case the data exporter is entitled to suspend the transfer of data and/or terminate the contract.
\n\n
\n\n
(b): that it has no reason to believe that the legislation applicable to it prevents it from fulfilling the instructions received from the data exporter and its obligations under the contract and that in the event of a change in this legislation which is likely to have substantial adverse effect on the warranties and obligations provided by the Clauses, it will promptly notify the change to the data exporter as soon as it is aware, in which case the data exporter is entitled to suspend the transfer of data and/or terminate the contract.
\n\n
\n\n
Controller to Controller SCC of 27 December 2004 (2004/915/EC)
\n\n
\n\n
Clause I (b): The data exporter warrants and undertakes that it has used reasonable efforts to determine that the data importer is able to satisfy its legal obligations under these clauses.
\n\n
\n\n
Clause II (c): The data importer warrants and undertakes that it has no reason to believe, at the time of entering into these clauses, in the existence of any local laws that would have a substantial adverse effect on the guarantees provided for under these clauses, and it will inform the data exporter (which will pass such notification on to the authority where required) if it becomes aware of any such laws.
\n\n
\n\n
Reactions of data protection authorities
\n\n
\n\n
In the meantime, several data protection authorities as well as the European Data Protection Supervisor (statement 17 July 2020), the European Data Protection Board (statement 17 July 2020) and the German Conference of the Independent Data Protection Authorities of the Federal Government and the Länder (Datenschutzkonferenz - DSK) (press release 28 July 2020) have issued initial guidance for how to handle data transfers in future. You may find the respective references to the guidance on the IAPP Resource Center page.
\n\n
\n\n
Some data protection authorities, such as the German data protection authorities in Berlin (press release 17 July 2020) and Hamburg (press release 16 July 2020) have issued rigorous statements on the unlawfulness of data transfer to the US, based on SCC. The Berlin data protection authority is even calling on all those responsible under its supervision not to transfer personal data to the USA any longer, but to switch immediately to service providers based in the EU or another third country with an adequate level of protection.
\n\n
\n\n
The EDPB has issued, in addition to its statement, FAQ. More guidance, in particular regarding the additional safeguards to be taken, is expected.
\n\n
\n\n
What companies can do
\n\n
\n\n
While it is expected that the EDPB, the EU Commission and the supervisory authorities provide further guidance on the \"additional safeguards\"; and the EU Commission issues revised SCC, data exporters and importers should consider additional safeguards to ensure an adequate level of protection when transferring personal data from the EU to third countries:
\n\n
\n\n
\n
Document the analysis, the outcome, and any steps taken.
\n
\n\n
\n\n
\n
Identify and document any cross-border data transfer within your organization and to vendors and other business partners located outside of the EU/CH:
\n
\n\n
\n\n
If any personal data is transferred cross-border based on EU-US Privacy Shield, determine alternative legal mechanisms to enable such transfers under the GDPR (such as SCC subject to the conditions outlined by the CJEU, or one of the legal derogations under art. 49 GDPR), and amend contracts accordingly. Create a plan outlining all steps, responsibilities and timelines, including the possible termination of the EU-US Privacy Shield in accordance with the notification requirements, and adhere to the plan.
\n\n
\n\n
If any personal data is transferred cross-border based on SCC (including intragroup data transfer agreements), assess, together with the data importer, whether the legislation of the third country of destination ensures adequate protection under EU law of personal data transferred under the SCC. In particular, it should be assessed if the data importer is subject to any law and practice that allows data access by public authorities (such as under Art. 702 FISA in the US), and therefore the data importer may not be able to comply with the SCC. In this case, the data exporter shall conduct a privacy risk assessment to evaluate the likelihood of disclosure or access, the sensitivity and the volume of the data, and the retention period, and consider additional safeguards beyond SCC, including, for example, contractual and technical measures such as data encryption in transit and at rest. If such other measures are not possible, the data exporter should suspend or end the transfer of personal data, or notify the competent supervisory authority, which may ban any further data transfer.
\n\n
\n\n
If the transfer is based on BCR, the same analysis as for SCC should be conducted.
\n\n
\n\n
If the transfer is based on one of the legal derogations provided by Art. 49 GDPR, such as explicit consent or the necessity to perform a contract, no further steps are required for now.
\n\n
\n\n
\n
Document the analysis, the outcome, and any steps taken.
\n
\n\n
\n\n
\n
Review and amend due diligence processes and contractual templates:
\n
\n\n
\n\n
To be able to conduct appropriate conformity and risk assessments, the due diligence process and the questionnaire for data protection assessments of vendors should be revised to include questions about the existence of monitoring and data access laws and practices to which the data importer is subject. Particular attention should also be paid to the data importer's internal rules and procedures concerning the handling of requests from public authorities and notification to the data exporter. Also, any data importers, i.e., processors and controllers, should be evaluated in the future.
\n\n
\n\n
The contractual language in templates regarding the cross-border data transfers should be revised to emphasize the primary obligations of the data exporter/importer arising from the SCC itself, the handling of government requests to access personal data, and removing any reference to the Privacy Shield Framework.
\n\n
\n\n
\n
Service providers (data importers) may assist their customers by conducting a thorough analysis to verify the adequacy of EU laws and comply with the SCC (such exercise may also help to maintain a competitive edge).
\n
\n\n
\n\n
\n
Establish (or revise) internal policies and procedures to address cross-border requirements in compliance with the GDPR and the CJEU judgment.
\n
\n\n
\n\n
\n
In the long-term, companies may consider moving to more robust data transfer mechanisms, as provided in Art. 46 GDPR, such as binding corporate rules (BCR for Controllers and BCR for Processors) which are approved by the EU supervisory authorities, code of conduct, or certification mechanisms.
\n
\n","datum":"03.08.2020","teasertext":"
On 16 July 2020, the Court of Justice of the European Union (CJEU) delivered its judgment in Case C-311/18 — Data Protection Commissioner v. Facebook Ireland and Maximillian Schrems (so-called \"Schrems II\"). In this case, M. Schrems requested the Commission to prohibit or suspend the transfer by Facebook Ireland of his personal data to Facebook Inc., established in the US, on the ground that that third country did not ensure an adequate level of protection. This ruling has far-reaching consequences for any transfers of data from the EU to third countries.
\n","preview":"","datei":[],"linkextern":""},{"id":179,"title":"Privacy by Design in Digital Health","slug":"privacy-by-design-in-digital-health","link":"/en/news-knowledge/privacy-by-design-in-digital-health","titel":"Privacy by Design in Digital Health","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
1 Introduction
\n\n
\n\n
The exponential growth of digital health solutions and products, such as software or internet-enabled devices, brings a range of benefits for patients, the health industry and the general public, from preventing new diseases, monitoring patient conditions, data analysis, personalised medicine to reducing health costs through more efficient processes.
\n\n
\n\n
To be effective, these technologies rely on the use of large amounts of data. Particular caution is needed when personal data are involved, as the processing of personal data, in particular health-related data, can pose significant risks to the privacy of data subjects and the security of personal data. It is therefore of utmost importance to implement the fundamental data protection principles as laid down in data protection laws, such as the EU General Data Protection Regulation (EU) 2016/679 of 27 April 2016 (GDPR), the EU directive on privacy and electronic communications (Directive 2002/58/EC of 12 July 2002) and applicable national data protection laws. In particular, principles such as data minimisation and transparency, as well as technical security measures such as pseudonymisation or encryption, must be embedded in the design, development, and use of such solutions. In short: privacy by design must be implemented.
\n\n
\n\n
With the outbreak of COVID-19 and the efforts to find fast digital solutions to contain the spread of the virus, in particular through so-called contact tracing apps, which should help to efficiently interrupt chains of infection, the concept of privacy by design has gained in importance and awareness. For such apps to be successful and effective, they must be designed in such a way that the privacy of the individual and the protection of his or her personal data is guaranteed, at least in Europe. People must be assured that they are in control of their data, that their data are secure and only used for well-defined purposes and that their privacy rights are respected. Public trust and acceptance is of paramount importance to encourage the use of such applications, where their use is voluntary.
\n\n
\n\n
In order to realise the benefits of digital health solutions, those responsible for the development and management of such solutions and data processing, such as healthcare companies or public authorities, must meet the expectations of individuals, gain and maintain their trust and respect their privacy. Privacy by design has become a critical factor in building and maintaining trust, competitiveness, and success in the marketplace.
\n\n
\n\n
The challenge is to find the right balance between the potential of digital health to improve health services on the one hand and the protection of the personal rights of patients and consumers on the other. All legitimate interests and objectives, including data protection, should be taken into account without unnecessary compromise. This approach requires creative solutions in technical and organisational respects.
\n\n
\n\n
This article examines the privacy aspects under the GDPR that need to be taken into account when designing digital health solutions and why this is important to fully exploit the potential of digital health. It also attempts to clarify the concept of privacy by design and to translate legal requirements into practical solutions, with a focus on mobile applications in the context of digital health.
\n\n
\n\n
2 Emerging digital health technologies
\n\n
\n\n
Digital health refers to the use of information and communication technologies (ICT) to improve the quality, efficiency, and management of healthcare. Examples of digital health technologies include telemedicine, health monitoring and care with robots and sensors; wearables, i.e. mobile sensors worn directly on the body that record and analyse physiological data such as blood pressure, temperature, pulse or blood sugar levels in real time; and more generally the Internet of Things (IoT), i.e. the networking of physical devices equipped with software, sensors and network connectivity to collect and exchange data. Another example are the so-called contact tracing apps mentioned above, which are highly topical at the time of writing, and which are being developed by various countries worldwide to combat the spread of COVID-19. These apps are designed to alert people who have been in proximity to an infected person for a certain period of time so that they can take appropriate action.
\n\n
\n\n
3 The concept of privacy by design
\n\n
\n\n
The concept of privacy by design (PbD) is a fundamental prerequisite for the effective implementation of data protection. In essence, PbD requires that controllers take into account the principles and requirements of data protection both in the design phase of systems, processes, products or services and throughout the life cycle of personal data and that they provide for appropriate technical and organisational measures (TOMs) to implement the data protection requirements and to protect the rights of data subjects. Controllers are required to be proactive and anticipate potential privacy-invasive events before they materialise. Privacy by default is a fundamental element of privacy by design. It requires the controller to implement appropriate TOMs to ensure that, by default, only personal data necessary for each specific purpose of processing are processed. PbD must be implemented in relation to the quantity of data collected, the scope of their processing, the period of their storage, and their accessibility.
\n\n
\n\n
While the concept of PbD as a good practice has long existed, it was introduced as a legal obligation in Art. 25 GDPR with substantial fines in case of failure. With this, the legislator wanted to emphasise that it is not enough to set standards, but that these standards must be implemented in an effective and verifiable manner. However, Art. 25 GDPR does not specify how this obligation should be implemented in practice.
\n\n
\n\n
The implementation of PbD requires an assessment of the organisational, process, or product-related risks as well as the privacy risks for data subjects. This assessment aims to determine the necessary measures to be integrated from the outset as part of these products, systems, or processes to meet data protection requirements and to protect the privacy of data subjects. Risks may include, for example, excessive collection and disclosure of personal data, processing beyond the initial purpose, unlawful processing, loss, destruction, or alteration of data. Such risk assessment, coupled with a conformity assessment, is required for any processing of personal data, regardless of the sensitivity of the data.
\n\n
\n\n
Only if the processing is likely to present a high risk to the rights and freedoms of the data subjects, the controller must carry out a data protection impact assessment (DPIA) according to Art. 35 GDPR. A DPIA is a more comprehensive assessment that goes beyond conformity assessment by assessing the remaining risks to individuals, taking into account the TOMs embedded in the design of the product, system, or process. If the residual risk is still considered to be high, the controller must take further risk mitigation measures or, if this is not possible, refrain from processing or consult the data protection authorities. A DPIA will regularly be required for digital health solutions where health-related data or other special categories of data are processed, or technologies are used that may involve new forms of data collection and use.
\n\n
\n\n
4 Implement privacy by design in practice
\n\n
\n\n
4.1 Who is legally responsible for implementing privacy by design?
\n\n
\n\n
According to Art. 25 GDPR, the controller must implement the concept of PbD. Manufacturers, developers and service providers that are not controllers are only encouraged in Recital 78 GDPR to take into account 'privacy by design' when developing, designing, selecting and using applications, services and products based on the processing of personal data and to ensure that controllers and processors can comply with their data protection obligations. In practice, manufacturers of intelligent devices and health application developers will have a keen interest in fully implementing the concept of \"privacy by design\" to remain competitive.
\n\n
\n\n
4.2 What does the concept of privacy by design require from the controller?
\n\n
\n\n
The controller must establish technical measures, such as, for example, pseudonymisation, access authorisations, and restrictions, user authentication, encryption, logging, securing system configurations, protection measures against malware and data loss, and physical protection measures.
\n\n
\n\n
Furthermore, the controller must take organisational measures that are necessary for a well-functioning data protection management. These measures may include, for example, the allocation of responsibilities for the effective implementation of data privacy requirements, the implementation of enforceable policies and procedures for handling and documenting data breaches and data subject access requests, risk management, third-party management, data transfer governance, documentation of processing activities, training and controls. Also, the controller must take appropriate measures to respond to a withdrawal of consent, to a request for rectification or erasure of personal data or the portability of data.
\n\n
\n\n
4.3 How must the technical and organisational measures be?
\n\n
\n\n
The TOMs must be adequate and appropriate to
\n\n
\n\n
\n
effectively implement data protection principles, such as data minimisation, lawfulness, transparency, confidentiality, purpose limitation, data integrity, storage duration, security, as well as the requirements concerning commissioned data processing and cross-border data transfers;
\n
integrate the necessary safeguards into the processing to meet the requirements of the GDPR; and
\n
protect the rights of data subjects.
\n
\n\n
\n\n
A measure is adequate if it takes into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing.
\n\n
\n\n
4.4 When must TOMs be implemented?
\n\n
\n\n
The controller must implement TOMs both at the time of determining the means of processing and during the processing itself.
\n\n
\n\n
4.5 What data protection aspects must be taken into account in digital health solutions?
\n\n
\n\n
First, it must be determined which laws and regulations are applicable, in particular, whether the GDPR is applicable. It should also be examined whether sector-specific codes of conduct, certification systems, regulatory decisions, or guidelines for the development of digital health products are applicable. Ethical considerations should also be taken into account.
\n\n
\n\n
Secondly, it is necessary to determine which parties are involved in the development, deployment, and use of the product and the respective roles of these parties, who is the controller (several parties may be joint controllers) and, where appropriate, who is a processor. The identification of the controller, i.e., the party which alone or jointly with others determines the means and purposes of the data processing, is essential to determine who is responsible and accountable for complying with data protection requirements under the GDPR.
\n\n
\n\n
The following section explains which data protection principles must be observed and how they can be implemented in practice, with a focus on the use of mobile health apps.
\n\n
\n\n
Proportionality and data minimization
\n\n
\n\n
Personal data must be adequate, relevant, and limited to what is necessary for the purposes for which they are processed. This means that apps and devices that store or process personal data should be set up in such a way that only the data necessary for the respective purpose or the proper functioning of the app or device are stored and processed.
\n\n
\n\n
Personal data are defined as any information relating to an identified or identifiable natural person. In the context of a mobile application, data relating to the device, such as location data or usage data, are also considered personal data. Pseudonymised data, meaning data that are processed in such a way that they can no longer be attributed to a specific data subject without the use of additional information that is kept separately and securely, are also classified as personal data. Only irreversibly anonymised data are not considered personal data and are therefore not subject to the GDPR (and other data protection laws).
\n\n
\n\n
The principle of data minimisation can be achieved in different ways, for example, by reducing the amount of personal data or by making it more difficult or impossible to assign the data to an individual.
\n\n
\n\n
The type and amount of data necessary for the identified purpose may vary depending on the application area of the product. If, for example, an app is only used for information purposes, the collection of personal data is usually not necessary or pseudonymised login data might be sufficient. However, if an app is to monitor health and, if necessary, interact with a doctor or other persons, considerably more data, especially identification and health data, may be required. In the case of a COVID-19 contact tracing application to alert people who have been in the vicinity of a positive tested person, proximity data collected using Bluetooth technology should be sufficient. Location data that can be used to track individuals are not necessary for this purpose, nor are other personal data. Anonymised or at least pseudonymised data should be sufficient.
\n\n
\n\n
Depending on the functionalities of the app and the purpose of processing, it must, therefore, be evaluated for each data set whether the data are necessary to fulfil the purpose or whether the purpose can be fulfilled with less data (reduction of the data volume) or pseudonymised/anonymised data (making identification more difficult or impossible). A distinction should also be made between mandatory and voluntary data, which can be provided additionally to use specific functionalities.
\n\n
\n\n
Further measures to minimise data can consist in preventing the linking of personal data collected via the product with personal data stored in other systems unless such linking is necessary for the purpose. Location data should not be collected and stored if a generic location area is sufficient for the application functionality.
\n\n
\n\n
A central question is also where the data should be stored, i.e., only on the user's terminal device or on a central server, and who should have access to the data. If the data are only stored on the mobile device, the user has full control over the data and access. However, if the data are stored on a central server, other people can have access over which the user has no control. This question is currently being hotly debated in connection with the development of a COVID-19 tracing app, whereby the proponents of a decentralised solution believe that this approach is more consistent with the principle of data minimisation.
\n\n
\n\n
Which approach is ultimately chosen depends on the type of the mobile health app and its purposes. With both models, appropriate TOMs must be taken to protect the data from unauthorised access and misuse.
\n\n
\n\n
Legal justification
\n\n
\n\n
The processing of personal data must be lawful and carried out in good faith and must have a legal basis, as set out in Art. 6 and 9 of the GDPR and the ePrivacy Directive. The ePrivacy Directive requires the user's consent for the storage of information or access to stored data on the user's equipment unless the storage and access are legally permitted under national law, or the storage and access are strictly necessary to provide a service explicitly requested by the user. The consent shall also be required for the use of non-essential cookies or similar technologies on users' equipment and for the processing of location data other than traffic data, provided that such data are not anonymised.
\n\n
\n\n
In health or medical applications collecting and processing special categories of a patient or consumer data, the processing of these data will regularly require the explicit consent of the data subject. Consent must be voluntary and specific to each functionality that serves different purposes. Consent must be based on prior information and, in the case of special categories of data, the use of cookies or location data, consent must be given explicitly and therefore through positive action, such as downloading the application and ticking a consent box. Also, controllers must have a procedure in place which, on the one hand, allows for easy withdrawal of consent and, on the other hand, ensures that in the event of withdrawal, the data collected will not be further processed.
\n\n
\n\n
Transparency
\n\n
\n\n
Personal data must be processed transparently. Comprehensive privacy notice about what personal data are processed, how they are processed, and what they are used for, as described in Art. 12-14 GDPR, must be made available to the data subjects before their data are processed. This notice must, if applicable, also contain information on the use of cookies or similar technology on the terminal equipment and location data, as well as methods for refusing to store such cookies or giving consent to the use of cookies and location data.
\n\n
\n\n
Data subjects should have full transparency and control over the processing of their data and understand what data are processed, why, by whom, where and for how long, and how they can exercise their privacy rights.
\n\n
\n\n
The privacy notice should be easily accessible to data subjects at any time, before the collection of personal data and throughout the processing, either within the device or through a link to a website. The notice should be easy to understand, where appropriate in different languages, and have a multi-layered structure in which the essential information is summarised in a first layer, possibly supported visually by symbols, and with further details in a second layer if the user wishes to know more. The product should also enable for changes to the privacy notice and should allow users to manage their profiles and update their privacy settings.
\n\n
\n\n
Confidentiality and access to personal data
\n\n
\n\n
Personal data must be kept strictly confidential and may only be provided or disclosed to individuals on a need-to-know basis to fulfil the legitimate purposes for which the information was collected.
\n\n
\n\n
It is essential to determine whether access to the data by persons other than the user, such as doctors, service providers, insurance companies or authorities, is necessary to fulfil the purposes for which the data are processed. Accesses to the data, devices, server, and network should be documented.
\n\n
\n\n
Among the key issues are: Can the user influence and manage these accesses directly through the product? Who enters the data, only the user of the product or other persons, such as a doctor or a pharmacist? Are any service providers involved in the storage or other processing of the data? How is access or sharing of the data secured? Are the data encrypted during transmission and in storage? Who should have access to what personal data and for what purposes? Are these persons obliged to maintain confidentiality? How is access controlled and restricted?
\n\n
\n\n
Purpose limitation
\n\n
\n\n
Personal data must be collected only for specified, explicit, and legitimate purposes and not further processed in a way incompatible with those purposes.
\n\n
\n\n
The purpose of the processing should be specific and explicit and communicated to data subjects at the time of collection. The functionalities of the app should be set up as such that personal data are only processed for the specific purpose that was identified. Access to servers should be limited to persons that are committed to processing the data for the specified purpose only. If the personal data are to be used for purposes other than those notified, the data should be made anonymous, unless there is another legal basis for this secondary use. In any case, the data subjects should be informed and, unless there is no other legal basis, their consent should be obtained.
\n\n
\n\n
Data quality
\n\n
\n\n
Personal data stored must be accurate and, where necessary, up to date; every reasonable step must be taken to ensure that inaccurate personal data are deleted or rectified without delay.
\n\n
\n\n
The controller must have mechanisms in place to ensure that the data are accurate at the time of collection and are not unlawfully modified after that. There must be a mechanism to correct or delete inaccurate data, possibly by the user of the application.
\n\n
\n\n
Data retention
\n\n
\n\n
Personal data must be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed, unless regulatory or legal requirements require a longer or shorter retention period.
\n\n
\n\n
The controller must define a retention period for each data set, based on the purpose of the processing and, where appropriate, legal and regulatory retention periods. Mechanisms, including automatic solutions, where appropriate, and responsibilities for the effective erasure of the data must also be specified. If the data cannot be deleted, they should be made anonymous or, if this is not possible, pseudonymous.
\n\n
\n\n
Among the key issues are: Does the product allow for flexible data retention periods? Does the product enable the anonymization or deletion of data that is no longer needed? Is the data automatically deleted or anonymised after the retention period has expired? Is the data controller notified in advance by the system? Can users delete the data, and if so, how (e.g., by deactivating the app used)? Is there a retention and deletion concept?
\n\n
\n\n
Data security
\n\n
\n\n
Personal data must be processed in a manner that ensures appropriate security of the data, including protection against unauthorised or unlawful processing and accidental loss, destruction or damage, using appropriate TOMs. Such measures should encompass integrity and confidentiality, availability, resilience, and traceability and ensure a level of security appropriate to the risk.
\n\n
\n\n
Appropriate control access mechanisms and authentication measures should be embedded in the product infrastructure to detect and monitor unauthorised access to the data. Personal data should be encrypted on the device and, if stored on a server or shared with third parties, in transit and storage. Special attention is required if the data are stored in the cloud.
\n\n
\n\n
Privacy rights
\n\n
\n\n
Data subjects have a variety of privacy rights, including the right to information, the right of access, rectification and erasure, restriction of processing, data portability and the right to object to automated individual decision-making. They also have the right to complain with their supervisory authority if they feel that their rights are infringed, or their data are not appropriately protected. A process must be in place to respond to data subjects’ access requests and other privacy rights.
\n\n
\n\n
Among the key issues are: How can data subjects effectively exercise their rights? Does the product allow data subjects to exercise their rights directly through the app, in particular the right to access their data and correct it in case of inaccuracies or to delete the data from the mobile device by deleting the app? Are any rights restricted? How are rights such as data portability, deletion, or withdrawal of consent guaranteed?
\n\n
\n\n
Data processing by third parties and cross-border data transfers
\n\n
\n\n
Depending on the roles of the contributors in the development, management, and use of the app and the data processed, appropriate contractual obligations must be established to ensure data protection.
\n\n
\n\n
The controller must carry out a prior assessment of all data processors to ensure that they implement appropriate TOMs to ensure compliance with the data protection requirements and data subjects’ privacy rights.
\n\n
\n\n
If personal data are to be transferred to third parties outside the EEA in a country without a formal adequacy decision by the European Commission, adequate safeguards, such as EU standard contractual clauses, must be implemented to legitimise cross-border data transfers, unless a derogation as listed in Art. 49 GDPR applies, such as the explicit consent of the data subject.
\n\n
\n\n
For any cross-border data flow, the legal basis for such a transfer must be determined, and the necessary steps taken.
\n\n
\n\n
Accountability
\n\n
\n\n
The controller is responsible for ensuring compliance with the data protection principles and for providing proof of compliance with them. Appropriate processes, regular risk assessments, documentation, and reviews of the processing should be in place to support this obligation.
\n\n
\n\n
5 Conclusion
\n\n
\n\n
To fully exploit the benefits of digital health solutions and ensure their effectiveness, it is essential to embed fundamental data protection principles in the design of these solutions, taking into account organisational, process and product-related risks, as well as risks to the rights of data subjects.
\n\n
\n\n
Privacy by design is not only required by the GDPR and partly by laws of other countries outside the EEA but is a prerequisite for the effective and sustainable implementation of data protection, the basis for a well-functioning data protection management and a critical factor in achieving the necessary trust of the public, patients and consumers, public authorities, business partners and other stakeholders in such technologies.
\n\n
\n","datum":"13.07.2020","teasertext":"
The exponential growth of digital health solutions and products, such as software or internet-enabled devices, brings a range of benefits for patients, the health industry and the general public. To be effective, these technologies rely on the use of large amounts of data. Particular caution is needed when personal data are involved, as the processing of personal data, in particular health-related data, can pose significant risks to the privacy of data subjects and the security of personal data. This article examines the privacy aspects under the GDPR that need to be taken into account when designing digital health solutions. It also attempts to clarify the concept of privacy by design and to translate legal requirements into practical solutions, with a focus on mobile applications in the context of digital health.
\n","preview":"","datei":[],"linkextern":""},{"id":100,"title":"Why should companies invest in Binding Corporate Rules?","slug":"why-should-companies-invest-in-binding-corporate-rules","link":"/en/news-knowledge/why-should-companies-invest-in-binding-corporate-rules","titel":"Why should companies invest in Binding Corporate Rules?","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
1 Introduction
\n\n
\n\n
Article 47 of the EU General Data Protection Regulation (\"GDPR\") expressly recognizes Binding Corporate Rules (\"BCR\") as one of the means for the international transfer of personal data, both for controllers (covering personal data they control) and for processors (covering personal data they process on behalf of others based on a processing agreement). Before the GDPR came into force, BCR were recognized and approved by the current practice of the data protection authorities and the guidelines of the Article 29 Working Party (“Working Party”). Other countries outside of the EU, such as Switzerland, recognize the concept of BCR as well.
\n\n
\n\n
What is the practical significance of BCR for companies and why should companies invest in BCR? This article shall explore what BCR under the GDPR are, what needs to be considered when applying and implementing BCR and their benefits.
\n\n
\n\n
2 What are Binding Corporate Rules?
\n\n
\n\n
The GDPR defines the term “Binding Corporate Rules” in Art. 4 para. 20 as “personal data protection policies which are adhered to by a controller or processor established on the territory of a Member State for transfers or a set of transfers of personal data to a controller or processor in one or more third countries within a group of undertakings, or group of enterprises engaged in a joint economic activity”.
\n\n
\n\n
BCR are therefore one of the appropriate safeguards for the transfer of personal data within a group of undertakings, or group of enterprises engaged in a joint economic activity (“Group”) from the EEA to countries which do not provide an adequate level of data protection. In practice, BCR are a set of internal rules, standards and processes, such as codes of conduct, that regulate internal data management practices in a binding and consistent manner throughout the Group with the primary objective to facilitate the free movement of personal data within that Group while ensuring an effective level of data protection. BCR are, however, not intended to be used as a means for allowing cross-border data transfers to companies not being part of that Group.
\n\n
\n\n
The concept and content of the BCR have mainly remained the same under the GDPR, with some minor changes. One significant change is the extension of the group of applicants. While BCR were previously only applicable to groups of undertakings, they are now also open to groups of enterprises engaged in joint economic activities. The term \"group of undertakings\" is defined in Art. 4 para. 19 GDPR as \"controlling undertaking and its controlled undertakings\". However, the term \"group of enterprises engaged in a joint economic activity\" is not defined in the GDPR. The term is open for interpretations but may be interpreted as to include a group of independent organizations which have agreed to cooperate, such as joint ventures.
\n\n
\n\n
Also, the list of minimum requirements has been extended to include the contact details of each member of the Group, the description of the principles of privacy by design and privacy by default, the right not to be subject to profiling, the information obligations according to Art. 13 and 14 GDPR, and the details of the persons responsible for training and complaint procedures.
\n\n
\n\n
The Working Party provides in WP 256 (BCR for controllers) and WP 257 (BCR for processors) updated guidelines and very useful tables setting out the elements and principles that controllers and processors should state in their BCR, incorporating the new language in line with the GDPR and the necessary content mandated by Art. 47 GDPR and making a distinction between what must be included in the BCR and what must be presented to the competent supervisory authority in the BCR application.
\n\n
\n\n
BCR must comply with a whole range of requirements and must contain all elements as set out in Art. 47 para. 2 GDPR, including:
\n\n
\n\n
\n
The structure and contact details of the group of undertakings, or group of enterprises engaged in a joint economic activity and of each of its members;
\n
\n\n
\n\n
\n
The data transfers or set of transfers, including the categories of personal data, the type of processing and its purposes, the type of data subjects affected and the identification of the third country or countries in question;
\n
\n\n
\n\n
\n
Their legally binding nature, both internally and externally;
\n
\n\n
\n\n
\n
The application of the general data protection principles, in particular purpose limitation, data minimization, limited storage periods, data quality, data protection by design and by default, legal basis for processing, processing of special categories of personal data, measures to ensure data security, and the requirements in respect of onward transfers to bodies not bound by the BCR;
\n
\n\n
\n\n
\n
The rights of data subjects in regard of processing and the means to exercise those rights, including the right not to be subject to decision based solely on automated processing, including profiling, the right to lodge a complaint with the competent supervisory authority and before the competent courts, and to obtain redress and, where appropriate, compensation for a breach of the BCR;
\n
\n\n
\n\n
\n
The acceptance by the controller or processor established on the territory of a Member State of liability for any breaches of the BCR by any member concerned not established in the Union, whereby the controller and the processor shall be exempt from that liability, in whole or in part, only if it proves that that member is not responsible for the event giving rise to the damage;
\n
\n\n
\n\n
\n
How the information on the BCR, in particular on the provisions relating to the general data protection principles, the rights of the data subjects, and the liability for any breaches of the BCR is provided to the data subjects;
\n
\n\n
\n\n
\n
The tasks of any data protection officer designated in accordance with Art. 37 GDPR or any other person or entity in charge of monitoring compliance with the BCR as well as monitoring training and complaint handling;
\n
\n\n
\n\n
\n
The complaint procedures;
\n
\n\n
\n\n
\n
The mechanisms for ensuring verification of compliance with the BCR. Such mechanisms shall include data protection audits and methods for ensuring corrective actions to protect the rights of the data subject. Results of such verification should be communicated to the DPO or any other person in charge of monitoring compliance with the BCR and to the board of the controlling undertaking, and should be available upon request to the competent supervisory authority;
\n
\n\n
\n\n
\n
The mechanisms for reporting and recording changes to the BCR and reporting those changes to the supervisory authority;
\n
\n\n
\n\n
\n
The cooperation mechanisms with the supervisory authority to ensure compliance by any member of the group of undertakings, or group of enterprises engaged in a joint economic activity, in particular by making available to the supervisory authority the results of verifications;
\n
\n\n
\n\n
\n
The mechanisms for reporting to the competent supervisory authority any legal requirements to which a member of the group of undertakings, or group of enterprises engaged in a joint economic activity is subject in a third country which are likely to have substantial adverse effect on the guarantees provided by the BCR; and
\n
\n\n
\n\n
\n
The appropriate data protection training to personnel having permanent or regular access to personal data.
\n
\n\n
\n\n
3 What do companies commit themselves to when signing the BCR?
\n\n
\n\n
By signing the BCR, companies undertake to comply with and implement the rules, in particular to:
\n\n
\n\n
\n
set up a procedure for managing and monitoring the implementation of the BCRs;
\n
\n\n
\n\n
\n
make the BCR binding on employees;
\n
\n\n
\n\n
\n
make the rights of data subjects easily accessible, as set out in the BCR, e.g. via the intranet and the Internet;
\n
\n\n
\n\n
\n
introduce disciplinary procedures for staff who infringe the BCRs;
\n
\n\n
\n\n
\n
comply with the data protection principles as set out in the BCR;
\n
\n\n
\n\n
\n
provide basic training for all employees and specific training for employees with regular access to personal data;
\n
\n\n
\n\n
\n
carry out regular compliance assessments on data protection to ensure the effective application of the BCR;
\n
\n\n
\n\n
\n
establish a procedure to ensure adequate handling of complaints;
\n
\n\n
\n\n
\n
accept liability for any breach of its obligations under the BCR;
\n
\n\n
\n\n
\n
cooperate with other Group companies and support them in dealing appropriately with inquiries from supervisory authorities or other authorities as well as from data subjects; and
\n
\n\n
\n\n
\n
cooperate with and allow audits by the relevant regulatory authorities.
\n
\n\n
\n\n
4 What should organizations consider before applying for BCR?
\n\n
\n\n
The use of BCR as an appropriate safeguard for international data transfers from the EEA requires the approval of the competent supervisory authority in the relevant jurisdiction following the consistency mechanism set out in Art. 63 and 64 GDPR. The competent supervisory authority will approve the BCR under the condition that:
\n\n
\n\n
\n
BCR are legally binding and enforceable on the undertakings concerned;
\n
\n\n
\n\n
\n
BCR expressly confer on the data subjects’ enforceable rights concerning the processing of their personal data; and
\n
\n\n
\n\n
\n
BCR comply with the minimum information requirements set out in Art. 47 para. 2 GDPR.
\n
\n\n
\n\n
Before applying for BCR approval, an organization should carefully consider and answer some key questions:
\n\n
\n\n
What does the company want to achieve with the approved BCR?
\n\n
\n\n
Is the only objective to facilitate the free flow of personal data within the Group? If so, has the organization considered alternatives, if any, to achieve this objective, such as concluding an intra-group data transfer agreement (“IGDTA”)? Alternatively, is the company's goal, besides safeguarding cross-border data transfers, also to achieve and demonstrate accountability and commitment to responsible data use? If so, the organization should assess whether BCR are the right approach or whether there are other options such as certification or a code of conduct, which might be more suitable for achieving the interests of the organization.
\n\n
\n\n
Which BCR should be implemented?
\n\n
\n\n
The organization must determine if it wants to apply for BCR for controllers or BCR for processors, or both. Depending on that decision, the appropriate requirements must be fulfilled.
\n\n
\n\n
What shall be the scope of the BCR?
\n\n
\n\n
Shall the BCR only cover personal data transferred from the EEA within the Group or shall they cover all processing of personal data within the Group? This last option would include any data and go far beyond the legal requirements extending the liability and privacy rights. This extension is ultimately a decision that each organization must take and may be appropriate for organizations that have decided to establish the same set of rules, standards and rights throughout the whole organization, irrespective of the jurisdiction and legal requirements. The organization must also determine if it wants to cover all personal data or limit the BCR to only a set of data such as HR or customer data. Finally, the organization must determine if all members of the Group shall be bound by the BCR or only a selected number of companies.
\n\n
\n\n
Which supervisory authority should be the lead authority for the BCR (“BCR Lead”)?
\n\n
\n\n
The BCR Lead is the authority that acts as the single point of contact with the applicant organization during the authorization procedure and the application process in its cooperation phase. The BCR Lead may differ from the \"one-stop-shop\" lead supervisory authority according to Art. 56 GDPR, which is mainly involved in handling data breaches and investigatory or enforcement activities in cross-border processing operations within the EU. The organization applying for BCR authorization must justify the reasons why a particular supervisory authority should be considered as the BCR Lead. The criteria for such justification are set out in WP 263:
\n\n
\n\n
\n
The location of the Group’s European headquarters;
\n
\n\n
\n\n
\n
The location of the company within the Group with delegated data protection responsibilities;
\n
\n\n
\n\n
\n
The location of the company which is best placed (in terms of the management function, administrative burden, etc.) to deal with the application and to enforce the BCR in the Group;
\n
\n\n
\n\n
\n
The place where most decisions in terms of the purposes and the means of the processing (i.e. transfer) take place; and
\n
\n\n
\n\n
\n
The member state within the EU from which most or all transfers outside the EEA will take place.
\n
\n\n
\n\n
For companies with their head office or principal place of business in the EU, the justification is quite simple. However, how should companies with their registered office outside the EU and without a principal place of business in the EU choose the appropriate supervisory authority and justify their choice? What arguments could be put forward if there is no Member State within the EU from which most or all transfers are made outside the EEA, but such transfers are roughly the same between all entities in the EU? In this case, the organization may delegate responsibilities to the Group company that is best placed to process the application for BCR on behalf of the Group. This entity should be located in one of the most important countries for the Group with a strong presence and at the same place as the chosen supervisory authority.
\n\n
\n\n
Once the organization has selected the BCR Lead based on the criteria mentioned above, it will submit its application to that supervisory authority. It should be noted, however, that the selected supervisory authority is not obliged to accept the choice if it believes that another supervisory authority is more suitable to be the BCR Lead, in particular taking into account the workload and number of pending BCR applications. The requested supervisory authority will share the application with all concerned supervisory authorities to make a final decision on which supervisory authority is appointed as BCR Lead.
\n\n
\n\n
It is advisable that the organization contacts the selected supervisory authority before applying to check whether the supervisory authority is, in principle, willing to act as BCR Lead or whether there may be objections from the supervisory authority, for example, due to lack of resources to deal with the application in a timely manner.
\n\n
\n\n
What should the liability system look like?
\n\n
\n\n
Art. 47 para. 2f requires the acceptance by the controller or processor established on the territory of a Member State of liability for any breaches of the BCR by any member concerned not established in the Union. WP 256 and WP 257 provide that, where it is not possible for a Group with particular corporate structures to impose on a specific entity to take all the responsibility for any breach of the BCR outside of the EU, it may provide that every BCR member exporting data out of the EU on the basis of the BCR will be liable for any breaches of the BCR by the BCR member established outside the EU which received the data from this EU BCR member. Will it be acceptable for the BCR Lead to introduce an alternative liability system in line with the Standard Contractual Clauses? If not, which Group company could take responsibility? What are the options? Clarification of this issue is crucial, especially for companies based outside the EU which do not have a main establishment in the EU. For some organizations, it may not be feasible to allocate responsibility for the payment of damages to a local entity as a result of a breach of the BCR by a Group company outside the EU.
\n\n
\n\n
What is the implementation status of the data privacy management program within the organization?
\n\n
\n\n
Has the organization already implemented global standards, policies and procedures, and if so, what is the maturity level at the corporate level and throughout the organization? Where are potential gaps and risks? Depending on the groundwork done and the maturity level of the data protection management program, the BCR approval process may take longer or shorter.
\n\n
\n\n
Is the buy-in of key stakeholders secured?
\n\n
\n\n
Do key stakeholders, from executive management to key country organizations and functions, offer their buy-in to the process? Stakeholder support requires their awareness and understanding of the need and benefits of implementing BCR, the commitments that each business unit and function must make with BCR approval, and the expectations placed in them. Preliminary discussions and presentation of the business case with these stakeholders are therefore an essential step before applying for BCR.
\n\n
\n\n
Are there sufficient resources and expertise to manage the approval and implementation of BCR?
\n\n
\n\n
Is there a team in place to develop the BCR, collect all relevant information, involve the relevant functions, discuss with the BCR Lead and manage the communication and implementation of the BCR across the organization? This team may consist of a leader and project manager as well as contributors to critical functions and most important markets. A proper functioning internal team is crucial to a smooth approval process and implementation throughout the organization. For smaller companies with fewer resources and expertise in data protection and project management, the involvement of external experts should be considered.
\n\n
\n\n
5 What should organizations consider once BCR approval is obtained?
\n\n
\n\n
The approval of the BCR is an essential step in the whole process. However, the BCR have no practical effect if not correctly implemented throughout the Group. Therefore, in parallel to the approval process, it is crucial that the organization that is responsible for the implementation of the BCR puts in place a concrete and enforceable communication and implementation plan with responsibilities and reasonable timelines. Here are some suggestions as to what such a plan should at least contain:
\n\n
\n\n
A communication plan that sets out who should inform whom, how, when and about what during the whole process. When applying for BCR approval, all Group companies and functions at the corporate and local level should be informed of the content and impact of the BCR, in particular their obligations, and of the progress of the BCR approval process. They should also be informed of the steps they need to take before approval to best prepare for the implementation of the BCR. Throughout the process, it is also advisable to address possible problems, questions and concerns to ensure the broadest possible support and to prevent serious issues or concerns from arising following the approval of the BCR. In some countries, works councils must also be informed or consulted, and finally, once approved and implemented, all employees who regularly process personal data must be informed and trained. Clear roles and responsibilities must be assigned to ensure appropriate communication at each level of the organization.
\n\n
\n\n
An implementation plan that is addressed to those functions and individuals responsible for implementing the privacy management program and the BCR, in practice the data protection officers, managers or champions, and outlines what needs to be done, when and how. The steps may include the preparation by adopting the Group privacy policy framework and implementing the data protection management program at the local level, signing the BCR and making them binding upon employees, training employees, verifying compliance with the BCR and handling complaints.
\n\n
\n\n
Effective BCR require the establishment of an organization with responsible persons at corporate and local level to implement the BCR and monitor compliance. A person at corporate level should be appointed to maintain an updated list of BCR members, monitor the state of implementation and any changes, and report annually to the supervisory authority.
\n\n
\n\n
6 Why should organizations invest in BCR?
\n\n
\n\n
In practice, many companies have concluded so-called intra-group data transfer agreements (“IGDTA”) covering the cross-border transfer of personal data within their Group. So why should companies go through the effort of implementing BCR when they can achieve the same goal with an IGDTA? Companies with an IGDTA meet the legal requirements for cross-border data transfer. However, they may not benefit from the impact of BCR, which significantly increase awareness and understanding of privacy requirements within the organization and establish accountability for compliance with data protection requirements in each function and business unit at corporate and local levels throughout the organization. Also, the effort required to create an IGDTA that includes the evaluation of all types of data flows, categories of personal data, purposes and safeguards, as well as the recipients of the data, the documentation of this information, the possible translation into the local language and the signing of contracts by all affiliates, should not be underestimated. It requires the involvement of all business units and functions at global and local levels. At the same time, the IGDTA often remains in a drawer after signing and is never considered again. Rarely will companies implement an IGDTA by establishing appropriate policies, procedures, processes and training.
\n\n
\n\n
Organizations that develop and implement BCR regularly aim at achieving an appropriate data protection governance structure with uniform standards and processes across the enterprise and not only at transferring their data legitimately within the Group. With the approval of the BCR by the supervisory authorities, organizations also want to show that they not only take data protection seriously, but also effectively implement the requirements in the company and assume responsibility for compliance with data protection.
\n\n
\n\n
BCR are based on a comprehensive and effective data protection management program with all the elements required to demonstrate accountability. These elements include:
\n\n
\n\n
\n
A governance structure with leadership and oversight of the data protection program;
\n
\n\n
\n\n
\n
A policy framework with policies and procedures to ensure fair and responsible processing of personal data;
\n
\n\n
\n\n
\n
Transparency through appropriate communication to data subjects;
\n
\n\n
\n\n
\n
Risk assessment and management at the program and data processing level;
\n
\n\n
\n\n
\n
Awareness raising and training of employees and others who process personal data;
\n
\n\n
\n\n
\n
Monitoring compliance with the data protection program and verification of its effectiveness through regular self-assessments and internal or external audits; and
\n
\n\n
\n\n
\n
Processes to adequately respond to data subjects' rights, complaints and inquiries, as well as privacy incidents and to enforce compliance with internal rules.
\n
\n\n
\n\n
Organizations subject to the GDPR and other stringent data protection acts must establish a comprehensive data protection management program including all the elements as listed above to ensure compliance with the applicable requirements and responsible data use. With the implementation of such a privacy management program organization are ready to consider applying for BCR approval in order to benefit from a valid data transfer mechanism while increasing their commitment to privacy within the company and promoting a culture of responsible data use.
\n\n
\n\n
To obtain approval of the BCR and ensure compliance with the commitments that are made with the application, the data privacy management program must, however, include specific procedures and processes. The organization must assign responsibilities for the implementation of the BCR to each BCR member, in particular for binding the company and its employees to the BCR and for publishing notices. It must further establish a complaint handling process, develop awareness-raising and training plans and have a mechanism to implement these plans, such as the introduction of regular e-learning for all employees and tailor-made training for specific functions and persons with data protection responsibilities. The organization must also establish an audit framework and a program to ensure that internal or external accredited auditors regularly verify compliance with the BCR. A mechanism must also be put in place to track all changes and inform BCR members and the supervisory authority. A list of BCR members must be maintained and made available to all members who are required to inspect that list before transferring personal data across borders.
\n\n
\n\n
BCR are ultimately a formalization and publication of the data protection management program. At the same time, they are a mechanism for demonstrating accountability to regulators, business partners, customers and individuals and integrating data protection and security into the company's culture. Processors also gain an immediate competitive advantage compared to other service providers that do not have BCR. The benefits of BCR are apparent and should be considered by any multinational company with cross-border data flows.
\n\n
\n\n
7 Conclusions
\n\n
\n\n
BCR are not only a sustainable legal basis for data transfer but also a system that enables companies with approved BCR to be transparent to regulators, customers, consumers and business partners by disclosing the company's policies and procedures on how they process and secure personal data. At the same time, BCR help organizations demonstrate that they take data protection seriously and that they have adopted appropriate data management practices to ensure compliant and responsible data processing throughout the Group. By implementing BCR, organizations affirm their responsibility to comply with legal requirements and regularly go even beyond by implementing common standards and rights for individuals across the Group. BCR help to further improve the quality and maturity of the Group's privacy management program by fostering a culture of internal compliance and accountability and strengthening the overall trust of individuals, customers, business partners and regulators.
\n\n
\n\n
Implementing BCR brings a whole range of benefits not only for the Group itself but also for the data subjects and the supervisory authorities. The effort involved in the approval and implementation process pays off in any case, measured by the advantages for multinational companies, large or small, which stand for the legally compliant and responsible handling of personal data. At the same time, and as further motivation for companies to invest in BCR, it would be desirable for supervisory authorities to formally recognize BCR as an accountability system beyond a data transfer mechanism, along with certifications and codes of conduct, and to find ways to further speed up the approval process.
\n\n
\n","datum":"30.06.2019","teasertext":"
What is the practical significance of BCR for companies and why should companies invest in BCR? This article explores what BCR under the GDPR are, what needs to be considered when applying and implementing BCR, and their benefits.
\n","preview":"","datei":[],"linkextern":""},{"id":157,"title":"Implementing Privacy by Design in practice","slug":"implementing-privacy-by-design-in-practice","link":"/en/news-knowledge/implementing-privacy-by-design-in-practice","titel":"Implementing Privacy by Design in practice","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
1 Introduction
\n\n
\n\n
Data protection has become increasingly important in recent years. Not only have the EU and many countries around the world revised their data protection laws and introduced stricter rules to protect the rights of data subjects and significant sanctions for non-compliance with the law. The awareness and expectations of individuals, such as consumers, patients, employees, service providers and business partners, as well as public authorities, have also increased significantly. While until a few years ago data protection was hardly on the priority list of many companies and hardly any resources were spent on implementing the legal requirements, most companies have realized since the introduction of the EU General Data Protection Regulation (GDPR) that data protection is a serious issue.
\n\n
\n\n
The reason for the increased sensitivity to data protection is not only the threat of sanctions and the loss of reputation in the event of a breach of data protection regulations. Companies have understood that they can only take full advantage of new technologies such as Blockchain, Machine Learning, Artificial Intelligence, Internet of Things and Mobile Apps if they meet individuals' expectations, maintain their trust and respect their privacy. Today, data protection is no longer seen as just a compliance or information security issue, but as an essential factor in building and maintaining trust, competitiveness and success in the marketplace.
\n\n
\n\n
Organizations must know and foresee their risks and take appropriate measures to eliminate them, reduce them to an acceptable level or manage them. To this end, organizations must, first of all, know what personal data they store and process, in which business areas, in which systems and for what purposes. This knowledge is the fundamental prerequisite for active risk and data protection management.
\n\n
\n\n
Before processing personal data, companies must take into account the data protection aspects and principles as well as possible restrictions and risks in advance and take appropriate risk-minimizing measures. Such an assessment is necessary, for example, before the introduction of a new data-processing system or a health app or before the storage of particularly sensitive data in a cloud, the introduction of a monitoring system in the company or the outsourcing of data processing to a service provider in a country outside the EEA or Switzerland. With this approach, the company can not only ensure compliance with legal requirements, but also make strategic and operational decisions in advance and efficiently implement business processes. This can include, for example, storing data on servers in Switzerland instead of in the USA or purchasing software with integrated data protection principles. The company can also take the necessary steps to ensure that its privacy policies and applicable laws are implemented.
\n\n
\n\n
This procedure is nothing more than “privacy by design.”
\n\n
\n\n
2 Privacy by design: a new obligation for controllers
\n\n
\n\n
The EU General Data Protection Regulation (GDPR) has introduced a legal obligation for controllers referred to as “data protection by design and by default.” This principle requires the controller to implement appropriate technical and organizational measures designed to implement data protection principles into the processing of personal data in an effective manner. Failures to comply with this obligation are subject to significant fines following Art. 83 GDPR.
\n\n
\n\n
Further laws have introduced the concept of privacy by design, such as the Draft Swiss Federal Act on Data Protection, published on September 15, 2017 (D-FADP)1 or the new Indian Personal Data Protection Bill which was published in 2018.2 The concept has further been introduced, although not explicitly, in the new Brazilian General Data Protection Law (Lei Geral de Proteção de Dados, LGPD) which will come into effect in early 2020.3
\n\n
\n\n
The concept of privacy by design is a fundamental requirement for the effective implementation of data protection. Privacy by design essentially requires controllers to take into account the privacy principles and requirements both, at the design stage of any IT system and technology, business practice, service or product and throughout the whole life cycle of the personal data, and to embed appropriate technical and organizational measures to implement the data protection requirements and to protect the rights of data subjects.
\n\n
\n\n
Although implementing data protection by design has become a new obligation under the GDPR, the concept is not new. It had existed for a long time as best practice and served as a practical approach to those organizations that had implemented data protection principles before the GDPR was even drafted.
\n\n
\n\n
The concept was already indirectly considered in EU Directive 95/464 and then introduced in 2009 as “Privacy by Design” by Ann Cavoukian, at that time the Information and Privacy Commissioner of Ontario, Canada, building on seven basic principles5:
\n\n
\n\n
Be Proactive, not Reactive; Preventative not Remedial: Being proactive and preventative anticipates and prevents privacy invasive events before they happen and privacy risks before they materialize.
\n\n
\n\n
Privacy as the Default: Privacy, in particular, transparency, data minimization, purpose limitation, confidentiality and data retention, is built into filing systems and business processes by default, automatically protecting personal data without the need for the data subjects to become active.
\n\n
\n\n
Privacy Embedded into Design: Privacy is embedded into the design and architecture of IT systems and business practices in a holistic and integrative way becoming an essential component of the core functionality being delivered. This means that privacy is integral to the system, without diminishing its functionality.
\n\n
\n\n
Full Functionality – Positive-Sum, not Zero-Sum: All legitimate interests and objectives, and not only the privacy goals, shall be accommodated without unnecessary trade-offs. Creative solutions shall be found that enable multifunctionality.
\n\n
\n\n
End-to-End Security – Lifecycle Protection: Personal data shall be secured, depending on their level of sensibility, from the collection throughout the entire lifecycle, by strong technical and organizational measures such as appropriate encryption, strong access controls and logging methods.
\n\n
\n\n
Visibility and Transparency: Visibility and transparency about the processing operations are essential to establishing accountability and trust.
\n\n
\n\n
Respect for User Privacy: The privacy of individuals should remain at the center of the interest and individuals should be offered measures such as strong privacy defaults, appropriate notice, and empowering user-friendly options.
\n\n
\n\n
Privacy by design was finally recognized by the 32nd International Conference of Data Protection and Privacy Commissioners in 2010 as “an essential component of fundamental privacy provisions6” and can also be found in various other documents, such as the FDPICs guide to technical and organizational measures for data protection of 2015.7 A similar concept, “Security by Design” follows the same approach and can be found in standards such as ISO/IEC/27001.
\n\n
\n\n
By introducing the concept of privacy by design as a legal obligation, the legislator ultimately wants to make it clear that it is not enough to set standards, but that these standards must be implemented effectively and verifiably. The principle applies to the entire processing of personal data, whether in the development and implementation of new business processes, systems, services or products that process personal data in any way.
\n\n
\n\n
3 How to implement privacy by design in practice?
\n\n
\n\n
3.1 What does Article 25 GDPR say?
\n\n
\n\n
Article 25 GDPR describes the concept of privacy by design and covers the following questions:
\n\n
\n\n
\n
Who is obliged to implement privacy by design? The controller. Manufacturers of products and applications as well as service providers are only encouraged to consider privacy by design in recital 78 GDPR. In practice, however, manufacturers and service providers will have a keen interest in implementing the concept to remain competitive.
\n
\n\n
\n\n
\n
What needs to be done? The controller must implement technical and organizational measures, so-called TOMs, such as the pseudonymization of personal data.
\n
\n\n
\n\n
\n
How must the TOMs be? They must be adequate8 and appropriate to implement data protection principles such as data minimization effectively and to integrate the necessary safeguards into the processing to meet the requirements of the GDPR and to protect the rights of data subjects.
\n
\n\n
\n\n
\n
When must TOMs be implemented? Both at the time of determining the means for processing and during the processing itself.
\n
\n\n
\n\n
Article 25 GDPR does, however, not specify how this obligation is to be implemented in practice.
\n\n
\n\n
The mention of pseudonymization in Art. 25 GDPR can only be understood as an example of a technical measure. Further technical measures, such as access authorizations and restrictions, user authentication, access restrictions, encryption, logging, secure system configurations, protective measures against malware and data loss, physical protective measures, as well as a technical implementation of the right of objection and the correction or deletion of data or data portability must also be considered. Article 32 GDPR (and in Switzerland Art. 7 FADP) must be observed.
\n\n
\n\n
Furthermore, organizational measures must also be taken. These include, for example, policies, guidelines, instructions and manuals, records of processing activities, documentation of data breaches and data protection impact assessments, contracts with third parties and processors, training and controls, meaning all the elements that are necessary for a well-functioning data protection management system.
\n\n
\n\n
The technical and organizational measures must be suitable for implementing the data protection principles and safeguarding the rights of the data subjects, whereby data minimization is again only mentioned as one example. Of course, all other principles, such as lawfulness, transparency, confidentiality, purpose limitation, data integrity, storage duration and security, as well as the requirements concerning commissioned data processing and cross-border data transfers must also be taken into account.
\n\n
\n\n
3.2 How can Article 25 GDPR be implemented in practice?
\n\n
\n\n
One effective way to implement privacy by design in practice is to build a data management and risk assessment program with responsibilities and a process to identify systematically, evaluate, address and mitigate potential privacy and security risks associated with the collection and processing of personal data. The seven best practices principles described in Chapter 2 can serve as guidance for the implementation of data protection by design in the company. An effective data management and risk assessment program should include the following elements:
\n\n
\n\n
3.2.1 Data Protection Management System (Fig.1)
\n\n
\n\n
\n
A documented commitment by management to establish and enforce high standards of data protection for the company with the aim of integrating data protection into the corporate culture and embedding the data protection principles in the design and implementation of corporate policies, data protection management systems, business practices, services and products.
\n
\n\n
\n\n
\n
The appointment of a data protection advisor and allocation of responsibilities at all levels of the organization, including management, business units and functions, for the effective implementation of data protection requirements.
\n
\n\n
\n\n
\n
The establishment of a data protection framework with enforceable data protection policies and guidelines that attach appropriate importance to data protection and regulate the collection, processing, transfer, storage and deletion of data, as well as mechanisms to monitor implementation and compliance with standards and rules.
\n
\n\n
\n\n
\n
The application of appropriate processes to ensure that data protection principles and requirements are adequately taken into account and integrated into data processing procedures and thus the principle of privacy by design is lived.
\n
\n\n
\n\n
\n
The introduction of records of processing activities.
\n
\n\n
\n\n
\n
Risk management with compliance checks and, where appropriate, data protection impact assessment.
\n
\n\n
\n\n
\n
Third-party management and data transfer governance.
\n
\n\n
\n\n
\n
Regular and documented awareness campaigns and performance of employee training.
\n
\n\n
\n\n
\n
Regular and documented monitoring and controls through self-assessments and audits to verify the effective implementation of the data protection management program and compliance with legal requirements and internal policies and directives.
\n
\n\n
\n\n
3.2.2 Processes
\n\n
\n\n
The processes, as mentioned above, include the following elements:
\n\n
\n\n
\n
The allocation of responsibilities in the relevant functions, such as Procurement, Legal and IT, which, as “gatekeepers,” ensure that the processes are adhered to.
\n
\n\n
\n\n
\n
The identification of privacy risks relating to systems, websites, apps, business processes or products at the time of the design and throughout the lifecycle of the data, from collection to disposal.
\n
\n\n
\n\n
\n
The documentation of the data processing activities (inventory).
\n
\n\n
\n\n
\n
The performance of compliance and risk assessments and, where appropriate, DPIAs before personal data is collected and stored in systems, transferred or otherwise processed for business purposes of anticipating risks and adverse effects for the individuals concerned and to determine corrective actions.
\n
\n\n
\n\n
\n
The implementation of the identified measures.
\n
\n\n
\n\n
3.2.3 Risk Management
\n\n
\n\n
The conformity and risk assessment of data processing procedures is essential in the privacy by design process and answers questions such as:
\n\n
\n\n
\n
Is the purpose of the processing specifically described? How is it ensured that the data is not processed for other purposes?
\n
\n\n
\n\n
\n
What is the legal basis for the processing of personal data? Is the consent of the data subjects required and, if so, how should it be obtained and documented? How can a withdrawal of consent be asserted and how is it handled and documented? If the controller has a legitimate business interest, were the interests of the controller weighed against the interests of the data subjects? Has this balancing test of interests been documented?
\n
\n\n
\n\n
\n
Are all intended personal data necessary to fulfill the purpose or can specific data sets be omitted if necessary? Can the purpose also be accomplished with anonymous, pseudonymous or simply less data?
\n
\n\n
\n\n
\n
Are the systems, websites, apps, business processes and products which store or process personal data, and which are developed or purchased by the company set up in such a way that only the necessary data for the purpose in question is stored and processed? How is the accuracy of the data ensured?
\n
\n\n
\n\n
\n
Who should have access to which personal data and for what purposes? Is the group of people who should have access to the data defined and documented? Are these persons obliged to maintain confidentiality? How is access controlled and restricted?
\n
\n\n
\n\n
\n
Have processors, if any, been audited to ensure that they can comply with data protection requirements?
\n
\n\n
\n\n
\n
Are data processing agreements and other arrangements in place, where necessary, to govern the relationship with third parties?
\n
\n\n
\n\n
\n
Is personal data accessed from abroad or transferred abroad? If so, have suitable legal measures been taken and documented to legitimize the data transfer? How are the measures implemented and compliance monitored?
\n
\n\n
\n\n
\n
Are all necessary security measures planned and, if necessary, already implemented?
\n
\n\n
\n\n
\n
What rights do the data subjects have? Are there any restrictions? How is it ensured that data subjects could exercise their rights effectively? Who is responsible for responding to data subjects requests? How are rights such as data portability, deletion or revocation of consent guaranteed?
\n
\n\n
\n\n
\n
How long should personal data be stored and processed? Is there a retention and deletion concept?
\n
\n\n
\n\n
\n
Are the data subjects informed about the processing of their personal data or is notice planned and how is it to be carried out? Is the data protection notice easily understandable and accessible?
\n
\n\n
\n\n
\n
What technical and organizational measures are expected to secure the data and how are these measures to be implemented, verified and controlled?
\n
\n\n
\n\n
\n
What security measures are taken to avoid security incidents? What is the process in the event of a security incident?
\n
\n\n
\n\n
4 Conclusion
\n\n
\n\n
Consistent and sustainable compliance with data protection requires the strategic and conceptual integration of data protection principles in all business practices, in the organizational structure, in the development of rules, IT systems and products. It requires active cooperation between Business, Information Security / IT and Legal / Data Protection.
\n\n
\n\n
The concept privacy by design is not new and has been considered as best practice for years. New is the inclusion of the concept in the GDPR as a legal obligation for controllers, subject to sanctions if violated.
\n\n
\n\n
Privacy by design is, however, not only a legal obligation but also a fundamental prerequisite for the effective and sustainable implementation of data protection and the basis for a well-functioning data protection management.
\n\n
\n\n
\n\n
[1]Art. 6.1, 2 D-FADP: Data Protection by Design: The controller must set up technical and organizational measures in order for the data processing to meet the data protection regulations and in particular the principles set out in Art. 5 (general principles of lawfulness, proportionality, purpose limitation, data minimization, transparency, retention, and quality). It considers this obligation from the planning of the processing.
\n\n
The technical and organizational measures must be appropriate in particular with regard to the state of the art, the type and extent of processing, as well as the risks that the processing at hand poses to the personality and the fundamental rights of the data subjects.
\n\n
Art. 6.3 D-FADP: Data Protection by Default: The controller is additionally bound to ensure through appropriate predefined settings that the processing of the personal data is limited to the minimum required by the purpose, unless the data subject directs otherwise.
[4]Recital 46 Directive 95/46: Whereas the protection of the rights and freedoms of data subjects with regard to the processing of personal data requires that appropriate technical and organizational measures be taken, both at the time of the design of the processing system and at the time of the processing itself, particularly in order to maintain security and thereby to prevent any unauthorized processing; whereas it is incumbent on the Member States to ensure that controllers comply with these measures; whereas these measures must ensure an appropriate level of security, taking into account the state of the art and the costs of their implementation in relation to the risks inherent in the processing and the nature of the data to be protected.
\n\n
\n\n
[5] Privacy by Design: The 7 Foundational Principles, Implementation and Mapping of Fair Information Practices, from Ann Cavoukian, Ph.D.
\n\n
\n\n
[6] Resolution on privacy by design: https://icdppc.org/document-archive/adopted-resolutions/
[8] Article 25.1 GDPR: “Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing.”
\n","datum":"25.03.2019","teasertext":"
The EU General Data Protection Regulation (GDPR) has introduced a legal obligation for controllers referred to as “data protection by design and by default.” This principle requires the controller to take appropriate technical and organizational measures designed to embed data protection principles into the processing of personal data in an effective manner. This article explains how to implement Privacy by Design in practice.
\n","preview":"","datei":[],"linkextern":""},{"id":158,"title":"The concept of controller and processor in practice","slug":"das-konzept-des-verantwortlichen-und-des-auftragsverarbeiters-in-der-praxis","link":"/en/news-knowledge/das-konzept-des-verantwortlichen-und-des-auftragsverarbeiters-in-der-praxis","titel":"The concept of controller and processor in practice","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
1 Introduction
\n\n
\n\n
If several persons are involved in the processing of personal data, the question inevitably arises as to their data-protection-related role. With the introduction of the GDPR and the provisions regarding the relationship of controllers and processors in article 28 and joint controllers in article 26, the difficulties in determining the correct roles of the parties remain. Organizations are increasingly faced with the challenge of determining their role(s), in particular in complex situations and business models where multiple parties in different jurisdictions are involved in the processing activity, each with varying degrees of autonomy, control and responsibility.
\n\n
\n\n
The distinction between the different roles is crucial to allocate responsibilities, and in particular to determine which party must primarily comply with the data protection principles, data subjects’ privacy rights and notification obligations. The distinction is further essential to determine the applicable law in a cross-border context, the contractual arrangements, and the allocation of liability for damages resulting from unlawful processing.
\n\n
\n\n
Following the GDPR, each person that processes personal data is, from a data protection perspective, either a controller or a processor. If several controllers are involved in the processing of personal data, they are, depending on the concrete situation, either joint controllers or independent controllers. The GDPR defines in article 4 the terms “controller,” “processor,” and “processing,” and in article 26 the concept of “joint controller:”
\n\n
\n\n
The “controller” is the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data.
\n\n
\n\n
“Joint controllers” are controllers that jointly determine what data shall be processed for what purpose and by which means.
\n\n
\n\n
The “processor” is the natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller.
\n\n
\n\n
The term “processing” covers any operation or set of operations which is performed on personal data, whether or not by automated means, such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction.
\n\n
\n\n
The term independent controllers is not defined in the GDPR. The term, as used in this article, means controllers that, differently than joint controllers, do not determine the purposes and means jointly for the processing of personal data, but each for itself for own and different purposes from each other.
\n\n
\n\n
In this article, we will explore the essential factors for determining the roles of the parties, and in particular the relationship between customers and service providers, and their consequences.1
\n\n
\n\n
2 The essential factors for determining the role(s) of the parties
\n\n
\n\n
2.1 The essential factors
\n\n
\n\n
The principal factors for determining if a party is a controller, joint controller or a processor are on the one hand the degree of autonomy of each person in determining for what purposes, how and in what manner personal data is processed, and on the other hand the degree of control over the content of personal data. Such determination is always a factual one and must be taken on a case-by-case basis considering each specific processing operation.
\n\n
\n\n
In a first step, however, it must be assessed whether the organization that is holding personal data “processes” such data, and if so, in which ways. While the definition of “processing” is pervasive and covers anything that is done with personal data, there are situations where an organization holding personal data does not qualify as neither a controller nor a processor because it does not process the data in the sense of the law. The ICO provides an example2, where a courier service is contracted by a local hospital to deliver envelopes containing patient’s medical records to other health service institutions. While the courier is in physical possession of the personal data, it does not process the data contained in the letters, since it may not open the mail to access any personal data or other content. Processing personal data implies a degree of access to or the ability to control the use of the data itself. The physical possession of the letters containing personal data is not sufficient. The organization that chooses to use the delivery services to transfer personal data is the controller in this scenario and is responsible for complying with the requirements under the GDPR, and, in particular, to organize such services in such a way that the personal data are adequately protected and, if necessary, an obligation of confidentiality is in place. The critical factor in this case is that the service provider has no plan, intention and interest to process the personal data.
\n\n
\n\n
The mail delivery service will, however, be a controller in its own right in respect to any personal data such as, for example, individual senders’ and recipients’ names and addresses it holds to arrange delivery or tracking.
\n\n
\n\n
2.2 Controller
\n\n
\n\n
An organization is a controller if, through its managers and staff, it decides why and how personal data shall be processed and therefore controls the overall purposes and means of data processing. As a general rule, the legal entity is considered the controller rather than the individual that acts on behalf of the legal entity.3 The capacity for determining the purposes and means of processing may derive from legal circumstances, such as a legal obligation, or from factual circumstances.
\n\n
\n\n
The controller processes (or engages another person to process on its behalf) personal data for its own purposes and typically determines:
\n\n
\n\n
\n
to initiate a processing activity;
\n
what personal data to collect, from whom, from what sources and for what purposes;
\n
how the data shall be processed;
\n
whether to share personal data with third parties and if so with whom;
\n
whether to engage one or several processors for processing the data on its behalf;
\n
whether to modify, anonymize or delete the data; and
\n
for how long the data is stored.
\n
\n\n
\n\n
The controller usually interacts directly with data subjects who expect the organization to be the controller, although direct interaction is not a prerequisite and may not always be the case, such as, for example, in a clinical trial context where the pharmaceutical company, and sponsor of the trial, does generally not even know the identity of the study participants. The controller must retain control over the data but must not necessarily have access to or process the personal data.4
\n\n
\n\n
An organization that processes personal data based on a legal obligation, for example, a tax authority or a social insurance office, or a specialist that processes personal data in accordance with its own professional obligations, such as a legal attorney or an accountant, is generally considered a controller and retains overall responsibility for the specific processing activity. However, in cases where an accountant provides other than accountant services, such as payroll services, it becomes a processor.
\n\n
\n\n
2.3 Joint controller
\n\n
\n\n
Where two or more controllers jointly determine the purposes and means of data processing according to the criteria mentioned above, they are joint controllers. The wish of the parties involved to be jointly responsible is not sufficient to assume joint controllership. The factual circumstances and the behavior in determining the purposes and means are essential. The European Court of Justice provided some clarifications in its decision of June 2018 (Wirtschaftsakademie) where it ruled that the operator of a Facebook fan page is a joint controller with Facebook for the processing of personal data.5 In a further decision of July 2018 (Jehovan), the European Court of Justice further clarified that it is sufficient that a person or entity that exerts influence over the processing of personal data, for its own purposes, and who participates, as a result, in the determination of the purposes and means of that processing, may be regarded as a controller.6 In spite of these decisions, the uncertainty as to which level of co-determination is sufficient to assume joint controllership is still unclear and must be examined on a case-by-case basis.
\n\n
\n\n
2.4 Processor
\n\n
\n\n
A service provider is a processor under the conditions, that the service provider (a) processes personal data (b) on behalf of the controller and (c) under the controller’s instructions. These factors are essential for the service provider to be a processor. Otherwise, and in particular, where the service provider has a certain degree of autonomy in making decisions or in controlling the content of the data, it may be a controller, eventually a joint controller. This does not mean, however, that the processor may not take any decisions. In practice, the controller may delegate some decisions relating to the technical and organizational questions to the processor, such as which hardware or software to use while still determining substantial questions such as the type of personal data to be processed, the retention period or the access rights.7 The question arises as to the degree to which the processor may decide on the means of processing on behalf of the controller without himself becoming a controller. The GDPR states in article 28 para. 10 that a processor becomes a controller as soon as it determines the purposes and means of processing. In practice, this means, that as soon as the processor goes beyond the instructions of the controller, it becomes a controller. This is the case where a service provider uses the data for its own purposes, for example, for conducting analytics and improving its own services. When determining if a service provider is a processor or a controller, respectively a joint controller for a specific processing activity, the following should be taken into consideration:
\n\n
\n\n
\n
the margin of maneuver that is left to the processor. The more detailed instructions the controller gives, the smaller is the margin of maneuver for the service provider;
\n
the level of control the controller wants to exercise;
\n
the expectations of the data subjects of who the controller is. This will depend on the information received from the controller.8
\n
\n\n
\n\n
Typically, a processor
\n\n
\n\n
\n
processes the data based on a mandate by the customer;
\n
has no control over the data and does not decide what data to collect and how to use it;
\n
has no own business interest in processing the data;
\n
is contractually or legally prohibited to use the data for own purposes;
\n
provides technical and operational support to the customer;
\n
has no contractual relationship with the data subjects concerning the processing activity;
\n
is not expected by the data subjects to be the controller.
\n
\n\n
\n\n
Depending on the specific circumstances, the level of instructions and the control by the customer, the service provider may be a processor, joint or independent controller.9
\n\n
\n\n
3 The consequences for each role
\n\n
\n\n
3.1 The organization is a controller
\n\n
\n\n
If an organization qualifies as a controller, it is responsible for complying with the data protection principles, and in particular must have a legal basis for processing the personal data and must comply with the GDPR requirements, such as providing notice to data subjects and granting data subject access rights. The organization has the freedom to engage one or several processors to process personal data on its behalf, subject to specific instructions regarding the purposes and ways of processing while remaining in control of and responsible for the data. In this case, the organization must ensure to have a Data Processing Agreement in place with such processors in line with article 28 GDPR.
\n\n
\n\n
A controller may also share personal data with another controller, without being a joint controller. For example, if an address broker sells personal data to an organization that processes that data for customer relation and marketing purposes, both organizations are controllers. Because they determine their purposes and means of processing separately from each other they are considered independent controllers. The GDPR does not mandate any particular contract or arrangement in this case, unless personal data is shared cross-border from the EEA to a country that does not provide an adequate level of data protection, in which case appropriate safeguards must be put in place, such as EU Standard Contractual Clauses. Nevertheless, because each party is responsible and liable for complying with the GDPR, and, in particular, with the principle of purpose limitation, it is recommended to establish a Data Sharing Agreement outlining the main obligations of the parties.
\n\n
\n\n
3.2 The organization is a joint controller
\n\n
\n\n
If the organization is a joint controller, it must, together with the other joint controllers, enter into an arrangement (such as a Joint Controller Agreement) setting out their respective responsibilities in complying with the GDPR. While the controllers must jointly determine the purposes and means of processing, such determination and the related responsibilities must not be equally shared among the parties but must be clearly outlined in the arrangement, in particular as regards:
\n\n
\n\n
\n
responding to data subject access rights;
\n
carrying out any data protection impact assessments;
\n
notifying data breaches; and
\n
informing individuals about the processing of their data according to article 13 and 14 GDPR.
\n
\n\n
\n\n
Further, the essence of the arrangement must be made available to data subjects who can reach out to each joint controller to exercise their privacy rights.
\n\n
\n\n
3.3 The organization is a processor
\n\n
\n\n
If the service provider is a processor, it must only process personal data on behalf of the controller and only on its instructions. The obligations of the parties must be specified in a Data Processing Agreement based on article 28 GDPR. The processor must, also, comply with all statutory obligations such as maintaining a record of processing activities or appointing a data protection officer, if the requirements under the GDPR are met.
\n\n
\n\n
Keep in mind the following:
\n\n
\n\n
\n
An organization may be a controller for certain processing activities and a processor for other processing activities.
\n
Not all service providers are also processors (if so, they must, however, sign a data processing agreement).
\n
While it is essential that the controller determines the purposes of the processing, in practice, the decision on the technical and organizational means for processing, such as storage, retrieval or erasure, is often delegated to the service provider. Special attention is required in assessing case by case whether the service provider still qualifies as a processor or as a joint controller.
\n
\n\n
\n\n
4 The contractual arrangements
\n\n
\n\n
4.1 Data Processing Agreement
\n\n
\n\n
The data processing agreement between the controller and the processor must include the following minimum requirements according to article 28 GDPR:
\n\n
\n\n
\n
the subject matter and the duration of processing;
\n
the nature and purposes of processing;
\n
the categories of personal data and data subjects;
\n
the obligations and rights of the controller (legal ground for processing and audit rights);
\n
the obligations of the processor, including (a) to process personal data only on documented instructions from the controller, (b) to ensure that only persons that have committed themselves to confidentiality are authorized to process the data; (c) to take all technical and organizational measures (article 32 GDPR) appropriate to the risk; (d) to only engage sub-processors with the prior specific or general written authorization of the controller, to inform the controller about new sub-processors and to contractually impose on such sub-processors the same obligations as imposed on the processor, whereby the processor remains liable to the controller for any failure of the sub-processors; (e) to assist the controller for inquiries and data subjects’ access requests; data breach notification and carrying out of data protection impact assessments; (f) at the end of the provision of services, and at the choice of the controller, to delete or return the personal data to the controller; (g) to make available to the controller all information necessary to demonstrate compliance with the obligations laid down in article 28 GDPR and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller; (h) to inform the controller immediately if, in the processor’s opinion, an instruction infringes the GDPR or other Union or Member State data protection provisions;
\n
a procedure on how to prove compliance with the obligations laid down in article 28 GDPR.
\n
\n\n
\n\n
Further, clarification in respect to the roles of the parties, cross-border data transfers, notification obligations, allocation of costs for assistance and audits or a provision regarding the liability are recommended, although those provisions are not mandatory under article 28 GDPR.
\n\n
\n\n
4.2 Joint Controller Arrangement
\n\n
\n\n
According to article 26 GDPR, the joint controllers must, using an arrangement between them, determine their respective responsibilities for compliance with the obligations under the GDPR. The law does not specify in detail what elements must be covered and therefore the parties have, in contrary to the data processing agreement under article 28 GDPR, a certain level of flexibility. The arrangement, be it an agreement or a policy, should outline the purposes and means of the processing and cover the following questions:
\n\n
\n\n
\n
Who provides notice to the data subjects following article 13 and 14 GDPR?
\n
With whom should the data subjects exercise their privacy rights (contact person)?
\n
Who will handle data subjects’ access requests and other rights?
\n
Who will handle complaints and requests from supervisory authorities?
\n
Who will make available the essence of the joint controller arrangement to data subjects?
\n
Who will appoint a DPO, if required?
\n
Who will determine, document and monitor the technical and organizational security measures?
\n
Who will carry out a data protection impact assessment, if needed?
\n
Who will engage processors, if any?
\n
Who will keep the record of processing activities?
\n
Who will determine if a data breach must be notified to supervisory authorities and data subjects and handle such notifications?
\n
\n\n
\n\n
4.3 Data Sharing Agreement
\n\n
\n\n
The GDPR is silent concerning data sharing agreements between independent controllers. An agreement is currently only mandated where controllers share personal data cross-border to a non-adequate country (EU Standard Contractual Clauses for Controllers10). However, even if there is no cross-border transfer of personal data, it is recommended taking into account the nature of the data sharing and the sensitivity of the personal data to be shared to outline, at a minimum, the principal obligations of the parties, and in particular to only process the data in accordance with the general privacy principles, the purposes of processing, whether the data can be disclosed to third parties, and if so, under what condition, the agreement to provide mutual assistance, if reasonably required, the implementation of security measures as well as indemnification and liability.
\n\n
\n\n
5 The procedure for determining the roles and the appropriate contractual arrangement
\n\n
\n\n
Summarizing, the steps to be taken whenever multiple parties are involved in the processing of personal data, and in particular, where one or several service providers are engaged, are the following:
\n\n
\n\n
\n
Assess what services the service provider shall provide and if such services require the processing of personal data.
\n
Assess the role(s) of the service provider.
\n
Establish the appropriate contractual arrangement(s) covering the responsibilities of the parties.
\n
\n\n
\n\n
6 Conclusion
\n\n
\n\n
With the introduction of the GDPR and the provisions on the relationship between controllers and processors in article 28 and joint controllers in Article 26, the difficulties in determining the roles of the parties remain. The evaluation is particularly difficult in complex situations and business models in which several parties in different jurisdictions are involved in the processing activity, each with different degrees of autonomy, control and responsibility.
\n\n
\n\n
The main factors in determining whether a party is a controller, joint controller or processor are, on the one hand, the degree of autonomy of each party in determining for what purposes, how and in what manner personal data are processed and, on the other hand, the degree of control over the content of personal data. The determination of roles is always factual and must be made on a case-by-case basis, taking into account each processing operation.
\n\n
\n\n
7 References
\n\n
\n\n
\n
Article 29 Data Protection Working Party: Opinion 1/2010 on the concept of “controller” and “processor” (referenced as WP 169)
\n
Information Commissioner’s Office (ICO): Data controllers and data processors: what the difference is and what the governance implications are (referenced as ICO guidance)
\n
Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. (Bitkom): Begleitende Hinweise zu der Anlage Auftragsverarbeitung (referenced as Leitfaden Bitkom)
\n
Judgement of the EU Court of Justice in Wirtschaftsakademie, C-210/16, EU:C:2018:388 (referenced as Decision C-210/16 Wirtschaftsakademie)
\n
Judgement of the EU Court of Justice in Jehovan todistajat C-25/17, EU:C:2018:551 (referenced as Decision C-25/17 Jehovan)
\n
Konferenz der unabhängigen Datenschutzbehörden des Bundes und der Länder (DSK): Kurzpapier Nr. 13: Auftragsverarbeitung, Art. 28 DS-GVO, Stand 17.12.2018 (referenced as DSK Kurzpapier Nr. 13)
\n
Commission Decision of 27 December 2004 amending Decision 2001/497/EC as regards the introduction of an alternative set of standard contractual clauses for the transfer of personal data to
\n
\n\n
\n\n
[1] Detailed analyses on the concept and several examples can be found in (a) the WP169, (b) the ICO guidance, (c) the Leitfaden Bitkom and (d) the DSK Kurzpapier Nr. 13.
\n\n
[2] ICO guidance where additional explanation can be found in notes 33-39
[9] Examples can be found in the WP 169, the ICO guidance and the DSK Kurzpapier article Nr. 13
\n\n
[10] EU Standard Contractual Clauses for Cfor conontrollers
\n","datum":"15.03.2019","teasertext":"
If several persons are involved in the processing of personal data, the question inevitably arises as to their data-protection-related role. This article explores the essential factors for determining the roles of the parties, and in particular the relationship between customers and service providers, and their consequences.
\n","preview":"","datei":[],"linkextern":""},{"id":159,"title":"The new EU General Data Protection Regulation (GDPR) is published","slug":"eu-datenschutz-grundverordnung-veroeffentlicht","link":"/en/news-knowledge/eu-datenschutz-grundverordnung-veroeffentlicht","titel":"The new EU General Data Protection Regulation (GDPR) is published","text":"
On May 4, 2016, the EU General Data Protection Regulation (GDPR) was published in the Official Journal of the European Union. The GDPR will replace the current EU Data Protection Directive and will be directly applicable in all EU Member States. Companies will have time until May 25, 2018 to implement all required steps necessary to comply with the new regulation.
\n\n
\n\n
The GDPR contains strengthened and new rights for data subjects, such as a right to be forgotten or a right to data portability, and new obligations for data controllers and data processors.
\n\n
\n\n
Here are some of the key changes:
\n\n
\n\n
The territorial scope has been expanded to include data controllers and (new) data processors that are established in the EU. Importantly, also companies that are NOT established in the EU, but offer goods or services to, or monitor the (online) behavior of data subjects in the EU, fall under the scope of the GDPR.
\n\n
\n\n
Controllers must demonstrate their accountability to comply with the GDPR. This includes the obligation to:
\n\n
\n\n
\n
Maintain a documentation of processing activities
\n
Establish policies and guidelines
\n
Appoint a data protection officer (DPO) in certain cases
\n
Implement security measures
\n
Implement data protection by design and by default and
\n
Conduct privacy impact assessments
\n
\n\n
\n\n
Accountability may be demonstrated by various means, such as with Binding Corporate Rules (BCR), certifications or codes of conduct.
\n\n
\n\n
The requirements for obtaining consent have been strengthened. Consent must be freely given, specific, informed, unambiguous and explicit for sensitive personal information and must be revocable at any time. It must be clearly distinguishable from other matters when requested in the context of a written document and it must be provided in an intelligible and easily accessible form, using clear and plain language. Also, consent will not be valid if there is a clear imbalance between the data subject and the controller, which may be the case for example in the employment context. Importantly, a controller may not make a service conditional upon consent, unless the processing of personal data is necessary for that specific service.
\n\n
\n\n
Data processors have now direct statutory obligations under the GDPR. This includes the obligation to:
\n\n
\n\n
\n
Maintain records of processing activities
\n
Implement appropriate data security measures
\n
Cooperate with supervisory authorities
\n
Assist controllers to comply with the GDPR
\n
Comply with cross-border data transfer restrictions
\n
Notify controllers in case of a data breach
\n
Become a joint controller, if data is processed beyond instructions of the controller
\n
Enter into a written data processing agreement with the controller
\n
Appoint a DPO in certain cases
\n
\n\n
\n\n
Data controllers must notify supervisory authorities about data breaches without undue delay and, where feasible, within 72 hours after having become aware of the breach. Where the breach is likely to result in a high risk to individuals’ rights and freedoms, such individuals must be notified about the breach without undue delay.
\n\n
\n\n
Violations of the GDPR may result in fines up to EUR 10 m or 2% of the annual worldwide turnover for example for failures to comply with the general obligations, to appoint a DPO or to implement security measures and privacy impact assessments. More severe failures, for example to comply with the basic privacy principles for data processing, such as consent requirements, data subject rights or data transfer restrictions, may result in fines up to EUR 20 m or 4% of the annual worldwide turnover.
\n\n
\n\n
What should companies do now?
\n\n
\n\n
Companies subject to the GDPR should start now to implement appropriate measures to comply with the GDPR in two years’ time by taking the following steps:
\n\n
\n\n
\n
Get familiar with the GDPR and the obligations applicable to your organization
\n
Conduct an assessment of the current privacy management practices within your organization and of the gaps in respect to the new requirements under the GDPR
\n
Identify measures that must be taken to comply with the GDPR and define an action and time plan for the remediation
\n
Watch out for guidelines and opinions that will be published by national Data Protection Authorities and the Article 29 Working Party in the coming months
\n
\n\n
\n\n
How can we help you?
\n\n
\n\n
We are happy to assist organizations in getting a better understanding of the requirements under the GDPR applicable to them; conducting assessments and gap analyses, providing guidance on remediation and developing necessary policies, guidelines and processes to ensure compliance with the GDPR and minimizing risks.
\n\n
\n\n
You can find the final text in various languages here.
\n\n
\n","datum":"04.05.2016","teasertext":"
On May 4, 2016, the EU General Data Protection Regulation (GDPR) was published in the Official Journal of the European Union. The GDPR will replace the current EU Data Protection Directive and will be directly applicable in all EU Member States. Companies will have time until May 25, 2018 to implement all required steps necessary to comply with the new regulation.
\n","preview":"","datei":[],"linkextern":""}],"weiterlesen":"Continue reading","mehrlesen":"Read more","beitragAnsehen":"View Article"}}]}},"page":{"meta":{"locale":"en","title":"News & Knowledge – Privacy Legal | Daniela Fabian","keywords":"","description":"Information on recent developments in privacy and data protection and publications on various privacy-related topics.","status":200,"translatedPaths":{"de":"/de/news","en":"/en/news-knowledge"},"slug":"news-knowledge","uri":"/en/news-knowledge","url":"https://privacylegal.ch/en/news-knowledge","hasSubnavigation":false},"content":[{"component":"HeaderSubpage","data":{"id":94,"title":"News Header","slug":"news-header","link":"/en/dev/part-data/blocks/news-header","hintergrundbild":{"id":17,"alt":false,"caption":false,"small":"https://privacylegal.ch/gallery/preview/17/fpl-bilder-serie-01-1811012.jpg","normal":"https://privacylegal.ch/gallery/normal/17/fpl-bilder-serie-01-1811012.jpg","large":"https://privacylegal.ch/gallery/full/17/fpl-bilder-serie-01-1811012@2x.jpg"},"titel":"Recent Developments and Knowledge","untertitel":"
Countries around the world continue to adopt new or stricter regulations in the areas of data protection, information security, artificial intelligence, etc. to address the rapid development of new technologies and the growing requirements and concerns of a digitalized society.
\n"}},{"component":"News","data":{"id":96,"title":"News & Knowledge","slug":"news-knowledge","link":"/en/dev/part-data/blocks/news-knowledge","news":[{"id":178,"title":"Onepager «Data Protection for Law Firms» (in German)","slug":"onepager-datenschutz-x-advokatur","link":"/en/news-knowledge/onepager-datenschutz-x-advokatur","titel":"Onepager «Data Protection for Law Firms» (in German)","text":"
Within the scope of the expert group \"ditgital\" of the Basel Bar Association, Daniela Fábián, Caroline Hasler and Apollo Dauag have established a onepager in view of the entry into force of the new data protection law in Switzerland (in particular the Federal Act on Data Protection and the Data Protection Ordinance), with the aim of giving an overview of the relevant points for lawyers.
\n\n
\n\n
The onepager is not meant to be absolute or exhaustive, but rather as a useful basic tool. Please note that the onepager is only available in German.
Within the scope of the expert group \"ditgital\" of the Basel Bar Association, Daniela Fábián, Caroline Hasler and Apollo Dauag have established a onepager in view of the entry into force of the new data protection law in Switzerland (in particular the Federal Act on Data Protection and the Data Protection Ordinance), with the aim of giving an overview of the relevant points for lawyers.
\n\n
\n","preview":"","datei":[],"linkextern":""},{"id":175,"title":"Data Breach Prevention and Response Strategy","slug":"strategie-zum-umgang-und-zur-vermeidung-von-datenschutzverletzungem","link":"/en/news-knowledge/strategie-zum-umgang-und-zur-vermeidung-von-datenschutzverletzungem","titel":"Data Breach Prevention and Response Strategy","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
1 Introduction
\n\n
\n\n
Laws around the world impose strict data security obligations on organisations that process personal data, and in some cases require them to report data breaches to data protection authorities and individuals affected by the data breach. In addition to significant sanctions for failing to take appropriate technical and organisational measures (TOMs) to protect data, and potentially for failing to report a data breach as required by law, organisations may suffer, among other things: loss of stakeholder trust; reputational damage; and disruption of business activities as a result of a data breach, leading to economic losses. In addition, there are significant costs associated with managing a data breach and remediating the damage caused by the breach.
\n\n
\n\n
Investing in data security to prevent data breaches, such as those caused by cyberattacks or employee errors, and being prepared to respond in the event of a data breach is therefore worthwhile not only to comply with the legal obligations, but also to avoid negative consequences for the organisation and its stakeholders.
\n\n
\n\n
This chapter elaborates on what constitutes a personal data breach and what a data breach prevention and response strategy might look like. It is limited to dealing with data breaches involving personal data. It takes the requirements of the General Data Protection Regulation (GDPR) as a starting point, but without limiting itself to the GDPR. In particular, it considers the incident notification requirements under the new EU Directive on measures for a high common level of cybersecurity across the Union (NIS2), effective as of 16 January 2023, which significantly expands the categories of entities within the scope, including entities such as manufacturers of chemicals and medical devices, food processors, social network providers, and postal and courier services. With such an extension, a wide range of entities that did not fall under the former NIS Directive, will be subject to additional incident notifications. The NIS2 Directive must be transposed by the EU Member States into national law by 18 October 2024.
\n\n
\n\n
2 What is a Personal Data Breach and its Potential Consequences?
\n\n
\n\n
A personal data breach (data breach) occurs when personal data held by an organisation is lost or subjected to unauthorised access, modification, disclosure, or other misuse or interference. The GDPR defines the term “personal data breach” as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored, or otherwise processed. Privacy laws in other jurisdictions contain similar, though not identical, definitions. An “incident,” on the other hand, is defined by NIS2 as an event compromising the availability, authenticity, integrity, or confidentiality of stored, transmitted, or processed data, or of the services offered by, or accessible via, network or information systems. We refer to a potential data breach when personal data is affected.
\n\n
\n\n
The EDPB’s Guidelines 9/2022 on Data Breach Notification under the GDPR, adopted on 28 March 2023 (previously the Working Party Opinion 03/2014 (WP29) on Data Breach Notification), divide data breaches into three security principles:
\n\n
\n\n
■ Confidentiality breach – where there is an unauthorised or accidental disclosure of, or access to, personal data.
\n\n
■ Integrity breach – where there is an unauthorised or accidental alteration of personal data.
\n\n
■ Availability breach – where there is an accidental or unauthorised loss of access to, or destruction of, personal data.
\n\n
\n\n
Examples of data breaches include: the loss or theft of a data carrier (e.g., notebook, phone, USB stick, paper files) containing unencrypted personal data of customers or employees (breach in confidentiality, and potentially availability if there is no backup for the stolen device); the successful penetration of an organisation’s computer systems containing personal data for the purpose of copying, exfiltrating, and misusing personal data for malicious purposes (breach in confidentiality and possibly integrity); a ransomware attack in which the attacker encrypts data with a malicious code and then demands a ransom from the attacked organisation in exchange for the decryption key (availability breach, and possibly confidentiality breach); the unauthorised downloading of personal data by a terminated employee for further private use (confidentiality breach); and the inadvertent disclosure of personal data by an employee to unauthorised persons inside or outside the organisation, e.g., by sending it to an incorrect address or by sending a file that inadvertently contains personal data not intended for the recipients (confidentiality breach).
\n\n
\n\n
A data breach may have various negative effects on individuals and result in physical, material and immaterial damage. It may, for example, cause the affected individual to lose control over their personal data, to be restricted in the exercise of their personal rights, to suffer financial loss or personal disadvantage, emotional distress, embarrassment or humiliation, or to suffer damage to their reputation. Possible consequences may also include identity theft or fraud, loss of employment or business opportunities, unwanted marketing or spam, reversal of pseudonymisation, or other significant economic or social disadvantages.
\n\n
\n\n
Organisations can also suffer harm as a result of a data breach. Responding to a data breach and potential subsequent complaints and implementing remedial actions may have financial, legal and resource implications. Data breaches can further result in reputational damage and loss of stakeholder trust.
\n\n
\n\n
According to the Ponemon Institute’s 2022 Cost of a Data Breach Report, the average cost of a data breach was $4.35 million in 2022. The average cost has increased by 12.7 % from $3.86 million in 2020, with costs being significantly lower for organisations with more mature security levels. The average total cost per record containing personal data was $164. The longer it took to detect the breach, the more expensive it was, with most of the costs related to detection and escalation, followed by cost of lost business (including business interruption and lost revenue due to system downtime, cost of lost customers and acquiring new customers, loss of reputation, and diminished goodwill). The remaining cost drivers were post-breach response, and notification. The costliest initial attack vectors were phishing followed by compromised business emails, vulnerability in third-party software, and stolen or compromised credentials.
\n\n
\n\n
3 Data Breach Notification Requirements
\n\n
\n\n
Many countries around the world have introduced data breach notification regulations. The first laws were enacted in the U.S. at the state level starting in 2002 (California). Other countries have followed, such as the EU Member States and the United Kingdom with the GDPR and the UK Data Protection Regulation (UK GDPR), respectively, as well as other countries around the world, such as Australia, Brazil, China, Colombia, Egypt, Ghana, Israel, Kenya, Mexico, New Zealand, the Philippines, Singapore, South Korea, Switzerland, Taiwan, Thailand and Uruguay.
\n\n
\n\n
Independent of data breach notification requirements, most countries in the world have introduced data security obligations that must be implemented by the affected entities, including data controllers and data processors. Such new legislation includes the NIS2 Directive and similar national laws, such as the UK’s Network and Information Systems Regulations 2018 (NIS Regulations) and Switzerland’s Information Security Act, as well as new EU laws related to the NIS2 Directive, such as the Critical Entities Resilience Directive (CER Directive), the EU Digital Operational Resilience Act (DORA) and the Cyber Resilience Act as part of the EU’s new digital legislative package, addressing the cyber resilience of entities across the EU.
\n\n
\n\n
NIS2 significantly expands the categories of entities falling under its scope and applies to companies active in sectors including energy, transport, banking, financial markets, health, drinking water, waste water, digital infrastructure, ICT service management, public administration and space (essential sectors), as well as postal and courier services, waste management, manufacture, production and distribution of chemicals, production, processing and distribution of food, manufacturing, digital providers and research (important sectors).
\n\n
\n\n
According to NIS2 rules, essential and important entities are required to notify their computer security incident response team (CSIRT) or, where applicable, the competent EU Member State authority of any significant incident in a multiple-stage reporting system:
\n\n
\n\n
1. an early warning without undue delay and in any event within 24 hours of becoming aware of the significant incident, which, where applicable, indicates whether the significant incident is suspected of being caused by unlawful or malicious acts or could have a cross-border impact;
\n\n
\n\n
2. an incident notification without undue delay and in any event within 72 hours of becoming aware of the significant incident, which, where applicable, should update the information provided with the early warning and indicate an initial assessment of the significant incident, including its severity and impact, as well as, where available, the indicators of compromise; and
\n\n
\n\n
3. a final report not later than one month after the submission of the incident notification, including a detailed description of the incident, specifying its severity and impact, the type of threat or root cause that is likely to have triggered the incident, applied and ongoing mitigation measures, and, where applicable, the cross-border impact of the incident.
\n\n
\n\n
The incident is significant if: (a) it has caused, or is capable of causing, severe operational disruption of the services or financial loss for the entity concerned; or (b) it has affected, or is capable of affecting, other natural or legal persons by causing considerable material or non-material damage.
\n\n
\n\n
NIS2 sets out cooperation rules for the NIS2 competent authorities and the data protection authorities, and states that in cases where an incident to be reported under NIS2 also qualifies as a notifiable data breach under the GDPR, the NIS2 competent authorities should work in close cooperation with data protection authorities under the GDPR when addressing incidents resulting in data breaches. The NIS2 competent authorities must, without undue delay, inform the data protection authorities. However, where the data protection authority competent under the GDPR is established in another Member State than the NIS2 competent authority, the NIS2 competent authority must inform the data protection authority established in its own Member State of the data breach.
\n\n
\n\n
Depending on how the NIS2 Directive is implemented in the EU Member States, it may be required for organisations covered by the NIS2 Directive to report an incident under NIS2 that also constitutes a data breach under the GDPR to the NIS2 competent authority and the data protection authorities in the EU Member States concerned (or the lead authority, if applicable).
\n\n
\n\n
The notification obligation will continue to be a challenge for companies established outside the EU. While the Art. 29 Working Party recommended in its guidelines on notification of data breaches under the GDPR, last revised 6 February 2018, that notification should be made to the data protection authority of the Member State where the controller’s representative in the EU is established, the EDPB now overturns this position in its Guidelines 9/2022 on personal data breach notification under GDPR, adopted on 28 March 2023, by clarifying that the mere presence of a representative in a Member State does not trigger the one-stop-shop system. Therefore, controllers established outside the EU without a main establishment in the EU must notify cross-border data breaches to any data protection authority in the Member States where the data subjects are located.
\n\n
\n\n
4 Data Breach Prevention and Response Strategy
\n\n
\n\n
Although security requirements and the conditions and modalities of notification obligations may vary from country to country, any organisation that processes personal data and is subject to security and notification obligations should define and implement a data security and breach management strategy to ensure adequate data security and risk mitigation in the event of an incident and be prepared to deal with any data breaches.
\n\n
\n\n
The data breach response strategy does not need to be stand-alone but can and should be aligned with other internal data-management and security strategies, e.g., information security, where possible. It should cover three key factors: prevention; response; and improvement.
\n\n
\n\n\n\n
\n\n
4.1 Prevention – Implement appropriate TOMs
\n\n
\n\n
Even with the best possible security, data breaches cannot be completely avoided. However, data breaches are often the result of a vulnerable and outdated security regime or system weaknesses. Prevention through the adoption of appropriate security measures is therefore key to preventing vulnerabilities in systems or insufficient security that can potentially lead to a data breach.
\n\n
\n\n
Data and risk mapping: Only if organisations know what types of data breaches could occur and understand the characteristics of these breaches, can they take the necessary TOMs to reduce the risk of a successful attack or breach.
\n\n
\n\n
The basic prerequisite is first that companies know what types of data and personal data they process, who the data subjects are and their locations, where the data is stored and who should have access to it. This knowledge requires the mapping of all data systems, products and services that process personal data and their classification. Organisations should then assess the risk level to their organisation and to individuals in the case of a data breach, as well as identifying the possible types of attacks and based on that understanding and the level of risk, take the appropriate TOMs to mitigate the consequences in the case of a data breach.
\n\n
\n\n
Implementation of TOMs: Based on the risk level, such TOMs may include a state-of-the-art encryption of the data at rest and a separate back-up of the data to help mitigate the consequences of a successful ransomware attack, or the loss or theft of a device with personal data. In addition to a state-of-the-art encryption, measures such as key management, regular updates of systems, use of strong authentication methods like two-factor authentication, firewalls, etc. may help to mitigate the consequences of data exfiltration. Regular awareness campaigns and training to staff on security aspects, instructions on how to use company devices and information as well as the implementation of technical measures and controls may help to prevent human errors.
\n\n
\n\n
Applicable laws and competent authorities: Organisations should assess which data protection and other laws apply to them in case of an incident and data breach. This should include assessing whether an entity is covered by NIS2. Based on this knowledge, organisations should determine which authorities to notify in case of a NIS2 incident and data breach. This insight will help save valuable time in the event of an incident.
\n\n
\n\n
External resources and insurance coverage: Besides the implementation of robust TOMs, organisations should evaluate in advance what type of external expertise is required in the case of a data breach and ensure that such expertise is available on short notice, which may require the negotiation of frame contracts in advance. Additionally, organisations may consider holding an insurance policy for data breaches.
\n\n
\n\n
Data breach response plan: Finally, organisations should deploy a data breach response plan that sets out procedures, modalities, and responsibilities in the event the organisation experiences a data breach (or a suspected data breach, i.e., a security incident) to respond to a data breach in a timely and efficient manner.
\n\n
\n\n
4.2 Response – Implement a data breach response plan
\n\n
\n\n
4.2.1. Why a data breach response plan?
\n\n
\n\n
Due to the usually very short timelines for reporting a data breach to the data protection authorities and individuals (at least in some countries, including the EU), it is critical that each organisation handling personal data put in place a documented data breach response plan. Implementing such a plan can help organisations in: (a) mitigating the impact on the organisation and affected individuals, and the costs resulting from the data breach; (b) meeting their data security obligations; (c) protecting important business assets, including personal data of their employees and clients and the company’s reputation; (d) dealing with negative media or stakeholder attention; and (e) instilling public confidence and trust in the organisation’s capacity to protect personal data entrusted to the company by properly responding to a data breach.
\n\n
\n\n
The data breach response plan should be aligned with other plans as appropriate, such as existing security incident response, disaster recovery, business continuity, or contingency plans. This approach can ensure effective management with clear responsibilities, avoid duplication, and leverage synergies.
\n\n
\n\n
4.2.2. Content of a data breach response plan
\n\n
\n\n
A data breach response plan should establish the rules and processes on how to handle a data breach in compliance with internal standards and legal and regulatory requirements. It should outline what a data breach is, possibly providing some concrete examples tailored to the specific organisation, allocate the roles and responsibilities for detecting, responding, and documenting a data breach, describe the process for handling a data breach, from detection to notification and risk mitigation, and specify the obligations towards third parties processing the data on their behalf.
\n\n
\n\n
4.2.3. Establishment of an incident response team
\n\n
\n\n
While in small organisations the managing director or owner is often the person who deals with a data breach, usually with external assistance, establishing an incident response team has proven effective in mid-sized and larger organisations. The purpose of such a team is to ensure that in the event of a data breach, the relevant functions are immediately engaged, and data breaches can be promptly addressed, the risks assessed, and any required notifications made in a timely manner.
\n\n
\n\n
\n\n
The composition of the team will depend on the organisation and the nature of the business, but will typically require different skill sets, which can be ensured by involving internal functions and external legal, data forensics, and media management experts. Organisations should assess what type of external expertise will be needed in the event of a data breach in advance, and ensure that this expertise is available on short notice. The organisation should maintain and regularly update a current list of team members, including their roles, responsibilities, and contact details, as well as the contact information of their delegates. Team members should receive regular training including on compliance with the applicable laws and notification requirements and participate in mock exercises. The response team should consist of a core team that includes, at a minimum, the data protection officer and the information security officer, and should be extended to include other functions such as human resources, research and development, or communications, as well as outside legal counsel and forensic analysts, depending on the severity and nature of the incident.
\n\n
\n\n
The incident response team should be responsible for managing the overall data breach, investigating, and reviewing the circumstances of the data breach and the facts of the case, engaging relevant functions and external experts, assessing the level of risk, determining remediation actions, determining the need for internal escalation, and notifying data protection authorities and individuals. The data breach response plan should identify the specific responsibilities of each member of the response team.
\n\n
\n\n
Furthermore, corporate management bodies should oversee, approve and be trained on the cybersecurity measures taken by the organisation, according to the new requirements of the NIS2 Directive.
\n\n
\n\n
4.2.4. Process for responding to a data breach
\n\n
\n\n
The process for responding to a data breach typically includes different steps, starting from the detection of the data breach and reporting to the immediate containment, investigation of the data breach, risk evaluation, internal escalation, notification, and documentation.
\n\n
\n\n\n\n
\n\n
Detection and reporting: Each employee should understand how to recognise a potential data breach and know how to report such a data breach or suspected data breach (security incident) to the incident response team, who will immediately perform a preliminary evaluation and determine whether the incident qualifies as a data breach.
\n\n
\n\n
Containment: Once the source of the data breach has been identified, the data breach should be contained immediately to prevent further exposure of personal data, for example, and depending on the concrete impact, by remediating identified vulnerabilities in systems, recovering records, shutting down the compromised system, restricting access to data, recalling sent emails containing personal data that were inadvertently attached to the email or sent to the wrong recipients, or deleting them from the accounts of the unintended recipients.
\n\n
\n\n
Investigation: The incident response team should investigate and document the facts and circumstances of the data breach, including: the causes of the data breach such as any vulnerabilities in the computer systems; the nature of the data breach (breach of confidentiality, availability, or integrity); the nature, scope, and sensitivity of the personal data involved, as well as the origin of the data; the type, number, and location of data subjects; applicable data protection laws; and notification requirements.
\n\n
\n\n
Risk evaluation: Based on the outcome of the investigation and taking into account the type of personal data compromised, the extent of the data breach, and the type and number of individuals affected by the data breach, the incident response team must assess the level of risk of the data breach to the rights and freedoms of data subjects and the organisation. To assess the level of risk, they must determine the impact that the data breach could have on the rights and freedoms of individuals and the likelihood that this impact will actually occur. The greater the impact and the greater the likelihood, the higher the risk. Essential elements for determining the impact on individuals are the ease of their identification (how easily can an individual be identified from the compromised data?) and the severity (how much harm can be caused by the data breach?). Key elements in determining the likelihood of the identified impact actually occurring are the potential vulnerabilities due to the lack of appropriate TOMs and the ability to exploit those vulnerabilities or the intent of the individuals accessing or possessing the data (was the data exfiltrated by a hacker with malicious intent or sent by an employee to the wrong recipient in the same organisation by mistake?).
\n\n
\n\n
Escalation: The data breach response plan should define the internal escalation process, which should depend on the severity and extent of the breach, the level of risk identified, and the requirement for notification.
\n\n
\n\n
Notification: The incident response team determines, based on all the facts and the risk evaluation, whether the data breach must be notified to local data protection authorities and affected individuals, and if so, when, where, and how. At the same time, the incident response team should address notification of other authorities, such as those responsible for NIS2 incidents, if the organisation is subject to NIS2 and it is a significant incident. The data breach response plan should identify which function is responsible for notifying the authorities and individuals. In general, the notification of a data breach is assigned to the data protection officer. Notification of an incident subject to other laws, such as NIS2, may be assigned to other functions. It is recommended that notifications be coordinated. It is also advantageous if scenarios requiring notification have already been worked through and documented.
\n\n
\n\n
Documentation: Any data breach, whether notified to data protection authorities and/or individuals or not, should be documented, including the facts and circumstances of the breach, its effects, and the corrective actions taken and planned to prevent future similar data breaches, the risk evaluation, and the appropriate justification for the decisions made with respect to the notification to data protection authorities and individuals.
\n\n
\n\n
4.2.5. Considerations in implementing a data breach response plan globally
\n\n
\n\n
Given the large number of countries with data breach notification requirements, globally operating companies are faced with the challenge of finding solutions that are as comprehensive and uniform as possible in order to, on the one hand, deal with data breaches uniformly and efficiently across the organisation and, on the other hand, take into account the specifics of the individual countries.
\n\n
\n\n
When implementing a data breach response plan globally, companies must take into account locally applicable data privacy and security laws, as well as notification requirements and modalities, languages, and cross-border data transfer restrictions, and align the data breach response plan accordingly. Companies should also decide what the internal reporting channel for discovered data breaches should be. Depending on their organisational set-up, they could establish one global reporting channel or separate regional or local reporting channels. Also, organisations must determine where data breaches should be documented (in a centralised system or locally), and whether a global incident response team should be deployed around the world, or regional/local response teams be established.
\n\n
\n\n
4.3 Improvement – Address security gaps to prevent future (similar) data breaches – regularly re-evaluate the data breach response plan to increase effectiveness
\n\n
\n\n
The third phase of the data breach response strategy consists of improvements in two respects: addressing identified vulnerabilities to prevent future similar data breaches; and increasing the effectiveness of the data breach response plan.
\n\n
\n\n
Address any identified security vulnerabilities to prevent future similar data breaches. Once the notification and documentation process is complete, the incident response team should determine and implement appropriate measures to prevent future similar data breaches. Depending on the concrete type of data breach and the root cause, such measures may include, for example, conducting regular security audits and reviewing and updating policies and procedures in light of lessons learned, reviewing and amending contracts with third parties to ensure the appropriate handling of data breaches. Other measures may include, for example, restricting the downloading of personal data to mobile devices without adequate security protection, such as state-of-the-art encryption or the establishment of separate backups of specific data sets, and regular training for the business units concerned.
\n\n
\n\n
Periodically re-evaluate the data breach response plan to increase its effectiveness, taking into account changes in applicable data protection laws, best practices and internal business requirements.
\n\n
\n\n
5 Conclusion
\n\n
\n\n
Data security is one of the essential obligations of any organisation that processes personal data. A breach of the confidentiality, integrity or availability of data can have negative consequences not only for the individuals concerned, but also for the responsible organisation. A data breach can result in notification obligations, significant costs to contain the data breach and repair the damage caused by the breach, as well as loss of stakeholder trust, reputational damage, and business disruption. Investing in data security to prevent data breaches, such as those caused by cyberattacks or human error, and being prepared to respond in the event of a data breach, is therefore essential for any organisation to meet its legal obligations and avoid negative consequences for itself and the individuals affected.
\n\n
\n","datum":"21.07.2023","teasertext":"
Laws around the world impose strict data security obligations on organisations that process personal data, and in some cases require them to report data breaches to data protection authorities and individuals affected by the data breach. This article elaborates on what constitutes a personal data breach and what a data breach prevention and response strategy might look like. In particular, it considers the incident notification requirements under the new EU Directive on measures for a high common level of cybersecurity across the Union (NIS2), effective as of 16 January 2023, which significantly expands the categories of entities within the scope. With such an extension, a wide range of entities that did not fall under the former NIS Directive, will be subject to additional incident notifications.
\n","preview":"","datei":[],"linkextern":""},{"id":173,"title":"Get ready for the new Swiss Data Protection Act","slug":"bereiten-sie-sich-auf-das-neue-schweizer-datenschutzgesetz-vor","link":"/en/news-knowledge/bereiten-sie-sich-auf-das-neue-schweizer-datenschutzgesetz-vor","titel":"Get ready for the new Swiss Data Protection Act","text":"
This webinar on Mondaq, that builds on the previous webinar \"The new Swiss Data Protection Act - What you need to know\", specifically targets the preparatory measures for the implementation of the new law, which will come into force on September 1, 2023.
\n\n
\n\n
Specific topics such as the scope of application of the Federal Data Protection Act (also for companies abroad), the requirements for appointing a representative in Switzerland, the specific requirements for the duty to inform data subjects, the record of processing activities, data security requirements, data breach handling and notification, data protection impact assessment, outsourcing and international data transfer are highlighted and provided with practical implementation tips.
\n\n
\n\n
To download the webinar in PDF format, please click here.
\n\n
\n\n
To view the webinar directly on the Mondaq website, please click here.
\n","datum":"08.06.2023","teasertext":"
This webinar on Mondaq, that builds on the previous webinar \"The new Swiss Data Protection Act - What you need to know\", specifically targets the preparatory measures for the implementation of the new law, which will come into force on September 1, 2023.
\n","preview":"","datei":[],"linkextern":""},{"id":172,"title":"New Swiss Data Protection Act - the most important changes for companies","slug":"neues-schweizer-datenschutzgesetz-die-wichtigsten-neuerungen-fuer-unternehmen","link":"/en/news-knowledge/neues-schweizer-datenschutzgesetz-die-wichtigsten-neuerungen-fuer-unternehmen","titel":"New Swiss Data Protection Act - the most important changes for companies","text":"
To download the article in PDF format, please click here.
The Swiss Parliament passed the revised Data Protection Act (nFADP) on 25 September 2020.2 The nFADP as well as the new Data Protection Ordinance (DPO) and the new Ordinance on Data Protection Certification (DPCO) will enter into force on 1 September 2023.
\n\n
\n\n
The aim of the revision was, on the one hand, to strengthen data protection by improving the transparency of data processing and the control options of data subjects over their data and, at the same time, to increase the sense of responsibility of those responsible.3 Another important goal was to maintain Switzerland's competitiveness and to enable Switzerland to ratify the Council of Europe's revised data protection convention ETS 108, to align with the EU's General Data Protection Regulation (GDPR) and thus to continue to be recognized as a third country with an adequate level of data protection.
\n\n
\n\n
At a Glance
\n\n
\n\n
\n
The basic concept of “permission of data processing subject to prohibition” (i.e. prohibition if the data processing leads to an “unlawful violation of the personality of a person”) remains unchanged. Consent to the processing of personal data is still generally not required, even for profiling and the processing of sensitive personal data. The principles of data processing also remain largely unchanged.
\n
\n\n
\n\n
\n
Legal entities are no longer protected; only natural persons are protected under the nFADP.
\n
\n\n
\n\n
\n
The scope of the nFADP covers actions that have an effect in Switzerland, even if they are initiated abroad.
\n
\n\n
\n\n
\n
The definitions of “controller of the data file”, “personality profile” and “data file” have been deleted; the definitions of “profiling”, “high-risk profiling” and “data security breach” have been introduced. Genetic and biometric data as well as data on ethnic origin, are considered to be sensitive personal data under the nFADP.
\n
\n\n
\n\n
\n
The concepts of “privacy by design” and “privacy by default” are now enshrined in the law, as is already the case in the EU General Data Protection Regulation (GDPR).
\n
\n\n
\n\n
\n
Data security is the responsibility of the controller as well as the processor. A risk-based approach is introduced.
\n
\n\n
\n\n
\n
Data processing by processors remains largely unchanged. Under the nFADP, the processor may only assign the processing to a sub-processor with prior authorisation by the controller.
\n
\n\n
\n\n
\n
The appointment of a data protection advisor remains voluntary. It can be an advantage when it comes to performing a data protection impact assessment.
\n
\n\n
\n\n
\n
Under the nFADP, both the controller and the processor must keep an inventory of their processing activities. This inventory does not have to be declared to the Federal Data Protection and Information Commissioner (FDPIC) (up to now, the controller generally needed to declare data files to the FDPIC).
\n
\n\n
\n\n
\n
Companies based outside Switzerland who process personal data of persons in Switzerland will have to designate a representative in Switzerland.
\n
\n\n
\n\n
\n
The requirements for cross-border disclosure of personal data remain largely unchanged. Under the nFADP, the Federal Council bindingly determines whether the legislation of a state or an international body guarantees an adequate level of protection.
\n
\n\n
\n\n
\n
The duty of information has been extended to the collection of all kinds of personal data (until now it was only applicable to the collection of sensitive personal data and personality profiles) and also includes automated individual decision-making.
\n
\n\n
\n\n
\n
Under the nFADP, the controller must carry out a data protection impact assessment if the intended data processing may lead to a high risk for the data subject.
\n
\n\n
\n\n
\n
In the future, the controller must notify the FDPIC of data security breaches.
\n
\n\n
\n\n
\n
Under the nFADP, data subjects have the right to data portability.
\n
\n\n
\n\n
\n
The powers of the FDPIC are extended. In the future, the FDPIC can order a number of administrative measures.
\n
\n\n
\n\n
\n
The criminal provisions have been significantly tightened, with fines of up to 250 000 Swiss francs for private persons (i.e. not companies!), but only for violations in certain areas, in particular for the breach of obligations to provide access and information and to cooperate, for the violation of duties of diligence with respect to the requirements for cross-border disclosure of personal data, the appointment of a processor and for failure to comply with the minimum data security requirements. Fines are only applicable to violations that result from a wilful act and are in most cases, only imposed upon the filing of a complaint.
The nFADP aims to protect personal privacy and the fundamental rights of natural persons whose personal data is processed. Under the current law, legal entities are also protected. By cancelling the protection of legal entities, the nFADP aligns with the GDPR, that also protects only natural persons.
\n\n
\n\n
The nFADP also regulates the territorial scope. According to art. 3, the law applies to actions that have an effect in Switzerland, even if they are initiated abroad.
Various definitions are now aligned with the GDPR.
\n\n
\n\n
The term \"personal data\" is limited to all information that relates to an identified or identifiable natural person. In future, only natural persons about whom personal data is processed will be considered «data subjects”.
\n\n
\n\n
Concerning the identifiability, the “relative approach” is maintained. According to the Federal Council Dispatch on the Federal Act on the complete revision of the Federal Act on Data Protection and the modification of other federal enactments6, the mere theoretical possibility to identify a person is, as under current law, not sufficient to presume that a person is identifiable. The Federal Council already stipulated in its Dispatch to the FADP of 19887 that no identifiability is given if “the effort necessary to identify a data subject is so great that, according to general life experience, it cannot be expected that any interested person should undertake such effort”. “It must rather be considered what means can be reasonably employed to identify a person and be determined whether the employment of such means is reasonable under the given circumstances, for instance in terms of time and cost. In doing so, the technologies available at the time of processing and their further development must be taken into account. The law does not apply to anonymised data, if a re-identification by third parties is impossible (the data has been completely and irreversibly anonymised) or if a re-identification would only be possible with a great effort that no interested person would undertake. The same applies to pseudonymised data».8
\n\n
\n\n
The definition of “sensitive personal data” has been extended to include “data on ethnic origin”, “genetic data” and “biometric data which uniquely identifies a natural person”. While it is made clear that biometric data must uniquely identify a natural person, the same addition has been deleted for genetic data in the procedure of the resolution of differences.
\n\n
\n\n
The definitions of “controller of the data file”, “personality profile” and “data file” have been deleted. The following new definitions have been introduced:
\n\n
\n\n
\n
“controller”: a private person or federal body that alone or jointly with others decides on the purpose and the means of the processing.
\n
\n\n
\n\n
\n
“processor”: a private person or federal body that processes personal data on behalf of the controller.
\n
\n\n
\n\n
\n
“profiling”: any form of automated processing of personal data consisting in the use of such data to evaluate certain personal aspects relating to a natural person, in particular, to analyse or predict aspects relating to that natural person's performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, whereabouts or movements.
\n
\n\n
\n\n
\n
“high-risk profiling”: profiling which involves a high risk to the personality or fundamental rights of the data subject, by creating a link between data which allows an assessment of substantial aspects of the personality of a natural person.
\n
\n\n
\n\n
\n
“data security breach”: a security breach which leads to an unintentional or unlawful loss, deletion, destruction or modification of personal data or to personal data being disclosed or made accessible to unauthorised persons.
\n
\n\n
\n\n
3. Principles of data processing
\n\n
\n\n
The principles of data processing remain materially largely unchanged.
\n\n
\n\n
\n
Art. 6 para. 4 now explicitly stipulates that personal data must be destroyed or anonymised as soon as it is no longer needed with regard to the purpose of the processing. To comply with this obligation, the controller must determine retention periods in advance.
\n
\n\n
\n\n
\n
The definition of “personality profile” is replaced by “profiling” (see description under “definitions”). The terminology of profiling was the sticking point on which the Councils disagreed until the very end and which was also largely discussed in the media. In the end, the conciliation committee followed the proposal of the Council of States and decided to introduce the definition of “high-risk profiling” (which is comparable to the current concept of the personality profile), with the consequence that if consent is required for this type of profiling, it must be explicit.
\n
\n\n
\n\n
It should be noted that the nFADP does not introduce a consent requirement for high-risk profiling, but only requires that consent, if at all required as a justification under art. 31 nFADP, must be given explicitly. It is worth recalling that the basic concept of both the FADP and the nFADP is different from that of the GDPR. While under the GDPR, a legal ground is always required for the processing of personal data (art. 6 and 9 GDPR), the processing of personal data under the FADP and nFADP is, in principle, permitted as long as the personality of the data subjects is not unlawfully violated. Hence, the \"permission principle subject to prohibition\" continues to apply under the nFADP, while the GDPR applies the \"prohibition principle subject to permission\".
\n\n
\n\n
4. Privacy by Design und Privacy by Default
\n\n
\n\n
The principles of “privacy by design” and “privacy by default”, as known from the GDPR, are now also enshrined in the nFADP. In today's practice, the controller is already required to set up data processing activities in a manner that complies with the data protection regulations and the principles of data processing. The nFADP explicitly regulates that the controller must ensure, through appropriate pre-defined settings, that the processing of personal data is limited to the minimum required by the purpose unless the data subject determines otherwise (privacy by default).
The slightly revised article 8 nFADP stipulates that both the controller and the processor must ensure, through adequate technical and organisational measures, a level of data security that appropriately addresses the risk. This means that a risk-based approach is introduced. “The higher the risk of a data security breach, the higher the requirements for the measures to be taken”.9 Further provisions on minimum data security requirements can be found in Section 1 of the DPO.
\n\n
\n\n
6. Data processing by processors
\n\n
\n\n
Art. 9 nFADP essentially adopts the current article 10a FADP. The rather unfortunate term “third parties” is replaced by “processors”. The processing of personal data may still be assigned by agreement or by legislation to a processor if (a) the data is processed only in a manner permitted for the controller itself, and (b) no statutory or contractual duty of confidentiality prohibits the assignment. The controller must ensure in particular that the processor can guarantee data security. As under the GDPR, the processor may only assign the processing to a sub-processor with the prior authorisation by the controller.
\n\n
\n\n
7. Data protection advisor
\n\n
\n\n
Controllers may, but are not required to, appoint a data protection advisor as a contact point for the data subjects and the relevant authorities responsible for data protection matters in Switzerland. The data protection advisor has the duty to train and advise the controller in matters of data protection and to participate in the enforcement of data protection regulations.
\n\n
\n\n
Contrary to the current FADP, the data protection advisor is not responsible for supervising the company’s internal compliance with data protection regulations, nor for maintaining an inventory of data files.
\n\n
\n\n
Private controllers who appointed a data protection advisor have an advantage when they need to perform a data protection impact assessment according to art. 22 nFADP by reason of their processing activities, provided that they consult their data protection advisor. In this case, they can abstain from consulting the FDPIC.10 The controller must consult the FDPIC before the processing when the data protection impact assessment shows that the processing presents a high risk for the personality or fundamental rights of the data subject, despite the measures envisaged by the controller. The controller may abstain from consulting the FDPIC if the data protection advisor (a) performs his or her function towards the controller in a professionally independent manner and without being bound by instructions, (b) does not perform any activities which are incompatible with his or her tasks as data protection advisor, (c) possesses the necessary professional knowledge, and (d) if the controller publishes the contact details of the data protection advisor and communicates them to the FDPIC.
\n\n
\n\n
8. Inventory of processing activities
\n\n
\n\n
As under the GDPR, controllers and processors must each keep an inventory of their processing activities. The nFADP lists the minimum information that needs to be contained in such inventories. The inventory of processing activities does no longer have to be declared to the FDPIC.
\n\n
\n\n
9. Representative in Switzerland
\n\n
\n\n
Similar to the GDPR, private controllers with their domicile or residence abroad must, under certain circumstances, designate a representative in Switzerland if they process personal data of persons in Switzerland. The representative serves as a contact point for data subjects and the FDPIC. The controller must publish the name and address of the representative. The requirements for designating a representative and the duties of the representative are regulated in art. 14 and 15 nFADP.
\n\n
\n\n
10. Cross-border disclosure of personal data
\n\n
\n\n
Under the current FADP, personal data must not be disclosed cross-border if such disclosure would seriously endanger the personal privacy of the data subjects, in particular, due to the absence of legislation that guarantees adequate protection. The FDPIC maintains a list with a general evaluation of the data protection level in the listed countries. However, this non-binding list does not relieve the data exporter from its responsibility to assess on a case by case basis whether the legislation of the respective country guarantees an adequate level of protection.
\n\n
\n\n
Under the nFADP, the Federal Council bindingly determines whether the legislation of a state or an international body guarantees an adequate level of protection. If this is the case, personal data may be transferred cross-border. If not, data protection must be guaranteed by measures such as (a) an international treaty, (b) data protection clauses between the contracting parties, which were communicated beforehand to the FDPIC, (c) standard data protection clauses previously approved, established or recognised by the FDPIC (such as the EU standard contractual clauses) or (d) binding corporate rules (BCR) previously approved by the FDPIC or by a foreign authority which is responsible for data protection and belongs to a state which guarantees adequate protection (for example the CNIL in France as lead authority). The Federal Council can provide for other adequate safeguards, such as, for example, a follow-up agreement to the Swiss-US Privacy Shield.11
\n\n
\n\n
By derogation from the principles mentioned above, personal data may only be disclosed cross-border if one of the exceptions provided for in art. 17 nFADP applies, such as, for example, the explicit consent of the data subject.
\n\n
\n\n
11. Duty of information when collecting personal data
\n\n
\n\n
The duty of information has been tightened. While the duty of information currently only applies to the collection of sensitive personal data and personality profiles, the controller must, in the future, generally inform the data subjects about the collection of their personal data. The minimum information that must be given in the privacy statement is stipulated in art. 19 nFADP, differentiating between data collected directly from the data subject and data collected indirectly via other sources. This minimum information is less extensive than under the GDPR. However, there is one aspect where the nFADP is stricter than the GDPR: if personal data is disclosed cross-border, the controller must inform the data subject of the state where the recipient is located, no matter whether it is located in a state with an adequate level of data protection or in a third country.
\n\n
\n\n
Exceptions to the duty of information have been concretised. Private controllers may still restrict, defer or waive the provision of information in some instances. Among others, this is possible when the overriding interests of the controller demand it and when the controller does not disclose the personal data to third parties, companies controlled by the same legal entity not being considered as third parties in the sense of this exception.
\n\n
\n\n
Under the nFADP, the controller must, as a general rule, inform the data subject of a decision which is taken exclusively based on automated processing and which has legal effects on the data subject or affects him or her significantly (so-called “automated individual decision”). The data subject can request that a natural person review the automated individual decision. Art. 21 nFADP provides for exceptions to this rule.
\n\n
\n\n
12. Data protection impact assessments
\n\n
\n\n
As under the GDPR, the controller must conduct a data protection impact assessment before the data processing if the intended data processing may lead to a high risk for the data subject’s personality or fundamental rights. The existence of high risk, particularly when using new technologies, depends on the nature, the extent, the circumstances and the purpose of the processing (in particular the processing of sensitive personal data on a broad scale and the systematic surveillance of extensive public areas).
\n\n
\n\n
The data protection impact assessment contains a description of the intended processing, an evaluation of the risks for the data subject’s personality or fundamental rights, as well as the intended measures to protect the data subjects’ personality and fundamental rights. Art. 22 nFADP provides for certain exceptions. If the controller considers performing several similar processing operations, it may establish a joint impact assessment.
\n\n
\n\n
If the data protection impact assessment shows that the intended processing leads to a high risk for the personality or the fundamental rights of the data subject despite the measures envisaged, the controller must consult the FDPIC before the processing. It can abstain from consulting the FDPIC if it has appointed a data protection advisor according to art. 10 nFADP and consulted him or her regarding the processing in question.
\n\n
\n\n
13. Notification of data security breaches
\n\n
\n\n
Like the GDPR, the nFADP introduces a duty of notification of data security breaches, i.e. security breaches that lead to the unintentional or unlawful loss, deletion, destruction or modification of personal data or to personal data being disclosed or made accessible to unauthorised persons.
\n\n
\n\n
The good news is that the provisions regarding the notification obligation are slightly more pragmatic under the nFADP than under the GDPR. The controller must notify the FDPIC as soon as possible of a data security breach that is probable to result in a high risk to the personality or the fundamental rights of the data subject.
\n\n
\n\n
Unlike the GDPR, the nFADP only requires notification to the FDPIC where there is a high risk for the data subject. This is meant to prevent the notification of minor breaches. It remains the responsibility of the controller to determine the impact of the breach and the resulting risk for the data subject.
\n\n
\n\n
Contrary to the GDPR, the nFADP does not stipulate a specific period within which the notification to the FDPIC must be made, but demands that the controller notify the breach as soon as possible after having become aware of it. The controller must act quickly but has a certain margin of discretion. “What is decisive in this context is, among others, the extent of the threat for the data subject. The bigger the threat and the larger the number of data subjects concerned, the quicker the controller must act.”12 Furthermore, the controller only needs to inform the data subject if it is necessary for the protection of the data subject or if the FDPIC requests so. What is decisive in this context is whether the notification can reduce the risk for the personality or the fundamental rights of the data subject. This is, in particular, the case where the data subject can take measures for his or her protection, for example by changing his or her login details or password.13 Under certain circumstances, the controller may restrict the information to the data subject, defer it or refrain from providing information.
\n\n
\n\n
The processor has no duty to notify the FDPIC but must inform the controller as soon as possible of any data security breach.
\n\n
\n\n
Art. 24 nFADP lists the minimum requirements for a notification to the FDPIC.
\n\n
\n\n
14. Rights of the data subject
\n\n
\n\n
Access right: The access right currently regulated in art. 8 FADP is now regulated in art. 25 nFADP. The principle remains unchanged. The controller provides the data subject with the information required to enable him or her to assert his or her rights and to ensure the transparent processing of personal data. It is the same information as the one that must be given based on the duty of information. The minimum information that must be provided in reply to a request for information is listed in the nFADP. A new element is information on the existence of automated individual decision-making. In this case, the data subject must also be informed about the logic on which the decision is based. The data subject can further request that a natural person review the automated individual decision.
\n\n
\n\n
The current limitations to the access right continue to exist. Under the nFADP, the controller may “refuse, restrict or defer the provision of information if the request for information is manifestly unfounded or is obviously of a querulous nature”. According to the Federal Council Dispatch14, this limitation is to be interpreted in a narrow sense. In particular, the controller must choose the most favourable solution for the data subject. It must, to the extent possible, only restrict the provision of information, may defer it if necessary and can only refuse it in absolutely clear and obvious cases.
\n\n
\n\n
Right to data portability: Under the nFADP, the data subject has, under certain circumstances, a right to data portability.15 The data subject may request the transfer of his or her personal data to him or her or, if this does not involve a disproportionate effort, to another controller. As a general rule, the data must be disclosed free of charge and in a standard electronic format. The same limitations as for the access right apply.
\n\n
\n\n
Legal claims: The currently applicable legal claims continue to apply and are listed in art. 32 nFADP. The right to deletion or destruction is now explicitly regulated in the nFADP, although it is already implied in the current law.
\n\n
\n\n
15. Administrative measures and sanctions
\n\n
\n\n
The competences of the FDPIC are extended in art. 51 nFADP. Under the new law, he can not only recommend measures but also order administrative measures. Among these measures are for example measures against data processing that violates the data protection regulations, including the order to destroy personal data or the prohibition to disclose personal data cross-border, as well as the order to perform a data protection impact assessment or to inform the data subject. The FDPIC still cannot issue any fines. This competence remains with the cantons.16
\n\n
\n\n
The criminal provisions have been significantly tightened.17 Under the nFADP, private persons (i.e. not companies, as under the GDPR!) are, on complaint, liable to a fine of up to 250 000 Swiss francs if they violate their duty to provide access or information, or their duties of diligence, namely if they disclose personal data cross-border or assign the data processing to a processor without complying with the requirements, or fail to comply with the minimum data security requirements. Persons who wilfully refuse to cooperate with the FDPIC in the context of an investigation are also liable to a fine.
\n\n
\n\n
Further, a person who violates his or her duty of confidentiality by wilfully disclosing secret personal data of which he or she has gained knowledge while exercising his or her profession which requires knowledge of such data is liable to a fine. This provision introduces a duty of confidentiality for persons (and their auxiliary persons) who are not covered by the obligation of professional secrecy under criminal law18. A breach of professional confidentiality can be sanctioned on a complaint with a fine of up to 250 000 Swiss francs.
\n\n
\n\n
Finally, persons who wilfully fail to comply with a decision issued by the FDPIC or by the appellate authorities under threat of penalty are liable to a fine of up to 250 000 Swiss francs.
\n\n
\n\n
It should be noted that only those who act intentionally are liable to prosecution, whereby contingent intent is sufficient. The addressees of the penal provisions are in principle managers, i.e. persons who have independent decision-making powers.19 The company can only be directly fined if the fine does not exceed 50 000 Swiss francs and the investigation of the culpable manager would require disproportionate investigative measures.20
\n\n
\n\n
Finally, it should be noted that violations of essential duties newly enshrined in the law, such as the keeping of an inventory of processing activities, the notification of data security breaches or the obligation to perform data protection impact assessments, are not liable to a fine.
\n\n
\n\n
Implementation measures
\n\n
\n\n
Companies should carry out a data management analysis and identify their level of compliance with the nFADP as well as any possible gaps and risks. In doing so, they should focus on the following areas:
\n\n
\n\n
\n
governance structure,
\n
data protection standards and processes to comply with the privacy principles and data security,
\n
transparency towards the data subjects,
\n
inventory of processing activities,
\n
data flows within the company and to service providers (taking into consideration the latest developments and the policy paper of the FDPIC21),
\n
processes for performing data protection impact assessments,
\n
notification of data security breaches to the FDPIC and
\n
responding to requests for information (access rights).
\n
\n\n
\n\n
Companies who already introduced a GDPR data protection program will have less need for action than companies who are not subject to the GDPR or who have not yet taken any respective measures.
\n\n
\n\n
Many companies will, in any case, have to introduce concepts such as privacy by design as well as processes that allow the legally compliant deletion or destruction of personal data and support data portability. Many companies will also have to review their privacy statements and, if needed, adapt them or issue new privacy statements to fulfil the requirements of the nFADP. Current inventories of data files will have to be restructured to record data processing activities.
\n\n
\n\n
If you have any questions or need support in this area, please do not hesitate to contact FABIAN PRIVACY LEGAL.
\n\n
\n\n
\n\n
[1] This article is an updated version of the article published in October 2020 by the same author under the same title.
[3] Dispatch on the Federal Act on the total revision of the Federal Act on Data Protection and the amendment of other enactments on data protection (BBl 2017 6943)
[11] On 8 September 2020, the Federal Data Protection and Information Commissioner (FDPIC) determined that the Swiss-US Privacy Shield was no longer adequate for the transfer of personal data from Switzerland to the US. The European Commission and the United States announced in March 2022 an \"agreement in principle\" on the new Transatlantic Data Protection Framework (TADPF), which is intended to facilitate the flow of data between the EU and the US and address the concerns raised by the European Court of Justice in the Schrems II decision in 2020. US President Biden subsequently issued the Executive Order On Enhancing Safeguards for United States Signals Intelligence Activities in October 2022, implementing US commitments under the TADPF. On 13 December 2022, the European Commission published a draft adequacy decision concluding that the EU-US data protection framework provides an adequate level of protection for personal data transferred by EU companies to the US. A final decision by the European Commission is expected around mid-2023.
The new Swiss Data Protection Act (Federal Act on Data Protection - nFADP) will enter into force together with the new Ordinance to the Federal Act on Data Protection (DPO) and the new Ordinance on Data Protection Certification (DPCO) on 1 September 2023. The nFADP introduces new obligations for private persons and federal bodies, improves the rights of data subjects and significantly tightens personal criminal liability for violations of the nFADP. What do companies in Switzerland and abroad need to know to ensure data protection-compliant data processing? This article summarises the most important changes for companies.
\n","preview":"","datei":[],"linkextern":""},{"id":170,"title":"What does data protection have to do with digital transformation? (in German)","slug":"was-hat-datenschutz-mit-digitaler-transformation-zu-tun","link":"/en/news-knowledge/was-hat-datenschutz-mit-digitaler-transformation-zu-tun","titel":"What does data protection have to do with digital transformation? (in German)","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
Was hat Datenschutz mit digitaler Transformation zu tun?
\n\n
Die Digitalisierung erlaubt es, Daten immer besser und schneller zu sammeln und analysieren. Sind Personendaten involviert, muss der Datenschutz eingehalten werden.
\n\n
Am 1. September 2023 tritt das revidierte Datenschutzgesetz (DSG) in Kraft, mit neuen Pflichten und verschärften Sanktionen.
\n\n
\n\n
Eckpunkte des revidierten DSG
\n\n
Besonders schützenswerte Daten umfassen neu genetische und biometrische Daten. Profiling und Profiling mit hohem Risiko, also die automatisierte Bearbeitung von Personendaten, um persönliche Aspekte zu analysieren oder vorherzusagen, wurden eingeführt. Jede Person kann vom Verantwortlichen die Herausgabe ihrer Personendaten, die sie diesem bekanntgegeben hat und automatisiert bearbeitet werden, in einem gängigen elektronischen Format verlangen. Verantwortliche müssen betroffene Personen über die Beschaffung von Personendaten sowie automatisierte Einzelentscheidungen informieren. Datenbearbeitungen müssen ab Planung durch geeignete Massnahmen die Einhaltung der Datenschutzvorschriften gewährleisten (Privacy by Design) und bei hohem Risiko einer Datenschutz-Folgenabschätzung unterzogen werden. Neu muss ein Bearbeitungsverzeichnis geführt werden und die Datensicherheit durch geeignete technische und organisatorische Massnahmen gewährleistet sein. Verletzungen der Datensicherheit müssen je nach Risiko dem EDÖB gemeldet werden.
\n\n
\n\n
Verschärfte Sanktionen
\n\n
Wer vorsätzlich gegen Informations-, Auskunfts oder Sorgfaltspflichten verstösst, namentlich die Datensicherheits-Anforderungen nicht einhält, Personendaten ins Ausland bekanntgibt oder ohne Erfüllung der gesetzlichen Anforderungen Auftragsbearbeiter einsetzt, riskiert eine Busse bis zu 250'000 Franken. Adressat der Busse ist nicht das Unternehmen, sondern die Leitungsperson mit entsprechender Entscheidungs- und Weisungskompetenz.
\n\n
\n\n
Was können Unternehmen tun?
\n\n
Unternehmen sollten frühzeitig ihre Bearbeitungstätigkeiten erfassen, Datenschutzerklärungen prüfen und ggf. anpassen und Prozesse zur Sicherstellung der gesetzeskonformen Umsetzung der Datenschutzanforderungen und Pflichten implementieren.
\n\n
\n","datum":"18.12.2022","teasertext":"
Thanks to the ongoing digitalization, data collection and analysis is becoming increasingly better and faster. In this context, data protection is essential whenever personal data is involved. In an article published in the magazine \"Ausblick 2023\", Daniela Fábián Masoch explains the changes brought about by the entry into force of the revised Swiss data protection act on September 1, 2023 and what companies can do in order to be prepared. Please note that the publication is only available in German.
\n","preview":"","datei":[],"linkextern":""},{"id":174,"title":"The new Swiss Data Protection Act - What you need to know","slug":"das-neue-schweizer-datenschutzgesetz-was-sie-wissen-muessen","link":"/en/news-knowledge/das-neue-schweizer-datenschutzgesetz-was-sie-wissen-muessen","titel":"The new Swiss Data Protection Act - What you need to know","text":"
The revised Federal Act on Data Protection (nFADP) will come into force on September 1, 2023, together with the implementing provisions in the Ordinance to the Federal Act on Data Protection (DPO) and the Ordinance on Data Protection Certifications (DPCO).
\n\n
\n\n
Although the principles of data protection remain essentially the same, a number of new obligations are imposed on companies. These obligations include, for example, an extended duty to inform data subjects, the performance of data protection impact assessments, the record of data processing activities, the implementation of privacy by design and the notification of data security breaches. The penal provisions for natural persons have also been tightened significantly.
\n\n
\n\n
As the nFADP does not provide for any transition periods, companies should now examine the extent to which their internal regulations and processes for data management comply with the new requirements.
\n\n
\n\n
This webniar on Mondaq highlights the new obligations for companies and the consequences of non-compliance. It will highlight the need for action for companies and provide pragmatic implementation approaches. Finally, the most important differences to the GDPR will be highlighted.
\n\n
\n\n
To download the webinar in PDF format, please click here.
\n\n
\n\n
To view the webinar directly on the Mondaq website, please click here.
\n","datum":"07.12.2022","teasertext":"
This webniar on Mondaq highlights the new obligations for companies and the consequences of non-compliance. It will highlight the need for action for companies and provide pragmatic implementation approaches. Finally, the most important differences to the GDPR will be highlighted.
To download the article in PDF format, please click here.
\n\n
\n\n
1 Introduction
\n\n
\n\n
Laws around the world impose strict data security obligations on organisations that process personal data, and in some cases require them to report data breaches to data protection authorities and individuals affected by the data breach. In addition to significant sanctions for failing to take appropriate technical and organisational measures to protect data, and potentially for failing to report a data breach as required by law, organisations may suffer, among other things, loss of stakeholder trust, reputational damage, and disruption of business activities as a result of a data breach, leading to economic losses. In addition, there are significant costs associated with managing a data breach and remediating the damage caused by the breach.
\n\n
\n\n
Investing in data security to prevent data breaches, such as those caused by cyberattacks or employee errors, and being prepared to respond in the event of a data breach is therefore worthwhile not only to comply with the legal obligations, but also to avoid negative consequences for the organisation and its stakeholders.
\n\n
\n\n
This article elaborates on what constitutes a personal data breach and what a data breach prevention and response strategy might look like. It is limited to dealing with data breaches involving personal data and takes the requirements of the General Data Protection Regulation (GDPR) as a starting point, but without limiting itself to the GDPR.
\n\n
\n\n
2 What is a Data Breach and its Potential Consequences?
\n\n
\n\n
A data breach (also called a personal data breach or security breach) occurs when personal data held by an organisation is lost or subjected to unauthorised access, modification, disclosure, or other misuse or interference. The GDPR defines the term personal data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored, or otherwise processed. Privacy laws in other jurisdictions contain similar, though not identical, definitions.
\n\n
\n\n
In its Opinion 03/2014 on data breach notification and its Guidelines on personal data breach notification under Regulation (EU) 2016/679 (WP250rev.01), the Article 29 Data Protection Working Party divided data breaches into three security principles:
\n\n
\n\n
\n
Confidentiality breach – where there is an unauthorised or accidental disclosure of, or access to, personal data.
\n
\n\n
\n\n
\n
Integrity breach – where there is an unauthorised or accidental alteration of personal data.
\n
\n\n
\n\n
\n
Availability breach – where there is an accidental or unauthorised loss of access to, or destruction of, personal data.
\n
\n\n
\n\n
Examples of data breaches include the loss or theft of a data carrier (e.g., notebook, phone, USB stick, paper files) containing unencrypted personal data of customers or employees (breach in confidentiality, and potentially availability if there is no backup for the stolen device); the successful penetration of an organisation’s computer systems containing personal data for the purpose of copying, exfiltrating, and misusing personal data for malicious purposes (breach in confidentiality and possibly integrity); a ransomware attack in which the attacker encrypts data with a malicious code and then demands a ransom from the attacked organisation in exchange for the decryption key (availability breach, and possibly confidentiality breach); the unauthorised downloading of personal data by a terminated employee for further private use (confidentiality breach); the inadvertent disclosure of personal data by an employee to unauthorised persons inside or outside the organisation, e.g., by sending it to an incorrect address or by sending a file that inadvertently contains personal data not intended for the recipients (confidentiality breach).
\n\n
\n\n
A data breach may have various negative effects on individuals and result in physical, material and immaterial damage. It may, for example, cause the affected individual to lose control over his or her personal data or to be restricted in the exercise of his or her personal rights, to suffer financial loss or personal disadvantage, emotional distress, embarrassment or humiliation, or damage to his or her reputation. Possible consequences may also include identity theft or fraud, loss of employment or business opportunities, unwanted marketing or spam, reversal of pseudonymisation, or other significant economic or social disadvantages.
\n\n
\n\n
Organisations can also suffer harm as a result of a data breach. Responding to a data breach and potential subsequent complaints and implementing remedial actions may have financial, legal and resource implications. Data breaches can further result in reputational damage and loss of stakeholder trust.
\n\n
\n\n
According to the Ponemon Institute’s 2021 Cost of a Data Breach Report, the average total cost of a data breach increased by nearly 10% year over year. The amount increased from $3.86 million in 2020 to $4.24 million in 2021, with costs being significantly lower for organisations with more mature security levels. The average total cost was $1.07 million higher for breaches where remote work was a factor in the breach, compared to breaches where remote work was not a factor. The average total cost per record containing personal data was $161. The longer it took to detect the breach, the more expensive it was, with 38% of the costs related to lost business (including business interruption and lost revenue due to system downtime, cost of lost customers and acquiring new customers, loss of reputation, and diminished goodwill). 29% of the costs related to detection and escalation. The remaining cost drivers were post-breach response (27%), and notification (6%). The costliest initial attack vectors were business emails, followed by phishing, malicious insiders, social engineering, and compromised credentials.
\n\n
\n\n
3 Data Breach Notification Requirements
\n\n
\n\n
Many countries around the world have introduced data breach notification regulations. The first laws were enacted in the U.S. at the state level starting in 2002 (California). Other countries have followed, such as the EU Member States and the United Kingdom with the General Data Protection Regulation (GDPR) and the UK Data Protection Regulation (UK GDPR), respectively, as well as other countries around the world, such as Australia, Brazil, China, Colombia, Egypt, Ghana, Israel, Kenya, Mexico, New Zealand, the Philippines, Singapore, South Korea, Switzerland, Taiwan, Thailand and Uruguay.
\n\n
\n\n
Independent of data breach notification requirements, most countries in the world have introduced data security obligations that must be implemented by data controllers and data processors.
\n\n
\n\n
4 Data Breach Response Strategy
\n\n
\n\n
Although security requirements and the conditions and modalities of notification obligations may vary from country to country, any organisation that processes personal data and is subject to security and notification obligations should define and implement a data security and breach management strategy to ensure adequate data security and risk mitigation in the event of an incident and be prepared to deal with any data breaches.
\n\n
\n\n
The data breach response strategy does not need to be stand-alone but can and should be aligned with other internal data management and security strategies, e.g., information security, where possible. It should cover three key factors: prevention; response; and improvement.
\n\n
\n\n
4.1 Prevention – Implement appropriate TOMs
\n\n
\n\n
Even with the best possible security, data breaches cannot be completely avoided. However, data breaches are often the result of a vulnerable and outdated security regime or system weaknesses. Prevention through the adoption of appropriate security measures is therefore key to preventing vulnerabilities in systems or insufficient security that can potentially lead to a data breach.
\n\n
\n\n
Data and risk mapping: Only if organisations know what types of data breaches could occur and understand the characteristics of these breaches, they can take the necessary technical and organisational measures (TOMs) to reduce the risk of a successful attack or breach.
\n\n
\n\n
The basic prerequisite is first that companies know what types of data and personal data they process, who the data subjects are and their locations, where the data is stored and who should have access to it. This knowledge requires the mapping of all data systems, products and services that process personal data and their classification. Organisations should then assess the risk level to their organisation and to individuals in the case of a data breach as well as identify the possible types of attacks and based on that understanding and the level of risk, take the appropriate technical and organisational measures to mitigate the consequences in the case of a data breach.
\n\n
\n\n
Implementation of TOMs: Based on the risk level, such TOMs may include a state-of-the-art encryption of the data at rest and a separate back-up of the data to help mitigate the consequences of a successful ransomware attack or the loss or theft of a device with personal data. In addition to a state-of-the-art encryption, measures such as key management, regular updates of systems, use of strong authentication methods like two factor authentication, firewalls, etc. may help to mitigate the consequences of data exfiltration. Regular awareness campaigns and training to staff on security aspects, instructions on how to use company devices and information as well as the implementation of technical measures and controls may help to prevent human errors.
\n\n
\n\n
External resources and insurance coverage: Besides the implementation of robust TOMs, organisations should evaluate in advance what type of external expertise is required in the case of a data breach and ensure that such expertise is available on short notice, which may require the negotiation of frame contracts in advance. Additionally, organisations may consider holding an insurance policy for data breaches.
\n\n
\n\n
Data breach response plan: Finally, organisations should deploy a data breach response plan that sets out procedures, modalities, and responsibilities in the event the organisation experiences a data breach (or a suspected data breach, i.e., a security incident) to respond to a data breach in a timely and efficient manner.
\n\n
\n\n
4.2 Response – Implement a data breach response plan
\n\n
\n\n
4.2.1. Why a data breach response plan?
\n\n
\n\n
Due to the usually very short timelines for reporting a data breach to the data protection authorities and individuals (at least in some countries, including the EU), it is critical that each organisation handling personal data put in place a documented data breach response plan. Implementing such a plan can help organisations in (a) mitigating the impact on the organisation and affected individuals and the costs resulting from the data breach, (b) meeting their data security obligations, (c) protecting important business assets, including personal data of their employees and clients and the company’s reputation, (d) dealing with negative media or stakeholder attention, and (e) instilling public confidence and trust in the organisation’s capacity to protect personal data entrusted to the company by properly responding to a data breach.
\n\n
\n\n
The data breach response plan should be aligned with other plans as appropriate, such as existing security incident response, disaster recovery, business continuity, or contingency plans. This approach can ensure effective management with clear responsibilities, avoid duplication, and leverage synergies.
\n\n
\n\n
4.2.2. Content of a data breach response plan
\n\n
\n\n
A data breach response plan shall establish the rules and processes on how to handle a data breach in compliance with internal standards and legal and regulatory requirements. It shall outline what a data breach is, possibly providing some concrete examples tailored to the specific organisation, allocate the roles and responsibilities for detecting, responding, and documenting a data breach, describe the process for handling a data breach, from detection to notification and risk mitigation, and specify the obligations towards third parties processing the data on their behalf.
\n\n
\n\n
4.2.3. Establishment of an incident response team
\n\n
\n\n
While in small organisations, the managing director or owner is often the person who deals with a data breach, usually with external assistance, establishing an incident response team has proven effective in mid-sized and larger organisations. The purpose of such a team is to ensure that in the event of a data breach, the relevant functions are immediately engaged, and data breaches can be promptly addressed, risks assessed, and any required notifications made in a timely manner.
\n\n
\n\n
The composition of the team will depend on the organisation and the nature of the business, but will typically require different skill sets, which can be ensured by involving internal functions and external legal, data forensics, and media management experts. Organisations should assess in advance what type of external expertise will be needed in the event of a data breach and ensure that this expertise is available on short notice. The organisation should maintain and regularly update a current list of team members, including their roles, responsibilities, and contact details, as well as the contact information of their delegates. Team members should receive regular training and participate in mock exercises. The response team should consist of a core team that includes, at a minimum, the data protection officer, and the information security officer, and should be extended to include other functions such as human resources, research and development, or communications, as well as outside legal counsel and forensic analysts, depending on the severity and nature of the incident.
\n\n
\n\n
The incident response team shall be responsible for managing the overall data breach, investigating, and reviewing the circumstances of the data breach and the facts of the case, engaging relevant functions and external experts, assessing the level of risk, determining remediation actions, determining the need for internal escalation, and notifying data protection authorities and individuals. The data breach response plan should identify the specific responsibilities of each member of the response team.
\n\n
\n\n
4.2.4. Process for responding to a data breach
\n\n
\n\n
The process for responding to a data breach typically includes different steps, starting from the detection of the data breach and reporting to the immediate containment, investigation of the data breach, risk evaluation, internal escalation, notification, and documentation.
\n\n
\n\n
Detection and reporting: Each employee should understand how to recognise a potential data breach and know how to report such a data breach or suspected data breach (security incident) to the incident response team, that will immediately perform a preliminary evaluation and determine if the incident qualifies as a data breach.
\n\n
\n\n
Containment: Once the source of the data breach has been identified, the data breach should be contained immediately to prevent further exposure of personal data, for example, and depending on the concrete impact, by remediating identified vulnerabilities in systems, recovering records, shutting down the compromised system, restricting access to data, recalling sent emails containing personal data that were inadvertently attached to the email or sent to the wrong recipients, or deleting them from the accounts of the unintended recipients.
\n\n
\n\n
Investigation: The incident response team should investigate and document the facts and circumstances of the data breach, including the causes of the data breach such as any vulnerabilities in the computer systems; the nature of the data breach (breach of confidentiality, availability, or integrity); the nature, scope, and sensitivity of the personal data involved, as well as the origin of the data; the type, number, and location of data subjects; applicable data protection laws; and notification requirements.
\n\n
\n\n
Risk evaluation: Based on the outcome of the investigation and taking into account the type of personal data compromised, the extent of the data breach, and the type and number of individuals affected by the data breach, the incident response team must assess the level of risk of the data breach to the rights and freedoms of data subjects and the organisation. To assess the level of risk, they must determine the impact that the data breach could have on the rights and freedoms of individuals and the likelihood that this impact will actually occur. The greater the impact and the greater the likelihood, the higher the risk. Essential elements for determining the impact on individuals are the ease of their identification (how easily can an individual be identified from the compromised data?) and the severity (how much harm can be caused by the data breach?). Key elements in determining the likelihood of the identified impact actually occurring are the potential vulnerabilities due to the lack of appropriate TOMs and the ability to exploit those vulnerabilities or the intent of the individuals accessing or possessing the data (was the data exfiltrated by a hacker with malicious intent or sent by an employee to the wrong recipient in the same organisation by mistake?).
\n\n
\n\n
Escalation: The data breach response plan should define the internal escalation process, which should depend on the severity and extent of the breach, the level of risk identified, and the requirement for notification.
\n\n
\n\n
Notification: The incident response team determines, based on all the facts and the risk evaluation, whether the data breach must be notified to local data protection authorities and affected individuals, and if so, when, where, and how. The data breach response plan should identify which function is responsible for notifying the authorities and individuals. Generally, this task is assigned to the data protection officer. It is also advantageous if possible scenarios requiring notification have already been worked through and documented.
\n\n
\n\n
Documentation: Any data breach, whether notified to data protection authorities and/or individuals or not, shall be documented, including the facts and circumstances of the breach, its effects, and the corrective actions taken and planned to prevent future similar data breaches, the risk evaluation, and the appropriate justification for the decisions made with respect to the notification to data protection authorities and individuals.
\n\n
\n\n
4.2.4. Considerations in implementing a data breach response plan globally
\n\n
\n\n
Given the large number of countries with data breach notification requirements, globally operating companies are faced with the challenge of finding solutions that are as comprehensive and uniform as possible in order to, on the one hand, deal with data breaches uniformly and efficiently across the organisation and, on the other hand, take into account the specifics of the individual countries.
\n\n
\n\n
When implementing a data breach response plan globally, companies must take into account locally applicable data privacy and security laws, as well as notification requirements and modalities, languages, and cross-border data transfer restrictions, and align the data breach response plan accordingly. Companies should also decide what the internal reporting channel for discovered data breaches should be. Depending on their organisational set-up, they could establish one global reporting channel or separate regional or local reporting channels. Also, organisations must determine where data breaches should be documented (in a centralised system or locally), and whether a global incident response team should be deployed around the world or regional/local response teams should be established.
\n\n
\n\n
4.3 Improvement – Address security gaps to prevent future (similar) data breaches – regularly re-evaluate the data breach response plan to increase effectiveness
\n\n
\n\n
The third phase of the data breach response strategy consists of improvements in two respects: addressing identified vulnerabilities to prevent future similar data breaches; and increasing the effectiveness of the data breach response plan.
\n\n
\n\n
Address any identified security vulnerabilities to prevent future similar data breaches. Once the notification and documentation process is complete, the incident response team should determine and implement appropriate measures to prevent future similar data breaches. Depending on the concrete type of data breach and the root cause, such measures may include, for example, conducting regular security audits and reviewing and updating policies and procedures in light of lessons learned, reviewing and amending contracts with third parties to ensure appropriate handling of data breaches. Other measures may include, for example, restricting the downloading of personal data to mobile devices without adequate security protection, such as state-of-the-art encryption or the establishment of separate backups of specific data sets, and regular training for the business units concerned.
\n\n
\n\n
Periodically re-evaluate the data breach response plan to increase its effectiveness taking into account changes in applicable data protection laws, best practices and internal business requirements.
\n\n
\n\n
5 Conclusion
\n\n
\n\n
Data security is one of the essential obligations of any organisation that processes personal data. A breach of the confidentiality, integrity or availability of data can have negative consequences not only for the individuals concerned, but also for the responsible organisation. A data breach can result in notification obligations, significant costs to contain the data breach and repair the damage caused by the breach, as well as loss of stakeholder trust, reputational damage, and business disruption. Investing in data security to prevent data breaches, such as those caused by cyberattacks or human error, and being prepared to respond in the event of a data breach is therefore essential for any organisation to meet its legal obligations and avoid negative consequences for itself and individuals affected.
\n\n
\n","datum":"13.07.2022","teasertext":"
Laws around the world impose strict data security obligations on organisations that process personal data, and in some cases require them to report data breaches to data protection authorities and individuals affected. Failure to comply with these laws may lead to significant sanctions, loss of stakeholder trust, reputational damage, and disruption of business activities. Investing in data security to prevent data breaches and being prepared to respond in the event of a data breach is therefore worthwhile not only to comply with the legal obligations, but also to avoid negative consequences. This article elaborates on what constitutes a personal data breach and what a data breach prevention and response strategy might look like.
\n","preview":"","datei":[],"linkextern":""},{"id":127,"title":"Keep legally up to date with the ongoing digital development (in German)","slug":"juristisch-a-jour-sein-mit-der-digitalen-entwicklung-fuer-firmen-heute-unerlaesslich","link":"/en/news-knowledge/juristisch-a-jour-sein-mit-der-digitalen-entwicklung-fuer-firmen-heute-unerlaesslich","titel":"Keep legally up to date with the ongoing digital development (in German)","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
Juristisch à jour sein mit der digitalen Entwicklung - für Firmen heute unterlässlich
\n\n
\n\n
Dem Thema Datenschutz kommt in einer zunehmend digitalisierten Welt grosse Bedeutung zu. Die Rechtsprechung passt sich dieser Entwicklung an, mit neuen Regularien und Gesetzen. Daniela Fábián, Gründerin von FABIAN PRIVACY LEGAL, unterstützt Unternehmen dabei, diesen Vorgaben nachzukommen.
\n\n
\n\n
Interview mit Daniela Fábián, Anwältin und Geschäftsführerin FABIAN PRIVACY LEGAL
\n\n
\n\n
Daniela Fábián, welches sind die juristischen Frage- und Problemstellungen, mit denen Ihre Kundinnen und Kunden an Sie herantreten?
\n\n
\n\n
Zu meinen Kunden gehören Konzerne, KMUs und Start-ups. Diese Unternehmen brauchen Unterstützung bei der Umsetzung der datenschutzrechtlichen Anforderungen, die sich aufgrund neuer Gesetze und der sich wandelnden Rechtsprechung ergeben. Ich unterstütze sie in der Risiko- und Bedarfsanalyse und der Entwicklung und Implementierung ihrer Datenschutzstrategie und -programme sowie bei der Beantwortung unterschiedlicher Praxisfragen. Unternehmen, die bereits ein Datenschutzprogramm implementiert haben, suchen uns auf, um sie bei der weltweiten Umsetzung ihrer globalen Datenschutzstrategie oder bei spezifischen Projekten zu unterstützen.
\n\n
\n\n
Was raten Sie Unternehmen in der Schweiz, die dieses Thema bisher noch nicht vertieft behandelt haben?
\n\n
\n\n
Mit dem totalrevidierten DSG kommen neue Pflichten auf Unternehmen zu, wie etwa erweiterte Informations- und Meldepflichten, die Durchführung von Datenschutz-Folgenabschätzungen und die Dokumentation von Bearbeitungstätigkeiten. Unternehmen müssen jetzt handeln. Zunächst sollten sie sich einen Überblick über die Ist-Situation verschaffen. Welche Personendaten bearbeiten wir und zu welchen Zwecken? Sind die betroffenen Personen informiert? Woher stammen die Daten, wo werden sie gespeichert und wer hat Zugriff darauf? Welche internen Prozesse und Regelungen bestehen? Solche und ähnliche Fragen stehen im Zentrum und helfen dabei, Lücken und Risiken zu identifizieren. Darauf basierend lässt sich eine Risikoanalyse vornehmen.
\n\n
\n\n
Um welche Risiken geht es dabei?
\n\n
\n\n
Dies unterscheidet sich je nach Unternehmen und Branche. Zum Beispiel müssen Pharma- und Medtech-Firmen, die mit sensiblen Patientendaten arbeiten, anderen Anforderungen genügen als etwa Logistikunternehmen. Der internationale Datentransfer und die Auslagerung der Datenbearbeitung können ebenfalls zu einem Risiko werden, wenn nicht alle erforderlichen Massnahmen getroffen werden. Schliessich nehmen Cyberattacken zu und ein Zuwiderhandeln gegen das DSG kann Geldbussen sowie Reputationsschäden nach sich ziehen.
\n\n
\n\n
Können Sie ein konkretes Beispiel dafür nennen, wie Firmen Ihr Fachwissen nutzen?
\n\n
\n\n
In der Regel suchen meine Kunden meine praktische Erfahrung bei der Umsetzung pragmatischer Datenschutzmanagementprogramme und -lösungen. Meine Expertise ist etwa auch bei der Entwicklung von Apps, zentralen Datenschutzmanagementsystemen oder digitalen Marketingkampagnen gefragt. Bei solchen Projekten ist es wichtig, alle relevanten Datenschutzanforderungen und -grundsätze bereits in der Konzeptionsphase in die Prozesse und Systeme einzubinden. Auch bei Verträgen mit komplexen Datenflüssen und der Beteiligung mehrerer Parteien besteht oft Unterstützungsbedarf.
\n\n
\n\n
Die digitale Technologie entwickelt sich rasant. Welche Fragen und Anliegen werden Sie und Ihre Kundinnen und Kunden künftig beschäftigen?
\n\n
\n\n
Für Schweizer Unternehmen wird neben der Umsetzung des revidierten DSG der internationale Datenfluss und damit verbunden die Überprüfung der Outsourcing-Strategie eine Priorität bleiben. Im Weiteren wird der Einsatz von künstlicher Intelligenz in vielen Bereichen weiter zunehmen, was immer auch Datenschutzfragen aufwirft sobald Personendaten involviert sind, Profile erstellt oder automatisierte Entscheide erfolgen. Auch das Konzept «Privacy by Design», gemäss dem die Datenbearbeitungsgrundsätze bereits bei der Entwicklung neuer Tools berücksichtigt und technisch umgesetzt werden müssen, wird Unternehmen aller Art zunehmend beschäftigen. Richtig umgesetzt, kann damit das Risiko von Datenschutzverletzungen und Cyberattacken reduziert werden.
\n\n
\n\n
Ihre Anwaltskanzlei ist spezialisiert auf internationales, europäisches und schweizerisches Datenschutzrecht, Governance, Risikomanagement und Programmimplementierung. Wie kam es zu dieser Spezialisierung?
\n\n
\n\n
Datenschutz begleitet mich schon seit meiner Assistenzzeit an der Uni Basel. Später arbeitete ich als In-House-Anwältin bei Novartis, wo ich unter anderem die Verantwortung für den globalen Datenschutz übernahm und für den Konzern das globale Datenschutzprogramm und die «Binding Corporate Rules» entwickelt und weltweit implementiert habe. In dieser Zeit konnte ich mir ein tiefgreifendes Wissen in diesem damals noch neuen Thema aneignen. Mit dieser Erfahrung machte ich mich Ende 2015 mit meiner eigenen Kanzlei selbstständig. Heute begleite ich Unternehmen, viele davon aus dem Pharma- und Life-Sciences-Sektor, von der ersten Analyse über die Risikoeinschätzung bis hin zur Entwicklung und Implementierung von Datenschutzprogrammen. Dazu gehört auch das Training von Mitarbeitenden, um ein durchgehendes Verständnis für die Relevanz des Themas zu kultivieren und Awareness zu schaffen. Um sicherzustellen, dass wir für alle Anliegen, einschliesslich IT-relevanter Themen und anderer Rechtsordnungen, die notwendige Expertise bereitstellen können, arbeiten wir mit Kooperationspartnern in unterschiedlichen Bereichen und in diversen Ländern.
\n","datum":"25.04.2022","teasertext":"
In an interview with the magazine \"Fokus Rechtsguide\", Daniela Fábián Masoch explains what companies should to in order to keep legally up to date with the ongoing digital development and to comply with new data protection laws, such as the revised Swiss Data Protection Act. Please note that the publication is only available in German.
\n","preview":"","datei":[],"linkextern":""},{"id":129,"title":"Privacy by Design as a fundamental requirement for the processing of personal data","slug":"privacy-by-design-as-a-fundamental-requirement-for-the-processing-of-personal-data","link":"/en/news-knowledge/privacy-by-design-as-a-fundamental-requirement-for-the-processing-of-personal-data","titel":"Privacy by Design as a fundamental requirement for the processing of personal data","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
Privacy by design (“PbD”) is a fundamental requirement for privacy-compliant processing of personal data and is, in principle, a well-known approach. Nevertheless, PbD is often not consistently implemented, in some cases leading to significant consequences and costs for organisations. This article describes the concept of PbD and its practical implementation under the application of the European Union (“EU”) General Data Protection Regulation (EU) 2016/679 of 27 April 2016 (“GDPR”).
\n\n
\n\n
1 Introduction
\n\n
\n\n
The ongoing development of new and complex technologies such as artificial intelligence (“AI”), blockchain, or the Internet of Things (“IoT”) and their increasing use, as well as ongoing digitisation and centralisation of data management, are leading to increasingly sophisticated ways of automating the processing of enormous amounts of data, facilitating data flows and availability, profiling consumers, customers, patients, or job applicants, and making automated decisions.
\n\n
\n\n
To reap the benefits of these technologies, digitisation, and new business models in connection with the processing of personal data, those who develop or deploy them must consider and implement applicable data protection principles and requirements through appropriate and adequate technical and organisational measures from the outset, already at the design stage, and continuously monitor, adjust and update them throughout the lifecycle of the system, product, or process.
\n\n
\n\n
With this PbD approach, a company can ensure compliance with legal requirements, meet the expectations of individuals and stakeholders, build trust, make strategic and operational decisions with foresight and efficiently implement business processes. This can include, for example, storing data on servers in the EU or Switzerland instead of in the U.S.A. or purchasing software with integrated data protection principles.
\n\n
\n\n
PbD has become a critical factor in building and maintaining trust, competitiveness and success in the marketplace.
\n\n
\n\n
2 The Concept of PbD
\n\n
\n\n
The concept of PbD is a fundamental requirement for the effective implementation of data protection. In essence, PbD requires that controllers consider data protection principles and requirements both at the design stage of systems, processes, products or services that involve the processing of personal data, and throughout the lifecycle of personal data, and that they provide for appropriate technical and organisational measures (“TOMs”) to implement data protection requirements and protect the rights of data subjects. Controllers must be proactive and anticipate potential privacy intrusions before they occur.
\n\n
\n\n
One of the fundamental elements of PbD is “privacy by default”. This concept requires that the controller implements appropriate TOMs to ensure that, by default, only personal data that is necessary to fulfil the specific purpose is processed. PbD must be implemented in terms of the amount of data collected, the scope of its processing, the duration of its storage, its security, and its accessibility.
\n\n
\n\n
While the concept of PbD has long existed as good practice, it was introduced as a legal obligation for controllers in Art. 25 GDPR, with significant fines for non-compliance. In introducing the PbD concept, the legislator primarily wanted to emphasise that it is not enough to set standards, and that the controller must also implement these standards in an effective and verifiable manner. Other laws have also adopted the concept of PbD, most recently the new Swiss Federal Act on Data Protection (“nFADP”), which is expected to come into force in 2022. However, unlike the GDPR, under the nFADP a breach of the new PbD obligation will have no direct consequences.
\n\n
\n\n
However, neither the GDPR nor the nFADP specify how the controller should implement PbD in practice.
\n\n
\n\n
So far, the introduction of processes and the designation of responsibilities for the systematic and timely assessment of the planned data processing, the technologies and systems used for this purpose and the data protection risks for the data subjects have proven effective. This risk assessment aims to identify the technical and organisational measures required to effectively integrate data protection principles and requirements into the design of the respective products, systems or processes and to protect the privacy of the data subjects. Risks to data subjects include, for example, excessive collection and disclosure of personal data, processing of data for purposes other than the original purpose, unlawful processing, as well as loss, destruction or alteration of data.
\n\n
\n\n
Such a risk assessment, coupled with a compliance assessment, is required for any processing of personal data, including, for example, the implementation of a Customer Relation Management (“CRM”) or HR data management system or the outsourcing of data processing, regardless of the technology used or the sensitivity of the data. While similar, this risk and compliance assessment is not a data protection impact assessment (“DPIA”) as required under Art. 35 GDPR.
\n\n
\n\n
A controller must conduct a DPIA only if the processing is likely to present a high risk to data subjects’ rights and freedoms. A DPIA is a broader assessment that goes beyond a compliance assessment by evaluating the residual risks to data subjects, taking into account the TOMs embedded in the design of the product, system or process. If the residual risk is still considered high, the controller must take further measures to mitigate the risk. If this is not possible, the controller must consult the data protection authority or refrain from processing. A DPIA will be regularly required for digital health solutions where health-related data or other special categories of data are processed. A DPIA will also be regularly required for the use of innovative or combined technologies and extensive profiling.
\n\n
\n\n
3 Implementing PbD In Practice
\n\n
\n\n
3.1 Technical and organisational measures
\n\n
\n\n
The controller must implement TOMs both at the time of determining the means of processing and during the processing itself. The TOMs must be adequate and appropriate to:
\n\n
\n\n
\n
effectively implement data protection principles, such as data minimisation, lawfulness, transparency, confidentiality, purpose limitation, data integrity, storage duration, security, as well as the requirements concerning commissioned data processing and cross-border data transfers;
\n
integrate the necessary safeguards into the processing to meet the requirements of the GDPR; and
\n
protect the rights of data subjects.
\n
\n\n
\n\n
A measure is adequate if it considers state of the art, the cost of implementation, the nature, scope, context and purposes of the processing, and the risks of varying likelihood and severity to natural persons’ rights and freedoms.
\n\n
\n\n
Technical measures may include, for example:
\n\n
\n
robust encryption methods for systems and data;
\n
pseudonymisation or aggregation of the data;
\n
access authorisations and restrictions;
\n
user authentication;
\n
firewalls; and
\n
automated deletion concepts.
\n
\n\n
\n\n
Organisational measures may include, for example:
\n\n
\n
the assignment of responsibilities for the effective implementation of data protection requirements;
\n
the implementation of enforceable policies and procedures for handling and documenting data privacy violations and requests for information from data subjects, risk management, third-party vendor management, data transfer management, and the documentation of processing activities;
\n
the implementation of training and controls; and
\n
the establishment of processes to ensure data protection rights, such as revoking consent or requesting erasure of the data.
\n
\n\n
\n\n
3.2 Data Protection Management System
\n\n
\n\n
One effective way to implement PbD in practice is to build a data management and risk assessment programme with responsibilities and a process to systematically identify, evaluate, address and mitigate potential privacy and security risks associated with the collection and processing of personal data. A Data Protection Management System should include the following elements:
\n\n
\n\n
\n
a documented commitment by the company’s management to establish and enforce high standards of data protection for the company, to integrate data protection into the corporate culture and embed the data protection principles in the design and implementation of corporate policies, data protection management systems, business practices, services and products;
\n
\n\n
\n
the appointment of a data protection officer or advisor and the allocation of responsibilities at all levels of the organisation, including business units and functions, for the effective implementation of data protection requirements;
\n
the establishment of a data protection framework with enforceable data protection policies and guidelines that attach appropriate importance to data protection and regulate the collection, processing, transfer, storage and deletion of data, as well as mechanisms to monitor implementation and compliance with standards and rules;
\n
the application of appropriate processes to ensure that data protection principles and requirements are adequately taken into account and integrated into data processing procedures and that the PbD principle is thus lived;
\n
\n\n
\n
the introduction of records of processing activities (“RoPA”);
\n
risk management with risk assessments, compliance checks and, where appropriate, data protection impact assessments;
\n
third-party management and data transfer governance;
\n
regular and documented awareness campaigns and conducting employee trainings; and
\n
regular and documented monitoring and controls through self-assessments and audits to verify the effective implementation of the data protection management programme and compliance with legal requirements and internal policies and directives.
\n
\n\n
\n\n
3.3 Data protection considerations and design strategies
\n\n
\n\n
Applicable laws
\n\n
The controller must clarify the applicable laws and regulations. In particular, organisations outside the EU must determine whether the GDPR applies to them and their activities. The controller should also check whether industry-specific codes of conduct, certification systems, regulatory decisions or guidelines apply to the planned data processing and take into account ethical considerations.
\n\n
\n\n
Involved parties
\n\n
It is then necessary to identify which parties are involved in the data processing or the development and use of the system, service or product, and their role (e.g., controller or processor). Several parties may be jointly responsible for the data processing. Identifying the data controller, i.e., the party that alone or jointly with others decides the means and purposes of data processing, is essential to determine who is responsible and accountable for compliance with data protection requirements under the GDPR.
\n\n
\n\n
Legal justification
\n\n
For all personal data processing, controllers must rely on one of the legal bases set out in Art. 6 and 9 of the GDPR, most used are: the legitimate interest; performance of a contract; legal obligation; or consent.
\n\n
\n\n
In health or medical apps collecting and processing special categories of patient or consumer data, the processing of this data will regularly require the data subjects explicit consent. In this case, consent must be voluntary and specific to each functionality that serves a distinct purpose. Consent must further be based on prior information. In the case of special categories of data, the use of cookies or location data, the data subject must provide explicit consent through positive action, such as downloading the app and ticking a consent box. Also, controllers must have a procedure in place that allows for easy withdrawal of consent and, on the other hand, ensures that in the event of withdrawal, the data collected will not be further processed.
\n\n
\n\n
Proportionality and data minimisation
\n\n
Personal data must be adequate, relevant, and limited to what is necessary for the purposes for which it is processed. This means that systems, apps and devices that store or process personal data should be set up so that only the data necessary for the individual purpose or the proper functioning of the system, app or device is stored and processed.
\n\n
\n\n
The principle of data minimisation can be achieved in different ways, for example, by reducing the amount of personal data collected and processed or by making it more difficult or impossible to assign the data to an individual.
\n\n
\n\n
Depending on the functionalities of the system, app or product and the purpose of the processing, the controller must therefore assess for each data set to be collected whether this data is indeed necessary to fulfil the purpose or whether the purpose can be fulfilled with less data (reduction of data volume) or pseudonymised/anonymised data (making identification difficult or impossible). A further distinction must be made between mandatory data and voluntary data that can be additionally provided for the use of certain functionalities.
\n\n
\n\n
Another measure that the controller can take to achieve the data minimisation requirement is to prevent the linking of personal data stored in different systems for different purposes.
\n\n
\n\n
Transparency and fair processing
\n\n
Personal data must be processed transparently and fairly. Data subjects should have full transparency and control over the processing of their data and understand what data is being processed, why, by whom, where and for how long, and how they can exercise their data protection rights. The processing of personal data should neither violate applicable laws, nor be unexpected to the data subject.
\n\n
\n\n
The privacy notice should be easily accessible to data subjects at any time, before the collection of personal data and throughout the processing. Users of apps, for example, should be notified before the download of the app. The notice should be easy to understand and, where appropriate, translated in different languages.
\n\n
\n\n
Confidentiality and access to personal data
\n\n
Personal data must be kept strictly confidential and may only be provided or disclosed to individuals on a need-to-know basis to fulfil the legitimate purposes for which the data was collected.
\n\n
\n\n
Special attention is required for centralised data management systems. In this case, the controller should establish data access and restriction policies and limit the access through technical means.
\n\n
\n\n
Purpose limitation
\n\n
Personal data shall only be collected for specified, explicit and legitimate purposes and shall not be further processed in a way incompatible with those purposes.
\n\n
\n\n
The controller should determine the processing purposes and communicate them to the data subjects. The functionalities of the system, app or product should be set up to ensure that personal data is only processed for these purposes. The controller must also determine who should have access to which data for which purposes and implement these regulations through technical measures as well as instructions, training and controls.
\n\n
\n\n
If the personal data is to be processed later for purposes other than those communicated, it should be anonymised, unless there is another legal basis for this secondary use. In any case, data subjects should be informed in advance about the use of their data for any secondary purpose and, unless there is another legal basis, their consent should be obtained.
\n\n
\n\n
Data quality
\n\n
The personal data stored must be accurate and, where necessary, kept up to date, and all reasonable steps must be taken to ensure that inaccurate personal data is erased or rectified without delay.
\n\n
\n\n
The controller must have mechanisms in place to ensure that data is accurate at the time of collection and is not unlawfully altered thereafter. There must be a mechanism to correct or delete inaccurate data.
\n\n
\n\n
Data retention
\n\n
Personal data must be kept in a form that permits the identification of data subjects for no longer than is necessary for the purposes for which the personal data is processed, unless regulatory or legal requirements necessitate a longer or shorter retention period.
\n\n
\n\n
The controller should establish a data retention and deletion policy and determine a retention period for each data set based on the purpose of the processing and, where applicable, legal and regulatory retention periods.
\n\n
\n\n
The controller must also define mechanisms, including automated solutions where appropriate, and responsibilities for the effective deletion of data. If the data cannot be deleted, it must be anonymised or, if this is not possible, pseudonymised.
\n\n
\n\n
Data security
\n\n
Personal data must be processed in a manner that ensures appropriate security of the data, including protection against unauthorised or unlawful processing and accidental loss, destruction or damage, using appropriate TOMs. These measures should include data integrity and confidentiality, availability, resilience and traceability, and ensure a level of security appropriate to the risk to the rights of data subjects.
\n\n
\n\n
Appropriate control access mechanisms and authentication measures should be embedded in the system infrastructure to detect and monitor unauthorised access to data. Personal data should be protected by strong and robust state-of-the-art encryption, both in transit and in storage. Special attention is required when data is stored in the cloud.
\n\n
\n\n
Privacy rights
\n\n
Data subjects have various data protection rights, including the right to information, access, rectification and erasure, restriction of processing, data portability and the right to object to automated individual decision-making. They also have the right to complain to the competent supervisory authority if they feel their rights are being violated or their data is not adequately protected. The controller must define processes to ensure that data can be corrected, deleted or transferred at the data subjects’ legitimate request. For apps in particular, the controller should consider whether users should be able to exercise their rights directly through the app, if necessary, by accessing the data and correcting or deleting it if inaccurate.
\n\n
\n\n
Data processing by third parties and cross-border data transfers
\n\n
Depending on the roles of the contributors in the development, management and use of the system, app or product and the data processed, the controller must establish appropriate contractual obligations to ensure data protection.
\n\n
\n\n
Before sharing any personal data with a processor, the controller must verify that the processor implements appropriate TOMs to ensure compliance with the data protection requirements and data subjects’ privacy rights.
\n\n
\n\n
If personal data is to be transferred to third parties outside the European Economic Area (“EEA”) to a country without a formal adequacy decision by the European Commission, appropriate safeguards, such as EU standard contractual clauses (“SCCs”), must be implemented to legitimise cross-border data transfers, unless an exemption pursuant to Art. 49 GDPR applies, such as the explicit consent of the data subject.
\n\n
\n\n
Before transferring the data, the controller, respectively the data exporter, must check whether the destination country ensures an adequate protection level equivalent to that in the EU. If this is not the case, the data exporter should consider storing and processing the data in the EU or an adequate country. If this is not an option, additional contractual, technical and organisational measures must be taken, such as pseudonymisation or encryption of the data while keeping the encryption key in the EU and separate from the service provider.
\n\n
\n\n
4 Conclusion
\n\n
\n\n
Consistent and sustainable compliance with data protection requires the strategic and conceptual integration of data protection principles in all business practices, the organisational structure, the development of rules, IT systems and products.
\n\n
\n\n
To fully exploit the benefits of new technologies and ensure their effectiveness, it is essential to embed fundamental data protection principles into the design of these solutions, taking into account organisational, process and system-related risks, as well as risks to the rights of data subjects.
\n\n
\n\n
PbD is not only required by the GDPR and partly by laws of other countries outside the EEA. It is a prerequisite for the effective and sustainable implementation of data protection, the basis for the smooth functioning of data protection management, and a critical factor in achieving the necessary trust of employees, customers, patients and consumers, public authorities, business partners and other stakeholders in the use of new technologies and the processing of their personal data.
\n\n
\n","datum":"06.07.2021","teasertext":"
Privacy by Design (\"PbD\") is a fundamental requirement for privacy-compliant processing of personal data and is, in principle, a well-known approach. Nevertheless, PbD is often not consistently implemented, in some cases leading to significant consequences and costs for organizations. This article describes the concept of PbD and its practical implementation under the application of the EU General Data Protection Regulation.
\n","preview":"","datei":[],"linkextern":""},{"id":130,"title":"Revised Swiss Data Protection Act - what do companies have to do? (in German)","slug":"das-revidierte-datenschutzgesetz-handlungsbedarf-fuer-unternehmen","link":"/en/news-knowledge/das-revidierte-datenschutzgesetz-handlungsbedarf-fuer-unternehmen","titel":"Revised Swiss Data Protection Act - what do companies have to do? (in German)","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
Das revidierte Datenschutzgesetz - Handlungsbedarf für Unternehmen?
\n\n
\n\n
Das Schweizer Parlament hat im September 2020 das revidierte Datenschutzgesetz verabschiedet, welches voraussichtlich 2022 in Kraft treten wird. Daniela Fábián Masoch, Rechtsanwältin und Datenschutzexpertin, erklärt, welche Pflichten auf Unternehmen zukommen und wie sich diese vorbereiten können.
\n\n
\n\n
Datenschutz hat in den vergangenen Jahren stark an Bedeutung gewonnen. Konsumenten, Kunden, Patienten und Arbeitnehmer, aber auch Führungskräfte und Behörden sind zunehmend sensibilisiert und haben hohe Erwartungen an den Schutz von Personendaten. Infolgedessen wurden die Datenschutzgesetze weltweit entsprechend verschärft.
\n\n
\n\n
Unter dem revidierten Schweizer Datenschutzgesetz (nDSG) bleibt die Bearbeitung von Personendaten grundsätzlich erlaubt. Unternehmen müssen aber in Zukunft eine ganze Reihe neuer oder erweiterter Vorschriften befolgen.
\n\n
\n\n
Welche neuen Pflichten kommen auf Unternehmen zu?
\n\n
\n\n
Erweiterte Informationspflicht: Künftig müssen Unternehmen betroffene Personen bei der Beschaffung von Personendaten informieren (bisher nur besonders schützenswerte Daten und Persönlichkeitsprofile), wobei das Gesetz Mindestangaben vorschreibt. Konkret bedeutet dies, dass Unternehmen ihre Datenschutzerklärungen überprüfen und ggf. anpassen oder komplett neu erstellen und den betroffenen Personen mitteilen müssen.
\n\n
\n\n
Privacy by Design (PbD): Unternehmen sind künftig verpflichtet, geplante Datenbearbeitungen so auszugestalten, dass die datenschutzrechtlichen Vorschriften und die Grundsätze der Datenbearbeitung eingehalten werden. PbD ist jedoch nicht bloss als neue Verpflichtung zu verstehen, sondern vielmehr als Grundvoraussetzung für einen verantwortungsvollen und effektiven Datenschutz. Eine wirksame Umsetzung der Datenschutzgrundsätze setzt voraus, dass Unternehmen proaktiv handeln und potenzielle Risiken für die Privatsphäre von betroffenen Personen antizipieren.
\n\n
\n\n
Datenschutz-Folgenabschätzung: Unternehmen müssen künftig für Datenbearbeitungen, die ein hohes Risiko für die Persönlichkeit oder die Grundrechte der betroffenen Person mit sich bringen können, eine Datenschutz-Folgenabschätzung durchführen. Sie müssen die Risiken für die betroffene Person vorgängig bewerten und geeignete Massnahmen zum Schutz ihrer Persönlichkeit und Grundrechte ergreifen. Dies kann beispielsweise bei einer umfangreichen Bearbeitung von besonders schützenswerten Daten der Fall sein, aber auch bei der Verwendung neuer Technologien.
\n\n
\n\n
Verzeichnis der Bearbeitungstätigkeiten: Unternehmen sind neu grundsätzlich verpflichtet, ein Verzeichnis ihrer Bearbeitungstätigkeiten zu führen. Ein solches Verzeichnis kann, wenn es sorgfältig geführt und mit zusätzlichen Informationen ergänzt wird, durchaus einen Vorteil haben, nämlich als Grundlage für Konformitätsprüfungen und Datenschutz-Folgenabschätzungen dienen.
\n\n
\n\n
Meldung von Verletzungen der Datensicherheit: Wie bereits unter der EU-Datenschutz-Grundverordnung (DSGVO) müssen Unternehmen in Zukunft Verstösse der Datensicherheit (wie z. B. unberechtigte Datenzugriffe) je nach Risiko dem Eidgenössischen Datenschutz- und Öffentlichkeitsbeauftragten (EDÖB) melden und die betroffenen Personen informieren.
\n\n
\n\n
Welche Sanktionen drohen Unternehmen, wenn sie die gesetzlichen Anforderungen nicht einhalten?
\n\n
\n\n
Im Unterschied zur DSGVO wird grundsätzlich nicht das Unternehmen, sondern die verantwortliche natürliche Person mit Bussgeldern von bis zu CHF 250'000 belegt. Strafbar macht sich insbesondere, wer gegen die Informations- oder Auskunftspflicht verstösst oder die Sorgfaltspflichten verletzt, namentlich die Mindestanforderungen an die Datensicherheit nicht einhält, Personendaten ins Ausland bekanntgibt oder die Datenbearbeitung einem Auftragsbearbeiter überträgt, ohne die gesetzlichen Anforderungen zu erfüllen. Bussen setzen allerdings eine vorsätzliche Handlung voraus und werden in den meisten Fällen nur auf Antrag verhängt.
\n\n
\n\n
Handlungsbedarf für Unternehmen?
\n\n
\n\n
Da das nDSG keine Übergangsfristen vorsieht, sollten Unternehmen frühzeitig prüfen, inwieweit ihre internen Regelungen und Prozesse betreffend Datenmanagement mit den neuen Anforderungen übereinstimmen.
\n\n
\n\n
Insbesondere müssen Konzepte wie Privacy by Design umgesetzt und Prozesse eingeführt werden, die eine gesetzeskonforme Löschung oder Vernichtung der Daten und die Datenportabilität unterstützen sowie die Durchführung von Datenschutz-Folgenabschätzungen und die rechtzeitige Meldung von Datensicherheitsverstössen sicherstellen. Datenschutzerklärungen müssen überprüft und gegebenenfalls an die Anforderungen des nDSG angepasst werden. Verzeichnisse, die derzeit Datensammlungen dokumentieren, müssen neu strukturiert werden, um zukünftig Bearbeitungsaktivitäten zu erfassen.
\n\n
\n","datum":"26.02.2021","teasertext":"
In September 2020, the Swiss Parliament adopted the revised Data Protection Act, that is expected to enter into force in 2022. In an article published in the Bilanz magazine, Daniela Fábián Masoch explains the new obligations for companies and what they can do in order to be prepared. Please note that the publication is only available in German.
\n","preview":"","datei":[],"linkextern":""},{"id":131,"title":"EU personal data transfers 2021: Planning for a year of increased scrutiny","slug":"eu-personal-data-transfers-2021-planning-for-a-year-of-increased-scrutiny","link":"/en/news-knowledge/eu-personal-data-transfers-2021-planning-for-a-year-of-increased-scrutiny","titel":"EU personal data transfers 2021: Planning for a year of increased scrutiny","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
By Dan Goldstein, Co-Founder, Tueoris, LLC and Daniela Fábián Masoch, Founder FABIAN PRIVACY LEGAL
\n\n
\n\n
As 2021 begins, ex-EU transfers of personal data continue to pose a challenge for data privacy professionals. While new Standard Contractual Clauses (“SCCs”) appear promising, the lingering impact of the Schrems II decision along with the European Data Protection Board’s Draft Recommendations on Measures that Supplement Transfer Tools1 (the “EDPB Recommendations”) are likely to leave exporters and importers of European resident personal data spending valuable time focused on data transfer risk mitigation strategies.
\n\n
\n\n
Across Europe, Data Protection Authorities maintain a consistent view that countries with laws or practices that allow government “generalized” access to the content of electronic communications do not provide privacy safeguards essentially equal to those in EU member states. Such laws or practices are viewed as impinging on the effectiveness of safeguards contained in the EU General Data Protection Regulation (“GDPR”). Parties relying on SCCs or Binding Corporate Rules (“BCRs”) for transfers to such countries must identify and implement, on a case-by-case basis, supplementary measures that elevate protections to a level equal to EU law.
\n\n
\n\n
Prior to determining whether such measures will be adequate, parties to a transfer should – in line with the EDPB Recommendations – undertake to ascertain a complete view of the data transfers taking place within the lifecycle of defined processing activities. Upon gaining a holistic view of these data flows, the parties should then conduct Transfer Impact Assessments (“TIAs”) to determine risks the transfers to data importers and sub-processors pose to the data subjects, as well as compliance risks faced by the parties to the transfers. Where those TIAs uncover risks of government access to personal data, supplementary controls will be necessary. However, controls considered adequate by EU authorities may be limited.
\n\n
\n\n
Know Your Data Flows
\n\n
\n\n
The logical starting point for compliant ex-EU personal data transfers is to fully understand where EU personal data is flowing within and outside of your organization. The EDPB acknowledges in its Recommendations that “recording and mapping all transfers can be a complex exercise”, but also stresses that awareness of personal data flows is “necessary to ensure that it is afforded an essentially equivalent level of protection wherever it is processed”.
\n\n
\n\n
Since the GDPR came into effect in 2018, most organizations processing EU resident personal data have spent time and effort to understand the flow of such data, typically by recording the characteristics of processing activities in accordance with GDPR Article 30. However, Article 30 records often fall short in capturing a holistic view of personal data flows across an organization’s third-party ecosystem and the countries in which those parties are located.
\n\n
\n\n
Conducting a thorough and detailed exercise to create visual depictions of data flows (i.e., data mapping) enables the identification of transfers not only to ex-EU importers, but also subsequent third-party transfers throughout the personal data lifecycle .
\n\n
\n\n
To design and implement reasonable security controls, the organization must first understand the nature of the data that must be secured. A successful data mapping initiative will not only map the flow of personal data, but also identify and depict the specific personal data elements involved in the process, facilitating the development of tailored safeguards necessary for each transfer throughout the data lifecycle. These detailed data maps become a highly valuable tool, not only to determine security controls commensurate to the risks to the data subjects, but also to demonstrate appropriate diligence to regulatory authorities should transfers come under scrutiny.
\n\n
\n\n
Transfer Impact Assessments
\n\n
\n\n
Overview
\n\n
\n\n
In line with the EDPB Recommendations, it has become imperative to conduct a TIA prior to transferring EU resident personal data to parties in non-adequate countries2. TIAs must be conducted for prospective transfers of EU data to recipients in non-adequate countries, as well as current, ongoing transfers (and should assess any onward transfers). As such, in addition to conducting TIAs for transfers identified in the data mapping exercise, a TIA should be triggered prior entering into contracts with service providers that will require ex-EU transfers of EU personal data.
\n\n
\n\n
A thorough TIA will consider numerous risk factors, however whether the laws or practices of the country where the importer is located impinge on the effectiveness of the safeguards of the transfer tool being used (e.g., SCCs) is of primary importance to EU authorities. For transfers of EU personal data to the US, the prevailing EU view is that Section 702 of the U.S. Foreign Intelligence Surveillance Act does not adequately safeguard privacy rights under EU law. Thus, transfers being made to US recipient using transfer mechanisms such as SCCs or BCRs must be supplemented with additional measures to limit government access. Notably, even considering what may be viewed as a rather black or white view of Section 702, the EDPB Recommendations do recognize that an organization’s TIAs should consider the context of the specific transfer – an important point, as different activities will carry widely different risks of government access.
\n\n
\n\n
Conducting the TIA
\n\n
\n\n
TIAs must be conducted diligently and be thoroughly documented, as Data Protection Authorities will expect a TIA to be available if a transfer comes under their scrutiny. Developing and implementing a standard and repeatable TIA methodology supports outcomes that meet EU authorities’ expectations.
\n\n
\n\n
A TIA which includes a series of questions with “scored” answers allows the organization to consistently quantify results and create requirements for completed TIAs that fall within various score ranges. For example, a score within a defined low-risk range might allow a transfer to go ahead without further action. A score within a defined medium-risk range might require implementation of supplementary measures to bring the level of protection to an EU level, and review and approval by the Chief Privacy Officer. A score within a defined high-risk range might require review by the Chief Privacy Officer and may lead to a decision to suspend or stop the transfer.
\n\n
\n\n
The EDPB emphasizes that the TIA should primarily focus on the laws of the country to which the transfer will be made, and, specifically, on factors indicating whether government authorities in that country will seek access to the data. In addition to these objective factors, it is useful – in order to obtain an overall risk score indicating appropriate technical, contractual and organizational measures – to consider other aspects of the data and transfer as well (“context”). This context helps to establish relative likelihood of government requests for EU personal data for transfers made for widely disparate purposes. For example, a transfer initiated by a data subject to manage their customer preferences will pose different risks of government access than a transfer of a large volume of personal data of EU resident social media users to a US importer.
\n\n
\n\n
In establishing the TIA risk criteria, consideration should be given to additional factors such as:
\n\n
\n\n
\n
Purpose of the transfer;
\n
Exporting party (category);
\n
Data subject type;
\n
Types of data transferred;
\n
Volume of data transferred;
\n
Manner in which access is provided to the importer (e.g., limited push or unlimited pull);
\n
Frequency of transfers;
\n
Onward transfers (including category of sub-processor and purpose); and
\n
Security controls in transit;
\n
Importer security controls;
\n
History of government access requests to the importer; and
\n
History of government access requests to similarly situated importers.
\n
\n\n
\n\n
While the EDPB does not place much value in evaluation of historical government requests to the importing organization or other similarly situated organizations, these factors should be considered so that the parties conducting the TIA can gain an internal understanding of the actual risks of government requests and develop an appropriate response strategy.
\n\n
\n\n
Remediating Identified Risks
\n\n
\n\n
Upon completing the TIA and ascertaining the risk score, along with defined requirements aligned to the scores, it may be necessary to take steps to remediate risks and, as the EDPB Recommendations state, “bring the level of protection of the data transferred up to the EU standard of essential equivalence”.
\n\n
\n\n
Technical Controls
\n\n
\n\n
Significant attention has been focused on encryption of personal data in transit to, and at rest in, the recipient in the ex-EU country. The EDPB Recommendations specify that in those circumstances where encryption may be appropriate, it will only be considered an effective control if the encryption keys are maintained by the EU-based exporter, other entities in the EEA, or an ex-EU country with an adequacy designation. In other words, if a US-based importer holds the encryption key, the control will likely not be considered effective by EU authorities.
\n\n
\n\n
The Recommendations call out the common scenario3 in which a data importer – in a country in which the government may access the personal data (e.g., the US) – uses EU personal data to provide services to the EU controller (e.g., payroll or other HR-focused services). The EDPB takes the position that if the importer in such a scenario is able to use the data in the clear, even encryption in transit and at rest will not provide an adequate level of protection of the rights of the data subjects, as the government could compel production of the data.
\n\n
\n\n
The logical outcome of strict adherence to this position appears to be a new level of EU data localization. In such instances, exporters and importers may need to evaluate alternatives (e.g., storage and processing of data in the EEA or in an adequate country). If data localization is not an option, the parties may consider a risk-based decision to move forward with the transfer, implementing supplemental organizational and contractual controls4 in order to continue business operations in a manner beneficial to shareholders, employees and other interested parties. Where the risks are deemed to be too high, the parties may need to either suspend or stop further transfers.
\n\n
\n\n
Where appropriate, depending on the context of the transfer, pseudonymization may also present an adequate control. However, in accordance with the EDPB Recommendations, any additional information that would allow the identification of individuals whose personal data is transferred, must be held by the exporter either in the EU or other adequate country (this is a common scenario, for example, in the conduct of clinical trials). In addition, the parties should establish in the TIA that the individuals cannot be identified by public authorities by cross-referencing the pseudonymized personal data with additional information that the authorities may possess.
\n\n
\n\n
Contractual Limitations
\n\n
\n\n
Based on the context of the transfers taking place, contractual provisions may comprise additional controls supporting the compliant transfer of EU personal data. Contractual provisions may include:
\n\n
\n\n
\n
Limitations on the data being transferred, for example, only specified data subjects or data elements;
\n
Requirements for technical measures which must be implemented for the transfers to take place;
\n
A commitment to inform the EU data controller of government requests for personal data and – where commercially feasible and permitted by applicable law – to inform data subjects of such requests; and/or
\n
A binding commitment by the importer to challenge government requests, including efforts to delay response to requests pending resolution of the challenge.
\n
\n\n
\n\n
Contractual limitations should be drafted considering other contractual obligations that may already be in place, for example in SCCs or in an organization’s BCRs.
\n\n
\n\n
Administrative Controls
\n\n
\n\n
Administrative controls represent a further means for organizations importing personal data of EU residents to a non-adequate country to safeguard such personal data – where appropriate – from government access. Controls may include updating internal privacy policies and procedures to include detailed actions in the event of government requests. Such provisions may detail, for example, the process for the intake and response to requests, including review by appropriate internal stakeholders in the EU and in the country from which the government request is made. They may also document the organization’s commitments to inform data subjects of such requests and, where appropriate, to challenge government requests.
\n\n
\n\n
In addition, personnel who may be tasked with the intake, review and disposition of requests should receive training on internal procedures for managing government requests for access to personal data.
\n\n
\n\n
Final Thoughts
\n\n
\n\n
As we enter a new year, the state of ex-EU data transfers remains a moving target. While anticipated new SCCs are promising – particularly the processor-to-processor and processor-to-controller SCCs – they do not mitigate the risk of access to EU personal data by governments in non-EU countries. The EDPB Recommendations provide highly valuable guidance, but ultimately include some conclusions that point to EU data localization. In order to minimize risks associated with data transfers, organizations should (in line with EDPB Recommendations) undertake detailed data mapping exercises for processing activities which include transfers of EU resident personal data and conduct detailed TIAs to identify risks related to the transfers. A consistent approach to mapping and TIAs will not only provide information necessary to implement appropriate data protection controls, but will also demonstrate to EU regulatory authorities that your organization takes compliance with transfer rules seriously, and has taken appropriate measures to safeguard the privacy rights of EU residents.
[2] The EDPB Recommendations state that, “you must assess. . . if there is anything in the law or practice of the third country that may impinge on the effectiveness of the appropriate safeguards of the Article 46 GDPR transfer tool you are relying on, in the context of your specific transfer.”
[4] Such supplemental controls may include, for example, a documented commitment to challenge compelled government disclosure of personal data.
\n","datum":"26.01.2021","teasertext":"
As 2021 begins, ex-EU transfers of personal data continue to pose a challenge for data privacy professionals. The following article explains what organizations can do in order to minimize risks associated with data transfers.
\n","preview":"","datei":[],"linkextern":""},{"id":132,"title":"The EU Commission launches public consultation on revised SCC","slug":"die-europaeische-kommission-veroeffentlicht-entwurf-der-revidierten-standardvertragsklauseln","link":"/en/news-knowledge/die-europaeische-kommission-veroeffentlicht-entwurf-der-revidierten-standardvertragsklauseln","titel":"The EU Commission launches public consultation on revised SCC","text":"
On 12 November 2020, the EU Commission launched public consultation (until 10 December) on revised Standard Contractual Clauses (SCC). Please click here to download the Commission implementing decision and the Annex with the proposed clauses.
\n","datum":"12.11.2020","teasertext":"
On 12 November 2020, the EU Commission launched public consultation (until 10 December) on revised Standard Contractual Clauses (SCC). Please click here to download the Commission implementing decision and the Annex with the proposed clauses.
\n","preview":"","datei":[],"linkextern":""},{"id":133,"title":"The EDPB releases recommendations on cross-border data transfers","slug":"the-edpb-releases-recommendations-on-cross-border-data-transfers","link":"/en/news-knowledge/the-edpb-releases-recommendations-on-cross-border-data-transfers","titel":"The EDPB releases recommendations on cross-border data transfers","text":"
On 11 November 2020, the EDPB released two recommendations regarding cross-border data transfers. Public consultation is running until 30 November 2020.
\n\n
\n\n
\n
Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data (these recommendations provide data exporters with a series of steps to follow, potential sources of information, and some examples of supplementary measures that could be put in place), and
\n
\n\n
\n\n
\n
Recommendations 02/2020 on the European Essential Guarantees for surveillance measures (these recommendations provide elements to examine whether surveillance measures allowing access to personal data by public authorities in a third country can be regarded as a justifiable interference or not).
\n
\n\n
\n\n
To download the recommendations, please click on the following links:
On 11 November 2020, the EDPB released two recommendations regarding cross-border data transfers. Public consultation is running until 30 November 2020.
\n","preview":"","datei":[],"linkextern":""},{"id":153,"title":"Privacy by Design as an opportunity for companies (in German)","slug":"privacy-by-design-as-an-opportunity-for-companies","link":"/en/news-knowledge/privacy-by-design-as-an-opportunity-for-companies","titel":"Privacy by Design as an opportunity for companies (in German)","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
Privacy by Design als Chance für Unternehmen
\n\n
\n\n
Das Schweizer Parlament hat kürzlich das revidierte Datenschutzgesetz verabschiedet. Neu gilt der Grundsatz des sogenannten «Privacy by Design». Die korrekte Umsetzung dieses Prinzips ist die Grundvoraussetzung für einen verantwortungsvollen und effektiven Datenschutz und trägt entscheidend zum Erfolg eines Unternehmens bei. Daniela Fábián, Rechtsanwältin und Datenschutzexpertin, erläutert den Grundsatz und seine praktische Umsetzung.
\n\n
\n\n
Datenschutz hat in den vergangenen Jahren stark an Bedeutung gewonnen. Konsumenten, Kunden, Patienten und Arbeitnehmer sowie Unternehmensführer und Behörden sind zunehmend sensibilisiert und haben höhere Erwartungen an den Schutz von Personendaten. Infolgedessen wurden Datenschutzgesetze weltweit entsprechend verschärft.
\n\n
\n\n
Während viele Unternehmen bis vor Kurzem kaum Ressourcen für den Datenschutz bereitgestellt haben, ist den meisten Unternehmen inzwischen bewusst, dass Datenschutz ein ernst zu nehmendes Thema ist. Grund hierfür sind nicht nur drohende Sanktionen und Reputationsverlust im Falle einer Verletzung der Datenschutzvorschriften, sondern dass Unternehmen verstanden haben, dass sie die Vorteile neuer Technologien wie Blockchain, Machine Learning, Künstliche Intelligenz, Internet of Things oder autonomes Fahren nur dann voll ausschöpfen können, wenn sie gleichzeitig die Erwartungen der betroffenen Personen erfüllen, ihr Vertrauen gewinnen sowie deren Privatsphäre respektieren.
\n\n
\n\n
Verantwortungsvoller und effektiver Datenschutz setzt voraus, dass Unternehmen die grundlegenden Datenschutzgrundsätze wie Datenminimierung und Transparenz sowie technische Sicherheitsmassnahmen wie Pseudonymisierung oder Verschlüsselung bereits bei der Konzeption von digitalen Lösungen und generell in jegliche Datenbearbeitung integrieren. Diesen Ansatz nennt man «Privacy by Design», kurz «PbD».
\n\n
\n\n
Das Schweizer Parlament hat nun diesen Grundsatz unter dem Titel «Datenschutz durch Technik und datenschutzfreundliche Voreinstellungen» im revidierten Datenschutzgesetz verankert.
\n\n
\n\n
Was bedeutet Privacy by Design für Unternehmen?
\n\n
\n\n
PbD ist nicht bloss eine neue Verpflichtung für Verantwortliche. PbD ist vielmehr Grundvoraussetzung für verantwortungsvollen Datenschutz. Um Datenschutzgrundsätze wirksam umzusetzen, müssen Unternehmen proaktiv handeln und potenzielle Risiken für die Privatsphäre von betroffenen Personen antizipieren.
\n\n
\n\n
Unternehmen, die z. B. ein neues Datenmanagementsystem einführen, eine App entwickeln, sensible Daten in einer Cloud speichern, Überwachungssysteme im Unternehmen einführen oder die Bearbeitung von Personendaten an Dritte ins Ausland verlagern wollen, müssen sich schon früh über potenzielle Auswirkungen und Risiken für die betroffenen Personen und deren Daten im Klaren sein.
\n\n
\n\n
Bei der Entwicklung einer App z. B. muss ein Unternehmen bereits in der Designphase prüfen, ob und wenn ja, welche Personendaten für die Nutzung erforderlich sind und wie technisch sichergestellt wird, dass nicht mehr Daten als erforderlich erhoben werden. Wo und wie lange werden die Daten gespeichert, in der App oder auf einem zentralen Server, im In- oder Ausland? Wer soll auf die Daten Zugriff haben und warum? Sind Dienstleister involviert und wenn ja, wie wird sichergestellt, dass auch sie die Datenschutzvorschriften einhalten? Wie wird technisch sichergestellt, dass die Nutzer vor dem Download der App die Datenschutzerklärung sehen und gegebenenfalls in die Datenbearbeitung einwilligen sowie ihre Rechte geltend machen können, dass die Daten nicht für andere Zwecke bearbeitet werden und bei Bedarf gelöscht oder herausgegeben werden können? Welche technischen Massnahmen sind erforderlich, um die Daten vor Cyberrisiken zu schützen?
\n\n
\n\n
Mit diesem Ansatz kann das Unternehmen nicht nur die Einhaltung der gesetzlichen Anforderungen sicherstellen, sondern bereits im Vorfeld strategische und operative Entscheidungen treffen und Geschäftsprozesse effizient umsetzen. Dazu können z. B. die Speicherung von Daten auf Servern in der Schweiz statt in den USA oder der Kauf von Software mit integriertem Datenschutz gehören.
\n\n
\n\n
Wie können Unternehmen Privacy by Design in der Praxis umsetzen?
\n\n
\n\n
Eine wirksame Möglichkeit, PbD in der Praxis umzusetzen, ist ein Datenschutzmanagement- und Risikobewertungsprogramm mit Verantwortlichkeiten und einem Prozess zur systematischen Identifizierung, Bewertung, Behandlung und Minderung potenzieller Datenschutz- und Sicherheitsrisiken im Zusammenhang mit der Datenbearbeitung aufzubauen. Durch systematische Konformitäts- und Risikoprüfungen können Unternehmen notwendige und geeignete Massnahmen bestimmen, um die Einhaltung der Datenschutzgrundsätze sicherzustellen und Risiken für die betroffenen Personen, und damit verbunden für das Unternehmen selbst, zu reduzieren.
\n\n
\n\n
Privacy by Design ist ein entscheidender Faktor für den Aufbau und die Aufrechterhaltung von Vertrauen, Wettbewerbsfähigkeit und Erfolg auf dem Markt. Unternehmen sollten PbD also durchaus als Chance begreifen.
\n\n
\n","datum":"31.10.2020","teasertext":"
The Swiss Parliament recently adopted the revised Data Protection Act, which newly introduces the concept of “privacy by design”. The correct implementation of this concept is the basis for responsible and efficient data protection and a decisive factor for the success of each company. In an article published in the Bilanz (Fokus Business Success) magazine, Daniela Fábián Masoch explains the concept and its practical implementation. Please note that the publication is only available in German.
\n","preview":"","datei":[],"linkextern":""},{"id":128,"title":"The new Swiss Data Protection Act - the most significant changes for companies","slug":"das-neue-schweizer-datenschutzgesetz-die-wichtigsten-neuerungen-fuer-unternehmen","link":"/en/news-knowledge/das-neue-schweizer-datenschutzgesetz-die-wichtigsten-neuerungen-fuer-unternehmen","titel":"The new Swiss Data Protection Act - the most significant changes for companies","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
On 25 September 2020, the Swiss Parliament adopted the revised Federal Act on Data Protection (FADP-new).1 The Federal Council will decide on the entry into force after the 100-day referendum period has expired. This article summarises the most significant changes for companies.2
\n\n
\n\n
At a glance
\n\n
\n\n
\n
The basic concept of “permission of data processing subject to prohibition” (i.e. prohibition if the data processing leads to an “unlawful violation of the personality of a person”) remains unchanged. Consent to the processing of personal data is still generally not required, even for profiling and the processing of sensitive personal data. The principles of data processing also remain largely unchanged.
\n
\n\n
\n\n
\n
Legal entities are no longer protected; only natural persons are protected under the FADP-new.
\n
\n\n
\n\n
\n
The scope of the FADP-new covers actions that have an effect in Switzerland, even if they are initiated abroad.
\n
\n\n
\n\n
\n
The definitions of “controller of the data file”, “personality profile” and “data file” have been deleted; the definitions of “profiling”, “high-risk profiling” and “data security breach” have been introduced. Genetic and biometric data as well as data on ethnic origin, are considered to be sensitive personal data under the FADP-new.
\n
\n\n
\n\n
\n
The concepts of “privacy by design” and “privacy by default” are now enshrined in the law, as is already the case in the EU General Data Protection Regulation (GDPR).
\n
\n\n
\n\n
\n
Data security is the responsibility of the controller as well as the processor. A risk-based approach is introduced.
\n
\n\n
\n\n
\n
Data processing by processors remains largely unchanged. Under the FADP-new, the processor may only assign the processing to a sub-processor with prior authorisation by the controller.
\n
\n\n
\n\n
\n
The appointment of a data protection advisor remains voluntary. It can be an advantage when it comes to performing a data protection impact assessment.
\n
\n\n
\n\n
\n
Under the FADP-new, both the controller and the processor must keep an inventory of their processing activities. This inventory does not have to be declared to the Federal Data Protection and Information Commissioner (FDPIC) (up to now, the controller generally needed to declare data files to the FDPIC).
\n
\n\n
\n\n
\n
Companies based outside Switzerland who process personal data of persons in Switzerland will have to designate a representative in Switzerland.
\n
\n\n
\n\n
\n
The requirements for cross-border disclosure of personal data remain largely unchanged. Under the FADP-new, the Federal Council bindingly determines whether the legislation of a state or an international body guarantees an adequate level of protection.
\n
\n\n
\n\n
\n
The duty of information has been extended to the collection of all kinds of personal data (until now it was only applicable to the collection of sensitive personal data and personality profiles) and also includes automated individual decision-making.
\n
\n\n
\n\n
\n
Under the FADP-new, the controller must carry out a data protection impact assessment if the intended data processing may lead to a high risk for the data subject.
\n
\n\n
\n\n
\n
In the future, the controller must notify the FDPIC of data security breaches.
\n
\n\n
\n\n
\n
Under the FADP-new, data subjects have the right to data portability.
\n
\n\n
\n\n
\n
The powers of the FDPIC are extended. In the future, the FDPIC can order a number of administrative measures.
\n
\n\n
\n\n
\n
The criminal provisions have been significantly tightened, with fines of up to 250 000 Swiss francs for private persons (i.e. not companies!), but only for violations in certain areas, in particular for the breach of obligations to provide access and information and to cooperate, for the violation of duties of diligence with respect to the requirements for cross-border disclosure of personal data, the appointment of a processor and for failure to comply with the minimum data security requirements. Fines are only applicable to violations that result from a wilful act and are in most cases, only imposed upon the filing of a complaint.
The FADP-new aims to protect personal privacy and the fundamental rights of natural persons whose personal data is processed. Under the current law, legal entities are also protected. By cancelling the protection of legal entities, the FADP-new aligns with the GDPR, that also protects only natural persons.
\n\n
\n\n
The FADP-new also regulates the territorial scope. According to art. 3, the law applies to actions that have an effect in Switzerland, even if they are initiated abroad.
Various definitions are now aligned with the GDPR.
\n\n
\n\n
The definition of “personal data” is limited to “all information relating to an identified or identifiable natural person”. The term “data subject” only refers to natural persons whose data is processed.
\n\n
\n\n
Concerning the identifiability, the “relative approach” is maintained. According to the Federal Council Dispatch on the Federal Act on the complete revision of the Federal Act on Data Protection and the modification of other federal enactments5, the mere theoretical possibility to identify a person is, as under current law, not sufficient to presume that a person is identifiable. The Federal Council already stipulated in its Dispatch to the FADP of 19886 that no identifiability is given if “the effort necessary to identify a data subject is so great that, according to general life experience, it cannot be expected that any interested person should undertake such effort”. “It must rather be considered what means can be reasonably employed to identify a person and be determined whether the employment of such means is reasonable under the given circumstances, for instance in terms of time and cost. In doing so, the technologies available at the time of processing and their further development must be taken into account. The law does not apply to anonymised data, if a re-identification by third parties is impossible (the data has been completely and irreversibly anonymised) or if a re-identification would only be possible with a great effort that no interested person would undertake. The same applies to pseudonymised data”.7
\n\n
\n\n
\n
The definition of “sensitive personal data” has been extended to include “data on ethnic origin”, “genetic data” and “biometric data which uniquely identifies a natural person”. While it is made clear that biometric data must uniquely identify a natural person, the same addition has been deleted for genetic data in the procedure of the resolution of differences.
\n
\n\n
\n\n
\n
The definitions of “controller of the data file”, “personality profile” and “data file” have been deleted. The following new definitions have been introduced:\n
\n
“controller”: a private person or federal body that alone or jointly with others decides on the purpose and the means of the processing.
\n
“processor”: a private person or federal body that processes personal data on behalf of the controller.
\n
“profiling”: any form of automated processing of personal data consisting in the use of such data to evaluate certain personal aspects relating to a natural person, in particular, to analyse or predict aspects relating to that natural person's performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, whereabouts or movements.
\n
“high-risk profiling”: profiling which involves a high risk to the personality or fundamental rights of the data subject, by creating a link between data which allows an assessment of substantial aspects of the personality of a natural person.
\n
“data security breach”: a security breach which leads to an unintentional or unlawful loss, deletion, destruction or modification of personal data or to personal data being disclosed or made accessible to unauthorised persons.
\n
\n
\n
\n\n
\n\n
3. Principles of data processing
\n\n
\n\n
The principles of data processing remain materially largely unchanged.
\n\n
\n\n
\n
Art. 6 para. 4 now explicitly stipulates that personal data must be destroyed or anonymised as soon as it is no longer needed with regard to the purpose of the processing. To comply with this obligation, the controller must determine retention periods in advance.
\n
\n\n
\n\n
\n
The definition of “personality profile” is replaced by “profiling” (see description under “definitions”). The terminology of profiling was the sticking point on which the Councils disagreed until the very end and which was also largely discussed in the media. In the end, the conciliation committee followed the proposal of the Council of States and decided to introduce the definition of “high-risk profiling” (which is comparable to the current concept of the personality profile), with the consequence that if consent is required for this type of profiling, it must be explicit. It remains to be seen how companies will assess the risk level of profiling in practice. In any case, this exercise will certainly be a challenge for companies.
\n
\n\n
\n\n
It should be noted that the FADP-new does not introduce a consent requirement for high-risk profiling, but only requires that consent, if at all required as a justification under art. 31 FADP-new must be given explicitly. It is worth recalling that the basic concept of both the FADP and the FADP-new is different from that of the GDPR. While under the GDPR, a legal ground is always required for the processing of personal data (art. 6 and 9 GDPR), the processing of personal data under the FADP and FADP-new is, in principle, permitted as long as the personality of the data subjects is not unlawfully violated. Hence, the \"permission principle subject to prohibition\" continues to apply under the FADP-new, while the GDPR applies the \"prohibition principle subject to permission\".
\n\n
\n\n
4. Privacy by design and privacy by default
\n\n
\n\n
The principles of “privacy by design” and “privacy by default”, as known from the GDPR, are now also enshrined in the FADP-new. In today's practice, the controller is already required to set up data processing activities in a manner that complies with the data protection regulations and the principles of data processing. The FADP-new explicitly regulates that the controller must ensure, through appropriate pre-defined settings, that the processing of personal data is limited to the minimum required by the purpose unless the data subject determines otherwise (privacy by default).
\n\n
\n\n
5. Data security
\n\n
\n\n
The slightly revised article 8 FADP-new stipulates that both the controller and the processor must ensure, through adequate technical and organisational measures, a level of data security that appropriately addresses the risk. This means that a risk-based approach is introduced. “The higher the risk of a data security breach, the higher the requirements for the measures to be taken”.8 The Federal Council will issue provisions on the minimum requirements for data security.
\n\n
\n\n
6. Data processing by processors
\n\n
\n\n
Art. 9 FADP-new essentially adopts the current article 10a FADP. The rather unfortunate term “third parties” is replaced by “processors”. The processing of personal data may still be assigned by agreement or by legislation to a processor if (a) the data is processed only in a manner permitted for the controller itself, and (b) no statutory or contractual duty of confidentiality prohibits the assignment. The controller must ensure in particular that the processor can guarantee data security. As under the GDPR, the processor may only assign the processing to a sub-processor with the prior authorisation by the controller.
\n\n
\n\n
7. Data protection advisor
\n\n
\n\n
Controllers may, but are not required to, appoint a data protection advisor as a contact point for the data subjects and the relevant authorities responsible for data protection matters in Switzerland. The data protection advisor has the duty to train and advise the controller in matters of data protection and to participate in the enforcement of data protection regulations.
\n\n
\n\n
Contrary to the current FADP, the data protection advisor is not responsible for supervising the company’s internal compliance with data protection regulations, nor for maintaining an inventory of data files.
\n\n
\n\n
Private controllers who appointed a data protection advisor have an advantage when they need to perform a data protection impact assessment according to art. 22 FADP-new by reason of their processing activities, provided that they consult their data protection advisor. In this case, they can abstain from consulting the FDPIC.[9] The controller must consult the FDPIC before the processing when the data protection impact assessment shows that the processing presents a high risk for the personality or fundamental rights of the data subject, despite the measures envisaged by the controller. The controller may abstain from consulting the FDPIC if the data protection advisor (a) performs his or her function towards the controller in a professionally independent manner and without being bound by instructions, (b) does not perform any activities which are incompatible with his or her tasks as data protection advisor, (c) possesses the necessary professional knowledge, and (d) if the controller publishes the contact details of the data protection advisor and communicates them to the FDPIC.
\n\n
\n\n
8. Inventory of processing activities
\n\n
\n\n
As under the GDPR, controllers and processors must each keep an inventory of their processing activities. The FADP-new lists the minimum information that needs to be contained in such inventories. The inventory of processing activities does no longer have to be declared to the FDPIC.
\n\n
\n\n
9. Representative in Switzerland
\n\n
\n\n
Similar to the GDPR, private controllers with their domicile or residence abroad must, under certain circumstances, designate a representative in Switzerland if they process personal data of persons in Switzerland. The representative serves as a contact point for data subjects and the FDPIC. The controller must publish the name and address of the representative. The requirements for designating a representative and the duties of the representative are regulated in art. 14 and 15 FADP-new.
\n\n
\n\n
10. Cross-border disclosure of personal data
\n\n
\n\n
Under the current FADP, personal data must not be disclosed cross-border if such disclosure would seriously endanger the personal privacy of the data subjects, in particular, due to the absence of legislation that guarantees adequate protection. The FDPIC maintains a list with a general evaluation of the data protection level in the listed countries. However, this non-binding list does not relieve the data exporter from its responsibility to assess on a case by case basis whether the legislation of the respective country guarantees an adequate level of protection.
\n\n
\n\n
Under the FADP-new, the Federal Council bindingly determines whether the legislation of a state or an international body guarantees an adequate level of protection. If this is the case, personal data may be transferred cross-border. If not, data protection must be guaranteed by measures such as (a) an international treaty, (b) data protection clauses between the contracting parties, which were communicated beforehand to the FDPIC, (c) standard data protection clauses previously approved, established or recognised by the FDPIC (such as the EU standard contractual clauses) or (d) binding corporate rules (BCR) previously approved by the FDPIC or by a foreign authority which is responsible for data protection and belongs to a state which guarantees adequate protection (for example the CNIL in France as lead authority). The Federal Council can provide for other adequate safeguards, such as, for example, a follow-up agreement to the Swiss-US Privacy Shield.10
\n\n
\n\n
By derogation from the principles mentioned above, personal data may only be disclosed cross-border if one of the exceptions provided for in art. 17 FADP-new applies, such as, for example, the explicit consent of the data subject.
\n\n
\n\n
11. Duty of information when collecting personal data
\n\n
\n\n
The duty of information has been tightened. While the duty of information currently only applies to the collection of sensitive personal data and personality profiles, the controller must, in the future, generally inform the data subjects about the collection of their personal data. The minimum information that must be given in the privacy statement is stipulated in art. 19 FADP-new, differentiating between data collected directly from the data subject and data collected indirectly via other sources. This minimum information is less extensive than under the GDPR. However, there is one aspect where the FADP-new is stricter than the GDPR: if personal data is disclosed cross-border, the controller must inform the data subject of the state where the recipient is located.
\n\n
\n\n
Exceptions to the duty of information have been concretised. Private controllers may still restrict, defer or waive the provision of information in some instances. Among others, this is possible when the overriding interests of the controller demand it and when the controller does not disclose the personal data to third parties, companies controlled by the same legal entity not being considered as third parties in the sense of this exception.
\n\n
\n\n
Under the FADP-new, the controller must, as a general rule, inform the data subject of a decision which is taken exclusively based on automated processing and which has legal effects on the data subject or affects him or her significantly (so-called “automated individual decision”). The data subject can request that a natural person review the automated individual decision. Art. 21 FADP-new provides for exceptions to this rule.
\n\n
\n\n
12. Data protection impact assessments
\n\n
\n\n
As under the GDPR, the controller must conduct a data protection impact assessment before the data processing if the intended data processing may lead to a high risk for the data subject’s personality or fundamental rights. The existence of high risk, particularly when using new technologies, depends on the nature, the extent, the circumstances and the purpose of the processing (in particular the processing of sensitive personal data on a broad scale and the systematic surveillance of extensive public areas).
\n\n
\n\n
The data protection impact assessment contains a description of the intended processing, an evaluation of the risks for the data subject’s personality or the fundamental rights, as well as the intended measures to protect the data subjects’ personality and fundamental rights. Art. 22 FADP-new provides for certain exceptions. If the controller considers performing several similar processing operations, it may establish a joint impact assessment.
\n\n
\n\n
If the data protection impact assessment shows that the intended processing leads to a high risk for the personality or the fundamental rights of the data subject despite the measures envisaged, the controller must consult the FDPIC before the processing. It can abstain from consulting the FDPIC if it has appointed a data protection advisor according to art. 10 FADP-new and consulted him or her regarding the processing in question.
\n\n
\n\n
13. Notification of data security breaches
\n\n
\n\n
Like the GDPR, the FADP-new introduces a duty of notification of data security breaches, i.e. security breaches that lead to the unintentional or unlawful loss, deletion, destruction or modification of personal data or to personal data being disclosed or made accessible to unauthorised persons.
\n\n
\n\n
The good news is that the provisions regarding the notification obligation are slightly more pragmatic under the FADP-new than under the GDPR. The controller must notify the FDPIC as soon as possible of a data security breach that is probable to result in a high risk to the personality or the fundamental rights of the data subject.
\n\n
\n\n
Unlike the GDPR, the FADP-new only requires notification to the FDPIC where there is a high risk for the data subject. This is meant to prevent the notification of minor breaches. It remains the responsibility of the controller to determine the impact of the breach and the resulting risk for the data subject.
\n\n
\n\n
Contrary to the GDPR, the FADP-new does not stipulate a specific period within which the notification to the FDPIC must be made, but demands that the controller notify the breach as soon as possible after having become aware of it. The controller must act quickly but has a certain margin of discretion. “What is decisive in this context is, among others, the extent of the threat for the data subject. The bigger the threat and the larger the number of data subjects concerned, the quicker the controller must act.”11 Furthermore, the controller only needs to inform the data subject if it is necessary for the protection of the data subject or if the FDPIC requests so. What is decisive in this context is whether the notification can reduce the risk for the personality or the fundamental rights of the data subject. This is, in particular, the case where the data subject can take measures for his or her protection, for example by changing his or her login details or password.12 Under certain circumstances, the controller may restrict the information to the data subject, defer it or refrain from providing information.
\n\n
\n\n
The processor has no duty to notify the FDPIC but must inform the controller as soon as possible of any data security breach.
\n\n
\n\n
Art. 24 FADP-new lists the minimum requirements for a notification to the FDPIC.
\n\n
\n\n
14. Rights of the data subject
\n\n
\n\n
Access right: The access right currently regulated in art. 8 FADP is now regulated in art. 25 FADP-new. The principle remains unchanged. The controller provides the data subject with the information required to enable him or her to assert his or her rights and to ensure the transparent processing of personal data. It is the same information as the one that must be given based on the duty of information. The minimum information that must be provided in reply to a request for information is listed in the FADP-new. A new element is information on the existence of automated individual decision-making. In this case, the data subject must also be informed about the logic on which the decision is based. The data subject can further request that a natural person review the automated individual decision.
\n\n
\n\n
The current limitations to the access right continue to exist. Under the FADP-new, the controller may “refuse, restrict or defer the provision of information if the request for information is manifestly unfounded or is obviously of a querulous nature”. According to the Federal Council Dispatch13, this limitation is to be interpreted in a narrow sense. In particular, the controller must choose the most favourable solution for the data subject. It must, to the extent possible, only restrict the provision of information, may defer it if necessary and can only refuse it in absolutely clear and obvious cases.
\n\n
\n\n
Right to data portability: Under the FADP-new, the data subject has, under certain circumstances, a right to data portability.14 The data subject may request the transfer of his or her personal data to him or her or, if this does not involve a disproportionate effort, to another controller. As a general rule, the data must be disclosed free of charge and in a standard electronic format. The same limitations as for the access right apply.
\n\n
\n\n
Legal claims: The currently applicable legal claims continue to apply and are listed in art. 32 FADP-new. The right to deletion or destruction is now explicitly regulated in the FADP-new, although it is already implied in the current law.
\n\n
\n\n
15. Administrative measures and sanctions
\n\n
\n\n
The competences of the FDPIC are extended in art. 51 FADP-new. Under the new law, he can not only recommend measures but also order administrative measures. Among these measures are for example measures against data processing that violates the data protection regulations, including the order to destroy personal data or the prohibition to disclose personal data cross-border, as well as the order to perform a data protection impact assessment or to inform the data subject. The FDPIC still cannot issue any fines. This competence remains with the cantons.15
\n\n
\n\n
The criminal provisions have been significantly tightened.16 Under the FADP-new, private persons (i.e. not companies, as under the GDPR!) are, on complaint, liable to a fine of up to 250 000 Swiss francs if they violate their duty to provide access or information, or their duties of diligence, namely if they disclose personal data cross-border or assign the data processing to a processor without complying with the requirements, or fail to comply with the minimum data security requirements. Persons who wilfully refuse to cooperate with the FDPIC in the context of an investigation are also liable to a fine.
\n\n
\n\n
Further, a person who violates his or her duty of confidentiality by wilfully disclosing secret personal data of which he or she has gained knowledge while exercising his or her profession which requires knowledge of such data is liable to a fine. This provision introduces a duty of confidentiality for persons (and their auxiliary persons) who are not covered by the obligation of professional secrecy under criminal law17. A breach of professional confidentiality can be sanctioned on a complaint with a fine of up to 250 000 Swiss francs.
\n\n
\n\n
Finally, persons who wilfully fail to comply with a decision issued by the FDPIC or by the appellate authorities under threat of penalty are liable to a fine of up to 250 000 Swiss francs.
\n\n
\n\n
It should be noted that violations of essential duties newly enshrined in the law, such as the keeping of an inventory of processing activities, the notification of data security breaches or the obligation to perform data protection impact assessments, are not liable to a fine.
\n\n
\n\n
Implementation measures
\n\n
\n\n
Companies should carry out a data management analysis and identify their level of compliance with the FADP-new as well as any possible gaps and risks. In doing so, they should focus on the following areas:
\n\n
\n\n
\n
governance structure,
\n
data protection standards and processes to comply with the privacy principles and data security,
\n
transparency towards the data subjects,
\n
inventory of processing activities,
\n
data flows within the company and to service providers (taking into consideration the latest developments and the policy paper of the FDPIC18),
\n
processes for performing data protection impact assessments,
\n
notification of data security breaches to the FDPIC and
\n
responding to requests for information (access rights).
\n
\n\n
\n\n
Companies who already introduced a GDPR data protection program will have less need for action than companies who are not subject to the GDPR or who have not yet taken any respective measures.
\n\n
\n\n
Many companies will, in any case, have to introduce concepts such as privacy by design as well as processes that allow the legally compliant deletion or destruction of personal data and support data portability. Many companies will also have to review their privacy statements and, if needed, adapt them or issue new privacy statements to fulfil the requirements of the FADP-new. Current inventories of data files will have to be restructured to record data processing activities.
\n\n
\n\n
If you have any questions or need support in this area, please do not hesitate to contact FABIAN PRIVACY LEGAL.
[10] On 8 September 2020, the Federal Data Protection and Information Commissioner (FDPIC) determined that it no longer considers the Swiss-US Privacy Shield adequate for transferring personal data from Switzerland to the USA (see the policy paper of the FDPIC).
On 25 September 2020, the Swiss Parliament adopted the revised Federal Act on Data Protection. The Federal Council will decide on the entry into force after the 100-day referendum period has expired. This article summarizes the most significant changes for companies.
\n","preview":"","datei":[],"linkextern":""},{"id":97,"title":"Das revidierte Schweizer Datenschutzgesetz ist verabschiedet","slug":"the-revised-swiss-data-protection-act-is-adopted","link":"/en/news-knowledge/the-revised-swiss-data-protection-act-is-adopted","blocks":[{"id":123,"title":"PDF Test","slug":"pdf-test","link":"/en/dev/part-data/the-revised-swiss-data-protection-act-is-adopted-blocks/pdf-test"},{"id":124,"title":"PDF Test","slug":"pdf-test","link":"/en/dev/part-data/the-revised-swiss-data-protection-act-is-adopted-blocks/pdf-test"}],"titel":"The revised Swiss Data Protection Act is adopted","preview":"","text":"
On 25 September 2020, the Swiss Parliament adopted the revised Federal Act on Data Protection (FADP-new) (final voting text in French). The federal law is subject to an optional referendum. The Federal Council decides on the entry into force after the 100-day referendum period has expired.
\n\n
\n\n
After disagreeing until the very end on the issue of profiling, the Councils finally agreed on the introduction of the concept of “high-risk profiling”. The consequence of this type of profiling is that consent, if required, must be explicit (see below the relevant legal articles concerning profiling and consent).
\n\n
\n\n
It remains to be seen how companies will assess the risk level of profiling in practice. In any case, this exercise will be a challenge for companies.
\n\n
\n\n
It should be noted that the revised FADP does not introduce a consent requirement for high-risk profiling, but only requires that consent, if at all required as a justification under Art. 31 FADP-new, must be given explicitly. It must be reminded that the basic concept of the FADP and FADP-new is different from that of the GDPR. While under the GDPR, a legal ground is always required for the processing of personal data (Art. 6 and 9 GDPR), the processing of personal data under the FADP and FADP-new is, in principle, permitted as long as the personality of the data subjects is not unlawfully violated. According to the FADP-new, the “permission principle subject to prohibition” continues to apply, while the GDPR applies the “prohibition principle subject to permission”.
\n\n
\n\n
The revised Data Protection Act will in future apply to the processing of personal data of natural persons (today also legal entities). It introduces specific terms such as “controller” and “processor” and extends the term “sensitive personal data” to include “genetic data” and “biometric data that uniquely identifies a natural person”. Concepts, as already known from the GDPR, are now enshrined in the law, such as Privacy by Design, the inventory of processing activities, data protection impact assessments, the general duty to provide information when collecting personal data and the notification of data security breaches. In the future, under certain conditions, controllers located abroad will also have to appoint a representative in Switzerland if they process personal data of persons in Switzerland. The new law tightens the penal provisions with fines of up to 250,000 Swiss francs for private individuals who violate specific provisions, such as the obligation to inform, consult and cooperate with the FDPIC, the provisions on the transfer of personal data abroad and the assignment of processors, as well as non-compliance with minimum data security requirements.
\n\n
\n\n
A detailed summary and analysis of the revised law and its principles will follow.
\n\n
\n\n
Relevant articles in the FADP-new concerning profiling (unofficial translation):
\n\n
\n\n
Art. 5 lit f:
\n\n
Profiling Is any automated processing of personal data consisting in the use of such data to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects relating to the performance of work, economic situation, health, personal preferences, interests, reliability, behaviour, whereabouts or movements of that natural person.
\n\n
\n\n
Art. 5 lit g:
\n\n
High-risk profiling: profiling which involves a high risk to the personality or fundamental rights of the data subject, by creating a link between data which allows an assessment of substantial aspects of the personality of a natural person.
\n\n
\n\n
Art. 6 para 6:
\n\n
If the consent of the data subject is required, this consent is only valid if it is given voluntarily for one or more specific processing operations after adequate information has been provided.
\n\n
\n\n
Art. 6 para. 7:
\n\n
Consent must be given explicitly for: a. the processing of sensitive personal data; b. high risk profiling by a private person; or c. profiling by a federal body.
\n\n
\n\n
Art. 30 Violation of the personality
\n\n
1 Anyone who processes personal data must not unlawfully violate the personality of the data subjects.
\n\n
2 A violation of personality exists in particular if:
\n\n
a. personal data is processed in violation of the principles set out in Articles 6 and 8;
\n\n
b. personal data is processed contrary to the data subject’s express declaration of intent;
\n\n
c. sensitive personal data is disclosed to third parties.
\n\n
3 As a rule, there is no violation of personality if the data subject has made the personal data generally accessible and has not expressly prohibited its processing.
\n\n
\n\n
Art. 31 para 1
\n\n
A violation of privacy is unlawful if it is not justified by the consent of the person concerned, by an overriding private or public interest or by law.
\n","datum":"25.09.2020","teasertext":"
On 25 September 2020, the Swiss Parliament adopted the revised Federal Act on Data Protection (FADP-new). The federal law is subject to an optional referendum. The Federal Council decides on the entry into force after the 100-day referendum period has expired.
\n","datei":[],"linkextern":""},{"id":154,"title":"Swiss Data Protection Authority considers CH-US Privacy Shield no longer adequate","slug":"swiss-data-protection-authority-considers-ch-us-privacy-shield-no-longer-adequate","link":"/en/news-knowledge/swiss-data-protection-authority-considers-ch-us-privacy-shield-no-longer-adequate","titel":"Swiss Data Protection Authority considers CH-US Privacy Shield no longer adequate","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
On 8 September, the Federal Data Protection and Information Commissioner (FDPIC) determined that it no longer considers the CH-US Privacy Shield adequate for transferring personal data from Switzerland to the USA (please see the statement, the policy paper, and the amended list of states with adequate protection here). Such a decision was expected following the EU Court of Justice (CJEU) judgment of mid-July in the case C-311/18 — Data Protection Commissioner v. Facebook Ireland and Maximillian Schrems. See our summary here.
\n\n
\n\n
Based on this determination and within the scope of its competence (Art. 31 para. 1 lit. d FADP and Art. 7 of the Ordinance to the FADP (OFADP)), the FDPIC has removed the USA from the list of states with adequate data protection under certain conditions (Privacy Shield) and classifies the USA from now on as a country with insufficient protection.
\n\n
\n\n
The list of states is a list of countries whose legislation guarantees adequate data protection in the opinion of the FDPIC. However, the list does not release data exporters from their obligation to assess the presumed level of protection if there are indications of data protection risks in a specific case and, if necessary, to take appropriate safeguards within the meaning of Art. 6 para. 2 FADP, or even to refrain from exporting the data. The list distinguishes between countries with \"adequate data protection\" and countries with \"adequate data protection under certain conditions\". The USA has belonged to the second group since the beginning of 2017 with the introduction of the CH-US Privacy Shield.
\n\n
\n\n
With the removal of the USA from the list, the transfer of personal data to the USA now requires the fulfillment of one of the conditions of Art. 6 para. 2 FADP (such as contractual guarantees, binding corporate rules (BCR), or consent). The data exporter remains obliged to carry out a risk assessment in each case and, in particular, to ensure data protection's adequacy in the destination country.
\n\n
\n\n
However, the determination of the FDPIC and the removal of the USA from the list of states does not influence the continued existence of the CH-US Privacy Shield. The framework would have to be formally revoked by the US Department of Commerce. If a company continues to transfer personal data to the USA under the CH-US Privacy Shield without taking additional safeguards under Art. 6 para. 2 FADP, it is in breach of the data protection principles under the FADP. It thus unlawfully violates the personality of the data subjects, unless there is a legal justification, including consent, an overriding private or public interest or law.
\n\n
\n\n
In its policy paper, the FDPIC provides guidance on the measures to be taken by companies that transfer personal data to non-listed countries based on contractual clauses. Data exporters should consider each case with due diligence, and, in particular, verify if the receiving company in a non-listed country is subject to governmental access, and further whether the receiving company is entitled and in a position to provide the cooperation necessary for the enforcement of Swiss data protection principles. If this is not the case, Swiss data exporters must consider technical measures that effectively prevent the authorities in the destination country from accessing the transferred personal data, in particular, through encryption along with the principles of BYOK (bring your own key) and BYOE (bring your own encryption). However, encryption may not be useful for the receiving company's services beyond mere data hosting. If such technical measures are not possible, the FDPIC recommends refraining from transferring personal data to non-listed countries based on contractual clauses.
\n\n
\n\n
Please note that under the current FADP, the FDPIC only has the power to issue recommendations regarding the method of processing, and, in case such recommendations are not followed or rejected, to refer the matter to the Federal Administrative Court for a decision. Under the revised Draft FADP (D-FADP, according to the current state), however, the FDPIC shall obtain extended power to issue an order to the controller directly and prohibit the data transfer abroad if it is contrary to the requirements of the D-FADP or violates provisions relating to the disclosure of personal data abroad. Responsible individuals who deliberately fail to comply with an order issued by the FDPIC may be fined up to 250,000 Swiss francs, provided that the order contains such a threat of punishment.
\n\n
\n\n
Therefore, Swiss companies should continue to monitor developments in this matter and watch out for further guidance of the FDPIC. Companies should also identify and document any cross-border data transfer within their organization and to third parties, and the safeguards used. Transfers relying on the CH-US Privacy Shield should be based on alternative transfer mechanisms. If Standard Contractual Clauses (SCC) are used, companies should conduct assessments in each case, as described above, and take additional contractual, technical, and organizational measures to reach an adequate protection level for the data transferred.
\n","datum":"11.09.2020","teasertext":"
On 8 September 2020, the Federal Data Protection and Information Commissioner (FDPIC) determined that it no longer considers the CH-US Privacy Shield adequate for transferring personal data from Switzerland to the USA, following the EU Court of Justice judgment of mid-July in the Schrems II case. The following article explains the consequences of this decision for Swiss companies transferring personal data to third countries and gives advice on how they should react.
\n","preview":"","datei":[],"linkextern":""},{"id":155,"title":"What needs to be considered when transferring personal data to third countries? (in German)","slug":"was-ist-bei-der-uebermittlung-von-personendaten-ins-ausland-zu-beachten","link":"/en/news-knowledge/was-ist-bei-der-uebermittlung-von-personendaten-ins-ausland-zu-beachten","titel":"What needs to be considered when transferring personal data to third countries? (in German)","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
Was ist bei der Übermittlung von Personendaten ins Ausland zu beachten?
\n\n
\n\n
Der Gerichtshof der Europäischen Union (EuGH) hat in einem kürzlich publizierten Entscheid die Übermittlung von Personendaten in Drittländer erheblich erschwert. Welche Auswirkungen hat dieser Entscheid auf Unternehmen in der Schweiz?
\n\n
\n\n
Die geltende EU Datenschutz-Grundverordnung (DSGVO) und das schweizerische Datenschutzgesetz (DSG) verbieten grundsätzlich die Übermittlung von Personendaten aus dem Europäischen Wirtschaftsraum (EWR) und der Schweiz in Länder, die keinen angemessenen Datenschutz gewährleisten (Drittländer).
\n\n
\n\n
Eine Übermittlung in Drittländer, einschliesslich Fernzugriff, ist nur erlaubt, wenn mindestens eine der gesetzlich vorgesehenen Schutzmassnahmen getroffen wird, wie beispielsweise die Anwendung von EU-Standardvertragsklauseln (SCC) zwischen Datenexporteuren und Datenempfängern oder die Einführung von verbindlichen internen Unternehmensregeln (BCR) für den internen Datenaustausch. Eine Übermittlung ist auch erlaubt, wenn eine Ausnahmeregelung vorliegt, beispielsweise die ausdrückliche Einwilligung der betroffenen Personen.
\n\n
\n\n
Die USA gelten grundsätzlich aus europäischer Sicht als Drittland. Sowohl die EU als auch die Schweiz haben jedoch mit den USA ein Regelwerk erarbeitet, den sogenannten EU-U.S. Privacy Shield und CH-U.S. Privacy Shield. Dieses Regelwerk erlaubt die Übermittlung von Personendaten aus der EU und der Schweiz an US-Unternehmen, die sich dem jeweiligen Privacy Shield unterstellt haben.
\n\n
\n\n
Das Urteil des EuGH in Sachen Schrems II erschwert die grenzüberschreitende Datenübermittlung
\n\n
\n\n
Am 16. Juli 2020 hob der Gerichtshof der Europäischen Union (EuGH) in der Rechtssache C-311/18 - Data Protection Commissioner v. Facebook Ireland and Maximilian Schrems (Schrems II) den EU-U.S. Privacy Shield mit sofortiger Wirkung auf. Der Grund für diese Entscheidung liegt darin, dass das US-Recht aufgrund der weitgehenden Befugnisse der US Geheimdienste gemäss der Einschätzung des EuGH kein Schutzniveau bietet, das dem in der Europäischen Union im Wesentlichen gleichwertig ist.
\n\n
\n\n
Gleichzeitig bestätigte der EuGH die prinzipielle Gültigkeit von SCC. Der EuGH appelliert jedoch an die bereits in den SCC festgeschriebenen Verpflichtungen von Unternehmen, die Personendaten auf der Grundlage von SCC aus der EU in ein Drittland exportieren oder importieren, und betont, dass die reine Unterzeichnung der SCC nicht ausreicht. Die Parteien müssen im Einzelfall prüfen, ob die SCC im Empfängerland eingehalten werden können und die Rechte der betroffenen Personen im Empfängerland ein angemessenes Schutzniveau geniessen, das dem in der Europäischen Union gleichwertig ist.
\n\n
\n\n
Ist dies nicht der Fall, muss der Datenexporteur zusätzliche Schutzmassnahmen ergreifen oder die betreffende Datenübermittlung aussetzen. Schutzmassnahmen können technischer Natur sein, wie beispielsweise die Verschlüsselung der Daten. Zusätzliche vertragliche Absicherungen und organisatorische Massnahmen sind ebenfalls denkbar. Der EuGH legt jedoch nicht fest, welche Art von Schutzmassnahmen ergriffen werden sollen, und lässt somit den Unternehmen einen gewissen Spielraum.
\n\n
\n\n
Was bedeutet dieses Urteil für Unternehmen in der Schweiz?
\n\n
\n\n
Das EuGH-Urteil ist auf die Schweiz nicht direkt anwendbar. Somit bleibt der CH-U.S. Privacy Shield vorerst gültig. Auch vom Eidgenössischen Datenschutz- und Öffentlichkeitsbeauftragten (EDÖB) anerkannte SCC können weiterhin für Datenübermittlungen aus der Schweiz genutzt werden. Der EDÖB hat das Urteil des EuGH zur Kenntnis genommen, hat sich aber noch nicht zur Gültigkeit des CH-U.S. Privacy Shields geäussert. Es ist jedoch zu erwarten, dass die Behörde dem EuGH-Urteil folgen und auch den CH-U.S. Privacy Shield für ungültig erklären wird (wie sie es auch 2015 nach der Ungültigkeitserklärung des Vorgängerabkommens Safe-Harbor getan hat). Für Unternehmen in der Schweiz, die dem DSG unterliegen, besteht somit aufgrund des EuGH-Urteils vorerst kein dringender Handlungsbedarf. Dennoch sollten die internen und externen Datenflüsse jetzt schon ermittelt und Vorbereitungen für einen kurzfristigen Wechsel von Privacy Shield auf SCC getroffen werden. Auf viele Unternehmen in der Schweiz ist jedoch auch die DSGVO anwendbar. Diese Unternehmen sollten jetzt aktiv werden, um Personendaten weiterhin legitim in Drittländer übermitteln zu können und signifikante Bussgelder zu vermeiden.
\n\n
\n\n
Was können Unternehmen tun?
\n\n
\n\n
\n
Unternehmen sollten die Entwicklungen in der EU und in der Schweiz überwachen und insbesondere auf die Herausgabe von Leitlinien und revidieren SCC als auch auf eine allfällige Ungültigkeitserklärung des CH-U.S. Privacy Shields achten.
\n
\n\n
\n\n
\n
Interne und externe grenzüberschreitende Datenübermittlungen sollten ermittelt und dokumentiert werden.
\n
\n\n
\n\n
\n
Für Datenübermittlungen, die auf den EU-U.S. Privacy Shield gestützt sind, sollten SCC mit den Datenempfängern vereinbart werden.
\n
\n\n
\n\n
\n
Für Datenübermittlungen auf der Grundlage von SCC (einschliesslich konzerninterner Datenübermittlungsvereinbarungen) sollten im Rahmen der Due Diligence mit dem Datenempfänger Analysen im Empfängerland durchgeführt und gegebenenfalls zusätzliche vertragliche, organisatorische und technische Massnahmen getroffen werden.
\n
\n\n
\n\n
\n
Schliesslich sollten Unternehmen ihre Datenübermittlungsstrategie überdenken und gegebenenfalls einen Wechsel auf robustere Mechanismen, wie BCR in Betracht ziehen.
\n
\n\n
\n","datum":"04.09.2020","teasertext":"
In an article published in the magazine \"Fokus Rechtsguide\", Daniela Fábián Masoch explains what needs to be considered when transferring personal data to third countries and what are the consequences of the CJEU judgment (Schrems II) for Swiss companies. Please note that the publication is only available in German.
\n","preview":"","datei":[],"linkextern":""},{"id":156,"title":"CJEU judgment on cross-border data transfers from the EU to third countries - what now?","slug":"urteil-des-eugh-zu-grenzueberschreitenden-datenuebermittlungen-aus-der-eu-in-drittlaender-was-nun","link":"/en/news-knowledge/urteil-des-eugh-zu-grenzueberschreitenden-datenuebermittlungen-aus-der-eu-in-drittlaender-was-nun","titel":"CJEU judgment on cross-border data transfers from the EU to third countries - what now?","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
On 16 July 2020, the Court of Justice of the European Union (CJEU) delivered its judgment in Case C-311/18 — Data Protection Commissioner v. Facebook Ireland and Maximillian Schrems (so-called \"Schrems II\"). In this case, M. Schrems requested the Commission to prohibit or suspend the transfer by Facebook Ireland of his personal data to Facebook Inc., established in the US, on the ground that that third country did not ensure an adequate level of protection. This ruling has far-reaching consequences for any transfers of data from the EU to third countries.
\n\n
\n\n
The CJEU’s findings of the decision
\n\n
\n\n
1. Privacy Shield
\n\n
\n\n
The CJEU invalidated, with immediate effect, the European Commission Decision 2016/1250 on the transfer of personal data to the US (Privacy Shield). The rationale for this decision is in essence that US law as evaluated by the CJEU, in particular Section 702 Foreign Intelligence Surveillance Act “FISA” and Executive Order 12333, does not provide a level of protection substantially equivalent to that in the EU (in terms of appropriate safeguards, enforceable rights and effective legal remedies required by the GDPR).
\n\n
\n\n
Please note that the Swiss Data Protection Authority (FDPIC) has taken note of the CJEU ruling. This ruling is not directly applicable to Switzerland and, therefore, to the CH-US Privacy Shield. The FDPIC will examine the judgment in detail and comment on it in due course. While the CH-US Privacy Shield is, at the moment, still valid, it is to be expected that the authority will follow the CJEU ruling and invalidate the CH-US Privacy Shield as well (as it did in 2015 after the invalidation of the Safe Harbor arrangement).
\n\n
\n\n
2. Standard Contractual Clauses (SCC)
\n\n
\n\n
The CJEU confirmed the validity, in principle, of the Commission Decision 2010/87/EC on Standard Contractual Clauses (SCC). However, the CJEU stressed the responsibility of the data exporter and data importer to carry out a case-by-case analysis of the domestic law of the data importer, specifically concerning access by public authorities and judicial redress to determine whether the rights of data subjects in the third country enjoy a level of protection equivalent to that in the Union. Where this is not the case, data exporters must take additional, effective safeguards or suspend the data transfer in question. Such additional safeguards may include technical measures such as encryption of the data in transit and at rest, contractual safeguards, or organizational measures. The CJEU does not, however, specify what kind of additional safeguards should be taken and thus leaves companies in uncertainty. More guidance is expected in the near future.
\n\n
\n\n
The obligations highlighted by the CJEU are not new. They are already included both in the Controller to Processor SCC and in the Controller to Controller SCC. The CJEU calls upon the existing obligations of companies which export, and import, personal data based on SCC from the EU to a third country without adequacy finding by the EU Commission, and stresses that it is not enough to sign the SCC, but that the parties must examine on a case-by-case basis whether the SCC can be complied with in the recipient country.
\n\n
\n\n
The CJEU decision concerns, in principle, the Controller to Processor SCC. However, the same arguments apply to any transfer of personal data from the EU to a third country, including on the basis of Controller to Controller SCC or Binding Corporate Rules (BCR).
\n\n
\n\n
Companies that do not carry out this analysis and possibly transfer personal data based on SCC to a third country, where the data recipient is not able to effectively comply with SCC due to conflicting local legislation, violate the requirements under the GDPR (even if SCC have been signed) and therefore risk hefty fines of up to EUR 20'000'000 or 4% of the annual turnover of the preceding year, whichever is higher. Also, such transfers may be prohibited or suspended by the competent supervisory authorities.
\n\n
\n\n
Relevant clauses in the current SCC
\n\n
\n\n
Controller to Processor SCC of 5 February 2010 (2010/87/EU)
\n\n
\n\n
Clause 4 (a): The data exporter agrees and warrants that the processing, including the transfer itself, of the personal data has been and will continue to be carried out in accordance with the relevant provisions of the applicable data protection law (…) and does not violate the relevant provisions of that State.
\n\n
\n\n
Clause 5: The data importer agrees and warrants:
\n\n
\n\n
(a): to process the personal data only on behalf of the data exporter and in compliance with its instructions and the Clauses; if it cannot provide such compliance for whatever reasons, it agrees to inform promptly the data exporter of its inability to comply, in which case the data exporter is entitled to suspend the transfer of data and/or terminate the contract.
\n\n
\n\n
(b): that it has no reason to believe that the legislation applicable to it prevents it from fulfilling the instructions received from the data exporter and its obligations under the contract and that in the event of a change in this legislation which is likely to have substantial adverse effect on the warranties and obligations provided by the Clauses, it will promptly notify the change to the data exporter as soon as it is aware, in which case the data exporter is entitled to suspend the transfer of data and/or terminate the contract.
\n\n
\n\n
Controller to Controller SCC of 27 December 2004 (2004/915/EC)
\n\n
\n\n
Clause I (b): The data exporter warrants and undertakes that it has used reasonable efforts to determine that the data importer is able to satisfy its legal obligations under these clauses.
\n\n
\n\n
Clause II (c): The data importer warrants and undertakes that it has no reason to believe, at the time of entering into these clauses, in the existence of any local laws that would have a substantial adverse effect on the guarantees provided for under these clauses, and it will inform the data exporter (which will pass such notification on to the authority where required) if it becomes aware of any such laws.
\n\n
\n\n
Reactions of data protection authorities
\n\n
\n\n
In the meantime, several data protection authorities as well as the European Data Protection Supervisor (statement 17 July 2020), the European Data Protection Board (statement 17 July 2020) and the German Conference of the Independent Data Protection Authorities of the Federal Government and the Länder (Datenschutzkonferenz - DSK) (press release 28 July 2020) have issued initial guidance for how to handle data transfers in future. You may find the respective references to the guidance on the IAPP Resource Center page.
\n\n
\n\n
Some data protection authorities, such as the German data protection authorities in Berlin (press release 17 July 2020) and Hamburg (press release 16 July 2020) have issued rigorous statements on the unlawfulness of data transfer to the US, based on SCC. The Berlin data protection authority is even calling on all those responsible under its supervision not to transfer personal data to the USA any longer, but to switch immediately to service providers based in the EU or another third country with an adequate level of protection.
\n\n
\n\n
The EDPB has issued, in addition to its statement, FAQ. More guidance, in particular regarding the additional safeguards to be taken, is expected.
\n\n
\n\n
What companies can do
\n\n
\n\n
While it is expected that the EDPB, the EU Commission and the supervisory authorities provide further guidance on the \"additional safeguards\"; and the EU Commission issues revised SCC, data exporters and importers should consider additional safeguards to ensure an adequate level of protection when transferring personal data from the EU to third countries:
\n\n
\n\n
\n
Document the analysis, the outcome, and any steps taken.
\n
\n\n
\n\n
\n
Identify and document any cross-border data transfer within your organization and to vendors and other business partners located outside of the EU/CH:
\n
\n\n
\n\n
If any personal data is transferred cross-border based on EU-US Privacy Shield, determine alternative legal mechanisms to enable such transfers under the GDPR (such as SCC subject to the conditions outlined by the CJEU, or one of the legal derogations under art. 49 GDPR), and amend contracts accordingly. Create a plan outlining all steps, responsibilities and timelines, including the possible termination of the EU-US Privacy Shield in accordance with the notification requirements, and adhere to the plan.
\n\n
\n\n
If any personal data is transferred cross-border based on SCC (including intragroup data transfer agreements), assess, together with the data importer, whether the legislation of the third country of destination ensures adequate protection under EU law of personal data transferred under the SCC. In particular, it should be assessed if the data importer is subject to any law and practice that allows data access by public authorities (such as under Art. 702 FISA in the US), and therefore the data importer may not be able to comply with the SCC. In this case, the data exporter shall conduct a privacy risk assessment to evaluate the likelihood of disclosure or access, the sensitivity and the volume of the data, and the retention period, and consider additional safeguards beyond SCC, including, for example, contractual and technical measures such as data encryption in transit and at rest. If such other measures are not possible, the data exporter should suspend or end the transfer of personal data, or notify the competent supervisory authority, which may ban any further data transfer.
\n\n
\n\n
If the transfer is based on BCR, the same analysis as for SCC should be conducted.
\n\n
\n\n
If the transfer is based on one of the legal derogations provided by Art. 49 GDPR, such as explicit consent or the necessity to perform a contract, no further steps are required for now.
\n\n
\n\n
\n
Document the analysis, the outcome, and any steps taken.
\n
\n\n
\n\n
\n
Review and amend due diligence processes and contractual templates:
\n
\n\n
\n\n
To be able to conduct appropriate conformity and risk assessments, the due diligence process and the questionnaire for data protection assessments of vendors should be revised to include questions about the existence of monitoring and data access laws and practices to which the data importer is subject. Particular attention should also be paid to the data importer's internal rules and procedures concerning the handling of requests from public authorities and notification to the data exporter. Also, any data importers, i.e., processors and controllers, should be evaluated in the future.
\n\n
\n\n
The contractual language in templates regarding the cross-border data transfers should be revised to emphasize the primary obligations of the data exporter/importer arising from the SCC itself, the handling of government requests to access personal data, and removing any reference to the Privacy Shield Framework.
\n\n
\n\n
\n
Service providers (data importers) may assist their customers by conducting a thorough analysis to verify the adequacy of EU laws and comply with the SCC (such exercise may also help to maintain a competitive edge).
\n
\n\n
\n\n
\n
Establish (or revise) internal policies and procedures to address cross-border requirements in compliance with the GDPR and the CJEU judgment.
\n
\n\n
\n\n
\n
In the long-term, companies may consider moving to more robust data transfer mechanisms, as provided in Art. 46 GDPR, such as binding corporate rules (BCR for Controllers and BCR for Processors) which are approved by the EU supervisory authorities, code of conduct, or certification mechanisms.
\n
\n","datum":"03.08.2020","teasertext":"
On 16 July 2020, the Court of Justice of the European Union (CJEU) delivered its judgment in Case C-311/18 — Data Protection Commissioner v. Facebook Ireland and Maximillian Schrems (so-called \"Schrems II\"). In this case, M. Schrems requested the Commission to prohibit or suspend the transfer by Facebook Ireland of his personal data to Facebook Inc., established in the US, on the ground that that third country did not ensure an adequate level of protection. This ruling has far-reaching consequences for any transfers of data from the EU to third countries.
\n","preview":"","datei":[],"linkextern":""},{"id":179,"title":"Privacy by Design in Digital Health","slug":"privacy-by-design-in-digital-health","link":"/en/news-knowledge/privacy-by-design-in-digital-health","titel":"Privacy by Design in Digital Health","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
1 Introduction
\n\n
\n\n
The exponential growth of digital health solutions and products, such as software or internet-enabled devices, brings a range of benefits for patients, the health industry and the general public, from preventing new diseases, monitoring patient conditions, data analysis, personalised medicine to reducing health costs through more efficient processes.
\n\n
\n\n
To be effective, these technologies rely on the use of large amounts of data. Particular caution is needed when personal data are involved, as the processing of personal data, in particular health-related data, can pose significant risks to the privacy of data subjects and the security of personal data. It is therefore of utmost importance to implement the fundamental data protection principles as laid down in data protection laws, such as the EU General Data Protection Regulation (EU) 2016/679 of 27 April 2016 (GDPR), the EU directive on privacy and electronic communications (Directive 2002/58/EC of 12 July 2002) and applicable national data protection laws. In particular, principles such as data minimisation and transparency, as well as technical security measures such as pseudonymisation or encryption, must be embedded in the design, development, and use of such solutions. In short: privacy by design must be implemented.
\n\n
\n\n
With the outbreak of COVID-19 and the efforts to find fast digital solutions to contain the spread of the virus, in particular through so-called contact tracing apps, which should help to efficiently interrupt chains of infection, the concept of privacy by design has gained in importance and awareness. For such apps to be successful and effective, they must be designed in such a way that the privacy of the individual and the protection of his or her personal data is guaranteed, at least in Europe. People must be assured that they are in control of their data, that their data are secure and only used for well-defined purposes and that their privacy rights are respected. Public trust and acceptance is of paramount importance to encourage the use of such applications, where their use is voluntary.
\n\n
\n\n
In order to realise the benefits of digital health solutions, those responsible for the development and management of such solutions and data processing, such as healthcare companies or public authorities, must meet the expectations of individuals, gain and maintain their trust and respect their privacy. Privacy by design has become a critical factor in building and maintaining trust, competitiveness, and success in the marketplace.
\n\n
\n\n
The challenge is to find the right balance between the potential of digital health to improve health services on the one hand and the protection of the personal rights of patients and consumers on the other. All legitimate interests and objectives, including data protection, should be taken into account without unnecessary compromise. This approach requires creative solutions in technical and organisational respects.
\n\n
\n\n
This article examines the privacy aspects under the GDPR that need to be taken into account when designing digital health solutions and why this is important to fully exploit the potential of digital health. It also attempts to clarify the concept of privacy by design and to translate legal requirements into practical solutions, with a focus on mobile applications in the context of digital health.
\n\n
\n\n
2 Emerging digital health technologies
\n\n
\n\n
Digital health refers to the use of information and communication technologies (ICT) to improve the quality, efficiency, and management of healthcare. Examples of digital health technologies include telemedicine, health monitoring and care with robots and sensors; wearables, i.e. mobile sensors worn directly on the body that record and analyse physiological data such as blood pressure, temperature, pulse or blood sugar levels in real time; and more generally the Internet of Things (IoT), i.e. the networking of physical devices equipped with software, sensors and network connectivity to collect and exchange data. Another example are the so-called contact tracing apps mentioned above, which are highly topical at the time of writing, and which are being developed by various countries worldwide to combat the spread of COVID-19. These apps are designed to alert people who have been in proximity to an infected person for a certain period of time so that they can take appropriate action.
\n\n
\n\n
3 The concept of privacy by design
\n\n
\n\n
The concept of privacy by design (PbD) is a fundamental prerequisite for the effective implementation of data protection. In essence, PbD requires that controllers take into account the principles and requirements of data protection both in the design phase of systems, processes, products or services and throughout the life cycle of personal data and that they provide for appropriate technical and organisational measures (TOMs) to implement the data protection requirements and to protect the rights of data subjects. Controllers are required to be proactive and anticipate potential privacy-invasive events before they materialise. Privacy by default is a fundamental element of privacy by design. It requires the controller to implement appropriate TOMs to ensure that, by default, only personal data necessary for each specific purpose of processing are processed. PbD must be implemented in relation to the quantity of data collected, the scope of their processing, the period of their storage, and their accessibility.
\n\n
\n\n
While the concept of PbD as a good practice has long existed, it was introduced as a legal obligation in Art. 25 GDPR with substantial fines in case of failure. With this, the legislator wanted to emphasise that it is not enough to set standards, but that these standards must be implemented in an effective and verifiable manner. However, Art. 25 GDPR does not specify how this obligation should be implemented in practice.
\n\n
\n\n
The implementation of PbD requires an assessment of the organisational, process, or product-related risks as well as the privacy risks for data subjects. This assessment aims to determine the necessary measures to be integrated from the outset as part of these products, systems, or processes to meet data protection requirements and to protect the privacy of data subjects. Risks may include, for example, excessive collection and disclosure of personal data, processing beyond the initial purpose, unlawful processing, loss, destruction, or alteration of data. Such risk assessment, coupled with a conformity assessment, is required for any processing of personal data, regardless of the sensitivity of the data.
\n\n
\n\n
Only if the processing is likely to present a high risk to the rights and freedoms of the data subjects, the controller must carry out a data protection impact assessment (DPIA) according to Art. 35 GDPR. A DPIA is a more comprehensive assessment that goes beyond conformity assessment by assessing the remaining risks to individuals, taking into account the TOMs embedded in the design of the product, system, or process. If the residual risk is still considered to be high, the controller must take further risk mitigation measures or, if this is not possible, refrain from processing or consult the data protection authorities. A DPIA will regularly be required for digital health solutions where health-related data or other special categories of data are processed, or technologies are used that may involve new forms of data collection and use.
\n\n
\n\n
4 Implement privacy by design in practice
\n\n
\n\n
4.1 Who is legally responsible for implementing privacy by design?
\n\n
\n\n
According to Art. 25 GDPR, the controller must implement the concept of PbD. Manufacturers, developers and service providers that are not controllers are only encouraged in Recital 78 GDPR to take into account 'privacy by design' when developing, designing, selecting and using applications, services and products based on the processing of personal data and to ensure that controllers and processors can comply with their data protection obligations. In practice, manufacturers of intelligent devices and health application developers will have a keen interest in fully implementing the concept of \"privacy by design\" to remain competitive.
\n\n
\n\n
4.2 What does the concept of privacy by design require from the controller?
\n\n
\n\n
The controller must establish technical measures, such as, for example, pseudonymisation, access authorisations, and restrictions, user authentication, encryption, logging, securing system configurations, protection measures against malware and data loss, and physical protection measures.
\n\n
\n\n
Furthermore, the controller must take organisational measures that are necessary for a well-functioning data protection management. These measures may include, for example, the allocation of responsibilities for the effective implementation of data privacy requirements, the implementation of enforceable policies and procedures for handling and documenting data breaches and data subject access requests, risk management, third-party management, data transfer governance, documentation of processing activities, training and controls. Also, the controller must take appropriate measures to respond to a withdrawal of consent, to a request for rectification or erasure of personal data or the portability of data.
\n\n
\n\n
4.3 How must the technical and organisational measures be?
\n\n
\n\n
The TOMs must be adequate and appropriate to
\n\n
\n\n
\n
effectively implement data protection principles, such as data minimisation, lawfulness, transparency, confidentiality, purpose limitation, data integrity, storage duration, security, as well as the requirements concerning commissioned data processing and cross-border data transfers;
\n
integrate the necessary safeguards into the processing to meet the requirements of the GDPR; and
\n
protect the rights of data subjects.
\n
\n\n
\n\n
A measure is adequate if it takes into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing.
\n\n
\n\n
4.4 When must TOMs be implemented?
\n\n
\n\n
The controller must implement TOMs both at the time of determining the means of processing and during the processing itself.
\n\n
\n\n
4.5 What data protection aspects must be taken into account in digital health solutions?
\n\n
\n\n
First, it must be determined which laws and regulations are applicable, in particular, whether the GDPR is applicable. It should also be examined whether sector-specific codes of conduct, certification systems, regulatory decisions, or guidelines for the development of digital health products are applicable. Ethical considerations should also be taken into account.
\n\n
\n\n
Secondly, it is necessary to determine which parties are involved in the development, deployment, and use of the product and the respective roles of these parties, who is the controller (several parties may be joint controllers) and, where appropriate, who is a processor. The identification of the controller, i.e., the party which alone or jointly with others determines the means and purposes of the data processing, is essential to determine who is responsible and accountable for complying with data protection requirements under the GDPR.
\n\n
\n\n
The following section explains which data protection principles must be observed and how they can be implemented in practice, with a focus on the use of mobile health apps.
\n\n
\n\n
Proportionality and data minimization
\n\n
\n\n
Personal data must be adequate, relevant, and limited to what is necessary for the purposes for which they are processed. This means that apps and devices that store or process personal data should be set up in such a way that only the data necessary for the respective purpose or the proper functioning of the app or device are stored and processed.
\n\n
\n\n
Personal data are defined as any information relating to an identified or identifiable natural person. In the context of a mobile application, data relating to the device, such as location data or usage data, are also considered personal data. Pseudonymised data, meaning data that are processed in such a way that they can no longer be attributed to a specific data subject without the use of additional information that is kept separately and securely, are also classified as personal data. Only irreversibly anonymised data are not considered personal data and are therefore not subject to the GDPR (and other data protection laws).
\n\n
\n\n
The principle of data minimisation can be achieved in different ways, for example, by reducing the amount of personal data or by making it more difficult or impossible to assign the data to an individual.
\n\n
\n\n
The type and amount of data necessary for the identified purpose may vary depending on the application area of the product. If, for example, an app is only used for information purposes, the collection of personal data is usually not necessary or pseudonymised login data might be sufficient. However, if an app is to monitor health and, if necessary, interact with a doctor or other persons, considerably more data, especially identification and health data, may be required. In the case of a COVID-19 contact tracing application to alert people who have been in the vicinity of a positive tested person, proximity data collected using Bluetooth technology should be sufficient. Location data that can be used to track individuals are not necessary for this purpose, nor are other personal data. Anonymised or at least pseudonymised data should be sufficient.
\n\n
\n\n
Depending on the functionalities of the app and the purpose of processing, it must, therefore, be evaluated for each data set whether the data are necessary to fulfil the purpose or whether the purpose can be fulfilled with less data (reduction of the data volume) or pseudonymised/anonymised data (making identification more difficult or impossible). A distinction should also be made between mandatory and voluntary data, which can be provided additionally to use specific functionalities.
\n\n
\n\n
Further measures to minimise data can consist in preventing the linking of personal data collected via the product with personal data stored in other systems unless such linking is necessary for the purpose. Location data should not be collected and stored if a generic location area is sufficient for the application functionality.
\n\n
\n\n
A central question is also where the data should be stored, i.e., only on the user's terminal device or on a central server, and who should have access to the data. If the data are only stored on the mobile device, the user has full control over the data and access. However, if the data are stored on a central server, other people can have access over which the user has no control. This question is currently being hotly debated in connection with the development of a COVID-19 tracing app, whereby the proponents of a decentralised solution believe that this approach is more consistent with the principle of data minimisation.
\n\n
\n\n
Which approach is ultimately chosen depends on the type of the mobile health app and its purposes. With both models, appropriate TOMs must be taken to protect the data from unauthorised access and misuse.
\n\n
\n\n
Legal justification
\n\n
\n\n
The processing of personal data must be lawful and carried out in good faith and must have a legal basis, as set out in Art. 6 and 9 of the GDPR and the ePrivacy Directive. The ePrivacy Directive requires the user's consent for the storage of information or access to stored data on the user's equipment unless the storage and access are legally permitted under national law, or the storage and access are strictly necessary to provide a service explicitly requested by the user. The consent shall also be required for the use of non-essential cookies or similar technologies on users' equipment and for the processing of location data other than traffic data, provided that such data are not anonymised.
\n\n
\n\n
In health or medical applications collecting and processing special categories of a patient or consumer data, the processing of these data will regularly require the explicit consent of the data subject. Consent must be voluntary and specific to each functionality that serves different purposes. Consent must be based on prior information and, in the case of special categories of data, the use of cookies or location data, consent must be given explicitly and therefore through positive action, such as downloading the application and ticking a consent box. Also, controllers must have a procedure in place which, on the one hand, allows for easy withdrawal of consent and, on the other hand, ensures that in the event of withdrawal, the data collected will not be further processed.
\n\n
\n\n
Transparency
\n\n
\n\n
Personal data must be processed transparently. Comprehensive privacy notice about what personal data are processed, how they are processed, and what they are used for, as described in Art. 12-14 GDPR, must be made available to the data subjects before their data are processed. This notice must, if applicable, also contain information on the use of cookies or similar technology on the terminal equipment and location data, as well as methods for refusing to store such cookies or giving consent to the use of cookies and location data.
\n\n
\n\n
Data subjects should have full transparency and control over the processing of their data and understand what data are processed, why, by whom, where and for how long, and how they can exercise their privacy rights.
\n\n
\n\n
The privacy notice should be easily accessible to data subjects at any time, before the collection of personal data and throughout the processing, either within the device or through a link to a website. The notice should be easy to understand, where appropriate in different languages, and have a multi-layered structure in which the essential information is summarised in a first layer, possibly supported visually by symbols, and with further details in a second layer if the user wishes to know more. The product should also enable for changes to the privacy notice and should allow users to manage their profiles and update their privacy settings.
\n\n
\n\n
Confidentiality and access to personal data
\n\n
\n\n
Personal data must be kept strictly confidential and may only be provided or disclosed to individuals on a need-to-know basis to fulfil the legitimate purposes for which the information was collected.
\n\n
\n\n
It is essential to determine whether access to the data by persons other than the user, such as doctors, service providers, insurance companies or authorities, is necessary to fulfil the purposes for which the data are processed. Accesses to the data, devices, server, and network should be documented.
\n\n
\n\n
Among the key issues are: Can the user influence and manage these accesses directly through the product? Who enters the data, only the user of the product or other persons, such as a doctor or a pharmacist? Are any service providers involved in the storage or other processing of the data? How is access or sharing of the data secured? Are the data encrypted during transmission and in storage? Who should have access to what personal data and for what purposes? Are these persons obliged to maintain confidentiality? How is access controlled and restricted?
\n\n
\n\n
Purpose limitation
\n\n
\n\n
Personal data must be collected only for specified, explicit, and legitimate purposes and not further processed in a way incompatible with those purposes.
\n\n
\n\n
The purpose of the processing should be specific and explicit and communicated to data subjects at the time of collection. The functionalities of the app should be set up as such that personal data are only processed for the specific purpose that was identified. Access to servers should be limited to persons that are committed to processing the data for the specified purpose only. If the personal data are to be used for purposes other than those notified, the data should be made anonymous, unless there is another legal basis for this secondary use. In any case, the data subjects should be informed and, unless there is no other legal basis, their consent should be obtained.
\n\n
\n\n
Data quality
\n\n
\n\n
Personal data stored must be accurate and, where necessary, up to date; every reasonable step must be taken to ensure that inaccurate personal data are deleted or rectified without delay.
\n\n
\n\n
The controller must have mechanisms in place to ensure that the data are accurate at the time of collection and are not unlawfully modified after that. There must be a mechanism to correct or delete inaccurate data, possibly by the user of the application.
\n\n
\n\n
Data retention
\n\n
\n\n
Personal data must be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed, unless regulatory or legal requirements require a longer or shorter retention period.
\n\n
\n\n
The controller must define a retention period for each data set, based on the purpose of the processing and, where appropriate, legal and regulatory retention periods. Mechanisms, including automatic solutions, where appropriate, and responsibilities for the effective erasure of the data must also be specified. If the data cannot be deleted, they should be made anonymous or, if this is not possible, pseudonymous.
\n\n
\n\n
Among the key issues are: Does the product allow for flexible data retention periods? Does the product enable the anonymization or deletion of data that is no longer needed? Is the data automatically deleted or anonymised after the retention period has expired? Is the data controller notified in advance by the system? Can users delete the data, and if so, how (e.g., by deactivating the app used)? Is there a retention and deletion concept?
\n\n
\n\n
Data security
\n\n
\n\n
Personal data must be processed in a manner that ensures appropriate security of the data, including protection against unauthorised or unlawful processing and accidental loss, destruction or damage, using appropriate TOMs. Such measures should encompass integrity and confidentiality, availability, resilience, and traceability and ensure a level of security appropriate to the risk.
\n\n
\n\n
Appropriate control access mechanisms and authentication measures should be embedded in the product infrastructure to detect and monitor unauthorised access to the data. Personal data should be encrypted on the device and, if stored on a server or shared with third parties, in transit and storage. Special attention is required if the data are stored in the cloud.
\n\n
\n\n
Privacy rights
\n\n
\n\n
Data subjects have a variety of privacy rights, including the right to information, the right of access, rectification and erasure, restriction of processing, data portability and the right to object to automated individual decision-making. They also have the right to complain with their supervisory authority if they feel that their rights are infringed, or their data are not appropriately protected. A process must be in place to respond to data subjects’ access requests and other privacy rights.
\n\n
\n\n
Among the key issues are: How can data subjects effectively exercise their rights? Does the product allow data subjects to exercise their rights directly through the app, in particular the right to access their data and correct it in case of inaccuracies or to delete the data from the mobile device by deleting the app? Are any rights restricted? How are rights such as data portability, deletion, or withdrawal of consent guaranteed?
\n\n
\n\n
Data processing by third parties and cross-border data transfers
\n\n
\n\n
Depending on the roles of the contributors in the development, management, and use of the app and the data processed, appropriate contractual obligations must be established to ensure data protection.
\n\n
\n\n
The controller must carry out a prior assessment of all data processors to ensure that they implement appropriate TOMs to ensure compliance with the data protection requirements and data subjects’ privacy rights.
\n\n
\n\n
If personal data are to be transferred to third parties outside the EEA in a country without a formal adequacy decision by the European Commission, adequate safeguards, such as EU standard contractual clauses, must be implemented to legitimise cross-border data transfers, unless a derogation as listed in Art. 49 GDPR applies, such as the explicit consent of the data subject.
\n\n
\n\n
For any cross-border data flow, the legal basis for such a transfer must be determined, and the necessary steps taken.
\n\n
\n\n
Accountability
\n\n
\n\n
The controller is responsible for ensuring compliance with the data protection principles and for providing proof of compliance with them. Appropriate processes, regular risk assessments, documentation, and reviews of the processing should be in place to support this obligation.
\n\n
\n\n
5 Conclusion
\n\n
\n\n
To fully exploit the benefits of digital health solutions and ensure their effectiveness, it is essential to embed fundamental data protection principles in the design of these solutions, taking into account organisational, process and product-related risks, as well as risks to the rights of data subjects.
\n\n
\n\n
Privacy by design is not only required by the GDPR and partly by laws of other countries outside the EEA but is a prerequisite for the effective and sustainable implementation of data protection, the basis for a well-functioning data protection management and a critical factor in achieving the necessary trust of the public, patients and consumers, public authorities, business partners and other stakeholders in such technologies.
\n\n
\n","datum":"13.07.2020","teasertext":"
The exponential growth of digital health solutions and products, such as software or internet-enabled devices, brings a range of benefits for patients, the health industry and the general public. To be effective, these technologies rely on the use of large amounts of data. Particular caution is needed when personal data are involved, as the processing of personal data, in particular health-related data, can pose significant risks to the privacy of data subjects and the security of personal data. This article examines the privacy aspects under the GDPR that need to be taken into account when designing digital health solutions. It also attempts to clarify the concept of privacy by design and to translate legal requirements into practical solutions, with a focus on mobile applications in the context of digital health.
\n","preview":"","datei":[],"linkextern":""},{"id":100,"title":"Why should companies invest in Binding Corporate Rules?","slug":"why-should-companies-invest-in-binding-corporate-rules","link":"/en/news-knowledge/why-should-companies-invest-in-binding-corporate-rules","titel":"Why should companies invest in Binding Corporate Rules?","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
1 Introduction
\n\n
\n\n
Article 47 of the EU General Data Protection Regulation (\"GDPR\") expressly recognizes Binding Corporate Rules (\"BCR\") as one of the means for the international transfer of personal data, both for controllers (covering personal data they control) and for processors (covering personal data they process on behalf of others based on a processing agreement). Before the GDPR came into force, BCR were recognized and approved by the current practice of the data protection authorities and the guidelines of the Article 29 Working Party (“Working Party”). Other countries outside of the EU, such as Switzerland, recognize the concept of BCR as well.
\n\n
\n\n
What is the practical significance of BCR for companies and why should companies invest in BCR? This article shall explore what BCR under the GDPR are, what needs to be considered when applying and implementing BCR and their benefits.
\n\n
\n\n
2 What are Binding Corporate Rules?
\n\n
\n\n
The GDPR defines the term “Binding Corporate Rules” in Art. 4 para. 20 as “personal data protection policies which are adhered to by a controller or processor established on the territory of a Member State for transfers or a set of transfers of personal data to a controller or processor in one or more third countries within a group of undertakings, or group of enterprises engaged in a joint economic activity”.
\n\n
\n\n
BCR are therefore one of the appropriate safeguards for the transfer of personal data within a group of undertakings, or group of enterprises engaged in a joint economic activity (“Group”) from the EEA to countries which do not provide an adequate level of data protection. In practice, BCR are a set of internal rules, standards and processes, such as codes of conduct, that regulate internal data management practices in a binding and consistent manner throughout the Group with the primary objective to facilitate the free movement of personal data within that Group while ensuring an effective level of data protection. BCR are, however, not intended to be used as a means for allowing cross-border data transfers to companies not being part of that Group.
\n\n
\n\n
The concept and content of the BCR have mainly remained the same under the GDPR, with some minor changes. One significant change is the extension of the group of applicants. While BCR were previously only applicable to groups of undertakings, they are now also open to groups of enterprises engaged in joint economic activities. The term \"group of undertakings\" is defined in Art. 4 para. 19 GDPR as \"controlling undertaking and its controlled undertakings\". However, the term \"group of enterprises engaged in a joint economic activity\" is not defined in the GDPR. The term is open for interpretations but may be interpreted as to include a group of independent organizations which have agreed to cooperate, such as joint ventures.
\n\n
\n\n
Also, the list of minimum requirements has been extended to include the contact details of each member of the Group, the description of the principles of privacy by design and privacy by default, the right not to be subject to profiling, the information obligations according to Art. 13 and 14 GDPR, and the details of the persons responsible for training and complaint procedures.
\n\n
\n\n
The Working Party provides in WP 256 (BCR for controllers) and WP 257 (BCR for processors) updated guidelines and very useful tables setting out the elements and principles that controllers and processors should state in their BCR, incorporating the new language in line with the GDPR and the necessary content mandated by Art. 47 GDPR and making a distinction between what must be included in the BCR and what must be presented to the competent supervisory authority in the BCR application.
\n\n
\n\n
BCR must comply with a whole range of requirements and must contain all elements as set out in Art. 47 para. 2 GDPR, including:
\n\n
\n\n
\n
The structure and contact details of the group of undertakings, or group of enterprises engaged in a joint economic activity and of each of its members;
\n
\n\n
\n\n
\n
The data transfers or set of transfers, including the categories of personal data, the type of processing and its purposes, the type of data subjects affected and the identification of the third country or countries in question;
\n
\n\n
\n\n
\n
Their legally binding nature, both internally and externally;
\n
\n\n
\n\n
\n
The application of the general data protection principles, in particular purpose limitation, data minimization, limited storage periods, data quality, data protection by design and by default, legal basis for processing, processing of special categories of personal data, measures to ensure data security, and the requirements in respect of onward transfers to bodies not bound by the BCR;
\n
\n\n
\n\n
\n
The rights of data subjects in regard of processing and the means to exercise those rights, including the right not to be subject to decision based solely on automated processing, including profiling, the right to lodge a complaint with the competent supervisory authority and before the competent courts, and to obtain redress and, where appropriate, compensation for a breach of the BCR;
\n
\n\n
\n\n
\n
The acceptance by the controller or processor established on the territory of a Member State of liability for any breaches of the BCR by any member concerned not established in the Union, whereby the controller and the processor shall be exempt from that liability, in whole or in part, only if it proves that that member is not responsible for the event giving rise to the damage;
\n
\n\n
\n\n
\n
How the information on the BCR, in particular on the provisions relating to the general data protection principles, the rights of the data subjects, and the liability for any breaches of the BCR is provided to the data subjects;
\n
\n\n
\n\n
\n
The tasks of any data protection officer designated in accordance with Art. 37 GDPR or any other person or entity in charge of monitoring compliance with the BCR as well as monitoring training and complaint handling;
\n
\n\n
\n\n
\n
The complaint procedures;
\n
\n\n
\n\n
\n
The mechanisms for ensuring verification of compliance with the BCR. Such mechanisms shall include data protection audits and methods for ensuring corrective actions to protect the rights of the data subject. Results of such verification should be communicated to the DPO or any other person in charge of monitoring compliance with the BCR and to the board of the controlling undertaking, and should be available upon request to the competent supervisory authority;
\n
\n\n
\n\n
\n
The mechanisms for reporting and recording changes to the BCR and reporting those changes to the supervisory authority;
\n
\n\n
\n\n
\n
The cooperation mechanisms with the supervisory authority to ensure compliance by any member of the group of undertakings, or group of enterprises engaged in a joint economic activity, in particular by making available to the supervisory authority the results of verifications;
\n
\n\n
\n\n
\n
The mechanisms for reporting to the competent supervisory authority any legal requirements to which a member of the group of undertakings, or group of enterprises engaged in a joint economic activity is subject in a third country which are likely to have substantial adverse effect on the guarantees provided by the BCR; and
\n
\n\n
\n\n
\n
The appropriate data protection training to personnel having permanent or regular access to personal data.
\n
\n\n
\n\n
3 What do companies commit themselves to when signing the BCR?
\n\n
\n\n
By signing the BCR, companies undertake to comply with and implement the rules, in particular to:
\n\n
\n\n
\n
set up a procedure for managing and monitoring the implementation of the BCRs;
\n
\n\n
\n\n
\n
make the BCR binding on employees;
\n
\n\n
\n\n
\n
make the rights of data subjects easily accessible, as set out in the BCR, e.g. via the intranet and the Internet;
\n
\n\n
\n\n
\n
introduce disciplinary procedures for staff who infringe the BCRs;
\n
\n\n
\n\n
\n
comply with the data protection principles as set out in the BCR;
\n
\n\n
\n\n
\n
provide basic training for all employees and specific training for employees with regular access to personal data;
\n
\n\n
\n\n
\n
carry out regular compliance assessments on data protection to ensure the effective application of the BCR;
\n
\n\n
\n\n
\n
establish a procedure to ensure adequate handling of complaints;
\n
\n\n
\n\n
\n
accept liability for any breach of its obligations under the BCR;
\n
\n\n
\n\n
\n
cooperate with other Group companies and support them in dealing appropriately with inquiries from supervisory authorities or other authorities as well as from data subjects; and
\n
\n\n
\n\n
\n
cooperate with and allow audits by the relevant regulatory authorities.
\n
\n\n
\n\n
4 What should organizations consider before applying for BCR?
\n\n
\n\n
The use of BCR as an appropriate safeguard for international data transfers from the EEA requires the approval of the competent supervisory authority in the relevant jurisdiction following the consistency mechanism set out in Art. 63 and 64 GDPR. The competent supervisory authority will approve the BCR under the condition that:
\n\n
\n\n
\n
BCR are legally binding and enforceable on the undertakings concerned;
\n
\n\n
\n\n
\n
BCR expressly confer on the data subjects’ enforceable rights concerning the processing of their personal data; and
\n
\n\n
\n\n
\n
BCR comply with the minimum information requirements set out in Art. 47 para. 2 GDPR.
\n
\n\n
\n\n
Before applying for BCR approval, an organization should carefully consider and answer some key questions:
\n\n
\n\n
What does the company want to achieve with the approved BCR?
\n\n
\n\n
Is the only objective to facilitate the free flow of personal data within the Group? If so, has the organization considered alternatives, if any, to achieve this objective, such as concluding an intra-group data transfer agreement (“IGDTA”)? Alternatively, is the company's goal, besides safeguarding cross-border data transfers, also to achieve and demonstrate accountability and commitment to responsible data use? If so, the organization should assess whether BCR are the right approach or whether there are other options such as certification or a code of conduct, which might be more suitable for achieving the interests of the organization.
\n\n
\n\n
Which BCR should be implemented?
\n\n
\n\n
The organization must determine if it wants to apply for BCR for controllers or BCR for processors, or both. Depending on that decision, the appropriate requirements must be fulfilled.
\n\n
\n\n
What shall be the scope of the BCR?
\n\n
\n\n
Shall the BCR only cover personal data transferred from the EEA within the Group or shall they cover all processing of personal data within the Group? This last option would include any data and go far beyond the legal requirements extending the liability and privacy rights. This extension is ultimately a decision that each organization must take and may be appropriate for organizations that have decided to establish the same set of rules, standards and rights throughout the whole organization, irrespective of the jurisdiction and legal requirements. The organization must also determine if it wants to cover all personal data or limit the BCR to only a set of data such as HR or customer data. Finally, the organization must determine if all members of the Group shall be bound by the BCR or only a selected number of companies.
\n\n
\n\n
Which supervisory authority should be the lead authority for the BCR (“BCR Lead”)?
\n\n
\n\n
The BCR Lead is the authority that acts as the single point of contact with the applicant organization during the authorization procedure and the application process in its cooperation phase. The BCR Lead may differ from the \"one-stop-shop\" lead supervisory authority according to Art. 56 GDPR, which is mainly involved in handling data breaches and investigatory or enforcement activities in cross-border processing operations within the EU. The organization applying for BCR authorization must justify the reasons why a particular supervisory authority should be considered as the BCR Lead. The criteria for such justification are set out in WP 263:
\n\n
\n\n
\n
The location of the Group’s European headquarters;
\n
\n\n
\n\n
\n
The location of the company within the Group with delegated data protection responsibilities;
\n
\n\n
\n\n
\n
The location of the company which is best placed (in terms of the management function, administrative burden, etc.) to deal with the application and to enforce the BCR in the Group;
\n
\n\n
\n\n
\n
The place where most decisions in terms of the purposes and the means of the processing (i.e. transfer) take place; and
\n
\n\n
\n\n
\n
The member state within the EU from which most or all transfers outside the EEA will take place.
\n
\n\n
\n\n
For companies with their head office or principal place of business in the EU, the justification is quite simple. However, how should companies with their registered office outside the EU and without a principal place of business in the EU choose the appropriate supervisory authority and justify their choice? What arguments could be put forward if there is no Member State within the EU from which most or all transfers are made outside the EEA, but such transfers are roughly the same between all entities in the EU? In this case, the organization may delegate responsibilities to the Group company that is best placed to process the application for BCR on behalf of the Group. This entity should be located in one of the most important countries for the Group with a strong presence and at the same place as the chosen supervisory authority.
\n\n
\n\n
Once the organization has selected the BCR Lead based on the criteria mentioned above, it will submit its application to that supervisory authority. It should be noted, however, that the selected supervisory authority is not obliged to accept the choice if it believes that another supervisory authority is more suitable to be the BCR Lead, in particular taking into account the workload and number of pending BCR applications. The requested supervisory authority will share the application with all concerned supervisory authorities to make a final decision on which supervisory authority is appointed as BCR Lead.
\n\n
\n\n
It is advisable that the organization contacts the selected supervisory authority before applying to check whether the supervisory authority is, in principle, willing to act as BCR Lead or whether there may be objections from the supervisory authority, for example, due to lack of resources to deal with the application in a timely manner.
\n\n
\n\n
What should the liability system look like?
\n\n
\n\n
Art. 47 para. 2f requires the acceptance by the controller or processor established on the territory of a Member State of liability for any breaches of the BCR by any member concerned not established in the Union. WP 256 and WP 257 provide that, where it is not possible for a Group with particular corporate structures to impose on a specific entity to take all the responsibility for any breach of the BCR outside of the EU, it may provide that every BCR member exporting data out of the EU on the basis of the BCR will be liable for any breaches of the BCR by the BCR member established outside the EU which received the data from this EU BCR member. Will it be acceptable for the BCR Lead to introduce an alternative liability system in line with the Standard Contractual Clauses? If not, which Group company could take responsibility? What are the options? Clarification of this issue is crucial, especially for companies based outside the EU which do not have a main establishment in the EU. For some organizations, it may not be feasible to allocate responsibility for the payment of damages to a local entity as a result of a breach of the BCR by a Group company outside the EU.
\n\n
\n\n
What is the implementation status of the data privacy management program within the organization?
\n\n
\n\n
Has the organization already implemented global standards, policies and procedures, and if so, what is the maturity level at the corporate level and throughout the organization? Where are potential gaps and risks? Depending on the groundwork done and the maturity level of the data protection management program, the BCR approval process may take longer or shorter.
\n\n
\n\n
Is the buy-in of key stakeholders secured?
\n\n
\n\n
Do key stakeholders, from executive management to key country organizations and functions, offer their buy-in to the process? Stakeholder support requires their awareness and understanding of the need and benefits of implementing BCR, the commitments that each business unit and function must make with BCR approval, and the expectations placed in them. Preliminary discussions and presentation of the business case with these stakeholders are therefore an essential step before applying for BCR.
\n\n
\n\n
Are there sufficient resources and expertise to manage the approval and implementation of BCR?
\n\n
\n\n
Is there a team in place to develop the BCR, collect all relevant information, involve the relevant functions, discuss with the BCR Lead and manage the communication and implementation of the BCR across the organization? This team may consist of a leader and project manager as well as contributors to critical functions and most important markets. A proper functioning internal team is crucial to a smooth approval process and implementation throughout the organization. For smaller companies with fewer resources and expertise in data protection and project management, the involvement of external experts should be considered.
\n\n
\n\n
5 What should organizations consider once BCR approval is obtained?
\n\n
\n\n
The approval of the BCR is an essential step in the whole process. However, the BCR have no practical effect if not correctly implemented throughout the Group. Therefore, in parallel to the approval process, it is crucial that the organization that is responsible for the implementation of the BCR puts in place a concrete and enforceable communication and implementation plan with responsibilities and reasonable timelines. Here are some suggestions as to what such a plan should at least contain:
\n\n
\n\n
A communication plan that sets out who should inform whom, how, when and about what during the whole process. When applying for BCR approval, all Group companies and functions at the corporate and local level should be informed of the content and impact of the BCR, in particular their obligations, and of the progress of the BCR approval process. They should also be informed of the steps they need to take before approval to best prepare for the implementation of the BCR. Throughout the process, it is also advisable to address possible problems, questions and concerns to ensure the broadest possible support and to prevent serious issues or concerns from arising following the approval of the BCR. In some countries, works councils must also be informed or consulted, and finally, once approved and implemented, all employees who regularly process personal data must be informed and trained. Clear roles and responsibilities must be assigned to ensure appropriate communication at each level of the organization.
\n\n
\n\n
An implementation plan that is addressed to those functions and individuals responsible for implementing the privacy management program and the BCR, in practice the data protection officers, managers or champions, and outlines what needs to be done, when and how. The steps may include the preparation by adopting the Group privacy policy framework and implementing the data protection management program at the local level, signing the BCR and making them binding upon employees, training employees, verifying compliance with the BCR and handling complaints.
\n\n
\n\n
Effective BCR require the establishment of an organization with responsible persons at corporate and local level to implement the BCR and monitor compliance. A person at corporate level should be appointed to maintain an updated list of BCR members, monitor the state of implementation and any changes, and report annually to the supervisory authority.
\n\n
\n\n
6 Why should organizations invest in BCR?
\n\n
\n\n
In practice, many companies have concluded so-called intra-group data transfer agreements (“IGDTA”) covering the cross-border transfer of personal data within their Group. So why should companies go through the effort of implementing BCR when they can achieve the same goal with an IGDTA? Companies with an IGDTA meet the legal requirements for cross-border data transfer. However, they may not benefit from the impact of BCR, which significantly increase awareness and understanding of privacy requirements within the organization and establish accountability for compliance with data protection requirements in each function and business unit at corporate and local levels throughout the organization. Also, the effort required to create an IGDTA that includes the evaluation of all types of data flows, categories of personal data, purposes and safeguards, as well as the recipients of the data, the documentation of this information, the possible translation into the local language and the signing of contracts by all affiliates, should not be underestimated. It requires the involvement of all business units and functions at global and local levels. At the same time, the IGDTA often remains in a drawer after signing and is never considered again. Rarely will companies implement an IGDTA by establishing appropriate policies, procedures, processes and training.
\n\n
\n\n
Organizations that develop and implement BCR regularly aim at achieving an appropriate data protection governance structure with uniform standards and processes across the enterprise and not only at transferring their data legitimately within the Group. With the approval of the BCR by the supervisory authorities, organizations also want to show that they not only take data protection seriously, but also effectively implement the requirements in the company and assume responsibility for compliance with data protection.
\n\n
\n\n
BCR are based on a comprehensive and effective data protection management program with all the elements required to demonstrate accountability. These elements include:
\n\n
\n\n
\n
A governance structure with leadership and oversight of the data protection program;
\n
\n\n
\n\n
\n
A policy framework with policies and procedures to ensure fair and responsible processing of personal data;
\n
\n\n
\n\n
\n
Transparency through appropriate communication to data subjects;
\n
\n\n
\n\n
\n
Risk assessment and management at the program and data processing level;
\n
\n\n
\n\n
\n
Awareness raising and training of employees and others who process personal data;
\n
\n\n
\n\n
\n
Monitoring compliance with the data protection program and verification of its effectiveness through regular self-assessments and internal or external audits; and
\n
\n\n
\n\n
\n
Processes to adequately respond to data subjects' rights, complaints and inquiries, as well as privacy incidents and to enforce compliance with internal rules.
\n
\n\n
\n\n
Organizations subject to the GDPR and other stringent data protection acts must establish a comprehensive data protection management program including all the elements as listed above to ensure compliance with the applicable requirements and responsible data use. With the implementation of such a privacy management program organization are ready to consider applying for BCR approval in order to benefit from a valid data transfer mechanism while increasing their commitment to privacy within the company and promoting a culture of responsible data use.
\n\n
\n\n
To obtain approval of the BCR and ensure compliance with the commitments that are made with the application, the data privacy management program must, however, include specific procedures and processes. The organization must assign responsibilities for the implementation of the BCR to each BCR member, in particular for binding the company and its employees to the BCR and for publishing notices. It must further establish a complaint handling process, develop awareness-raising and training plans and have a mechanism to implement these plans, such as the introduction of regular e-learning for all employees and tailor-made training for specific functions and persons with data protection responsibilities. The organization must also establish an audit framework and a program to ensure that internal or external accredited auditors regularly verify compliance with the BCR. A mechanism must also be put in place to track all changes and inform BCR members and the supervisory authority. A list of BCR members must be maintained and made available to all members who are required to inspect that list before transferring personal data across borders.
\n\n
\n\n
BCR are ultimately a formalization and publication of the data protection management program. At the same time, they are a mechanism for demonstrating accountability to regulators, business partners, customers and individuals and integrating data protection and security into the company's culture. Processors also gain an immediate competitive advantage compared to other service providers that do not have BCR. The benefits of BCR are apparent and should be considered by any multinational company with cross-border data flows.
\n\n
\n\n
7 Conclusions
\n\n
\n\n
BCR are not only a sustainable legal basis for data transfer but also a system that enables companies with approved BCR to be transparent to regulators, customers, consumers and business partners by disclosing the company's policies and procedures on how they process and secure personal data. At the same time, BCR help organizations demonstrate that they take data protection seriously and that they have adopted appropriate data management practices to ensure compliant and responsible data processing throughout the Group. By implementing BCR, organizations affirm their responsibility to comply with legal requirements and regularly go even beyond by implementing common standards and rights for individuals across the Group. BCR help to further improve the quality and maturity of the Group's privacy management program by fostering a culture of internal compliance and accountability and strengthening the overall trust of individuals, customers, business partners and regulators.
\n\n
\n\n
Implementing BCR brings a whole range of benefits not only for the Group itself but also for the data subjects and the supervisory authorities. The effort involved in the approval and implementation process pays off in any case, measured by the advantages for multinational companies, large or small, which stand for the legally compliant and responsible handling of personal data. At the same time, and as further motivation for companies to invest in BCR, it would be desirable for supervisory authorities to formally recognize BCR as an accountability system beyond a data transfer mechanism, along with certifications and codes of conduct, and to find ways to further speed up the approval process.
\n\n
\n","datum":"30.06.2019","teasertext":"
What is the practical significance of BCR for companies and why should companies invest in BCR? This article explores what BCR under the GDPR are, what needs to be considered when applying and implementing BCR, and their benefits.
\n","preview":"","datei":[],"linkextern":""},{"id":157,"title":"Implementing Privacy by Design in practice","slug":"implementing-privacy-by-design-in-practice","link":"/en/news-knowledge/implementing-privacy-by-design-in-practice","titel":"Implementing Privacy by Design in practice","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
1 Introduction
\n\n
\n\n
Data protection has become increasingly important in recent years. Not only have the EU and many countries around the world revised their data protection laws and introduced stricter rules to protect the rights of data subjects and significant sanctions for non-compliance with the law. The awareness and expectations of individuals, such as consumers, patients, employees, service providers and business partners, as well as public authorities, have also increased significantly. While until a few years ago data protection was hardly on the priority list of many companies and hardly any resources were spent on implementing the legal requirements, most companies have realized since the introduction of the EU General Data Protection Regulation (GDPR) that data protection is a serious issue.
\n\n
\n\n
The reason for the increased sensitivity to data protection is not only the threat of sanctions and the loss of reputation in the event of a breach of data protection regulations. Companies have understood that they can only take full advantage of new technologies such as Blockchain, Machine Learning, Artificial Intelligence, Internet of Things and Mobile Apps if they meet individuals' expectations, maintain their trust and respect their privacy. Today, data protection is no longer seen as just a compliance or information security issue, but as an essential factor in building and maintaining trust, competitiveness and success in the marketplace.
\n\n
\n\n
Organizations must know and foresee their risks and take appropriate measures to eliminate them, reduce them to an acceptable level or manage them. To this end, organizations must, first of all, know what personal data they store and process, in which business areas, in which systems and for what purposes. This knowledge is the fundamental prerequisite for active risk and data protection management.
\n\n
\n\n
Before processing personal data, companies must take into account the data protection aspects and principles as well as possible restrictions and risks in advance and take appropriate risk-minimizing measures. Such an assessment is necessary, for example, before the introduction of a new data-processing system or a health app or before the storage of particularly sensitive data in a cloud, the introduction of a monitoring system in the company or the outsourcing of data processing to a service provider in a country outside the EEA or Switzerland. With this approach, the company can not only ensure compliance with legal requirements, but also make strategic and operational decisions in advance and efficiently implement business processes. This can include, for example, storing data on servers in Switzerland instead of in the USA or purchasing software with integrated data protection principles. The company can also take the necessary steps to ensure that its privacy policies and applicable laws are implemented.
\n\n
\n\n
This procedure is nothing more than “privacy by design.”
\n\n
\n\n
2 Privacy by design: a new obligation for controllers
\n\n
\n\n
The EU General Data Protection Regulation (GDPR) has introduced a legal obligation for controllers referred to as “data protection by design and by default.” This principle requires the controller to implement appropriate technical and organizational measures designed to implement data protection principles into the processing of personal data in an effective manner. Failures to comply with this obligation are subject to significant fines following Art. 83 GDPR.
\n\n
\n\n
Further laws have introduced the concept of privacy by design, such as the Draft Swiss Federal Act on Data Protection, published on September 15, 2017 (D-FADP)1 or the new Indian Personal Data Protection Bill which was published in 2018.2 The concept has further been introduced, although not explicitly, in the new Brazilian General Data Protection Law (Lei Geral de Proteção de Dados, LGPD) which will come into effect in early 2020.3
\n\n
\n\n
The concept of privacy by design is a fundamental requirement for the effective implementation of data protection. Privacy by design essentially requires controllers to take into account the privacy principles and requirements both, at the design stage of any IT system and technology, business practice, service or product and throughout the whole life cycle of the personal data, and to embed appropriate technical and organizational measures to implement the data protection requirements and to protect the rights of data subjects.
\n\n
\n\n
Although implementing data protection by design has become a new obligation under the GDPR, the concept is not new. It had existed for a long time as best practice and served as a practical approach to those organizations that had implemented data protection principles before the GDPR was even drafted.
\n\n
\n\n
The concept was already indirectly considered in EU Directive 95/464 and then introduced in 2009 as “Privacy by Design” by Ann Cavoukian, at that time the Information and Privacy Commissioner of Ontario, Canada, building on seven basic principles5:
\n\n
\n\n
Be Proactive, not Reactive; Preventative not Remedial: Being proactive and preventative anticipates and prevents privacy invasive events before they happen and privacy risks before they materialize.
\n\n
\n\n
Privacy as the Default: Privacy, in particular, transparency, data minimization, purpose limitation, confidentiality and data retention, is built into filing systems and business processes by default, automatically protecting personal data without the need for the data subjects to become active.
\n\n
\n\n
Privacy Embedded into Design: Privacy is embedded into the design and architecture of IT systems and business practices in a holistic and integrative way becoming an essential component of the core functionality being delivered. This means that privacy is integral to the system, without diminishing its functionality.
\n\n
\n\n
Full Functionality – Positive-Sum, not Zero-Sum: All legitimate interests and objectives, and not only the privacy goals, shall be accommodated without unnecessary trade-offs. Creative solutions shall be found that enable multifunctionality.
\n\n
\n\n
End-to-End Security – Lifecycle Protection: Personal data shall be secured, depending on their level of sensibility, from the collection throughout the entire lifecycle, by strong technical and organizational measures such as appropriate encryption, strong access controls and logging methods.
\n\n
\n\n
Visibility and Transparency: Visibility and transparency about the processing operations are essential to establishing accountability and trust.
\n\n
\n\n
Respect for User Privacy: The privacy of individuals should remain at the center of the interest and individuals should be offered measures such as strong privacy defaults, appropriate notice, and empowering user-friendly options.
\n\n
\n\n
Privacy by design was finally recognized by the 32nd International Conference of Data Protection and Privacy Commissioners in 2010 as “an essential component of fundamental privacy provisions6” and can also be found in various other documents, such as the FDPICs guide to technical and organizational measures for data protection of 2015.7 A similar concept, “Security by Design” follows the same approach and can be found in standards such as ISO/IEC/27001.
\n\n
\n\n
By introducing the concept of privacy by design as a legal obligation, the legislator ultimately wants to make it clear that it is not enough to set standards, but that these standards must be implemented effectively and verifiably. The principle applies to the entire processing of personal data, whether in the development and implementation of new business processes, systems, services or products that process personal data in any way.
\n\n
\n\n
3 How to implement privacy by design in practice?
\n\n
\n\n
3.1 What does Article 25 GDPR say?
\n\n
\n\n
Article 25 GDPR describes the concept of privacy by design and covers the following questions:
\n\n
\n\n
\n
Who is obliged to implement privacy by design? The controller. Manufacturers of products and applications as well as service providers are only encouraged to consider privacy by design in recital 78 GDPR. In practice, however, manufacturers and service providers will have a keen interest in implementing the concept to remain competitive.
\n
\n\n
\n\n
\n
What needs to be done? The controller must implement technical and organizational measures, so-called TOMs, such as the pseudonymization of personal data.
\n
\n\n
\n\n
\n
How must the TOMs be? They must be adequate8 and appropriate to implement data protection principles such as data minimization effectively and to integrate the necessary safeguards into the processing to meet the requirements of the GDPR and to protect the rights of data subjects.
\n
\n\n
\n\n
\n
When must TOMs be implemented? Both at the time of determining the means for processing and during the processing itself.
\n
\n\n
\n\n
Article 25 GDPR does, however, not specify how this obligation is to be implemented in practice.
\n\n
\n\n
The mention of pseudonymization in Art. 25 GDPR can only be understood as an example of a technical measure. Further technical measures, such as access authorizations and restrictions, user authentication, access restrictions, encryption, logging, secure system configurations, protective measures against malware and data loss, physical protective measures, as well as a technical implementation of the right of objection and the correction or deletion of data or data portability must also be considered. Article 32 GDPR (and in Switzerland Art. 7 FADP) must be observed.
\n\n
\n\n
Furthermore, organizational measures must also be taken. These include, for example, policies, guidelines, instructions and manuals, records of processing activities, documentation of data breaches and data protection impact assessments, contracts with third parties and processors, training and controls, meaning all the elements that are necessary for a well-functioning data protection management system.
\n\n
\n\n
The technical and organizational measures must be suitable for implementing the data protection principles and safeguarding the rights of the data subjects, whereby data minimization is again only mentioned as one example. Of course, all other principles, such as lawfulness, transparency, confidentiality, purpose limitation, data integrity, storage duration and security, as well as the requirements concerning commissioned data processing and cross-border data transfers must also be taken into account.
\n\n
\n\n
3.2 How can Article 25 GDPR be implemented in practice?
\n\n
\n\n
One effective way to implement privacy by design in practice is to build a data management and risk assessment program with responsibilities and a process to identify systematically, evaluate, address and mitigate potential privacy and security risks associated with the collection and processing of personal data. The seven best practices principles described in Chapter 2 can serve as guidance for the implementation of data protection by design in the company. An effective data management and risk assessment program should include the following elements:
\n\n
\n\n
3.2.1 Data Protection Management System (Fig.1)
\n\n
\n\n
\n
A documented commitment by management to establish and enforce high standards of data protection for the company with the aim of integrating data protection into the corporate culture and embedding the data protection principles in the design and implementation of corporate policies, data protection management systems, business practices, services and products.
\n
\n\n
\n\n
\n
The appointment of a data protection advisor and allocation of responsibilities at all levels of the organization, including management, business units and functions, for the effective implementation of data protection requirements.
\n
\n\n
\n\n
\n
The establishment of a data protection framework with enforceable data protection policies and guidelines that attach appropriate importance to data protection and regulate the collection, processing, transfer, storage and deletion of data, as well as mechanisms to monitor implementation and compliance with standards and rules.
\n
\n\n
\n\n
\n
The application of appropriate processes to ensure that data protection principles and requirements are adequately taken into account and integrated into data processing procedures and thus the principle of privacy by design is lived.
\n
\n\n
\n\n
\n
The introduction of records of processing activities.
\n
\n\n
\n\n
\n
Risk management with compliance checks and, where appropriate, data protection impact assessment.
\n
\n\n
\n\n
\n
Third-party management and data transfer governance.
\n
\n\n
\n\n
\n
Regular and documented awareness campaigns and performance of employee training.
\n
\n\n
\n\n
\n
Regular and documented monitoring and controls through self-assessments and audits to verify the effective implementation of the data protection management program and compliance with legal requirements and internal policies and directives.
\n
\n\n
\n\n
3.2.2 Processes
\n\n
\n\n
The processes, as mentioned above, include the following elements:
\n\n
\n\n
\n
The allocation of responsibilities in the relevant functions, such as Procurement, Legal and IT, which, as “gatekeepers,” ensure that the processes are adhered to.
\n
\n\n
\n\n
\n
The identification of privacy risks relating to systems, websites, apps, business processes or products at the time of the design and throughout the lifecycle of the data, from collection to disposal.
\n
\n\n
\n\n
\n
The documentation of the data processing activities (inventory).
\n
\n\n
\n\n
\n
The performance of compliance and risk assessments and, where appropriate, DPIAs before personal data is collected and stored in systems, transferred or otherwise processed for business purposes of anticipating risks and adverse effects for the individuals concerned and to determine corrective actions.
\n
\n\n
\n\n
\n
The implementation of the identified measures.
\n
\n\n
\n\n
3.2.3 Risk Management
\n\n
\n\n
The conformity and risk assessment of data processing procedures is essential in the privacy by design process and answers questions such as:
\n\n
\n\n
\n
Is the purpose of the processing specifically described? How is it ensured that the data is not processed for other purposes?
\n
\n\n
\n\n
\n
What is the legal basis for the processing of personal data? Is the consent of the data subjects required and, if so, how should it be obtained and documented? How can a withdrawal of consent be asserted and how is it handled and documented? If the controller has a legitimate business interest, were the interests of the controller weighed against the interests of the data subjects? Has this balancing test of interests been documented?
\n
\n\n
\n\n
\n
Are all intended personal data necessary to fulfill the purpose or can specific data sets be omitted if necessary? Can the purpose also be accomplished with anonymous, pseudonymous or simply less data?
\n
\n\n
\n\n
\n
Are the systems, websites, apps, business processes and products which store or process personal data, and which are developed or purchased by the company set up in such a way that only the necessary data for the purpose in question is stored and processed? How is the accuracy of the data ensured?
\n
\n\n
\n\n
\n
Who should have access to which personal data and for what purposes? Is the group of people who should have access to the data defined and documented? Are these persons obliged to maintain confidentiality? How is access controlled and restricted?
\n
\n\n
\n\n
\n
Have processors, if any, been audited to ensure that they can comply with data protection requirements?
\n
\n\n
\n\n
\n
Are data processing agreements and other arrangements in place, where necessary, to govern the relationship with third parties?
\n
\n\n
\n\n
\n
Is personal data accessed from abroad or transferred abroad? If so, have suitable legal measures been taken and documented to legitimize the data transfer? How are the measures implemented and compliance monitored?
\n
\n\n
\n\n
\n
Are all necessary security measures planned and, if necessary, already implemented?
\n
\n\n
\n\n
\n
What rights do the data subjects have? Are there any restrictions? How is it ensured that data subjects could exercise their rights effectively? Who is responsible for responding to data subjects requests? How are rights such as data portability, deletion or revocation of consent guaranteed?
\n
\n\n
\n\n
\n
How long should personal data be stored and processed? Is there a retention and deletion concept?
\n
\n\n
\n\n
\n
Are the data subjects informed about the processing of their personal data or is notice planned and how is it to be carried out? Is the data protection notice easily understandable and accessible?
\n
\n\n
\n\n
\n
What technical and organizational measures are expected to secure the data and how are these measures to be implemented, verified and controlled?
\n
\n\n
\n\n
\n
What security measures are taken to avoid security incidents? What is the process in the event of a security incident?
\n
\n\n
\n\n
4 Conclusion
\n\n
\n\n
Consistent and sustainable compliance with data protection requires the strategic and conceptual integration of data protection principles in all business practices, in the organizational structure, in the development of rules, IT systems and products. It requires active cooperation between Business, Information Security / IT and Legal / Data Protection.
\n\n
\n\n
The concept privacy by design is not new and has been considered as best practice for years. New is the inclusion of the concept in the GDPR as a legal obligation for controllers, subject to sanctions if violated.
\n\n
\n\n
Privacy by design is, however, not only a legal obligation but also a fundamental prerequisite for the effective and sustainable implementation of data protection and the basis for a well-functioning data protection management.
\n\n
\n\n
\n\n
[1]Art. 6.1, 2 D-FADP: Data Protection by Design: The controller must set up technical and organizational measures in order for the data processing to meet the data protection regulations and in particular the principles set out in Art. 5 (general principles of lawfulness, proportionality, purpose limitation, data minimization, transparency, retention, and quality). It considers this obligation from the planning of the processing.
\n\n
The technical and organizational measures must be appropriate in particular with regard to the state of the art, the type and extent of processing, as well as the risks that the processing at hand poses to the personality and the fundamental rights of the data subjects.
\n\n
Art. 6.3 D-FADP: Data Protection by Default: The controller is additionally bound to ensure through appropriate predefined settings that the processing of the personal data is limited to the minimum required by the purpose, unless the data subject directs otherwise.
[4]Recital 46 Directive 95/46: Whereas the protection of the rights and freedoms of data subjects with regard to the processing of personal data requires that appropriate technical and organizational measures be taken, both at the time of the design of the processing system and at the time of the processing itself, particularly in order to maintain security and thereby to prevent any unauthorized processing; whereas it is incumbent on the Member States to ensure that controllers comply with these measures; whereas these measures must ensure an appropriate level of security, taking into account the state of the art and the costs of their implementation in relation to the risks inherent in the processing and the nature of the data to be protected.
\n\n
\n\n
[5] Privacy by Design: The 7 Foundational Principles, Implementation and Mapping of Fair Information Practices, from Ann Cavoukian, Ph.D.
\n\n
\n\n
[6] Resolution on privacy by design: https://icdppc.org/document-archive/adopted-resolutions/
[8] Article 25.1 GDPR: “Taking into account the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing.”
\n","datum":"25.03.2019","teasertext":"
The EU General Data Protection Regulation (GDPR) has introduced a legal obligation for controllers referred to as “data protection by design and by default.” This principle requires the controller to take appropriate technical and organizational measures designed to embed data protection principles into the processing of personal data in an effective manner. This article explains how to implement Privacy by Design in practice.
\n","preview":"","datei":[],"linkextern":""},{"id":158,"title":"The concept of controller and processor in practice","slug":"das-konzept-des-verantwortlichen-und-des-auftragsverarbeiters-in-der-praxis","link":"/en/news-knowledge/das-konzept-des-verantwortlichen-und-des-auftragsverarbeiters-in-der-praxis","titel":"The concept of controller and processor in practice","text":"
To download the article in PDF format, please click here.
\n\n
\n\n
1 Introduction
\n\n
\n\n
If several persons are involved in the processing of personal data, the question inevitably arises as to their data-protection-related role. With the introduction of the GDPR and the provisions regarding the relationship of controllers and processors in article 28 and joint controllers in article 26, the difficulties in determining the correct roles of the parties remain. Organizations are increasingly faced with the challenge of determining their role(s), in particular in complex situations and business models where multiple parties in different jurisdictions are involved in the processing activity, each with varying degrees of autonomy, control and responsibility.
\n\n
\n\n
The distinction between the different roles is crucial to allocate responsibilities, and in particular to determine which party must primarily comply with the data protection principles, data subjects’ privacy rights and notification obligations. The distinction is further essential to determine the applicable law in a cross-border context, the contractual arrangements, and the allocation of liability for damages resulting from unlawful processing.
\n\n
\n\n
Following the GDPR, each person that processes personal data is, from a data protection perspective, either a controller or a processor. If several controllers are involved in the processing of personal data, they are, depending on the concrete situation, either joint controllers or independent controllers. The GDPR defines in article 4 the terms “controller,” “processor,” and “processing,” and in article 26 the concept of “joint controller:”
\n\n
\n\n
The “controller” is the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data.
\n\n
\n\n
“Joint controllers” are controllers that jointly determine what data shall be processed for what purpose and by which means.
\n\n
\n\n
The “processor” is the natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller.
\n\n
\n\n
The term “processing” covers any operation or set of operations which is performed on personal data, whether or not by automated means, such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction.
\n\n
\n\n
The term independent controllers is not defined in the GDPR. The term, as used in this article, means controllers that, differently than joint controllers, do not determine the purposes and means jointly for the processing of personal data, but each for itself for own and different purposes from each other.
\n\n
\n\n
In this article, we will explore the essential factors for determining the roles of the parties, and in particular the relationship between customers and service providers, and their consequences.1
\n\n
\n\n
2 The essential factors for determining the role(s) of the parties
\n\n
\n\n
2.1 The essential factors
\n\n
\n\n
The principal factors for determining if a party is a controller, joint controller or a processor are on the one hand the degree of autonomy of each person in determining for what purposes, how and in what manner personal data is processed, and on the other hand the degree of control over the content of personal data. Such determination is always a factual one and must be taken on a case-by-case basis considering each specific processing operation.
\n\n
\n\n
In a first step, however, it must be assessed whether the organization that is holding personal data “processes” such data, and if so, in which ways. While the definition of “processing” is pervasive and covers anything that is done with personal data, there are situations where an organization holding personal data does not qualify as neither a controller nor a processor because it does not process the data in the sense of the law. The ICO provides an example2, where a courier service is contracted by a local hospital to deliver envelopes containing patient’s medical records to other health service institutions. While the courier is in physical possession of the personal data, it does not process the data contained in the letters, since it may not open the mail to access any personal data or other content. Processing personal data implies a degree of access to or the ability to control the use of the data itself. The physical possession of the letters containing personal data is not sufficient. The organization that chooses to use the delivery services to transfer personal data is the controller in this scenario and is responsible for complying with the requirements under the GDPR, and, in particular, to organize such services in such a way that the personal data are adequately protected and, if necessary, an obligation of confidentiality is in place. The critical factor in this case is that the service provider has no plan, intention and interest to process the personal data.
\n\n
\n\n
The mail delivery service will, however, be a controller in its own right in respect to any personal data such as, for example, individual senders’ and recipients’ names and addresses it holds to arrange delivery or tracking.
\n\n
\n\n
2.2 Controller
\n\n
\n\n
An organization is a controller if, through its managers and staff, it decides why and how personal data shall be processed and therefore controls the overall purposes and means of data processing. As a general rule, the legal entity is considered the controller rather than the individual that acts on behalf of the legal entity.3 The capacity for determining the purposes and means of processing may derive from legal circumstances, such as a legal obligation, or from factual circumstances.
\n\n
\n\n
The controller processes (or engages another person to process on its behalf) personal data for its own purposes and typically determines:
\n\n
\n\n
\n
to initiate a processing activity;
\n
what personal data to collect, from whom, from what sources and for what purposes;
\n
how the data shall be processed;
\n
whether to share personal data with third parties and if so with whom;
\n
whether to engage one or several processors for processing the data on its behalf;
\n
whether to modify, anonymize or delete the data; and
\n
for how long the data is stored.
\n
\n\n
\n\n
The controller usually interacts directly with data subjects who expect the organization to be the controller, although direct interaction is not a prerequisite and may not always be the case, such as, for example, in a clinical trial context where the pharmaceutical company, and sponsor of the trial, does generally not even know the identity of the study participants. The controller must retain control over the data but must not necessarily have access to or process the personal data.4
\n\n
\n\n
An organization that processes personal data based on a legal obligation, for example, a tax authority or a social insurance office, or a specialist that processes personal data in accordance with its own professional obligations, such as a legal attorney or an accountant, is generally considered a controller and retains overall responsibility for the specific processing activity. However, in cases where an accountant provides other than accountant services, such as payroll services, it becomes a processor.
\n\n
\n\n
2.3 Joint controller
\n\n
\n\n
Where two or more controllers jointly determine the purposes and means of data processing according to the criteria mentioned above, they are joint controllers. The wish of the parties involved to be jointly responsible is not sufficient to assume joint controllership. The factual circumstances and the behavior in determining the purposes and means are essential. The European Court of Justice provided some clarifications in its decision of June 2018 (Wirtschaftsakademie) where it ruled that the operator of a Facebook fan page is a joint controller with Facebook for the processing of personal data.5 In a further decision of July 2018 (Jehovan), the European Court of Justice further clarified that it is sufficient that a person or entity that exerts influence over the processing of personal data, for its own purposes, and who participates, as a result, in the determination of the purposes and means of that processing, may be regarded as a controller.6 In spite of these decisions, the uncertainty as to which level of co-determination is sufficient to assume joint controllership is still unclear and must be examined on a case-by-case basis.
\n\n
\n\n
2.4 Processor
\n\n
\n\n
A service provider is a processor under the conditions, that the service provider (a) processes personal data (b) on behalf of the controller and (c) under the controller’s instructions. These factors are essential for the service provider to be a processor. Otherwise, and in particular, where the service provider has a certain degree of autonomy in making decisions or in controlling the content of the data, it may be a controller, eventually a joint controller. This does not mean, however, that the processor may not take any decisions. In practice, the controller may delegate some decisions relating to the technical and organizational questions to the processor, such as which hardware or software to use while still determining substantial questions such as the type of personal data to be processed, the retention period or the access rights.7 The question arises as to the degree to which the processor may decide on the means of processing on behalf of the controller without himself becoming a controller. The GDPR states in article 28 para. 10 that a processor becomes a controller as soon as it determines the purposes and means of processing. In practice, this means, that as soon as the processor goes beyond the instructions of the controller, it becomes a controller. This is the case where a service provider uses the data for its own purposes, for example, for conducting analytics and improving its own services. When determining if a service provider is a processor or a controller, respectively a joint controller for a specific processing activity, the following should be taken into consideration:
\n\n
\n\n
\n
the margin of maneuver that is left to the processor. The more detailed instructions the controller gives, the smaller is the margin of maneuver for the service provider;
\n
the level of control the controller wants to exercise;
\n
the expectations of the data subjects of who the controller is. This will depend on the information received from the controller.8
\n
\n\n
\n\n
Typically, a processor
\n\n
\n\n
\n
processes the data based on a mandate by the customer;
\n
has no control over the data and does not decide what data to collect and how to use it;
\n
has no own business interest in processing the data;
\n
is contractually or legally prohibited to use the data for own purposes;
\n
provides technical and operational support to the customer;
\n
has no contractual relationship with the data subjects concerning the processing activity;
\n
is not expected by the data subjects to be the controller.
\n
\n\n
\n\n
Depending on the specific circumstances, the level of instructions and the control by the customer, the service provider may be a processor, joint or independent controller.9
\n\n
\n\n
3 The consequences for each role
\n\n
\n\n
3.1 The organization is a controller
\n\n
\n\n
If an organization qualifies as a controller, it is responsible for complying with the data protection principles, and in particular must have a legal basis for processing the personal data and must comply with the GDPR requirements, such as providing notice to data subjects and granting data subject access rights. The organization has the freedom to engage one or several processors to process personal data on its behalf, subject to specific instructions regarding the purposes and ways of processing while remaining in control of and responsible for the data. In this case, the organization must ensure to have a Data Processing Agreement in place with such processors in line with article 28 GDPR.
\n\n
\n\n
A controller may also share personal data with another controller, without being a joint controller. For example, if an address broker sells personal data to an organization that processes that data for customer relation and marketing purposes, both organizations are controllers. Because they determine their purposes and means of processing separately from each other they are considered independent controllers. The GDPR does not mandate any particular contract or arrangement in this case, unless personal data is shared cross-border from the EEA to a country that does not provide an adequate level of data protection, in which case appropriate safeguards must be put in place, such as EU Standard Contractual Clauses. Nevertheless, because each party is responsible and liable for complying with the GDPR, and, in particular, with the principle of purpose limitation, it is recommended to establish a Data Sharing Agreement outlining the main obligations of the parties.
\n\n
\n\n
3.2 The organization is a joint controller
\n\n
\n\n
If the organization is a joint controller, it must, together with the other joint controllers, enter into an arrangement (such as a Joint Controller Agreement) setting out their respective responsibilities in complying with the GDPR. While the controllers must jointly determine the purposes and means of processing, such determination and the related responsibilities must not be equally shared among the parties but must be clearly outlined in the arrangement, in particular as regards:
\n\n
\n\n
\n
responding to data subject access rights;
\n
carrying out any data protection impact assessments;
\n
notifying data breaches; and
\n
informing individuals about the processing of their data according to article 13 and 14 GDPR.
\n
\n\n
\n\n
Further, the essence of the arrangement must be made available to data subjects who can reach out to each joint controller to exercise their privacy rights.
\n\n
\n\n
3.3 The organization is a processor
\n\n
\n\n
If the service provider is a processor, it must only process personal data on behalf of the controller and only on its instructions. The obligations of the parties must be specified in a Data Processing Agreement based on article 28 GDPR. The processor must, also, comply with all statutory obligations such as maintaining a record of processing activities or appointing a data protection officer, if the requirements under the GDPR are met.
\n\n
\n\n
Keep in mind the following:
\n\n
\n\n
\n
An organization may be a controller for certain processing activities and a processor for other processing activities.
\n
Not all service providers are also processors (if so, they must, however, sign a data processing agreement).
\n
While it is essential that the controller determines the purposes of the processing, in practice, the decision on the technical and organizational means for processing, such as storage, retrieval or erasure, is often delegated to the service provider. Special attention is required in assessing case by case whether the service provider still qualifies as a processor or as a joint controller.
\n
\n\n
\n\n
4 The contractual arrangements
\n\n
\n\n
4.1 Data Processing Agreement
\n\n
\n\n
The data processing agreement between the controller and the processor must include the following minimum requirements according to article 28 GDPR:
\n\n
\n\n
\n
the subject matter and the duration of processing;
\n
the nature and purposes of processing;
\n
the categories of personal data and data subjects;
\n
the obligations and rights of the controller (legal ground for processing and audit rights);
\n
the obligations of the processor, including (a) to process personal data only on documented instructions from the controller, (b) to ensure that only persons that have committed themselves to confidentiality are authorized to process the data; (c) to take all technical and organizational measures (article 32 GDPR) appropriate to the risk; (d) to only engage sub-processors with the prior specific or general written authorization of the controller, to inform the controller about new sub-processors and to contractually impose on such sub-processors the same obligations as imposed on the processor, whereby the processor remains liable to the controller for any failure of the sub-processors; (e) to assist the controller for inquiries and data subjects’ access requests; data breach notification and carrying out of data protection impact assessments; (f) at the end of the provision of services, and at the choice of the controller, to delete or return the personal data to the controller; (g) to make available to the controller all information necessary to demonstrate compliance with the obligations laid down in article 28 GDPR and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller; (h) to inform the controller immediately if, in the processor’s opinion, an instruction infringes the GDPR or other Union or Member State data protection provisions;
\n
a procedure on how to prove compliance with the obligations laid down in article 28 GDPR.
\n
\n\n
\n\n
Further, clarification in respect to the roles of the parties, cross-border data transfers, notification obligations, allocation of costs for assistance and audits or a provision regarding the liability are recommended, although those provisions are not mandatory under article 28 GDPR.
\n\n
\n\n
4.2 Joint Controller Arrangement
\n\n
\n\n
According to article 26 GDPR, the joint controllers must, using an arrangement between them, determine their respective responsibilities for compliance with the obligations under the GDPR. The law does not specify in detail what elements must be covered and therefore the parties have, in contrary to the data processing agreement under article 28 GDPR, a certain level of flexibility. The arrangement, be it an agreement or a policy, should outline the purposes and means of the processing and cover the following questions:
\n\n
\n\n
\n
Who provides notice to the data subjects following article 13 and 14 GDPR?
\n
With whom should the data subjects exercise their privacy rights (contact person)?
\n
Who will handle data subjects’ access requests and other rights?
\n
Who will handle complaints and requests from supervisory authorities?
\n
Who will make available the essence of the joint controller arrangement to data subjects?
\n
Who will appoint a DPO, if required?
\n
Who will determine, document and monitor the technical and organizational security measures?
\n
Who will carry out a data protection impact assessment, if needed?
\n
Who will engage processors, if any?
\n
Who will keep the record of processing activities?
\n
Who will determine if a data breach must be notified to supervisory authorities and data subjects and handle such notifications?
\n
\n\n
\n\n
4.3 Data Sharing Agreement
\n\n
\n\n
The GDPR is silent concerning data sharing agreements between independent controllers. An agreement is currently only mandated where controllers share personal data cross-border to a non-adequate country (EU Standard Contractual Clauses for Controllers10). However, even if there is no cross-border transfer of personal data, it is recommended taking into account the nature of the data sharing and the sensitivity of the personal data to be shared to outline, at a minimum, the principal obligations of the parties, and in particular to only process the data in accordance with the general privacy principles, the purposes of processing, whether the data can be disclosed to third parties, and if so, under what condition, the agreement to provide mutual assistance, if reasonably required, the implementation of security measures as well as indemnification and liability.
\n\n
\n\n
5 The procedure for determining the roles and the appropriate contractual arrangement
\n\n
\n\n
Summarizing, the steps to be taken whenever multiple parties are involved in the processing of personal data, and in particular, where one or several service providers are engaged, are the following:
\n\n
\n\n
\n
Assess what services the service provider shall provide and if such services require the processing of personal data.
\n
Assess the role(s) of the service provider.
\n
Establish the appropriate contractual arrangement(s) covering the responsibilities of the parties.
\n
\n\n
\n\n
6 Conclusion
\n\n
\n\n
With the introduction of the GDPR and the provisions on the relationship between controllers and processors in article 28 and joint controllers in Article 26, the difficulties in determining the roles of the parties remain. The evaluation is particularly difficult in complex situations and business models in which several parties in different jurisdictions are involved in the processing activity, each with different degrees of autonomy, control and responsibility.
\n\n
\n\n
The main factors in determining whether a party is a controller, joint controller or processor are, on the one hand, the degree of autonomy of each party in determining for what purposes, how and in what manner personal data are processed and, on the other hand, the degree of control over the content of personal data. The determination of roles is always factual and must be made on a case-by-case basis, taking into account each processing operation.
\n\n
\n\n
7 References
\n\n
\n\n
\n
Article 29 Data Protection Working Party: Opinion 1/2010 on the concept of “controller” and “processor” (referenced as WP 169)
\n
Information Commissioner’s Office (ICO): Data controllers and data processors: what the difference is and what the governance implications are (referenced as ICO guidance)
\n
Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. (Bitkom): Begleitende Hinweise zu der Anlage Auftragsverarbeitung (referenced as Leitfaden Bitkom)
\n
Judgement of the EU Court of Justice in Wirtschaftsakademie, C-210/16, EU:C:2018:388 (referenced as Decision C-210/16 Wirtschaftsakademie)
\n
Judgement of the EU Court of Justice in Jehovan todistajat C-25/17, EU:C:2018:551 (referenced as Decision C-25/17 Jehovan)
\n
Konferenz der unabhängigen Datenschutzbehörden des Bundes und der Länder (DSK): Kurzpapier Nr. 13: Auftragsverarbeitung, Art. 28 DS-GVO, Stand 17.12.2018 (referenced as DSK Kurzpapier Nr. 13)
\n
Commission Decision of 27 December 2004 amending Decision 2001/497/EC as regards the introduction of an alternative set of standard contractual clauses for the transfer of personal data to
\n
\n\n
\n\n
[1] Detailed analyses on the concept and several examples can be found in (a) the WP169, (b) the ICO guidance, (c) the Leitfaden Bitkom and (d) the DSK Kurzpapier Nr. 13.
\n\n
[2] ICO guidance where additional explanation can be found in notes 33-39
[9] Examples can be found in the WP 169, the ICO guidance and the DSK Kurzpapier article Nr. 13
\n\n
[10] EU Standard Contractual Clauses for Cfor conontrollers
\n","datum":"15.03.2019","teasertext":"
If several persons are involved in the processing of personal data, the question inevitably arises as to their data-protection-related role. This article explores the essential factors for determining the roles of the parties, and in particular the relationship between customers and service providers, and their consequences.
\n","preview":"","datei":[],"linkextern":""},{"id":159,"title":"The new EU General Data Protection Regulation (GDPR) is published","slug":"eu-datenschutz-grundverordnung-veroeffentlicht","link":"/en/news-knowledge/eu-datenschutz-grundverordnung-veroeffentlicht","titel":"The new EU General Data Protection Regulation (GDPR) is published","text":"
On May 4, 2016, the EU General Data Protection Regulation (GDPR) was published in the Official Journal of the European Union. The GDPR will replace the current EU Data Protection Directive and will be directly applicable in all EU Member States. Companies will have time until May 25, 2018 to implement all required steps necessary to comply with the new regulation.
\n\n
\n\n
The GDPR contains strengthened and new rights for data subjects, such as a right to be forgotten or a right to data portability, and new obligations for data controllers and data processors.
\n\n
\n\n
Here are some of the key changes:
\n\n
\n\n
The territorial scope has been expanded to include data controllers and (new) data processors that are established in the EU. Importantly, also companies that are NOT established in the EU, but offer goods or services to, or monitor the (online) behavior of data subjects in the EU, fall under the scope of the GDPR.
\n\n
\n\n
Controllers must demonstrate their accountability to comply with the GDPR. This includes the obligation to:
\n\n
\n\n
\n
Maintain a documentation of processing activities
\n
Establish policies and guidelines
\n
Appoint a data protection officer (DPO) in certain cases
\n
Implement security measures
\n
Implement data protection by design and by default and
\n
Conduct privacy impact assessments
\n
\n\n
\n\n
Accountability may be demonstrated by various means, such as with Binding Corporate Rules (BCR), certifications or codes of conduct.
\n\n
\n\n
The requirements for obtaining consent have been strengthened. Consent must be freely given, specific, informed, unambiguous and explicit for sensitive personal information and must be revocable at any time. It must be clearly distinguishable from other matters when requested in the context of a written document and it must be provided in an intelligible and easily accessible form, using clear and plain language. Also, consent will not be valid if there is a clear imbalance between the data subject and the controller, which may be the case for example in the employment context. Importantly, a controller may not make a service conditional upon consent, unless the processing of personal data is necessary for that specific service.
\n\n
\n\n
Data processors have now direct statutory obligations under the GDPR. This includes the obligation to:
\n\n
\n\n
\n
Maintain records of processing activities
\n
Implement appropriate data security measures
\n
Cooperate with supervisory authorities
\n
Assist controllers to comply with the GDPR
\n
Comply with cross-border data transfer restrictions
\n
Notify controllers in case of a data breach
\n
Become a joint controller, if data is processed beyond instructions of the controller
\n
Enter into a written data processing agreement with the controller
\n
Appoint a DPO in certain cases
\n
\n\n
\n\n
Data controllers must notify supervisory authorities about data breaches without undue delay and, where feasible, within 72 hours after having become aware of the breach. Where the breach is likely to result in a high risk to individuals’ rights and freedoms, such individuals must be notified about the breach without undue delay.
\n\n
\n\n
Violations of the GDPR may result in fines up to EUR 10 m or 2% of the annual worldwide turnover for example for failures to comply with the general obligations, to appoint a DPO or to implement security measures and privacy impact assessments. More severe failures, for example to comply with the basic privacy principles for data processing, such as consent requirements, data subject rights or data transfer restrictions, may result in fines up to EUR 20 m or 4% of the annual worldwide turnover.
\n\n
\n\n
What should companies do now?
\n\n
\n\n
Companies subject to the GDPR should start now to implement appropriate measures to comply with the GDPR in two years’ time by taking the following steps:
\n\n
\n\n
\n
Get familiar with the GDPR and the obligations applicable to your organization
\n
Conduct an assessment of the current privacy management practices within your organization and of the gaps in respect to the new requirements under the GDPR
\n
Identify measures that must be taken to comply with the GDPR and define an action and time plan for the remediation
\n
Watch out for guidelines and opinions that will be published by national Data Protection Authorities and the Article 29 Working Party in the coming months
\n
\n\n
\n\n
How can we help you?
\n\n
\n\n
We are happy to assist organizations in getting a better understanding of the requirements under the GDPR applicable to them; conducting assessments and gap analyses, providing guidance on remediation and developing necessary policies, guidelines and processes to ensure compliance with the GDPR and minimizing risks.
\n\n
\n\n
You can find the final text in various languages here.
\n\n
\n","datum":"04.05.2016","teasertext":"
On May 4, 2016, the EU General Data Protection Regulation (GDPR) was published in the Official Journal of the European Union. The GDPR will replace the current EU Data Protection Directive and will be directly applicable in all EU Member States. Companies will have time until May 25, 2018 to implement all required steps necessary to comply with the new regulation.
Countries around the world continue to adopt new or stricter regulations in the areas of data protection, information security, artificial intelligence, etc. to address the rapid development of new technologies and the growing requirements and concerns of a digitalized society.