2

I'm wondering if someone can shed some light on this for me please and help distinguish the differences between what I need to mention In my privacy policy for a data controller and data processor.

I'm a Web Developer and so the reason for this is that I'm classed as both a data controller on my own website but yet I deal with data from clients therefore I am a data processor.

I have a privacy policy on my website which explains what data is being processed on my website, why, what and where ect. But nowhere does it mention anything to do with what I collect from my clients internally via email systems ect.

A client has asked for my privacy policy but the only one I have is based around my own personal website. Do I need to create another policy for my clients and base this around what I process for them?

Improve this question

2 Answers 2

Reset to default
2

First, the relationship between the controller and processor is described in great details in GDPR Chapter 4. It is recommended reading.

TL;DR: The controller is the one who calls the shots (i.e. what personal data to process, what means to use to process it, the purpose of processing, and the legal basis for processing). This is usually the owner of information system. The processor is the the entity that actually do the processing. If their relationship is not described in a legal document known as a DPA, both the controller and processor risks fines.

A client has asked for my privacy policy but the only one I have is based around my own personal website. Do I need to create another policy for my clients and base this around what I process for them?

I think you have the right idea about you having different roles in different contexts, and also that you work for clients, you are processor. This also means that the client is the controller.

A "privacy policy"-type document is not sufficient to regulate the relationship between the controller and processor.

How to regulate this relationship is described in GDPR Article 28 (3). Its start out by saying:

Processing by a processor shall be governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller and that sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller.

It then goes on to describe what stipulations the contract must contain.

This contract is usually called a DPA. The initials may stand for "Data Processing Agreement" or "Data Protection Addendum".

Basically, if you personal process data on behalf of clients, you need to have this place. Both the controller and processor will be fined by the supervisory authority finds out that you are processing personal data without having such a contract in place.

Improve this answer
2
  • "A 'privacy policy'-type document is not sufficient to regulate the relationship between the controller and processor." - even after reading both answers several times, this appears to be the opposite of what you wrote in another answer. (Either that, or the asker of the other question who responded to your answer "all DPAs will just be the usual privacy policies, improved to be compliant with GDPR" totally misunderstood your answer.)
    – O. R. Mapper
    Jun 21, 2018 at 12:32
  • An example DPA is the one google uses for its Google Cloud Platform.
    – wimh
    Sep 19, 2018 at 18:30
2

The way I understand GDPR (as of now), you (the web developer) are a data processor if you deal with personal data on behalf of your clients.

So suppose you build a very simple website for a client, and this website is just a bunch of static pages with no contact forms, no scripts for analytics, etc. You install it on their hosting space, and that's it. You have not touched any personal data on behalf of your client, you know nothing about what data they collect, etc. So in this case you are not a processor. You just collect your client's name, their phone number, and all the data that is needed to contact him, do your job, getting paid, etc. What you do with this data should be explained in your privacy policy.

Now suppose you build a website, for which you also provide a hosting plan and maintenance. The site has a contact form, and the contact requests are saved in a database. Your client becomes a data controller, because they collect personal data with the contact form on their website, and so your client should have a privacy policy for this. You do maintenance, so you probably make backups of the website and store it somewhere locally. The backups contain all the personal data of the requests sent via the contact form on your client's website, so you end up processing data on your client's behalf, and you are a processor. Also, since you use WhateverHosting (made up name) as the hosting provider for your clients, WhateverHosting is actually going to be your sub-processor. For all this to be legal according to the GDPR you need a DPA contract between you and your client.

The way I see it a DPA is just going to be a GDPR-compliant privacy policy that also follows article 28 of the GDPR. In practice, for example, article 28 implies you must include a list of your sub-processors, and then you can't add/remove/change sub-processors without your client's consent.

Improve this answer

You must log in to answer this question.

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