IAPP CIPM – International Transfers and DPO Part 2

5. Exceptions

Hi, guys. In this lesson, we will discuss exceptions. If you are making a restricted transfer that is not covered by an adequacy decision or an appropriate safeguard, then you can only make the transfer if it is covered by one of the exceptions set out in Article 49 of the GDPR. You should only use these as true exceptions from the general rule that you should not make a restricted transfer unless it is covered by an adequacy decision or there are appropriate safeguards in place. If it is covered by an exception, you may go ahead with the restricted transfer. Of course, you must still comply with the rest of the GDPR. Each exception will be analysed in this lesson. So let’s start with exception number one. Has the individual explicitly or implicitly consented to the restricted transfer? So please see the section regarding consent for what is required for valid, explicit consent under GDPR. You can either find it in the GDPR regulation or in my course related to GDPR compliance from scratch.

A valid consent must be specific as well as informed. You must provide the individual with precise details about the restricted transfer. You cannot obtain valid consent for restricted transfers. In general, you should tell the individual the following: the identity of the receiver or the categories of receiver; the country or countries to which the data is to be transferred. Why? You need to make a restricted transfer. The type of data, the individual’s right to withdraw consent, and the possible risks involved in making a transfer to a country that does not provide adequate protection for personal data and does not have any other appropriate safeguards in place For example, you might explain that there will be no local supervisory authority and no or only limited individual data protection or privacy rights given the high threshold for valid consent and that the consent must be capable of being withdrawn. This may mean that using consent is not a feasible solution. Exception number two: do you have a contract with the individual? Is the restricted transfer necessary for you to perform that contract?

Are you about to enter into a contract with the individual? Is the restricted transfer necessary for you to take the steps requested by the individual in order to enter into that contract? This exception explicitly states that it can only be used for occasional restricted transfers. This means that the restricted transfer may occur more than once, but not regularly. If you make restricted transfers on a regular basis, you should implement an appropriate safeguard. The transfer must also be necessary, which means that you cannot perform the core purpose of the contractor or the core purpose of the steps needed to enter into the contract without making the restricted transfer. It does not cover a transfer for you to use a cloud-based system. Let’s take an example. A UK travel company offering bespoke travel arrangements may rely on this exception to send personal data to a hotel in Peru, provided that it does not regularly arrange for its customers to stay at that hotel. If it did, it should consider using an appropriate safeguard, such as the standard contractual clauses. It is only necessary to send limited personal data for this purpose, such as the name of the guest, the room required, and the length of stay.

An example of necessary steps being taken at the individual’s request in order to enter into a contract before the package is confirmed and the contract entering into effect when the individual wishes to reserve a room in the Peruvian Hotel The UK travel agency must send the Peruvian hotel and all of this information. The UK Travel Company then sends the customer’s name in order to reserve the room. Public authorities cannot rely on this exception when exercising their public powers. Let’s take a look at exemption number three. Do you have a contract with an individual that benefits another individual whose data is being transferred? Is that transfer necessary for you to either enter into the contract or perform that contract as set out in exception two? You may only use this exception for occasional transfers, and the transfer must be necessary for you to perform the core purposes of the contract or to enter into that contract. You may rely on both exceptions two and three. Exception two is for the individual entering into the contract, and exception three is for other people benefiting from that contract, often family members.

Exceptions two and three are not identical. You cannot rely on exception 3 for any restricted transfers needed for steps taken prior to entering into the contract. Public authorities cannot rely on this exception when exercising their public powers. Let’s take an example following the exception 2 example: exception 3 may apply if the customer is buying the travel package for themselves and their family. Once the customer has bought the package with the UK travel company, it may be necessary to send the names of the family members to the Peruvian hotel in order to book the rooms. Let’s take a look at exception 4. You need to make the restricted transfer for important reasons of public interest. There must be a European Union or law that states or implies that this type of transfer is allowed for important reasons of public interest, which may be in the spirit of reciprocity for international cooperation. For example, an international agreement or convention that the UK or European Union has signed that recognises certain objectives and provides for international cooperation For example, there is the 2005 International Convention for Cooperation and the Suppression of Acts of Nuclear Terrorism.

This can be relied upon by both public and private entities. If a request is made by a non-EU authority requesting a restricted transfer under this exception and there is an international agreement such as a mutual assistance treaty, you should consider referring the request to the existing mutual assistance agreement or treaty; you should not rely on this exception for systematic transfers. Instead, you should consider one of the appropriate safe words. You should only use it in specific situations, and each time you should satisfy yourself that the transfer is necessary for an important reason of public interest. Exception five: you need to make the restricted transfer to establish if you have a legal claim. You need to make a legal claim to defend a legal claim. This exception explicitly states that you can only use it for occasional transfers. This means that a transfer may happen more than once, but not regularly.

If you are regularly transferring personal data, you should put in place an appropriate safeguard. The transfer must be necessary, so there must be a close connection between the need for the transfer and the relevant legal claim. The claim must have a basis in law and a formal, legally defined process. But it is not just judicial or administrative procedures. This means that you can apply a broad interpretation of what constitutes an illegal claim to COVID. For example, in civil and criminal law, the court procedure does not need to be initiated for all judicial legal claims, and it covers out-of-court procedures. And second, administrative or regulatory procedures such as those to defend an investigation in antitrust law or financial services regulation or to seek approval for a merger You cannot rely on this exception if there is only the mere possibility that a legal claim or other formal proceedings may be brought in the future.

Public authorities can rely on this exception in relation to the exercise of their powers. Exception six: you need to make the restricted transfer to protect the vital interests of an individual. He or she must be physically or legally incapable of giving consent. This applies in a medical emergency where the transfer is needed. In order to give the medical care required, the imminent risk of serious harm to the individual must outweigh any data protection concerns. You cannot rely on this exception to carry out general medical research. If the individual is physically and legally capable of giving consent, then you cannot rely on this exception. For details as to what is considered a vital interest under the GDPR, please see the section on vital interest as a condition of processing special category data. Let’s take a look at exception number seven.

You are transferring restricted data from a public register. The register must be created under European law and must be open to either the public in general or any person who can demonstrate a legitimate interest. For example, registers of companies, associations, criminal convictions, land registers, or public vehicle registers The whole of the register cannot be transferred, nor can whole categories of personal data. The transfer must comply with any general laws that apply to disclosures from public registers. If the register has been established by law and access is only given to those with a legitimate interest, part of that assessment must take into account the data protection rights of the individuals whose personal data is to be transferred. This may include consideration of the risk to that personal data of transferring it to a country with less protection.

This excludes private company-run registers, such as credit reference databases, and exception number eight. You are making a one-off restricted transfer, and it is in your compelling legitimate interest. If you cannot rely on any of the other exceptions, there is one final exception to consider. This exception should not be relied on lightly and never routinely, as it is only for truly exceptional circumstances. For this exception to apply to a restricted transfer, there are several conditions that should be met. There must be no adequacy decision that applies. You are unable to use any of the other appropriate safeguards. You must give serious consideration to this, even if it would require significant investment from you. None of the other exceptions apply. Again, you must give serious consideration to the other exceptions. It may be that you can obtain explicit consent with some effort or investment. Your transfer must not be repetitive; it may happen more than once, but not regularly. The personal data must only relate to a limited number of individuals. There is no absolute threshold for this. The number of individuals involved should be part of the balancing exercise you must undertake. The transfer must be necessary for your compelling, legitimate interest.

Please see the section in the GDPR guide on “Legitimate Interest” as a lawful basis for processing. But bear in mind that this exception requires a higher standard as it must be a compelling legitimate interest. An example is the transfer of personal data to protect a company’s IT systems from serious and immediate harm. On balance, your compelling legitimate interest outweighs the rights and freedoms of the individuals. You have made a full assessment of the circumstances surrounding the transfer and provided suitable safeguards to protect the personal data. Suitable safeguards might be strict confidentiality agreements that require data to be deleted soon after the transfer, technical controls to prevent the use of the data for other purposes, or sending encrypted or confidential data. This must be recorded in full. In your documentation of your processing activities, you have informed the data processing authority of this transfer. We will ask to see full details of all the steps you have taken as set forth above, including the last one, in which you informed the individual of the transfer and explained your compelling legitimate interest to them. So all these ten different conditions need to apply to your restricted transfer in order for these exceptions to be allowed.

6. Controllers & GDPR DPOs not in the EU (LSAs examples)

Hi guys. In this lesson, we’ll discuss controllers and GDPR data privacy officers outside the European Union. Under Article 27, if a controller or processor not established in the European Union processes personal data of European Union residents in relation to the offering of goods or services or the monitoring of their behaviour as specified under Article 3.2, then the controller or processor must designate in writing a European Union-based representative.

The representative must be established in a European Union member state where the data subjects whose personal data is being processed or whose behaviour is being monitored are located. The representative must be addressable by data privacy associations and data subjects on all processing issues related to compliance. Because the controller or processor is not established within the European Union, they cannot take advantage of the lead DPA role, or what is called “One Stop Shop,” if they are involved in cross-border data processing activity in the European Union. As the Working Party 29 stated, if the company does not have an establishment in the European Union, the mere presence of a representative in a member state does not trigger the one-stop shop system. This means that controllers without any establishment in the European Union must deal with local supervisory authorities in every member state they are active in through their local representative. So let me explain a bit.

What is the lead DPA or lead supervisory authority? LSA Simply put, this means a company that has operations in multiple countries can choose to deal with the supervisory authority of one country instead of having to deal with the supervisory authority in each country of operation. A lead supervisory authority is the authority with primary responsibility for dealing with cross-border data processing activity. For example, when a data subject makes a complaint about the processing of his or her personal data, the lead supervisory authority will coordinate any investigation involving other concerned supervisory authorities. Identifying the lead supervisory authority depends on determining the location of the controller’s main establishment or single establishment in the European Union. So let’s take two examples. For example, a food retailer may have its headquarters or central administration in Rotterdam, Netherlands. It has establishments in various other European Union countries that are in contact with individuals there. All establishments make use of the same software to process consumers’ personal data for marketing purposes. All the decisions about the purposes and means of processing consumers’ personal data for marketing purposes are taken within its Rotterdam headquarters.

This means that the Netherlands supervisory authority is the company’s primary supervisory authority for this cross-border processing activity. Example number two: a bank has its corporate headquarters in Frankfurt, and all its banking processing activities are organised from there. But its insurance department is located in Vienna. If the establishment in Vienna has the power to decide on all insurance data processing activity and to implement these decisions for the whole European Union, then as foreseen in Article 4.16 of the GDPR, The Austrian supervisory authority would be the lead authority with respect to the cross-border processing of personal data for insurance purposes only, and the German authorities would supervise the processing of personal data for banking purposes wherever the clients are located. Let’s talk about GDPR data privacy officers located outside the European Union.

The Working Party 29 has stated that under the GDPR, the accessibility of the data privacy officer must be effective. It regards that accessibility as being effective if the DPO is located within the European Union. This is true even if the controller or processor is not located in the European Union. It does concede that when the controller or processor has no establishment in the European Union, it may be feasible for the DPO to be colocated with the controller or processor outside the European Union. As the DPO has four equal stakeholders, they are responsible for being located outside the European Union. At the main establishment of the controller or processor, it may make them more accessible to the board of directors and to the operational personnel in the controller or processor organizations. At the same time, the DPO would be less accessible to the local DPA and to data subjects located within the EU.

While anyone can communicate globally via remote messaging and video conference, it is not the same as speaking the language and understanding the cultural expectations of data subjects and the working styles of data privacy associations. The world is not unicultural or unilingual, and the remote DPO may find these barriers significant in accomplishing their responsibilities toward remote data subjects and DPAs. If it is necessary for a DPO to be located outside of the European Union, it must be co-located with the main global establishment of the controller or processor. This would seem to be an ideal example of when the DPO role should be split into at least two individuals: one outside the European Union, responsible for controller and processor compliance and board communications, and the other inside the European Union, responsible for data subject communication and data privacy authority coordination.

7. Representatives vs DPOs

Hi guys. In this lesson, we will discuss representatives versus DPOs. This then raises the question of whether a non-European controller or processor could utilise a European Union-based data privacy officer to beat their representative. The GDPR applies to controllers and processors that process personal data of individuals in the European Union, regardless of where the organisation is established in the world.

Those organisations who are not established inside the European Union are required to appoint a representative who is established in the European Union for purposes of GDPR compliance. The GDPR also requires the data privacy officer under some circumstances and makes the role voluntary otherwise, and the Working Party 29 recommends the DPO be located within the European Union for accessibility, even if the controller or processor is not. So, what is the EU representative role, and how does it interplay with the sometimes overlapping role of the DPO? Under Article 27, it states that a controller or processor who is not established in the European Union and offers goods or services to data subjects in the European Union or monitors the behaviour of data subjects occurring within the European Union must appoint a representative in writing. On first impression, this representative within the European Union seems to be merely providing a local point of presence within the European Union, which is reached more easily than a non-EU controller or processor.

The EU representative is required to be colocated in one of the European Union member states with the data subjects who are being offered these goods and services or whose behaviour is monitored. The representative must be available to both the local DPA and data subjects, which makes sense given that these individuals and supervisory authorities would desire someone nearby who speaks the language and understands their customs and expectations. This seems like the representative role should be one of limited agency, where the European Union representative merely takes messages and passes information onto the controller and processor located overseas and then communicates back to the data subject or DPA after receiving instructions from the controller or processor. Subsection 4 of Article 27 states that the representative is to be addressed in addition to or instead of the controller or processor on all issues related to processing for the purposes of ensuring compliance with the regulation.

This wording seems to imply that the European Union representative may be the only one contacted for GDPR compliance issues if the controller or processor cannot be reached. However, as the DPAs may revive administrative fines and penalties of a significant nature and data subjects may initiate litigation against controllers and processors for damages, the European Union representative could find themselves a named party in administrative actions or litigation as the only defendant that a European Union court may be able to obtain effective jurisdiction over. At least the DPO is protected against legal actions by the data subject and presumably the DPA. But similar statutory protection does not appear in the GDPR for the European Union representative. Perhaps the presumption was that the European Union representative would be an employee of the controller and processor or, at a minimum, an external agent who has contractually limited their liability and been specifically indemnified by the controller or processor for any issues related to GDPR. A difficulty for any external agent taking on this role is that the controller or processor is not established within the European Union.

The agent would have to resort to courts outside the European Union if it became necessary to enforce the liability and indemnity clauses of their contract. Reviewing an earlier draught of the GDPR passed by the European Parliament in 2014 provides some insight. Under the penalties article, it stated that where the controller has established a representative, any penalties should be applied to the representative without prejudice to any penalties that could be initiated against the controller. In the final draught of the GDPR, revised wording has been moved to rescue 80, and let me just go back a bit. So the resident 80 says that the designated representative should be subject to enforcement proceedings in the event of non-compliance by the controller/processor, so the European Union representative may be legally pursued locally for the GDPR. Noncompliance of Overseas Entities Given the limits to the extraterritoriality of laws and the jurisdictional reach of courts, it seems likely the European Union representative would be required to, at least initially, incur legal and other costs for addressing enforcement actions and be responsible for paying administrative fines and damage suit rewards. What about the line separating the roles of the European Union representative and the DPO? Well, the earlier draught of the GDPR had required that non-European controllers and processors appoint representatives in the following situations: where there was a processing of personal data relating to more than 5000 data subjects during any consecutive twelve-month period; or where there was a processing of special categories of personal data, such as location data or data on children or employees in large-scale filling systems.

This was similar to the criteria used to determine when a DPO was required. The final text has revised this to require a European Union representative for non-EU controllers or processors when offering goods and services or monitoring the behaviour of data subjects, somewhat overlapping the DPA requirement. If large-scale, regular, and systematic monitoring is performed, the contact details of the European Union representative are required to be disclosed to the DPA and to data subjects, just as they are to the controllers or processors. A European Union representative is required to maintain a record of processing, which is not a primary responsibility of a DPO but could be an added task. As our DPOs in Washington, the European Union representative is required to collaborate with the DPA. It specifies that the representative is required to perform its tasks according to the mandate received from the controller or processor, which is somewhat different than the independence specified for DPOs in the performance of their tasks.

So the DPO and European Union representative roles have diverged as the GDPR has been revised, but the final text is not completely clear. For example, can a DPO also fulfil the role of European Union representative for non-EU controllers and processors? Would any European Union-based DPO want to take on this representative role for a non-EU controller or processor? Given the potential legal exposures described above and the uncertain state of the GDPR’s final wording, the following query was sent to, for example, the Irish DPC Data Privacy Consortium. Can the Article 27 Representative of Controllers and Processors not established in the EU also be the Article 37 and 39 Data Protection Officer? And if so, how would the representative be shielded from liability from data subjects and the DPC in the same manner that the DPO is? The DPC’s reply focused on the potential conflicts of interest between the roles, such as the confidentiality required of the DPO when receiving concerns from employee data subjects versus instructions given by the data controller to his representative.

Another potential conflict noted was when the DPA was involved in enforcement activities and looked to the DPO to be independent while the controller and representative were of coequal standing. Another potential conflict arises when the independent DPOrole performs tasks that contradict the instructions given to the representative role by the controller. While the representative may be subject to enforcement proceedings, the DPC did not believe that the representative would be subject to ultimate legal liability under the GDPR, although they should contractually insulate themselves due to these potential conflicts. The DPC, while noting that there is no express prohibition on the same person fulfilling both roles, advises caution and notes the controller’s responsibility to ensure that the DPO does not take on other tasks that result in a conflict.

8. Data Sovereignty vs Data Residency vs Data Localization

The terms “data sovereignty,” “data residancy,” and “data localization” are often sources of confusion for businesses managing data across borders, especially on cloud infrastructure. They are, in fact, used so interchangeably that their individual meaning has become lost. Yet why do these terms exist? And why are they used so interchangeably? What are their practical, not just philosophical, differences? And why do businesses need to keep on top of them?

So, how do these three terms relate to one another? They are effectively three degrees of a single concept, which is how data privacy impacts cross-border data flows. This subject has become increasingly important in recent years, with the GDPR regulation granting greater rights to individuals over how their data is used by businesses both within and outside the European Union. Organizations that handle international data must ensure that data privacy is not put at risk when shared across borders. Likewise, understanding the legal requirements of storing data in a certain country is fundamental to meeting data privacy and security standards. So what is data residency? Data residency refers to where a business, industry,  body, or government specifies that their data is stored in a geographical location of their choice, usually for regulatory or policy reasons. A typical example of a data residency requirement in action is where a company wishes to take advantage of a better tax regime.

Doing so will usually require the business to prove they are not conducting a too great proportion of core business activities outside the country’s borders, including the processing of data. They will therefore impose a data residency that requires them to use certain infrastructures and then impose strict data management workflows on themselves and any cloud service providers in order to protect their taxation rights. What is “data sovereignty”? Data sovereignty differs from data residency in that the data is not only stored in a designated location but is also subject to the laws of the country in which it is physically stored. This difference is also crucial for businesses, as the government’s rights of access to data found within its borders differ widely from country to country. This is where data sovereignty and residency are often conflated. Ensuring data sits within a geographical location for whatever reason, whether avoiding or taking advantage of laws, regulations, and tax regimes, or even for pure preference and comfort, is a matter of data residency.

But the principle that the data is subject to the legal protections and punishments of that country is a matter of data sovereignty. They are clearly related and even two sides of the same coin, but one is a matter of national legal rights and obligations, while the other is a matter of geography. Recognizing this distinction will help professionals better prepare for compliance, data management, and exchange. Then what is data localization? This is the most stringent and restrictive concept of the three. Data residency, like data sovereignty, is based on legal obligations. It is also the concept that is growing the fastest internationally; data localization requires that data created within certain borders stay within them.

In contrast to the two terms above, it is almost always applied to the creation and storage of personal data, with exceptions including some countries’ regulations over tax, accounting, and gambling. In many cases, data localization laws simply require that a copy of such data be held within the country’s borders, usually to guarantee that the relevant government can audit data on its own citizens without having to contend with another government’s privacy laws. India’s Draft Personal Data Protection Bill is an example of exactly this. However, there are countries where the law is so strict as to prevent it from crossing the border at all. For instance, Russia’s own Personal Data Law requires the storage, update, and retrieval of data on its citizens to be limited to data centre resources. Within the Russian Federation, typical criticism of these laws is that they use the mask of enhanced cybersecurity or citizens’ privacy concerns to conceal the real motivation of national protectionism.

This border-based silhouetting of data, it is claimed, obstructs businesses and governments from realising the full potential the data stands to offer and contributes to digital fission and the Splinter Net. But regardless of the debate surrounding the practises, we find that executives often need to better understand the importance of the differences between these three terms. As data privacy professionals, we may be sticklers for using the right vocabulary in the current circumstances, but the frequency and manner in which these words are used interchangeably amongst the businesses we engage with and even other industry commentators indicate a dangerously widespread misunderstanding. Addressing any level of confusion in your own business will allow you to identify the precise obligations that apply to you and interrogate your cloud service provider’s capabilities more rigorously. As a starting point, try applying the above distinctions to these key questions about your own infrastructure: Where are each of your various categories of data—personal data, financial records, et cetera—created or processed? And what obligations might this bring? So, where is it kept? And who owns the data center? Your data may be in a data centre in the UK, but if this data centre is owned by a US-headquartered company, then the US government may have the right to access your data under the Cloud Act. What are your procedures for backup? Where is your data backed up according to the type of data in question? What local stipulations exist for the security or encryption of the data? How confident are you in your cloud partner’s understanding of current and future data privacy regulations? How have they evidenced that their data centres meet all your local and global privacy needs? Or have you assumed it?