Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk //

Compliance

4/16/2018
10:30 AM
Roger Kjensrud
Roger Kjensrud
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

How GDPR Forces Marketers to Rethink Data & Security

The European regulation is making marketing technology companies re-examine their security, and that's a good thing.

Multinational marketers are closing in on the May 25 date by which they must comply with the EU's General Data Protection Regulation (GDPR). As the date looms, marketers are tying up loose ends to ensure they meet the deadline. However, most view the GDPR — a regulation that governs the way in which consumer data is collected as well as how it's used and stored — as a major challenge and remain uncertain how much their data policies will change. Scrambling to meet the deadline, companies are in various states of preparedness.

The GDPR will offer consumers in the EU more control over their personal data and outlines requirements for data collection, storage, and use. It will also impose potentially steep fines on companies with poor data-handling practices and those that experience data breaches in which they are found at fault. While the regulations are limited to the personal data of consumers living in the EU, they apply to any company handling, transmitting, or storing that data, whether it has a physical location in the EU or not. This includes marketing technology (martech) companies that process data for and receive personal data from their customers.

What Is Personal Data?
Many martech companies don't collect personally identifiable information, which means the data does not directly identify an individual. Generally, the consumer is assigned a cookie with some random, unique value to tie certain website events together. With the GDPR, the notion of personal data is extended to include online identifiers such as IP addresses and cookie values.

These identifiers do not identify an individual, but if you combine these with additional information, you can identify a person. So it becomes critical that we understand the nature of the additional information to process it in a secure and compliant manner. Securing data may include what the GDPR refers to this as pseudonymization, where the data is processed so that it cannot be attributed to a specific person. Hashing and encryption are examples of pseudonymization.

What About Personal Data You Didn't Ask For?
Martech companies need to think through and map out how all their data is collected and what is sent to them from their partners and customers. I recommend answering the following questions:

  1. What data are you collecting, and what data are your customers sending you?
  2. As a data processor, do you really need the data customers are sending you? If you do not really need it, do not accept the data. Period.

Furthermore, I recommend that customers perform pseudonymization on any personal data before the data processor collects it. The less personal data martech companies handle, the better.

The Right to Forget
Within the martech sphere, companies will either obtain consent or have a legitimate interest for processing personal data and need to comply with requirements such as data portability, also referred to as the "right to forget." The right to forget revolves around the concept that consumers have a right to demand the deletion of their personal data from companies that have that data, even if they previously have given permission for its collection.

Brands collect and store consumers' first-party data as a matter of course — that is, any data consumers offer when they buy something or conduct transactions online. If you're shopping on Amazon, banking with Wells Fargo, buying tickets with Ticketmaster, or booking rides on Uber, you have offered your data. Besides the brands, the requirements apply to their third-party vendors, including their data processors. Martech companies may also have access to all or part of this data, or process some or all of it for the brands, including pseudonymized personal data.

The right to forget can be technically challenging to solve for, especially in martech, where millions of records are processed daily.

If you apply pseudonymization to personal data, it becomes very important to store this data in one place (database normalization). Any reference to the personal data will come via a foreign key or token. When martech companies receive a request to delete personal data, it is a matter of updating the record with some value that does not mean anything (e.g., "unknown").

The idea here is that companies do not physically delete everything associated with the customer but, rather, change the pseudonymized value and leave everything else in place because retailers have legitimate business interests in the data. The net effect is that the retailer will have its metrics available — for example, the number of sales for a given marketing channel. If the pseudonymized data is spread to multiple data stores and systems, it becomes very hard to control and satisfy the right-to-forget principle.

The GDPR Effect
With the GDPR in place, the martech sector must look at privacy issues as part of the requirements for building its systems — these issues cannot be afterthoughts. As software is built, the privacy piece must be part of it from the start — a "privacy by design" approach. The sector also needs to start treating IP addresses, device identifiers, and other identifiers as personal data. Just because these don't identify a person by themselves, the combination with additional information could.

It is also important that martech companies train their teams and make it clear to customers that they do not want any of their customers' personal data that they do not need to provide services to the customer. On the training front, teams need to make this a requirement at the beginning of the process when they integrate and onboard customers. If, however, the customer does need to send personal data, the data must be pseudonymized.

Overall, the GDPR forces companies in the martech sector to rethink their systems and how they handle data. We want to be transparent and build systems that protect consumers' data according to what they consented to. In an era when security breaches are pervasive, the GDPR is something we need. 

Related Content:

 

Interop ITX 2018

Join Dark Reading LIVE for two cybersecurity summits at Interop ITX. Learn from the industry's most knowledgeable IT security experts. Check out the Interop ITX 2018 agenda here.

Roger Kjensrud is Co-Founder and Chief Technology Officer at Impact, where he's tasked with architecting and enhancing the company's natively integrated marketing technology platform for addressing fraud detection and prevention; marketing intelligence; and managing and ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Mobile Banking Malware Up 50% in First Half of 2019
Kelly Sheridan, Staff Editor, Dark Reading,  1/17/2020
7 Tips for Infosec Pros Considering A Lateral Career Move
Kelly Sheridan, Staff Editor, Dark Reading,  1/21/2020
For Mismanaged SOCs, The Price Is Not Right
Kelly Sheridan, Staff Editor, Dark Reading,  1/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment:   It's a PEN test of our cloud security.
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2007-6758
PUBLISHED: 2020-01-23
Server-side request forgery (SSRF) vulnerability in feed-proxy.php in extjs 5.0.0.
CVE-2010-3295
PUBLISHED: 2020-01-23
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.
CVE-2019-3691
PUBLISHED: 2020-01-23
A Symbolic Link (Symlink) Following vulnerability in the packaging of munge in SUSE SUSE Linux Enterprise Server 15; openSUSE Factory allowed local attackers to escalate privileges from user munge to root. This issue affects: SUSE SUSE Linux Enterprise Server 15 munge versions prior to 0.5.13-4.3.1....
CVE-2020-6843
PUBLISHED: 2020-01-23
Zoho ManageEngine ServiceDesk Plus 11.0 Build 11007 allows XSS.
CVE-2020-7931
PUBLISHED: 2020-01-23
In JFrog Artifactory 5.x and 6.x, insecure FreeMarker template processing leads to remote code execution, e.g., by modifying a .ssh/authorized_keys file. Patches are available for various versions between 5.11.8 and 6.16.0. The issue exists because use of the DefaultObjectWrapper class makes certain...