gdpr european-union
How to determine what frequency of GDPR SAR is not excessive?
<p>Repeat Subject Access Requests are limited in frequency by the <a href="https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-law-enforcement-processing/individual-rights/manifestly-unfounded-and-excessive-requests/" rel="nofollow noreferrer">Manifestly unfounded and excessive requests rules</a>.  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;  <a href="https://www.legislation.gov.uk/ukpga/2018/12/section/53/enacted" rel="nofollow noreferrer">The actual legislation</a> says even less, but does say that it up to the controller to show that it is excessive.</p>
<p>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 <a href="https://www.gov.uk/government/publications/protection-of-freedoms-bill" rel="nofollow noreferrer">Protection of Freedoms Act 2012</a> 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.</p>
<p>I can think of 2 ways to make this decision, depending on what factors are important in the definition:</p>
<ul>
<li><p>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.</p>
</li>
<li><p>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.</p>
</li>
</ul>
<p>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.</p>
<p>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.</p>
<p>As a data subject, what aspects should be considered when making these decisions?</p>

<p>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.</p>
<p>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.</p>
<p>I think your proposed approach is likely to be <em>both</em> unfounded and excessive.</p>
<p>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.</p>
<p>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 <em>your</em> 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.</p>
<p>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.</p>
<p>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.</p>
