GDPR at One Year: What We’ve Learned
May 21, 2019
The European Union’s General Data Protection Regulation (GDPR) went into effect on May 25, 2018, generating both headlines and legal uncertainty. Now, one year on, is a good time to recap the main lessons learned and our recommendations for compliance going forward.
One of GDPR’s central rules is that parties who control the processing of personal data of EU individuals (data controllers) must require parties who actually do their processing (data processors) to adhere to certain GDPR obligations. Many approaches to compliance with that rule, codified in Article 28 of GDPR, have surfaced. Best practices are not yet clear, but innovative contractual solutions for compliance with Article 28 are being developed and tested.
Article 28 is typically implemented by a data controller through a document commonly known as a Data Processing Addendum (DPA). DPAs typically are attached as amendments to existing pre-GDPR data processing contracts or as exhibits to new, post-GDPR contracts. Countless varieties of DPAs have emerged this past year, taking dramatically different approaches to Article 28 compliance. Here is what we see at Moses & Singer in the droves of DPAs now in play at GDPR's one year anniversary:
• Length. We have seen DPAs range from 2 pages to over 50 pages.
• What GDPR Covers.
• GDPR is EU-centric. There appears to be a widespread belief that GDPR applies to everything—every contract, every party, and every engagement—no matter who may be contracting and for what. GDPR, however, is an EU-centric law and applies to business in the EU. GDPR does state in Article 3 that it applies to organizations outside the EU that offer goods or services to individuals in the EU, but that leaves a great many transactions outside the reach of GDPR. Thus, for example, if, in a business-to-business transaction, a US data processor is not offering goods or services to an individual in the EU, query whether GDPR should apply to the processor. While guidance here from EU regulators is lacking, care should be taken when contracting to impose GDPR only where the facts may warrant.
• Non-EU Data and Potential Conflicts of Law. GDPR applies to the personal data of people located in the EU (although even that principle is sometimes debated). However, some DPAs apply GDPR to all personal data, whether the data comes from the EU or not. The data controllers’ rationale for this is to impose the highest data protection standards (presumptively the GDPR standard) across the board to all personal data. However, even if GDPR invokes the highest data protection standard in the world, there may be, now or later (as privacy laws quickly evolve these days), conflicts of laws, where there isn't necessarily a "highest" standard, but differing and perhaps incompatible standards. This may already be true of GDPR and the data security breach notification laws of the U.S. states. Such conflicts will require attention in future DPAs.
• Costs of Data Processor Compliance. Clearly, not every processor and not every processing transaction is subject to GDPR. The mindset of many controllers who ask processors to enter into DPAs seems to be that the cost of the obligations required by the DPA are a cost of doing business that the processor should absorb. But if the processor is not governed by GDPR, query whether such costs should instead be considered 'out-of-scope' and pass-through charges, as the processor would not otherwise have to incur them. Such costs may not otherwise be built into the processor's pricing.
• Subprocessors. DPAs typically restrict processors from allowing other processors, often referred to as subprocessors, access to personal data without the controller's consent. This consent is required by GDPR Article 28(2). Also, GDPR Article 28(4) requires processors who engage subprocessors to carry out duties for the controller to require those subprocessors to adhere to the terms of the DPA between the controller and processor ('flow down' terms). A common point of contention is what is meant by "subprocessor"—is it a subcontractor of the services provided to the controller, or more broadly any third party engaged by the processor?
"Processor" is broadly defined in GDPR as anyone that processes personal data, and "processes" is broadly defined as almost anything — collecting, storing, retrieving, transmitting, adapting, altering, erasing, destroying, etc. Does "processor" include anyone that provides back office support, such as hosting, cloud, administrative, clerical or other services incidental to what we may think of as “processing”? Such a reading of GDPR would raise serious problems for most businesses in an era of outsourcing and cloud computing. Can a processing business practicably seek consent from every controller client for every service provider that the processor uses? To deal with these practical and unsettled questions, processors endeavor to negotiate clauses clarifying that subprocessors means subcontractors and not back office providers, or that exclude back office providers altogether from the Article 28 requirements. How these clauses will fare when tested and where the "processor" line will be drawn remains to be seen.
Some of these quandaries may be resolved over time if practices evolve to become 'standard' or 'customary' in commercial contracting, or if EU regulators offer guidance. For the time being, contracting around GDPR remains somewhat uncertain and at times hotly debated, with DPAs exhibiting many different approaches and requirements.
Moses & Singer's attorneys have drafted and negotiated hundreds of DPAs in a myriad of settings, gaining unique insight into the various approaches and resolutions available to both controllers and processors. If you conduct business with EU customers or businesses or want to find out if GDPR applies to you, please contact Blaze Waleski email@example.com.