In something of a massive data dump, the EU’s Article 29 Working Party emerged from its December plenary meeting today with a number of GDPR application guidance documents, including explanations for the mandatory DPO role, the mechanisms for data portability, how a “lead authority” to lead the one-stop shop enforcement mechanism will be established, and some notes on enforcement and the EU-U.S. Privacy Shield.
The WP29 welcomes comments on the guidance from stakeholders through January 2017, so there is some possibility their collective minds will be changed on some of this guidance. Feedback can be directed to firstname.lastname@example.org and email@example.com.
It is a lot to consume, and we’ll provide further analysis and reaction in the coming days, but here are the guidance highlights:
Who Needs To Get DPO-Ready?
Article 37(1) of the GDPR requires the designation of a DPO a) where the processing is carried out by a public authority or body; b) where the core activities of the controller or the processor consist of processing operations that require regular and systematic monitoring of data subjects on a large scale; or c) where the core activities of the controller or the processor consist of processing on a large scale of special categories of data (as defined in Article 9).
For many IAPP members, the key questions have surrounded interpretation of “core activities” and “large scale.” The WP29’s guidance suggests these terms are to be interpreted broadly, and that organizations should err on the side of appointing a DPO when in doubt. Indeed, the WP29 recommends that organizations voluntarily appoint a DPO even if they conclude one is not mandatory.
The WP29 defines “core activities” as “key operations necessary to achieve the controller’s or processor’s goals.” This does not mean that the organization must be in the business of data analytics, however, but rather that data processing is “an inextricable part of the controller’s or processor’s activity.” The WP29 cites as an example a hospital’s need to process health data as core to its ultimate activity of providing health care services, or a private security company’s use of surveillance technologies to process personal data as core to its ultimate goal of keeping its clients secure.
At the other end of the spectrum, processing personal data merely to pay employees or conduct routine IT support are not considered “core activities.”
Thus, organizations must ask themselves: “Is processing personal data inextricably part of or necessary to achieve our ultimate organizational goals?”
Referring to the recitals, and promising to provide additional guidance over time, the WP29 defines “large scale” with particular reference to the number of data subjects, rather than the organization’s size. This means an organization with few employees may nonetheless engage in “large scale” processing if it serves a large customer base, while a company serving a small clientele is unlikely to meet the “large scale” definition.
In particular, the WP29 identifies the following “large scale” factors:
- The number of data subjects concerned, either as a specific number or as a proportion of the relevant population.
- The volume of data and/or the range of different data items being processed.
- The duration, or permanence, of the data processing activity.
- The geographical extent of the processing activity.
“Large scale” processing includes a hospital’s processing of personal data, but excludes a solo practice physician who sees only a few patients. It includes processing of travel data by a local transportation company, but excludes an individual criminal defense lawyer’s database of client convictions.
Regular and Systematic Monitoring
The term “regular and systematic monitoring of data subjects” includes all forms of internet-based tracking and profiling, but is “not restricted to the online environment and online tracking.”
WP29 interprets “regular” as meaning one or more of the following:
- Ongoing or occurring at particular intervals for a particular period.
- Recurring or repeated at fixed times.
- Constantly or periodically taking place.
It interprets “systematic” as meaning one or more of the following:
- Occurring according to a system.
- Pre-arranged, organised or methodical.
- Taking place as part of a general plan for data collection.
- Carried out as part of a strategy.
The WP29’s examples range from telecommunications services and network providers to health and fitness apps to video surveillance usage.
Public authority or body
Similar to the other terms, the WP29 encourages broad interpretation of what constitutes a “public authority or body” for which a DPO is mandatory. It leaves to the Member States designation of applicable public authorities and bodies but strongly urges private entities performing public functions or exercising public authority to appoint a DPO even though there is no obligation in such cases.
Who Is the DPO?
The WP29 emphasizes that the DPO is a professional who must be qualified to determine the organization’s compliance with national and European data protection laws and practices, including “an in-depth understanding of the GDPR.” The DPO must be involved from the earliest stage possible in all issues related to data protection, and must be included as a “discussion partner” within the organization, invited to attend management meetings, consulted on issues of data protection, and involved promptly in data breach incidents.
The WP29 does not clearly indicate if the CPO may also serve as the DPO. It suggests in a footnote that the DPO’s independent function may not be consistent with C-suite roles, disqualifying senior management positions that “lead to the determination of purposes and means” of data processing, such as the head of Human Resources or IT.
The WP29 also suggests that when a company elects not to appoint a DPO, it should document the decision. The WP29 recommends that companies with a CPO who is not also going to serve as the DPO make it clear that the CPO is not the DPO. In another footnote, the WP29 suggests that CPOs may not in all instances qualify as DPO: “This is also relevant for chief privacy officers (CPOs) or other privacy professionals already in place today in some companies, who may not always meet the GDPR criteria, for instance, in terms of available resources or guarantees for independence, and therefore, cannot be considered and referred to as DPOs.”
How will data portability work, exactly?
Data subjects have a right to data portability under Article 20 of the GDPR. This new right allows data subjects to receive from any controller, in a machine readable format, the personal data they provided “knowingly and actively” to the controller and — according to the Article 29 Working Party’s new guidance — any personal data generated by their activity. The right is also intended to encourage the free flow of data from one controller to another, throughout the EU, to foster competition among data controllers, and to spur innovation in data portability technologies and services.
The “right to receive personal data” component reflects an “access” right that allows data subjects to extract from controllers their own data for personal use, such as getting information about their loyalty card purchases or their music playlist history. Data subjects may also transmit their personal data from one controller to another, which the WP29 cites as key to empowering consumers and encouraging innovation in data portability technologies. To this end, the WP29 encourages controllers to offer not only downloading options, but an application programming interface, known as an API, that will facilitate data transfer among controllers.
Controllers are not obliged under data portability rules to retain data longer than a typical retention schedule would allow. A receiving data controller need not accept all transferred data, and indeed should refrain from processing data not relevant to the receiving controller’s purposes. While the receiving organization becomes the new controller, moreover, and must clarify its processing purposes with the data subject, the WP29 emphasizes that the transmitting controller may still have obligations to the data subject, such as erasure rights.
When does portability apply?
Processing operations based on either the data subject’s consent or a contract with the data subject trigger the data portability rights. Importantly, it does not apply in the case of processing for “legitimate interests.” These rights also do not apply in other cases, such as in the exercise of a public authority’s duties, although the WP29 nonetheless encourages developing “processes to automatically answer portability requests” as a good practice, citing as an example a government service allowing data subjects to easily download past personal income tax filings.
The WP29 also discourages a narrow interpretation of “data concerning the data subject” and a broad interpretation of “data provided by the data subject.” In particular, a controller must allow portability not only of data submitted by the data subject (e.g. name, address) but as well data generated by the data subject’s use of the controller’s services (such as search history, traffic data, or location data). This does not include anonymous data but does include pseudonymous data.
Importantly, the WP29 excludes from the data portability requirement proprietary data that it calls “inferred data and derived data” such as a credit score or analysis of the user’s health even if this data is part of the subject’s profile. Because “inferred” and “derived” data are the only personal data excluded from the broad portability obligation, organizations are well advised to categorize their data collections carefully, document them, and build them into automated portability functions.
Rights of third parties
Another key limitation on the data portability right is that it not limit the rights and freedoms of third parties. This is designed to prevent a receiving controller from processing transferred data in contradiction to the GDPR. As the WP29 explains: “The data subject initiating the transmission of his or her data to another data controller either gives consent to the new data controller for processing or enters into a contract with them. Where personal data of third parties are included in the data set, another ground for lawfulness of processing must be identified.” When a data subject exports its data – including third-party data – to a new controller, therefore, the data might only be used for the subject’s personal or household use. For example, if a data subject ports over a contact list to a new email account, the receiving controller may not mine the subject’s contacts for marketing purposes.
Intellectual property and security
Several key questions are raised by data subjects’ rights to extract “their” data from controllers. One is whether data subjects may now intrude on commonly accepted notions of trade secrets or other proprietary products the controllers may claim to that data. The other is the challenge of keeping secure personal data that must be maintained for easy extraction by data subjects.
As to the former, the WP29 merely states that “[t]he right to data portability is not a right for an individual to misuse the information in a way that could be qualified as an unfair practice or that would constitute a violation of intellectual property rights. A potential business risk cannot, however, in and of itself, serve as the basis for a refusal to answer the portability request.”
As to the security concerns, the WP29 is equally glib. “The data controller is responsible for taking all the security measures needed to ensure that personal data is securely transmitted (e.g., by use of encryption) to the right destination (e.g., by use of additional authentication information).” Because of the risk that data subjects might ask for their data and then fail to keep it secure, controllers responding to portability requests should “as a best practice, recommend appropriate format(s) and encryption measures to help the data subject” maintain security.
Where to set up the “one-stop shop”
The WP29’s guidance for establishing the lead data protection authority to head the so-called “one-stop shop” mechanism for regulating a company that conducts cross-border data processing is fairly fine-grained. It gets into the weeds of defining “substantial” and “affect” in defining cross-border processing, itself, and puts forward sample scenarios for purposes of illustrating how decisions should be made in picking a lead DPA. Further, there is a set of FAQs to accompany its guidance document.
However, at its core, the guidance is fairly simple, emphasizing transparency and communication with the data protection authorities. It must be clear where an organization’s “main establishment” in the EU is, and this main establishment must be where decisions about the processing of personal data are actually made. If your main establishment is in the Netherlands, your lead authority will be the Netherlands DPA.
In a case where a controller is established in one Member State and the processor is established in a separate Member State, it is the controller that counts: The lead authority will be the DPA of the controller’s Member State.
Further, data protection authorities reserve the right to say an organization can have multiple “lead authorities” if decisions about different types of data processing are made in different Member States by different members of the organization. For example, if a multi-national financial services company has its banking operations in Germany, and its insurance operations in France, the German DPA would lead any investigation into personal data processing for banking, while the French DPA would lead an investigation into insurance-related processing.
Finally, an organization forgoes its right to the one-stop shop altogether if it exists outside of the EU and does not formally declare a main establishment in the EU, but rather operates through a series of representatives in various Member States (Note: IAPP Westin Researcher Cobun Keegan, CIPM, CIPP/US, and Privacy Management Partners’ Jeroen Terstegge, CIPP/E, CIPP/US, recently explored the role of the “representative” in a piece examining the WhatsApp case in the Netherlands).
Similarly, if an organization comprises a number of disparate operations in a number of Member States, and it isn’t clear which is the main establishment, the one-stop shop will not apply and any DPA may investigate as it sees fit.
It would seem to behoove these sorts of organizations, along with non-EU companies wishing to do business with people in more than one Member State, to designate an EU headquarters to serve as a main establishment. However, that HQ “must have the authority to implement decisions about the processing activity and to take liability for the processing, including having sufficient assets.” It cannot be a main establishment on paper only.
There is even particular emphasis that the GDPR does not allow for “forum shopping.” In other words, the DPAs make it explicit that they won’t just take your word for it. In fact, “The process of determining where the main establishment is may require active inquiry and co-operation by the supervisory authorities. … The burden of proof ultimately falls on controllers and processors. They should be able to demonstrate to supervisory authorities where decisions about data processing are actually taken and implemented. Effective records of data processing activity would help both organisations and supervisory authorities to determine the lead authority.”
This, yet again, emphasizes accountability and the existence of a robust privacy program that can document which personal data is being processed in which way, when, and where.
Other Enforcement Notes
As a final part of the WP29’s work in its most recent plenary, the collective data protection authorities made a number of decisions concerning enforcement activities.
First, WP29 re-established its enforcement subgroup, to be headed by the Spanish and Dutch DPAs. This group will be in charge of coordinating enforcement of cross-border cases until the GDPR comes into force.
The group also adopted position papers on mutual assistance, cooperation and the one-stop shop mechanism and will begin putting some of these into test action throughout 2017. WP29 is already working on its GDPR-created successor, the European Data Protection Board, and emphasized to the European Data Protection Supervisor that it will need an IT platform, post haste, with which to communicate more effectively.
Finally, WP29 further defined its implementation of the EU-U.S. Privacy Shield framework for transferring personal data to the United States. The collective DPAs have agreed upon communications documents that will be posted for individuals and companies to use for complaints and participation in the Shield program, and the WP29 formally acknowledged that it is the “EU centralized body” that will handle complaints from individuals regarding data transferred to the U.S. for commercial purposes but then accessed for national security purposes.
How exactly that will work in practice, and how the “EU informal panel of DPAs” necessary for commercial complaints will work, is the subject of the next WP29 plenary, now set for February 2017.
If you want to comment on this post, you need to login.