Research paper

profilekoti
Reference4.pdf

A rticle

GDPR: What (a n d Why) You Need to Know A bout EU D ata P rotection Law by Kyle Petersen

T h e European Union General Data Protection Regulation (GDPR) went into effect on May 25, 2018. You have likely already h eard of GDPR, but why should you care about EU law? You should care because GDPR expands the territorial scope of EU data protection laws, significantly increases the penalties for non-compliance, and is enshrouded with uncertainty. In other words, it should have your attention because: (i) organizations with no physical presence in the EU may be subject to GDPR; (ii) like U.S. anti-bribery and anti-trust laws, GDPR introduces extremely high fines - up to 4% of annual global m mover (an activist group in the EU filed complaints against Facebook and Google within h ours of GDPR com ing into effect seeking roughly $8 billion in fines); and (iii) it remains to be seen how strict EU data protection authorities will enforce GDPR. GDPR com es from a civil law legal system, which can be frustrating for U.S. trained attorneys to navigate. Civil law jurisdictions are historically highly regulated, but enforcem ent of those regulations is often inconsistent. For these reasons, you should be aware of GDPR and understand it enough to recognize when it might affect your clients.

The first thing to know about GDPR is to whom 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 o r services to individuals located in the EU; o r (iii) m onitor behavior of individuals located in the EU. See Regulation 2016/679 of the European Parliam ent and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC, 2016 O.J. (L 119), art. 3. U.S. organizations 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. organizations, particularly those in the business-to- business, o r B2B, context. It also provides practical insights on

achieving compliance and the challenges organizations will likely face in doing so. While it focuses on aspects that many consider to be the most concerning, this article addresses a m ere fraction of GDPR. For example, in the B2C context, organizations need to have a legal basis for processing personal data, comply with GDPR’s notice requirem ent, and be able to respond appropriately to individuals exercising their “data subject rights,” all of which this article does not address but are equally important.

B A C K G R O U N D O N EU D A TA P R O TE C TIO N L A W S

Since 1995, the EU has regulated data privacy u n d er Directive 95/46/EC of the European Parliam ent and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data, 1995 O.J. (L 281) (Directive). A directive is EU legislation that requires m em ber states to achieve a certain goal but allows each m em ber state to im plem ent its own laws on how to reach such goal. The Directive resulted in twenty-eight data protection laws across the EU. In an effort to keep pace with technology, offer greater protections and rights to EU citizens, and harm onize 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 m em ber states. The immediate result of GDPR will be one com prehensive data protection law in the EU, instead of twenty-eight, although GDPR has several “opening clauses,”

KYLE PETERSEN is an associate attorney at Kirton McConkie.

Volume 3 1 1 . 4

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 will affect U.S. organizations. Just how much effect GDPR will have on an organization will depend on whether that organization is considered a data controller or processor under GDPR.

CONTROLLER V. PROCESSOR

Before you worry about all of GDPR’s ninety-nine articles, you must understand your client's business well enough to answer this question: is your client a controller, processor, or both? The answer to this question defines what regulatory duties your client has 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.” GDPR, art. 4. 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.” Id. 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 mid out of controller and processor roles. When making the controller-processor determination, it does not matter what an organization calls itself. Consider for example Opinion 10/2006 on the processing of personal data by the Society for Worldwide Interbank Financial Telecommunication (SWIFT), Article 29 Working Party, Nov. 22,2006. SWIFT, a 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 the September 11, 2001 terrorist attacks on the United States, 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

Have confidence in Eide Bailly's experienced and certified professionals. We can assist

with economic damage calculations, forensic accounting and fraud investigations,

computer forensics and eDiscovery management.

W hat inspires you, inspires us. 801.456.5957 | eidebailly.com /forensics

EideBailly CPAs & BUSINESS ADVISORS

13

m

customers. The Belgian DPA found that SWIFT violated the Belgian 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 as required by Belgian law. Id.

The SWIFT case highlights the importance of thoughtful consideration of the controller-processor classification. It also illustrates a common scenario whereby organizations act as processors and controllers with respect to different types of data (e.g., controller of human resources data but processor of payment card information).

Controller Obligations

Controllers have several obligations under GDPR. Although many requirements introduced by the Directive continue under GDPR, GDPR introduces new controller obligations that merit special attention. Of particular concern are GDPR’s breach notice, third party processor, and privacy by design and default requirements.

Breach Notice 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, art. 4.

GDPR adopts the breach notice requirement developed in the United States, a familiar concept to many U.S. attorneys. However, unlike state requirements in the U.S., 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. Byway of example, a ransomware attack not involving the extraction of personal information would not generally 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.

Id. art. 33.

In addition to notifying the supervisory authority, an organization must also notify the data subject if the personal data breach “is likely to result in a high risk to the rights and freedoms of [the data subject].” Id. art. 34.

Organizations face several challenges with GDPR's breach notice requirement. First, organizations will likely not fully understand the extent of a breach within seventy-two 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 United States. Next, when is an organization considered to have become “aware” of the personal data breach? Finally, 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.

Third Party Processors Article 28 requires that any processing carried out on behalf of a controller 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.

Id. art. 28. Article 28 poses a challenging task for organizations that outsource processing activities (e.g., doud storage, payment processors, marketing communications, etc.). To comply, organizations will need to update their contracts (or put contracts

14

Article 25 provides that

[t]aking into account the state of the ail, 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.

Id. art. 25.

in place) with vendors that process EU personal data. While updating a standard form agreement with GDPR specific language is a relatively simple task, 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 many cases, U.S. vendors will be unfamiliar with GDPR. Organizations will need to carefully determine what contracts need to be updated and be prepared to explain to vendors the reason why. Whether you advise controllers or processors, watch out for language that appears GDPR-related but is too broad or narrow (i.e., the contract introduces obligations not required under Article 28 or obligations that do not meet the standards set forth in Article 28).

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.

One challenge an organization may face here is whether its products or systems are capable of complying with certain requirements under GDPR. For example, GDPR grants several rights to data subjects, including the right to erasure and data portability. Id. art. 17, 20. 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

| Babcock Scott & Babcock, P.C. S S A TTO R N EY S & COU NS E LOR S AT L A W | W E BU ILD SOL UTION S

(801) 531-7000 • www.babcockscott.com Over 100 combined years o f legal experience

B U I L D I N G R E S O L U T I O N • C O N S T R U C T I O N & C O M M E R C I A L M E D I A T O R S

15

systems can be costly and time consum ing. However, organizations may co nsid er the cost, available technology, and risks to data subjects when deciding w h ether to und ertake substantial engineering efforts to restru ctu re p ro du cts and systems. In o th er w ords, technical an d organizational m easures im plem ented by Facebook may not be ap pro priate for your client’s organizaiton.

In addition to privacy by design, GDPR req u ires privacy by default. Article 25 furth er provides that “ [t]h e c o n tro ller shall im plem ent ap p ro p riate technical and organisational m easures for en surin g that, by default, only p erson al data which are necessary for each specific p u rp o se of the p rocessing are p ro cessed .” Id. art. 25. Privacy by default refers to p ro ced u res an d settings an organization im plem ents. It req u ires that organizations (i) only collect p erson al inform ation for a specified purpose; (ii) retain the m inim um am ount of p ersonal inform ation necessary; an d (iii) retain such personal inform ation only as long as necessary.

Organizations will struggle to im plem ent privacy by design and default w ithout knowing key inform ation about the data it collects. Specifically, an organization should know w hat type of data it collects (hum an reso urces, m arketing, etc.), w here it stores data (on-site servers, cloud, etc.), how long data is kept, an d how it is used. This p ro cess is known as mapping. Data m apping will help organizations develop internal GDPR-compliant policies and pro ced ures.

P r o c e s s o r O b l i g a t i o n s

Under the Directive, only co ntro llers h ad direct com pliance obligations. This is not the case u n d er GDPR. GDPR introduces several new requirem ents on p ro cesso rs an d exposes them to substantial penalties an d claims. While p ro cesso rs have fewer obligations than controllers, they will face significantly increased risk u n d er GDPR. Key obligations on p ro cessors include the duties to notify the co n tro ller of a breach and to im plem ent ap p ro p riate security m easures.

Breach Notice

Article 33 req u ires p ro cesso rs to ‘‘notify the co n tro ller without undue delay after becom ing aw are of a p erson al data b re ach .” Id. art. 33. However, a p ro c e s so r’s obligation with resp ect to a data breach will likely not stop at notifying the controller. As noted above, if the co n tro ller is GDPR com pliant, its contract with a p ro cesso r will req u ire the p ro cesso r to assist the

co n tro ller with its b re ach notice obligations. Therefore, p ro cesso rs will not only be req u ired to notify the co n tro ller of a b reach but can also expect to be contractually obligated to provide o th er inform ation ab ou t the b re ach that will assist the co ntro ller with its com pliance obligations u n d e r Article 33. A p ro c e s so r’s failure to notify the co n tro ller of a data b reach not only exposes the p ro c e s so r to penalties u n d er GDPR, it may also result in a breach of contract.

Security Measures

Article 32 provides that the “p ro c e s so r shall im plem ent ap p ro p riate technical an d organizational m easu res to en su re a level of security ap pro priate to the risk ,” including pseudony- misation an d encryption of p erson al data, the ability to en sure the ongoing confidentiality, an d the ability to resto re the availability an d access to p erson al data following a technical event. Id. art. 32. Accordingly, p ro cesso rs and contro llers have the sam e obligation to im plem ent ap pro priate security m easures. Under the Directive, co ntro llers w ere responsible for ensuring that p ro cesso rs im plem ented such m easures. GDPR now places that responsibility on p ro cesso rs as well.

When advising on what constitutes ap pro priate security m easures, what may be ap p ro p riate for one p ro cesso r may not be ap pro priate for another. P rocesso rs (an d co ntro llers) have som e flexibility in m aking this determ ination b ecau se GDPR allows p ro cesso rs to co nsid er the state of the art, costs of implem entation, nature, scope, context, an d p u rp o ses of processing, as well as the risk to data subjects.

As n oted above, co ntro llers should still contractually obligate p ro cesso rs to im plem ent ap p ro p riate security m easures, which m eans a failure of a p ro c e s so r to do so will result not only in a breach of contract, but also a violation of GDPR.

C O N C L U S I O N

GDPR is h ere to stay and will likely becom e the global stan dard for data privacy. In today’s data-driven world, you should u nd erstand GDPR well enough to recognize when it might im pact your client’s business. While GDPR intro du ces several obligations that could potentially affect U.S. organizations, you should pay p artic u lar attention to w h ether your client is a controller, processor, o r both. Making that determ ination will identify w hat obligations your client has u n d er GDPR. Complying with those obligations will protect y our clients from claims an d substantial penalties u n d e r GDPR.

16

Copyright of Utah Bar Journal is the property of Utah State Bar and its content may not be copied or emailed to multiple sites or posted to a listserv without the copyright holder's express written permission. However, users may print, download, or email articles for individual use.