GDPR liability for Web Designer I am a web designer that works with a range of clients on a project basis. I complete a project and then offer my services at any hourly rate for any other work required in the future. Do I have a legal responsibility to ensure any projects are GDPR compliant which are: finished before 25th May 2018? finished after the 25th May 2018?
If you are purely a designer (and not contracted for the daily operation of the site), the answer is "no". GDPR Article 4 defines the "roles" responsible for complying with GDPR, and there are two: Controller and Processor. The Controller is the one who calls the shots. In particular: Decides what personal data to process. This is usually the owner of the web site. The Processor is the one that actually does the processing. This is usually some company providing some sort of data processing service (e.g. SaaS, PaaS, etc.). The relationship between the Processor and the Controller must be contractual. The contract is called a DPA (Data Protection Agreement or Data Processing Addendum). As a designer, you don't fit into any of these roles. If your contract with the client is silent on liability for GDPR compliance, then you have no liability. This goes for projects completed both before and after the May 25 deadline. Of course, if there are GDPR clauses in your contract, then you must fulfil them just as have to fulfil any other contractual obligation. But unlike the controller and the processor, there are no automatic legal liability for a designer or programmer.
The line they'll rely on for GDPR compliance is the first part of that sentence - "If you agree to this during the order process", which suggests that there will be a separate request to opt in to marketing communications at some other time in the process. Check any order documents. There's likely to be a tick box or similar on at least one. If that implies opting out rather than opting in there may be grounds to argue with that under GDPR, but there's nothing in the quoted text that suggests a problem.
The material scope of the GDPR (Article 2) is limited to the processing of personal data (including mere storage) by automated means or as part of a filing system. The question of whether your activity falls within this scope hinges on what you actually do with the data once you take possession of it. You have mentioned saving the contact information of people you have met at conferences, which could refer to simply retaining it for later use, or to the technological process of storing data in a computer. The former, if not done in any structured way (a filing system) would not fall within the scope of the GDPR. The latter, even if poorly executed, such as a photo stored on a business smartphone or a text document thrown onto your workstation's desktop, would always fall within scope as computerised data is processed &quot;by automated means&quot;. When the contact information you receive identifies a specific person, as distinct from just a corporate switchboard number and company name for example, it is personal data. When you get that personal data from the person it identifies (data subject), and you're otherwise in scope, Article 13 is invoked, requiring you to provide a list of information, &quot;at the time when personal data are obtained&quot;, unless &quot;the data subject already has the information.&quot; This is known as the right to be informed. The requirements differ when personal data are not obtained directly from the data subject. I would argue it is unreasonable to be expected to provide the information to the data subject over a cup of coffee or in a quick business card exchange, but if you start entering it into a spreadsheet or your CRM, you need to provide the required information, which may be as simple as a follow-up email thanking them for their time and letting them know you'll keep their contact details on file, along with a link to your organisation's privacy policy, assuming it covers this use, or if not, a specific privacy notice. You will of course be required to comply with other requirements such as the principles of data minimisation and identify a lawful basis, maintain adequate security by implementing technical and organisational measures, hold contracts with any third parties who process personal data on your behalf, and have a process for upholding data subject rights and responding to requests to exercise them - among others - but you should already be doing that for your other processing activities unless exempt. Additional information Edits have been made as clarifications and questions were forthcoming. Email marketing You need to consider the applicable country's implementation of Directive 2002/58/EC as amended (&quot;ePrivacy Directive&quot;). For example, in the UK you could send such messages without consent to contacts at incorporated companies or public sector bodies, but would have required consent for sole traders, private individuals, or partners in an unincorporated partnership. In Ireland, you have an exemption to consent for existing customers who were offered the opportunity to opt out when their email address was collected, but must use the email address for marketing within 12 months. Each EU country will have a different implementation of the Directive. In the Netherlands, Article 17 of the Telecommunications Act implements Directive 2003/58/EC and thus provisions for direct marketing by email. Processing by automated means Processing by automated means refers to processing of personal data in electronic, rather than manual form. All electronic processing is within the material scope of the GDPR, while only manual processing that forms or is intended to form part of a filing system is. Recital 15: The protection of natural persons should apply to the processing of personal data by automated means, as well as to manual processing, if the personal data are contained or are intended to be contained in a filing system. Art. 4(2): ‘processing’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means ICO guidance What is personal data?: The GDPR covers the processing of personal data in two ways: personal data processed wholly or partly by automated means (that is, information in electronic form); and personal data processed in a non-automated manner which forms part of, or is intended to form part of, a ‘filing system’ (that is, manual information in a filing system).
No, it's not legal. The General Data Protection Regulations (GDPR) apply given that you are in the UK (regardless of where the Data Processor is based). The UK GDPR is slightly modified due to Brexit, but the same principles apply. The only plausible legal basis for this actions would be that you consent to it, and you're entitled to withdraw that consent at any time. Some may claim that Article 6.1(b) applies, i.e. that it's necessary to send marketing email in order to fulfil the contract, but GDPR is clear that bundling such consent into a contract for service simply to permit the data processor additional actions isn't allowed, as I'll demonstrate. UK GDPR requires that consent to use your personal information (in this case, your email address) for the stated purpose be freely given. Consent to use your information for direct marketing is not freely given if it's inseparable from the consent to use it for some other service, as per para 43: Consent is presumed not to be freely given if it does not allow separate consent to be given to different personal data processing operations despite it being appropriate in the individual case, or if the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance. And Article 7.4 backs this up with When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract. The intent of Article 6.1(b) is that only the processing required for the service you have bought is allowed (e.g. if you supply your address for delivery of stuff you've bought, the data processor can use that address to send you the stuff, but is not allowed to add a contract term that allows them to send you unwanted stuff). Examples of emails that Article 6.1(b) would allow (in my assessment) include things such as notification of upcoming downtime, or a reminder that subscriptions are due, but not unsolicited advertisements for other products. There's a grey area that's open to interpretation, where adverts are piggybacked onto actual service messages.
a few quick notes that come to mind. As the commenters point out: DSGVO is indeed the German equivalent name to the GDPR (English term) "Imprint" isn't a privacy related topic that much, as such it's not really changed by the upcoming GDPR The GDPR changes many things, but the requirement for up front information isn't one of them - so it would've already been a rule to follow Sometimes the question who is responsible for privacy information might not be that easy to decide when you're on platforms. I take this situation as being pretty clear though. You are basically given a blank slate, you can do with that page whatever you want, and the visitor has no clue whatsoever that it might be hosted by Github. In addition to this, Github would be classified as a data processor (providing the tool) and you as the data controller who is in charge of practically everything except for the provision of the page. I hope this helps. Btw. it's not that hard anymore to write a privacy policy these days.
GDPR defines the responsibility of Companies to ensure that Personal Data in their possession is maintained Secure ensuring Confidentiality and Privacy towards the Data Subjects to whom it pertains. Prior to the Articles themselves, there are notes and over (49) one may read that companies must have in place (where applicable) mechanisms like CERT and any other SECURITY assuring tools/ processes. (83) again is all about ensuring Security. (94) reads that if the Controller (company) find it cannot ensure Security it must stop processing activities and report to the Supervisory Authority for guidance and support. Then we have Article 3 (f) establishing that it is the company responsibility to "... ensures appropriate security of the personal data, including protection against unauthorized or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organizational measures (‘integrity and confidentiality’)..." Bottom line... T&amp;C Companies must ensure that Personal Data is processed by them (and that includes communications) are Secure while ensuring Confidentiality and Pricavy towards the Data Subjects. The wording "...commercially reasonable efforts..." is wrong, because it is not something that may be a legal requirement or not depending on "cost"; it is a Legal Obligation. Then "... the Internet is not an inherently secure environment and so we cannot guarantee the security of your Personal Information..."; this is just "poor legal advice" for GDPR does expect companies to make the Internet safe, it expects companies to maintain their IT Landscape safe... an analogy can be made about going through a group of sharks in the ocean while just swimming or on board of a big boat... the ocean is dangerous due to the sharks, yet if you are in a big boat, you won't even notice them. Then the "cherry on top"; "... e assume no liability for any disclosure of data due to errors in transmission, unauthorized third-party access or other acts of third parties, or acts or omissions beyond our reasonable control..."; now i really do not know which lawyer has written this, but it basically reads something like: "the law obliges me to ensure you are safe... however I am not able to". Now, I have seen similar "statements", but I must confess it was like 2 or 3 years ago... most companies have corrected them over time and since they become aware that penalties were for real. Just a final disclaimer It is a fact that while in transit (over the Internet) a message being delivered through a T&amp;C Company Services will travel through 3rd party infrastructure contexts, rendering it at risk ... however, if it is properly encrypted (as it should) the transition time will not be sufficient for a successful breach attempt. So, yes they are capable of ensuring all they have stated they can not.
An app(lication program) is software run on the end-users machine. That does not fall under the GDPR. Any processing (including storage) you do on user data has to be compliant with the GDPR. Allows a user to authenticate via e.g. Facebook and stores some basic data (optional) Authentication via Facebook leaves GDPR compliance to Facebook (AFAIK). It would be a good idea to provide alternative authentication methods, such as Google and an "own account" user name and password so that the user doesn't have to share information with a multinational company in order to use your service. The "basic data" will need to be processed according to the GDPR. As long as the "optional" part is "opt in" (i.e. the user needs to at least click on something) then this means you have permission to process that data. Providing this "basic data" as a JSON or CSV file should meet data portability requirements. Allows a user to upload a GPX file (a route or some other activity) Stores the above file to Google's database Allows the user to analyze that file. Since the user is actively choosing to upload each file you have permission to do this. You should make it clear in your privacy policy that the data will be held by Google. Doing so should not be a problem as Google has set up the legal framework to do this under the GDPR. You don't have to store the information encrypted, but you should use encryption (e.g. HTTPS) for any data transmission. Allowing the user to analyse the file is not an issue; either the user is doing it on their own machine (GDPR irrelevant) or you are doing it under user instruction (meaning you have consent). Since the user has uploaded GPX files they already have data portability on those files. You should tell your users that while you will employ best endeavours you don't promise to keep their files accessible and they should maintain their own private copies. That way if your entire database gets corrupted they can't blame you for loss of data. Finally, make sure there is a "Close my account and delete all my data" option.
The question says: But by hashing a IP address you process the personal information and that you can't do without the user's permission! But processing personal data (PI) is covered not by the e-Privacy Directive (ePD) but by the GDPR. Under the GDPR processing may be lawful if it is done under any of the six lawful bases specified by Article 6. Consent is one of these. But paragraph (f) permits processing when: 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 ... This is generally known as the &quot;legitimate interest&quot; basis for processing. It normally requires a balancing against the privacy interests of the data subject. Where, as here, the processing is specifically to remove any traceability of the subject, and hence to protect the privacy of the subject, there doesn't seem to be much conflict, so I suspect such processing would be lawful. I have not found, after a brief search, an actual case where this has been tested, so my conclusion might be mistaken. Personal Data under the GDPR and hashing GDPR Quotes Article 4 of the GDPR defines &quot;Personal data&quot; (in paragraph (1) as follows: personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person; The term &quot;pseudonymisation&quot; is defined in paragraph 5 of article 4 as follows: ‘pseudonymisation’ means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person; GDPR recital 26 reads: The principles of data protection should apply to any information concerning an identified or identifiable natural person. Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person. To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments. The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. This Regulation does not therefore concern the processing of such anonymous information, including for statistical or research purposes. Hashing If a cryptographically secure hash function is used to convert an identifier, such as an IP address, into a replacement hash, there is no practical way from the hash value alone to recover the identifier. However, if a particular identifier value is compared with a stored hash value, it is easy to tell if there is a match. Finding a match does not prove that the identifier is the same -- depending on the length of the hash value being used and of the identifier, there may be many values that would give the same hash. But the chance of two random IDs having matching hashes is very small. Thus, if a controller were to store hashed versions of the IP addresses, no one could convert that back to a list of visiting IP addresses. But if soemoen had the IP address of a suspected visitor, and access to the hash function, it would be easy to check if that IP was on the list. If a keyed hash function were used, only someone with access to the key could perform this check. It is not feasible to hash all possible IP addresses as there are over 4 billion possible IPv4 addresses, and over 10^38 IPv6 addresses (over one thousand decillion). Thus creating a table to reverse the hashing in general is not feasible. Whether the possibility of checking for a match makes a hashed IP &quot;reasonably identifiable&quot; as representing a specific natural person under the GDPR and related laws has not, as far as I know, been authoritatively decided. Note that at most it would reveal that a person using a certain internet connection had (probably) visited a particular site.