How does GDPR affect sports statistics? I am involved in maintaining few sports statistics systems. Of course, these systems are full of personal data. It is important to keep a list of players in a hockey game and a name associated with a result in a running event. Even more - the date of birth is also important in many cases. Currently databases store and publicly display all of this information. Here you have a few examples: https://www.iaaf.org/records/by-category/u18-world-best-performance http://www.eliteprospects.com/player.php?player=8627 Can this still be justified under GDPR or will databases have to hunt the people one by one and ask for their consent?
Consent of the data subject is only one of several conditions that allow the processing of personal data; these are found at Article 6(1) of Regulation 2016/679. The last, item (f), is also of interest: Article 6 Lawfulness of processing Processing shall be lawful only if and to the extent that at least one of the following applies: (a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes; (b) 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; (c) processing is necessary for compliance with a legal obligation to which the controller is subject; (d) processing is necessary in order to protect the vital interests of the data subject or of another natural person; (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; (f) 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. Point (f) of the first subparagraph shall not apply to processing carried out by public authorities in the performance of their tasks. Most sports statistics systems maintain identifying data for legitimate purposes pursued by the systems' owners. Since the data in question are already publicly available, and in many cases are made public by the athletes in the course of their lives as public figures, it is unlikely that a court would find that the athletes' interests or fundamental rights and freedoms override the interests of the systems' owners in processing the data.
Article 32 of the GDPR requires companies to adequately secure their data when handling data belonging to EU citizens. This also applies to cross border scenarios where data is transferred between countries. Technically speaking, the GDPR doesn't set a standard for security: you don't have to encrypt your data, use AES or RSA encryption, or hash and salt passwords. It is your choice on how to secure your data, though the GDPR does mandate specific ways to secure data. However, not doing so opens yourself up to two consequences: The European data protection supervisor is tasked with the enforcement of regulations. A company can be forced to increase their level security if a valid complaint alleging that inadequate security measures are in place is made There is a significant amount of security risk, and if a data breach occurs, the GDPR allows authorities to levy heavy fines. Especially heavy fines may occur if it is found that the data was not securely stored. So the answer is: A complaint to relevant authorities can force the company to take action, or they will lose access to the European market.
GDPR compliance is a matter between every customer and the business, not between different customers. How did you get the other customer's contact details? If they were provided or leaked by the business, that might be a failure of the business's obligation as a data controller to protect the personal data they are processing, possibly even a data breach in the sense of the GDPR. When you contacted the other person this was presumably a purely private or household activity, just like contacting any other personal acquaintance. In that case, the GDPR simply does not apply to any “processing” you may have done (compare Art 2(2)(c)). Things would be very different if you were promoting your own business, but that doesn't seem to have been the case. If the matter really is as plain as you described, then you can effectively ignore their references to the GDPR until you are contacted by your data protection authority, by their lawyer, or are served with court papers. None of these should happen: even if you were a “data controller” and your processing were subject to the GDPR – only the other customer and not the business would be the data subject, and only a data subject has a right for remedies like making complaints to the data protection agency and only the data subject would have standing to sue you in court for GDPR violations.
StackExchange is a processor under GDPR because it processes the data you provide it when you sign up and input personal information. It's determined by an analysis of what function(s) the business is performing. If you are merely processing the data but don't have control over it (e.g. another business is using your software to do something with data that it is providing you) then you are likely to be a data processor. Conversely, if you control the data, you are likely to be a data controller. It is possible to be both a data controller and a data processor at the same time. That specific link in your post goes on to state: Our business customers may qualify as controllers when they purchase certain of our products and services. We act as processors on behalf of such Customers. This is referring to the Teams product that StackExchange offers or whatever the &quot;internal company-only question and answer site&quot; product they offer is called.
It seems clear that this is personal information under the GDPR. If you are subject to the GDPR, you need to have a "lawful basis" to store or process such information. (You are subject to the GDPR if you are locates in the EU, or if your users are. My understanding is that it is location at the time the app is accessed that matters, not a user's citizenship. I am not totally sure about that, however. Unless your app is limited to non-EU access, it it probably safest to comply with the GDPR) The degree of precision of your location data will not matter -- a specific city is quite enough to make it personal data if it can be tied to a specific person. There are various lawful bases that may be relied on for processing and storage, but explicit consent is probably the one with the widest applicability. To use consent as the lawful basis, you must present an OPT-IN decision to the user, and record the results. If the user does nothing, the result must record lack of consent. You may not use a pre-checked consent box or another mechanism that has the effect of an opt-out choice. You should be clear about what information will be stored, and how it will or might be used. You will also need to consider how your app will function for those who do not consent, and how to handle requests to withdraw consent. So if an app obtains user consent to store location data in a manner that complies with the GDPR, it may store user location data. The consent should make the possible uses of the data clear. If the data is to be shared, the consent should make the possible extent of sharing clear. Some previous questions and answers here on law.se dealing with GDPR consent that seem possibly relevant: User consent required under GDPR What provisions should I make regarding GDPR consent when users do not sign themselves up? GDPR - Withdrawn user consent Opt Out Consent under GDPR
Personal data is any information relating to an identifiable person, even if that person is only identifiable with the help of additional data and/or third parties. Making inferences about a particular person, for example whether that person might have performed unauthorized construction, sounds very much like processing of personal data to me. In this scenario, the information is used to verify the tax assessment for a particular person, so the information clearly relates to a data subject. The owner for a piece of land is certainly identifiable with the help of the land registry, if one exists in the country. Similar registries might also exist with tax authorities or a postal service. Here, it is the tax authority itself doing the processing, so they probably already have tax records about the owners at the address. But just because it's processing of personal data doesn't mean that it is illegal. Satellite data and aerial photography providers can probably rely on a legitimate interest to collect, sell, or otherwise publish their data. Homeowners can reasonably expect that their property will be included in low-res aerial photography. It might not be necessary to notify the data subjects if an exception in Art 14(5) applies. A public authority using aerial photography to find building code violations or to levy correct taxes may be able to base this processing activity on authorization via some law. If the public authority would have the right to inspect the buildings, then it might be possible to argue that the public authority can use aerial photography to decide which inspections/audits to prioritize. Of course, decisions producing significant legal effects must not be based on “AI” alone, due to the Art 22 GDPR right to not be subject to unchecked automated decision making (unless specifically authorized by a suitable law).
In short, no. Article 20 of the GDPR covers the “Right to data portability”, which essentially says two main things: The data subject had the right to an exported copy of their personal data in a common format And The data subject has the right to have this data transmitted directly from one controller to another where technically feasible. Neither of these rights as stated in the GDPR require the data controller to provide a button to initiate either a data export or a transfer to another controller.
Yes, but it doesn't matter. This answer discusses gdpr implications. Personal data is any information that relates to an identifiable person. The GDPR has an extremely broad concept of identifiability, also covering indirect identification using additional information and with the help of third parties. Even just being able to single out one data subject, i.e. being able to distinguish different users from another, counts as identification. If you already have a concept of user accounts, any information that is linked with the user accounts and somehow relates to those users would also be personal data. Since you have distinct push tokens per user, it seems like this criterion would be met. Additionally, those unique tokens might be directly identifying by themselves. The GDPR does not allow for semantic games like “it only identifies the device, not the user”. The key here is that the definition of identifiability does not hinge on your intentions, but on objective capabilities: if you or someone else who can come into possession of this data were to attempt to identify the user (such as singling out users from another), would they be reasonably likely able to do that? Since most devices are single-user, being able to identify a device would imply that you're reasonably likely to also identify users. Just because something is personal data doesn't mean you're forbidden from using that data. It means that you'd have to comply with GDPR rules, if you're otherwise within scope of that regulation (e.g. if you're EU/UK-based, or are targeting your services to people who are in UK/EU). For example, basic GDPR compliance steps include having a clear legal basis for your processing of personal data (such as necessity for performing a contract to which the data subject is party, or necessity for a legitimate interest, or consent), providing a privacy notice, and taking appropriate technical and organizational measures (TOMs) to ensure the compliance and security of processing. For example, TOMs regarding these push tokens could involve encryption, access controls, and a plan for installing security patches in order to prevent data breaches. Using push tokens is already a good measure in this context, since they are effectively pseudonymous and prevent linking additional information via that token (two sites/apps pushing notifications to the same person will have entirely different tokens). However, the push notification provider (e.g. Google, Apple, Mozilla) can resolve the pseudonymous tokens and link them to a person, indicating that these tokens are ultimately identifying (even if you can't perform that linking yourself). Note that if GDPR applies, then other EU/UK rules might apply as well. For example, sending electronic messages (such as emails) is subject to anti-spam rules (EU: ePrivacy, UK: PECR). These rules apply regardless of whether personal data is involved. Since the rules are not technology-specific, it is likely that regulators would consider user-visible push notifications to be equivalent to more well understood technologies like email and SMS.