Does GDPR apply when PII is already publicly available? Pretend there is a website, it might be free to access, or be a paid per search service, where the users get access to summarised information on the people that they search for. All of the information this website displays has been taken from public sources, such as news papers, personal profiles on company websites, LinkedIn, Facebook, other websites etc... Nothing has been copied from these sources, aside from the person's full name and position (such as secretary). The people have never consented to having their data published onto this website, it was mined manually by employees. Would the people be allowed to request their data be removed? I am interested in how GDPR or the Data Protection Act would apply when this information is already publicly available.
The site would combine the data in novel ways, which is processing the data. Processing personal data which is publicly available is still processing personal data. You would have to take GDPR into account. That does not mean the processing is forbidden, but you need a legal basis for doing it. In many ways, having the informed consent is the easiest legal basis, but there are others. The data subject would have the right to demand information about the data you hold, and to demand the correction of wrong data. There is not necessarily a right to demand deletion, but if consent is withdrawn and you have no other basis for data processing, you have to delete. Note also that the consent basis would mean you have to actively contact the people whose consent you seek before the processing starts, and document how you do it. That makes pay-per-request models difficult. But consider that the news media can process some data about some people without the consent of the subjects of their activities. They just need to balance privacy and other legitimate interests all the time.
In principle, the data subject's right to access involves a copy of all personal data the controller holds on them. There are no time limits by default. Of course, the controller can ask a data subject to clarify their request, e.g. to focus on a particular time frame. There is an implied time limit though: personal data may only be processed/stored for as long as the data is necessary to achieve the purposes for which it was collected. Afterwards, it must be deleted. A controller with good data management will be able to limit their effort by having as short retention periods as possible for their different records. Furthermore, a lot of data is not personal data, or falls out of scope of the GDPR because it is not processed with automated means or forms part of a filing system. For example, if thousands of old invoices were archived in paper form in boxes that are only sorted by year, there might be an argument that this isn't a filing system in the sense of the GDPR and that a DSAR would not have to involve looking through all the archived invoices (compare also Art 11). In your scenario, there is a clear retention period of six years. You are asking for records about how that data might have been used further in the past. To the degree that such data is actually available, that could reasonably be personal data and should be included in a response to a DSAR. E.g. they might have information like this: “File #1234 was included in a data set that was sold to EvilCorp in 2007. The entries in File #1234 that are older than 2014 have been purged, so we do not know which entries were included in the data set. The current name on File #1234 is Dave.” This information about the sale would be personal data because it relates to you, and you are identifiable. Of course, the controller might not be set up to perform this search unless specifically asked. However, more unspecific information might not be personal data. For example: “About 70% of our files were included in a data set that was sold to EvilCorp in 2007. We no longer have records indicating whether your file was included.” Since there is no link between the sale and your personal data, I don't think it would have to be included in a DSAR response. The primary reason why you should be told about sales of personal data is that per Art 15(1)(c), you should be informed about “the recipients or categories of recipient to whom the personal data have been or will be disclosed” in a DSAR response. So when making a data subject access request, it could make sense to explicitly referencing this paragraph. So you would be interested in receiving a copy of your personal data as per Art 15 GDPR, and in particular any available information per Art 15(1)(c) GDPR about the recipients or categories of recipients to whom your personal data has been or may have been disclosed in the past. Quite likely the response will be underwhelming, e.g. by just giving a broad category such as “potential creditors who are contractually obligated to use the data only in accordance with our policies”. Whether such responses are compliant (I don't necessarily think so) will not be clear until there's a good precedent, and that would require that someone sorts this out in court.
By itself, a chess position is not personal data. Personal data is “any information relating to an … identifiable natural person”. Since the file in question includes the name of the opponent, it is clearly personal data about the opponent. If the files are used for “purely personal or household purposes”, the GDPR won't apply per Art 2(2)(c). If the files are shared more widely – especially if the files are published – then GDPR becomes relevant. The person/entity who is data controller has to consider GDPR compliance. Data controller is whoever determines the purposes and means of processing of personal data (the “why” and “how”). The first question would be under which legal basis this personal data about another person can be shared. The GDPR offers multiple legal basis, notably “legitimate interests” and “consent”. Consent is always an option, but must be freely given (entirely voluntary). Legitimate interests can serve as a legal basis after a balancing test between your interests and the data subject's rights and interests. This balancing test also depends on the reasonable expectations of the data subject, which in turn depends on the more general context. For example, in a chess community where such sharing is completely normal there would likely be a legitimate interest for you to share games as well, if the games occurred in the context of this community. But if you play a game with a friend who is not part of this community, the friend cannot reasonably expect that their name and associated personal data would be shared. The second question would be how you would satisfy further GDPR compliance obligation, in particular the Art 13/Art 14 right to information. When collecting personal data, it is necessary to provide certain information such as your identity, what processing is being carried out, and how the data subject can invoke their GDPR rights (a privacy notice or privacy policy). This might be difficult or awkward to do. Practical solutions to these problems: If you want to share a game but aren't sure that the opponent is OK with this, remove identifying aspects such as names. For example, you could crop a screenshot, or describe the game in textual notation without listing the opponent's name. Play the game via a chess website that publishes the game. This way, the website is the data controller, and you and the opponent are the data subjects. This avoids having to act as the data controller yourself. This might work for private interactions, but not e.g. if you run a chess club and require members to play via that website – you might still be in a data controller role then and have full compliance obligations.
Yes, GDPR applies: you are a data controller established/living in the UK or are offering services to people in the UK you fall under the material scope of the GDPR. The Art 2(2)(c) exemption for “purely personal or household activity” does not apply since you're offering the service to the public. You must consider GDPR compliance here. This is especially important as you are showing personal data to the public. Don't do that unless you have a very good reason, appropriate safeguards, and are clear to users how their information will be shown. On a high level, GDPR compliance involves working on the following questions: For what purpose are you processing personal data? Context: purpose limitation principle per GDPR Art 5(1)(b) What is the legal basis for processing? GDPR Art 6(1) lists the available legal bases. Here, consent, necessity for performance of a contract, or a legitimate interest could be a legal basis. They may have further obligations attached. A legitimate interest requires a balancing test that considers the data subject's rights and freedoms. Consent must fulfil the conditions per Art 7 in order to be valid. What is the minimal data necessary to achieve the purpose? Per the Art 5(1)(c) data minimisation principle, it is illegal to process personal data beyond what is necessary and adequate. You must provide data protection by design and by default per Art 25. Special categories of data per Art 9 such as health data are illegal to process outside of narrow exemptions. You must delete data once it is no longer necessary. What appropriate safeguards and security measures should you apply? Per Art 24 and 25, you are responsible for determining and implementing appropriate measures. This depends a lot on your specific context, so there's no checklist you can apply. Per Art 25(1) you must pseudonymize the processed information if that is compatible with the processing purpose. What further compliance measures do you have to consider? There are additional GDPR and non-GDPR compliance measures. From the GDPR side: Use the answers to these questions to write a privacy policy, including the information that you must provide to data subjects per Art 13. Consider whether you have to maintain a Records of Processing document per Art 30, or if you have to make a Data Protection Impact Assessment per Art 35. If you use third party services, figure out whether they are a joint controller or data processor and apply appropriate safeguards. If you have data processors, ensure that you have a contract in place that covers the items from Art 28(3). If you share data with other controllers (not processors) you need a legal basis for doing so. If you transfer data into a non-EU/EEA country (after 2020: non-UK country) you need a legal basis per Art 44 and have to cover additional items in your privacy policy. Ideally, the target country is covered by an EC adequacy decision per Art 45. For US-based companies, this is the case only when they have self-certified under the Privacy Shield framework. Non-GDPR compliance steps could include cookie consent banners, or showing a VAT ID. How can you prepare for data subject requests? Data subjects have various rights per Arts 15–23, subject to the modalities in Art 12. For example, a data subject could request that their information is erased from your website. The exact rights also depend on the legal basis you selected. You should figure out in advance how to deal with such requests.
Generating a list of all possible numbers doesn't sound like it would constitute personal data any more than listing all dates for the last hundred years as a "possible date of birth" would. However, the moment anyone linked even one of the numbers with any other personal data - for example a name - they would be bound by GDPR and would need to show a Lawful Basis for processing the data. [If you linked your own name you could presumably argue Consent, but anyone else's would need to have an associated Lawful Basis.]
Don't collect or process personal data Many (though of course not all) websites can easily be run without collecting or otherwise processing any personal data. The position of GDPR is that if you are not able to fulfil the basic, simplest core conditions for processing personal data (understanding what you're processing and why and why it's allowed, describing it in a privacy policy, having a non-underage person who's responsible for that) then you are not allowed to process personal data of other people. So don't. Build your website so that any personal data are not collected.
There is nothing preventing the OP's &quot;subject&quot; from making a Subject Access Request in these circumstances From the British Transport Police's Privacy Notice page, under the heading &quot;How we use personal data&quot;: This privacy notice explains: ... the rights individuals have when we process their personal data. ... Right of Access: You can request access to the personal data we hold about you free of charge. You can request access to the personal data we hold about you using the contact details in this privacy notice. ... We collect personal data from a variety of sources, including: ... sound and visual images (e.g. from body worn cameras, CCTV, or facial recognition software); ... our own CCTV systems and body worn cameras. There's more detail in the link, which I have not replicated here to save space and avoid unnecessary &quot;noise&quot;, but the above should cover the relevant points raised by the OP
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).