How to determine what frequency of GDPR SAR is not excessive? Repeat Subject Access Requests are limited in frequency by the Manifestly unfounded and excessive requests rules. The critical bit seems to be &quot;A request may be excessive if it: repeats the substance of previous requests and a reasonable interval has not elapsed&quot;. This is clarified &quot;how often the data is altered – if information is unlikely to have changed between requests, you may decide you do not need to respond to the same request twice.&quot; The actual legislation says even less, but does say that it up to the controller to show that it is excessive. I was in the process of setting up a cron job to make an SAR to the DVLA requesting a list of organisations that have received my data. This is to know about claims such as parking fines being made under the Protection of Freedoms Act 2012 when something goes wrong with the letters sent. I thought I had read that every 3 months was considered &quot;not excessive&quot; but I cannot find that now. I can think of 2 ways to make this decision, depending on what factors are important in the definition: If the important factor is the use to which the data is to be put, then there is timing defined by the act, and this gives 14 days for a letter to be posted, received, acted upon than the response posted and received. I would say in this context 7 days would not be excessive for a process that could be completely automated. If the important factor is &quot;information is unlikely to have changed between requests&quot; then I would take the distribution of information sharing events in the response to the 1st request, put them into a bayesian model and make requests at the frequency of the low end of the 95% credible interval of getting a change in the time period. It is quite possible, depending on the frequency of information sharing events , the time period for which information is provided as well as the model and prior, that this would be less than 7 days. I either case I would provide this rational in the initial data request, as well as informing them of my intention to make these follow up requests. It would then be up to the data controller to demonstrate that my rules are manifestly excessive. As well as the DVLA, a similar argument could be made for many other organisations such as credit reference agencies. Many people may be interested in making these requests if it was demonstrated useful. As a data subject, what aspects should be considered when making these decisions?
There are no specific criteria for deciding whether a request is manifestly unfounded or excessive, because this depends very much on context. The ICO has given some clarifications, but they still won't tell you an allowed frequency of requests. We (as data subjects) should not invent particular criteria because they would be only our opinion. In any case, the data controller would have burden of proof to show that a request was indeed manifestly unfounded or excessive. That means that a data controller will generally err on the side of caution and allow repeated requests. But that doesn't mean you won't get pushback on your proposed frequency. I think your proposed approach is likely to be both unfounded and excessive. A controller has one month to respond to your request. Sending off a request while a previous request is still pending would likely demonstrate an excessive frequency of requests. Even if the data controller responds more quickly, it is doubtful whether that would entitle you to more frequent updates. Since the data controller will inform you about important events with a letter, this weakens your need to make frequent requests. Your “Bayesian model” is also flawed, both in content and application. As your prior, you expect a very high rate of events. However, a normal citizen would expect to receive a parking fine approximately never. Your model should more correctly be based around the probability of missing an event, while also accounting for letters (which generally do arrive in time). It might also be incorrect to use your circumstances as the basis for determining a reasonable frequency. The ICO suggests multiple factors (nature of the data, purposes of processing, how often the data is altered, relationship with other GDPR rights). These factor's generally relate to the controller's processing, but not to your individual circumstances. Next, your requests seem unfounded: the purpose of your requests is not aligned with the GDPR, and automated requests raise doubt about whether the request is valid. Your motivation to make the requests is “to know about claims such as parking fines […] when something goes wrong with the letters sent”. This is a fairly speculative reason since letters generally do arrive well. In contrast, the GDPR provides for the right to access “in order to be aware of, and verify, the lawfulness of the processing” (Recital 63). You are not claiming the right to access for the purpose of verification and to obtain information about the processing, instead you're abusing the GDPR rights to create a kind of API that auto-updates. So, is three months a hard and fast rule? Definitely not, but it seems like an unobjectionable, reasonable frequency. If a data controller thinks a request every three months is excessive, you'll likely be able to push back successfully. But with more frequent requests, you're entering a grey area. Here, it becomes increasingly likely that the controller is able to demonstrate that your requests are invalid.
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.
See Art. 17(2) GDPR: Where the controller has made the personal data public and is obliged pursuant to paragraph 1 to erase the personal data, the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure by such controllers of any links to, or copy or replication of, those personal data. So the controller must tell all other controllers (like google) to delete the data. The privacy policy must include the fact that data is made public.
Term 1 isn't going to hold up, but that is not a GDPR matter. It's just a matter of basic consumer protection law in the EU. You can't offload responsibility for your mistakes. Looking at 2, Dale M. already pointer out that it's now how the GDPR works. You are the Data Controller. X,Y and Z are Data Processors. Article 28(1) of the GDPR is in direct conflict with your disclaimer. You accept zero responsibility, the GDPR says you are fully responsible. That's the exact opposite.
Any processing of personal data needs a legal basis, for example necessity for some contract or legitimate interest. If no other legal basis allows the processing, you need to acquire consent. Consent must be freely given. If something is gated behind consent without that consent being really necessary, this might coerce users and they would not be able to consent freely. The GDPR does not have a hard ban on this, but it explicitly calls out that this case must be considered when determining whether consent is valid. So what your company is trying to do is in a dark grey area. Not necessarily wrong, but likely so. Consent could be made free if users have an actual choice. For example, some online newspaper sites had success with a “pay or consent” wall. (Success in the sense that some data protection authorities allowed this). In your case, this could mean that users either consent to extra data collection, or that they buy some reasonably priced premium mode. But none of this is for you to decide. You can voice your doubts that the software would be compliant. You could also ask if the Data Protection Impact Assessment document for this proposed processing is available (creating such an assessment is likely mandatory in this case). But in the end, it is the company's obligation to be compliant, and this responsibility is largely shouldered by the company's data protection officer (to whom you can turn with further questions).
GDPR does not cease to apply because of the location of data storage. It applies based on the location of the data processor, data controller, and data subject. If you are in the EU, you are a data subject covered by GDPR. It does not matter where the data are stored. Note that you are asked to confirm that you're aware that US laws may be less protective, but you're not asked to acknowledge that anything about the arrangement causes the "laws of your country/region" not to apply. The company also does not seem to be claiming that they don't apply, although it seems that they want you to think so, and it's not clear whether they think so. You are correct that GDPR doesn't allow its protections to be waived. A data subject may always consent to certain processing, and some processing may be performed without consent, but it's not possible to waive the right to withhold consent for processing that does require it.
Q1. Is there a requirement under GDPR for data processors to disclose sub-processing arrangements and the names of the organisations involved in this? "The processor shall not engage another processor without prior specific or general written authorisation of the controller. In the case of general written authorisation, the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes." -- EU General Data Protection Regulations (GDPR) Article 28 Paragraph 2 This clearly states that the processor would need to make clear that they are subcontracting the services and get permission for this as part of the contract, but doesn't specify whether the subcontractors must be named and identified. Perhaps there is other prior existing subcontracting legislation that requires them to be named? Some procurement contracts as supplied by controllers may specify a list of nominated (allowed) sub-contractors or require the full identification of sub-contractors though I've not found anything in law that requires they be named other than as part of a specific contractual obligation. Q2. Is there a requirement under GDPR for data processors to disclose the country or countries where data is stored and processed? "Processing by a processor shall be governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller and that sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller. That contract or other legal act shall stipulate, in particular, that the processor: ... (h) makes available to the controller all information necessary to demonstrate compliance with the obligations laid down in this Article and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller. ..." -- EU General Data Protection Regulations (GDPR) Article 28 Paragraph 3(h) This clearly states the data processor must make available to the data controller all details required to demonstrate compliance. It's quite likely larger organisations may choose to make this simple for data controllers by supplying this information in the form of a completed Data Privacy Impact Analysis document. "Each controller and, where applicable, the controller's representative, shall maintain a record of processing activities under its responsibility. That record shall contain all of the following information: ... (e) where applicable, transfers of personal data to a third country or an international organisation, including the identification of that third country or international organisation and, in the case of transfers referred to in the second subparagraph of Article 49(1), the documentation of suitable safeguards; ..." -- EU General Data Protection Regulations (GDPR) Article 30 Paragraph 1(e) This clearly states the data controller must maintain a record of the country or countries involved if any of these are outside the EU, and so this information must be made available to the controller as stated above.
It's hard to prove a negative, and I'm not sure which specific part of the quoted Terms you object, to, but it specifically states that content access may be done to: Comply with the law Protect its customers; and Protect the security of its business; and Protect its business interests. It's unlikely that access of information to comply with the law is illegal. At least one EU directive, Directive 95/46/EC, sets limits on the collection and use of personal information. We're concerned with the first condition for lawful data processing, and the second principle of data quality. Data processing is only lawful if the data subject has unambiguously given his consent; or processing is necessary for the performance of a contract to which the data subject is party; or processing is necessary for compliance with a legal obligation to which the controller is subject; or processing is necessary to protect the vital interests of the data subject; or 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 or in a third party; or processing is necessary for the purposes of the legitimate interest pursued by the controller or by the third party, except where such interests are overridden by the interests for fundamental rights and freedoms of the data subject which require protection. The principles of data quality, which must be implemented for all lawful data processing activities, are the following: personal data must be processed fairly and lawfully, and collected for specified, explicit and legitimate purposes. They must also be adequate, relevant and not excessive, accurate and, where necessary, kept up to date, must not be stored for longer than necessary and solely for the purposes for which they were collected; special categories of processing: it is forbidden to process personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, and the processing of data concerning health or sex life. This provision comes with certain qualifications concerning, for example, cases where processing is necessary to protect the vital interests of the data subject or for the purposes of preventive medicine and medical diagnosis. So, let's say that someone has given their consent. It'd be at least a little questionable whether the inspection of private information could mean that they access personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, and the processing of data concerning health or sex life. I'm a bit less clear on US laws, but you'd probably look for laws around Personal Identifying Information, as that's where a lot of focus has been.