Marketing Meets GDPR, Part 2

In Part 1 of this post, we discussed the process of finding, sorting and rationalizing customer Personally Identifiable Information (PII).  We then considered the process of gaining customer consent for data maintained inside of your marketing systems.  The age and organization of the data was considered as well as strategies to reduce the amount of data on hand due to both a potential information liability issue and a cost to maintain issue.  In Part 2 of this paper, we will consider the next phase of the life of the data after it has been rationalized and organized.  What additional considerations do you need to be aware of when considering the mining of information from this data and the use of this data to stay in contact with your customers?

Perhaps the first aha moment was when you recognized that a data set containing your customers’ Personally Identifiable Information (PII) was about to be put to marketing use.  Instead, now you consider the absolute requirement of taking positive measures to protect this freshly cleaned and organized information before putting it into use. 

Step 1: Consider the need for encryption of data that is either at rest and in transit.  There are best in class, current standards for encryption in each of these cases with which your IT team ought to be intimately familiar.  This means you are now ensuring that, should an attack be made on your data center, whether your data center is on premise or in the cloud, you will have made it as difficult as possible for the attacker to actually see your data even if they have successfully hacked your infrastructure.  At the data level, regulators agree that state of the art encryption for all PII is considered to be your primary defense.  This is true whether you are considering state by state laws in the USA or if you are considering GDPR.  

Also, now that you have a clean data set, organized, trimmed and encrypted, you will want to make a practice of establishing an aging program for all PII.  If your classification is as a data controller, you should instruct your data processor how on long to hold PII data and if you are a data controller/processor or a data processor, you should have your own rules for purging PII from your system.  The act of purging PII can be accomplished through a number of mechanisms.  Data that is more than your defined number of months or years old can simply be deleted from your database to accomplish the purge.  Data can also be anonymized or pseudonymized, which is the act of replacing PII with meaningless, generic PII such that there is nothing to tie the data in the database formerly associated with PII to an actual person.

Step 2:  Next on the queue are your decisions for how marketing data will be viewed in your system.  The days of database forms with an export function are behind us.  While we always point to the dark side of the web when considering data breaches, perhaps the less talked about but more insidious issue is the simple scraping of information from a system into a file format that can then be easily sold or otherwise misused.  There are a couple main reasons for this:

  1. A well-meaning employee with an easily guessed password has made your database an easy target for data mining by a not so well-meaning hacker.
  2. An employee gone rogue who is preparing his or her departure has today become perhaps the more likely source of data leakage.

Either way, the PII data that your customers are trusting you to hold has now entered the realm of information for sale on the dark web and now you are left to respond and recover rather than prepare and protect. 

What to do then with the viewing of data?  How do we make the default state of the data in use safe for everyone to use every day?  First consideration is whether it is essential that you know the person who perhaps fits a demographic you are looking to match or if you simply need to know the people, without any need to expose identity, who fit this certain demographic.  This is true, even to the extent of sending a message, email or exposing a targeted offer to them on their phone, all of this can be done without ever exposing the PII of the person you would like to target with your marketing.  Unless there is a compelling case for the former, your ability to be satisfied with the latter is most helpful for your security needs. 

So how do you make the default state of the data to be used safe for everyone, every day, most especially the Service Center personnel?  Several years ago, the idea of tokenization became commonplace among companies working with credit card accounts when they did not want to be responsible for holding the actual credit card Personal Account Number (PAN) information.  This concept has now migrated to the realm of identity management services where products such as Azure AD, Centrify and Okta, to name a few, fundamentally tokenize then vault identity information.  The purpose of these services is to store limited amounts of PII, in particular, passwords for the purpose of the authentication of individuals.  These identity management services then share a token with the contracted company to service their authentication needs. 

While this concept works well with Identity and credit card PAN data, it can also be extended to the PII encrypted and stored in your system.  A meaningless string, the token, connected with all of the day-to-day information such transaction history and even some ‘almost PII,’ like a zip code or a birthday, can be shared alongside the token.  What you will not see are items like email addresses, first and last names, or other PII. However, what you can see would be the actual transaction history of a person for purposes of understanding purchase trends and other buying history.  If the requirement is to specifically target an individual, this can still be accomplished without exposing an email address from your encrypted PII.  The methodology is beyond the scope of the present discussion, but trust this can be accomplished relatively easily once the required strategy is understood. 

From a Customer Service perspective, tokenization and masking email addresses will protect your Customer Service Agents from having to see PII.  A bit of creativity will be needed, and scripting required for service agents to identify transactions for customers who are calling about specific transactions, but that has been solved many times over, particularly in the banking industry where there is similar sensitivity to protecting PII but still the need to work at a detail level with customer transactions. 

Step 3:  Now that you have managed to keep a veil over your well protected customer identities, created a strategy to extract demographics without PII and possibly even directly contact individuals without exposing email addresses, what is left to be done? Maintain relevance.  Your most current data is your best data – so from that perspective, all data may be created equally, but not all data is valued equally.  Newer is better.  What is most valuable is not knowing what your customer did in the past, but using data and other intelligence to predict and suggest what your customer will do in the future.  The best way to predict the future is to look at my recent past, add in a little artificial intelligence (AI), and project what the future might look like tomorrow (coffee), next week (gasoline), or next month (windshield wipers).   

As you continue down the GDPR path with a need to fulfill your marketing purpose, there are a couple more things that you must ensure are in place.  You must provide your customers the opportunity to opt out, remove consent, or suspend their relationship with you.  May not be the news we want to hear, but if we are concerned about compliance and protecting the privacy of individuals, it is essential that we provide these mechanisms for opting out, removing consent or suspending their relationship.  There may be perfectly legitimate reasons for opting out today but then, the ability to opt back in next week or next month may be desirable.  So, if your customer opts out, and they do not specifically ask to have their account deleted, give them the opportunity to opt back in.  You must also provide the opportunity or the ability for your customer to delete their account.  This is a true deletion in which the PII is removed from the system and transaction history is no longer connected to the person.  Even if the same person should sign up with all the same credentials, the connection to their data history is gone.  And though this may not be what anyone really wants, merchant or consumer, it’s what the regulation requires.  Finally, your program, its transparency, the rights it provides your customers and the consequences associated with every action they take, must be clearly spelled out in your Privacy Policy.   

As you progress with GDPR, your business can, and most probably will, become more efficient with higher quality information and possibly even at a lower cost to operate, if your company takes a proactive and thoughtful approach to data management. 

Add Comment