By Gabe Levine, Principal Attorney / Founder, Groundwork Legal and Josh Barrett, Attorney / Principal, CreateLegal
Ok, first of all, this article is not legal advice, and it’s not meant to be a primer on GDPR. There’s like a thousand of those out there—some good, some bad and some mediocre. (We even link to one of the good ones.) But do go ahead and get some legal advice if you think you might be impacted by GDPR.
I. Setting the Stage
Relax, it’s not like you’re not already violating some data protection laws and agreements…
Let’s start with some more locally-curated flavors of data protection, unrelated to the European General Data Protection Regulation (GDPR). The United States may not be a sufficient protector of “data subjects” personal data, according to the European Union, but we are certainly not without regulation, both at a state and federal level. To name a few, we’ve got:
The Original! The California Online Privacy Protection Act, known as Cal-OPPA;
Not to be confused with “COPAA” or the Children’s Online Privacy Protection Act;
HIPAA and related “Personal Health Information” laws;
The Gramm–Leach–Bliley Act for bank customers’ protection; and
The Massachusetts Data Security Regulation (MDSR).
If you’ve signed any agreements incorporating the “Information Security” policies of any public company in the technology, medical, banking or other highly-regulated sector, you’re probably in technical breach of those agreements. If you’re hosting, processing or even just accessing any of this regulated data, you might even be violating some laws or regulations. And nothing bad has happened yet…Right?
Now that you’re a little more relaxed, let’s turn to GDPR…Ok, panic! No, just kidding.
II. Is My Agency Subject to GDPR?
You might not be subject to GDPR’s territorial reach.
Without getting too granular or legalistic about it, the folks trying to read the tea leaves of GDPR’s territorial reach provision seem to think that it requires something more than merely having a website accessible to Europeans. Either you have to have a presence in Europe, collect more than incidental European personal data or target European citizens (through, for example, localizations or European currency transactions). Of course, the “mentioning of customers or users who are in the Union” may also be enough, according to the official guidance. We’re not exactly sure what this means, and you never know, but the bottom line here seems to be that you’re not automatically subject to the GDPR simply because your site is accessible to European citizens. Time (and regulatory and/or court actions) will tell.
So, you’re totally in the clear!
Just because you might not be subject to GDPR doesn’t mean you should do nothing. I mean…you might be…but also…just like the enactment of Cal-OPPA led to Privacy Policies becoming de rigueur, we suspect the same will be true of GDPR standards for disclosure and informed consent. Again, this isn’t a primer; so, we’re not going to tell you what to do, but we do want to provide some useful information if we can.
III. How Might You Be Impacted?
As a digital agency, there are a number of ways we see that you can be impacted:
As a controller with regard to information provided through your corporate (or brochure-ware) site;
As a processor for your clients (for example, if you are offering any hosting or similar services where you might receive, store or process personal data); and
As an agency designing and developing websites and applications.
IV. What We’re Thinking
Taking each of the above possibilities in turn:
As a Controller: Unless you (a) have a physical presence in Europe, (b) are collecting more than incidental European personal data or (c) are targeting European citizens through localizations or European currency transactions, probably don’t lose a lot of sleep over your brochure-ware site. (SaaS, mobile and desktop software applications are beyond the scope of this little piece.)
As a Processor: If you have a European or multinational client for which you are hosting or otherwise processing user data, you’ll probably be asked to sign a Data Processing Addendum (DPA), which will, once signed, leave no doubt that you are subject to GDPR. Either way, like any other agreement you sign, you should know what’s in that thing, and then make the decision whether the risk is worth the reward. The first step there is to actually read it, because these DPAs (like InfoSec policies) are usually more than 50% technical, and your lawyer may just shrug, and ask whether you can and will do what the agreement requires. (Here’s a useful little checklist on compliance for processors.) Unfortunately, and to make a long story short, these DPAs are going to suck. They will certainly include the “Standard Contractual Clauses” (SCC), which, amongst other crappy things, subject you to the jurisdiction of the European courts and agencies and make the data subject a “third-party beneficiary” of the agreement. So, random French dude can bring an action against you in Europe. The unfortunate reality is that this may be a requirement if you want to serve European clients, especially if you want to store or process their data. (As an aside, this is yet another reason to avoid “hosting” and related services. Stay away from the data, and you’re obviously in a much better situation.)
As a Designer/Developer: Some of you will almost certainly have clients who will ask you to help them comply, or simply say that they need their site or application to comply with GDPR. Look, from a contractual standpoint, this is probably not a reasonable guarantee to make, unless your agency is actually an expert at designing and building GDPR-compliant applications/systems and have budgeted to do so for the particular project. Nonetheless, agencies should start what will be the inevitable move towards compliance by obtaining education for designers and developers on how to actually create sites and applications that comply. The whole industry will obviously need to learn, get better and adapt to new practices, as it has for accessibility standards. (We think there’s some additional useful guidance here and here.)
In general, we think it makes sense to do what you reasonably can to move in the direction of compliance, and to help your clients to do so (while being mindful that you shouldn’t make promises you can’t keep). For example, you might:
Establish internal policies and procedures to protect user data (whether it’s your client’s users for sites or applications you’re supporting or your own sites and applications);
Investigate whether the services you use to store and process data have adequate protections and reasonable agreements; and
Investigate whether it makes sense for you to obtain an insurance policy that covers data breach (often known as a cyber—yes, freakin’ cyber!—policy) and whether that policy does or can cover GDPR/Europe-related actions and obligations.
V. A Tweak to the Bureau Standard Statement of Work
In light of this whole GDPR thing, we’ve made a few updates to the Bureau Standard Agreement Statement of Work, which is being released as version 1.2 with this blog post, and is available for download here:
We generalized and expanded the excluded work bullet relating to regulatory compliance with privacy laws. This exclusion means that the Client is responsible for determining what it needs to do to be compliant and provide those specifications to the Agency.
We included three new assumptions relating to privacy compliance. When included, these provisions give the Agency comfort that it will not be subject to GDPR (and if the Client got these things wrong, Agency has a basis for terminating the agreement or adjusting its fee). These items are also canaries in the GDPR coal mine—if the Client rejects one or more of these items, you’ll know that you have GDPR issues to contend with (and time to call a lawyer for help).
The first item assumes that the Client’s data handling practices comply with applicable privacy laws. This assumption makes clear that privacy compliance is the Client’s responsibility.
The second item is an assumption that the project won’t cause the Agency to be treated as a “data processor” or “data controller” under GDPR. If the project would cause an Agency to be treated in one of these ways, you’ll know to get some GDPR support.
The last bullet point is an assumption that the Client won’t provide the Agency with personally identifiable information (e.g., names, email addresses, location, race/ethnicity, etc.) relating to citizens in the EU. Effectively, if an Agency can’t see or access the type of data regulated by GDPR, it’s unlikely that GDPR will apply.
Looking for more insights? Join Josh and Gabe for their workshop, "Bureau Standard Form of Agreement: SOW Edition for DPMs" at the Digital PM Summit in Memphis this September.