By Bradley Gross, Founder & President, The Law Office of Bradley Gross, P.A.
The General Data Protection Regulation (GDPR) became effective on May 25, 2018, and U. S.-based services providers have been in a panic ever since. Blogs, social media aggregators, and industry pundits have attempted to explain the scope of the regulation, usually with greater measures of inaccuracy than success. Consultants are also jumping on the bandwagon, peddling their services by exploiting services providers’ fear of prosecution under the new regulation. On top of this, most articles on the subject are written by people who have neither read the entire GDPR nor have any historical knowledge of the scope and enforcement of privacy laws in the EU or U.S.
Service providers are scared. Customers are concerned. The EU is watching, and lawyers are trolling about (as they tend to do) waiting to see who they can sue, and how much they can recover. With that as a backdrop, it’s time to separate fact from fear and determine whether your company needs to modify its service offerings or practices in light of the provisions of the GDPR.
THE HISTORY OF THE RIGHT TO BE FORGOTTEN
We begin with a concept that has long existed in Europe and which forms the cornerstone of the GDPR: namely, the right to be forgotten. In Europe they don’t just talk about the right to be forgotten—they actually implement it. The first attempt to enforce the right to be forgotten can be traced back to 1995, when the EU implemented the EU Data Protection Directive. The directive purported to provide privacy protections for EU residents causing companies worldwide to reexamine the ways and means by which they gathered and used individuals’ personal information. While it wasn’t perfect, the directive was a good first attempt at protecting individuals’ privacy. It even had the buy-in of the U.S. Federal Trade Commission, which created and enforced a framework by which companies could transfer EU residents’ information from the U.S. to the EU without violating EU law.
"Assuming that your company determines the means by how its clients’ data is processed, does it also determine the purpose of that processing? Let me answer that question for you: No, it doesn’t."
But the directive had several flaws, the biggest of which allowed EU countries to create their own data privacy laws. Consequently, various EU countries created and enforced their own privacy laws, sometimes without regard to the privacy laws of their neighboring countries. The resulting patchwork of laws were difficult to reconcile, and even more difficult to enforce.
In the meantime, the right to be forgotten took center stage in several EU court cases. In 2014, an EU court required Google to de-list certain articles from its search results. Two years later, a court in Italy ruled that a newspaper was required to anonymize online archives of its articles, holding that the newspaper’s online archive had expired “just like milk, yoghurt, or a pint of ice-cream.” Around the same time, a Belgian court ruled that a newspaper was required to remove all decades-old referenc-es to an individual in its online archives, and found that the individual’s right to be forgotten was more important than the newspaper’s right to freedom of expression. Just last year, France’s privacy regulator asked the highest court in the EU to determine whether Google had to remove search results only in countries where the removal requests were originated, or whether the removal requests could be enforced across national borders.
Despite all this, however, privacy laws in Europe remained inconsistent. EU members began to clamor for a solution that would harmonize the scope and implementation of privacy rights across the EU. Finally, in April 2016, the EU created a regulation that would (hopefully) resolve the issue once and for all. Enter the GDPR.
"Ambiguity in your company’s master service agreement could mislead your customers into believing that your company has the technical and/or organizational ability to meet the requirements of the GDPR — and that could lead to litigation for both parties due to noncompliance."
Adopted by the EU in 2016 and enforceable as of May 25, 2018, the GDPR imposes significant privacy-related obligations on certain solution providers. But contrary to what much of the current literature says, not all solution providers are required to comply with the GDPR.In fact, I’ll go out on the proverbial limb and say this: Most MSPs do not need to modify their systems or services to comport with the GDPR.
To understand why this is the case, we need to first examine who is covered by the regulation. The GDPR applies only to entities (called “controllers” in the regulation) who “process” the personal information of residents in the EU. As such, if your company doesn’t acquire, store, retrieve, or use the personal information of EU citizens, then the GDPR doesn’t apply to your company.
But’s let’s say your company does possess the personal data of EU citizens. In that case, does the GDPR automatically apply to your business? Do you have to take immediate precautions to ensure that your company’s operations comport with the letter of the law? Not necessarily — and this is where the definitions of “process” and “controller” become extremely important.
Under the GDPR, a company “processes” data when it engages in:
any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure, or destruction.
Admittedly, that’s a pretty broad definition, and it seems to cover virtually any MSP that has anything to do with clients that have access to, or use, GDPR-protected data. But remember, the GDPR applies only to “controllers” who process the personal information of EU citizens. Although your company may “process” information, is it a “controller”? Let’s take a look.
The GDPR defines a “controller” as the person or company that “determines the purposes and means of the processing of personal data.” Question: Why did I emphasize the word “and” in that definition? Answer:
When reading a regulation such as the GDPR, every word matters. In this case, the word “and” may mean the difference between having to comply with the GDPR or ignoring it completely.
When a statute uses the word “and,” it means that the condition before the word “and,” as well as the condition that follows the word “and,” must both be fulfilled for the statute to apply. For example, if I said that I will reward you if you come to my house and sing me a song, then you would need to (1) travel to my house and (2) sing to me. If you sang to me at the mall, I’d owe you nothing. Similarly, if you came to my house but failed to sing to me, then you wouldn’t get a reward.
Under the GDPR, you cannot be a “controller” unless your company determines the “purpose” of why the GDPR-protected data is being processed and the means of how that data is processed. Assuming that your company determines the “means” by how its clients’ data is processed, does it also determine the “purpose” of that processing? Let me answer that question for you: No, it doesn’t.
The “purpose” of processing GDPR-protected data is determined entirely by your client — and not by your company. Could you, for example, tell me the purpose for which your client is using your MSP’s hosted cloud storage solution? Of course not. Perhaps your client uses your service to store its customers’ data for marketing purposes. Maybe your client uses your service solely to store data for archival purposes. Alternatively, your client may be using your service to store information to facilitate warranty services. The truth is, you have no idea what the “purpose” is for your client’s use of your service. For that reason, your company is likely not a “controller” under the GDPR.
Now, like everything in life, there are exceptions. For example, if your company specifically states that it is GDPR-compliant, then it needs to comply with the provisions of the GDPR or it could face significant civil penalties from the EU. Another exception could exist if your company’s master service agreement is ambiguously worded. Ambiguity in your company’s master service agreement could mislead your customers into believing that your company has the technical and/or organizational ability to meet the requirements of the GDPR — and that could lead to litigation for both parties, due to noncompliance.
There’s a lot of misinformation floating around out there concerning the GDPR. My advice: Don’t panic. Have your attorney conduct an audit to determine whether your company both “processes” EU-regulated data, and whether it determines the “purpose” of such processing. In all likelihood, your U.S.-based MSP doesn’t need to worry much about the GDPR.
BRADLEY GROSS is the founder and president of the law office of Bradley Gross, P.A. Gross is a world-recognized expert in information technology law. His law firm specializes in transactions involving MSPs, VARs, OEMs, technology solutions resellers, cloud solutions providers, IT professionals, and technology and media companies globally.