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
Diversity: It's About Inclusion
Kelly Jackson Higgins, Executive Editor at Dark Reading,  4/25/2018
Threat Intel: Finding Balance in an Overcrowded Market
Kelly Sheridan, Staff Editor, Dark Reading,  4/23/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How to Cope with the IT Security Skills Shortage
Most enterprises don't have all the in-house skills they need to meet the rising threat from online attackers. Here are some tips on ways to beat the shortage.
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-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.