GDPR: Where in the World are My Records, Anyway?

First off, a disclaimer: I am not a lawyer and I have no legal training! I’m not even that good at playing Ace Attorney, so you definitely shouldn’t take anything I say as legal advice. Please consult your own legal counsel for any clarifications or specifics around anything you read here.

By now, most marketers know that GDPR regulations mean they need to capture consent to message Europeans and are taking the steps outlined in the first part of our series to update privacy policies and record when someone opts in to messaging. Keep in mind that the General Data Protection Regulation has data at its heart. As marketing departments become increasingly larger data stewards for organizations, we need to think about what data is being collected and who these data protection laws cover.

Protecting Sensitive Personal Data

One of the most often overlooked parts of GDPR for marketers is Article 9, which talks about prohibited types of data processing—information that you are not allowed to keep about a person unless you have very specific reasons outlined in the legislation. These special categories of personal data include any data on a person’s:

• Racial or ethnic origin

• Political opinions

• Religious or philosophical beliefs

• Trade union membership

• Genetic or health status

• Sex life or sexual orientation

While most companies would immediately say they don’t capture this kind of data, it’s important to remember where this sort of data could show up unintentionally to identify someone when collecting marketing information. For example, if your company is hosting a luncheon for prospects, you may ask if the person needs a kosher or diabetic-friendly meal. Collecting and keeping this kind of data means you’re handling sensitive personal data, since religious or health data could be concluded based on the answers to these questions.

You’ll want to perform a review of your databases to see if anything that could reasonably infer any of these groups of sensitive personal data is currently being stored or captured and adjust your intake and handling of these data points accordingly. You’ll want to either delete the data for EU citizens (which aren’t just limited to those in EU countries–see more on this below) find a non-identifying way of capturing the information you need, or put an express warning when you capture the data (for example, “we’ll use this information to determine your lunch and then purge it from our system for your privacy.”)

When handling this sort of data, you should keep only what you need for exactly as long as you need it. In other words, as soon as it’s irrelevant, it should be purged from any database that you’re using. Ideally, you would store this content in a way that doesn’t even link the data to a particular person (so simply count how many of each type of meal are needed, for example) to prevent any potential issues.

It’s also important to stress that when it comes to special categories of personal data, you should take a higher level of privacy and care when handling records: be sure to not make copies of data, don’t load items onto a USB stick or email files that may contain sensitive personal data unless the data has been encrypted.

Finding Who’s Covered by GDPR

Once you’ve reviewed your database for any potentially sensitive data, the next logical step is to figure out what records require GDPR protection. However, if you haven’t been practicing good data hygiene, figuring out where your records reside may be an exercise in and of itself. The steps outlined here are specific to getting your database specifically ready for GDPR, but if your database needs a deep cleaning, our eight-step data hygiene checklist can help.

The very first (and easiest thing to do, long-term) is to look at the geographic data you’ve captured up until now and come up with some way to standardize values. Make some decisions on how you want to store things (Full state/province name or two-letter code? Full country name or abbreviation? Local language or standardized to one language?) in order to know what your baseline is and make sure wherever someone is located is stored in a way that you can reliably search against.

Additionally, you’ll want to establish a common list of countries your company recognizes as distinct, as there are different answers depending on who you ask: as an example, some companies would list Puerto Rico as its own country or territory, whereas others list it as state in the United States. DemandLab recommends starting with the ISO 3166-1 list of countries (which is used by Google’s APIs) and modifying the list as appropriate for your business. Keep in mind that if you use any geodata appending services, they may have their own variations of what a country is or isn’t and you’ll need to account for those.

Why is this important? Simply put, EU citizens are simply not just citizens of the main EU countries, but any country/territory those main EU countries offer citizenship to.

Countries/Territories with EU Citizenship include:

• Anguilla

• Aruba

• Azores

• Bermuda

• Bonaire, Sint Eustatius, and Saba (previously known as the Netherlands Antilles)

• British Antarctic Territory

• British Indian Ocean Territory

• British Virgin Islands

• Büsingen am Hochrhein

• Campione d’Italia

• Canary Island

• Cayman Islands

• Ceuta and Melilla

• Channel Islands (Bailiwick of Jersey and Bailiwick of Guernsey)

• Falkland Islands

• French Guiana

• French Polynesia

• Gibraltar

• Greenland

• Guadeloupe

• Helgoland

• Isle of Man

• Livigno

• Madeira

• Martinique

• Mayotte

• Montserrat

• Mount Athos

• New Caledonia

• Pitcairn Islands

• Reunion

• Saint Barthélemy

• Saint Helena, Ascension and Tristan da Cunha

• Saint Martin

• Saint Pierre and Miquelon

• Sint Maarten

• South Georgia and the South Sandwich Islands

• Turks and Caicos Islands

• Wallis and Futuna

Because some of these areas are listed as their own countries and some as territories, you’ll need to double-check that these areas are accounted for in any GDPR setup you craft.

Once you’ve determined your list of countries, you’re going to want to standardize this list wherever countries are offered: on website forms, on your official products (if applicable) and in places like your CRM; if you’re using Salesforce, you may want to look into implementing state and country picklists. This will give you one source of truth and one set of values to look for in your database.

With that in mind, you’ll now need to go through your database and:

• Standardize the values for your countries (DE, Deutchland and Baden-Württemberg all say “Germany” in the country field, for example) to align to the list of countries you’ve decided upon.

• Append country data where you can make reasonable inferences–if you have a city, state and postal code, but no country, you can probably figure out the country. You’ll want to apply this level of logic across your entire database.

Do note when you do this sort of standardization that it’s a good idea to dump all of your address fields, because it’s very common for data to be entered into incorrect fields (postal code in country, city in state, etc.) and now’s a great time to correct those mistakes.

Once this process is completed, you’ll have a clearer understanding of what data you have, but odds are you will likely have a lot of incomplete data. There are a few methods we can take to try to figure out if a record would fall under GDPR:

Email Address: One of the biggest clues of a record’s location can be found in their email address. Most European email providers use a country-code top level domain (such as web.de, orange.fr or yahoo.co.uk) at the end of their domain, so using a tool that can search for these ends can help track down Europeans who may not have country information on file. Additionally, you can look for major European email providers who don’t necessarily have a country code at the end of their domain. Examples of European services that use standard domains include:

• @btinternet.com

• @btopenworld.com

• @fsmail.net

• @gmx.com

• @laposte.net

• @mail.com

• @ntlworld.com

• @plus.net

• @sky.com

• @talk21.com

• @talktalk.net

• @virgin.net

• @virginmedia.com

Phone Number: When storing international phone numbers, a few patterns typically emerge: either a number will be stored with a plus sign in front of it, or have its two/three-digit country calling code separated by a hyphen or space. As such, searching for numbers that start with plus signs can give clues—do note that while US and Canadian numbers start with +1, some areas affected by GDPR such as Bermuda and Montserrat use calling codes like +1 441 or +1 664.

By using quotation marks, you can do some deep querying in Salesforce to account for potential spaces and hyphens. For example, a query like:

Phone starts with “43 “,”32 “,”45 “,”33”,”49 “,”30 “,”36 “,”39 “,”31 “,”48 “,”40 “,”34 “,”46 “,”44 “,43-,32-,45-,33-,49-,30-,36-,39-,31-,48-,40-,34-,46-,44-

will cover phone numbers in Austria, Belgium, Denmark, France, Germany, Greece, Hungary, Italy, the Netherlands, Poland, Romania, Spain, Sweden, and the United Kingdom.

There are also three-digit country code prefixes for some numbers, but these do run the risk of accidentally catching US phone numbers based on area codes, so exercise discretion when viewing these results.

Phone starts with “359 “,”385 “,”357 “,”420 “,”372 “,”358 “,”350 “,”353 “,”371 “,”370 “,”352 “,”356 “,”351 “,”421 “,”386 “, 359-,385-,357-,420-,372-,358-,350-,353-,371-,370-,352-,356-,351-,421-,386-

These codes cover Bulgaria, Croatia, Cyprus, Czechia, Estonia, Finland, Gibraltar, Ireland, Latvia, Lithuania, Luxembourg, Malta, Portugal, Slovakia, and Slovenia.

Finally, if you haven’t done so already, now is an excellent time to standardize your phone number formatting in Salesforce. When using Phone type fields in Salesforce, the system will make you use a plus sign if you’re not entering a standard US/Canadian (+1) phone number, so this can also give you some clues for finding international numbers.

Inferred Country data: Marketo uses a service to translate the first IP someone uses to visit your website into geolocation data. This data can be spotty at times (for instance, despite having lived in California and Pennsylvania, my mobile IP often gets flagged as Virginia), but typically it will get an IP country correct if it can positively identify one. It’s important to stress that this is only the first IP seen; if someone shows up once in the United States and then subsequently is seen from Denmark, the Inferred Country for the record will still say United States.

Based on a combination of these three items, you’ll want to place your remaining records in one of three buckets: Likely EU, Not Likely EU or Undetermined. If you don’t feel comfortable appending a particular country to records that are likely or not likely EU, you may want to create a standalone field that denotes how a record falls under one of these three categories.

That’s a lot of effort. I’m just going to get a third-party tool or service to help me figure out who’s in Europe.

Hold your horses! If you’ll remember, the main part of GDPR is data protection. As a steward of your records, you’ll need to think about how these records are processed and if you’re passing over any protected information. This is also a great area to draw to your legal counsel’s attention (as well as any department that handles data movement, like sales), as this starts to get a bit complex.

If you send your data out to a third party (for example, to get address data appended to figure out where someone is), whether that’s a vendor, an agency or another company you share your records’ data with, you’re going to need to ensure these parties (which we’ll call “data processors”) are complying with GDPR regulations as well: they’re not handing off data to other third parties, proper precautions are taken when data is moving in and out of borders, there’s adequate security, etc. You should review all third parties that act as data processors for your company and ensure that you have a data processing agreement in place.

Do note that if you use a service like a data enrichment company to try to figure out where someone is, you will need to send over data with no personal identifying information. As such, you would be looking at completing partial addresses, looking up business locations, or checking against domains rather than include data such as name, phone, or email address. This is why we recommend doing your own in-house work to identify records first and using a data enrichment vendor as a supplemental item.

If you’re looking for more guidance on data processing, you’re not alone: stay tuned for the next part of our series, where we’ll take a deep dive on what you and your company need to do when handling third parties.