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.
Robin Kurzer on May 23, 2018 at 10:51 am | Reading time: 7 minutes
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).As companies scramble to become compliant with the May 25 deadline for enforcement of the General Data Protection Regulation (
The letter of the lawGDPR’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-floppingDigital 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. Podnar continued:
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.