On May 25, 2018, the new General Data Protection Regulation (GDPR) goes into effect in the European Union. If you’re a managed service provider (MSP), what does the GDPR mean to you? Most likely, nothing.
I don’t think that most MSPs will be required to do anything differently from what they were doing prior to the implementation of the GDPR. (And by “most” I mean 99 percent of MSPs—that’s not an exact tally, but I think I’m pretty close.) So if you’re an MSP in panic mode, just relax, and for goodness sakes don’t start paying GDPR “experts” for services that you don’t need.
For those of you who don’t know, the GDPR is a set of new rules that will replace the outdated European Union Data Protection Directive (the “EU Directive”)—a 1995 doctrine that regulates the processing of personal data of residents of the European Union. The idea behind both the GDPR and the EU Directive is to give EU citizens greater control over the ways in which their personal data is obtained, used, stored, corrected, and destroyed.
Since May 25 is only a few weeks away, I’ve been flooded with questions from MSPs across the country asking how, if at all, they need to modify the way they do business. Do we need to implement different security protocols? Do we need to have audits of our systems to make sure we’re in compliance? Do we need to modify our master agreements to accommodate the GDPR? Is it true that you’ve never lost an arm wrestle? (OK, that last one was just to make sure you’re paying attention. But candidly, I can’t remember the last time I lost an arm wrestle.)
Here’s the deal: The GDPR imposes numerous and significant data-related obligations on companies that determine the purpose for processing GDPR-protected data, as well as the means by which such processing occurs. Let me repeat that: To be governed under the GDPR, your company needs to determine why the applicable GDPR-protected data is being processed, and determine the means by which such data is processed. Remember the “and” in that sentence—it’s important, and I’ll be testing you on it later.
Now, I’m a lawyer (pronounced LAW-YA for my New York/Long Island readers), so I feel compelled to break this down a bit more by examining the language of the GDPR itself. We’ll begin with the definition of the activity that makes the GDPR relevant; namely, the meaning of “processing” of data. Under the GDPR, “processing” means:
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.
Wow, that’s a lot of words. In fact, that definition seems to include virtually any MSP that has anything to do with clients that possess or use GDPR-protected data. For example, that definition could include MSPs that provide backup and disaster recovery (BDR) services, since BDR services clearly “process” data by recording, storing, and allowing access to that data, right?
Perhaps, but there’s more to this story … and it has to do with the word “and.” How exciting!
Under Article 12 of the GDPR, the regulation limits itself to “controllers” who process GDPR-protected data. (Now, we already know what “process” means, right? If not, jump back a few paragraphs and keep reading until you get it. I’ll wait … still waiting … welcome back.)
So are you a “controller”? Good question—let’s take a look. Article 4 of the GDPR defines a “controller” as the person or company that “determines the purposes and means of the processing of personal data.” Notice that I highlighted the word “and.” (Why Brad? Why did you do that for a second time in this article?) When a statute uses the word “and” it means that the thing that comes before the word “and” and the thing that comes after the word “and” must both be true before a condition is fulfilled. (For example, if I said I’ll give you $50 if you stand up and sing, then you have to both stand up AND sing; fulfilling one condition without fulfilling the other wouldn’t get you the $50.)
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 the data is processed. Now let’s focus on “purpose”: Does your company determine the purpose of why your clients are using your services to process GDPR-protected data? Let me answer that question for you: No, it doesn’t.
The “purpose” of processing GDPR-protected data is determined entirely by your client. So even if we assume that your company, to some extent, determines the “means” of processing data (i.e., the way in which the data will be stored, accessed, etc.), your company likely doesn’t determine the purpose for why the GDPR-data is being processed. And for that reason, the GDPR likely doesn’t impact you.
Now, like everything in life, there are exceptions. For example, if your company specifically states that it is GDPR-compliant, then it needs to be fully compliant or it could face significant civil penalties from the EU. On the U.S. side of things, the Federal Trade Commission wouldn’t look kindly upon companies claiming to be GDPR-compliant if they weren’t fully compliant. 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 them, and for you, for noncompliance. My advice: Have counsel review your master agreements to eliminate any troublesome ambiguities.
Questions? I love them. Ask away.