 |
 |
I’m still struggling with the interpretation. Could someone put me out of my misery (or add to it) please?
Taking what seem to be the relevant statements and working in the simplest of examples to illustrate my interpretation which doesn’t acknowledge
any non-working days…
Article 3 (1)
“Where a period expressed in days, weeks, months or years is to be calculated from the moment at which an event occurs or an action takes place, the day during which that event
occurs or that action takes place shall not be considered as falling within the period in question.”
The period in this case is expressed in months i.e. one month. The event i.e. subject access request, occurs at 15.00 on 11th August. The day during which the
event occurs (11th August) shall not be considered as falling within the period in question. So the period in question begins at 00.01 on 12th August.
Article 3 (2) (c)
“a period expressed in weeks, months or years shall start at the beginning of the first hour of the first day of the period, and shall end with the expiry of the last hour
of whichever day in the last week, month or year is the same day of the week, or falls on the same date, as the day from which the period runs. If, in a period expressed in months or in years, the day on which it should expire does not occur in the last month,
the period shall end with the expiry of the last hour of the last day of that month;”
The period starts at the beginning of the first hour of the first day of the period (00.01 on 12th August). The expiry is therefore 23.59 on 12th September.
They key phrase for me is “…shall
not be considered as falling within the period in question.” If the event is stated to not be within the period in question, how is a conclusion reached that the period does start on that day? Did the 2004 case render the regulation wording incorrect
and it went under the radar for 15 years?
Mark
From: This list is for those interested in Data Protection issues <[log in to unmask]>
On Behalf Of Donald Henderson - CHX
Sent: 15 August 2019 16:05
To: [log in to unmask]
Subject: Re: [data-protection] starting the clock - SARs
CAUTION: This email originated
from outside of the organisation. Do not click links or open attachments unless you recognise the sender and believe the content to be safe. If in any doubt, contact IT Services immediately.
Is it just me, or is this all starting sound a bit bonkers? From a member of the public's perspective, they appear to have no certainty about how long a request might take until they submit it.
I must admit, I heard ICO advice pre-GDPR implementation (and pre any advice on what a month was) that we should just use 28 days. We looked at our response time and noted that we either get things out in 2-3 weeks or miss by a country mile. The difference
between 28 days and 31 is, consequently academic as far as we are concerned. For simplicity, therefore, we just use 28 days regardless of holidays.
Donald
-----Original Message-----
From: This list is for those interested in Data Protection issues <[log in to unmask]> On Behalf Of Clay Garland
Sent: 15 August 2019 15:56
To: [log in to unmask]
Subject: Re: [data-protection] starting the clock - SARs
Sorry for the double post, but with regard to public holidays in Scotland as defined in Reg. 1182/71, they (along with those of every other member state) are published for 2019 here:
https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:C2018/466/13&from=FR
This leads to a slight problem, in that the list in the OJEU has Scottish and Northern Irish public holidays the wrong way round. So if you're based in Scotland you can count St Patrick's Day as a non-working day, but not St Andrew's. This is presumably either
a typo in the Journal or a mistake by the Foreign Office - place your bets now.
Regarding official EU holidays, these only apply to EU institutions and are therefore sadly only relevant to SARs submitted to - e.g. the European Commission.
-----Original Message-----
From: This list is for those interested in Data Protection issues <[log in to unmask]> On Behalf Of Clay Garland
Sent: 15 August 2019 15:43
To: [log in to unmask]
Subject: Re: [data-protection] starting the clock - SARs
Bill,
Can't comment on EU public holidays, but a request received on 31st January is due on 28th Feb (or 29th if a leap year), or the first working day afterwards if that isn't a working day.
So a request received on 31st Jan 2019 would have been due 28th Feb 2019, and a request received 31st Jan 2020 would be due on 2nd March 2020 (but only because 29th Feb is a Saturday).
Kind regards,
Clay
-----Original Message-----
From: This list is for those interested in Data Protection issues <[log in to unmask]> On Behalf Of Bill Dunn
Sent: 15 August 2019 15:30
To: [log in to unmask]
Subject: Re: [data-protection] starting the clock - SARs
If we are to use Regulation 1182/71 in addition to Saturday and Sundays, I think that we would go by the FOISA public holidays plus the days that are EU public holidays that are not already included - for Maundy Thursday (9 April), Easter Monday (13 April),
Labour Day (1 May) Ascension Day (21 May), the day after Ascension Day (22 May), Whit Monday (1 June), 21 July (Belgian National Holiday!), 2 November (All Soul's Day), July, 2 November and 24-31 December 2020 (Commission decision 2019/C 38/5). Pity it only
counts towards the final date and not completely discounted.
Just to be clear, if we receive a subject access request at 12:00 on 28 January, the response has to be issued by 11:59 on 28 February? If we receive it at 12:00 on 29 January, we have until 11:59 on 29 February to respond. If on 31 January, 2 February?
If we receive a request at 12:00 on 27 November, the response has to go by 4 January 2021 (thanks to the EU holidays - if they still apply)?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
All archives of messages are stored permanently and are
available to the world wide web community at large at
http://www.jiscmail.ac.uk/lists/data-protection.html
If you wish to leave this list please send the command
leave data-protection to [log in to unmask] All user commands can be found at
https://www.jiscmail.ac.uk/help/subscribers/subscribercommands.html
Any queries about sending or receiving messages please send to the list owner
[log in to unmask]
Full help Desk - please email [log in to unmask] describing your needs
To receive these emails in HTML format send the command:
SET data-protection HTML to [log in to unmask]
(all commands go to [log in to unmask] not the list please)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[University of Central Lancashire]
Please consider the environment before printing
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
All archives of messages are stored permanently and are
available to the world wide web community at large at
http://www.jiscmail.ac.uk/lists/data-protection.html
If you wish to leave this list please send the command
leave data-protection to [log in to unmask] All user commands can be found at
https://www.jiscmail.ac.uk/help/subscribers/subscribercommands.html
Any queries about sending or receiving messages please send to the list owner
[log in to unmask]
Full help Desk - please email [log in to unmask] describing your needs
To receive these emails in HTML format send the command:
SET data-protection HTML to [log in to unmask]
(all commands go to [log in to unmask] not the list please)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
All archives of messages are stored permanently and are
available to the world wide web community at large at
http://www.jiscmail.ac.uk/lists/data-protection.html
If you wish to leave this list please send the command
leave data-protection to [log in to unmask] All user commands can be found at
https://www.jiscmail.ac.uk/help/subscribers/subscribercommands.html
Any queries about sending or receiving messages please send to the list owner
[log in to unmask]
Full help Desk - please email [log in to unmask] describing your needs
To receive these emails in HTML format send the command:
SET data-protection HTML to [log in to unmask]
(all commands go to [log in to unmask] not the list please)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The information in this email is solely for the intended recipients.
If you are not an intended recipient, you must not disclose, copy, or distribute its contents or use them in any way: please advise the sender immediately and delete this email.
Perth & Kinross Council does not warrant that this email or any attachments are virus-free and does not accept any liability for any loss or damage resulting from any virus infection. Perth & Kinross Council may monitor or examine any emails received by its
email system.
The information contained in this email may not be the views of Perth & Kinross Council. It is possible for email to be falsified and the sender cannot be held responsible for the integrity of the information contained in it.
General enquiries to Perth & Kinross Council should be made to
[log in to unmask] or 01738 475000.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
All archives of messages are stored permanently and are
available to the world wide web community at large at
http://www.jiscmail.ac.uk/lists/data-protection.html
If you wish to leave this list please send the command
leave data-protection to [log in to unmask]
All user commands can be found at
https://www.jiscmail.ac.uk/help/subscribers/subscribercommands.html
Any queries about sending or receiving messages please send to the list owner
[log in to unmask]
Full help Desk - please email [log in to unmask] describing your needs
To receive these emails in HTML format send the command:
SET data-protection HTML to [log in to unmask]
(all commands go to [log in to unmask] not the list please)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
National Star, National Star College, StarBistro, StarShop, StarGolf, StarGlamping, StarPrint, StarArts, StarSports, StarTechnology, StarTraining, LiftTraining and Steps into Work are working names of National Star Foundation which is registered in England and Wales, company number 522846, charity number 220239. Registered office Ullenwood Manor, Ullenwood, Cheltenham, Gloucestershire, GL53 9QU
All archives of messages are stored permanently and are available to the world wide web community at large at http://www.jiscmail.ac.uk/lists/data-protection.html
Selected commands (the command has been filled in below in the body of the email if you are receiving emails in HTML format):
All user commands can be found at https://www.jiscmail.ac.uk/help/subscribers/subscribercommands.html and are sent in the body of an otherwise blank email to [log in to unmask]
Any queries about sending or receiving messages please send to the list owner [log in to unmask]
(Please send all commands to [log in to unmask] not the list or the moderators, and all requests for technical help to [log in to unmask], the general office helpline)