Podcast 
GDPR: What U.S. Companies Need to Know

In this episode of Solving for B°, Vice President of Software Development, Donovan Buck and Marketing Copywriter, Jared Haube join us to talk about the GDPR, which takes effect on May 25, 2018. How does this legislation affect U.S. based companies? Our experts will discuss what American businesses need to consider in preparation for the GDPR, how to prepare for the legislation and how to remain compliant.

Read the Transcript

*This transcript has been edited and formatted for readability.

What is the GDPR?

Chris: So, it should be noted that today's discussion is centered around the GDPR and how it affects U.S. based companies. While there's a lot to unpack from a myriad of different angles, we're specifically dealing with what U.S. businesses need to consider about this legislation. With that in mind, let's start with the simple question. What is the GDPR?

Donovan: Well, the GDPR is a suite of new regulations from the European Union and the fundamental spirit of it is that all natural persons – which is distinct from legal persons, you have to be an actual person – have the right to know when their data is being collected and the right to refuse that data collection. If they do consent to data collection they have the right to manage how that data is used, revoke their consent and even choose at a later date to completely be forgotten.

Chris: And just so we're setting a baseline, when does this regulation go into effect?

Donovan: On May 25th.

Chris: Got it. So, this is a regulation from the EU. Why does this matter to companies in the United States?

Donovan: Well, the regulation applies to anyone who is doing business in the EU. “Doing business” might mean having offices in the EU, having distributors in the EU, or just having customers in the EU. Just having someone visit your website from the EU does not required you to adhere to GDPR. That visit does not imply an intent to do business in the EU. But if any of those other things apply, you must be conformant with GDPR or risk being fined.

Jared: You can think of the internet as having essentially no borders, and GDPR reflects that when it comes to enacting strict rules in the area of data collection, retention and use by organizations. This is true for organizations that gather that information, as well as companies that process it, which is an important distinction.

What is the Purpose of the GDPR?

Chris: And the intention of this is to protect us, the consumer, right? It's not necessarily a frivolous piece of legislation just to make companies jump through more hoops. It's so that we don't fall victim to stuff like we're seeing with Facebook and Cambridge Analytica right now.

Donovan: Exactly. So, there was some good foresight there when they were putting this regulation in place because that's exactly what it's designed to protect us from.

Chris: And I think that this can look like it's a little reactionary to the Cambridge Analytica situation. But it isn’t, is it?

Donovan: This has been in works for years. In fact, it's not really the first legislation of its type in the EU. Prior to GDPR and in place now we have the DPD, The Data Protection Directive, which is not necessarily legally binding in all the EU countries. But it's an advisory document stating many of the same principles that we have in GDPR. They're just ratified in GDPR, and with this regulation, they're instantly applicable in all the member countries.

Jared: And that's where the tricky part in GDPR comes in. All the rules and principles embodied within the regulation are very broad in scope. So, there can be a lot of confusion in terms of applicability for compliance.

One more note on that is that the GDPR does not replace or supersede the EU Cookie Law. That piece of regulation is also still in effect. That also adds complexity to what's already existing as Donovan has already mentioned, the DPD. We can really think of the context broad in scope.

Chris: So, this is a pretty layered issue. Even outside of this regulation what the EU is trying to do to protect citizens on the web is pretty complex.

Jared: Yes, and as Donovan mentioned, having the user access your website from the EU does not establish your intention to do business there. However, if you actively court business, GDPR very much matters.

When is it Acceptable to Collect Data?

Chris: So, we've established that the spirit of this regulation is to try to protect users. And the way users are being protected is to forbid the irresponsible collection of their data. But when is it acceptable to collect personal data?

Donovan: Well, there are six legal bases for processing personal data. Most of those don't apply to companies doing business in the U.S. But there are two that do apply:

1. Consent - You can ask for and receive consent from the users to collect their data. That involves stating explicitly and clearly what you are collecting, what you are going to do with their data, who you might share it with and logging that consent --making sure you have a record of that user's consent.
2. Necessity for data to do business - The other legal basis for processing is if having that personal data is strictly necessary for doing business or fulfilling a contract. One example might be if you're selling something online in an e-commerce transaction, of course you need their address, their billing information and so forth. So, you can collect that information because it is necessary to fulfill that contract. But if you're going to use information that you're going to collect during that transaction for other purposes, for that you must gather consent. For example, if I'm going to send an email with other products they might be interested in at a later date, I have to have consent from the user prior to doing that. And I have to let them know that at the point when I'm collecting that data.

Jared: I think one item to note in the context of U.S. based websites and the general rules and principles embodied within GDPR is Article 3. Article 3 of the GDPR merits significant attention because it essentially motivates and underpins most, if not all the other regulations.

The main aspect of part one of Article 3 involves dealing with personal data by a controller or processor who is established in the European Union while part two of Article 3 is about dealing with personal data by a controller or processor that is not based in the EU. And in that context, where they offer services and products to people in the European Union or they track behavior of people in the European Union.

Controller vs. Processor

Chris: In discussion of Article 3, you mentioned a “controller” and “processor” a couple of times. Can we talk a little bit about what is a controller versus a processor?

Donovan: Yes, and I'm just going read right from the GDPR for this one. “The controller is the natural or legal person or public authority, agency or other body that alone or with others determines the purposes and means of the processing of data.”

In short, if you're a BrandExtract client and we're building you a website, you are ultimately responsible for making sure that the principles of GDPR are adhered to. Of course, we are going to do our best to guide you there and give you good advice, but we're not lawyers so it may involve your legal professionals and other people to help inform what needs to be done. We have a good idea of what needs to be done from a technology standpoint. But there are business decisions to be made as well. And those are on you.

We frequently incorporate third-party tools when we build websites. For example, Google Analytics, HubSpot, Pardot, etc. Those are processors of personal data. And the processors are also required to adhere to the standards of GDPR. So, if we're putting Google Analytics on your site and we haven't anonymized the data, then we need to make sure that we've gathered consent from the users.

And how that can reflect on your brand is a concern. Showing a warning to people saying, “We're going track all your usage behaviors, we're going track every page you click on and we're going be able to know what you did” might not be the best thing for your brand.

We strive to make it so that we don't have to worry about getting that consent. We can do that by anonymizing the data. By not being able to identify a single person or individual gives us the power to do things without having to ask for consent. And we are somewhat limited. We can't do the Pardot thing where we try and identify a user in advance. But we can certainly do basic analytics, like knowing how many people are visiting a page. We just don't know exactly who.

Jared: Just to complement Donovan's response regarding data controllers and processors, back to Article 3: if a company isn't established in the European Union then part one isn't applicable. However, if that company or companies that manage and work with personal data of EU citizens, and it sells to or monitors people within the EU, then part two, Article 3 may very well apply.

Considerations When Gathering User Data

Chris: Let's say it is necessary for you to conduct business to get this personal information or you have consent. I think you mentioned in the opening that you have to be able to delete it on command. What are some of the other considerations to keep in mind assuming you do have a reason or a basis for collecting data?

Donovan: As far as gathering consent and the users being able to revoke consent, there does not necessarily need to be a technological solution – you don't have to have an automated process. But you must have a process of some kind that allows the user to submit a request for what data you have about them.

They have the right to correct that data if it's something that makes sense to be there, maybe medical records. They have the right to ask you to remove all that data. That's well within their prerogative to do. And when they do request that their data be removed, you have to respond in a timely manner. You have to get it done.

We don't want to imply that every company has to have some automated tool that people can go and manage all this information. Because honestly, I believe at the end of the day, not that many people are going to make those types of requests. I predict it will be akin to reading an end-user licensing agreement. It will pretty much be scrolling to the bottom and click accept and they move on with their lives and forget about it.

I think that we're going to see a lot of that kind of behavior with GDPR consent forms. People will scroll to the end of the message, then they will click and they will move on with their lives. But we have to have the ability to respond to those requests when they come. So, that doesn't mean that we have to have those automated tools. We don't have to spend all that money in advance. We just have to have a process in place where a human can go and take care of that for them.

Chris: And if you're collecting the data, does it need to be anonymized? Or do we need to take steps to pseudonymize our data?

Donovan: Well, before we go to pseudonymization we should talk about anonymization and identifiable personal data. So, when we're collecting data on users, sometimes we don't know who that user is. We just have a cookie or an IP address or something like that. In our mind that person is anonymous. But in reality, they're just anonymous for now, because we have the ability at a later date to ask them a question or prompt them somehow, or dig and find out who they actually are.

And once we've done that we can reconcile who they are with all the things they've done in the past. So, all that data that we've collected in the past is identifiable. We can figure out who that is eventually, maybe with some extra steps. So, that data, under that principle, is protected because it is identifiable. We can find out who that person is later.

To genuinely anonymize something you have to make it so that you've broken that trail. For IP addresses you can scramble the last octet of the IP address – the last three digits – and not be able to track who that individual is. You can track generally what country they're in but not who the individual is. So, that's a way to anonymize data that you have. That's one practice you could put in place to avoid having to gather consent if there's no way to associate that data with the person.

Pseudonymization actually comes in later, when you're storing data about your users. Rather than storing all that personal data and the identifier for who that user is in the same database, or even in the same data center, you create a unique identifier and put that on both sets of data and you store that personally identifiable information – their name, their email address – somewhere locally and secured and very protected. You've got control over it.

And then the other data that doesn't have the personally identifiable information, maybe something you share with Google Analytics or another processor. Someone who's helping you do some kind of analysis of your data. You share that information with the unique identifier, the ID for that user that you've come up with. So, that processor of your data doesn't have the ability to identify that person. Only you do. That's where pseudonymization comes into play. It's the best practice for keeping people's data safe even outside of the realm of GDPR.

Does GDPR Apply to Already Acquired Data?

Chris: This applies to data that you will be collecting in the future but what about data that you may already have in your systems?

Donovan:  That's one of the sobering things about this May 25th date. BrandExtract, for example, has clients whose websites we've managed for close to two decades. And we have log files going back for two decades. Those have IP addresses. And there are people from all over the world. And come May 25th, if we don't have each of those user's explicit permission to have their personal data stored, then we don't have a legal basis for having that information. So it needs to go. It needs to be erased.

This deadline requires you not only need to have the tools in place for people to service themselves and for you to fulfill your obligations as a data processor, but you also need to get consent from all the users you already have data on before May 25th. And if you don't, that data needs to go.

Jared:  To reinforce Donovan's point there, the impact of GDPR is being felt across the branding and marketing industry. Donovan has touched on BrandExtract’s own position ahead of the May 25th activation date for GDPR, but Adweek recently featured an article that discusses GDPR's impact on mobile marketing. And it noted how an ad tech company called Drawbridge actually closed its media buying unit in Europe because it turned out that the firm's approach to gathering data from mobile tablets and desktops for targeted advertising wouldn't have cut the mustard. And that's just one example of the potential shakeup facing advertising and marketing fields, companies and services.

Penalties for Violation of GDPR

Chris: So, we know the basis of what we need to do. What happens if you are not compliant or you are found in violation of this legislation?

Donovan: Most articles that I see lead with this fact because they're trying to get your attention. The penalties for non-compliance with GDPR can be as high as 20 million Euros or 4% of your total annual turnover, which I take to mean the same as annual revenue.

Those fines are reserved for the most egregious offenders and we're not likely to see anything approaching that for people who maybe made their best efforts and didn't quite get the job done.

But that's just the regulatory agency penalties. You can also be sued by individuals who have had their data compromised. Usually, when these things happen it's more than one person, so you're talking about a class-action suit of some kind. This being the EU, my understanding is that the drive-by demand letters that we see here in the States are less prevalent because there is a risk that you can be forced to pay the defendant's legal fees if you're found to be filing a frivolous lawsuit.

Tips to Prepare for GDPR

Chris: Do you guys have any tips ­– they can be high-level tips – for companies out there right now that are preparing for this?

Donovan: I do. The first one is don't freak out. It's not that bad. I know it can seem scary, especially when people start talking about the penalties. But the steps to compliance are pretty well documented and tangible. If you fancy a bit of light reading, the GDPR text itself is digestible by regular humans, not just lawyers. It's clear. Technically it makes sense. And there are some basic steps that you need to cover to make sure you're in compliance.

Next, you need to look at your site. You need to audit the site for any data collection points that you have. Get rid of ones you don't need. Make sure that third parties that you're using on your site are in compliance. And then if you need one, add a consent mechanism. It can be just a consent mechanism. You don't have to add automated tools. The consent part needs to be automated but the rest can wait.

You can see if the demand is there and if you need to spend the money to build those tools. In the meantime, you can just add processes for managing user data, fulfilling requests from the user for their data, deleting their information and make sure that you have a process in place where you will respond in a timely manner. 

And then lastly, you want to ensure that you and your processors are following best practices for making sure that your data is secure; encryption, pseudonymization, physical security – all the things of that nature.

Jared: From an organizational perspective, I'd say make sure that the stakeholders and key people in your company are aware that things are changing as a result of GDPR, that the inherent awareness is there. Try and document the actual data of EU citizens that your company has. That definitely helps paint the road map to what Donovan was mentioning regarding actual technical steps that you can take.

One more that we can definitely consider is just reviewing the procedures to make sure that all the rights of data subjects are covered. From an organizational standpoint, I think those come to mind as first steps. 

Common Cases to Consider for GDPR

Chris: What are some of the more common scenarios? I know that there's analytics. We use Google Analytics here and I know a lot of people out there are do as well. Does this impact analytics?

Donovan: Well, with Google Analytics, the process when a user hits a page that has a Google Analytics script on it, the first thing that happens is that a request is made to Google for the analytics script. And when that request is made it gives Google the ability to track that user by IP address or even put a cookie on their machine. I'm not saying that Google puts a cookie from their end but they have that ability.

And the second thing that happens is the web page loads and the Google Analytics code puts a cookie on that user's machine, but that cookie is associated with your website domain, not Google.

With Google you have the ability to anonymize the request for the JavaScript code they send you so that they will not record information like the IP address of who requested that file.

And you also have the ability to not put cookies on the user's machine. These are just two little settings in Google Analytics or actually, the little bits of code you need to put in your snippet.

But you could anonymize Google Analytics so that you no longer have to gather consent. It's safe to use because it does not gather personally identifiable information. But by default, it doesn't do that.

Chris: And what about marketing automation software? We brought up Pardot earlier. How does GDPR affect marketing automation tools?

Donovan: So, Pardot's business model is basically built on doing exactly what GDPR doesn't want you to do. To use Pardot you need to gather consent from the users before you put that Pardot snippet on a web page. The language that you use to explain to the users what you're doing and why you're doing it and gathering consent, I think, is going to be a challenging thing to write.

I'm glad that's not my job because you're going to have to explain to them that this is going to give us the ability to track you across every page, know what you're doing and allow us to infer where you work and where you're coming from. I think people might be turned off by that.

Chris: And one other one I want to touch on is hosted fonts. How's the GDPR going to affect hosted fonts?

Donovan:  Well, for any asset that's hosted by a third party – it could be images, it could be fonts, it could be javascript files off a content delivery network – you're giving the person whose stuff you're embedding on your page the ability to do all those same things; track a user by IP address, put a snippet on their machine. And that could be in violation of GDPR.

You need to monitor all those vendors and audit them and make sure they stay in compliance. I think the easier thing to do is just avoid using third-party hosted assets whenever possible because it just generates more work for yourself.

I have one more tip that's really important – web server log files. I think we touched on it earlier, but honestly, not many of the articles I've seen really talk about this. Web server log files by default gather IP addresses just by the fact you put a website on the webserver, it's going do it automatically.

You need to go in and reconfigure your web servers so that when they're writing the request to the log files, the IP address is either scrubbed or it's anonymized. Which is kind of sad from a developer’s perspective because it's helpful sometimes when you're debugging a problem to find out what's going on with one individual. But we have to have their permission to do it.

Chris: Excellent. Well, this has been fantastic. Thank you so much for joining us and helping us to break down the GDPR.

For more on the GDPR, check out our Insights article that discusses the GDPR for U.S. based companies.