The European Union General Data Protection Regulation’s (“GDPR”) is here. By now, most U.S. businesses and organizations have heard of GDPR. This EU regulation is drawing attention in the United States because it expands the territorial scope of EU data protection laws, significantly increases the penalties for non-compliance and is enshrouded with uncertainty. Specifically, GDPR: (i) may apply to U.S. businesses and organizations with no physical presence in the EU (or European Economic Area); (ii) like U.S. anti-bribery and anti-trust laws, introduces extremely high fines—up to 4% of annual global turnover; and (iii) introduces vague requirements with little guidance and it is unclear how strict EU data protection authorities will enforce it. Whether you are a U.S. cloud based service provider or have employees across the EU, you need to understand GDPR enough to know when it affects your business.
The first thing to know about GDPR is when it applies. GDPR applies to organizations established outside the EU that; (i) process (as defined below) personal data of individuals located in the EU; (ii) offer goods or services to individuals located in the EU; or (iii) monitor behavior of individuals located in the EU. U.S. businesses will be subject to GDPR if they engage in these activities, despite not having a physical presence in the EU.
This article addresses key provisions of GDPR that are likely to affect U.S. businesses, particularly those in the B2B context. It also provides practical insights on achieving compliance and the challenges businesses will likely face in doing so.
Background on EU Data Protection Laws
Since 1995, the EU has regulated data privacy under Directive 95/46/EC (the “Directive”). A directive is EU legislation that requires member states to achieve a certain goal, but allows each member state to implement their own laws on how to reach such goal. The Directive resulted in 28 data protection laws across the EU. In an effort to keep pace with technology, offer greater protections and rights to EU citizens and harmonize data protection laws, EU Parliament approved the final text of GDPR in 2016. Unlike the Directive, GDPR is a regulation—a binding legislative act that is enforceable as law in all EU member states. The immediate result of GDPR is one comprehensive data protection law in the EU, instead of 28, although GDPR has several “opening clauses”, which permit EU member states to modify certain provisions of GDPR. While many aspects of the Directive continue in GDPR, there are key differences that affect U.S. businesses. Just how much effect GDPR has on a business depends on whether that organization is considered a data controller or processor under GDPR.
Controller v. Processor
You must understand your business well enough to answer this question: is your business a controller, processor or both. The answer to this question defines what regulatory duties you have under GDPR.
GDPR defines controller as “the natural or legal person…which, alone or jointly with others, determines the purposes and means of the processing of personal data…” Simply put, a controller is the person who owns or functionally controls the personal data. GDPR defines processor as “a natural or legal person…which processes personal data on behalf of the controller.” Processors take direction from controllers and do not have the right to determine the purpose for which personal data will be used.
Though the distinction may seem clear, in practice many organizations weave in and out of controller and processor roles. In making the controller-processor determination, remember that it does not matter what a business calls itself. Consider for example the SWIFT case. SWIFT (Society for Worldwide Interbank Financial Telecommunication), global financial service provider that facilitates international money transfers considered itself a processor, and called itself a processor in all of its consumer contracts. After September 11th, the U.S Department of Treasury subpoenaed SWIFT to provide access to personal data for the purpose of monitoring financial transactions for terrorist activity.
The Belgian data protection authority (“Belgian DPA”) investigated SWIFT after The New York Times reported on the matter in 2006. The Belgian DPA ultimately found that SWIFT, despite calling itself a processor, was functionally controlling personal data, or rather, sharing personal data without permission from its customers. The Belgian DPA found that SWIFT violated Belgian’s data protection law because as a controller of the personal data it shared with the U.S. government, it did not provide notice to, or obtain consent from, its customers.
The SWIFT case illustrates the importance of thoughtful consideration of whether an organization acts as a controller or processor. It also highlights a common scenario whereby an organization acts as a processor and controller with respect to different data (e.g., controller of HR data, but processor of payment card information).
GDPR introduces new controller obligations that merit special attention. Of particular concern are GDPR’s breach notice, vendor management and privacy by design and default requirements.
GDPR’s breach notice requirements are what many consider to be the most troublesome addition, primarily due to a sweeping definition of what constitutes a breach. GDPR defines personal data breach as “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed.”
GDPR adopts the breach notice requirement developed in the U.S., a concept familiar to many U.S. businesses. However, unlike U.S. state requirements, which generally only apply to unauthorized access or acquisition, GDPR broadens the definition of a breach to include alteration, destruction or loss of personal information. By way of example, a ransomware attack not involving the extraction of personal information would generally not trigger U.S. state breach notice requirements, but could trigger GDPR breach notice requirements if there is a loss of personal information (i.e., an organization’s inability to access its personal information).
Article 33 provides that “[i]n case of a personal data breach, the controller shall without undue delay and where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority…unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.”
Organizations will face two problems with this requirement. First, organizations likely do not fully understand the extent of a breach within 72 hours of becoming aware of it, but will be required to submit a report to a government authority—a report that may not accurately describe the breach. Such report could potentially be produced in class action litigation in the U.S. Second, the exception to notifying the supervisory authority—if the breach is unlikely to result in a risk to the rights and freedoms of natural persons—will understandably lead to internal debates on the necessity of notification.
Article 28 requires that controllers only use processors that provide sufficient guarantees to implement appropriate technical and organizational measures. It further provides that any processing must be governed by a contract, and such contract must obligate the processor to:
- process personal data only on documented instructions from the controller;
- ensure confidentiality;
- Implement appropriate security measures;
- assist the controller with its obligations to comply with certain provisions of GDPR;
- delete or return personal information upon request; and
- provide information necessary to demonstrate compliance with its obligations.
Article 28 poses a challenging task for businesses that outsource processing activities. To comply with GDPR, organizations will need to update their contracts with vendors that process EU personal data. This may seem like a simple task, and it may in fact be if updating a standard form agreement is all that is required for your business. However, the real challenge is identifying current vendors that process EU personal data, locating those contracts and explaining to vendors why you need them to take on additional burdens or liability in the middle of the term with no additional compensation.
Vendors, especially those with no nexus to the EU will likely question why they must assist the counter party with its GDPR compliance. In some cases, vendors will be unfamiliar with GDPR. Businesses will need to carefully determine which contracts need to be updated and be prepared to explain to vendors the reason why.
Businesses with a high volume of vendor contracts should start with high risk vendors (i.e., vendors that process significant amounts of EU personal data or data that is considered sensitive) and update their contracts in batches.
Privacy by Design and default
Prior to GDPR, organizations complied with global data protection laws via privacy policies, contractual terms, registrations, etc. For the first time in the privacy arena, GDPR requires organizations to take one step further and develop products with privacy in mind. This will require different departments within an organization to work together to develop GDPR compliant policies, procedures and systems simultaneously with product development. This concept is known as privacy by design.
Article 25 provides that “[t]aking 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, the controller shall, both at the time of the determination of the means for processing and at the time of the processing itself, implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation, in an effective manner and to integrate the necessary safeguards into the processing…”
One important question to consider here is whether an organization’s products or systems are capable of complying with data subjects’ rights. Under GDPR, data subjects have several rights, including the right to erasure and data portability. That is, individuals have the right to request that a controller delete their personal information (right to erasure) or export it in a machine readable format for their own personal use (data portability).
Many existing technology systems were not designed to delete data or export it in machine readable format. Updating such systems can be costly and time consuming. The good news, however, is organizations may consider the cost, available technology, and risks to data subjects when deciding whether to undertake substantial engineering efforts to restructure certain products and systems. In other words, technical and organizational measures implemented by Facebook, may not be appropriate for a local startup.
In addition to privacy by design, GDPR requires privacy by default. Article 25 further provides that “[t]he controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed.” Privacy by default refers to procedures and settings a business implements. It requires that organizations (i) only collect personal information for a specified purpose; (ii) retain the minimum amount of personal information necessary; and (iii) retain such personal information only as long as necessary.
It will be impossible to implement privacy by design and default without an organization or business knowing key information about the data it collects. Specifically, businesses should know what type of data they collect, where it is stored (HR, marketing, etc.), how long data is kept and how it is used. This process is known as mapping. Businesses should map their data and develop policies and procedures on how to respond to data subjects exercising their rights under GDPR.
Under the Directive, only controllers had direct compliance obligations. This is not the case under GDPR. GDPR introduces several new requirements on processors and exposes them to substantial penalties and claims. While processors have fewer obligations than controllers, they will face significantly increased risk under GDPR. Key obligations on processors include the duties to notify the controller of a breach and to implement appropriate security measures.
Article 33 requires processors to “notify the controller without undue delay after becoming aware of a personal data breach.” However, a processor’s obligation with respect to a data breach will likely not stop at notifying the controller. As noted above, if the controller is GDPR compliant, its contract with a processor will require the processor to assist the controller with its breach notice obligations. Therefore, processors will not only be required to notify the controller of a breach, but can also expect to be contractually obligated to provide other information about the breach that will assist the controller’s compliance with its obligations under Article 33. A processor’s failure to notify the controller of a data breach not only exposes a processor to penalties under GDPR, it may also result in a breach of contract.
Article 32 provides that the “…processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk,” including pseudonymisation and encryption of personal data, the ability to ensure the ongoing confidentiality and the ability to restore the availability and access to personal data following a technical event. Accordingly, processors and controllers have the same obligation to implement appropriate security measures. Under the Directive, controllers were responsible for ensuring that processors implemented such measures. GDPR now places that responsibility on processors as well.
When determining what constitutes appropriate security measures, remember that what may be appropriate for one processor, may not be appropriate for another. Processors have some flexibility in making this determination because GDPR allows processors to consider the state of the art, costs of implementation, nature, scope, context and purposes of processing, as well as the risk to data subjects.
As noted above, controllers should still contractually obligate processors to implement appropriate security measures, which means a failure of a processor to do so will result not only in a breach of contract, but also a violation of GDPR.
GDPR is here to stay. U.S businesses need to understand and recognize when GDPR might impact their businesses. While GDPR introduces several obligations that could potentially affect U.S. organizations, you should pay particular attention to whether you are a controller, processor or both. Making that determination will identify what obligations your business has under GDPR. Complying with those obligations will protect your business from substantial penalties under GDPR.