A web freelancer in GDPR land: The Pool of Tears
Caution! This article was published over a year ago, and hasn't been updated since. Situation, software and support of the topic below could have changed in the meantime.
It's been a long time since my previous GDPR article, and luckily in the last months many informative blog posts appeared - and some of them are even aiming for small business and web developers (you can find a small link collection at the end this text).
Disclaimer: All information in this article is no legal advice but how I understand the General Data Protection Regulation and what I think it'll mean to my business. Feel maybe inspired, but not advised legally 🤗
After reading that old article of mine again it's quite interesting which questions I asked myself and what I reflected upon back then. It appears - that is what the GDPR wants you to do: Reflecting on your data usage, what pieces of data you collect and where you store it.
"Stocktaking II - The Paperwork Strikes Back"
There's a paragraph in the first article called "Stocktaking", and it turns out to be quite crucial:
- I tried to summarize where personal data of customers is normally stored and in what context it is used.
- I mentioned that I use a web hoster for an Open Exchange account, with mails, contacts and calendar features. All of them potentially and most certainly containing personal data of my customers. Also, I use a cloud storage provider, SpiderOak back than, Tresorit now.
- I wondered whether I get "points on the GDPR security scoreboard" for my systems being backed up, encrypted by Apple's FileVault and that my cloud storage providers are encrypted as well.
At the end of this bit I asked "How and to what extent do I have to change my workflow and processes here?" and it seems - not really, but I have some paperwork to do and have to put that stocktaking into a specific document:
- GPDR Article 30 (1) demands such a reflection or "data stocktaking", calling it " A record of processing activities". At first, you have to name and supply the contact details of the data controller (in solo businesses, this is the freelancer), then the purposes of processing, what data is stored precisely, and if the data is shared with another country.
- With my web hosters, cloud storage providers and all other third parties that get access to the personal data of my customers (called data processors), I have to sign a contract called Data Processing Agreement (that's GPDR Article 30 (2)). It's good advice to affix all Data Processing Agreements to your record of processing activities and to cross-reference them rather too detailed than too little.
- I only get my "points on the scoreboard" when I add these "general description of the technical and organisational security measures" to the record of processing activities
All this serves two purposes:
- I am more aware of data processing, sharing, and protection
- I can hand out said document to data protection authorities and they can judge upon this how good my data protection security was (in the worst case).
Consent
In the following paragraph about consent, I wondered how to deal with a typical project inquiry. Like many others, I did not understand the "management of consent" at first and started thinking, that you need a written consent for every breath you take.
But, luckily, the situation is much more complex and the lawfulness of data processing is not only based on consent but also other factors (GDPR Article 6 a - f) like:
- Article 6 b: Contract arrangements, "in order to take steps at the request of the data subject prior to entering into a contract", and that is more or less the situation I described in the last GDPR blog post
- Article 6 c: "Processing is necessary for compliance with a legal obligation" (I can see a group of Germans nodding in the distance)
- Article 6 d: "Processing is necessary in order to protect the vital interests of the data subject". Since I'm a web developer and not a paramedic, I assume I won't be confronted with this at all
- Article 6 e: "processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority". See 6 d, no application for my business
- And now the big one: Article 6 f states "Processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child." Legitimate interest, I was told by wise men and women who know the law, can be for example Website analytics like Matomo (Piwik) or Google Analytics. These are tools that serve my interests as a freelancer (for example they tells me about the devices of my visitors and help me improve my websites), simultaneously they don't hurt other people's fundamental rights (at least when you anonymize their IP addresses: Google Analytics, Matomo (Piwik).
Well, that's a lot at first. But I assume that you can base most of your business communication on 6 b and 6 f. Things are different with marketing tools like newsletters, though. Here, 6 a is applicable ("the data subject has given consent to the processing of his or her personal data for one or more specific purposes").
All in all and more than 6 months after my first blog post on the topic I feel more familiar with the GDPR, its intentions but also it flaws. I also got the feeling that, no matter how deep you dive into that law (be it because of fear or sincere interest) nothing but court rulings will give us clarity on how things will work in detail. That's unfortunate, but it can't be helped.
And Alice also left Wonderland only after an absurd court hearing.