GDPR and local data storage in mobile app Let's say that I have a mobile app that tracks the user and saves his GPS coordinates locally only on a mobile device so that he can check where he was. The mobile application does not send this data to any server. Does GDPR affect me and my app in any way? Do I need for example to change my app in such way that it encrypts that personal GPS data on the device? Or GDPR has no influence on my app as I as a person do not have any access to that data?
No. As long as you don't see and have no means to access this data, but it is under the control of the user at all times, you are neither the controller or the processor of this personal data, and the GDPR does not apply to you.
From the GDPR's definitions: ‘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; This blurred image would be &quot;information relating to an identified ... natural person (‘data subject’).&quot; It does not matter whether the person can be identified using the information in question. Therefore, the answer to your question Under GDPR, does blurhash of a profile picture count as personal data is yes.
Art. 17 GDPR Right to erasure (‘right to be forgotten’) The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies: Assuming private messages contain personal data, if at least one of the following points (a..f) applies, it would have to be deleted. (a) the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed; The original main purpose was probably Article 6(1)(b) (performance of a contract). If you delete your account, that would no longer apply. However, for the receiver of the private message, Article 6(1)(f) (legitimate interests pursued by a third party) would apply. The receiver might still want to read that message. So there is still a purpose to process this data. So point (a) does not apply. (Note that a Facebook private message can be considered a hosted version of SMS messages. A receiver does not expect SMS messages to be automatically deleted after they have reached the recipient's device. A receiver expects full control of the storage of SMS messages. I think a receiver expects the same for messages on facebook.) (b) the data subject withdraws consent on which the processing is based according to point (a) of Article 6(1), or point (a) of Article 9(2), and where there is no other legal ground for the processing; Data processing was not based on consent, so point (b) does not apply. (c) the data subject objects to the processing pursuant to Article 21(1) and there are no overriding legitimate grounds for the processing, or the data subject objects to the processing pursuant to Article 21(2); Article 21(1) allows you to object to processing based on Article 6(1)(f), unless there are compelling legitimate grounds for the processing which override the interests, rights and freedoms of the data subject. While I think processing is based on Article 6(1)(f), I also think there are legitimate grounds to refuse your objection. As explained before, the receiver might still want to read that message. The receiver was able before to read your message, so one can assume he/she has already knowledge of the personal data in the message. As it is a private message, no one else will be able to read that message. (At least Facebook will not allow it). So if the message is not deleted, the privacy implications for you are low. That's why I think the interests of the receiver will prevail. However, in the end, a judge will be the only person which can make such a consideration. So you would have to got to court to get a final decision about this. Article 21(2) is for direct marketing, that does not apply to this situation. So I think point (c) does also not apply. (d) the personal data have been unlawfully processed; (e) the personal data have to be erased for compliance with a legal obligation in Union or Member State law to which the controller is subject; These points do not apply. (f) the personal data have been collected in relation to the offer of information society services referred to in Article 8(1). This data processing was not based on consent, so even if you are a child below the age of 16 years, point (f) does not apply. Article 17(2) and Article 17(3) wont help you either. So in my opinion Facebook is right in this case.
IANAL. (1) GDPR is certainly relevant. (2) This is certainly "personal data" under the definition in GDPR article 4. (3) Maintaining this data is probably lawful under article 6 sections 1(a) (consent) - provided that the Terms and Conditions of the site make clear that the user by signing up is consenting to this information being held (3) There is certainly an obligation under article 14 to disclose that the information exists, and to say how it used. (4) Article 15 says that data subjects are entitled to see the information and know what recipients or categories of recipient have access to the information (I don't know whether it's enough to just say "moderators", or whether the moderators need to be identified). (5) I can't see any reasons why the obligations under articles 16, 17, and 18 regarding rectification, erasure, and restriction of processing aren't relevant. This is exactly the kind of situation that GDPR is designed to address. If you're restricting the service available to particular users based on a record of their behaviour or on judgements made by moderators, then they absolutely have a right to know, and a right of redress.
Possibly, but probably not. Personal data is any information relating to an identifiable person. The statement “Alice is sick” is information, and relates to Alice who is identifiable. Processing personal data is not inherently illegal, but does require a legal basis per Art 6 GDPR, such as a legitimate interest. Here, the information is data concerning health, processing of which is prohibited unless one of the explicit exceptions applies (such as explicit consent, or legal obligations). So it is legitimate to have concerns on whether disclosure of this information would be legal. If these rules were breached, that would be on the data controller. Here, the company would be the data controller, not Bob (unless Bob acted against training and instructions and processed the personal data for his own purposes). However, GDPR probably doesn't apply to this specific interaction. In Art 2(1), the GDPR says that This Regulation applies to the processing of personal data wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system. A conversation itself would not be subject to GDPR rules – there is no filing system or similar structured data involved. What GDPR would prevent is to keep records on Alice's health status, but doesn't necessarily prevent talking about it informally. For example, the EUR 35.3M fine against H&amp;M in Germany was imposed not because managers talked with employees about personal matters, but because they then maintained detailed files about those personal matters. Data controllers are responsible though for ensuring security and compliance through appropriate technical and organizational measures (TOMs). TOMs can include things such as non-disclosure agreements and training for staff. If Bob acts against such training, there could be repercussions along the Bob–Company employment relationship. But that would mostly be an employment law thing, not so much a GDPR thing.
GDPR is not a blanket ban on the handling of personal data. It is a set of guidelines when and how data may be processed and stored. Documenting the compliance with a deletion request is one of many purposes for which some data may be retained after a deletion request. Others would be past contractual obligations, legal documentation requirements, and even a balance of 'legitimate interests' of the processors and the data subjects. The processor might be able to argue that fraud/abuse prevention is such a legitimate interest. What if I want to create a service that does let users enter their friends' email addresses, and send those friends an email invitation to the service? Get a specialist lawyer on staff who can check your exact business processes. A web site like this cannot possibly give you a full explanation of the pitfalls.
The GDPR gives controllers a lot of latitude. They must decide on the correct course of action taking into account the possible risks to data subjects. Specifically, no notification of the authority is necessary if “the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.” In your scenario 1, you suggest that there is no breach because there is no evidence that the data was improperly accessed. This analysis is faulty: the controller is aware that the data was not properly secured, and cannot rule out that the data was improperly accessed. I would argue this fits the description of a “breach of security leading to the accidental or unlawful … unauthorised disclosure of … personal data” (compare the definition of a data breach in Art 4(12)). Thus, a data breach has happened. The question whether the supervisory authority has to be notified of that breach is more debatable. The controller must assess the likelihood of risks to the data subjects. Here, they can perhaps argue that the risk of disclosure is low. However, the nature of the breached data would also be relevant. If in doubt, the controller should make the notification. The goal of the GDPR is not to punish unlucky companies that suffer a breach, but to protect personal data. Thus, fixing mistakes and cooperating with the supervisory authorities is likely the best approach for most companies. In your second scenario, the data is sensitive – its disclosure has a high risk for data subjects. However, the risk of someone intercepting this data is debatable. Does the risk of interception balance out the sensitivity of the data? That's the data controller's call, but I don't think so. A notification would seem appropriate here. As a technical remark, simply offering HTTPS is not sufficient to prevent MitM attacks – users must be forced to use encrypted connections. If a controller sees MitM as a risk, they are required by Art 24 to take appropriate technical measures. Here HSTS and HSTS preload would prevent the connections from being downgraded to HTTP. Instead of offering insecure connections, the site would become inaccessible. A complementary strategy is to not serve content over HTTP, but have the HTTP server only issue a permanent redirect to the HTTPS URL.
Art 13 GDPR is about information to be provided when data is collected directly from the data subject. This information can be provided directly during/before collection. It is not generally necessary or useful to send the data subject an email with this information. Usually, a SaaS website will provide the information under Art 13 as part of their privacy policy, and link it in easy to find places. Also consider the EDPB guidelines on transparency, which suggests a layered approach: in addition to a detailed privacy policy, summarize key information directly when the data is collected, e.g. next to an input form.