Are there temporal limits to data requirements for a GDPR SAR? Are there any limits on data that must be provided as part of a GDPR subject access request (SAR) based on the age of the data? The particular case I am thinking about is SAR made to the 3 credit reference agencies. As I understand it they only keep my credit data for 6 years, but I would expect them to keep sales data for much longer. Say they know that they sold a large dataset to a third party 20 years ago, and cannot definitively say my data was not included. Are they required to give me details of this transaction? What if they had a potential data breach 20 years ago, would they be required to give details of this? Is there any particular language I should use in my SAR to make sure this is included?
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.
In answer to your questions, always get potential clients to sign a contract which covers the GDPR personal data processing requirements at a minimum, prior to giving them a copy of a consultant resume to retain. If you were sat in a meeting with them it is much simpler to record in your logs that the client had sight of the resume but was not left a copy of it in any format, than it is to keep track of which clients have a copy of which data and chasing up to ensure it is erased/destroyed when appropriate. To ensure clients treat the resumes as confidential, make sure they are labelled in the header and footer as confidential. They could also be kept in an envelope clearly marked confidential. There could also be a footnote in small print that informs anyone with a copy, who the data controller is, and that processing is strictly subject to the terms of the 'client contract' or whatever you call it, and that it should be returned or shredded within X days of receipt for example. If you have a computer system generate these it could even specify the client's name and the specific date it should be shredded by. Your notice could include a reminder that the personal data is protected under the E.U. General Data Protection Regulation (GDPR) 2016 and that (client name) as a data processor could be held liable in the event of unauthorised disclosure or processing, if they act outside or contrary to lawful instructions of the data controller. Whilst this won't enforce responsible processing at least it will ensure that your business has done its best to ensure any recipients are fully aware of their responsibilities to protect the information and it would be very difficult for a client to claim they weren't aware the information was confidential or that they had legally binding responsibilities to protect it. It's also worth noting that simply sending CV's/resumes (or other personal data) out via email (unless suitably encrypted) would not meet the requirement in GDPR recital 39 for personal data to be "processed in a manner that ensures appropriate security and confidentiality of the personal data, including for preventing unauthorised access to or use of personal data and the equipment used for the processing." Email technology whilst convenient does not offer any guarantees regarding privacy and confidentiality, therefore instead of sending resumes as email attachments it might be better to use a web-based extranet system which authenticates users before granting access to view resumes. Emails could just let clients know there is a new resume or X number of resumes waiting for them to review and give them a link/button to login. The records of processing activities are in GDPR Article 30 on page 50, and it does not specify a retention period nor that we can choose the retention period, but simply states that data controllers make the records available to the supervisory authority when requested to do so - this may imply indefinite retention of processing records even beyond the life of the processing system (e.g. discontinued products/services), however we may need to await further clarification on this issue from supervisory authorities to be sure.
There are two relevant bodies of EU law to consider here. The GDPR covers processing of personal data. Personal data is any data where the data subject can be identified directly or indirectly. The ePrivacy directive is also relevant, and covers how you may access and store information on the user's device. Directives are not directly applicable law. Instead every member state translates the directive into national law. In the UK, ePrivacy is implemented by PECR. Is the data you collect personal data in the sense of the GDPR? Yes: that hashed unique device ID or a system-provided advertising ID likely is personal data, and any linked data would then be personal data as well. This is going to be the case in particular if you store user accounts on your server and can connect these bug reports to a user. Consider also whether the game save could include personal data, and whether the video clip could be analyzed to identify the data subject. Does this mean collecting this information in bug reports is forbidden? No, the GDPR doesn't forbid or allow anything outright. Instead, you should go through the compliance process. In a nutshell: determine the purpose of this processing, e.g. “fixing bugs” find an Art 6 legal basis for this purpose, e.g. “Art 6(1)(f) legitimate interest” or “Art 6(1)(a) consent” if the legal basis is legitimate interest, you must balance that interest against the data subject's interests determine whether your compliance requirements include creating/updating your Records of Processing, or whether you have to write a Data Protection Impact Assessment implement the processing in a manner that respects GDPR principles such as Transparency and Data Minimization if the legal basis is legitimate interest you must implement an opt-out solution if the legal basis is consent, you must request consent first in a manner that satisfies the Art 7 conditions for consent – and allow consent to be revoked easily prepare to satisfy data subject rights: information requirements per Art 13, usually done in the privacy policy right to access, rectification, erasure, and data portability right to object (opt-out) and to restrict processing be aware of your general requirements a data controller to process this data securely, e.g. use HTTPS connections to transmit bug reports, take steps to protect your own accounts (e.g. 2FA), and ensure you have a suitable contract with any data processors that act on your behalf, e.g. cloud providers or contractors I would question whether your bug reports really need to include a device ID. That isn't forbidden, it just complicates compliance a bit. And what about ePrivacy? The ePrivacy directive is known for its cookie consent requirements. But these consent requirements apply when accessing any information on the user's device, or when applying equivalent fingerprinting techniques. Your game save is not an issue because it is necessary for the game. But that device ID and other system information is more difficult. So what to do? Compliance isn't trivial, but certainly possible. You will likely process the bug reports under your legitimate interest, but might still have to collect consent for accessing a system ID due to ePrivacy. Such a screen might look like this: Oh no, the game crashed! Do you want to send a bug report to the developers? Your bug report will be protected as per our privacy policy (link). Your bug report will contain the following information: … Yes, collect system information and send bug report No, do not send bug report You could make an argument that a bug report can be sent in any case, and that you just need ePrivacy consent to collect useful system information. For example: Oh no, the game crashed! When sending a bug report to developers, do you want to include extra system information (link to details) that helps fixing the problem? In any case, your bug report will be protected as per our privacy policy (link). Your bug report will contain the following information: … Yes, send bug report with extra system information No, send anonymous report
The provider has a legitimate interest in the data subjects data, and therefore they can override the right of deletion. See this example from the UK's Information Commissioners Office: A finance company is unable to locate a customer who has stopped making payments under a hire purchase agreement. The customer has moved house without notifying the finance company of their new address. The finance company wants to engage a debt collection agency to find the customer and seek repayment of the debt. It wants to disclose the customer’s personal data to the agency for this purpose. The finance company has a legitimate interest in recovering the debt it is owed and in order to achieve this purpose it is necessary for them to use a debt collection agency to track down the customer for payment owed. The finance company considers the balancing test and concludes that it is reasonable for its customers to expect that they will take steps to seek payment of outstanding debts. It is clear that the interests of the customer are likely to differ from those of the finance company in this situation, as it may suit the customer to evade paying their outstanding debt. However, the legitimate interest in passing the personal data to a debt collection agency in these circumstances would not be overridden by the interests of the customer. The balance would be in favour of the finance company. Article 17 of the GDPR, the &quot;Right to be forgotten&quot;, says this: 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: A) the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed; 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; 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); In your example, it's obvious that the personal data is still necessary for performance of the contract (Art 6(1)(b)) such as collecting payment, or for fulfilling legal obligations (Art 6(1)(c), Art 17(3)(b)) such as the obligation to keep financial records. Thus, there continues to be a legal basis for processing/keeping the data and rejecting the erasure request in whole or in part. Things are slightly different when the legal basis for this processing was consent (Art 6(1)(a)) or a legitimate interest (Art 6(1)(f)). Consent can always be withdrawn, but this kind of data collection is not typically based on consent. You can sometimes object to processing under a legitimate interest (see Art 21) but that doesn't work when the data controller has overriding legitimate grounds to continue processing. Such overriding grounds might be the legitimate interest to pursue the debt, and Art 21(1) and Art 17(3)(e) explicitly call out the “establishment, exercise or defence of legal claims” as overriding grounds. So that covers requests under A, B and C. Things like legal basis and erasure/objection must be analyzed on a per-purpose basis, so it is possible that you could get a partial erasure, such as erasing information that's only necessary for marketing (compare also objection per Art 21(2)). But its quite clear to me that a data subject cannot get out of paying a bill by using the GDPR.
If the data controller has “reasonable doubts concerning the identity of the natural person making the request”, then “the controller may request the provision of additional information necessary to confirm the identity of the data subject” (Art 12(6) GDPR). Until the data subject provides this information, the request is paused. But what are reasonable doubts, and what additional information can the controller request? The GDPR itself provides no clear guidelines, though general principles apply – the additional information must be necessary, adequate, and proportionate for the identity conformation purpose. The controller's obligation to comply with access requests must be balanced with the controller's obligation to ensure the security of data by rejecting invalid requests. Just accepting any request without any verification would also be a breach of the GDPR. For example: If the company identifies data subjects by email address, then demonstrating control over the email address would be an appropriate verification step. But just mentioning the email address would not be enough since it could be someone else's email address. If the company provides a website where data subjects have created user accounts, then being able to log in to the account would be an appropriate verification step. In these examples, asking e.g. for government photo ID would not be appropriate because that doesn't help strengthen the link between the person making the request and the personal data being processed. Such data collection would be disproportionate and unnecessary. In contrast, if you walk into a bank and ask for a copy of your data, it would be entirely appropriate for them to ask for government ID because (a) the higher general risks warrant stronger checks, and (b) such ID will help confirm that the person making the request is indeed the proper account holder. The bank will also have been legally required to request ID when the account was originally opened, so that asking for ID as an identity verification measure during this later request won't involve collection of more data than they already have. (These examples were made up by me and are not official, but read on.) The EDPB has issued draft guidelines on the right of access 01/2022, which also discuss the issue of additional information for identity verification in sections 3.2 and 3.3. In particular, paragraphs 73-78 talk about IDs: 73. It should be emphasised that using a copy of an identity document as a part of the authentication process creates a risk for the security of personal data and may lead to unauthorised or unlawful processing, and as such it should be considered inappropriate, unless it is strictly necessary, suitable, and in line with national law. […] it is also important to note that identification by means of an identity card does not necessarily help in the online context (e.g. with the use of pseudonyms) […]. 75. In any case, information on the ID that is not necessary for confirming the identity of the data subject, […] may be blackened or hidden by the data subject before submitting it to the controller, except where national legislation requires a full unredacted copy of the identity card (see para. 77 below). […] 76. […] Example: The user Ms. Y has created an account in the online store, providing her e-mail and username. Subsequently, the account owner asks the controller for information whether it processes their personal data, and if so, asks for access to them within the scope indicated in Art. 15. The controller requests the ID of the person making request to confirm her identity. The controller's action in this case is disproportionate and leads to unnecessary data collection. […] Example: A bank customer, Mr. Y,, plans to get a consumer credit. For this purpose, Mr. Y goes to a bank branch to obtain information, including his personal data, necessary for the assessment of his creditworthiness. To verify the data subject’s identity, the consultant asks for notarised certification of his identity to be able to provide him with the required information. The controller should not require notarised confirmation of identity, unless it is strictly necessary, suitable and in line with the national law […]. Such practice exposes the requesting persons to additional costs and imposes an excessive burden on the data subjects, hampering the exercise of their right of access. 77. Without prejudice to the above general principles, under certain circumstances, verification on the basis of an ID may be a justified and proportionate measure, for example for entities processing special categories of personal data or undertaking data processing which may pose a risk for data subject (e.g. medical or health information). However, at the same time, it should be borne in mind that certain national provisions provide for restrictions on the processing of data contained in public documents, including documents confirming the identity of a person (also on the basis of Art. 87 GDPR). Restrictions on the processing of data from these documents may relate in particular to the scanning or photocopying of ID cards or processing of official personal identification numbers. To summarize: controllers can request IDs only in comparatively niche scenarios, and must then take additional safeguards to protect the sensitive document (e.g. instructing the data subject to redact parts of the ID, not making copies, and immediately deleting the ID after successful verification). A lot here comes down to national laws, which may explicitly require or forbid use of the ID in this context. The EDPB guidelines are not binding or normative, especially since this guidance is still in the public consultation phase. However, the guidelines present an overall consensus of the national data protection authorities in the EU, and the guidelines are regularly cited by courts. In practice, many controllers do ask for disproportionate amounts of data. Sometimes this seems to be an attempt to discourage data subject requests, which would clearly be non-compliant. In some cases, this is due to a narrow interpretation of “reasonable doubts” in which they try to eliminate any doubt about the identity. If the data subject and data controller cannot agree on a suitable identity verification process, then the data subject can: Art 77: lodge a complaint with a data protection authority, and/or Art 79: sue the data controller in court, both for compliance (fulfilling the request) and for compensation (if damages were suffered). It is worth noting that the data controller is responsible for being able to demonstrate compliance (Art 5(2) accountability principle), such as demonstrating the apparent reasonable doubts to a supervisory authority or to a court. When the controller requests ID, the controller has the burden of proof to show that this is compliant.
The Right to Access is pretty absolute. However, there are some limitations: Is the service even the Data Controller for the data in question? Here, you're talking about notes of one user about another. Is the platform the controller for the notes, or would the note-taker be the controller? Or both, jointly? If the platform weren't a controller but merely a data processor for these notes, it would be illegal for them to disclose the information. Trish also correctly points out that the GDPR does not apply to processing for purely personal or household purposes, e.g. personal social media use. So GDPR would not provide a basis to compel a user to disclose their notes to the data subject, assuming that the note-taker is covered by this exception. Of course, this exception wouldn't apply if the notes are taken for other purposes, e.g. professional networking. Also, this exception doesn't affect the platform. There is an explicit limitation to the right of access in Art 15(4): The right to obtain a copy referred to in paragraph 3 shall not adversely affect the rights and freedoms of others. Disclosing user A's notes about user B to user B would likely violate the privacy rights of A. The notes are both A's and B's personal data. However, the correct balance depends on context. E.g. an employer probably can't refuse to provide access to a performance assessment merely because it was written by an identifiable manager. The UK ICO has provided detailed guidance on this aspect to the right of access. They propose a three-step test: Step one – Does the request require disclosing information that identifies another individual? For example, it might be possible to redact other people's information (but not in your Mastodon notes example). Step two – Has the other individual provided consent? Step three – Is it reasonable to disclose without consent? What is reasonable is highly context-dependent, but UK data protection law gives some concrete criteria to consider. The EU EDPB has draft guidance on the Right to Access. They note that the Art 15(4) can cover a wide range of rights, not just other people's privacy rights. But as in all things, the data controller is required to strike an appropriate balance between user A and B's conflicting rights. In the Mastodon user notes scenario, I think that the note author's rights to privacy should be considered more important than the data subject's right to access those notes, thus making it possible to reject that part of a DSAR under Art 15(4) GDPR. If we assume that the note-taker A is a (joint) controller for these notes, then it would also be necessary to consult them before making a decision about the access request.
These are only tangentially related to the GDPR A government entity processing data in accordance with a member state law is ipso facto in compliance with the GDPR. That’s because lawful government data processing is a legitimate reason for processing data under the GDPR. If Germany, for example, passes a law saying German police can record every phone call in Germany, then that would be a lawful basis for processing under the GDPR. There may be constitutional or other legal limitations on such a law but as far as the GDPR is concerned, they’re fine.
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.]