Data controllers and data processors: The difference and why it matters in GDPR
As the May 25 deadline for compliance with the European legislation looms, it's increasingly important to understand the difference between the two key roles.
As companies scramble to become compliant with the May 25 deadline for enforcement of the General Data Protection Regulation (GDPR), the distinction between data controllers and data processors — and their responsibilities — is coming into clearer focus.
To become compliant, companies are hiring data privacy officers, auditing processes and in some cases, pulling out of Europe altogether. And, as your personal email box can attest, they’re updating their terms and conditions, their privacy policies and gathering consent.
But as we inch closer to the deadline, companies may be using these designations to dictate roles and responsibilities that are unintended by GDPR. (I’m looking at you, Google).
The letter of the law
GDPR’s Article 4 defines data controllers and data processors (warning: legalese; bolding added).
(Article 4, section 7) ‘Controller’ means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law;
(Article 4, section 8) ‘processor’ means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller.
Sounds simple, right? The controller is “in control” of the data, and processors, well, process it.
GDPR puts most of the onus of compliance on the controller — requiring them to gather and manage consent and respond in a timely manner to data subject requests. The controller is responsible for determining the “why and how” of the way data is managed. Processors process data on behalf of the controller.
The EU provides a succinct example on its site:
A brewery has many employees. It signs a contract with a payroll company to pay the wages. The brewery tells the payroll company when the wages should be paid, when an employee leaves or has a pay rise, and provides all other details for the salary slip and payment. The payroll company provides the IT system and stores the employees’ data. The brewery is the data controller and the payroll company is the data processor.
It’s important to note that even though processors are not required to gather consent, they are held equally responsible for any penalties or claims for noncompliance.
So, who is in charge of collecting consent?
Travis Ruff, chief information security officer at customer data platform (CDP) Amperity, says it’s important to understand the differences between the roles.
“As GDPR takes effect, there is a significant debate regarding who is a controller, who is a processor, where the need to gain consent for processing lies and under what circumstances processors can (and should) attempt to transfer that responsibility and its associated risk to their third parties,” Ruff told me.
Ruff expanded on that:
The more important point, in my opinion, is the relationship between the two. If, as a controller, you enter into business arrangements with third parties, where you do not feel you can accurately describe the processing being performed on your customers’ data and gain consent from them to do so, those relationships should be rethought. If, as a processor, you are performing processing beyond that which is described in the contract between you and the controller, you are breaking both the letter and the spirit of the law. Any data transfer must only occur when both the controller and the processor have a clear definition of the relationship.
Companies are flip-flopping
Digital Policy Consultant Kristina Podnar, who also consults for us at Third Door Media, says companies that argue the definitions are working against the spirit of GDPR.
“We are starting to see companies flip-flop on whether they are a controller or a processor based on convenience, which is neither the goal of GDPR nor the right market approach,” Podnar told me. “Google is one of those that signaled early on that it would be a controller of data but is now looking to share the accountability with its publishers. It is disappointing that the ICO [Information Commissioner’s Office] and others are not providing clearer guidance (particularly in relation to commoditized SaaS/PaaS/IaaS cloud services) because it would significantly help all of us come down on the right side of this debate.”
The ICO is an independent UK entity that exists to uphold information rights in the public interest.
What I do find fascinating is that organizations are vying to have themselves categorized as a processor (over a controller) given that under the GDPR, processors are more exposed than previously under DPAs (data protection authorities). Specifically, I am thinking here of carrying out controllers’ instructions on data processing (Article 29), notification of data incidences or breaches to the controller without undue delay (Article 33) and supporting controllers in carrying out their DPIAs (Data Protection Impact Assessments) (Article 35, which doesn’t mandate the processors to support, but likely will be seen as required by controllers). I would expect them to be eager to ensure obligations are well defined in processing agreements to protect themselves and to work together (rather closely!) with the controllers to ensure GDPR compliance.
Some disagreements are bound to arise
As Podnar alluded to above, Google announced this spring that it would consider publishers using its ad serving platform, DoubleClick for Publishers (DFP), as “co-controllers” that must collect consent on its behalf. Publisher groups have pushed back, saying that Google is sloughing off the burdens of compliance, not gaining consent for all the ways it might use the data it collects on publishers’ visitors and entangling them in that liability.
GDPR itself recognizes that two entities can be co-controllers or joint controllers if they both make high-level decisions around the use of data. In order to be considered co-controllers, they must enter into an agreement with each other and both collect consent from data subjects. Google says its approach is merely an update to consent terms it already has with publishers and has told publishers using DFP that they’ll need to agree to the new co-controller terms in order to continue using its ad server.
When it comes to enforcement, Adrian Newby, chief technical officer at experience management platform Crownpeak, expects that regulators will be most interested in public-facing actions, including privacy notices, consent practices and information about how subjects may exercise their data protection rights.
“The regulators are likely to strike here first, as clear communication with audiences about how their data might be used will be the easiest for regulators to assess, since it requires no access to internal records or practices,” Newby said. “All they have to do is visit a website and check the notice to understand whether a company is in line with the new regulation. Marketers should therefore make this their number one priority.”
Note to companies: Figure it out
Chris Sperandio, product lead in privacy and compliance at CDP Segment, says that at the end of the day, it’s up to all parties to research their roles and responsibilities.
“Every company needs to accurately assess whether they’re a controller or processor (or both) in order to understand their obligations under the GDPR and ensure they are appropriately compliant,” Sperandio said.
Opinions expressed in this article are those of the guest author and not necessarily MarTech Today. Staff authors are listed here.