GDPR: The Controller Vs. Processor Hot Potato Could Hurt Consumers

“Data-Driven Thinking” is written by members of the media community and contains fresh ideas on the digital revolution in media.

Today’s column is written by Travis Ruff, chief information security officer at Amperity.

With much anticipation, the General Data Protection Regulation (GDPR) is here.

As it takes effect there is still a debate about which organizations are controllers vs. processors, what type of companies must get consent and when, and how consent risk should be managed.

The crux of the debate is the definition of controller vs. processor. GDPR defines the controller as the entity that determines how personal data is processed. It defines the processor as the provider of processing services, as dictated by the controller.

These definitions seem straightforward and avoid the pitfalls that generally complicate this debate, including who has the direct interaction with individuals and who stores and maintains the data.

I will not attempt to clarify or narrow these definitions as they work on both a macro and a micro level. What is fascinating about this debate is that it misses the most important point: This is less about a strict definition of controller vs. processor and more about where responsibilities lie in the relationship between the two.

If, as a data controller, I ignore due diligence and contractual requirements and enter into agreements or share data with third parties that I cannot trust to meet the limits of GDPR’s required processing and data protection, I should rethink and likely terminate those relationships.

If, as a processor, I knowingly or unknowingly perform processing activities beyond the scope of my agreements, I am ignoring both the letter and spirit of the law. The agreement between controller and processor must clearly define all of these requirements, including when a controller wishes to transfer risk to a processor.

As evidenced by Google, controllers are attempting to transfer to processors the key risk of consent. The benefits of transferring consent seem clear: The controller assumes no responsibility in the handling of data because their third party must gain consent. If a third party fails to get consent, it would be found at fault and answer to the data protection authorities.

I struggle to believe that this is actually how any reasonable case would play out.

The controller directs how data is collected from individuals. If it relies on a third party to get consent from individuals but fails to do so, there is no get-out-of-jail-free card to play; both will be held responsible because there is no effective way to transfer 100% of the risk.

Should transferring consent responsibilities and risk to a third party even be considered? In even the simplest ecommerce, retail, hospitality and travel environments, individuals’ data may be shared with multiple third parties.

In this scenario, is pushing consent activities to each third party desirable? Will five, 10 or more third parties reach out to each customer to independently gain consent? What is the benefit, especially when data-sharing obligations are factored in?

From the perspective of a controller, the benefits of gaining consent for all processing activities in a single, unified location gives it direct oversight of consent, regardless of whether the data processing is performed by the controller or a processor.

From the perspective of a processor, the complexity of obtaining consent grows exponentially. The processor must have sufficient personal information in order to get consent from an individual for processing. This involves a data transfer from the controller to the processor. Must the controller get individuals’ consent before transferring data to the third-party processor? A chicken-and-egg scenario may play out.

A processor will also likely hold an individual’s personal data from multiple controllers. If consent is managed at the processor level, is consent granted universally by an individual or is consent granted for only a specific controller-to-processor relationship, and thus a processor must reach out multiple times?

A goal of GDPR is to give individuals more control over the use and sharing of their data. But if forcing individuals to manage consent with 200 processors and 20 controllers instead of only the 20 controllers driving data activities, I would argue that the goal will not be achieved. In fact, individuals’ effective control of their data use and sharing may be diminished from where it was with existing laws, including the Data Protection Directive.

Follow Amperity (@amperity) and AdExchanger (@adexchanger) on Twitter.

This post was syndicated from Ad Exchanger.