Requesting to see holiday rota and GDPR my partner has asked if she can see the holiday rota and was told she couldn't because of GDPR. Is that correct? I know anything that identifies you needs to be secure but the rota of when people are working is clearly visible on their noticeboard so doesn't the same apply to that? thanks
There is no clear answer to this question. The GDPR doesn't not apply, but it delegates rules for processing in the context of employment to member states. That means, the laws in your country might override the GDPR here. As the data controller in this situation, the company must protect the personal data it processes, including the personal data of employees. Protection doesn't have to be absolute, just proportional to the risks. It may be fine to treat data in one context more carefully than another. This is always a judgement call of the data controller. There is nothing about holiday rotas where the GDPR would require them to be kept under lock. The company could very well decide that this data isn't very sensitive and that everyone can look at it themselves. For example, the company might argue they have a legitimate interest for this so that employees can see whether their colleagues are unavailable. But until the controller makes such a decision, the rota contains other person's personal data and cannot be disclosed without a legal basis. Here, I see three reasons why the company might be acting that way: They are overly careful with GDPR compliance and are cargo-culting restrictions that are not actually necessary. They have made a conscious decision to restrict access to this data to protect the private life of employees. They want to make it more difficult for employees to take time off.
This depends on the context – GDPR rarely restricts the use of specific kinds of data (see Art 9) but instead regulates the processing of this data, and the purposes for which it is processed. Personal data is any information relating to an identifiable person (Art 4(1)). So to show that some information is not personal data, you must show either that it doesn't relate to the identifiable person, or that it's not possible to identify the person. Whether a person is identifiable depends on the means of identification that are reasonably likely to be used, taking into account the cost and effort of these means (Recital 26). This recital also mentions that singling out a person is a kind of identification. If you have lots of birthdays so that there are no unique birthdays, or if the birthdays are stored without contextual information that would allow identification, this can indicate that it's not personal data. Some examples to illustrate my views: Scenario 1: you are collecting statistical data in a shopping mall and are collecting birthdays from passer-bys, without any additional information. This information is anonymous and not personal data, since you have no reasonable means to identify the persons. Scenario 2: in an office, there's a publicly visible calendar on the wall with the birthdays of all staff members. However, the calendar doesn't say whose birthday it is. This information is likely personal data, since it's reasonably possible to infer the correct person based on contextual information. At least HR would also have the birthday for all staff members on file, so that the company clearly has the means to identify anyone. (This doesn't mean such a public calendar is illegal, just that there must be a legal basis.) It is more difficult to determine whether information also relates to an identifiable person, i.e. whether this information is about that person. This depends not just on what the information is, but how the information is used. AFAIK there has yet to be EU-wide guidance by the EDBP, but the ICO has listed some hints. I think that a birthday of an identifiable person will almost always relate to that person.
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 GDPR does not prescribe how exactly consent must be managed, as long as consent was obtained in line with the GDPR's principles. Similarly, the EDPB does not provide concrete recommendations in its guidelines on consent, mainly noting that Controllers are free to develop methods to comply with this provision in a way that is fitting in their daily operations. I would not be too concerned with edge cases like failing HTTP requests, at least not any more than for other HTTP endpoints. If the user indicated consent, and you act on that indication of consent in good faith, that's probably fine. However, remember that you must provide a equally easy way for the user to revoke consent later. If the user changes their mind, they can use the mechanism that you offer to inspect their consent status, and revoke it if they want. But again, how to do that is largely up to you.
For land ownership records and other similar scenarios such as business directors, the requirement for these to be public will be in legislation rather than a contract - this provides the legal basis, see GDPR Article 6(1c). Additionally when government departments are doing it they also have 6(1e) as lawful basis: "1. Processing shall be lawful only if and to the extent that at least one of the following applies: ... (c) processing is necessary for compliance with a legal obligation to which the controller is subject; ... (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;" -- GDPR, Article 6(1c,e). I'm not familiar enough with the specific legislation that will apply here but pretty sure this will be the case, and having said this you may well find public registries also become less public going forward. The reason ICANN has come under fire, is partly because under GDPR privacy is a protected fundamental right and therefore to comply personal data should be kept private by default and privacy never something you would be required to pay extra for. Any contract ICANN have in place with their registrars will not override legislation, it is in fact the other way around. "2. The controller shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility. In particular, such measures shall ensure that by default personal data are not made accessible without the individual's intervention to an indefinite number of natural persons." -- GDPR, Article 25(2). This doesn't stop ICANN from maintaining a register of domain name owners (registrants), but it does mean they can't just publish all records upon request to anyone anymore - whether people will be granted access to personal data will now depend on if they have a lawful basis for this, and in these cases their processing of the personal data will be limited to those purposes. Being nosey doesn't count! "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 the contract." -- GDPR, Article 7 (4) - Conditions for consent. What this means essentially, is that if the consent is conditional for the contract it will not be treated as freely given, and therefore not valid - it will no longer be acceptable to contractually bind the provision of a product or service with consent to publish personal data or any other form of processing such as marketing mailing lists. Looking now at the specific points you have raised: "GDPR article 6 allows for processing of personal data on a contractual basis (section 1b)" Whilst this is true, this is only part of it - it doesn't allow for unlimited processing for any purpose and sharing it with any people, if you look at Article 5(b) it states that the information is collected for specific explicit legitimate purposes. Each purpose requires its own legal basis and needs to be compatible with the principles of GDPR. Without consent, ICANN currently does not have a legal basis to make the WHOIS records public for EU citizens and should have adopted some technical controls to require them to opt-in if they wish to be included in the public register. They're coming under fire for non-compliance having been given 2 years to prepare and change their systems/processes. "processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract;" Again whilst this is true, not all processing is necessary for the performance of a contract. In the same way people must give consent to receive marketing communications, they must freely give consent for their information to be shared/published (separate to the contract for provision of service) in the absence of other lawful basis for this processing. "Also section 1c, processing is necessary for compliance with a legal obligation to which the controller is subject;" There is no legislation which requires them to publish the personal data of domain name registrants. In this paragraph 'legal obligations' refers to those required by legislation (i.e. statutory obligations), not contracts (or non-statutory obligations) which are covered under Article 6(1b). "And finally section 1e, processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;" ICANN has no official government-assigned authority, and publishing the personal data globally is not in the interests of the data subject's or others' welfare or well-being - this is what is meant by 'public interest'. As far as I can see what ICANN are actually doing to comply seems to be accepted by the European Data Protection Board, they are only 'under fire' as you say because they are late in doing so. The deadline was 25th May 2018 and they had 2 years to prepare like all other organisations.
In my opinion, this should be enough. The GDPR regulation is general - it does not attempt to address these issues directly, precisely for the reasons we see here: You can never predict how the technology will develop. When interpreting the GDPR, we must keep the intended goal in mind. What is the purpose of the "right to erasure"? To prevent anyone from further processing the personal data. If you "crypto-shred" it, it can't be processed anymore, not even theoretically. The encryptec file cannot be used to identify the subject, therefore it is not even personal data anymore. In case it can be decrypted in the future... Well, that is just a speculation. The courts can go to great lengths in interpreting what personal data is (dynamic IP address is considered personal data, since it can be linked to a person by the police with a court order), but i am pretty sure that "it can be theoretically possible in some distant future" is beyond the limit. As for the second question, I am not aware of any applicable case-law, but I guess that current security and technological standards will be used to assess the delay. You have a right to protect your data, the subject has a right to erase them. Those rights must be balanced, neither fully overrules the other. The delay should be short enough so the right to erasure is effective, and it should not extremely long compared to other (economically viable) backup solutions available, in line with current industrial standards.
Certainly. A phone number is personal information (and on top of that, WhatsApp may provide some &quot;profile info&quot; from the people you contact). It is not difficult to identify a person by its phone number. So, sharing the phone number of the people affected should take into account the restrictions of GDPR. For instance, the Spanish Data Protection Agency (Agencia Española de Protección de Datos, AEPD) established in its Resolution R/03041/2017 that the Town Hall of Boecillo had violated the GDPR because it had created a WhatsApp group of citizens. Those citizens had provided their phone numbers to be informed about town hall activities, but they had not agreed to share their numbers with the other members of the group. And that was a very generic group. Doing a &quot;patients recovering from cancer&quot; or &quot;drug abusers under treatment&quot; or &quot;people who need food assistence&quot; group would involve sharing personal information that gets the maximum protection (in some specific instancies it could be that your information sharing that information is illegal even if the users gave you full consents). So yes, creating a WhatsApp group could very easily lead to a GDPR violation, and in fact it has been ruled at least once that it has. The fact that people cannot send messages is irrelevant. It would not make the issue any better or worse. After all, if I send a message through WhatsApp I am implicitly giving permission to everyone in the group to read it.
Maybe, but probably not The geographic location of the organisation is immaterial: under Article 3.2: This Regulation applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to: ... (b) the monitoring of their behaviour as far as their behaviour takes place within the Union. Posts anyone (not just EU citizens) make to Reddit (or anywhere else) while they are physically located in the EU or UK engage the GDPR. Pushift.io is therefore captured by the GDPR and any denial of that is just plain wrong. Given the denial, it is likely right out of the gate that they are non-complient. For example, they are unlikely to provided the required information under Article 14. More importantly, it seems that they have not determined the lawful basis for processing the data under Article 6 - they can possibly rely on the public interest basis (preserving deleted publication is arguably a public interest) or a legitimate interest but that requires a balancing of their interest against the data subject's. That said, the right to be forgotten is not absolute, the reasons that might be applicable here are: The data is being used to exercise the right of freedom of expression and information. The data is being used to perform a task that is being carried out in the public interest or when exercising an organization’s official authority. The data represents important information that serves the public interest, scientific research, historical research, or statistical purposes and where erasure of the data would likely to impair or halt progress towards the achievement that was the goal of the processing.