Control and security over customer data – especially PII (Personally identifiable information) is a hot-button issue amongst Ad Tech and MarTech companies due to the wide array of regulations and stiff penalties for non-compliance.
Any company that touches customer data is labelled either as a data processor or data controller. On the surface, the distinction seems one of semantics, but in reality, the implications of being one or the other carries serious weight and potential consequences.
Here are some definitions for context:
Data Subject: User of an application and/or website visitor (i.e. customer/prospect).
Data Controller: Company responsible for adequate treatment of the data. They determine the purposes for which and the manner in which any personal data are, or are to be processed (e.g. a company that uses a marketing automation or ad retargeting tool).
Data Processors: Intermediaries between Data Subjects and Data Controllers (e.g. tool or service providers, specialized analytics consultants, or digital and media agencies that process data on behalf of the Data Controller.
Typically, marketing cloud vendors and providers of stand alone Ad Tech and MarTech SaaS solutions that store data including PII are considered data processors. This is because they don’t use the data for any purpose other than that mandated by the data controller (their customer). They simply provide software for the data controller to use at its own discretion.
There are some situations where a B2B Ad Tech or MarTech company could be both a data controller and processor. For example, an email marketing software vendor used by brands to market to consumers. This company is a data processor because they process end-consumer data for their brand customers. If this email marketing software vendor were to also provide market research services to their brand customers using this same data, it would then also be a data controller.
While data can be as valuable as physical currency for marketers and having control over this data has many revenue-driving benefits – my take is that it’s more favorable and safe for Ad Tech and MarTech companies to hold as few data controller roles as possible and stay vigilant to not use collected data in any way that crosses the line into Data Controller territory. This is especially true for companies located in, or that have customers in the European Union, due to the recent EU data protection overhaul. This is for a couple of reasons.
First, data processors have fewer regulatory requirements than data controllers. These responsibilities concern the necessity to keep personal data secure from unauthorized access, disclosure, destruction or accidental loss.
Second, there are fewer legal liability risks attached to being categorized as a data processor vs. a data controller. Under the new EU General Data Protection Regulation, “Data controllers could face more severe regulatory fines than data processors for failing to keep personal data appropriately secure.” Additionally, “If data processors are at fault for data breaches then it is the data controller who contracted with them who is on the hook for any non-compliance with data protection laws, although the data processor could be liable to the data controller under their contract.”
This isn’t to say that data processors are free of all responsibility. Ad Tech and MarTech companies that are considered data processors should have a data processing agreement that they can sign with customers and should also assign a data protection officer to ensure they comply with all data processor obligations – regardless of what the letter of the law requires.
The regulatory framework along with definitions of data, PII, processing and controlling will likely continue to evolve. Most importantly, although there are often competing interests, risks and benefits, data processors and controllers should work together toward the same goal of ensuring all customer data is secure and used properly by all parties at all times.
This article was originally published on AdExchanger on May 24, 2016.
Questions, queries, comments?
Join the conversation about this post on Facebook, Twitter, and LinkedIn.
