1

I thought the processor was just someone who processes all personal data on behalf of the controller, basically a simple substitute for some matters. But from what I read online it seems that a processor is anyone that deals with any personal data, even partial data, as part of a service provided to the controller. So it sounds like everyone that deal with personal data as part of their job is a processor, except the end users of the service. But since processors must be bound by a specific contract to deal with the needs of the controller (article 28 says "processes the personal data only on documented instructions from the controller), then I'm afraid it will soon become a huge mess with a gazillion contracts to sign.

For example, John Doe has a website with a contact form. The contact form collects data, and the end user should accept the privacy policy written by John Doe. John Doe is the controller. However, John Doe's website is managed by a web agency! Is this web agency a processor? I guess so. So John doe needs to write a contract and have the web agency sign it. If every website owner does this, the web agency will have to read and sign hundreds of contracts. But the web agency hosts the sites on a web hosting provider, which in turn becomes another processor! And they use Gmail, provided by Google, which in turn is yet another processor that will have to sign millions of contracts. And so on, in an potentially endless cycle, just thinking that if you read your work email from your iPhone you might have to send a contract to Apple too.

It seems a huge mess to me, but I'm not sure I get it right. It looks like everyone is a processor except the end user, but the confusing thing is that the the law seems to say that it's the controller the one who decides the contractual terms, so it's not just a matter of accepting a privacy policy like we have been doing so far. So far, Google has provided a service to you, and you agreed to their privacy policy. Now it seems it's you, if you are a controller or a processor, that have to come up with a contract and Google has to accept it (if they want to). Like it's the other way around compared to the usual privacy policies. Of course this will probably never happen, and Google will probably come up with predefined contracts that both parties can agree on, but at that point what difference would there be between the contract required by GDPR and the usual privacy policies everyone has been using so far?

I hope the question is clear enough. I'm basically very confused about the actual role and duties of processors in real-world scenarios.

5
  • 1
    You’re right: “it will soon be a huge mess with a gazillion contracts to sign”
    – Dale M
    Commented May 30, 2018 at 21:23
  • John Doe and the web agency already have a contract. What provision of the GDPR would make it necessary for them to sign a new one?
    – phoog
    Commented May 31, 2018 at 15:25
  • @phoog, you are right, now I think I understand more. As long as the two parties agree and the contract is compliant with GDPR, it doesn't matter which party writes the contract. So the usual privacy policy (improved for GDPR) will do.
    – reed
    Commented May 31, 2018 at 15:56
  • @phoog: "John Doe and the web agency already have a contract." - at least some German webhosters do not seem to trust in that interpretation. For instance, this FAQ says: "Isn't a webhosting contract sufficient? No, absolutely not in the situation of processing on behalf. The law requires a separate contract for processing on behalf between the webhoster as a contractor and the customer as the contracting entity according to Art. 28 DSGVO (GDPR)." And given that it's an extra effort for this webhoster, I'm not sure why they should make it up. Commented Jun 1, 2018 at 21:01
  • You may find answers regarding the situation with Gmail (or other e-mail providers) in my recent thus-related question: According to GDPR, do I need a contract for processing on behalf with my e-mail provider? Commented Jun 1, 2018 at 21:10

1 Answer 1

3

You premise is correct. The processor is someone that processes data on your behalf, and since the GDPR definition of processing is extremely broad, that is about every third party subcontractor that you use for data processing, including various cloud providers.

I'm afraid it will soon become a huge mess with a gazillion contracts to sign.

I disagree. Yes, the GDPR says that a contract between the controller and processor must exist, but Article 28 of the GDPR does not say anything about how the controller shall document these instructions. Basically, in cases like the one you describe where John Doe relies on a web agency for having a contact form on the web, there will be a standardized (by the web agency) service agreement between the John Doe (controller) and the web agency (processor). There is nothing stopping the parties from agreeing that this service agreement that John Doe accepted as part of the onboarding procedure is also the DPA as required by the GDPR.

Putting something like the following in the service agreement would do it:

The parties agree that this Service Agreement between You (controller) and Us (processor) set out Your complete and final instructions to Us in relation to the processing of Personal Data and that processing outside the scope of these instructions (if any) shall require prior written agreement between You and Us. You also agree that We may engage Sub-processors to process Personal Data on Your behalf. The Sub-processors currently engaged by Us and authorized by You are listed in Annex A.

I think we will se a lot of amendments in service contracts as the GDPR gets better understood, but I don't really see a flood of DPAs in addition to these amended service contracts.

7
  • Yeah, so the way I see it in the end all DPAs will just be the usual privacy policies, improved to be compliant with GDPR.
    – reed
    Commented May 31, 2018 at 15:52
  • @reed: I have sent inquiries to various German webhosters. They all seemed to be convinced that integrating the DPAs in the privacy policies is not feasible, or not even lawful. Reasons stated included individually different requirements of what needs to be agreed upon in each DPA for each customer, and the fact that the DPA has to be something the customer provides to the webhoster for signing, not the other way round. I'm not claiming I understood that reasoning, but given that these webhosters have in-house legal departments and spend quite some additional effort for processing all ... Commented Jun 17, 2018 at 20:54
  • ... those individual DPAs without charging any extra money for them (well, not directly anyway), it seems a bit unlikely to me that it could actually be as easy as rewording the webhoster's network-wide privacy policy. Commented Jun 17, 2018 at 20:56
  • @reed: As another interesting data point, there is this other answer that concludes: "A 'privacy policy'-type document is not sufficient to regulate the relationship between the controller and processor." Commented Jun 21, 2018 at 12:34
  • @O.R.Mapper, the point is: what's the exact difference between a so-called privacy policy and a so-called DPA? My opinion is that a DPA is just going to be a GDPR-compliant privacy policy that includes the points mentioned in article 28 of the GDPR (article about processors). So it can be the same for all the clients, for example. We can't expect Google to sign a customized DPA for each of their clients. Clients can't tell Google what to do. Instead, Google will have to tell the clients that they will act according to the GDPR including article 28 (so they will list their sub-processors, etc).
    – reed
    Commented Jun 21, 2018 at 16:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .